WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] MMIO ioremap() error with PCI passthrough

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] MMIO ioremap() error with PCI passthrough
From: Andy Burns <lists.xensource.com@xxxxxxxxxxxxxx>
Date: Tue, 01 Jul 2008 19:50:53 +0100
Delivery-date: Tue, 01 Jul 2008 11:51:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C49024D0.1A470%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C49024D0.1A470%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.14) Gecko/20080421 Lightning/0.8 Thunderbird/2.0.0.14 Mnenhy/0.7.5.0
On 01/07/2008 18:15, Keir Fraser wrote:

Good idea. This kind of thing can be an honest mistake which would normally
never cause a problem running natively.

I've asked the linuxtv folk if they are interested in a patch.

Does the card work at all up to this point (first 40s)?

Well, if I modprobe the saa7134.ko and saa7134_dvb.ko
I get the /dev/video0 and /dev/dvb/adapter0 devices created

But if I try to scan for TV channels with

# dvbscan /usr/share/dvb/dvb-t/uk-Waltham  > ~/.tzap/channels.conf

I get "Unable to query frontend status", so the device doesn't seem to be functioning.

Any sign of life after the message prints?

The machine doesn't die when the stray interrupt fires, in fact I can rmmod the module and modprobe it again, the error repeats after another 40 seconds.

This would indicate either that Xen/pciback has got irq routing wrong for
this line (so the wrong interrupts are being delivered to the driver) or
that for some other reason the driver has decided that there was no work to
be done in response to the interrupt. Could the irq line for this device be
a shared line?

I did wonder how (or if) shared interrupts would work.

Given the relatively high number of devices on the motherboard and PCI-X/PCI/PCIe cards I suspect it will have to be shared.

Here is a brief lspci

00:00.0 Host bridge: Intel Corporation 82X38 Express DRAM Controller (rev 01) 00:01.0 PCI bridge: Intel Corporation 82X38 Express Host-Primary PCI Express Bridge (rev 01) 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02) 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02) 00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02) 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02) 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02) 00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 02) 00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 02) 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02) 01:00.0 VGA compatible controller: ATI Technologies Inc RV370 [Sapphire X550 Silent] 01:00.1 Display controller: ATI Technologies Inc RV370 secondary [Sapphire X550 Silent] 02:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6145 SATA II PCI-E controller (rev a1) 03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 12) 04:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 12) 05:00.0 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06) 05:00.1 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06) 07:01.0 SCSI storage controller: Marvell Technology Group Ltd. MV88SX6081 8-port SATA II PCI-X Controller (rev 09) 08:01.0 Multimedia controller: Philips Semiconductors SAA7130 Video Broadcast Decoder (rev 01) 08:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev c0)

Looks like the PCI slot with the tuner shares IRQ17 with the PCI-X slot used by my 8xSATA card.

07:01.0 SCSI storage controller: Marvell Technology Group Ltd. MV88SX6081 8-port SATA II PCI-X Controller (rev 09)
        Subsystem: Marvell Technology Group Ltd. Unknown device 11ab
        Interrupt: pin A routed to IRQ 17

08:01.0 Multimedia controller: Philips Semiconductors SAA7130 Video Broadcast Decoder (rev 01)
        Subsystem: Compro Technology, Inc. Videomate DVB-T200
        Interrupt: pin A routed to IRQ 17

I can try to move the tuner card to the other PCI slot, but I suspect it will just share with something else instead, besides I planned to populate both PCI slots with tuners for passthrough, once I got the first one working.

You could try disabling the spurious irq logic in
kernel/irq/spurious.c, and then see if the device works and also what the
irq rate looks like in /proc/interrupts.

I'll have a go at that.



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