[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] IVTV in domU: Cannot request encoder memory region on card 0


  • To: xen-users@xxxxxxxxxxxxxxxxxxx
  • From: "sven waeyenbergh" <sven.waeyenbergh@xxxxxxxxx>
  • Date: Fri, 4 Jan 2008 11:07:32 +0100
  • Cc: truls@xxxxxxxxxx
  • Delivery-date: Fri, 04 Jan 2008 02:08:05 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=A/U+FbSrwoSqYR8/23GzeOu2qhE/fIJ3VZtJ1xUzgno6OmZh7DRNLT70KpjgfTSqApkgrv8Qfuj+fyHqfbBP5hggHg50i4JEIQ2wCgU43DQiu3ISLEUkdUCDULR7h4kJQDbKP+j/eY5YqCxtn+8CzBGNiVutdWwQqVlTxqgbNIg=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

Hi,

i can confirm i have a similar setup running fine on Debian etch with a PVR500 and a PVR250.
I am using xen 3.0 (debian is a bit behind) and i've seen some posts of people having trouble with this on xen 3.1

in any case i thought i'd give you my notes from almost 2 years of playing with this:
- i never got this to work on 32bit with PAE. I think PAE does something weird on PCI level. Avoid PAE if possible.
- i did get this to run on 32bit, but it was never stable enough for everyday use.
- since i switched to 64bit, almost all troubles disappeared.
- your kernel params look fine, i have something very similar (no special parameters on dom0, domu: extra = "root=/dev/hda1 iommu=soft swiotlb=force") -> i advise you to drop the swiotlb stuff from dom0, it should only be needed on domU.
- the swiotlb stuff reserves some memory for drivers. That means that you will have to make sure to assign enough memory to the domU to boot from. I had to transfer a minimum of about 480MB before the system would even boot. It has been running in 512MB ever since. Note that i run the DB on another (virtual) system.
- make sure that the IVTV fireware and drivers on domU are in sync with the kernel you load. Especially for recent PVR500  cards (with the samsung tuners) you need a very recent version of the ivtv drivers.
- IVTV cards need to load firmware at boot-time. When testing with multiple reboots, the cards can easily get into a screwed-up state. Powerdown completely and leave powered off for about 2 minutes before rebooting to clear this up.
- i'm not sure that the pciback.hide stuff still works as kernel parameter. I use this script as a late-phase boot-script:

SLOT=0000:04:08.0
   # Add a new slot to the PCI Backend's list
   echo -n $SLOT > /sys/bus/pci/drivers/pciback/new_slot
   # Now that the backend is watching for the slot, bind to it
   echo -n $SLOT > /sys/bus/pci/drivers/pciback/bind
SLOT=0000:04:09.0
   # Add a new slot to the PCI Backend's list
   echo -n $SLOT > /sys/bus/pci/drivers/pciback/new_slot
   # Now that the backend is watching for the slot, bind to it
   echo -n $SLOT > /sys/bus/pci/drivers/pciback/bind
SLOT=0000:05:0a.0
   echo -n $SLOT > /sys/bus/pci/drivers/pciback/new_slot
   echo -n $SLOT > /sys/bus/pci/drivers/pciback/bind

- make sure that you first make sure that IVTV is running ok before starting to debug mythtv.

i hope at least some of this is helpful.

Greetings,
SVen


On Jan 4, 2008 4:16 AM, Truls Asheim < truls@xxxxxxxxxx> wrote:

Hi

 

I am trying to get my Happauge PVR-500 working inside a domU. Both host and guest are running Gentoo 2007.0 with kernel 2.6.20-r6-xen and xen verson 3.1.2.

 

My problem is that when i try to load the itvtv kernel module the following appears in dmesg:

 

Linux video capture interface: v2.00
ivtv:  ==================== START INIT IVTV ====================
ivtv:  version 0.10.6 (tagged release) loading
ivtv:  Linux version: 2.6.20-xen-r6 SMP mod_unload

ivtv:  In case of problems please include the debug info between
ivtv:  the START INIT IVTV and END INIT IVTV lines, along with
ivtv:  any module options, when mailing the ivtv-users mailinglist.
ivtv0: Autodetected Hauppauge card (cx23416 based)
PCI: Enabling device 0000:00:00.0 (0000 -> 0002)
ivtv0: Cannot request encoder memory region on card 0.
ivtv0: Error -5 on initialization
ivtv: probe of 0000:00:00.0 failed with error -5
ivtv:  ======================  NEXT CARD  ======================
ivtv1: Autodetected Hauppauge card (cx23416 based)
PCI: Enabling device 0000:00: 01.0 (0000 -> 0002)
ivtv1: Cannot request encoder memory region on card 1.
ivtv1: Error -5 on initialization
ivtv: probe of 0000:00:01.0 failed with error -5
ivtv:  ====================  END INIT IVTV  ====================

 

In the dmesg of the dom0 the following appears:

 

pciback 0000:07:08.0: set power state to 0
PCI: Enabling device 0000:07:08.0 (0000 -> 0002)
ACPI: PCI Interrupt 0000:07:08.0[A] -> GSI 21 (level, low) -> IRQ 21
pciback 0000:07:09.0: set power state to 0
PCI: Enabling device 0000:07:09.0 (0000 -> 0002)
ACPI: PCI Interrupt 0000:07:09.0[A] -> GSI 22 (level, low) -> IRQ 22

 

My current config is as follows:

 

The dom0 kernel is being booted with:

module /kernel-2.6.20-xen0 root=/dev/md1 dom0_mem=-128M swiotlb=128,force pciback.hide=(06:01.0)(07:08.0)(07:09.0)

 

I added the dom0_mem and swiotlb parameters in an attempt to make the ivtv driver work based on information i found on various places but they doesn't seem to make any difference.

The first pci device being hidden is a network card dedicated for my firewall running in another domU. The two last devices represents the tuners on the pvr-500 card.

 

The domU kernel is being booted with:  extra = "swiotlb=force iommu=soft";  and the pci devices are being imported with pci = [ '07: 08.0', '07:09.0']; in the domU config file.

Once again the swiotlb and iommu parameters were added as an attempt to make the ivtv driver work. Neither of them have made any difference.

 

I have seen other people reporting that they are able to get the ivtv driver working inside an domU so i'm pretty sure its possible i just have no idea where to start debugging the problem.

 

Any help will be appreciated!

 

Regards

Truls Asheim 

 

 


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

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.