Jonathan Matthews <[EMAIL PROTECTED]> wrote:

> -SNIP- <
I'm guessing that, under 2.4

a) I have to use 8139too


Not necessarily... see below.

Since the hang occurs at boot immediately after
"Configuring network interfaces: " with no errors reported:

b) it's the driver's probing of other io addresses that's causing
the hang.

Note that (b) is, of course, very probably, wrong.


I think your problem is happening much later than the kernel's detection of the NIC. This message is generated by the /etc/init.d/networking script that is run after the kernel has booted and as part of the /etc/rcS.d/ initscripts. The IO/IRQ probing has already been done. You can get an apparent "hang" at this point if you have the interface setup to use dhcp and it cannot find a dhcp server. There can be several reasons for this, including improper init of the NIC.


So, to cut to the chase: how do I pass the io and irq values to the
driver?

Please note that I'm aware of having (after an update-modules) the two
lines
alias eth0 8139too
options 8139too io=0xe00 irq=12
in /etc/modules.conf

and also the line

append="ether=12,0xe00,eth0"
in /etc/lilo.conf.

Neither one appears to do much good.

Any 8139too-under-2.4 users out there able to lend a hand?

cheers!
jc

I have about 4 of these RealTek 8139 cards in use here. Three of them are running on the "stock" debian 2.4.18 kernel using the 8139too.o driver... all without problems. Here is some info that I have collected over the years that might be useful in helping you track down the problem. Appologies if you have already done this...just trying to cover all bases.

1. All RealTek 8139 cards that I know about are PCI cards. If yours is NOT a PCI card (ISA??) then I would re-check the chipset number and make absolutely sure that it is the correct one.

2. You have very little control over passing IO/IRQ arguments to PCI cards. The IO/IRQ is set by your BIOS and the IRQ assignments are entirely dependent on the particular PCI slot the card is using. There is not any requirement to pass these arguments to the driver module on PCI cards in Linux as linux will take care of this automatically for PCI cards. The fact that you ARE trying to pass IO/IRQ values to the kernel might be messing it up! I would recommend you stop trying to pass specific IO/IRQ values to the module and let the kernel do its thing.

3. There are now several different models of the 8139 chipset. The "a" and "b" series work quite well with the rtl8139.o and 8139too.o modules in the 2.2.xx series kernel, as well as with the 8139too.o module in the 2.4.xx kernels. The newer "c" models has some problems with these particular drivers for some people. In the 2.4.18 kernel that I have, there is a "8149cp.o" module, which I believe is for the newer models. I don't have the newer models, so this is just a guess, but you might want to try the "8139cp.o" module (without any parameters). As I said, this is just a "guess". The fact that the card works with both of the regular modules in your 2.2.xx kernels tells me this is probably NOT a factor for you.

4. I would temporarily disable the init of the network... particularly this interface. You can do this by boot up to run-level 1 and/or editing your /etc/network/interface and taking eth0 (or whatever the interface for this card is) out of any "auto" statement. You can then manually expolore the system and try to pin-point the problem. See if the module is being loaded (lsmod) and explore the IRQs and IOs to see if you have any conflicts. If you see that eth0 has an assigned IRQ of "0" go into your BIOS and reset the "PnP OS" option to "off" or "no". Look for something else sitting on IRQ 12... a P/S-2 mouse is a likely suspect.

5. Check your dmesg file and see if it detects the 8139 NIC. This should happen before any of the initscripts are run, and there should be some info in your logs, even on the "failed" boots.

I suspect your "problem" is somewhere in the /etc/network/interface file rather than in the module... again, just a guess.

Cheers & Good Luck!

-Don Spoon-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to