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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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
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
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/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel