I''m trying to use PCI passthrough of a DVB-T tuner from a fedora8 dom0,
to a centOS5.2 domU for a mythtv-backend.
On the dom0 I have the following packages installed
kernel-xen.x86_64 2.6.21.7-3.fc8
libvirt.x86_64 0.4.3-1.fc8
libvirt-python.x86_64 0.4.3-1.fc8
python-virtinst.noarch 0.300.2-4.fc8
virt-manager.x86_64 0.5.3-2.fc8
virt-viewer.x86_64 0.0.2-2.fc8
xen.x86_64 3.1.2-2.fc8
xen-libs.x86_64 3.1.2-2.fc8
On the domU I have the following kernel installed
kernel-xen.x86_64 2.6.18.92.1.6.el5.centos.plus
Additionally I had to manually compile the saa7134_dvb.ko module for the
digital section of the card as the centosplus kernel only had the
saa7134.ko module for the analogue section of the card.
I tried adding a pciback.hide entry to grub.conf for the dom0, but this
wasn''t recognised, presumably because pciback is compiled as a module
on
fedora8 dom0 kernel?
I realise I can add entries to modprobe.conf to ensure no dom0 drivers
bind to my device, but for now I''m using the following script to get
dom0 to relinquish the card and make it available for the domU.
rmmod saa7134
modprobe pciback
SLOT=0000:08:01.0
echo -n $SLOT > /sys/bus/pci/drivers/pciback/new_slot
echo -n $SLOT > /sys/bus/pci/drivers/pciback/bind
I then create my domU with this config file
memory = 1024
name = "mythbe"
vif = [ ''mac=00:16:3E:76:E8:92, bridge=eth0'' ]
disk = [ ''phy:/dev/vgr1/lvmythroot,xvda,w'',
''phy:/dev/vgr5/lvmythdata,xvdb,w'' ]
pci = [''08:01.0'']
bootloader = "/usr/bin/pygrub"
vcpus = 1
on_reboot = ''restart''
on_crash = ''restart''
I see a few PCI related messages on the console and/or dmesg
PCI: Fatal: No PCI config space access function found
PCI: setting up Xen PCI frontend stub
PCI: System does not support PCI
PCI: System does not support PCI
pcifront pci-0: Installing PCI frontend
pcifront pci-0: Creating PCI Frontend Bus 0000:00
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
ohci_hcd: 2005 April 22 USB 1.1 ''Open'' Host Controller (OHCI)
Driver (PCI)
PCI: Enabling device 0000:00:00.0 (0000 -> 0002)
The DVB-T card is visble in the domU
# lspci -v
00:00.0 Multimedia controller: Philips Semiconductors SAA7130 Video
Broadcast Decoder (rev 01)
Subsystem: Compro Technology, Inc. Videomate DVB-T200
Flags: bus master, medium devsel, latency 64, IRQ 17
Memory at febffc00 (32-bit, non-prefetchable) [size=1K]
Capabilities: [40] Power Management version 1
I assume it''s normal that the bus/device/function numbers have been
changed between dom0 and domU?
Also the driver modules are being loaded
# lsmod | grep saa
saa7134_dvb 48004 0
dvb_pll 48965 1 saa7134_dvb
mt352 40133 1 saa7134_dvb
video_buf_dvb 40133 1 saa7134_dvb
nxt200x 46661 1 saa7134_dvb
tda1004x 48581 1 saa7134_dvb
saa7134 159017 1 saa7134_dvb
video_buf 59717 3 saa7134_dvb,video_buf_dvb,saa7134
compat_ioctl32 41793 1 saa7134
ir_kbd_i2c 42961 1 saa7134
i2c_core 56129 7
saa7134_dvb,dvb_pll,mt352,nxt200x,tda1004x,saa7134,ir_kbd_i2c
ir_common 63173 2 saa7134,ir_kbd_i2c
videodev 58049 1 saa7134
v4l1_compat 44613 2 saa7134,videodev
v4l2_common 57153 3 saa7134,compat_ioctl32,videodev
However I see an error in dmesg too
# dmesg|grep -i saa
saa7130/34: v4l2 driver version 0.2.14 loaded
saa7130[0]: found at 0000:00:00.0, rev: 1, irq: 17, latency: 64, mmio:
0xfebffc00
saa7130[0]: subsystem: 185b:c901, board: Compro Videomate DVB-T200
[card=71,autodetected]
saa7130[0]: can''t ioremap() MMIO memory
saa7134: probe of 0000:00:00.0 failed with error -5
Am I right in thinking pciback.permissive is now removed? Certainly
modinfo is unaware of it.
Any suggestions for how to stop the ioremap() call from failing and
preventing the driver from loading properly?
Thanks.
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
On 29/06/2008 09:49, Andy Burns wrote:> # dmesg|grep -i saa > > saa7130/34: v4l2 driver version 0.2.14 loaded > saa7130[0]: found at 0000:00:00.0, rev: 1, irq: 17, latency: 64, mmio: > 0xfebffc00 > saa7130[0]: subsystem: 185b:c901, board: Compro Videomate DVB-T200 > [card=71,autodetected] > saa7130[0]: can''t ioremap() MMIO memory > saa7134: probe of 0000:00:00.0 failed with error -5Sorry, I meant to include another message I see in the domU each time the domU boots. # xm dmesg (XEN) mm.c:625:d6 Non-privileged (6) attempt to map I/O space 000fec00 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sun, Jun 29, 2008 at 7:48 AM, Andy Burns <lists.xensource.com@ adslpipe.co.uk> wrote:> On 29/06/2008 09:49, Andy Burns wrote: > > # dmesg|grep -i saa >> >> saa7130/34: v4l2 driver version 0.2.14 loaded >> saa7130[0]: found at 0000:00:00.0, rev: 1, irq: 17, latency: 64, mmio: >> 0xfebffc00 >> saa7130[0]: subsystem: 185b:c901, board: Compro Videomate DVB-T200 >> [card=71,autodetected] >> saa7130[0]: can''t ioremap() MMIO memory >> saa7134: probe of 0000:00:00.0 failed with error -5 >> > > Sorry, I meant to include another message I see in the domU each time the > domU boots. > > # xm dmesg > > (XEN) mm.c:625:d6 Non-privileged (6) attempt to map I/O space 000fec00 > > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >I have mythbackend running in an Ubuntu-Hardy domU with a Centos 5.1 dom0. Here are the settings that work for me: In dom0 /boot/grub/: title CentOS (2.6.18-xen_3.2.0) root (hd0,5) kernel /boot/xen.gz-3.2 swiotlb=256 noirqdebug module /boot/vmlinuz-2.6-xen ro root=LABEL=/ max_loop=32 module /boot/initrd-2.6-xen.img In /etc/xen/Ubuntu-Hardy-Mythtv.cfg: bootloader = ''/usr/bin/pygrub'' memory = 640 name = "Ubuntu-Mythtv" disk [''file:/mnt/VM/Ubuntu-Hardy-Mythtv.img,hda1,w'',''file:/mnt/VM/Ubuntu-Hardy-Mythtv-swap.img,hda2,w''] vif = [ '''' ] pci = [ "0000:03:02.0","0000:04:08.0","0000:04:09.0","0000:02:00.0","0000:02:00.1" ] extra = "swiotlb=force all-generic-ide=1 clock=jiffies" sdl = 1 In the domU /boot/grub/menu.1st: title Ubuntu 8.04, kernel 2.6.24-16-xen root (hd0,0) kernel /boot/vmlinuz-2.6.24-16-xen root=/dev/hda1 ro console=xvc0 swiotlb=128,force initrd /boot/initrd.img-2.6.24-16-xen I have a jmicron pci express SATA-PATA combo card pcibacked, hence the all-generic-ide line above. For some reason jiffies in extra doesn''t stick. Also, I followed a recommendation from the mythv list to chrt the ivtv pids. So I have a boot script in the domU to run: #!/bin/bash /bin/echo jiffies > /sys/devices/system/clocksource/clocksource0/current_clocksource /usr/bin/chrt -rp 99 `pgrep ivtv0` /usr/bin/chrt -rp 99 `pgrep ivtv1` /usr/bin/chrt -rp 99 `pgrep ivtv2` #It probably wont hurt to increase the domU''s scheduling priority, run this in dom0: xm sched-credit -d Ubuntu-Mythtv -w 512 I would suggest having the Mythtv backend not do any transcoding or commflagging. Instead, create slave mythtv backends without tuners and have them do the transcode and commflagging. This effectively compartmentalizes the commflagger and transcoder so that the main mythtv backend will not drop frames when writing to the disk. My only problem with the system is I get dma timeout errors in dmesg. These were present even in a nonxen setup, so I think it is related to my hardware and ivtv. Hope that helps. I am still trying to find ways to optimize the mythbackend domU so If you have any ideas, please let me know. Chris _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 02/07/2008 23:27, Christopher Isip wrote:> I have mythbackend running in an Ubuntu-Hardy domU with a Centos 5.1 > dom0. Here are the settings that work for me:I found a bug in the saa7123 tuner driver where it was mapping too large an mmio area, so patched that, then found it was sharing an interrupt with devices from dom0, so added pollirq, now I have an infrequent DMA panic.> kernel /boot/xen.gz-3.2 swiotlb=256 noirqdebugI had been searching around for swiotlb info, I''ll try your settings tomorrow ... is noirqdebug preferred instead of pollirq? I was getting the "nobody cared, IRQ disable dmesg"> extra = "swiotlb=forcehmm, my domU kernel crashed immediately when I trye swiotlb=force> > #It probably wont hurt to increase the domU''s scheduling priority, run > this in dom0: > > xm sched-credit -d Ubuntu-Mythtv -w 512So far I''ve not noticed performance being a problem, recording 3 concurrent streams from a single tuner takes under 10% of one core of a Q9450 cpu.> I would suggest having the Mythtv backend not do any transcoding or > commflagging. Instead, create slave mythtv backends without tuners and > have them do the transcode and commflagging. This effectively > compartmentalizes the commflagger and transcoder so that the main mythtv > backend will not drop frames when writing to the disk.Good suggestion, though again I''ve been amazed how much faster this backend is at transcoding than my "old" P4 combined frontend/backend.> My only problem with the system is I get dma timeout errors in dmesg. > These were present even in a nonxen setup, so I think it is related to > my hardware and ivtv.hmm, mine are panics, not just dmesg, but I never saw them when the tuners were in the non-xen machines.> Hope that helps. I am still trying to find ways to optimize the > mythbackend domU so If you have any ideas, please let me know.Thanks, will do. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 02/07/2008 23:27, Christopher Isip wrote:> I have mythbackend running in an Ubuntu-Hardy domU with a Centos 5.1 > dom0. Here are the settings that work for me:After much pulling of hair trying various combinations of pci clots, swiotlb amd pollirq settings, some of which stopped the crashing, but made the dom0 NIC stop working, others stopped the crash but left the domU tuner deaf and/or dumb. I decided I''d try centos 5.2 dom0 with xen 3.2.0 and I have now got the tuner happily working in the domU, will try two tuners after a few days. I now don''t need any swiotlb settings at all, I have switched from pollirq to noirqdebug on the dom0 as per your settings I had to a self-build quite a bit ... xen (from the xs SRPMS as I''m x86_64) dom0 kernel (to enable the PCIID for my NICs for the sky2 driver) domU kernel (for the ioremap bug in saa7134 module) but I''m happy :-)> #It probably wont hurt to increase the domU''s scheduling priority, run > this in dom0: > xm sched-credit -d Ubuntu-Mythtv -w 512So far I haven''t nee that, I''ll see if I do as other domUs get busier> I would suggest having the Mythtv backend not do any transcoding or > commflagging. Instead, create slave mythtv backends without tuners and > have them do the transcode and commflagging.I still might do that, also wondering about moving the mysqld to another domU, currently the database is at least on separate xvdb from my recordings disk, so maybe not too bad.> Hope that helps. I am still trying to find ways to optimize the > mythbackend domU so If you have any ideas, please let me know.I came *very* close to giving up and putting mythbackend into dom0 until the paravirt_ops versions of dom0 xen are mainstream - glad I persevered, if you''re still having DMA issues I''d say centos5.2+xen3.2 is worth a look. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> I still might do that, also wondering about moving the mysqld to another > domU, currently the database is at least on separate xvdb from my > recordings disk, so maybe not too bad. >I have my mysql server on a separate domU and a slave mysql server in another domU as well for replication. I am hoping eventually to setup a script to backup the mysql database in the slave mysql server. That way, database backups wont interrupt mythtv.> > I came *very* close to giving up and putting mythbackend into dom0 until > the paravirt_ops versions of dom0 xen are mainstream - glad I persevered, if > you''re still having DMA issues I''d say centos5.2+xen3.2 is worth a look. > >I might give that a try sometime later. My systems seem to have stabilized a bit and I''d hate to break anything now. Thanks Chris _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On 02/07/2008 23:27, Christopher Isip wrote:> I have mythbackend running in an Ubuntu-Hardy domU with a Centos 5.1 > dom0. Here are the settings that work for me:I think I''m getting somewhere close to finding what causes my mythbackend domU to crash (naturally it proves very difficult to make it crash on demand). My dom0 and domU are 64bit centOS, the crash seems to happen when vmalloc returns an address higher than the 4GB mark which V4L then attempts to use for DMA scatter-gather operations. Can I ask whether your domU is 32 or 64 bit? I''d just used 64bit for the domU because I already had the DVD downloaded for the dom0 which has 8GB (I think it should be better to use 64 bit for the dom0 rather than 32 bit with PAE?) But I can''t really see any advantage for the domU to use 64 bit, so will try moving to 32bit centos 5.2 instead ... _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sun, Jul 13, 2008 at 5:38 PM, Andy Burns <lists.xensource.com@ adslpipe.co.uk> wrote:> On 02/07/2008 23:27, Christopher Isip wrote: > > I have mythbackend running in an Ubuntu-Hardy domU with a Centos 5.1 dom0. >> Here are the settings that work for me: >> > > I think I''m getting somewhere close to finding what causes my mythbackend > domU to crash (naturally it proves very difficult to make it crash on > demand). > > My dom0 and domU are 64bit centOS, the crash seems to happen when vmalloc > returns an address higher than the 4GB mark which > V4L then attempts to use for DMA scatter-gather operations. > > Can I ask whether your domU is 32 or 64 bit? > > I''d just used 64bit for the domU because I already had the DVD downloaded > for the dom0 which has 8GB (I think it should be better to use 64 bit for > the dom0 rather than 32 bit with PAE?) > > But I can''t really see any advantage for the domU to use 64 bit, so will > try moving to 32bit centos 5.2 instead ... > > > My domU is 32 bit.Chris _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users