>Hello, I have an LCII running GENERICSBC-15, and everything is kosher
>and lovely except for one major trouble: when the kernel gets to
>configuring the Ethernet, it gets caught in an infinite loop which
>reads "slot_noint() slot e". The card is an EtherWave LC, with a
>Sonic controller chip DP83902AVLJ. The big catch (perhaps) is that
>this card is a dual port 10BaseT card, so perhaps that's an issue. I
>could also use another card: a Techworks LC card, but it has a Sonic
>DP83932BVF controller, which is not currently supported, and causes a
>kernel panic. Could someone help with the Farallon card or give me
>any info on kernel support for the 83932? Thanks

Your message is confusing and perhaps of interest to others so I have cc'd
the list.

The National Semiconductor SONIC (Systems-Oriented Network Interface
Controller) is designated by the markings DP83932 the Techworks LC card you
mention uses a SONIC controller and is unsupported until a driver is
written as the hardware interface is different from the DP8390 controllers
which are supported.  Allen Briggs was the last person that I heard was
working on such a driver as this is what I remember is in the Q700 (dont
quote me on this last sentance).

The DP83902A Serial Network Interface Controller for Twisted Pair (ST-NIC)
is basically a DP8390 (NIC) couppled with an encoder/decoder and a
tranciever for 10bT and an AUI all on one CMOS chip.  Since it presents
basically a DP8390 NIC interface it should work with the current DP8390
driver (ae if you are configing your own kernel.) with little or (more
probably) no modifications.

If I read you message correctly you are saying that you get a mesage like
below that continues adnauseam such as:

slot_noint() slot e
slot_noint() slot e
slot_noint() slot e
slot_noint() slot e

I dont know what this is.  If you look in via.c it appears that the nubus
interupt table slotitab is initialized to contian pointers to a function
slot_nointr that should bassically be a warning that an interupt is
occuring that the kernel doesn't expect, then later in add_nubus_intr the
kernel claims nubus interupts that it knows how to handle by changing the
slotitabs slot_nointr routine to point to a interupt handler is designates.
It sounds like the LC nubus interups don't work as expected or perhaps the
LC nubus is odd in some way not epected by the kernel.  I don't have an
answer for you.

I can tell you that the DP83902VF based card I had in my IIci worked fine
till some bozo here turned off circuit breakers before he gave me a chance
to shutdown thus killing my card.

Hope this helps someone.  Send further questions to me.

---------
Christopher R. Bowman
crb@eng.umd.edu
My home page