[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] BUG: unable to handle kernel NULL pointer dereference - xen_spin_lock_flags



On Tue, 2012-02-14 at 15:28 +0000, Christopher S. Aker wrote:
> On 2/14/12 5:09 AM, Ian Campbell wrote:
> > I suspect this must be&netbk->net_schedule_list_lock but I don't see
> > how that can ever be NULL nor does the offset appear to be 0x474, at
> > least in my tree -- although that may depend on debug options.
> >
> > Are you rebooting guests or plug/unplugging vifs while this is going on?
> 
> Sorry - I'm relaying some of this on behalf of another team member.
> 
> The dom0 insta-panics when running iperf and then bringing a vif down 
> (for a network rules rebuild).  We've only been able to trigger it when 
> the dom0 is dealing with a boatload of packets.  So, it smells like a 
> race between the vif being marked down, and something thinking it can 
> still deliver packets to it...
> 
> root@dom0# ip link set vif2.0 down (return = BOOM)
> br0: port 4(vif2.0) entering forwarding state
> BUG: unable to handle kernel NULL pointer dereference at 00000474
> IP: [<c100e967>] xen_spin_lock_flags+0x27/0x70
> ...

I wonder if this is related to the discussion in
http://lists.xen.org/archives/html/xen-devel/2011-09/msg00981.html
http://lists.xen.org/archives/html/xen-devel/2011-09/msg00985.html

Jan, do you recall what you did about that issue?

Is it as simple as moving the call to netif_stop_queue(dev) in
xenvif_close before the carrier check?

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.