Messages in this thread | | | Date | Sat, 26 Sep 1998 11:17:18 +0200 (MET DST) | From | Gerard Roudier <> | Subject | Re: PCI_LATENCY_TIMER brain-damage in net drivers. |
| |
On Sat, 26 Sep 1998, David S. Miller wrote:
> Date: Sat, 26 Sep 1998 09:03:03 +0200 (MET DST) > From: Gerard Roudier <groudier@club-internet.fr> > > PCI latency timer values are only usefull when several devices are > requesting the PCI bus at the same time, by allowing BUS acquisition > latency prediction for the whole system. Setting a large value for a > device latency timer in low level drivers is kind of ego-mania and is > highly wrong and broken. > > I agree that some of these cases are broken. However there are some > cases (1 or 2 that I know of) where you do need to use a high value to > avoid hardware bugs in certain revisions of certain cards. > > I believe certain revisions of the Tulip or the 3c59x chipsets have > such an issue, whereby they cannot cope with getting kicked off the > PCI bus amidst their DMA burst transfers.
A device bug work-around should be at least commented so in the source code. BTW, you shouldn't remove the offending code from my previous mail. Let it get swapped-in again: ;-)
if (pci_latency < 10) { printk(" PCI latency timer (CFLT) is unreasonably low at %d." " Setting to 255 clocks.\n", pci_latency); pcibios_write_config_byte(pci_bus, pci_device_fn, PCI_LATENCY_TIMER, 255);
The only text part of this code states about 10 being an unreasonnable value and the code forces the maximum value 255 when the actual value is less than 10. Let's hope that the PCI device bug that is intended to be fixed by this code be less severe than the driver writer's misknowdlegde about PCI. In my opinion, _all_ occurences of this code that are intended to fix something must be changed to something really reasonnable.
> Yes, these chips are for shit, but the rest of the cases found should > be fixed.
Generally, several different work-arounds are possibles for a chip bug. You should prefer a work-around that is _fair_ with regards to shared resources, each time it is possible, even if you have to victimize some features of the offending chip. No need to change shit into double-shit.
Why do you want a PCI device to be kicked off the PCI BUS when the latency timer expires ? 1 - The arbiter and other devices donnot care of the PCI latency timer value of the master that has the BUS. 2 - The BUS release occurs on master decision or target abort.
But, obviously a PCI device may break things in some situations as, for examples:
3 - Not terminate a PCI write and invalidate on a whole cache line. 4 - Not be able to restart correctly some PCI transactions. (Note that in case of PCI latency timer expiration, it is the master that is expected to 'kicked itself off' the BUS).
The right fix for (3) is to disable write and invalidate for this chip. You may decide to _reduce_ the maximum burst length to a value that fits the latency timer of the device (when possible), but will have to cross fingers.
(4) is generally not fixable and so users must be aware that their system is broken. I would suggest to warn at boot when such a broken device is detected.
As I wrote, (3) and (4) are examples, and I am aware that there are bunches of other bugs that actually affects some existing PCI devices.
Regards, Gerard.
- 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.tux.org/lkml/
| |