VIA KT133A crash *post* 2.4.3-ac6

VIA KT133A crash *post* 2.4.3-ac6

[Rachel Greenham]

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.

-- 
Rachel

Re: VIA KT133A crash *post* 2.4.3-ac6

[Christian Bornträger]

> 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.

> 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.

> With DMA disabled, *all* kernels are completely stable.

same for me.


> 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.

Re: VIA KT133A crash *post* 2.4.3-ac6

[Rachel Greenham]

Christian Bornträger wrote:

>>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?
>

Oh yes. :-)

>
>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. :-)

>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. :-)

-- 
Rachel

Re: VIA KT133A crash *post* 2.4.3-ac6

[Alan Cox]

> 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

Re: VIA KT133A crash *post* 2.4.3-ac6

[Alan Cox]

> 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'. 

> 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. 

Re: VIA KT133A crash *post* 2.4.3-ac6

[Thomas Molina]

On Tue, 12 Jun 2001, Alan Cox wrote:

> > 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'.
>
> > 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.

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.

Re: VIA KT133A crash *post* 2.4.3-ac6

[Rachel Greenham]

Thomas Molina wrote:

>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>

-- 
Rachel

Re: VIA KT133A crash *post* 2.4.3-ac6

[Thomas Molina]

On Sat, 16 Jun 2001, Rachel Greenham wrote:

> Thomas Molina wrote:
>
> >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.

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.

> <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

Re: VIA KT133A crash *post* 2.4.3-ac6

[Christian Bornträger]

> 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
.
> 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. :-)

Re: VIA KT133A crash *post* 2.4.3-ac6

[Rachel Greenham]

Christian Bornträger wrote:

>>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/>

-- 
Rachel

Re: VIA KT133A crash *post* 2.4.3-ac6

[Rachel Greenham]

Thomas Molina wrote:

>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"

>><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:

>[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

>[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@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.

>
>[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
>
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... )

-- 
Rachel

Re: VIA KT133A crash *post* 2.4.3-ac6

[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?


justin

Re: VIA KT133A crash *post* 2.4.3-ac6

[Rachel Greenham]

Justin Guyett wrote:

>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...

-- 
Rachel

Re: VIA KT133A crash *post* 2.4.3-ac6

[Jason T. Collins]

justin@soze.net wrote:
 > 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?

I recently upgraded my system so it now (undeliberately!) seems to 
reproduce every problem ever mentioned here or elsewhere with regards to 
the VIA chipset -- I now have/have had the VIA timer bug (fixed due to 
patch), SB Live problems (seem to be resolved, card shuffling), nVidia 
crashing, and IDE lockups similiar to those mentioned earlier in this 
thread.  There's almost enough material for a VIA on Linux FAQ...

In addition, I had the IBM+Promise+VIA problem.  Moving the drive to my 
on-board 686A as others have done has solved it..  before that, Cerberus 
didn't last more than about 30 seconds with DMA enabled before causing 
random trashing of memory and other nasty disasters. 

Now I get about 3-10 minutes in and bizarrely, Linux just gives up -- 
disk access stops for no apparent/printked reason, and no amount of 
tweaking DMA settings or VM parameters seems to change that, unless I 
disable DMA completely.  In-memory programs keep running, but anything 
needing disk access blocks indefinitely.  What's weirder is, in about 
10% of the crashes (I've done this a LOT), hitting Alt-SysRq-S (sync) a 
couple times knocks the system out of the state and Cerberus will run as 
normal for about 5 or 10 more minutes and crash again.  :/  At least it 
isn't corrupting data.

I think we're trying to debug about a half dozen critical problems all 
at the same time here. ;)

To contribute to the hardware matching:

Jason's Box:
Abit KA7 (KX133, VIA686A Southbridge) / Athlon 850, latest BIOS
512 MB CAS2 PC133 SDRAM (Mushkin)
Promise Ultra100 (2.01 B 27 BIOS, latest)
OHCI-1394 Firewire Controller (Texas Instruments)
Bt878 video capture card
Creative Labs CT4620 SB Live!
nVidia GeForce 2 MX 64 MB (NV11 rev b2, LeadTek, latest BIOS)

hda=QUANTUM FIREBALLP LM20.5, FwRev=A35.0700, SerialNo=184006731872
hdb=IBM-DTLA-307060, FwRev=TX8OA50C, SerialNo=YQDYQFHT566
hdc=Pioneer DVD-ROM ATAPIModel DVD-104S 020, FwRev=E2.02, SerialNo=
hde=Maxtor 54610H6, FwRev=JAC61HU0, SerialNo=F600VF1D
hdg=Maxtor 54610H6, FwRev=JAC61HU0, SerialNo=F600TNTD


Jason T. Collins
Software Engineer
VA Linux Systems