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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
