HDD Problem

Aussie · 11-15-2002, 03:24 AM

Redhat kernels = Alan Cox kernels.....have you tried 2.4.19 from the -ac tree?

dnar · 11-15-2002, 03:49 AM

No, as I am relying on Netraverse kernel patches in order to run Win4Lin, I am limited to the kernel tree's that I can try. I have found messages on the Kernel threads that state via82cxxx.c 3.35 can be applied to the 2.4.19 kernel, and it appears to work fine, so far!

/famous last words.

BTW, I can tolerate many "flaky" things in a kernel, but disk corruption just plain sucks!

dnar · 11-15-2002, 05:28 AM

Damn, I thrashed the drive with LARGE reads & writes, all was good, then booted to my rescue disk and individually fsck'd all partitions to check for bad blocks. No bad blocks found. I then booted back to my main system, and what do you know? Really poor DMA performance, like hdparm -tT results around 1 - 2 M... Then dma errors galore in the logs...

The disk occasionally "locks" and all system activity comes to a stand still, for around 20 seconds, then it comes back....

I re-booted again and it's fine, then again it's bad. It appears that the reliability is dependant on something "magic" at boot time, like a lottery... Weird timming issue maybe? Back to running no DMA until I can find out more...

At least I know the drive is A Ok, no bad blocks... Not happy about no DMA, but at least everything is stable and reliable with no DMA.

Aussie · 11-15-2002, 05:32 AM

And perhaps time to try vmware......where there are no special kernel requirements needed.

dnar · 11-15-2002, 05:37 AM

Been there, done that... I only use Windows/Win4Lin to run MYOB Accounting and a few development tools like Protel and intel compilers. VMware is a lot more overhead, and is much slower to load and run.

To be honest, Win4Lin is fantastic, shame the netraverse patches never make it into the standard kernel as compile time options... The patches are pretty basic and mostly to do with memory.

dnar · 11-15-2002, 05:41 AM

Damn, now I am getting more IDE errors:-

Quote:

Nov 17 03:41:16 Criten kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
Nov 17 03:41:16 Criten kernel: hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=962, sector=962
Nov 17 03:41:16 Criten kernel: end_request: I/O error, dev 03:00 (hda), sector 962
Nov 17 03:41:22 Criten kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
Nov 17 03:41:22 Criten kernel: hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=964, sector=964
Nov 17 03:41:22 Criten kernel: end_request: I/O error, dev 03:00 (hda), sector 964
Nov 17 03:41:38 Criten kernel: hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
Nov 17 03:41:38 Criten kernel: hda: read_intr: error=0x40 { UncorrectableError }, LBAsect=1136, sector=1136
Nov 17 03:41:38 Criten kernel: end_request: I/O error, dev 03:00 (hda), sector 1136

This is just not a DMA issue, it now appears... When that block of errors where produced, the system stopped for approx 20 seconds...

Aussie · 11-15-2002, 06:40 AM

I'd be backing out of that patch if I were you.

dnar · 11-15-2002, 07:22 AM

Ok, more discoveries... I backed out of the patch as you have suggested, the same deal. I repeatedly issue hdparm -t tests, the results are changing significantly. It's like a wave, starts at 40M/s and reduces down to sub-1M rates (this is when the system stops and the kernel messages appear), then jumps back up to around 40 M/s.

Now, I have always ran the "-c3" option for 32 bit transfers WITH sync. I changed this to "-c1" - 32 bit transfers with no sync, and all is well again. This is repeatable which is good. I will continue to thrash the drive and do a few reboots (yikes) and let you know what I find...

dnar · 11-15-2002, 07:26 AM

These are the settings I am using now, with great sucess, using DMA, no errors and consistent transfer rates, so far...

Code:

[root@criten wayne]# /sbin/hdparm /dev/hda

/dev/hda:
 multcount    = 16 (on)
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  1 (on)
 readonly     =  0 (off)
 readahead    =  1 (on)
 geometry     = 4866/255/63, sectors = 78177792, start = 0

[root@criten wayne]# /sbin/hdparm -i /dev/hda

/dev/hda:

 Model=MAXTOR 6L040J2, FwRev=A93.0500, SerialNo=662217243206
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4
 BuffType=DualPortCache, BuffSize=1819kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78177792
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1:  1 2 3 4 5

[root@criten wayne]# /sbin/hdparm -tT /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.56 seconds =228.57 MB/sec
 Timing buffered disk reads:  64 MB in  1.66 seconds = 38.55 MB/sec
[root@criten wayne]#

Aussie · 11-15-2002, 09:02 AM

This is my hda,

Code:

 root@grendel bern# hdparm /dev/hda

/dev/hda:
 multcount    =  1 (on)
 IO_support   =  3 (32-bit w/sync)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 1027/255/63, sectors = 16514064, start = 0
root@grendel bern# hdparm -i /dev/hda

/dev/hda:

 Model=QUANTUM FIREBALLlct08 08, FwRev=A05.0X00, SerialNo=692936152914
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4
 BuffType=DualPortCache, BuffSize=418kB, MaxMultSect=16, MultSect=1
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=16514064
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 *udma4
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: ATA/ATAPI-4 T13 1153D revision 15:  1 2 3 4

root@grendel bern# hdparm -tT /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.61 seconds =209.84 MB/sec
 Timing buffered disk reads:  64 MB in  3.25 seconds = 19.69 MB/sec
root@grendel bern#

dnar · 11-15-2002, 09:10 AM

This is weird:

Code:

multcount    =  1 (on) <--- Minimum settings is typically 2 or 4, generally best set to 8 or 16

What distro & kernel?

mcleodnine · 11-15-2002, 10:00 AM

A couple of other things to look into...

Have you checked your drive temperature? I had a near meltdown this past winter when the big fan in the case died. System hard-locked and drives were too hot to touch.

Also - are you running smartd? I've run across a few threads that point to it as a cause of grief. I use it with no probs but it may be worth a look into.

One more question - are you overclocking the bus?

dnar · 11-15-2002, 10:39 AM

Drive temp is ok, this is in a full size tower case, with multiple intake/exhaust fans...

Smartd - no.

Overclocking? Not yet, PCI running at stock 33Mhz... This is a brand new Gigabyte GA-7VAXP motherboard, with the new KT400/VT8235 chipset, I wanted to run a few weeks at stock bus speed/CPU until stability had been proven...

Anyways, since going from 32-bit +Sync to 32-Bit no sync, the drive has not produced one error...

Postalbunny · 11-15-2002, 04:36 PM

/dev/hda:

Model=Maxtor 6Y060L0, FwRev=YAR41VW0, SerialNo=Y29CR6PE
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=120103200
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 *udma4 udma5 udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: (null): 1 2 3 4 5 6 7

What wories me is the coforms to "null" and it's in udma4, would 6 be safe and faster? and it doesn't appear to have pio or dma set... thi sis on the NEW 60gb maxtor I bought which hasn't been giving me any problems ... yet

It test at 14MB/s though and it's on an ultra66 so i figure something is messed up.

Any input would be appreciated, ps. i bought a new udma cable to just in case the other one was FUBAR.

Aussie · 11-15-2002, 05:10 PM

Quote:

Originally posted by dnar
This is weird:

Code:

multcount = 1 (on) <--- Minimum settings is typically 2 or 4, generally best set to 8 or 16

What distro & kernel?

Distro? <--look over there :-)
Kernal 2.4.19