xen and pci

xen and pci

[Adam Sulmicki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 644 bytes --]


hello,
	I'm running XEN 2.0 on IBM ThinkPad T23.

Now the weird thing is that I get two different outputs from /sbin/lspci
depending on whether I run 2.6.8.1-xen0 or 2.6.8.1-bproc.

In particular the output from  2.6.8.1-xen0 seems to be missing those 4
lines

	0000:00:01.0 PCI bridge: Intel Corp. 82830 830 Chipset AGP Bridge (rev 02)
	0000:00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 41)
	0000:02:00.0 CardBus bridge: Texas Instruments PCI1420
	0000:02:00.1 CardBus bridge: Texas Instruments PCI1420

ideas?

I have attached
	dmesg.2.6.8.1-bproc.gz,
	dmesg.2.6.8.1-xen0.gz,
	lspci.2.6.8.1-bproc,
	lspci.2.6.8.1-xen0

Adam


[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 5715 bytes --]

[-- Attachment #3: Type: APPLICATION/octet-stream, Size: 3774 bytes --]

[-- Attachment #4: Type: TEXT/PLAIN, Size: 1152 bytes --]

0000:00:00.0 Host bridge: Intel Corp. 82830 830 Chipset Host Bridge (rev 02)
0000:00:01.0 PCI bridge: Intel Corp. 82830 830 Chipset AGP Bridge (rev 02)
0000:00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 01)
0000:00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 01)
0000:00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 01)
0000:00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 41)
0000:00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 01)
0000:00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 01)
0000:00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus Controller (rev 01)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio Controller (rev 01)
0000:01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR (rev 05)
0000:02:00.0 CardBus bridge: Texas Instruments PCI1420
0000:02:00.1 CardBus bridge: Texas Instruments PCI1420
0000:02:02.0 Communication controller: Lucent Microelectronics WinModem 56k (rev 01)
0000:02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller (rev 41)


[-- Attachment #5: Type: TEXT/PLAIN, Size: 893 bytes --]

0000:00:00.0 Host bridge: Intel Corp. 82830 830 Chipset Host Bridge (rev 02)
0000:00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 01)
0000:00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 01)
0000:00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 01)
0000:00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 01)
0000:00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 01)
0000:00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus Controller (rev 01)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio Controller (rev 01)
0000:01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR (rev 05)
0000:02:02.0 Communication controller: Lucent Microelectronics WinModem 56k (rev 01)
0000:02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller (rev 41)

Re: xen and pci

[Niraj Tolia]

Adam,

I believe that Xen hides bridge devices from dom0. However, it should
not really affect you.

Niraj


-- 
http://www.cs.cmu.edu/~ntolia

On Fri, 29 Oct 2004 18:46:11 -0400 (EDT), Adam Sulmicki
<adam@cfar.umd.edu> wrote:
> 
> hello,
>         I'm running XEN 2.0 on IBM ThinkPad T23.
> 
> Now the weird thing is that I get two different outputs from /sbin/lspci
> depending on whether I run 2.6.8.1-xen0 or 2.6.8.1-bproc.
> 
> In particular the output from  2.6.8.1-xen0 seems to be missing those 4
> lines
> 
>         0000:00:01.0 PCI bridge: Intel Corp. 82830 830 Chipset AGP Bridge (rev 02)
>         0000:00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 41)
>         0000:02:00.0 CardBus bridge: Texas Instruments PCI1420
>         0000:02:00.1 CardBus bridge: Texas Instruments PCI1420
> 
> ideas?
> 
> I have attached
>         dmesg.2.6.8.1-bproc.gz,
>         dmesg.2.6.8.1-xen0.gz,
>         lspci.2.6.8.1-bproc,
>         lspci.2.6.8.1-xen0
> 
> Adam
> 
> 
>


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: xen and pci

[Adam Sulmicki]

On Fri, 29 Oct 2004, Niraj Tolia wrote:

> I believe that Xen hides bridge devices from dom0. However, it should
> not really affect you.

well the thing is that I'm trying to run PMCIA ethernet card, and with
those two lines missing

	0000:02:00.0 CardBus bridge: Texas Instruments PCI1420
	0000:02:00.1 CardBus bridge: Texas Instruments PCI1420

it seems like the yenta driver in xen0 can't find the bridge.




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: xen and pci

[Keir Fraser]

