How to track down a DMA panic?

I've recently been experimenting with running a myth backend within a CentOS 5.2 xen domU, I had to patch the saa7134 driver, and use irqpoll due to shared interrupts, but then the driver was basically working.

I have installed mythtv in the domU, it can scan for muxes, record several simultaneous streams from one tuner, and playback just like a physical machine.

... but ...

I have a lingering problem, occasionally I get a kernel panic due to DMA problems, I've been running the same tuners without xen for years without problems, so it seems likely that it's xen that's upsetting the drivers rather than an out-an-out driver bug, obviously I'd like to see if I can fix it.

Here is a typical crash dump

Fatal DMA error! Please use 'swiotlb=force' ----------- [cut here ] --------- [please bite here ] ---------

Kernel BUG at arch/x86_64/kernel/../../i386/kernel/pci-dma-xen.c:165
invalid opcode: 0000 [1] SMP
last sysfs file: /block/xvdc/removable
CPU 0
Modules linked in: saa7134_dvb(U) dvb_pll(U) mt352(U) video_buf_dvb(U) 

dvb_core(U) nxt200x(U) tda1004x(U) autofs4(U) sunrpc(U) xennet(U) ip6t_REJECT(U) xt_tcpudp(U) ip6table_filter(U) ip6_tables(U) x_tables(U) ipv6(U) xfrm_nalgo(U) crypto_api(U) xfs(U) dm_multipath(U) parport_pc(U) lp(U) parport(U) saa7134(U) video_buf(U) compat_ioctl32(U) ir_kbd_i2c(U) i2c_core(U) ir_common(U) videodev(U) v4l1_compat(U) v4l2_common(U) pcspkr(U) dm_snapshot(U) dm_zero(U) dm_mirror(U) dm_mod(U) xenblk(U) ext3(U) jbd(U) uhci_hcd(U) ohci_hcd(U) ehci_hcd(U)
Pid: 5517, comm: saa7130[0] dvb Tainted: G 2.6.18-prep #6

RIP: e030:[<ffffffff802720a2>]  [<ffffffff802720a2>] dma_map_sg+0x13f/0x1ae
RSP: e02b:ffff88003ceb7e00  EFLAGS: 00010282
RAX: 000000000000002f RBX: ffff8800227c1bd0 RCX: ffffffff804da728
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: 0000000000000002 R08: ffffffff804da728 R09: 0000000000002373
R10: 000000000000002c R11: ffff88003ceb8000 R12: 0000000000000006
R13: ffff88003fded070 R14: ffff88003bfdcde8 R15: 0000000000000003
FS:  00002b67c1d1e750(0000) GS:ffffffff805ac000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000
Process saa7130[0] dvb (pid: 5517, threadinfo ffff88003ceb6000, task 
ffff88003041e820)
Stack:  ffff8800349ee9b0  ffff8800349ee9b0  ffff88003bfdcde8 
ffff88003fded000
  0000000000000080  ffffffff88133937  ffff8800349ee980  0000000000005e00
  ffff88003bfdc000  ffffffff88144d34
Call Trace:
  [<ffffffff88133937>] :video_buf:videobuf_dma_map+0x115/0x159
  [<ffffffff88144d34>] :saa7134:buffer_prepare+0xbb/0x19b
  [<ffffffff80298a84>] keventd_create_kthread+0x0/0xc4
  [<ffffffff88132d43>] :video_buf:videobuf_read_start+0xa8/0x139
  [<ffffffff8836234b>] :video_buf_dvb:videobuf_dvb_thread+0x2a/0x127

As per the first line of the error message, I did try with swiotlb=force
as a kernel option, but that forced the kernel to immediately crash
on booting.

The machine will run for a few hours without crashing and my gut feeling is that the crash actually happens when the tuner is being re-tuned to a different mux, rather then when streaming data once a mux has been tuned.

I know what DMA does, but I don't know much detail about how it does it,
and even less about how linux dvb uses it, any suggestions for how I
should proceed to try and track this down?

Any test suites as part of linuxtv?

_______________________________________________
linux-dvb mailing list
[email protected]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb