Re: Passing io/eth params to 8319too driver
Jonathan Matthews <jaycee@jaycee.uklinux.net> 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 debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: