From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20041110 Firefox/1.0 Description of problem: After upgrading Fedora Core 3 from kernel-2.6.9-1.667 to kernel-2.6.10-1.741_FC3 my NIC, with driver de2104x, does not work anymore on boot. Rebooting with kernel-2.6.9-1.667 makes it work flawlessly again. After booting into kernel-2.6.10-1.741_FC3, which takes a looong time, because the network does not get initialized, messages appear in /var/log/messages, see attachment. Version-Release number of selected component (if applicable): kernel-2.6.10-1.741_FC3 How reproducible: Always Steps to Reproduce: 1. reboot into kernel-2.6.10-1.741_FC3 Actual Results: no working NIC Expected Results: working NIC Additional info: MANUALLY performing the following tasks after booting into kernel-2.6.10-1.741_FC3: rmmod tulip rmmod de2104x modprobe de2104x makes the NIC work again.
Created attachment 109839 [details] -
On first installment of Fedora Core 3 I had to manually change the following line in /etc/modprobe.conf to get the NIC working at all: alias eth0 tulip -> alias eth0 de2104x After every reboot the module 'tulip' still gets loaded, together with module 'de2104x'. I can safely 'rmmod tulip', because the NIC uses module de2104x... How can I stop module 'tulip' from loading on boot?
Same problem here, except it is platform i686. I changed initial installation from tulip to de2104x too. This setup ran without any problems until update to 2.6.10. I fixed it this way: In /etc/modprobe.conf: alias eth0 de2104x install de2104x /sbin/modprobe --ignore-install de2104x ; /sbin/rmmod de2104x ; /sbin/modprobe --ignore-install de2104x
thanks Oliver for the workaround...it works...around... ;) now let's see if RedHat can fix this bug without the need of this workaround I still want to know how to get rid of the dreaded default 'tulip' driver. When I enter the command 'kmodule' I still get the line: 'NETWORK tulip' How can I set this line to 'NETWORK de2104x' ? There seems to be NO manpage for 'kmodule' :(
Comment on attachment 109839 [details] - >Jan 16 11:06:18 localhost kernel: eth0: set link 10baseT auto >Jan 16 11:06:18 localhost kernel: eth0: mode 0x7ffc0040, sia 0x10c4,0xffffef01,0xffffffff,0xffff0008 >Jan 16 11:06:18 localhost kernel: eth0: set mode 0x7ffc0040, set sia 0xef01,0xffff,0x8 >Jan 16 11:06:23 localhost kernel: eth0: link up, media 10baseT auto >Jan 16 11:06:23 localhost dhclient: sit0: unknown hardware address type 776 >Jan 16 11:06:24 localhost dhclient: sit0: unknown hardware address type 776 >Jan 16 11:06:26 localhost dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67 >Jan 16 11:06:35 localhost last message repeated 2 times >Jan 16 11:06:40 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6 >Jan 16 11:06:46 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 >Jan 16 11:07:01 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 >Jan 16 11:07:16 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11 >Jan 16 11:07:27 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14 >Jan 16 11:07:41 localhost dhclient: No DHCPOFFERS received. >Jan 16 11:07:41 localhost dhclient: Trying recorded lease xxx.xxx.xxx.xxx >Jan 16 11:07:45 localhost kernel: eth0: timeout expired stopping DMA >
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
I already upgraded to FC4 and am using a different NIC, so can't report if the problem is solved in FC4. Maybe someone else could help out.
My FC3 box (i686) now runs with latest kernel. I don't need to remove and reload the module any more. Now I only use this line for network in modprobe.conf alias eth0 de2104x For me this bug looks fixed ...
Well, I think this bug is indeed solved and the case can be closed. Thank you for the final conclusive respons, Oliver, but I would like to know the exact kernel version your running, so I can close this bug.