| Message ID | 200908141850.44736.elendil@planet.nl (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 14 August 2009, Linus Torvalds wrote: > 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. OK. Thanks for taking a look. I'll happily ignore the error messages from now on. Luckily confirmation that things work correctly when faced with broken BIOSes can be useful too :-) Cheers, FJP -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- ioports.a76117d 2009-08-14 18:44:42.000000000 +0200 +++ ioports.current-git 2009-08-14 18:44:42.000000000 +0200 @@ -1,68 +1,68 @@ 0000-001f : dma1 0020-0021 : pic1 0040-0043 : timer0 0050-0053 : timer1 0060-0060 : keyboard 0064-0064 : keyboard 0070-0071 : rtc0 0080-008f : dma page reg 00a0-00a1 : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : 0000:00:1f.1 0170-0177 : piix 01e0-01ef : pnp 00:08 01f0-01f7 : 0000:00:1f.1 01f0-01f7 : piix 0376-0376 : 0000:00:1f.1 0376-0376 : piix 0378-037a : parport0 03c0-03df : vesafb 03f6-03f6 : 0000:00:1f.1 03f6-03f6 : piix 0480-048f : pnp 00:08 04d0-04d1 : pnp 00:08 0680-06ff : pnp 00:08 0778-077a : parport0 0800-080f : pnp 00:08 0cf8-0cff : PCI conf1 1000-10ff : 0000:00:1f.5 1400-14ff : 0000:00:1f.6 1800-187f : 0000:00:1f.6 1880-18bf : 0000:00:1f.5 +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 d800-d87f : 0000:00:1f.0 d800-d87f : pnp 00:08 d800-d803 : ACPI PM1a_EVT_BLK d804-d805 : ACPI PM1a_CNT_BLK d808-d80b : ACPI PM_TMR d810-d815 : ACPI CPU throttle d820-d820 : ACPI PM2_CNT_BLK d828-d82f : ACPI GPE0_BLK d830-d833 : iTCO_wdt d860-d87f : iTCO_wdt d880-d89f : pnp 00:08 d8a0-d8bf : pnp 00:08 e000-e07f : pnp 00:08 e080-e0ff : pnp 00:08 e400-e47f : pnp 00:08 e480-e4ff : pnp 00:08 e800-e87f : pnp 00:08 e880-e8ff : pnp 00:08 ec00-ec7f : pnp 00:08 ec80-ecff : pnp 00:08 eeac-eeac : pnp 00:08 eeb0-eebf : pnp 00:08 eec0-eeff : 0000:00:1f.0 eec0-eeff : pnp 00:08 eff8-efff : 0000:00:02.0