This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Xenlinux oops and crashes with nbd, Xen no longer boots

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xenlinux oops and crashes with nbd, Xen no longer boots
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 13 Jul 2004 16:29:00 +0100
Cc: Wm <bill@xxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 13 Jul 2004 16:36:46 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Tue, 13 Jul 2004 08:12:26 BST." <E1BkHSk-00013q-00@xxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
Now fixed. You've been able to hit this more reliably than anyone
else, so I'll be interested to hear confirmation that the problem
really has now gone away.

 -- Keir

> Okay, detangling the backtrace....
>  Entry EIP    Function                  Caller's return EIP
>  ---------    --------                  -------------------
>  0xc00c1220   alloc_skb(1656,GFP_NOIO)  0xc00ddd58
>  0xc00dd4b0   tcp_sendmsg               0xc00fa9a1
>  0xc00fa960   inet_sendmsg              0xc00bde23
>  0xc00bddb0   sock_sendmsg              0xc3cad25f
>  unknown      nbd_xmit                  0xc3cad511
>  unknown      nbd_send_req              0xc3cad91c
>  unknown      do_nbd_request            0xc008fc46
>  0xc008fbe0   generic_unplug_device     0xc000c342
>  0xc000c2e0   __run_task_queue          n/a (tail call)
>  0xc00b8f20   io_schedule               0xc000c0a8
>  0xc000c050   tasklet_action            0xc000be9e
>  0xc000bdc0   do_softirq                0xc006f2c0
>  0xc006f220   do_IRQ(133,-)             0xc007395e
>  0xc00738c0   evtchn_do_upcall          0xc006dcd7
>  0xc006dca4   hypervisor_callback       n/a (async callback)
> I see the problem. Well hidden because the key function (io_schedule)
> ends in a tail call. The problem is that we are scheduling I/O
> requests in interrupt context rather than deferring to a process
> context --- a known issue that hasn't bitten until now. I'll have to
> think about a fix.
>  -- Keir

This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
Xen-devel mailing list