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-users] kernel BUG pci-dma-xen.c:361!

Hello everyone,

I'm running Xen 3.3.0 on my small network server (Gentoo on dualcore AMD64). 
Everything went fine until I wanted to export some devices from dom0 to domU 
(you know, pciback.hide on hypervisor).

Trying to assign RTL8110SC (r8169) to firewall domU or USB OHCI and EHCI to 
print server domU, gets me to this error when booting or loading the module (or 
plugging USB) ...

------------[ cut here ]------------
kernel BUG at arch/x86_64/kernel/../../i386/kernel/pci-dma-xen.c:361!
invalid opcode: 0000 [1] SMP
Modules linked in:
Pid: 54, comm: khubd Not tainted 2.6.21-xen #5
RIP: e030:[<ffffffff80211122>]  [<ffffffff80211122>] dma_map_single+0x172/0x190
RSP: e02b:ffff88005fd35ba0  EFLAGS: 00010282
RAX: 000000000000002f RBX: ffff880000e755a0 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff8062e3e0
RBP: 0000000000000001 R08: ffff880000a48000 R09: 0000000000000eb9
R10: 000000000000002d R11: ffffffff8045d9f0 R12: ffff88005fd25870
R13: 0000000000000008 R14: 0000000000000010 R15: 0000000000000006
FS:  0000000000000000(0000) GS:ffffffff80668000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000201000 CR4: 0000000000000660
Process khubd (pid: 54, threadinfo ffff88005fd34000, task ffff8800007670a0)
Stack:  ffffffffffffe86f 0000000000000000 ffff880000042780 ffff88005fd3d848
 ffff880000e35400 ffffffff804a769f ffff88000099d800 ffff88005fd35c90
 ffffffff805f4300 ffffffff806cfe23 ffff88000099d800 ffffffff80230b60
Call Trace:
 [<ffffffff804a769f>] usb_hcd_submit_urb+0x7df/0x8a0
 [<ffffffff80230b60>] vprintk+0x2d0/0x360
 [<ffffffff804a82c0>] urb_destroy+0x0/0x10
 [<ffffffff8044cff1>] kref_put+0x81/0xa0
 [<ffffffff804a8a0c>] usb_start_wait_urb+0x12c/0x150
 [<ffffffff804a8935>] usb_start_wait_urb+0x55/0x150
 [<ffffffff804a8b0c>] usb_control_msg+0xdc/0x120
 [<ffffffff804a4bdb>] hub_port_init+0x2bb/0x620
 [<ffffffff8044c092>] kobject_get+0x12/0x20
 [<ffffffff804a5d94>] hub_thread+0x7a4/0xe40
 [<ffffffff80245940>] autoremove_wake_function+0x0/0x30
 [<ffffffff8022a060>] __wake_up_common+0x40/0x70
 [<ffffffff80245940>] autoremove_wake_function+0x0/0x30
 [<ffffffff804a55f0>] hub_thread+0x0/0xe40
 [<ffffffff802453d0>] keventd_create_kthread+0x0/0x90
 [<ffffffff80245389>] kthread+0xd9/0x120
 [<ffffffff8020a798>] child_rip+0xa/0x12
 [<ffffffff802453d0>] keventd_create_kthread+0x0/0x90
 [<ffffffff802452b0>] kthread+0x0/0x120
 [<ffffffff8020a78e>] child_rip+0x0/0x12

Code: 0f 0b eb fe 48 83 c4 08 48 89 c8 5b 5d 41 5c 41 5d c3 66 66
RIP  [<ffffffff80211122>] dma_map_single+0x172/0x190
 RSP <ffff88005fd35ba0>

In dev mailing list I found that adding 'swiotlb=force' to domU kernel params 
could by a solution, but only I'm getting after this is ...

"Kernel panic - not syncing: No suitable physical memory available for SWIOTLB 

Server has 8Gigs of memory, which should be sufficient. 
Anyone facing the same problem, or knows the way out?

Thanks a lot, Josef
P.S. It's interesting that exporting RTL8139 NIC to domU goes fine, without any 

Xen-users mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-users] kernel BUG pci-dma-xen.c:361!, josef.navratil <=