HDD Problem
 

I just got a new maxtor 30gb HD to slap into an old celeron computer and use as a router. I installed and noticed this msg in the logs today.

Nov 13 01:46:13 bunnymafia kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Nov 13 01:46:13 bunnymafia kernel: hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=17510397, sector=17301552
Nov 13 01:46:13 bunnymafia kernel: end_request: I/O error, dev 03:02 (hda), sector 17301552
Nov 13 01:46:13 bunnymafia kernel: EXT3-fs error (device ide0(3,2)): ext3_get_inode_loc: unable to read inode block - inode=1077162, block=2162694
Nov 13 01:46:18 bunnymafia kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Nov 13 01:46:18 bunnymafia kernel: hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=4665341, sector=4456496
Nov 13 01:46:18 bunnymafia kernel: end_request: I/O error, dev 03:02 (hda), sector 4456496
Nov 13 01:46:18 bunnymafia kernel: EXT3-fs error (device ide0(3,2)): ext3_get_inode_loc: unable to read inode block - inode=277488, block=557062
Nov 13 01:46:22 bunnymafia sshd(pam_unix)[1634]: session opened for user root by (uid=0)
Nov 13 01:46:24 bunnymafia kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Nov 13 01:46:24 bunnymafia kernel: hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=13316085, sector=13107240
Nov 13 01:46:24 bunnymafia kernel: end_request: I/O error, dev 03:02 (hda), sector 13107240
Nov 13 01:46:24 bunnymafia kernel: EXT3-fs error (device ide0(3,2)): ext3_get_inode_loc: unable to read inode block - inode=816028, block=1638405

The HD is auto-detected, so is it decting the wrong LBA or is the HD bad... or is linux freaking out over a misconfiguration?

Check the IDE cable, I used to get errors like this and it was a bad cable.

Thanks, i'll give that a shot. It is a really old IDE cable, i'm taking the HDD back as well just because I bought it 2 days ago and they won't have any problems taking it back and swapping it out. I've sense ran a fsck -v -c on it and it comes up with more bad blocks every day. It's up to 817 bad blocks now, and comes up with short reads when I try to access certain files. I've tried other cables that are udma that are even older and they give same errors in same spots, and seem to work fine with other drives from my other computer. Hopefully it's not the the HDD controler on the motherboard :)

I have the same problem, Maxtor 40GB on a Gigabyte GA-7VAXP (KT400 & 8235 chipset). If I turn off DMA, the problem goes away...

Still looking around, it appears to be a problem with VIA & the kernel...

What kernel version are you running dnar?

2.4.19 plain vanilla.

Ok, from a quick search of the LKML it seems that support for the kt400 is in the 2.5.xx kernel and a patch for 2.4.xx is in the works. You best bet is to upgrade as soon as support arives, probably in 2.4.21pre*.

Snap, found that just a while ago too. I have turned off DMA on this drive, but man I miss it... :rolleyes:

Thanks for the help. :)

Brisvegas LOL...

BTW, I did a little touring of Qld, mostly Fortitude Valley :rolleyes: in the mid-80's with a rock band...

Yeah, I've been waiting for support for this chipset before I upgrade my 1g tbird and kt7a, built it in jan 00 and it was a killer then....bit old now, but it still works well.
Mid 80's....I was living down near Byron Bay untill 87, then at New Farm for a few years.

I reluctantly upgraded a 1000 Tbird (running 1450) and EPoX 8KTA3/PC150 rig last week... I was burned with KT133a problems and just expected the KT400 to be an improvement. In reality, it look slike the VT8235 SouthBridge is the issue here. I have looked at ide-via.c and notice "future" support for the 8235 chip in the chipset table structure, but cant find the where the conditional test would be defined (so I asume its not). I dont feel like "breaking" my filesystems one more time this week, so I will leave DMA off and wait patiently for a new kernel...

Byron, very cool... :cool:

I tried turing off DMA but it was after fsck already marked 800 bad blocks on the disk... so the data kept giving "short reads". I went ahead and toook the whole thing back because it did it when I slapped it into my other machine (diff cbls and chipset). It's not a fast computer or antyhing, old sis chipset with ulta66 and a celeron 500 CPU /w 128mb pc100 sdram (doest go 133... just 100). I think it was the HDD, i got a 60gb 7200rpm maxtor because the 30gb we're not on sale ($54 @ frys... 60gb was $89).

One more thing about the prob, when i ran fsck -c -y it would go through but ask if it wanted ot "ignore" a short read or error and fix some of them that were bad blocks etc... then reboot and find "inconsistancies" and force fsck again and reboot etc... was that just because the filesystem got corrupted or because the HDD was bad and kept giving different responses?

I got anyone quick question while I got someone on the line. When I try hdparm -t /dev/hda or -T it never seems to get 66mb/s which I thought ulta66 would do correct? Even playing with the params I can only get up to 5Megs a second, and it's about 4-5 with default settings... am I missing something or is this a readout different from something? I did buy a new ultraDMA cbl just in case that was it... seems like 5mb instead of 66 (and the drive is Ultra133) is a LOT slower.

Do 'hdparm -i /dev/hda" to see what the drive is set to, eg;

If you get "short reads" while doing an "e2fsck" - I can guarrantee that the errors reported will be bogus and the fixups will not be right. Instead, abort out and do "e2fsck -c" to find and mark bad blocks.

I hand patched the via82cxxx.c from version 3.34 (2.4.19 kernel) to 3.35 - this adds support for the VIA VT8235 Southbridge. This appears to have solved the problem, but I will not be 100% confident until I it's run for a few days. I am watching the kernel logs like a hawk.

BTW, the RedHat 8.0 kernel (2.4.18-14) appears to be patched already. The reason I updated to 2.4.19 was that I run Win4Lin and require a patched kernel, and patches for RedHat 8 kernel where not initially available, yet patches for the plain 2.4.19 where. So, if your running the RedHat 8 kernel, you should be ok.