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


[Xen-devel] Re: [Xen-users] Xen-4 PVUSB kernel bug / Xenlinux 2.6.32

To: "Peter Klar" <mcbeagle@xxxxxx>
Subject: [Xen-devel] Re: [Xen-users] Xen-4 PVUSB kernel bug / Xenlinux 2.6.32
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Wed, 19 May 2010 14:36:13 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 19 May 2010 06:37:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100518192315.GC17817@xxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <201005142110.58032.mcbeagle@xxxxxx> <20100518192315.GC17817@xxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, May 14, 2010 at 09:10:57PM +0200, Peter Klar wrote:
> RIP: e030:[<ffffffff802a35a7>]  [<ffffffff802a35a7>] kfree+0xf7/0x100
> RSP: e02b:ffff880001008d08  EFLAGS: 00010046
> RAX: 4000000000000000 RBX: ffff88000cdf0000 RCX: ffff8800013168b8
> RDX: 0000000000066f80 RSI: ffff8800013d3c80 RDI: ffff88000cdf0000
> RBP: ffffffffa0043150 R08: 0000000000000000 R09: ffff88000181f1c0
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800000050c0
> R13: ffff88000d24c400 R14: ffff88000d24c55c R15: ffff8800000050c0
> FS:  00007f5cc08d8910(0000) GS:ffff880001005000(0000) knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00007ff066592000 CR3: 000000000b885000 CR4: 0000000000000660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process swapper (pid: 0, threadinfo ffffffff805e6000, task ffffffff80610420)
> Stack:
>  ffff8800000050c0 ffffffffa0043150 ffff8800000050c0 ffffffffa0043163
> <0> ffff8800000050c0 ffffffff803629d3 ffff8800000050c0 ffff88000d24c540
> <0> 0000000000000000 ffffffffa009d21e 0000000000009c01 ffff88000d7ec240
> Call Trace:
>  <IRQ> 
>  [<ffffffffa0043150>] ? urb_destroy+0x0/0x20 [usbcore]
>  [<ffffffffa0043163>] ? urb_destroy+0x13/0x20 [usbcore]

Would you be able to confirm that this is the conditional (rather than
the unconditional) call to kfree() in urb_destroy()?

If so, the question is where the URB gets URB_FREE_BUFFER set.
Looking through the entire kernel, the only somewhat suspicious
place is in drivers/usb/class/usblp.c:usblp_new_writeurb(), but as
far as I understand the device specific driver should only be used
in the DomU. Hence you would need to do some analysis on your
own, trying to find where that flag gets set (usbback uses the
transfer_buffer field of the struct urb for a different purpose, and
hence a conflict here seems the most likely cause of your problem).

If not, the struct urb's address itself would be bogus, meaning your
seeing general (usually much more difficult to debug) memory


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>