Bug 9336 - e100 does not work after boot
e100 does not work after boot
Status: REJECTED UNREPRODUCIBLE
Product: Platform Specific/Hardware
Classification: Unclassified
Component: i386
All Linux
: P1 normal
Assigned To: Jeff Garzik
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-09 00:36 UTC by Matti Linnanvuori
Modified: 2008-03-21 04:41 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.23.1
Tree: Mainline
Regression: ---


Attachments
lspci -vvv 2.6.23.8 SMP PREEMPT i686 (10.07 KB, text/plain)
2008-01-13 22:35 UTC, Matti Linnanvuori
Details
dmesg while eth1 did not work on Linux 2.6.23.8 (12.98 KB, text/plain)
2008-01-13 22:36 UTC, Matti Linnanvuori
Details
dmesg after eth1 worked after ifconfig eth1 down ifconfig eth1 up (13.05 KB, text/plain)
2008-01-13 22:37 UTC, Matti Linnanvuori
Details
Linux configuration file .config (57.44 KB, text/plain)
2008-01-13 22:40 UTC, Matti Linnanvuori
Details
Boot log with nolapic_timer (9.45 KB, application/octet-stream)
2008-01-24 05:18 UTC, Matti Linnanvuori
Details

Description Matti Linnanvuori 2007-11-09 00:36:20 UTC
Most recent kernel where this bug did not occur: unknown
Hardware Environment: GIC68 motherboard
Software Environment: ethtool version 3,
ip utility, iproute2-ss060323,
net-tools 1.60
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.
Comment 1 Matti Linnanvuori 2007-11-09 00:41:56 UTC
Running the following commands made packets transmission and reception possible:
ifconfig eth1 down
ifconfig eth1 up
Comment 2 Auke Kok 2007-11-13 10:39:30 UTC
did this work in older kernels? can you try 2.6.24-rc2 or even better, try jgarzik/netdev-2.6 #upstream?
Comment 3 Matti Linnanvuori 2007-11-14 10:44:20 UTC
I got a similar Bug 8652 in kernel version 2.6.21.5.

I have not been able to reproduce the bug in kernel version 2.6.23.1.
Comment 4 Auke Kok 2007-11-14 10:50:21 UTC
I read that as "you don't have any more problems". correct?

please close the bugreport if that is the case.

Comment 5 Matti Linnanvuori 2007-11-14 22:43:12 UTC
I have not had that problem any more. But I suspect it might be a bug that happens only sometimes.
Comment 6 fengming.pi 2007-12-06 23:51:07 UTC
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. 
Comment 7 Auke Kok 2007-12-07 11:31:14 UTC
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.
Comment 8 Matti Linnanvuori 2008-01-13 22:35:05 UTC
Created attachment 14444 [details]
lspci -vvv 2.6.23.8 SMP PREEMPT i686
Comment 9 Matti Linnanvuori 2008-01-13 22:36:30 UTC
Created attachment 14445 [details]
dmesg while eth1 did not work on Linux 2.6.23.8
Comment 10 Matti Linnanvuori 2008-01-13 22:37:39 UTC
Created attachment 14446 [details]
dmesg after eth1 worked after ifconfig eth1 down ifconfig eth1 up
Comment 11 Matti Linnanvuori 2008-01-13 22:40:16 UTC
Created attachment 14447 [details]
Linux configuration file .config
Comment 12 Matti Linnanvuori 2008-01-16 00:10:00 UTC
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.
Comment 13 Matti Linnanvuori 2008-01-16 08:16:35 UTC
http://marc.info/?l=linux-kernel&m=119940437408149&w=2
Comment 14 Thomas Gleixner 2008-01-24 04:16:28 UTC
Yes, that might hit us here. Grmbl. Can you please boot with "nolapic_timer" on the kernel command line ?
Comment 15 Matti Linnanvuori 2008-01-24 05:18:39 UTC
Created attachment 14557 [details]
Boot log with nolapic_timer
Comment 16 Matti Linnanvuori 2008-01-30 02:36:46 UTC

*** This bug has been marked as a duplicate of bug 5149 ***
Comment 17 Matti Linnanvuori 2008-02-09 23:37:51 UTC
I thought a wake-on-lan fix could fix this bug, too, but it is not necessarily a duplicate.
Comment 18 Matti Linnanvuori 2008-03-16 04:41:24 UTC
I think this is related to disabling of IRQs in a driver.

Note You need to log in before you can comment on or make changes to this bug.