On Mon, 7 Sep 2009, Yu Zhiwei wrote: > Hello, e1000 developers, > > I was trying to nfsroot with USB stick from my server, but failed to get IP > address from DHCP server most of time. I am sure that network configuration > is good, because I can nfsroot with e1000 on another server. This kernel > also works fine when it boots from harddisk with an ordinary linux > distribution. (CentOS 3.9 in my case) > > My server has 6 Intel 82574L on the mother board, CPU is Intel Core Duo 2 > E2160. Kernel version is 2.4.33.3, e1000e version is 1.0.2.5, and e1000e is > compiled into kernel image in order to nfsroot. e1000 is also compiled into > this kernel, so a few functions in e1000e are renamed to avoid naming > conflict. > > To debug, I added a few printk in netdev.c. I found that a lot of > interrupts, whose ICR value is 0x0 were received by eth2. I figured it out > that eth2 shared interrupt line 19 with usb-uhci, so these interrupts are > actually from my USB stick when USB stick is initialized. If I don't > compile USB code into kernel, the kernel can nfsroot without any problem. > Seems that Interrupts from USB stick affect e1000e. > > In kernel log, I noticed that e1000_watchdog_task() wasn't executed even > e1000_watchdog() scheduled the task. Therefore, ethernet link is not > detected as active, DHCP requests are enqueued but not sent.
I have seen this problem too with tasks not running that early in kernel boot. I don't know why the kernel won't allow tasks to run, but it will not. One option is to collapse the wathdog_task code into e1000_watchdog, which might get you working. > I am wondering if USB key interrupts stop watchdog task to run. Is it > timing problem or concurrency problem? I am doubting it is concurrency > problem because I cannot see any spinlock to protect tx queue. Please > correct me if I am wrong. I don't think USB interrupts are causing any issue, I believe it is the watchdog_task issue mentioned above. BTW newer kernels don't have this issue with the same code. > log is listed as follows, you can see after "DEBUG: e1000_watchdog: 06:00.0: > eth0: Entering, e1000_watchdog_task scheduled at jiffies=1467", > e1000_watchdog_task doesn't run. > Thanks for doing the detailed debug. One other option you could do is to force the driver to wait for link at the end of open. there is a driver variable called adapter->hw.phy.autoneg_wait_to_complete = 0; you can set that to 1 in e1000[e]_probe, see if that works. Jesse ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel
