Re: Xen-4 PVUSB kernel bug / Xenlinux 2.6.32

Re: Xen-4 PVUSB kernel bug / Xenlinux 2.6.32

[Pasi Kärkkäinen]

Adding xen-devel to CC.. has anyone seen this earlier? 

-- Pasi

On Fri, May 14, 2010 at 09:10:57PM +0200, Peter Klar wrote:
> Hallo,
> 
> system is Gentoo amd64, Xen-4.0.0, kernel is Gentoo's xen-sources-2.6.32-
> xen-r1.
> Hardware is DualCore AMD Athlon with 8GB RAM.
> 
> I tried to use an USB printer (Samsung CLP-310) via PVUSB as follows:
> - modprobe usbbk in dom0
> - xm usb-hc-create  domainX  2  8
> - xm usb-attach  domainX  0  1  2-3
> (selected the correspondend BusID displayed by 'xm usb-list-assignable-
> devices')
> 
> So far everything is ok, domU automatically loads the necessary modules,  
> lsusb within the domU 'domainX' displays the root-hub and the usb-printer.
> 
> When testing the printer with cups (printing a testpage) the dom0 kernel 
> dumps and the system hangs/is unusable, needs to be reset.
> The printer receives some but not the complete/correct data.
> 
> Testing an USB mass storage device (Kingston 8GB memstick) seems to work, 
> even though it could only be mounted readonly within the domU, at least I 
> got no kernel crash but didn't test this one further.
> 
> As the bug seems to be related to the SLAB allocator, the dump says 'kernel 
> BUG at mm/slub.c:2969!', I also recompiled the kernel using the SLAB instead 
> of SLUB allocator, but this does not make any difference, the behaviour is 
> the same (beside the dump then reports a bug within slab.c instead of 
> slub.c).
> 
> Do you have any hints regarding this issue, do I perhaps miss some USB 
> related modules or similar?
> I did not compile any hardware USB host controller driver for the domU 
> kernel (only xen-hcd), all in all the kernel is pretty stripped down.
> 
> Thanks & Regards
> Peter Klar
> 
> 
> ------------[ cut here ]------------
> kernel BUG at mm/slub.c:2969!
> invalid opcode: 0000 [#1] SMP 
> last sysfs file: /sys/devices/xen-backend/vbd-3-51745/statistics/wr_sect
> CPU 0 
> Modules linked in: usbbk ipv6 bridge stp llc usbhid hid usb_storage 
> ide_pci_generic evdev atiixp ehci_hcd ohci_hcd processor pcspkr r8169 
> usbcore ide_core thermal_sys mii button
> Pid: 0, comm: swapper Tainted: G        W  2.6.32-xen-r1-mcclure #1 To Be 
> Filled By O.E.M.
> 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]
>  [<ffffffff803629d3>] ? kref_put+0x33/0x70
>  [<ffffffffa009d21e>] ? ehci_urb_done+0xae/0x100 [ehci_hcd]
>  [<ffffffffa009d64c>] ? qh_completions+0x3dc/0x470 [ehci_hcd]
>  [<ffffffffa009e18e>] ? ehci_work+0x8e/0x950 [ehci_hcd]
>  [<ffffffff8026effc>] ? force_quiescent_state+0x2c/0x310
>  [<ffffffffa00a26d5>] ? ehci_irq+0x105/0x230 [ehci_hcd]
>  [<ffffffffa0042a61>] ? usb_hcd_irq+0x51/0xd0 [usbcore]
>  [<ffffffff8026f955>] ? rcu_process_callbacks+0x45/0x50
>  [<ffffffff8026aeba>] ? handle_IRQ_event+0x3a/0x100
>  [<ffffffff8026d605>] ? handle_level_irq+0x95/0x170
>  [<ffffffff8020a3bc>] ? call_softirq+0x1c/0x30
>  [<ffffffff8020bcf7>] ? handle_irq+0x17/0x20
>  [<ffffffff803d8bab>] ? evtchn_do_upcall+0x15b/0x270
>  [<ffffffff80209e1e>] ? do_hypervisor_callback+0x1e/0x30
>  <EOI> 
>  [<ffffffff8020c8fd>] ? xen_safe_halt+0xad/0x140
>  [<ffffffff802103f5>] ? xen_idle+0x25/0x60
>  [<ffffffff802080b7>] ? cpu_idle+0x47/0x80
>  [<ffffffff8065dc75>] ? start_kernel+0x2d5/0x3c0
> Code: 14 49 8b 00 48 89 04 d3 49 89 18 eb b1 66 a9 00 c0 74 18 5b 5d 41 5c 
> 48 89 f7 e9 25 93 fd ff 48 8b 76 10 48 8b 06 e9 48 ff ff ff <0f> 0b eb fe 0f 1f 
> 44 00 00 48 81 ef a8 00 00 00 e9 f4 fe ff ff 
> RIP  [<ffffffff802a35a7>] kfree+0xf7/0x100
>  RSP <ffff880001008d08>
> ---[ end trace 9ad80e66b0ffe961 ]---
> Kernel panic - not syncing: Fatal exception in interrupt
> Pid: 0, comm: swapper Tainted: G      D W  2.6.32-xen-r1-mcclure #1
> Call Trace:
>  <IRQ>  [<ffffffff802346a6>] ? panic+0x86/0x170
>  [<ffffffff8024e2b6>] ? up+0x16/0x50
>  [<ffffffff80234ee8>] ? release_console_sem+0x238/0x290
>  [<ffffffff8020dee1>] ? oops_end+0xd1/0xe0
>  [<ffffffff8020b294>] ? do_invalid_op+0x84/0xc0
>  [<ffffffff802a35a7>] ? kfree+0xf7/0x100
>  [<ffffffff8020e290>] ? print_context_stack+0x40/0xb0
>  [<ffffffff8020ef40>] ? dma_generic_free_coherent+0x0/0x40
>  [<ffffffff802244e0>] ? xen_destroy_contiguous_region+0x390/0x6e0
>  [<ffffffffa0043150>] ? urb_destroy+0x0/0x20 [usbcore]
>  [<ffffffff8020a045>] ? invalid_op+0x25/0x30
>  [<ffffffffa0043150>] ? urb_destroy+0x0/0x20 [usbcore]
>  [<ffffffff802a35a7>] ? kfree+0xf7/0x100
>  [<ffffffff802a34c6>] ? kfree+0x16/0x100
>  [<ffffffffa0043150>] ? urb_destroy+0x0/0x20 [usbcore]
>  [<ffffffffa0043163>] ? urb_destroy+0x13/0x20 [usbcore]
>  [<ffffffff803629d3>] ? kref_put+0x33/0x70
>  [<ffffffffa009d21e>] ? ehci_urb_done+0xae/0x100 [ehci_hcd]
>  [<ffffffffa009d64c>] ? qh_completions+0x3dc/0x470 [ehci_hcd]
>  [<ffffffffa009e18e>] ? ehci_work+0x8e/0x950 [ehci_hcd]
>  [<ffffffff8026effc>] ? force_quiescent_state+0x2c/0x310
>  [<ffffffffa00a26d5>] ? ehci_irq+0x105/0x230 [ehci_hcd]
>  [<ffffffffa0042a61>] ? usb_hcd_irq+0x51/0xd0 [usbcore]
>  [<ffffffff8026f955>] ? rcu_process_callbacks+0x45/0x50
>  [<ffffffff8026aeba>] ? handle_IRQ_event+0x3a/0x100
>  [<ffffffff8026d605>] ? handle_level_irq+0x95/0x170
>  [<ffffffff8020a3bc>] ? call_softirq+0x1c/0x30
>  [<ffffffff8020bcf7>] ? handle_irq+0x17/0x20
>  [<ffffffff803d8bab>] ? evtchn_do_upcall+0x15b/0x270
>  [<ffffffff80209e1e>] ? do_hypervisor_callback+0x1e/0x30
>  <EOI>  [<ffffffff8020c8fd>] ? xen_safe_halt+0xad/0x140
>  [<ffffffff802103f5>] ? xen_idle+0x25/0x60
>  [<ffffffff802080b7>] ? cpu_idle+0x47/0x80
>  [<ffffffff8065dc75>] ? start_kernel+0x2d5/0x3c0
> 
> 
> #################################################
> # uname -a
> Linux mcclure 2.6.32-xen-r1-mcclure #1 SMP Thu May 13 13:57:34 CEST 2010 
> x86_64 AMD Athlon(tm) Dual Core Processor 4850e AuthenticAMD GNU/Linux
> 
> #################################################
> # xm info
> host                   : mcclure
> release                : 2.6.32-xen-r1-mcclure
> version                : #1 SMP Thu May 13 13:57:34 CEST 2010
> machine                : x86_64
> nr_cpus                : 2
> nr_nodes               : 1
> cores_per_socket       : 2
> threads_per_core       : 1
> cpu_mhz                : 2494
> hw_caps                : 
> 178bf3ff:ebd3fbff:00000000:00000010:00002001:00000000:0000011f:00000000
> virt_caps              : hvm
> total_memory           : 8140
> free_memory            : 1413
> node_to_cpu            : node0:0-1
> node_to_memory         : node0:1413
> node_to_dma32_mem      : node0:1413
> max_node_id            : 0
> xen_major              : 4
> xen_minor              : 0
> xen_extra              : .0
> xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 
> hvm-3.0-x86_32p hvm-3.0-x86_64 
> xen_scheduler          : credit
> xen_pagesize           : 4096
> platform_params        : virt_start=0xffff800000000000
> xen_changeset          : unavailable
> xen_commandline        : dom0_mem=512M
> cc_compiler            : gcc version 4.1.2 (Gentoo 4.1.2 p1.3)
> cc_compile_by          : 
> cc_compile_domain      : priv.chaos
> cc_compile_date        : Mon May 10 23:18:53 CEST 2010
> xend_config_format     : 4
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users

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

[Jan Beulich]

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
corruption.

Jan

Re: [Xen-users] Xen-4 PVUSB kernel bug

[Pasi Kärkkäinen]

On Mon, Jun 07, 2010 at 05:57:25PM +0200, Peter Klar wrote:
> On Tuesday 01 June 2010, Andrew Lyon wrote:
> > I've only tried using pvusb once and that was a long time ago so I'm
> > not all that surprised that there are issues with it in this kernel,
> > I have much less time available now to debug issues with the dom0
> > kernel patch sets than I did a few months ago but if you could try
> > 2.6.32-r2 from http://code.google.com/p/gentoo-xen-kernel/downloads/list
> > and if the issue persists I will try to replicate it and see if I can
> > fix it.
> > 
> > I'm not sure if novell/suse support pv_usb or not, if they do then I
> > can probably get some assistance from Jan as he will certainly be
> > interested in fixing any bug that exists in the SLE11-SP1 kernel that
> > the patches originate from.
> 
> I tried the 2.6.32-r2 and the 2.6.34 kernels, the problem still exists, even 
> though the dom0 doesn't freeze anymore, it logs some kernel messages (see 
> below) but seems to work w/o any problems.
> 
> The printer still receives some data but doesn't print anything.
> The domU doesn't report any kernel messages or similar.
> 

