Sungem bug or something else?
Kevin B. Hendricks
khendricks at ivey.uwo.ca
Fri Jun 7 06:41:46 EST 2002
Does sungem use autonegotiate to determine its interface type and speed
(like some of the more advanced interface drivers) or does it look at
the rom or use a table?
If it autonegotiates, does the driver actually wait long enough for the
autonegotiation to fully complete before returning the first time?
Under some tulip drivers, I noticed something very similar (but no oops,
just a inability to use the driver until I rmmod and then insmod it
once). I think it happens because the the autonegotiation results where
handled asynchronously and the main driver routine simply started it and
returned before the auonegotiation actually completed and the interface
and speed were properly determined. The problem was right after
bringing up the network in the boot sequence things tried to use it (the
appletalk drivers, etc). So if I waited to insert the module for the
driver until after everything else was started (at the end of the
bootsequence) all was well.
This is all just a wag, but it is something to look at.
On Thursday, June 6, 2002, at 03:45 PM, Benjamin Herrenschmidt wrote:
>> I encounter an oops during boot bringing up a sungem
>> interface. (smp g4 450/gcc 3.1/glibc 2.2.5) If I defer
>> bringing up the network at boot, I can successfully
>> start eth0 (sungem) if I start eth1 (tulip) first, so
>> it may not be the sungem driver itself. This happens
>> on benh 2.4.19-Bpre10, and pre9.
> What kind of error is it ? A Machine Check ?
> Looking at your backtrace, it looks like the driver is
> trying to access the PHY chip. That can sometimes happen
> if you have some tool like miitool or ethtool trying to
> get at the link status while the chip isn't powered up.
> The problem here is that sungem on Apple HW only powers
> the chip when the interface is brought up, and powers it
> down about 10 seconds after bringing the interface down.
> This improve power management, but kills link monitoring
> There may be also a bug in the driver causing it to try
> to access the PHY registers when the chip is in down
> mode & getting the ethtool ioctl's
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-dev