> Ok, I found at least one remaining problem with the newer eepro100
> drivers: they reset the thing _twice_. Worse, the second reset is after we
> have potentially written some specific setup, which then is lost
> completely. Search for the lines that say
>
> outl(0, ioaddr + SCBPort);
>
> and only the first one is any good: the others will reset the card without
> doing the proper state setup.
The chip is reset the second time after doing the self-test: this is
recommended but not required. The only setup done between the first and
second reset is configuring an external 83840A transceiver to avoid an
interaction bug with the i82558. The internal transceiver on the i82558
needs no special configuration, so the extra reset isn't erasing any
configuration.
> The other problem seems to be due to the newer driver forcing a
> re-negotiation of the link, which is complete crap, because it ignores the
> options that the user has given (and that were honoured earlier at
> bootup).
I put that transceiver reset in there for a user that was having a specific
problem. In general I *don't* reset MII transceivers in my drivers at open()
time because of the potential problems. In this case the second negotiation
round apparently failed.
> I suspect these two problems explain the bootup failure I saw - they
> essentially resulted in the new driver ignoring the documented way of
> forcing it into half-duplex 100Mbps (auto-negotiation doesn't seem to work
> either, but that may be due to our particular hub, and not due to the
> driver or the card).
With this driver the force-full-duplex flag is honored on the chip, but not
set in the transceiver set-up. The Speedo3 (i82557-559 family) is unique in
using a additional, non-standard "full-duplex" output from the transceiver
(actually the FD-LED output) and thus doesn't need the driver to monitor the
negotitated link parameters. When the user forces full duplex, it overrides
the input wire.
Perhaps a better ways to do this is by setting the transceiver to only
advertise full-duplex types, but I was uncertain that future non-NatSemi
transceivers would have the same semantics for the FD-LED output.
> Donald, please sync with me when I release a 2.1.126.
Will do...
As you noted, the v1.04 and v1.05 drivers changed the synchronization
region. I now minimize the critical region to just allocating the next
descriptor slot. The slot is filled in a non-critical region.
Since the Suspend flag is only removed from the previous command when the
current command is completely filled, I believe that this is a safe change.
BTW, I do have SMP machines with EEPro100B adapters -- about 40 of them in a
cluster. But the cluster software configuration has to be stable over many
months, so I'm running an old 2.0.30 (31?) kernel with a hack to avoid the
SMP interrupt bug. It's running v0.99, which is the same as the v0.36
driver you are using. We don't have multicast codes, so it never encounters
the rapid-multicast-change bug that is in those driver versions.
[[ Hmmm, in retrospect, the multicast bug might have caused the problem that
prompted me to put in the transceiver reset -- Triggering that bug caused Tx
jabbers, which likely caused the switch to shut down the port. Only a link
reset could reactivate the port. Much like the SMP interrupt problem,
the patch for a symptom causes its own cascade of problems, even after the
original bug is fixed. ]]
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
-
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/