[Xen-devel] E1000 hanging

[peter bier <peter_bier@xxxxxx>]

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