> On Fri, 29 Oct 2004, Niraj Tolia wrote:
> 
> > I believe that Xen hides bridge devices from dom0. However, it should
> > not really affect you.
> 
> well the thing is that I'm trying to run PMCIA ethernet card, and with
> those two lines missing
> 
> 	0000:02:00.0 CardBus bridge: Texas Instruments PCI1420
> 	0000:02:00.1 CardBus bridge: Texas Instruments PCI1420
> 
> it seems like the yenta driver in xen0 can't find the bridge.

Long term, Xen's PCI code needs some work -- currently it is very
similar to the Linux code and so Xen probes behind all bridges and
reports the results to dom0. It therefore hides the bridges themselves
as otherwise Linux would see some devices twice and get confused.
The solution I think is for Xen not to do any start-of-day probing and
leave that entirely up to Linux. Xen should just tell dom0 where the
root buses are, and let dom0 go from there. Then just need a little
code in Xen to set up IRQ routing when a PCI device is enabled --
there are suitable hooks for thsi already.

*However* I think that pcmcia/cardbus bridges are safe to tell dom0
about (Xen cannot probe behind them) and they have a special subtype
that we could detect. So we can rejig the test that hides the bridges
to be a little bit smarter. 

Please try the following patch, which you can apply by pasting into a
file dev.patch and then:
 'cd xen/common ; chmod 0644 physdev.c ; patch -p1 <path/to/dev.patch'

 -- Keir

--- common/physdev.c    2004-10-22 11:51:50.918741798 +0100
+++ common-new/physdev.c        2004-10-30 08:40:33.513342843 +0100
@@ -747,7 +747,8 @@
          *
          * In Linux2.6 we set pcibios_scan_all_fns().
          */
-        if ( dev->hdr_type != PCI_HEADER_TYPE_NORMAL )
+        if ( (dev->hdr_type != PCI_HEADER_TYPE_NORMAL) &&
+             (dev->hdr_type != PCI_HEADER_TYPE_CARDBUS) )
             continue;
         pdev = xmalloc(sizeof(phys_dev_t));
         pdev->dev = dev;


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: xen and pci

[Adam Sulmicki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 837 bytes --]

On Sat, 30 Oct 2004, Keir Fraser wrote:

> -        if ( dev->hdr_type != PCI_HEADER_TYPE_NORMAL )
> +        if ( (dev->hdr_type != PCI_HEADER_TYPE_NORMAL) &&
> +             (dev->hdr_type != PCI_HEADER_TYPE_CARDBUS) )

Yup! This definitely helped. Now the Yenta Driver finds the bridge.

However, it still has trouble initalizing the card xircom_cb.

Not quite sure what it is wrong, just no errors at all. The only
signifcant difference I can see in 'dmesg' is that :

-cs: IO port probe 0x0c00-0x0cff: clean.
+cs: IO port probe 0x0c00-0x0cff: excluding 0xcf8-0xcff
-cs: IO port probe 0x03e0-0x04ff: excluding 0x4d0-0x4d7
+cs: IO port probe 0x03e0-0x04ff: excluding 0x3f8-0x3ff 0x4d0-0x4d7
 cs: IO port probe 0x0100-0x03af: clean.
 cs: IO port probe 0x0a00-0x0aff: clean.

attached:
	xircom-2.6.8.1-bproc
	xircom-2.6.8.1-xen0

Adam


