[Fwd: [Fwd: Re: [Xen-users] Re: [Xen-devel] bt878 based dvr card vs. pci pass-thru]]

[Sipos Ferenc <frank@xxxxxxx>]

Hi Lists,

sorry for reposting this, but since no response has arrived so far and
my time on this project is passing by I need to make a conclusion. Do I
better use my DVR cards in dom0 or moving it to a separate physical
machine rather than using them in a domU?

Could someone shed light on why it is trickier to pass-thru one of these
cards than any other pci devices? Do they try to read-write certain
parts of the memory (maybe because of some sort of direct memory access
or smthg?) which are normally hidden from the guest by the dom0?

Thanks for your time,
Frank

-------- Forwarded Message --------
> From: Sipos Ferenc <frank@xxxxxxx>
> To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
> Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser
> <keir@xxxxxxxxxxxxx>
> Subject: [Fwd: Re: [Xen-users] Re: [Xen-devel] bt878 based dvr card
> vs. pci pass-thru]
> Date: Mon, 18 Dec 2006 16:48:22 +0100
> 
> Hi,
> 
> some more info which I collected during physically accessing the machine
> while rebooting. I was suprised that while it was not able to do
> anything it was not a 'static' kernel panic, but the following text was
> scrolling continously thru the screen:
> 
> """
> ata3: port reset, p_is 1 is e pis 1 cmd c017 tf 50 ss 113 se 0
> ata3: status=0x50 { DriveReady SeekComplete }
> sda: Current: sense key: No sense
>       Additional sense: No additional sense information
> """
> 
> This and the same with 'ata2' and 'sdb'.
> Please let me know if it has anything to do with the below metioned
> setup.
> 
> Thanks.
> Frank
> 
> -------- Forwarded Message --------
> > From: Sipos Ferenc <frank@xxxxxxx>
> > To: Keir Fraser <keir@xxxxxxxxxxxxx>
> > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-users@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [Xen-users] Re: [Xen-devel] bt878 based dvr card vs. pci
> > pass-thru
> > Date: Mon, 18 Dec 2006 10:56:06 +0100
> > 
> > Hi All.
> > 
> > > This file should contain your device id, not slot address. Find out the
> > > numeric device id from 'lspci -n'.
> > It was clearly stated in the docs that I should have used the output of
> > 'lspci -n' but somehow it supressed my attention. Sorry for wasting your
> > time on that.
> > 
> > On an other note, I've did what you and the manual suggested and here is
> > the result:
> > 
> > """
> > Dec 18 10:47:43 hive kernel: pciback 0000:07:0e.0: enabling permissive
> > mode configuration space accesses!
> > Dec 18 10:47:43 hive kernel: pciback 0000:07:0e.0: permissive mode is
> > potentially unsafe!
> > Dec 18 10:47:43 hive kernel: pciback 0000:07:0e.1: enabling permissive
> > mode configuration space accesses!
> > Dec 18 10:47:43 hive kernel: pciback 0000:07:0e.1: permissive mode is
> > potentially unsafe!
> > Dec 18 10:47:43 hive kernel: pciback 0000:07:0f.0: enabling permissive
> > mode configuration space accesses!
> > Dec 18 10:47:43 hive kernel: pciback 0000:07:0f.0: permissive mode is
> > potentially unsafe!
> > Dec 18 10:47:43 hive kernel: pciback 0000:07:0f.1: enabling permissive
> > mode configuration space accesses!
> > Dec 18 10:47:43 hive kernel: pciback 0000:07:0f.1: permissive mode is
> > potentially unsafe!
> > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0c.0: assign to
> > virtual slot 0
> > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0c.1: assign to
> > virtual slot 0 func 1
> > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0d.0: assign to
> > virtual slot 1
> > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0d.1: assign to
> > virtual slot 1 func 1
> > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0e.0: assign to
> > virtual slot 2
> > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0e.1: assign to
> > virtual slot 2 func 1
> > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0f.0: assign to
> > virtual slot 3
> > Dec 18 10:47:43 hive kernel: pciback: vpci: 0000:07:0f.1: assign to
> > virtual slot 3 func 1
> > Dec 18 10:47:43 hive kernel: device vif2.0 entered promiscuous mode
> > Dec 18 10:47:43 hive kernel: ADDRCONF(NETDEV_UP): vif2.0: link is not
> > ready
> > Dec 18 10:47:47 hive kernel: ADDRCONF(NETDEV_CHANGE): vif2.0: link
> > becomes ready
> > Dec 18 10:47:47 hive kernel: xenbr0: port 3(vif2.0) entering learning
> > state
> > Dec 18 10:47:47 hive kernel: xenbr0: topology change detected,
> > propagating
> > Dec 18 10:47:47 hive kernel: xenbr0: port 3(vif2.0) entering forwarding
> > state
> > Dec 18 10:47:55 hive kernel: PCI: Enabling device 0000:07:0c.0 (0000 ->
> > 0002)
> > Dec 18 10:47:55 hive kernel: ACPI: PCI Interrupt 0000:07:0c.0[A] -> GSI
> > 16 (level, low) -> IRQ 16
> > Dec 18 10:47:55 hive kernel: PCI: Enabling device 0000:07:0d.0 (0000 ->
> > 0002)
> > Dec 18 10:47:55 hive kernel: ACPI: PCI Interrupt 0000:07:0d.0[A] -> GSI
> > 17 (level, low) -> IRQ 20
> > Dec 18 10:47:57 hive kernel:  [__report_bad_irq+36/128] __report_bad_irq
> > +0x24/0x80
> > Dec 18 10:47:57 hive kernel:  [note_interrupt+162/256] note_interrupt
> > +0xa2/0x100
> > Dec 18 10:47:57 hive kernel:  [__do_IRQ+233/256] __do_IRQ+0xe9/0x100
> > Dec 18 10:47:57 hive kernel:  [do_IRQ+55/112] do_IRQ+0x37/0x70
> > Dec 18 10:47:57 hive kernel:  [__do_IRQ+179/256] __do_IRQ+0xb3/0x100
> > Dec 18 10:47:57 hive kernel:  [evtchn_do_upcall+146/256]
> > evtchn_do_upcall+0x92/0x100
> > Dec 18 10:47:57 hive kernel:  [hypervisor_callback+61/72]
> > hypervisor_callback+0x3d/0x48
> > Dec 18 10:47:57 hive kernel:  [<cd8b5107>] uhci_irq+0x27/0x190
> > [uhci_hcd]
> > Dec 18 10:47:57 hive kernel:  [<cd8e03a4>] usb_hcd_irq+0x24/0x60
> > [usbcore]
> > Dec 18 10:47:57 hive kernel:  [handle_IRQ_event+89/160] handle_IRQ_event
> > +0x59/0xa0
> > Dec 18 10:47:57 hive kernel:  [__do_IRQ+138/256] __do_IRQ+0x8a/0x100
> > Dec 18 10:47:57 hive kernel:  [do_IRQ+55/112] do_IRQ+0x37/0x70
> > Dec 18 10:47:57 hive kernel:  [evtchn_do_upcall+146/256]
> > evtchn_do_upcall+0x92/0x100
> > Dec 18 10:47:57 hive kernel:  [hypervisor_callback+61/72]
> > hypervisor_callback+0x3d/0x48
> > Dec 18 10:47:57 hive kernel:  [safe_halt+32/80] safe_halt+0x20/0x50
> > Dec 18 10:47:57 hive kernel:  [start_hz_timer+18/32] start_hz_timer
> > +0x12/0x20
> > Dec 18 10:47:57 hive kernel:  [xen_idle+44/96] xen_idle+0x2c/0x60
> > Dec 18 10:47:57 hive kernel:  [cpu_idle+139/224] cpu_idle+0x8b/0xe0
> > Dec 18 10:47:57 hive kernel:  [start_kernel+427/496] start_kernel
> > +0x1ab/0x1f0
> > Dec 18 10:47:57 hive kernel:  [unknown_bootoption+0/480]
> > unknown_bootoption+0x0/0x1e0
> > """
> > 
> > I needed to force my machine to reboot physically. Any suggestions are
> > very welcome.
> > 
> > (Ubuntu 6.10 - dom0 & domU - and Xen-3.0.3 binary install with Kodicom
> > 4400R-like bt878 based DVR card)
> > Should you need more info on my setup, I'm happy to provide you with
> > that.
> > 
> > Frank
> > 
> > 
> > 
> > _______________________________________________
> > 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