On Monday 22 February 2010 04:51:43 pm Yoichi Yuasa wrote: > Hi Bjorn, > > On Mon, 22 Feb 2010 13:55:28 -0700 > Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote: > > > On Sunday 21 February 2010 12:45:31 am Yoichi Yuasa wrote: > > > > I'd like to understand the PCI architecture of Cobalt better. Would you > > > > mind turning on CONFIG_PCI_DEBUG and posting the dmesg log? > > > > > > If you want to know what happen, you can see my old e-mail. > > > > > > http://marc.info/?l=linux-kernel&m=118792430424186&w=2 > > > > There's not much detail there. It would save me a lot of time if > > you could collect the complete dmesg log, /proc/iomem, and /proc/ioports. > > It cannot boot without old hack. I know; I meant that the information from a kernel with the old hack would be useful. But I think I'm starting to understand anyway. The Linux I/O port number space is defined here: static struct resource cobalt_io_resource = { .start = 0x1000, .end = GT_DEF_PCI0_IO_SIZE - 1, /* 0x1ffffff */ [As an aside, I'm not sure 0x1000 is the correct start -- for example, I think Linux I/O port 0x1f0 is forwarded by the host bridge.] The corresponding PCI I/O port numbers are determined by the PCI I/O decoder address, so I agree that we need the io_offset to convert between the Linux port numbers and ports that appear on the PCI bus. I think the IDE device is a problem because pci_setup_device() fills in legacy resources with ports 0x1f0-0x1f7, etc. We expect those resources to contain PCI bus addresses at this point, but we could never see those addresses on the Cobalt PCI bus (we would only see things in the range 0x10000000-0x11ffffff). When we convert 0x1f0 with pcibios_bus_to_resource() (or with pcibios_fixup_device_resources() without the IORESOURCE_PCI_FIXED hack), we get 0x1f0 + 0xf0000000 == 0xf00001f0, when we want 0x1f0 instead. > pata_via 0000:00:09.1: BAR 0: can't reserve [io 0xf00001f0-0xf00001f7] I still don't know the best way to fix this, but does this make sense so far? Bjorn
