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

[orstig <orstig@xxxxxxxxx>]

Hello, i have now change to Debian lenny on dom0 and using the offical
2.6.18.8 xen kernel and xen-sources-2.6.32-1 patches on linux-2.6.32.10 on
domU. And now pvusb works stable for me, (tried a usb pen drive, a LG-dvdrw
and a ciedko air keyboard/mouse uptime on dom0 13 days and on domU 5 days).

/Magnus

Andrew Lyon wrote:
> 
> On Sun, May 16, 2010 at 9:10 PM, orstig <orstig@xxxxxxxxx> wrote:
>>
>> Hello, i have a similar problem with a logitech wireless mouse and
>> keyboard
>> (all hardware i have tryied starting today), i use this line in domU.cfg
>> vusb = ['usbver=1, numports=2, port_1=1-2.4']
>>
>> everything looks fine after boot up (device shows when lsusb and modules
>> are
>> being loaded) but neither keyboard or mouse are working.
>>
>> my crash (dom0) comes first when halting or rebooting domU
>>
>> system: Ubuntu 10.04 server amd64, Xen 4.0, xen-sources-2.6.32-1 patches
>> on
>> linux-2.6.32.10
>> hardware: Intel quad core 8GB RAM
>>
>> hope someone have a solution /orstig
>>
>>
>> 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@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-users
>>>
>>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Xen-4-PVUSB-kernel-bug-tp28563324p28577019.html
>> Sent from the Xen - User mailing list archive at Nabble.com.
>>
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-users
>>
> 
> 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.
> 
> Andy
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Xen-4-PVUSB-kernel-bug-tp28563324p28856062.html
Sent from the Xen - User mailing list archive at Nabble.com.


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