Hi. This already happens to somebody on internet, and they already fix it.
I am new on gentoo and i am installing a server in a very old MMX with 2 net cards:
# lspci | grep Ethernet
0000:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
0000:00:0f.0 Ethernet Controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip compatible 10/100 Ethernet (rev 40)
Before installing gentoo following the guide, and on the first reboot, the networking refuse to work as configured on the livecd.
on the livecd:
eth0 = davicom card = module "tulip" = IRQ 9
eth1 = Realtek card = module 8139too = IRQ 11
as mentioned on the lspci, the davicom card should be compatible with tulip, and on the live cd it is, and work fine (i didnt made any benchmark), but before reboot:
on the installed gentoo with genkernel:
eth0 = Realtek card = module 8139too = IRQ 11
eth1 = davicom card = module "tulip" = IRQ 9
notice which the asigned device are switched, this confuse my configuration at the first time. I dont understand why the same detection script make different results.
after see that and make lots of test i get working fine the realtek, but the davicom card doas not connect to anything but it seems to configure correctly with ifconfig at my hand, and with /etc/conf.d/net.
it just dont transmit and receive anything but is configured correctly
in the dmesg there are lines which says:
0000:00:0f.0: tulip_stop_rxtx() failed
this line shows every time which i got down the card with ifconfig
in google i found the first url mentioned above which is for debian and he sais which he have to do that to make it works:
so i do
ifconfig eth1 down
ifconfig eth1 192.168.1.21 netmask 255.255.255.0 up
route add default gw 192.168.1.1
and it works.
it detects again my card and after setup it, the ping works well
I dont understand why the livecd works fine with tulip and not on the hard disk (maybe becouse i have activated support for advanced routing on the kernel?) but the driver should be detected as dmfe.
This is the primary bug.
And the secondary is the order on what them where detected.
now, as a temporary fix i want to boot with noload=tulip and load the dmfe module with the file on modules.autoload.d? in a wait for a real fix on the next release. But the tulip loads anyway, i dont know how can i stop it.
is there some way to change the driver assigned to the interfaz eth0 to the interface eth1 and the driver of eth1 to eth0, this is becouse i plan to add more net cards and if the detection is so randomly, i need to make a casting or something.
like configure aliases where
net0 -> eth1
net1 -> eth0
net2 -> eth2
net_ppp0 -> ppp0 or 1 depending on which ISP connects first
net_ppp1 -> ppp1 or 0 depending on which ISP connects first
To make a little bit of order.
sorry by my ignorance. :P
(In adition to comment #0)
after booting with the modules.autoload.d/kernel-2.6 loading the dmfe, the order change again
eth0 = module dmfe or tulip = davicom card = work fine with both modules loaded at the same time
eth1 = module 8139too = Realtek card = work
Definitely not a gernkenel problem and looks like a configuration issue. Can somebody else read through this and check? Thanks.
(In reply to comment #2)
> Definitely not a gernkenel problem and looks like a configuration issue. Can
> somebody else read through this and check? Thanks.
i understand which genkernel or, more precisely the initrd provided, doas the autodetection.
I think it is an autodetection bug.
Well, the tulip driver can drive the davicom card, but only if the suboption
"Davicom DM910x/DM980x support" has been selected in the Tulip menue....
So it indeed can be a genkernel/user error (missing selection) problem..
@Diego: Can you please provide your kernel config? Also, with what driver did you noticed this problem and have you already tried with a more recent kernel?
About the interfaces names, that's a common problem. Sometimes a kernel modules just takes 1ms more to load in a newer kernel than the last stable version and happends that it registers the interface first. In this case, the ethernet interfaces "switch" modules. What I advise is to setup udev rules to force a interface name for a fisical ethernet card based on the MAC address of it. In my lappy, for example, I have a interface named "lan" and another named "wlan", no matter witch one gets initialized first.
Buah... sorry, Replace "Also, with what driver" with "Also, with what kernel"
Created attachment 77781 [details]
3 configs files
hi, since it was a long time ago, i really cant remember what exactly file was but i have a clue.
in the attached file are 3 files. the first one i create was the genkernel config file.
before see which dmfe was my driver and test it working, i recompile the kernel for my own striping all other unneeded drivers, and compiling on the kernel my drivers to not use any autodetection tool.
the was the second config file denoted as kernel without a v..
the third was for adding support for some networking stuff (i dont remember now what)
the kernel versions are on the file names respectively.
What i saw in the genkernel was that when i first compile it with the default options it doasnt work with my eth card with the tulip loaded, and on the live cd it works fine.
then i test for the module dmfe and it works. and then again on the kernel was the missing feature for the tulip module which doas the compatibility with my card.
i will look for udev it seems to be what i was looking for, but i made an script for gentoo to alias my connections and getting all the information which i need for my firewall.
Apparently there is no clear answer which driver works best:
tulip is the more generic driver, and davicom tried to clone tulip in their device, but apparently made a mess of it.
I'm doubtful if it would get fixed, but you could try filing an upstream bug after testing tulip on the latest development kernel (currently 2.6.16-rc2) at http://bugzilla.kernel.org
genkernel: you may wish to consider prioritising dmfe above tulip. If not, please just close this bug, there is no easy fix.
dsd: adding you so you know what's going on with this.
Genkernel doesn't load any network drivers at any point. Most likely, the problem is that the genkernel kernel *configures* both drivers by default. It appears that it is coldplug/some other service actually loading the module and causing the error. It sounds like the only solution possible from genkernel would be to *not* build the tulip module, which isn't acceptable as it would break many more network cards than it would fix.
My suggestion is for the user to add "tulip" to /etc/hotplug/blacklist or to build a kernel using his own configuration without tulip enabled.
(In reply to comment #9)
> Genkernel doesn't load any network drivers at any point. Most likely, the
> problem is that the genkernel kernel *configures* both drivers by default. It
> appears that it is coldplug/some other service actually loading the module and
> causing the error. It sounds like the only solution possible from genkernel
> would be to *not* build the tulip module, which isn't acceptable as it would
> break many more network cards than it would fix.
but this doasn't explain why the universal cd have the compatibility support for davicom cards on the tulip driver enabled by default and making a default genkernel doas not.
I didn't test the latest genkernel to see if it is fixed but i think which all the problem is just this, enabling compatility support on the tulip driver by default, this wont break any other card (the universal cd works very fine or not?)
Coldplug or whatever uses the tulip driver for this cards and it is fine if the tulip driver is configured with compatibility support for davicom cards.
They are the same config for 2006.0 (and 2005.1-r1) so I'm not sure where you're getting that they're different. At any rate, this should be fixed, I guess.