On Fri, 14 Aug 2009, Frans Pop wrote: > On Friday 14 August 2009, Linus Torvalds wrote: > > Can you send > > - output of /proc/ioports both with the current kernel (or the 2.6.30 > > kernel - they should be identical) and with one of the kernels in > > between that didn't warn > > - send the full bootup dmesg with CONFIG_PCI_DEBUG enabled > > > > and we can probably figure it out. > > Attached. Ok, this one actually looks obvious from just the ioports thing: --- ioports.a76117d 2009-08-14 18:44:42.000000000 +0200 +++ ioports.current-git 2009-08-14 18:44:42.000000000 +0200 ... +18c0-18df : 0000:00:1d.0 + 18c0-18df : uhci_hcd +18e0-18ff : 0000:00:1d.1 + 18e0-18ff : uhci_hcd bfa0-bfaf : 0000:00:1f.1 bfa0-bfaf : piix c000-cfff : PCI Bus 0000:01 c000-c0ff : PCI CardBus 0000:02 c400-c4ff : PCI CardBus 0000:02 cf40-cf7f : 0000:01:08.0 cf40-cf7f : e100 - cf80-cf9f : 0000:00:1d.1 - cf80-cf9f : uhci_hcd - cfe0-cfff : 0000:00:1d.0 - cfe0-cfff : uhci_hcd That old cf80-cf9f/cfe0-cfff location is just totally invalid. Your UHCI device is (as it shows) PCI device 0000:00:1d, functions 0/1. In other words, they are on PCI bus 0. But the c000-cfff area is a window that has been set up for PCI bus 1. The ioports.a76117d version is simply wrong. The Linux PCI layer did the right thing, and moved the silly device away from that PCI bus 1 window. Now, it so happens that I bet it does _work_ in there, but that's likely because that 0000:00:1d.x device is on the southbridge chip itself, and it probably simply gets decoded before it any access is even sent out on the PCI bus and hits the bridge for bus#1. But the fact is, your BIOS has simply set up the devices in a totally insane way, and I think the kernel did everything right. So the fact that it "worked" for a few kernels was simply due to a kernel bug, where "pci_claim_resource()" incorrectly allowed the resource to be inserted into a resource window that wasn't actually its parent, and a crazy BIOS that did crazy things, together with a chipset where those crazy things just _happened_ to work because of how decoding was done. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
