Re: 3com 3c905c-txm

From: Donald Becker (becker@scyld.com)
Date: Thu May 11 2000 - 11:59:01 EDT

  • Next message: Shyam Kaushik V: "mount problem"

    Alan Cox wrote:
    >
    > > > 00:0e.0 Ethernet controller: 3Com Corporation: Unknown device 9004 (rev 04)
    > >
    > > Support for this NIC was introduced in 2.2.16pre2

    Actually, support was available in May 1999 with the 99L driver using a
    general catch-all for 900* cards, and September 1999 as an explicitly
    identified card. It could have been in the kernel far earlier than now.

    Andrew Morton wrote

    > outw(some_command, ioaddr + EL3_CMD);
    > for (i = 2000; i >= 0 ; i--)
    > if ( ! (inw(ioaddr + EL3_STATUS) & CmdInProgress))
    > break;
    >
    > sometimes this timeout actually expires, which is why it was bumped to
    > 4000 in 2.3. The docs are vague in this area. Bogdan has confirmed that

    When I wrote this code in I tested the loop termination values. Commands
    typically took 0 or 1 PCI transaction times to occur. There were no times
    over 100 PCI transactions.

    Needing a value of 4000 indicates that the hardware has significantly
    changed (that's not out of the question) or the driver changes are doing
    Something Bad.

    > this fixes some crashes he has been experiencing. We end up talking to
    > the NIC before it is ready and, we believe, DMAing packets to/from
    > random bus addresses...

    You should confirm that you understand what is going on with the hardware
    first.

    > So in this patch I have simply increased the values to 4000. This is a
    > temp thing to keep people out of trouble. I suspect longer term we'll
    > be increasing the timeout to 1e6 and calling panic() if it expires.
    > We'll see.

    Nnnooo! You don't understand...

    > There are a lot of these magical busywait timeout loops in the kernel.
    > Some attempt to scale their count by loops_per_sec, but the recent
    > bogomips changes have made this practice unreliable. Advancing
    > processor speeds continue to disrupt it.

    This is NOT a magic CPU software timing loop. I don't write such things.
    This is a completion check based on the value of interest -- PCI bus cycles.
    Run-time operations should rarely or never take even one loop cycle, and
    only a major reset should take more than a few cycles.

    I count of 2000 is typically 1-2 milliseconds. Not microseconds,
    milliseconds. That's a big chunk of time for a device driver which might be
    blocking other operations.

    Please understand what the code is doing before changing it.

    Donald Becker becker@scyld.com
    Scyld Computing Corporation
    410 Severn Ave. Suite 210
    Annapolis MD 21403

    -
    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/



    This archive was generated by hypermail 2b29 : Thu May 11 2000 - 12:01:20 EDT