Re: Problem with ata layer in 2.6.24

[Gene Heskett <gene.heskett@gmail.com>]

On Monday 28 January 2008, Mark Lord wrote:
>> [   64.037975] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
>> [   64.038102] ata1.00: BMDMA stat 0x65
>> [   64.038227] ata1.00: cmd c8/00:58:89:3d:07/00:00:00:00:00/e0 tag 0 dma
>> 45056 in [   64.038229]          res 51/40:58:8b:3d:07/00:00:00:00:00/e0
>> Emask 0x9 (media error) [   64.038432] ata1.00: status: { DRDY ERR }
>> [   64.038555] ata1.00: error: { UNC }
>> [   64.050125] ata1.00: configured for UDMA/100
>> [   64.050134] sd 0:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
>> [   64.050138] sd 0:0:0:0: [sda] Sense Key : 0x3 [current] [descriptor]
>> [   64.050142] Descriptor sense data with sense descriptors (in hex):
>> [   64.050143]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
>> [   64.050149]         00 07 3d 8b
>> [   64.050152] sd 0:0:0:0: [sda] ASC=0x11 ASCQ=0x4
>> [   64.050155] end_request: I/O error, dev sda, sector 474507
>
>..
>
>This error looks somewhat different from the samples posted earlier.
>This one is quite definitively a "bad sector".
>
>It should also show up in "smartctl -a -data /dev/sda" (near the bottom)
>if SMART was enabled on this drive at boot.
>
It does not unforch.

>You could try reading that specific sector again just to make sure.
>One way is to figure out how to use "dd" for this.
[root@coyote ~]# dd if=/dev/sda bs=512 skip=474506 count=3
��▒6
{�G���G���libkdecorations.so.1.0.0��c�®���J{�G���G���libkfontinst.so.0.0.0��c�®����"ʂ�GP�~GJ3G 
6�7�8�#��z;����{�G���G���libkhotkeys_shared.so.1.0.0��c�®���N{�G���G���libkickermain.so.1.0.0��c�®���Y{�G���G���libkonq.so.4.2.0��c�®���Z{�G���G���libkonqsidebarplugin.so.1.2.0��c�®���d{�G���G���libksgrd.so.1.2.0��c�®����▒��G7 
G▒�=G▒]��^���▒?����e{�G���G���libksplashthemes.so.0.0.0��c�®����{�G���G���libtaskbar.so.1.2.0��c�®����{�G���G���libtaskmanager.so.1.0.0��c�®�3+0 
records in
3+0 records out
1536 bytes (1.5 kB) copied, 6.1403e-05 s, 25.0 MB/s

>Another way is to use the "make_bad_sector" utility that
>is included in the source tarball for hdparm-7.7, as follows:
>
>   make_bad_sector --readback /dev/sda 474507
>
Apparently not in the rpm, darnit.

>(when invoked as above, it does *not* "make" a bad sector; no worries).
>
>If it reports an I/O error consistently on that, then the sector is
>indeed faulty, and it's contents have long been lost.
>
>You can repair the bad sector (but not the original contents) like this:
>
>   make_bad_sector --rewrite /dev/sda 474507
>
>Cheers

I'm going up to Clarksburg this afternoon to see if I can find a couple of 
drives, one a 2.5" bigger than 40Gb for my 2.5" maxtor usb housing, and 
another pata drive big enough to run this thing & just re-install the 
December respin after I save as much of this as I can, there's nearly 50GB 
here now.

Maybe it won't be so fscking picky about the next drive.

I was hoping someone could look at that last dmseg I attached, but apparently 
everybody is blinded by unrelated details as that bad sector may have been 
transient, caused by the multiple hardware reset type reboots so far today :(

The last 3 reboots have interrupted a 'smartctl -t long /dev/sda' in 
progress. :(

If I reconvert to non libata, can I do that only for the pata drives of which 
there are 3 here including the dvd writer, and still use libata for the lone 
sata drive left?

And can I do that without mucking with the device map, which will make 
amanda/tar attempt to do a level 0 on the whole system if its changed.  I see 
the drives are at 254 again, when are they going to be given a stable device 
address out of the LANANA experimental group so we can reboot without mucking 
with that and driving tar crazy?

Thanks everybody.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
I just had my entire INTESTINAL TRACT coated with TEFLON!