So the answer is nothing over UDMA33 works safely on the via board in the
2.4.3-20 kernel?
-Original Message-
From: civileme [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 26, 2001 10:38 AM
To: Ivan Powis; [EMAIL PROTECTED]
Subject: Re: [expert] LM 8 Kernels , VIA chipsets UDMA100
On Tuesday 26 June 2001 13:46, Ivan Powis wrote:
I have a MS K7T Pro2-A motherboard with VIA KT133 chipset
(VT82C686B bridge). Also with IBM DTLA307030 UDMA100 Drive.
Originally I had SUSE 7.0 installed, which ran the disk as a
UDMA100 drive with reported (hdparm) transfer rates 35 MB/s.
Since my other systems run Mandrake I installed LM8 on this
system, but find that it won't recognise the drive as UDMA100,
and can't be made to with hdparm either. So it runs as UDMA33
with transfer rates of 23 MB/s. For the specific application
intended for this system, thats a _significant_ performance
hit.
Out of curiosity I installed the v2.2 kernel distributed with
LM8 and find that that is fine. So the I conclude the problem
is with the 2.4 kernel or at least the build distributed with
LM8.
I've browsed a lot and find lots of stubs (rather than
concluded threads) about DMA100 and off-board controller
problems, but I haven't find anything definitive about the
onboard VIA, LM8 and v2.4.
Is this a known problem? got a fix?
I append edited versions of the v2.4 and v2.2 kernel dmesg log
and the output from hdparm -i -Tt /dev/hda under both
kernels
v2.4:
Well, you are (un)lucky to get that performance out of it. We
have deliberately set kernel 2.4 to cripple itself when it sees
a 686B southbridge.
It is supposed to shut down DMA, and it does in most cases.
When the problem with the 686B Southbridge has a stable
workaround in the kernel (We cannot assume that all users will
have access or will upgrade their BIOS to extinguish the
_massive_corruption_ bug), then we will have a full-speed kernel
for you. Until then, kernel-linus and 2.2 work.
This bug has been observed in kernel 2.4, Win 95, 98 98SE ME NT
and Win2K. It's symptoms are many and varied:
Cannot write a full CD-R or CDRW.
Resets itself on transfers of 100Mb or more
Freezes during disk copy operations.
It is a hardware bug in the chipset itself which we had no
viable workaround for at production time (We knew of it just
days before release. SuSE could not have known of it at all
because their release was much earlier.)
If you want the best performance from hdparm, you might want to
go to /contribs and download drakopt. It works acceptably in
most cases and finds right now the highest speed. A version
scheduled for release in a few days will find the best
speed/noise immunity tradeoff according to user-set standards.
Civileme