[-- Attachment #2: Type: TEXT/PLAIN, Size: 2208 bytes --]

redbull:/home/sulmicki # /sbin/cardctl 
usage: /sbin/cardctl command [socket #]
    or /sbin/cardctl [-c configpath] [-f scheme] [-s stab] scheme [name]
    commands: status config ident info suspend resume reset eject insert
redbull:/home/sulmicki # /sbin/cardctl status
Socket 0:
  no card
Socket 1:
  3.3V CardBus card
  function 0: [ready]
redbull:/home/sulmicki # /sbin/cardctl config
Socket 0:
  not configured
Socket 1:
  Vcc 3.3V  Vpp1 3.3V  Vpp2 3.3V
  interface type is "cardbus"
  irq 9 [exclusive] [level]
  function 0:
redbull:/home/sulmicki # /sbin/cardctl ident
Socket 0:
  no product info available
Socket 1:
  no product info available
redbull:/home/sulmicki # /sbin/cardctl info
PRODID_1=""
PRODID_2=""
PRODID_3=""
PRODID_4=""
MANFID=0000,0000
FUNCID=255
PRODID_1=""
PRODID_2=""
PRODID_3=""
PRODID_4=""
MANFID=0000,0000
FUNCID=255
redbull:/home/sulmicki # 

Linux Kernel Card Services
  options:  [pci] [cardbus] [pm]

Yenta: CardBus bridge found at 0000:02:00.0 [1014:023b]
Yenta: Using INTVAL to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:02:00.0, mfunc 0x01d21022, devctl 0x64
Yenta: ISA IRQ mask 0x00d8, PCI irq 5
Socket status: 30000006

Yenta: CardBus bridge found at 0000:02:00.1 [1014:023b]
Yenta: Using INTVAL to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:02:00.1, mfunc 0x01d21022, devctl 0x64
Yenta: ISA IRQ mask 0x00d8, PCI irq 9
Socket status: 30000020

cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0820-0x08ff: clean.
cs: IO port probe 0x0800-0x080f: clean.
cs: IO port probe 0x03e0-0x04ff: excluding 0x4d0-0x4d7
cs: IO port probe 0x0100-0x03af: clean.
cs: IO port probe 0x0a00-0x0aff: clean.

eth1: Xircom cardbus revision 3 at irq 9 
xircom cardbus adaptor found, registering as eth1, using irq 9 
xircom_cb: Link status has changed 
xircom_cb: Link is 100 mbit 

redbull:/home/sulmicki # /sbin/lsmod
Module                  Size  Used by
xircom_cb              11008  0 
ds                     17924  4 
yenta_socket           19456  1 
pcmcia_core            63940  2 ds,yenta_socket



[-- Attachment #3: Type: TEXT/PLAIN, Size: 2079 bytes --]

redbull:/home/sulmicki # /sbin/cardctl
usage: /sbin/cardctl command [socket #]
    or /sbin/cardctl [-c configpath] [-f scheme] [-s stab] scheme [name]
    commands: status config ident info suspend resume reset eject insert
redbull:/home/sulmicki # /sbin/cardctl status
Socket 0:
  no card
Socket 1:
  3.3V CardBus card
  function 0: [ready]
redbull:/home/sulmicki # /sbin/cardctl config
Socket 0:
  not configured
Socket 1:
  Vcc 3.3V  Vpp1 3.3V  Vpp2 3.3V
  interface type is "cardbus"
  irq 9 [exclusive] [level]
  function 0:
redbull:/home/sulmicki # /sbin/cardctl ident
Socket 0:
  no product info available
Socket 1:
  no product info available
redbull:/home/sulmicki # /sbin/cardctl info
PRODID_1=""
PRODID_2=""
PRODID_3=""
PRODID_4=""
MANFID=0000,0000
FUNCID=255
PRODID_1=""
PRODID_2=""
PRODID_3=""
PRODID_4=""
MANFID=0000,0000
FUNCID=255
redbull:/home/sulmicki # 

Linux Kernel Card Services
  options:  [pci] [cardbus]

Yenta: CardBus bridge found at 0000:02:00.0 [1014:023b]
Yenta: Using INTVAL to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:02:00.0, mfunc 0x01d21022, devctl 0x64
Yenta: ISA IRQ mask 0x00d8, PCI irq 5
Socket status: 30000006

Yenta: CardBus bridge found at 0000:02:00.1 [1014:023b]
Yenta: Using INTVAL to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:02:00.1, mfunc 0x01d21022, devctl 0x64
Yenta: ISA IRQ mask 0x00d8, PCI irq 9
Socket status: 30000020

cs: IO port probe 0x0c00-0x0cff: excluding 0xcf8-0xcff
cs: IO port probe 0x0820-0x08ff: clean.
cs: IO port probe 0x0800-0x080f: clean.
cs: IO port probe 0x03e0-0x04ff: excluding 0x3f8-0x3ff 0x4d0-0x4d7
cs: IO port probe 0x0100-0x03af: clean.
cs: IO port probe 0x0a00-0x0aff: clean.

[no xircom messages at all]

redbull:/home/sulmicki # /sbin/lsmod
Module                  Size  Used by
xircom_cb              10240  0 
ds                     14212  4 
yenta_socket           18304  1 
pcmcia_core            59204  2 ds,yenta_socket

Re: xen and pci

[Adam Sulmicki]

On Sat, 30 Oct 2004, Keir Fraser wrote:

> *However* I think that pcmcia/cardbus bridges are safe to tell dom0 
> about (Xen cannot probe behind them) and they have a special subtype 
> that we could detect. So we can rejig the test that hides the bridges to 
> be a little bit smarter.

> --- common/physdev.c    2004-10-22 11:51:50.918741798 +0100
> +++ common-new/physdev.c        2004-10-30 08:40:33.513342843 +0100
> @@ -747,7 +747,8 @@
>          *
>          * In Linux2.6 we set pcibios_scan_all_fns().
>          */
> -        if ( dev->hdr_type != PCI_HEADER_TYPE_NORMAL )
> +        if ( (dev->hdr_type != PCI_HEADER_TYPE_NORMAL) &&
> +             (dev->hdr_type != PCI_HEADER_TYPE_CARDBUS) )
>             continue;
>         pdev = xmalloc(sizeof(phys_dev_t));
>         pdev->dev = dev;

The lack of pcmcia network was annoying me so I poked more around.

The above fix helps in that linux can find the cardbus bridge.

HOWEVER, once it finds it would like to configure devices behind this 
bridge, and it seems the xen prevents linux from doing just that.

It seems like linux treats the stuff it finds behind cardbus bridge like 
PCI device (i'm not sure if it is a real device or just how linux treats 
it a virtual pci devices).

thus for output of /sbin/lspci from linux classic we get

redbull:/usr/src/cm/xen # /sbin/lspci

0000:00:00.0 Host bridge: Intel Corp. 82830 830 Chipset Host Bridge (rev 02)
0000:00:01.0 PCI bridge: Intel Corp. 82830 830 Chipset AGP Bridge (rev 02)
0000:00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 01)
0000:00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 01)
0000:00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 01)
0000:00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 41)
0000:00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 01)
0000:00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 01)
0000:00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus Controller (rev 01)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio Controller (rev 01)
0000:01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR (rev 05)
0000:02:00.0 CardBus bridge: Texas Instruments PCI1420
0000:02:00.1 CardBus bridge: Texas Instruments PCI1420
0000:02:02.0 Communication controller: Lucent Microelectronics WinModem 56k (rev 01)
0000:02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller (rev 41)
0000:07:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03)

