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 about the method that the .90 driver
used. It worked for me, of course, cool, but when I thought about putting
a real general purpose patch into later versions of tulip.c to solve the
same problem, it bothered me that the old method assumes an association
between pci bus and cpu that may not be valid. I don't know that
there are any 386/486/5x86 systems that can use the 0x01A08000 setting
(that apparently works on most x86 pci 2.1 busses), but then again I don't
know that there aren't, either.
If the pci bus level is 2.0, it makes sense to use the cautious CSR0
setting, for the same reasons that the .90 tulip.c in 2.0.38 does, and if
the pci level is 2.1, you aren't taking any chances with 0x01A08000 that
the driver doesn't take now. The pci driver, initialized before any
pci devices, appears to know whether you have a pci 2.0 or pci 2.1 bus, so
why not use that information instead of cpu generation?
(Merely a suggestion)
Regards,
Clayton Weaver
<mailto:[email protected]>
(Seattle)
""
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 about the method that the .90 driver
> used. It worked for me, of course, cool, but when I thought about putting
> a real general purpose patch into later versions of tulip.c to solve the
> same problem, it bothered me that the old method assumes an association
> between pci bus and cpu that may not be valid. I don't know that
> there are any 386/486/5x86 systems that can use the 0x01A08000 setting
> (that apparently works on most x86 pci 2.1 busses), but then again I don't
> know that there aren't, either.
>
> If the pci bus level is 2.0, it makes sense to use the cautious CSR0
> setting, for the same reasons that the .90 tulip.c in 2.0.38 does, and if
> the pci level is 2.1, you aren't taking any chances with 0x01A08000 that
> the driver doesn't take now. The pci driver, initialized before any
> pci devices, appears to know whether you have a pci 2.0 or pci 2.1 bus, so
> why not use that information instead of cpu generation?
A good suggestion, too... Some other hardware behaves differently
based on PCI bus version, it would be nice for the driver to notice that
and enable (or disable) advanced features. To blindly assume is just a
PCI bus lockup waiting to happen...
Jeff
--
Jeff Garzik |
Building 1024 | These are not the J's you're lookin' for.
MandrakeSoft | It's an old Jedi mind trick.
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 misunderstand the reason for that code. It's not based on the PCI
bus version. It's to work-around a specific bug in the Intel chipset
used on 486 PCI motherboards such as the Asus SP3 and SP3G.
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.
>> That's one thing that bothered me about the method that the .90 driver
>> used. It worked for me, of course, cool, but when I thought about putting
I put the check in the old drivers because the SP3 was a common motherboard
"way back in the old days". The check was removed becaues the kernel
changes and removed the variable that held the processor architecture.
>> If the pci bus level is 2.0, it makes sense to use the cautious CSR0
>> setting, for the same reasons that the .90 tulip.c in 2.0.38 does, and if
>> the pci level is 2.1, you aren't taking any chances with 0x01A08000 that
>> the driver doesn't take now. The pci driver, initialized before any
>> pci devices, appears to know whether you have a pci 2.0 or pci 2.1 bus, so
>> why not use that information instead of cpu generation?
>
>A good suggestion, too... Some other hardware behaves differently
>based on PCI bus version, it would be nice for the driver to notice that
>and enable (or disable) advanced features. To blindly assume is just a
>PCI bus lockup waiting to happen...
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.
Donald Becker [email protected]
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
Annapolis MD 21403 410-990-9993
> 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 drivers can test the pci quirk list
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 quirks and we can do it nicely
> in 2.4 so that drivers can test the pci quirk list
I had the problem with the Intel Saturn II chipset used on the Asus SP3G.
The same problem was reported with the Saturn I on the SP3.
The bug manifests as occasional bus-master transfer data corruption.
The work-around was to change the Tulip PCI control register to use
8 longword cache alignment, 8 longword burst.
when the Tulip driver was run on a 486.
The old non-module work-around was
if (x86 <= 4)
printk(KERN_INFO "%s: This is a 386/486 PCI system, setting cache "
"alignment to %x.\n", dev->name,
0x01A00000 | (x86 <= 4 ? 0x4800 : 0x8000));
I removed this code and replaced with the ability to set the variable "csr0"
as a module option. There is no way to activate the fix with a built-in
driver.
Donald Becker [email protected]
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
Annapolis MD 21403 410-990-9993
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 #if CONFIG_M486 || CONFIG_386 then?
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
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: the pci probe (cat /proc/pci) on this machine says "No bursts" for
the host bridge.
Regards,
Clayton Weaver
<mailto:[email protected]>
(Seattle)
"Everybody's ignorant, just in different subjects." Will Rogers