Messages in this thread | | | Date | Thu, 30 Jul 1998 01:16:26 -0400 (EDT) | From | David C Niemi <> | Subject | Re: 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
| |