redbull:/usr/src/cm/xen # /sbin/lspci -tv

-[00]-+-00.0  Intel Corp. 82830 830 Chipset Host Bridge
       +-01.0-[01]----00.0  S3 Inc. SuperSavage IX/C SDR
       +-1d.0  Intel Corp. 82801CA/CAM USB (Hub #1)
       +-1d.1  Intel Corp. 82801CA/CAM USB (Hub #2)
       +-1d.2  Intel Corp. 82801CA/CAM USB (Hub #3)
       +-1e.0-[02-08]--+-[07]---00.0  Xircom Cardbus Ethernet 10/100
       |               \-[02]-+-00.0  Texas Instruments PCI1420
       |                      +-00.1  Texas Instruments PCI1420
       |                      +-02.0  Lucent Microelectronics WinModem 56k
       |                      \-08.0  Intel Corp. 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller
       +-1f.0  Intel Corp. 82801CAM ISA Bridge (LPC)
       +-1f.1  Intel Corp. 82801CAM IDE U100
       +-1f.3  Intel Corp. 82801CA/CAM SMBus Controller
       \-1f.5  Intel Corp. 82801CA/CAM AC'97 Audio Controller


... but when we repeat it under xenolinux, we don't see the "PCI" device 
"Xircom Cardbus Ethernet 10/100" anymore (although we do see the cardbus 
bridge)

redbull:/usr/src/cm/xen #  /sbin/lspci

0000:00:00.0 Host bridge: Intel Corp. 82830 830 Chipset Host Bridge (rev 02)
0000:00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 01)
0000:00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 01)
0000:00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 01)
0000:00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 01)
0000:00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 01)
0000:00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus Controller (rev 01)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio Controller (rev 01)
0000:01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR (rev 05)
0000:02:00.0 CardBus bridge: Texas Instruments PCI1420
0000:02:00.1 CardBus bridge: Texas Instruments PCI1420
0000:02:02.0 Communication controller: Lucent Microelectronics WinModem 56k (rev 01)
0000:02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller (rev 41)

