Most recent kernel where this bug did not occur: unknown
Hardware Environment: GIC68 motherboard
Software Environment: ethtool version 3,
ip utility, iproute2-ss060323,
ifconfig 1.42 (2001-04-13)
Problem Description: e100 did not send or receive packets after boot once
Steps to reproduce: compile e100 as a module and boot with Ethernet cable attached to Telco System’s T5 Compact 10/100/1000 Ethernet Routing Switch.
Running the following commands made packets transmission and reception possible:
ifconfig eth1 down
ifconfig eth1 up
did this work in older kernels? can you try 2.6.24-rc2 or even better, try jgarzik/netdev-2.6 #upstream?
I got a similar Bug 8652 in kernel version 220.127.116.11.
I have not been able to reproduce the bug in kernel version 18.104.22.168.
I read that as "you don't have any more problems". correct?
please close the bugreport if that is the case.
I have not had that problem any more. But I suspect it might be a bug that happens only sometimes.
I meet this problem on my 915gv machine when using 2.6.22 or 2.6.23 kernel,when i ifconfig,only display lo,not eth0. 2.6.21 has no this problem,network can work.
please post your dmesg, lspci -vvv from both 2.6.21 and 2.6.22 so we can see what is different. I can't investigate unless I have some debuggin information.
Created attachment 14444 [details]
lspci -vvv 22.214.171.124 SMP PREEMPT i686
Created attachment 14445 [details]
dmesg while eth1 did not work on Linux 126.96.36.199
Created attachment 14446 [details]
dmesg after eth1 worked after ifconfig eth1 down ifconfig eth1 up
Created attachment 14447 [details]
Linux configuration file .config
ifconfig eth1 showed UP and RUNNING even though traffic did not work.
The following lines in dmesg look suspicious:
[ 83.017954] Clocksource tsc unstable (delta = 111864067 ns)
[ 83.018930] Time: pit clocksource has been installed.
Yes, that might hit us here. Grmbl. Can you please boot with "nolapic_timer" on the kernel command line ?
Created attachment 14557 [details]
Boot log with nolapic_timer
*** This bug has been marked as a duplicate of bug 5149 ***
I thought a wake-on-lan fix could fix this bug, too, but it is not necessarily a duplicate.
I think this is related to disabling of IRQs in a driver.