> at booting, a NE2000 (the only network-card in the system!) is reported as:
>
> > ne.c:v1.10 9/23/94 Donald Becker (becker@cesdis.gsfc.nasa.gov)
> > NE*000 ethercard probe at 0x340: 00 00 e8 c6 d1 1f
> > eth0: NE2000 found at 0x340, using IRQ 15.
>
> quite fine. /proc/interrupts and /proc/ioports read as follows:
...
> 15: 634 NE2000
> ^^^^^^^^^^^^^^^^^^^^^
...
> now I go on, and type
>
> insmod /lib/modules/1.99.14./net/8390.o
> insmod /lib/modules/1.99.14./net/ne.o io=0x340
> ^^^^^^^^
>
> this is of course not correct. 0x340 is already being used by eth0.
> however, eth1 is detected:
This is the correct behavior.
The kernel did exact what you told it to do!
Remember, the kernel will allow the *root* user to do nonsensical things.
Specifically, the drivers ignore the resource allocation code when told to
probe a specific address.
> > eth1: NE2000 found at 0x340, using IRQ 7.
>
> next strange thing is this IRQ. IRQ=7 is not used under linux, I only use
> it under m$/dos for the SB16 card. under m$/dos, the SB16 is initialised the
> following way:
You should not normally do autoIRQ on a running system!
What's going on here is that the autoIRQ isn't watching IRQ15, since there is
already a card registered there. Therefore the driver won't find the correct
IRQ line, and will instead pick an active IRQ line without a driver already
registered. IRQ7 is the usual "noisy" IRQ line, and is usually the one found.
> last: when I now remove eth1 (rmmod ne.o; rmmod 8390.o), the NE2000 doesn't
> show up in /proc/ioports anymore, but that's of course a (folgefehler?)
> an error caused by a previous error :-)
Correct: the driver unconditionally unregisters itself when the module is
removed. This is arguably the correct behavior.
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/pub/people/becker/whoiam.html