On Sun, 2012-07-08 at 15:28 -0400, Andy Walls wrote: > On Sat, 2012-07-07 at 12:44 -0500, Robert Rust wrote: > > After weeks of headaches trying to get my HVR-1600 to work, I finally > > determined with help from this list that the H77 chipset on my > > motherboard was the root of my problems, so I replaced the board. I > > am now trying to set up my MythTV backend in a Xen domU after > > verifying that it can capture outside of Xen and in the Xen dom0 host. > > What is the difference between Xen domain dom0 and domU (for a Xen newb > like me)? > >
Ah, found it: http://wiki.xen.org/wiki/XenOverview#Introduction_to_Xen_Architecture "... Domain 0) is a specialized Virtual Machine that 0 has special privileges like the capability to access the hardware directly, handles all access to the system’s I/O functions ..." "... Xen [domU] guests are totally isolated from the hardware: in other words, they have no privilege to access hardware or I/O functionality. Thus, they are also called unprivileged domain (or DomU)." > > I can tune to channels and I get data when I cat /dev/video0 ... but > > the data doesn't seem to be valid video. > > Does anybody have input on how I can work towards a resolution on > > this? This page looks helpful: http://wiki.xen.org/wiki/XenPCIpassthrough If your linux kernel panics because the cx18 driver asks for more DMA buffer space than the SWIOTLB (Software IOMMU) in Linux can provide, you can cut down on the number and size of buffers for CX23418 data streams using cx18 module options. Also the Linux Software IOMMU requires copies of DMA buffres by the CPU, so performance will stink, unless you have lots of excess horsepower. Please note that the CX23418 acts as a DMA master on the PCI bus. When the cx18 driver tells the CX23418 about where the DMA buffers are, they must be the correct PCI address-space addresses that the CX23418 chip and firmware can actually DMA into. If you have a Linux kernel running in any other Xen (dom0 or domU) guest, you should probably blacklist the cx18 driver in that guest, so that instance of the cx18 driver doesn't also load the CX23418 with DMA addresses to use or otherwise change the CX23418's System Control Block (SCB) area. (In case you are interested, this is the function in the cx18 driver where the driver tells the firmware about the DMA addresses of buffers: http://git.linuxtv.org/media_tree.git/blob/staging/for_v3.6:/drivers/media/video/cx18/cx18-queue.c#l277 and this is the function that initializes the SCB on driver probe: http://git.linuxtv.org/media_tree.git/blob/staging/for_v3.6:/drivers/media/video/cx18/cx18-scb.c#l27 ) > Note the CX23418 is very latency sensitive. If the guest responds too > slowly to CX23418 interrupts, it will miss the CX23418 mailbox payload > data and hence lose video buffer data. The CX23418 won't wait forever > for the OS driver and will move on. (This is a firmware bug IMO, but > likely considered a required feature if you ask Conexant). The above still applies. Low interrupt latency response by the cx18 driver in the domU guest is important for glitch free recordings. Regards, Andy _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
