VIA KT133A crash *post* 2.4.3-ac6
This seems to just run and run... Sorry I couldn't report this earlier, but I've only just got this machine...
With DMA (UDMA Mode 5) enabled, my machine crashes on kernel versions from 2.4.3-ac7 onwards up to 2.4.5 right up to 2.4.5-ac13. 2.4.3 vanilla and 2.4.3-ac6 are completely stable. -ac7 of course is when a load of VIA fixes were done. :-}
Details:
System is:
CPU: Athlon 1.33 GHz with 266MHz FSB
Mobo: Asus A7V133 with 266MHz FSB, UltraDMA100 (PDC20265 according to kernel boot messages)
BIOS has been updated to latest available (massively unstable before)
512Mb PC133 RAM
Voodoo 3
3Com 3C905B
IBM UDMA100 41Gb Deskstar
Software:
SuSE 7.1 updated to current-everything
SuSE default kernel and self-built kernels of various versions
Symptoms:
With DMA disabled, *all* kernels are completely stable.
With DMA (any setting, but UDMA mode 5 preferred of course) enabled, on kernels 2.4.3-ac7 and onwards, random lockup on disk access within first few minutes of use - sometimes very quickly after boot, sometimes as much as ten minutes later given use. Running bonnie -s 1024 once or twice after boot generally excites it too. :-}. Lockup is pretty severe: machine goes completely unresponsive, Magic SysRq doesn't work. About the only thing that does still work is the flashing VGA cursor. :-)
Actual tested kernels:
2.4.0.SuSE, 2.4.0 vanilla, 2.4.3 vanilla, 2.4.3-ac6 - No failure 2.4.3-ac7, 2.4.4 vanilla, 2.4.5 vanilla, 2.4.5-ac13 - Failure.
Signature · 1 line
Rachel
Quoted 4 lines
With DMA (UDMA Mode 5) enabled, my machine crashes on kernel versions from 2.4.3-ac7 onwards up to 2.4.5 right up to 2.4.5-ac13. 2.4.3 vanilla and 2.4.3-ac6 are completely stable. -ac7 of course is when a load of VIA fixes were done. :-}
I encountered the same problem after 2.4.3-ac6.
Quoted 2 lines
CPU: Athlon 1.33 GHz with 266MHz FSB
Mobo: Asus A7V133 with 266MHz FSB, UltraDMA100 (PDC20265 according to
So you put your IBM drive on the promise, right?
Removing the hard disc from the promise controller and attaching it on the VIA-Controller solved my problems. The system is now rock solid. If you do so, take care that your root partition moves from hde to hda. Prepare a boot disk and pass a parameter like root=/dev/hda to the kernel. After a successful boot, modify fstab and lilo.conf and run lilo.
Quoted 1 line
With DMA disabled, *all* kernels are completely stable.
same for me.
Quoted 8 lines
With DMA (any setting, but UDMA mode 5 preferred of course) enabled, on kernels 2.4.3-ac7 and onwards, random lockup on disk access within first few minutes of use - sometimes very quickly after boot, sometimes as much as ten minutes later given use. Running bonnie -s 1024 once or twice after boot generally excites it too. :-}. Lockup is pretty severe:
machine goes completely unresponsive, Magic SysRq doesn't work. About the only thing that does still work is the flashing VGA cursor. :-) Please read the FAQ at http://www.tux.org/lkml/
sounds absoluty identical to my problem with ASUS A7V133 I reported some weeks ago.
Quoted 6 lines · Christian Bornträger
Quoted 3 lines
CPU: Athlon 1.33 GHz with 266MHz FSB
Mobo: Asus A7V133 with 266MHz FSB, UltraDMA100 (PDC20265 according toSo you put your IBM drive on the promise, right?
Oh yes. :-)
Quoted 7 lines
Removing the hard disc from the promise controller and attaching it on the VIA-Controller solved my problems. The system is now rock solid. If you do so, take care that your root partition moves from hde to hda. Prepare a boot disk and pass a parameter like root=/dev/hda to the kernel. After a successful boot, modify fstab and lilo.conf and run lilo.
Yeah, OTOH I'm also happy for the time being running 2.4.3 (actually 2.4.3-ac6 right now) which is OK at full-speed UDMA5, until the problem is fixed. Just thought people might like to know. :-)
Quoted 3 lines
sounds absoluty identical to my problem with ASUS A7V133 I reported some weeks ago.
I only just joined, to report this - I did scan the archives though, and saw a lot of *older* discussion of VIA problems, but didn't see anything that definitely said it was still there after the 2.4.3-ac7 fixes, so wasn't sure if anyone was on the case. :-)
Signature · 1 line
Rachel
Quoted 4 lines
With DMA (UDMA Mode 5) enabled, my machine crashes on kernel versions from 2.4.3-ac7 onwards up to 2.4.5 right up to 2.4.5-ac13. 2.4.3 vanilla and 2.4.3-ac6 are completely stable. -ac7 of course is when a load of VIA fixes were done. :-}
Unfortunately there isnt a great deal I can do but say 'talk to VIA'.
Quoted 4 lines
With DMA (any setting, but UDMA mode 5 preferred of course) enabled, on kernels 2.4.3-ac7 and onwards, random lockup on disk access within first few minutes of use - sometimes very quickly after boot, sometimes as much as ten minutes later given use. Running bonnie -s 1024 once or
Yep. Lots of people see these. I even have people reporting it and not reporting it on the same board.
Only known cure its to not use DMA.
Quoted 2 lines
VIA-Controller solved my problems. The system is now rock solid. If you do so, take care that your root partition moves from hde to hda. Prepare a boot
Certain IBM drives require a promise bios update too
Quoted 12 lines · Alan Cox
Quoted 4 lines
With DMA (UDMA Mode 5) enabled, my machine crashes on kernel versions from 2.4.3-ac7 onwards up to 2.4.5 right up to 2.4.5-ac13. 2.4.3 vanilla and 2.4.3-ac6 are completely stable. -ac7 of course is when a load of VIA fixes were done. :-}
Unfortunately there isnt a great deal I can do but say 'talk to VIA'.
Quoted 4 lines
With DMA (any setting, but UDMA mode 5 preferred of course) enabled, on kernels 2.4.3-ac7 and onwards, random lockup on disk access within first few minutes of use - sometimes very quickly after boot, sometimes as much as ten minutes later given use. Running bonnie -s 1024 once or
Quoted 4 lines
Yep. Lots of people see these. I even have people reporting it and not reporting it on the same board.
Only known cure its to not use DMA.
So is there no correlation from particular hardware to problems reported? I'm running the A7V133 with a Western Digital WD300BB UDMA 5 drive on kernel 2.4.5 with no trouble.
Quoted 4 lines · Thomas Molina
So is there no correlation from particular hardware to problems reported? I'm running the A7V133 with a Western Digital WD300BB UDMA 5 drive on kernel 2.4.5 with no trouble.
Well, I don't know. I'd guess there'd *have* to be some correlation, but we're not gathering enough information to see the pattern. ie: which BIOS version, what exact BIOS options are set, what processor/speed, what memory, what exact model of hard disk... We just may not have a big enough sample size. Even in my case the crashes aren't predictable in nature - 2.4.4 passed my bonnie test the first time, making me think the problem was introduced in 2.4.5, and only failed later in normal usage - next time I tested it it failed in the first minute or so. *Most* of the time failures occur during the bonnie test, but at all sorts of random times during the test.
<redundant>as long as you're sure you do have DMA enabled that is - SuSE at least leaves it disabled by default, under which conditions all kernels are stable for me</redundant>
Signature · 1 line
Rachel
Quoted 6 lines · Rachel Greenham
Quoted 4 lines · Thomas Molina
So is there no correlation from particular hardware to problems reported? I'm running the A7V133 with a Western Digital WD300BB UDMA 5 drive on kernel 2.4.5 with no trouble.
Quoted 10 lines
Well, I don't know. I'd guess there'd *have* to be some correlation, but we're not gathering enough information to see the pattern. ie: which BIOS version, what exact BIOS options are set, what processor/speed, what memory, what exact model of hard disk... We just may not have a big enough sample size. Even in my case the crashes aren't predictable in nature - 2.4.4 passed my bonnie test the first time, making me think the problem was introduced in 2.4.5, and only failed later in normal usage - next time I tested it it failed in the first minute or so. *Most* of the time failures occur during the bonnie test, but at all sorts of random times during the test.
I'm certainly willing to provide any data it's decided is necessary to collect to make the correlations. I'll even volunteer to be the collection point for such data. Beyond mainboard version, bios version, and perhaps hard drive info I'm not sure what's appropriate.
I've tried most of the tests you all have been discussing, with a couple of exceptions. I haven't tried bonnie ( don't even know where to get it or what it is supposed to test ). I do create a number of CDs each week so I am copying a moderate amount of data per session; my setup may be a bit different - I have the hard drive on the promise interface (ide2) and cdroms on the first ide interface (ide0) so I'm probably not testing the same ide-to-ide copy problem that others are seeing.
Quoted 3 lines
<redundant>as long as you're sure you do have DMA enabled that is - SuSE at least leaves it disabled by default, under which conditions all kernels are stable for me</redundant>
Fairly certain. I could be misinterpreting things, though. Here is some output I'm seeing:
[root@localhost /root]# hdparm -tT /dev/hde
/dev/hde:
Timing buffer-cache reads: 128 MB in 0.70 seconds =182.86 MB/sec
Timing buffered disk reads: 64 MB in 2.31 seconds = 27.71 MB/sec
[root@localhost /root]# hdparm /dev/hde
/dev/hde:
multcount = 0 (off) I/O support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead = 8 (on)
geometry = 3649/255/63, sectors = 58633344, start = 0
[root@localhost /root]# hdparm -i /dev/hde
/dev/hde:
Model=WDC WD300BB-00AUA1, FwRev=18.20D18, SerialNo=WD-WMA6W1592536 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq
}
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=58633344 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 udma0 udma1 udma2 udma3 udma4 *udma5
Quoted 2 lines
I'm certainly willing to provide any data it's decided is necessary to collect to make the correlations. I'll even volunteer to be the
.
Quoted 1 line
bit different - I have the hard drive on the promise interface (ide2) and
If possible, can you remove the hard disc from the promise and attach it on the VIA-Controller and test if the problem still occurs? (prepare a bootdisc if you cannot boot. Propably, you have to pass a new root-partition to the kernel)
I hardly believe that the promise controller has some problems with the new VIA setup introduced in 2.4.3-ac7. Using the promise ports of the A7V133 is the only correlation I see again and again...
--
PS: Sorry for using outlook, but sometimes you use an computer you doesn´t own. :-)
Quoted 4 lines · Thomas Molina
I've tried most of the tests you all have been discussing, with a couple of exceptions. I haven't tried bonnie ( don't even know where to get it or what it is supposed to test ).
Well, it's part of the SuSE distribution at least, and it tests hard disk performance - you need to give it a test size greater than your system's memory or all you're testing is Linux's ability to buffer reads and writes. :-) So for my 512Mb system I use "bonnie -s 1024"
Quoted 8 lines
Quoted 4 lines
<redundant>as long as you're sure you do have DMA enabled that is - SuSE at least leaves it disabled by default, under which conditions all kernels are stable for me</redundant>
Fairly certain. I could be misinterpreting things, though. Here is some output I'm seeing:
Compare:
Quoted 6 lines
[root@localhost /root]# hdparm -tT
/dev/hde
/dev/hde:Timing buffer-cache reads: 128 MB in 0.70 seconds =182.86 MB/sec Timing buffered disk reads: 64 MB in 2.31 seconds = 27.71 MB/sec
root@hex:/home/rachel > hdparm -tT /dev/hde
/dev/hde:
Timing buffer-cache reads: 128 MB in 0.66 seconds =193.94 MB/sec Timing buffered disk reads: 64 MB in 2.11 seconds = 30.33 MB/sec
Quoted 11 lines
[root@localhost /root]# hdparm
/dev/hde
/dev/hde:multcount = 0 (off) I/O support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead = 8 (on)
Quoted 2 lines
geometry = 3649/255/63, sectors = 58633344, start = 0
root@hex:/home/rachel > hdparm /dev/hde
/dev/hde:
multcount = 16 (on) I/O support = 3 (32-bit w/sync) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead = 8 (on)
geometry = 79780/16/63, sectors = 80418240, start = 0
I have 32-bit IO (with sync) and multiple sector transfers enabled, where you don't. I don't expect that's the cause of the problem though - For instance, I can run reliably with any kernel with those enabled, as long as DMA is disabled.
Quoted 5 lines
[root@localhost /root]# hdparm -i
/dev/hde
/dev/hde:
Quoted 10 lines
Model=WDC WD300BB-00AUA1, FwRev=18.20D18, SerialNo=WD-WMA6W1592536 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=58633344 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 udma0 udma1 udma2 udma3 udma4 *udma5
root@hex:/home/rachel > hdparm -i /dev/hde
/dev/hde:
Model=IBM-DTLA-305040, FwRev=TW4OA60A, SerialNo=YJEYJLG3070 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40 BuffType=DualPortCache, BuffSize=380kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=80418240 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 Drive Supports : Reserved : ATA-2 ATA-3 ATA-4 ATA-5 Kernel Drive Geometry LogicalCHS=79780/16/63 PhysicalCHS=79780/16/63
. o O ( Dont' suppose any of this is useful to anyone... )
Signature · 1 line
Rachel
I remember seeing something about how some via ide chipsets (686b I think) and [some?] ide promise controllers had problems with data corruption on the IBM dtla-series udma drives, and that IBM stated the problem was with the controllers. Is there a chance a problem like that could be screwing up the kernel?
justin
Quoted 6 lines · Justin Guyett
I remember seeing something about how some via ide chipsets (686b I think) and [some?] ide promise controllers had problems with data corruption on the IBM dtla-series udma drives, and that IBM stated the problem was with the controllers. Is there a chance a problem like that could be screwing up the kernel?
It's a thought - but then why only with some kernel versions?
/me wonders if everyone who's having this problem is using IBM dtla drives...
Signature · 1 line
Rachel
Quoted 8 lines · Christian Bornträger
Quoted 8 lines
If possible, can you remove the hard disc from the promise and attach it on the VIA-Controller and test if the problem still occurs? (prepare a bootdisc if you cannot boot. Propably, you have to pass a new root-partition to the kernel)
I hardly believe that the promise controller has some problems with the new VIA setup introduced in 2.4.3-ac7. Using the promise ports of the A7V133 is the only correlation I see again and again...
Yes, plugging the drive into the primary VIA IDE port, it seems to work perfectly. Am now on 2.4.5-ac14 with UDMA5 enabled and it seems quite happy.
Which would seem to indicate that yes, it *is* a Promise issue - or at least a Promise-on-VIA issue.
FWIW the Promise BIOS announces itself as version 2.01 build 35.
erk...
Thus far I've been presuming that the Promise IDE ports were UDMA100/66/33 and the VIA IDE ports were UDMA66/33, and thus naturally wanted to use the Promise ports to get better performance. Now, on more careful reading of the manual, it seems to be telling me that *all* of the IDE ports are UDMA100/66/33, the main benefit of the Promise chip besides being able to plug more IDE devices in, being the RAID 0 support (which I don't need [yet]). Then, on looking again at the bonnie *results* (rather than just noting that it hadn't *crashed*), I notice that the figures are about the same, possibly marginally better, than those I was getting out of the Promise ports.
And there I thought I'd have to be slumming it... Doh! :-} <sheepish/>
Signature · 1 line
Rachel