lkml.org 
[lkml]   [1998]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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