Ok.. CC'ing to xen-devel.

-- Pasi

> Regards
> 
> 
> ------------[ cut here ]------------
> kernel BUG at mm/slub.c:2846!
> invalid opcode: 0000 [#1] SMP 
> last sysfs file: /sys/devices/xen-backend/vbd-3-51745/statistics/wr_sect
> CPU 0 
> Modules linked in: usbbk ipv6 bridge stp llc usbhid hid ide_pci_generic 
> usb_storage evdev atiixp ide_core pcspkr ehs
> 
> Pid: 6169, comm: usbback.3.0 Not tainted 2.6.34-xen-mcclure #1 A780FullHD/To 
> Be Filled By O.E.M.
> RIP: e030:[<ffffffff802a9c0a>]  [<ffffffff802a9c0a>] kfree+0xea/0xf0
> RSP: e02b:ffff88000ccfbbc0  EFLAGS: 00010246
> RAX: 4000000000000000 RBX: ffff88000bd44000 RCX: ffff88000125d470
> RDX: 000000000005ea20 RSI: ffff8800013996e0 RDI: ffff88000bd44000
> RBP: ffffffffa0011350 R08: 0000000000000000 R09: ffff88000181f1c0
> R10: 0000000000000000 R11: ffffffff80209730 R12: 0000000000000000
> R13: 000000000000000e R14: 000000000000000e R15: 0000000000000001
> FS:  00007f7bd85be910(0000) GS:ffff880001004000(0000) knlGS:0000000000000000
> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00007f7bdf7c8000 CR3: 000000000d783000 CR4: 0000000000000660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process usbback.3.0 (pid: 6169, threadinfo ffff88000ccfa000, task 
> ffff88000b0e0ba0)
> Stack:
>  ffff8800061c9cc0 ffffffffa0011350 0000000000000000 ffffffffa0011363
> <0> ffff8800061c9cc0 ffffffff80369b43 000000000000000e ffff8800061c9cc0
> <0> ffff88000ccfbc10 ffffffffa016b72a ffff88000ccfbc10 ffff88000ccfbc10
> Call Trace:
>  [<ffffffffa0011350>] ? urb_destroy+0x0/0x20 [usbcore]
>  [<ffffffffa0011363>] ? urb_destroy+0x13/0x20 [usbcore]
>  [<ffffffff80369b43>] ? kref_put+0x33/0x70
>  [<ffffffffa016b72a>] ? usbbk_free_urbs+0x9a/0x120 [usbbk]
>  [<ffffffffa016c434>] ? usbbk_schedule+0x414/0x1070 [usbbk]
>  [<ffffffff802257fc>] ? update_curr+0x6c/0xf0
>  [<ffffffff8022b9ff>] ? check_preempt_wakeup+0x9f/0x100
>  [<ffffffff80228d5b>] ? try_to_wake_up+0xab/0x2d0
>  [<ffffffff8022437b>] ? target_load+0x2b/0x60
>  [<ffffffff8022c67a>] ? select_task_rq_fair+0x5ba/0x690
>  [<ffffffff802257fc>] ? update_curr+0x6c/0xf0
>  [<ffffffff8022594d>] ? __dequeue_entity+0x3d/0x50
>  [<ffffffff80227e21>] ? finish_task_switch+0x41/0xf0
>  [<ffffffff804f466d>] ? schedule+0x25d/0x780
>  [<ffffffff80224b3b>] ? __wake_up_common+0x5b/0x90
>  [<ffffffffa016c020>] ? usbbk_schedule+0x0/0x1070 [usbbk]
>  [<ffffffff80246876>] ? kthread+0x96/0xa0
>  [<ffffffff80205094>] ? kernel_thread_helper+0x4/0x10
>  [<ffffffff802467e0>] ? kthread+0x0/0xa0
>  [<ffffffff80205090>] ? kernel_thread_helper+0x0/0x10
> Code: 18 49 8b 00 48 89 04 13 49 89 18 eb b8 66 a9 00 c0 74 18 5b 5d 41 5c 
> 48 89 f7 e9 52 86 fd ff 48 8b 76 10 48 8 
> RIP  [<ffffffff802a9c0a>] kfree+0xea/0xf0
>  RSP <ffff88000ccfbbc0>
> ---[ end trace a9e5ebb40790f3ae ]---

Re: [Xen-users] Xen-4 PVUSB kernel bug

[Ky Srinivasan]

We fixed a bunch of usb related bugs in sles11 sp1; I don't recall if this was one of them.

Regards,

K. Y

>>> On 6/7/2010 at 12:29 PM, in message <20100607162941.GM17817@reaktio.net>, Pasi
Kärkkäinen<pasik@iki.fi> wrote: 
> On Mon, Jun 07, 2010 at 05:57:25PM +0200, Peter Klar wrote:
>> On Tuesday 01 June 2010, Andrew Lyon wrote:
>> > I've only tried using pvusb once and that was a long time ago so I'm
>> > not all that surprised that there are issues with it in this kernel,
>> > I have much less time available now to debug issues with the dom0
>> > kernel patch sets than I did a few months ago but if you could try
>> > 2.6.32-r2 from http://code.google.com/p/gentoo-xen-kernel/downloads/list
>> > and if the issue persists I will try to replicate it and see if I can
>> > fix it.
>> > 
>> > I'm not sure if novell/suse support pv_usb or not, if they do then I
>> > can probably get some assistance from Jan as he will certainly be
>> > interested in fixing any bug that exists in the SLE11-SP1 kernel that
>> > the patches originate from.
>> 
>> I tried the 2.6.32-r2 and the 2.6.34 kernels, the problem still exists, even 
>> though the dom0 doesn't freeze anymore, it logs some kernel messages (see 
>> below) but seems to work w/o any problems.
>> 
>> The printer still receives some data but doesn't print anything.
>> The domU doesn't report any kernel messages or similar.
>> 
> 
> Ok.. CC'ing to xen-devel.
> 
> -- Pasi
> 
>> Regards
>> 
>> 
>> ------------[ cut here ]------------
>> kernel BUG at mm/slub.c:2846!
>> invalid opcode: 0000 [#1] SMP 
>> last sysfs file: /sys/devices/xen-backend/vbd-3-51745/statistics/wr_sect
>> CPU 0 
>> Modules linked in: usbbk ipv6 bridge stp llc usbhid hid ide_pci_generic 
>> usb_storage evdev atiixp ide_core pcspkr ehs
>> 
>> Pid: 6169, comm: usbback.3.0 Not tainted 2.6.34-xen-mcclure #1 A780FullHD/To 
>> Be Filled By O.E.M.
>> RIP: e030:[<ffffffff802a9c0a>]  [<ffffffff802a9c0a>] kfree+0xea/0xf0
>> RSP: e02b:ffff88000ccfbbc0  EFLAGS: 00010246
>> RAX: 4000000000000000 RBX: ffff88000bd44000 RCX: ffff88000125d470
>> RDX: 000000000005ea20 RSI: ffff8800013996e0 RDI: ffff88000bd44000
>> RBP: ffffffffa0011350 R08: 0000000000000000 R09: ffff88000181f1c0
>> R10: 0000000000000000 R11: ffffffff80209730 R12: 0000000000000000
>> R13: 000000000000000e R14: 000000000000000e R15: 0000000000000001
>> FS:  00007f7bd85be910(0000) GS:ffff880001004000(0000) knlGS:0000000000000000
>> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>> CR2: 00007f7bdf7c8000 CR3: 000000000d783000 CR4: 0000000000000660
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process usbback.3.0 (pid: 6169, threadinfo ffff88000ccfa000, task 
>> ffff88000b0e0ba0)
>> Stack:
>>  ffff8800061c9cc0 ffffffffa0011350 0000000000000000 ffffffffa0011363
>> <0> ffff8800061c9cc0 ffffffff80369b43 000000000000000e ffff8800061c9cc0
>> <0> ffff88000ccfbc10 ffffffffa016b72a ffff88000ccfbc10 ffff88000ccfbc10
>> Call Trace:
>>  [<ffffffffa0011350>] ? urb_destroy+0x0/0x20 [usbcore]
>>  [<ffffffffa0011363>] ? urb_destroy+0x13/0x20 [usbcore]
>>  [<ffffffff80369b43>] ? kref_put+0x33/0x70
>>  [<ffffffffa016b72a>] ? usbbk_free_urbs+0x9a/0x120 [usbbk]
>>  [<ffffffffa016c434>] ? usbbk_schedule+0x414/0x1070 [usbbk]
>>  [<ffffffff802257fc>] ? update_curr+0x6c/0xf0
>>  [<ffffffff8022b9ff>] ? check_preempt_wakeup+0x9f/0x100
>>  [<ffffffff80228d5b>] ? try_to_wake_up+0xab/0x2d0
>>  [<ffffffff8022437b>] ? target_load+0x2b/0x60
>>  [<ffffffff8022c67a>] ? select_task_rq_fair+0x5ba/0x690
>>  [<ffffffff802257fc>] ? update_curr+0x6c/0xf0
>>  [<ffffffff8022594d>] ? __dequeue_entity+0x3d/0x50
>>  [<ffffffff80227e21>] ? finish_task_switch+0x41/0xf0
>>  [<ffffffff804f466d>] ? schedule+0x25d/0x780
>>  [<ffffffff80224b3b>] ? __wake_up_common+0x5b/0x90
>>  [<ffffffffa016c020>] ? usbbk_schedule+0x0/0x1070 [usbbk]
>>  [<ffffffff80246876>] ? kthread+0x96/0xa0
>>  [<ffffffff80205094>] ? kernel_thread_helper+0x4/0x10
>>  [<ffffffff802467e0>] ? kthread+0x0/0xa0
>>  [<ffffffff80205090>] ? kernel_thread_helper+0x0/0x10
>> Code: 18 49 8b 00 48 89 04 13 49 89 18 eb b8 66 a9 00 c0 74 18 5b 5d 41 5c 
>> 48 89 f7 e9 52 86 fd ff 48 8b 76 10 48 8 
>> RIP  [<ffffffff802a9c0a>] kfree+0xea/0xf0
>>  RSP <ffff88000ccfbbc0>
>> ---[ end trace a9e5ebb40790f3ae ]---
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [Xen-users] Xen-4 PVUSB kernel bug

[Jan Beulich]

>>> On 07.06.10 at 19:21, "Ky Srinivasan" <ksrinivasan@novell.com> wrote:
> We fixed a bunch of usb related bugs in sles11 sp1; I don't recall if this 
> was one of them.

This appears to be a different problem: usbback apparently passes
something to kfree() that hasn't come from the respective allocator
(or memory is being corrupted).

I'm suspecting a collision between usbback's and usblp's use of
urb->transfer_flags' URB_FREE_BUFFER. Someone able to
reproduce this would need to look into this - I don't have a USB
printer, so I can't even consider trying it myself.

Jan

>>>> On 6/7/2010 at 12:29 PM, in message <20100607162941.GM17817@reaktio.net>, Pasi
> Kärkkäinen<pasik@iki.fi> wrote: 
>> On Mon, Jun 07, 2010 at 05:57:25PM +0200, Peter Klar wrote:
>>> On Tuesday 01 June 2010, Andrew Lyon wrote:
>>> > I've only tried using pvusb once and that was a long time ago so I'm
>>> > not all that surprised that there are issues with it in this kernel,
>>> > I have much less time available now to debug issues with the dom0
>>> > kernel patch sets than I did a few months ago but if you could try
>>> > 2.6.32-r2 from http://code.google.com/p/gentoo-xen-kernel/downloads/list 
>>> > and if the issue persists I will try to replicate it and see if I can
>>> > fix it.
>>> > 
>>> > I'm not sure if novell/suse support pv_usb or not, if they do then I
>>> > can probably get some assistance from Jan as he will certainly be
>>> > interested in fixing any bug that exists in the SLE11-SP1 kernel that
>>> > the patches originate from.
>>> 
>>> I tried the 2.6.32-r2 and the 2.6.34 kernels, the problem still exists, even 
> 
>>> though the dom0 doesn't freeze anymore, it logs some kernel messages (see 
>>> below) but seems to work w/o any problems.
>>> 
>>> The printer still receives some data but doesn't print anything.
>>> The domU doesn't report any kernel messages or similar.
>>> 
>> 
>> Ok.. CC'ing to xen-devel.
>> 
>> -- Pasi
>> 
>>> Regards
>>> 
>>> 
>>> ------------[ cut here ]------------
>>> kernel BUG at mm/slub.c:2846!
>>> invalid opcode: 0000 [#1] SMP 
>>> last sysfs file: /sys/devices/xen-backend/vbd-3-51745/statistics/wr_sect
>>> CPU 0 
>>> Modules linked in: usbbk ipv6 bridge stp llc usbhid hid ide_pci_generic 
>>> usb_storage evdev atiixp ide_core pcspkr ehs
>>> 
>>> Pid: 6169, comm: usbback.3.0 Not tainted 2.6.34-xen-mcclure #1 A780FullHD/To 
> 
>>> Be Filled By O.E.M.
>>> RIP: e030:[<ffffffff802a9c0a>]  [<ffffffff802a9c0a>] kfree+0xea/0xf0
>>> RSP: e02b:ffff88000ccfbbc0  EFLAGS: 00010246
>>> RAX: 4000000000000000 RBX: ffff88000bd44000 RCX: ffff88000125d470
>>> RDX: 000000000005ea20 RSI: ffff8800013996e0 RDI: ffff88000bd44000
>>> RBP: ffffffffa0011350 R08: 0000000000000000 R09: ffff88000181f1c0
>>> R10: 0000000000000000 R11: ffffffff80209730 R12: 0000000000000000
>>> R13: 000000000000000e R14: 000000000000000e R15: 0000000000000001
>>> FS:  00007f7bd85be910(0000) GS:ffff880001004000(0000) knlGS:0000000000000000
>>> CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
>>> CR2: 00007f7bdf7c8000 CR3: 000000000d783000 CR4: 0000000000000660
>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>> Process usbback.3.0 (pid: 6169, threadinfo ffff88000ccfa000, task 
>>> ffff88000b0e0ba0)
>>> Stack:
>>>  ffff8800061c9cc0 ffffffffa0011350 0000000000000000 ffffffffa0011363
>>> <0> ffff8800061c9cc0 ffffffff80369b43 000000000000000e ffff8800061c9cc0
>>> <0> ffff88000ccfbc10 ffffffffa016b72a ffff88000ccfbc10 ffff88000ccfbc10
>>> Call Trace:
>>>  [<ffffffffa0011350>] ? urb_destroy+0x0/0x20 [usbcore]
>>>  [<ffffffffa0011363>] ? urb_destroy+0x13/0x20 [usbcore]
>>>  [<ffffffff80369b43>] ? kref_put+0x33/0x70
>>>  [<ffffffffa016b72a>] ? usbbk_free_urbs+0x9a/0x120 [usbbk]
>>>  [<ffffffffa016c434>] ? usbbk_schedule+0x414/0x1070 [usbbk]
>>>  [<ffffffff802257fc>] ? update_curr+0x6c/0xf0
>>>  [<ffffffff8022b9ff>] ? check_preempt_wakeup+0x9f/0x100
>>>  [<ffffffff80228d5b>] ? try_to_wake_up+0xab/0x2d0
>>>  [<ffffffff8022437b>] ? target_load+0x2b/0x60
>>>  [<ffffffff8022c67a>] ? select_task_rq_fair+0x5ba/0x690
>>>  [<ffffffff802257fc>] ? update_curr+0x6c/0xf0
>>>  [<ffffffff8022594d>] ? __dequeue_entity+0x3d/0x50
>>>  [<ffffffff80227e21>] ? finish_task_switch+0x41/0xf0
>>>  [<ffffffff804f466d>] ? schedule+0x25d/0x780
>>>  [<ffffffff80224b3b>] ? __wake_up_common+0x5b/0x90
>>>  [<ffffffffa016c020>] ? usbbk_schedule+0x0/0x1070 [usbbk]
>>>  [<ffffffff80246876>] ? kthread+0x96/0xa0
>>>  [<ffffffff80205094>] ? kernel_thread_helper+0x4/0x10
>>>  [<ffffffff802467e0>] ? kthread+0x0/0xa0
>>>  [<ffffffff80205090>] ? kernel_thread_helper+0x0/0x10
>>> Code: 18 49 8b 00 48 89 04 13 49 89 18 eb b8 66 a9 00 c0 74 18 5b 5d 41 5c 
>>> 48 89 f7 e9 52 86 fd ff 48 8b 76 10 48 8 
>>> RIP  [<ffffffff802a9c0a>] kfree+0xea/0xf0
>>>  RSP <ffff88000ccfbbc0>
>>> ---[ end trace a9e5ebb40790f3ae ]---
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com 
>> http://lists.xensource.com/xen-devel 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com 
> http://lists.xensource.com/xen-devel