Re: Follow up? LibPATA code issues / 2.6.15.4 (found the opcode=0x35)!

[Mark Lord <liml@rtr.ca>]

>Jeff/Mark, from these errors can we reach a consensus as to the cause
>of these errors and how to eliminate the problem? 

It is up to the current subsystem maintainer to help investigate this
and come up with a solution, in cooperation with eager testers such
as yourself.  I gave away my kernel subsystem maintainer's duties about
seven years ago, because it just takes too much time to do it really well.

In this case, I'm proving a tiny amount of help, simply because I don't
see anyone else even trying, and there is obviously something wrong here.

Now.. your hacked version of my simple patch is incorrect.  It is frequently
dumping out ata_op=0x51, which is obviously the ATA status value not the
original ATA command byte.

But ignoring that, we also see some valid output from where it does trip
the code from my original patches:  ata_op=0x35.

So, the drive is rejecting an LBA48 WRITE operation, which should happen
only if the drive does not have LBA48 support.  Now, I know you posted all
of this nice info months ago, but let's see it again now, for the exact
drive that is generating that specific message.  We need to see the output
from "hdparm --Istdout /dev/sdX" for that drive.

Thanks