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 : Mon May 15 2000 - 21:00:18 EST