redbull:/usr/src/cm/xen #  /sbin/lspci -tv

-+-[02]-+-00.0  Texas Instruments PCI1420
  |      +-00.1  Texas Instruments PCI1420
  |      +-02.0  Lucent Microelectronics WinModem 56k
  |      \-08.0  Intel Corp. 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller
  +-[01]---00.0  S3 Inc. SuperSavage IX/C SDR
  \-[00]-+-00.0  Intel Corp. 82830 830 Chipset Host Bridge
         +-1d.0  Intel Corp. 82801CA/CAM USB (Hub #1)
         +-1d.1  Intel Corp. 82801CA/CAM USB (Hub #2)
         +-1d.2  Intel Corp. 82801CA/CAM USB (Hub #3)
         +-1f.0  Intel Corp. 82801CAM ISA Bridge (LPC)
         +-1f.1  Intel Corp. 82801CAM IDE U100
         +-1f.3  Intel Corp. 82801CA/CAM SMBus Controller
         \-1f.5  Intel Corp. 82801CA/CAM AC'97 Audio Controller

poking a bit around we can see that the xircom pci device gets added by 
yenta_socket.c. In there yenta_allocate_res() tries to allocate resources 
for those devices behing the bridge. However, it appears that xen prevents 
xenolinux just from doing that, as shown below.

(XEN) 02:00:01 reg=0x14 len=0x01 val=0x00000210 0 Guest 0 attempting sub-dword read to BASE_ADDRESS 1
(XEN) PCI: Found IRQ 9 for device 02:00.1
(XEN) PCI: Sharing IRQ 9 with 00:1f.3
(XEN) PCI: Sharing IRQ 9 with 00:1f.5
(XEN) 02:00:01 reg=0x14 len=0x01 val=0x00000210 0 Guest 0 attempting sub-dword read to BASE_ADDRESS 1
(XEN) 02:00:01 reg=0x18 len=0x04 val=0xb00a0702 0 Guest attempting update to BASE_ADDRESS 2
(XEN) 02:00:01 reg=0x1c len=0x04 val=0x10c00000 0 Guest attempting update to BASE_ADDRESS 3
(XEN) 02:00:01 reg=0x20 len=0x04 val=0x10ffffff 0 Guest attempting update to BASE_ADDRESS 4
(XEN) 02:00:01 reg=0x24 len=0x04 val=0x11000000 0 Guest attempting update to BASE_ADDRESS 5
(XEN) 02:00:01 reg=0x30 len=0x04 val=0x000048ff 0 caution: guest tried to change rom address.
(XEN) b=7 d=0 f=0 target does not exist
(XEN) pci_cfgreg_read : 07:00:00 reg=0x0e len=0x01 val=0xffffffff ret=0xffffffed
(XEN) b=7 d=0 f=0 target does not exist
(XEN) pci_cfgreg_read : 07:00:00 reg=0x00 len=0x04 val=0xffffffff ret=0xffffffed

ideas?


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: xen and pci

[Adam Sulmicki]

On Sat, 18 Dec 2004, Adam Sulmicki wrote:

> HOWEVER, once it finds it would like to configure devices behind this bridge, 
> and it seems the xen prevents linux from doing just that.
>
> It seems like linux treats the stuff it finds behind cardbus bridge like PCI 
> device (i'm not sure if it is a real device or just how linux treats it a 
> virtual pci devices).
>
> redbull:/usr/src/cm/xen # /sbin/lspci
>
> 0000:02:00.0 CardBus bridge: Texas Instruments PCI1420
> 0000:02:00.1 CardBus bridge: Texas Instruments PCI1420

> 0000:07:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03)

well after a bit more playing with it, I got linux pci drivers to find the 
xircom PCI card (by letting linux write the pci registers on cardbus), but 
xen still knows nothing about it so things still explode, shortly later 
on.

on another front I have tried the xen 2.0-testing (ie the xen 2.1 
pre-release) which as I understand should leave most of the pci handling 
to dom0... but, ... so far it seems no different than xen 2.0 release in 
that it still does not find the xircom card and it is missing form output 
of /sbin/lspci



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: xen and pci

[mristola]

I have found one thing from my kernel configuration:

I use PCMCIA WLAN driver atmel_cs.c.
It requires CONFIG_ISA.

I do have:
CONFIG_ISA=y
CONFIG_ISAPNP=y

I don't know, why atmel_cs.c needs ISA bus.

atmel_cs.c notes, that if ISA bus is not enabled, the driver
might not be able to assign an IRQ. I don't know, on which 
kind of PCMCIA hardware.

For other readers: my PCMCIA WLAN card works under Xen Domain-0.
I do have a working kernel configuration for it.

Here is a short summary, with the ISA bus:


# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
CONFIG_ATMEL=m
CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m
CONFIG_HOTPLUG_PCI_CPCI=y
CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m
CONFIG_HOTPLUG_PCI_FAKE=m
CONFIG_HOTPLUG_PCI=m
CONFIG_HOTPLUG_PCI_PCIE=m
# CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE is not set
CONFIG_HOTPLUG_PCI_SHPC=m
# CONFIG_HOTPLUG_PCI_SHPC_PHPRM_LEGACY is not set
# CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE is not set
CONFIG_HOTPLUG=y
CONFIG_NET_PCMCIA=y
CONFIG_PCI_ATMEL=m
# CONFIG_PCMCIA_AHA152X is not set
CONFIG_PCMCIA_ATMEL=m
# CONFIG_PCMCIA_AXNET is not set
CONFIG_PCMCIA_DEBUG=y
# CONFIG_PCMCIA_FDOMAIN is not set
# CONFIG_PCMCIA_FMVJ18X is not set
# CONFIG_PCMCIA_NETWAVE is not set
# CONFIG_PCMCIA_NINJA_SCSI is not set
# CONFIG_PCMCIA_NMCLAN is not set
# CONFIG_PCMCIA_PCNET is not set
CONFIG_PCMCIA_PROBE=y
# CONFIG_PCMCIA_QLOGIC is not set
# CONFIG_PCMCIA_RAYCS is not set
# CONFIG_PCMCIA_SMC91C92 is not set
# CONFIG_PCMCIA_SYM53C500 is not set
# CONFIG_PCMCIA_WAVELAN is not set
# CONFIG_PCMCIA_WL3501 is not set
# CONFIG_PCMCIA_XIRCOM is not set
# CONFIG_PCMCIA_XIRC2PS is not set
# CONFIG_PCMCIA_XIRTULIP is not set
CONFIG_PCMCIA=y
# CONFIG_PCMCIA_3C574 is not set
# CONFIG_PCMCIA_3C589 is not set
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
CONFIG_YENTA=m
# PCMCIA/CardBus support
# PCMCIA character devices
# PCMCIA network device support
# PCMCIA SCSI adapter support

CONFIG_GENERIC_ISA_DMA=y
CONFIG_ISA=y
#
CONFIG_ISAPNP=y
# CONFIG_PNPBIOS is not set


Marko Ristola


On Sat, 18 Dec 2004 18:41:31 -0500 (EST) Adam Sulmicki <adam@cfar.umd.edu> wrote:

> On Sat, 30 Oct 2004, Keir Fraser wrote:
> 
> > *However* I think that pcmcia/cardbus bridges are safe to tell dom0 
> > about (Xen cannot probe behind them) and they have a special subtype 
> > that we could detect. So we can rejig the test that hides the bridges
> to 
> > be a little bit smarter.
> 
> > --- common/physdev.c    2004-10-22 11:51:50.918741798 +0100
> > +++ common-new/physdev.c        2004-10-30 08:40:33.513342843 +0100
> > @@ -747,7 +747,8 @@
> >          *
> >          * In Linux2.6 we set pcibios_scan_all_fns().
> >          */
> > -        if ( dev->hdr_type != PCI_HEADER_TYPE_NORMAL )
> > +        if ( (dev->hdr_type != PCI_HEADER_TYPE_NORMAL) &&
> > +             (dev->hdr_type != PCI_HEADER_TYPE_CARDBUS) )
> >             continue;
> >         pdev = xmalloc(sizeof(phys_dev_t));
> >         pdev->dev = dev;
> 
> The lack of pcmcia network was annoying me so I poked more around.
> 
> The above fix helps in that linux can find the cardbus bridge.
> 
> HOWEVER, once it finds it would like to configure devices behind this 
> bridge, and it seems the xen prevents linux from doing just that.
> 
> It seems like linux treats the stuff it finds behind cardbus bridge
> like 
> PCI device (i'm not sure if it is a real device or just how linux
> treats 
> it a virtual pci devices).
> 
> thus for output of /sbin/lspci from linux classic we get
> 
> redbull:/usr/src/cm/xen # /sbin/lspci
> 
> 0000:00:00.0 Host bridge: Intel Corp. 82830 830 Chipset Host Bridge
> (rev 02)
> 0000:00:01.0 PCI bridge: Intel Corp. 82830 830 Chipset AGP Bridge (rev
> 02)
> 0000:00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev
> 01)
> 0000:00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev
> 01)
> 0000:00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev
> 01)
> 0000:00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 41)
> 0000:00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 01)
> 0000:00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 01)
> 0000:00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus Controller (rev 01)
> 0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97
> Audio Controller (rev 01)
> 0000:01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR
> (rev 05)
> 0000:02:00.0 CardBus bridge: Texas Instruments PCI1420
> 0000:02:00.1 CardBus bridge: Texas Instruments PCI1420
> 0000:02:02.0 Communication controller: Lucent Microelectronics WinModem
> 56k (rev 01)
> 0000:02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) PRO/100
> VE (LOM) Ethernet Controller (rev 41)
> 0000:07:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev
> 03)
> 
> redbull:/usr/src/cm/xen # /sbin/lspci -tv
> 
> -[00]-+-00.0  Intel Corp. 82830 830 Chipset Host Bridge
>        +-01.0-[01]----00.0  S3 Inc. SuperSavage IX/C SDR
>        +-1d.0  Intel Corp. 82801CA/CAM USB (Hub #1)
>        +-1d.1  Intel Corp. 82801CA/CAM USB (Hub #2)
>        +-1d.2  Intel Corp. 82801CA/CAM USB (Hub #3)
>        +-1e.0-[02-08]--+-[07]---00.0  Xircom Cardbus Ethernet 10/100
>        |               \-[02]-+-00.0  Texas Instruments PCI1420
>        |                      +-00.1  Texas Instruments PCI1420
>        |                      +-02.0  Lucent Microelectronics WinModem
> 56k
>        |                      \-08.0  Intel Corp. 82801CAM (ICH3)
> PRO/100 VE (LOM) Ethernet Controller
>        +-1f.0  Intel Corp. 82801CAM ISA Bridge (LPC)
>        +-1f.1  Intel Corp. 82801CAM IDE U100
>        +-1f.3  Intel Corp. 82801CA/CAM SMBus Controller
>        \-1f.5  Intel Corp. 82801CA/CAM AC'97 Audio Controller
> 
> 
> ... but when we repeat it under xenolinux, we don't see the "PCI"
> device 
> "Xircom Cardbus Ethernet 10/100" anymore (although we do see the
> cardbus 
> bridge)
> 
> redbull:/usr/src/cm/xen #  /sbin/lspci
> 
> 0000:00:00.0 Host bridge: Intel Corp. 82830 830 Chipset Host Bridge
> (rev 02)
> 0000:00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev
> 01)
> 0000:00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev
> 01)
> 0000:00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev
> 01)
> 0000:00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 01)
> 0000:00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 01)
> 0000:00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus Controller (rev 01)
> 0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97
> Audio Controller (rev 01)
> 0000:01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR
> (rev 05)
> 0000:02:00.0 CardBus bridge: Texas Instruments PCI1420
> 0000:02:00.1 CardBus bridge: Texas Instruments PCI1420
> 0000:02:02.0 Communication controller: Lucent Microelectronics WinModem
> 56k (rev 01)
> 0000:02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) PRO/100
> VE (LOM) Ethernet Controller (rev 41)
> 
> redbull:/usr/src/cm/xen #  /sbin/lspci -tv
> 
> -+-[02]-+-00.0  Texas Instruments PCI1420
>   |      +-00.1  Texas Instruments PCI1420
>   |      +-02.0  Lucent Microelectronics WinModem 56k
>   |      \-08.0  Intel Corp. 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet
> Controller
>   +-[01]---00.0  S3 Inc. SuperSavage IX/C SDR
>   \-[00]-+-00.0  Intel Corp. 82830 830 Chipset Host Bridge
>          +-1d.0  Intel Corp. 82801CA/CAM USB (Hub #1)
>          +-1d.1  Intel Corp. 82801CA/CAM USB (Hub #2)
>          +-1d.2  Intel Corp. 82801CA/CAM USB (Hub #3)
>          +-1f.0  Intel Corp. 82801CAM ISA Bridge (LPC)
>          +-1f.1  Intel Corp. 82801CAM IDE U100
>          +-1f.3  Intel Corp. 82801CA/CAM SMBus Controller
>          \-1f.5  Intel Corp. 82801CA/CAM AC'97 Audio Controller
> 
> poking a bit around we can see that the xircom pci device gets added by
> 
> yenta_socket.c. In there yenta_allocate_res() tries to allocate
> resources 
> for those devices behing the bridge. However, it appears that xen
> prevents 
> xenolinux just from doing that, as shown below.
> 
> (XEN) 02:00:01 reg=0x14 len=0x01 val=0x00000210 0 Guest 0 attempting
> sub-dword read to BASE_ADDRESS 1
> (XEN) PCI: Found IRQ 9 for device 02:00.1
> (XEN) PCI: Sharing IRQ 9 with 00:1f.3
> (XEN) PCI: Sharing IRQ 9 with 00:1f.5
> (XEN) 02:00:01 reg=0x14 len=0x01 val=0x00000210 0 Guest 0 attempting
> sub-dword read to BASE_ADDRESS 1
> (XEN) 02:00:01 reg=0x18 len=0x04 val=0xb00a0702 0 Guest attempting
> update to BASE_ADDRESS 2
> (XEN) 02:00:01 reg=0x1c len=0x04 val=0x10c00000 0 Guest attempting
> update to BASE_ADDRESS 3
> (XEN) 02:00:01 reg=0x20 len=0x04 val=0x10ffffff 0 Guest attempting
> update to BASE_ADDRESS 4
> (XEN) 02:00:01 reg=0x24 len=0x04 val=0x11000000 0 Guest attempting
> update to BASE_ADDRESS 5
> (XEN) 02:00:01 reg=0x30 len=0x04 val=0x000048ff 0 caution: guest tried
> to change rom address.
> (XEN) b=7 d=0 f=0 target does not exist
> (XEN) pci_cfgreg_read : 07:00:00 reg=0x0e len=0x01 val=0xffffffff
> ret=0xffffffed
> (XEN) b=7 d=0 f=0 target does not exist
> (XEN) pci_cfgreg_read : 07:00:00 reg=0x00 len=0x04 val=0xffffffff
> ret=0xffffffed
> 
> ideas?
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
> users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
> 


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: xen and pci

[Adam Sulmicki]

On Tue, 4 Jan 2005 mristola@cc.hut.fi wrote:

> I don't know, why atmel_cs.c needs ISA bus.

I think the difference is that your card *IS* 16 bit PCMCIA card, while 
the one I'm using is 32bit cardbus.

as far as I know the first one is more like ISA bus, the other one is more 
like PCI bus.

Either way I give up this issue right now for now and I'll just wait for 
xen team to release revised version of xen's support for PCI bus.



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: xen and pci

[Ronald G. Minnich]

On Tue, 4 Jan 2005 mristola@cc.hut.fi wrote:

> I don't know, why atmel_cs.c needs ISA bus.

My memory is that PCMCIA *is* ISA bus ...

ron


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

RE: xen and pci

[Ian Pratt]

> on another front I have tried the xen 2.0-testing (ie the xen 2.1
> pre-release) which as I understand should leave most of the 
> pci handling to dom0... but, ... so far it seems no different 
> than xen 2.0 release in that it still does not find the 
> xircom card and it is missing form output of /sbin/lspci

The pci changes haven't gone in yet. We'll announce when they do as
we'll want people to test them.

Ian



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/

RE: xen and pci

[Adam Sulmicki]

>> on another front I have tried the xen 2.0-testing (ie the xen 2.1
>> pre-release) which as I understand should leave most of the
>> pci handling to dom0... but, ... so far it seems no different
>> than xen 2.0 release in that it still does not find the
>> xircom card and it is missing form output of /sbin/lspci
>
> The pci changes haven't gone in yet. We'll announce when they do as
> we'll want people to test them.

do you have any ETA? I just wonder if it worth of wait. For example the 
web page says that 2.1 is due out on January. Does this data still stand?



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/