lkml.org 
[lkml]   [1998]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: FS Corruption in 2.1.109 (fwd)
On Wed, 29 Jul 1998, Linus Torvalds wrote:
> I'm sure DMA is enabled on a lot of machines. And DMA works beautifully in
> 2.1.x on a lot of machines too. It may just be that for some reasons 2.0.x
> is less likely to use DMA than 2.1.x is.
...
> For example, if I read the 2.0.x code right, then 2.0.x will enable DMA
> only when it finds a TRITON chipset or with the specific case of a Promise
> Technology IDE Ultra-DMA 33.

The more recent 2.0.3x kernels that most people use turn it on for Triton
and successors, i.e. definitely including 430HX, 430VX, and 430TX chipsets
(based on experience, not reading of code). In the long run the VIA
chipsets like the MVP3 are probably going to be more important, but up to
now a large majority of Socket 7 MBs use Triton-family Intel chipsets.

I see two other trends which might explain increasing problems:

- Non-33-MHz PCI buses. I myself have seen instability from these,
in both 430HX and 430TX chipsets, but for me it was more a matter
of not being able to boot than of disk corruption. This affected
Win95 far worse than Linux BTW.

37.5 MHz PCI buses are very common for Cyrix-based systems using
any Intel 430HX/VX/TX, VIA VP3, SiS, or other clone chipset (except
the VIA MVP3 **). All of these chipsets set the PCI bus to the
memory bus speed / 2, i.e. 37.5 MHz for the commonplace 75 MHz
memory bus *required* by some Cyrix CPUs. I can't help but wonder
if some of the Cyrix instabilities are due to this problem rather
than instruction set weirdness.

** The VIA MVP3 holds the PCI bus steady at 33 MHz regardless of
the memory bus speed, i.e. it "does it right" like the new
100MHz PII chipsets.

- Proliferation of several cheaply designed clone chipsets, like
"TXPro", which have may have subtle PCI or IDE bugs.

If PCI buses are to blame, DMA IDE is just the tip of the iceberg and
turning it off will not even come close to solving the problem. You might
not notice the problems with PCI sound, but rather nasty results can be
expected with SCSI and Ethernet on these systems. I'd be *very surprised*
if there aren't a fair number of systems out there vulnerable to disk
corruption due to overspeed PCI buses, this is one of the first things we
should look for. The second thing we should look at is the chipset. Has
anyone with a non-PCI-overclocked 430HX reported problems?

Another theory is that there is an SMP bug or even a subtle UP locking or
timing bug which is causing rare problems in parallel with the PCI
overclocking problems. This makes the detective work considerably harder,
as we need to track down multiple variables, and this as Linus points out
could cause corruption even when using IDE and PCI CRCs/checksums. But
once again turning off IDE DMA just hides the most visible symptom and
makes this hypothetical bug considerably harder to find.

--- David C Niemi ---niemi at tux.org--- Reston, Virginia, USA ---
I am clearly more popular than Reagan. I am in my third term. Where's Reagan?
Gone after two! Defeated by George Bush and Michael Dukakis no less.
-- attributed to Washington DC mayor Marion Barry (perhaps apocryphal)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.078 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site