Linus Torvalds wrote: > I'm not going to do anything about it right now, since clearly we've > not changed any actual behavior from before. But if you remind me after > 2.6.31 is out, I'll look at perhaps making a better > "pci_claim_resource()" that actually iterates over the different parent > resources and doesn't just try to find one (and then fail if that > particular one doesn't work out). Just for your information, this issue also affects my (old) Toshiba Satellite A40. With pre-2.6.31 kernels I always had the following in dmesg: pci 0000:00:1d.0: BAR 4: can't allocate resource pci 0000:00:1d.1: BAR 4: can't allocate resource [...] pnp 00:08: io resource (0x10-0x1f) overlaps 0000:00:1d.0 BAR 4 (0x0-0x1f), disabling pnp 00:08: io resource (0x10-0x1f) overlaps 0000:00:1d.1 BAR 4 (0x0-0x1f), disabling I was very happy to see that for 2.6.31-rc2 those messages were gone. But with .31-rc5 they are back again, with added "address space collision": pci 0000:00:1d.0: BAR 4: address space collision on of device [0xcfe0-0xcfff] pci 0000:00:1d.0: BAR 4: can't allocate resource pci 0000:00:1d.1: BAR 4: address space collision on of device [0xcf80-0xcf9f] pci 0000:00:1d.1: BAR 4: can't allocate resource [...] pnp 00:08: io resource (0x10-0x1f) overlaps 0000:00:1d.0 BAR 4 (0x0-0x1f), disabling pnp 00:08: io resource (0x10-0x1f) overlaps 0000:00:1d.1 BAR 4 (0x0-0x1f), disabling It's never resulted in things not working, but it would still be nice if it got solved. Please let me know if you'd like anything tested. Cheers, FJP -- 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
