SIS 85C496 on Asus sp3 appears to have an equivalent bug (same CSR0
setting fixes kernel deadlocks that occur when using the
non-burst-challenged 0x01A08000 setting), so if you're going to catch it
with a special case in the pci code, you need to catch that as well as the
Saturn II chipset.
Note:
Donald Becker <[EMAIL PROTECTED]> said:
[...]
> The best way to check for this buggy chipset was to check for a 486
> processor. There are very few 486 chips on non-buggy motherboards, and the
> performance impact of shorter PCI bursts is minimal given the slow speed of
> the 486.
Enable it #i
On Sat, 9 Dec 2000, Alan Cox wrote:
> > Just in case you didn't catch it: this is not a PCI v2.0 vs. v2.1 issue.
> > The older Tulips work great with PCI v2.0 and v2.1. The bug is with longer
> > bursts and a specific i486 chipset/motherboard.
>
> Which chipset. I can then add it to the PCI qui
> Just in case you didn't catch it: this is not a PCI v2.0 vs. v2.1 issue.
> The older Tulips work great with PCI v2.0 and v2.1. The bug is with longer
> bursts and a specific i486 chipset/motherboard.
Which chipset. I can then add it to the PCI quirks and we can do it nicely
in 2.4 so that driv
Jeff Garzik wrote:
> Clayton Weaver wrote:
>>>
>> Shouldn't the setting of the CSR0 value for x86 switch between normal
>> (0x01A08000) and cautious (0x01A04800) based on some notion of
>> what generation of pci bus is installed rather than what cpu the kernel
>> is compiled for?
No, you m
Clayton Weaver wrote:
>
> Shouldn't the setting of the CSR0 value for x86 switch between normal
> (0x01A08000) and cautious (0x01A04800) based on some notion of
> what generation of pci bus is installed rather than what cpu the kernel
> is compiled for?
>
> That's one thing that bothered me abou
6 matches
Mail list logo
