[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] E1000 hanging
I analyzed the e1000-ethernet driver hanging the system during reboot reboot. I found out, that the system worked properly when exchanging the "ms_delay" by an "ms_delay_irq". When looking into it I recognized, that the process goes to sleep when applying the first function, while it loops for the approximate time when applying the latter function. Further analysis showed, that the system schedules "xen_idle" which in turn determines the "next timer". I wrote quite a lot of various code insertions both in the kernel an within the xen hypervisor. I found out, that the timer which is in fact specified is essentially in the infinite future. This causes the sleep call never to wake up. It wakes up immediately at any keyboard click, and from what I saw in the scheduling code of the hypervisior ( the DF_BLOCKED flag seems to become cleared on receipt of an interrupt ), this seems to be the case for any interrupt. I managed to "fix" the problem by adding a timer a 10th second in the future within "do_block" in the hypervisor. The problem seems to be that the timer has elapsed, between the time the system decides to schedule xen_idle and the moment it determines the "next timer". Addmitedly I all of this with xen.2.0.5. I used the 2.0.6 hypervisor without recompiling the kernel and it showd the same behavior. I tried xen-unstable yesterday, but the kernel failed to initialize and the last message I got was infroming that it was initializing the sata-disks. It hung and showed now devices. I will try 2.0.6 next week by compiling the kernel completely. Looking into the routines "xen_idle", "set_timeout_timer" and "next_timer_interrupt" I found no changes at first sight. So I do not expect the behavior to change. In the unstable version the check for local_softirq pending seems to be a candidate to fix the problem, because the system seems to be woken up at the next clock-tick. And the cleck for pending events in do_block AFTER seting the (now-called) _VCPUF_BLOCKED flag and ( in case ) clearing it again, seems to do the job. Did this problem no show up at other "short-term" waits than in the e1000 driver ? It occured there within the e1000_hw_reset routine. Is it good advice to try the "unstable" version ? Thanks in advance Peter Bier _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |