[eepro100] Lockup with Intel PRO/100+ Dual Port Server Adapter

Thomas Lorenzen tl@theory.ki.ku.dk
Fri, 12 Jan 2001 15:54:03 +0100 (CET)


     Hi'

On Fri, 12 Jan 2001, Donald Becker wrote:

>>> On Fri, 12 Jan 2001, Thomas Lorenzen wrote:
>>> 
>>> >    I have recently purchased an Intel PRO/100+ Dual Port
>>> > Server Adapter, which chips states to be of type 82558.
>>> > 
>>> >    At first the two ports on the nic were detected with
>>> > different irq's, but after some time I got the machine to
>>> > actually detect the two ports on the nic with the same irq.
>>> 
>>> Many older machines have a BIOS bug that incorrectly assigns different
>>> IRQs to devices behind a bus bridge.  This problem commonly affected 4
>>> port tulip cards, and the tulip driver has an ugly hack to deal with the
>>> problem.
>>> 
>>> What did you do to fix the problem on your machine?

   In the bios it was actually possible to specify the irq
numbers, which the system should assign to the different pci
slots. I then just assigned two times irq 9, and then the
two ports were configured to both use irq 9. Aparently,
however, that did not do such a good job anyway.

>>> >    However, I seem to be having problems bringing up the
>>> > interfaces, as doing so tends to hard lock the machine.
>>> > Sometimes it hard locks already at 'ifconfig eth0', other
>>> > times it hard locks at 'ifconfig eth1', and I have also
>>> > experienced a hard lock after some ping activity to the
>>> > ports. These lock ups occur regardless of the driver being
>>> > build into the kernel or loaded as a module. Furthermore
>>> > both the 2.2.16 shipped driver and the newest scyld driver
>>> > as well as the e100 driver from intel shows these symptoms.
>>> 
>>> What driver version are you using?
>>> eepro100.c v1.13 of 1/9/2001 has work-around for a hang that occurs with
>>> some firmware version the first time the interface is started after a
>>> warm boot.
>>> 
>>> The work-around is an ugly hack that should never be required, a
>>> udelay(10) after a register write during initialization, but it seems to
>>> reliably do the trick.

   Ok, it is almost weekend here, so I will try v1.13 later
on and inform you later on.

   I have been suggested to try the stuff on a newer
machine. My test machine is an old 486. Do you have any idea
about, if that could solve the problem. When working
properly, the board is planned to go into a PIII SMP
machine.

   Best Regards.

     Thomas.

----------------------------------------------------------------------
Cand. Scient. Thomas Lorenzen               Phone : (+ 45) 35 32 02 50
Department of Chemistry                       Fax : (+ 45) 35 32 02 59
University of Copenhagen                     Mail : tl@theory.ki.ku.dk
DK, 2100 Copenhagen, Denmark   Homepage : http://theochem.ki.ku.dk/~tl
----------------------------------------------------------------------