With v2.6.24 my second ALSA sound device stopped working.
After bisection it says this was the offending commit.
a7839e960675b549f06209d18283d5cee2ce9261 is first bad commit commit a7839e960675b549f06209d18283d5cee2ce9261 Author: Zhao Yakui <yakui.z...@intel.com> Date: Wed Nov 28 16:21:21 2007 -0800
PNP: increase the maximum number of resources
On some systems the number of resources(IO,MEM) returnedy by PNP device is greater than the PNP constant, for example motherboard devices. It brings that some resources can't be reserved and resource confilicts. This will cause PCI resources are assigned wrongly in some systems, and cause hang. This is a regression since we deleted ACPI motherboard driver and use PNP system driver.
[a...@linux-foundation.org: fix text and coding-style a bit] Signed-off-by: Li Shaohua <shaohua...@intel.com> Signed-off-by: Zhao Yakui <yakui.z...@intel.com> Cc: Bjorn Helgaas <bjorn.helg...@hp.com> Cc: Thomas Renninger <tr...@suse.de> Cc: <sta...@kernel.org> Signed-off-by: Andrew Morton <a...@linux-foundation.org> Signed-off-by: Linus Torvalds <torva...@linux-foundation.org>
The audio device is 00:1b.0 (see my lspci -vvv output), the other audio device works fine.
Avuton Olrich wrote: > With v2.6.24 my second ALSA sound device stopped working.
> After bisection it says this was the offending commit.
> a7839e960675b549f06209d18283d5cee2ce9261 is first bad commit > commit a7839e960675b549f06209d18283d5cee2ce9261 > Author: Zhao Yakui <yakui.z...@intel.com> > Date: Wed Nov 28 16:21:21 2007 -0800
> PNP: increase the maximum number of resources
> On some systems the number of resources(IO,MEM) returnedy by PNP device is > greater than the PNP constant, for example motherboard devices. It brings > that some resources can't be reserved and resource confilicts. This will > cause PCI resources are assigned wrongly in some systems, and cause hang. > This is a regression since we deleted ACPI motherboard driver and use PNP > system driver.
> [a...@linux-foundation.org: fix text and coding-style a bit] > Signed-off-by: Li Shaohua <shaohua...@intel.com> > Signed-off-by: Zhao Yakui <yakui.z...@intel.com> > Cc: Bjorn Helgaas <bjorn.helg...@hp.com> > Cc: Thomas Renninger <tr...@suse.de> > Cc: <sta...@kernel.org> > Signed-off-by: Andrew Morton <a...@linux-foundation.org> > Signed-off-by: Linus Torvalds <torva...@linux-foundation.org>
> The audio device is 00:1b.0 (see my lspci -vvv output), the other > audio device works fine.
[ 31.133060] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22 [ 31.133141] PCI: Unable to reserve mem region #1:4000@febf8000 for device 0000:00:1b.0 [ 31.133197] ACPI: PCI interrupt for device 0000:00:1b.0 disabled [ 31.133244] HDA Intel: probe of 0000:00:1b.0 failed with error -16
The iomem location of the HDA controller conflicts with this reservation by the BIOS:
[ 22.906654] system 00:08: iomem range 0xfebfa000-0xfebfac00 has been reserved
There was a patch floating around to ignore PnPACPI reservations which conflict with PCI BARs, which appears to be what's happening in this case. That patch originally worked for any board, but was later made specific to a certain Supermicro motherboard which had the sata_nv controller MMIO regions marked as reserved, preventing the driver from loading. We may need a more general solution. See:
> With v2.6.24 my second ALSA sound device stopped working.
Hmm. Why is PnP ACPI called before PCI probing? That seems to be the problem here - we should *never* have any firmware allocation block known hardware BARs, they should only be blocking new dynamic allocations.
Hmm. I wonder if the problem is that ACPIPnP marks the regions busy. That would be wrong. They shouldn't be busy, they should just "exist".
A busy region will stop a "request_region()" (incorrect for this case - thats' not what the PnP resurce allocation should be all about), but an *existing* resource will just stop a new resource being dynamically assigned to that address (not not stop a known resource from using it).
So maybe the ACPIPnP allocation is doen at the right moment, just doing the wrong thing..
On Mon, 2008-01-28 at 08:50 +1100, Linus Torvalds wrote:
> On Sun, 27 Jan 2008, Avuton Olrich wrote:
> > With v2.6.24 my second ALSA sound device stopped working.
> Hmm. Why is PnP ACPI called before PCI probing? That seems to be the > problem here - we should *never* have any firmware allocation block known > hardware BARs, they should only be blocking new dynamic allocations.
> Hmm. I wonder if the problem is that ACPIPnP marks the regions busy. That > would be wrong. They shouldn't be busy, they should just "exist".
> A busy region will stop a "request_region()" (incorrect for this case - > thats' not what the PnP resurce allocation should be all about), but an > *existing* resource will just stop a new resource being dynamically > assigned to that address (not not stop a known resource from using it).
> So maybe the ACPIPnP allocation is doen at the right moment, just doing > the wrong thing..
This is because the region is declaimed in motherboard device. That is BIOS thinks the region is reserved for motherboard. Maybe we should blacklist the system too.
Robert Hancock <hanco...@shaw.ca> wrote: > Avuton Olrich wrote: > > With v2.6.24 my second ALSA sound device stopped working.
> > After bisection it says this was the offending commit.
> > a7839e960675b549f06209d18283d5cee2ce9261 is first bad commit > > commit a7839e960675b549f06209d18283d5cee2ce9261 > > Author: Zhao Yakui <yakui.z...@intel.com> > > Date: Wed Nov 28 16:21:21 2007 -0800
> > PNP: increase the maximum number of resources
> > On some systems the number of resources(IO,MEM) returnedy by PNP device is > > greater than the PNP constant, for example motherboard devices. It brings > > that some resources can't be reserved and resource confilicts. This will > > cause PCI resources are assigned wrongly in some systems, and cause hang. > > This is a regression since we deleted ACPI motherboard driver and use PNP > > system driver.
> > [a...@linux-foundation.org: fix text and coding-style a bit] > > Signed-off-by: Li Shaohua <shaohua...@intel.com> > > Signed-off-by: Zhao Yakui <yakui.z...@intel.com> > > Cc: Bjorn Helgaas <bjorn.helg...@hp.com> > > Cc: Thomas Renninger <tr...@suse.de> > > Cc: <sta...@kernel.org> > > Signed-off-by: Andrew Morton <a...@linux-foundation.org> > > Signed-off-by: Linus Torvalds <torva...@linux-foundation.org>
> > The audio device is 00:1b.0 (see my lspci -vvv output), the other > > audio device works fine.
> [ 31.133060] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, > low) -> IRQ 22 > [ 31.133141] PCI: Unable to reserve mem region #1:4000@febf8000 for > device 0000:00:1b.0 > [ 31.133197] ACPI: PCI interrupt for device 0000:00:1b.0 disabled > [ 31.133244] HDA Intel: probe of 0000:00:1b.0 failed with error -16
> The iomem location of the HDA controller conflicts with this reservation > by the BIOS:
> [ 22.906654] system 00:08: iomem range 0xfebfa000-0xfebfac00 has been > reserved
> There was a patch floating around to ignore PnPACPI reservations which > conflict with PCI BARs, which appears to be what's happening in this > case. That patch originally worked for any board, but was later made > specific to a certain Supermicro motherboard which had the sata_nv > controller MMIO regions marked as reserved, preventing the driver from > loading. We may need a more general solution. See:
Andrew Morton wrote: >> There was a patch floating around to ignore PnPACPI reservations which >> conflict with PCI BARs, which appears to be what's happening in this >> case. That patch originally worked for any board, but was later made >> specific to a certain Supermicro motherboard which had the sata_nv >> controller MMIO regions marked as reserved, preventing the driver from >> loading. We may need a more general solution. See:
> Thanks. If we were to remove the supermicro-specificity, would this be a > sufficiently general solution?
I think so. There was one objection that it introduced a dependency on pnpacpi loading after PCI bus enumeration, though.
Linus also suggested that pnpacpi could be marking the resources as "present but unused" so that drivers can request those regions but we still prevent dynamically assigning resources into them. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
> I think so. There was one objection that it introduced a dependency on pnpacpi > loading after PCI bus enumeration, though.
> Linus also suggested that pnpacpi could be marking the resources as "present > but unused" so that drivers can request those regions but we still prevent > dynamically assigning resources into them.
I _think_ that's what ACPI used to do before switching over to the PnPACPI thing, so I do think that "present but not reserved" approach is not just the right one, but also the (historically) tested one.
On Thursday 31 January 2008 05:50:13 pm Linus Torvalds wrote:
> On Thu, 31 Jan 2008, Robert Hancock wrote:
> > I think so. There was one objection that it introduced a dependency on pnpacpi > > loading after PCI bus enumeration, though.
> > Linus also suggested that pnpacpi could be marking the resources as "present > > but unused" so that drivers can request those regions but we still prevent > > dynamically assigning resources into them.
> I _think_ that's what ACPI used to do before switching over to the PnPACPI > thing, so I do think that "present but not reserved" approach is not just > the right one, but also the (historically) tested one.
The reservation happens in drivers/pnp/system.c, and it does mark the region as "not busy."
I think the problem here is that the PCI BAR is bigger and spans the region reported by ACPI:
[ 22.906654] system 00:08: iomem range 0xfebfa000-0xfebfac00 has been reserved [ 31.133141] PCI: Unable to reserve mem region #1:4000@febf8000 for device 0000:00:1b.0
We can easily add more BIOSes to the PNP quirk.
I really don't want to use the earlier quirk that scanned PCI devices from a PNP quirk. I think that's just wrong because PNP (which conceptually includes ACPI) is what tells us about PCI root bridges.
> I think the problem here is that the PCI BAR is bigger and spans the > region reported by ACPI:
Ok, then it doesn't help that it's not busy.
In that case, the only real fix is to simply do the ACPI reservations *after* PCI probing. Which is what it should have done to begin with.
> We can easily add more BIOSes to the PNP quirk.
No. Don't add quirks just because the basic ordering is shit.
> I really don't want to use the earlier quirk that scanned PCI devices > from a PNP quirk. I think that's just wrong because PNP (which > conceptually includes ACPI) is what tells us about PCI root bridges.
So? Do the bridge listing separately from resource marking. Why tie the two together? They have absolutely *nothing* to do with each other.
The fact is, scanning devices should happen first. And AFTER the device tree is scanned, we can then safely add all the special resources that don't show up as normal devices.
On Monday 04 February 2008 11:18:09 am Linus Torvalds wrote:
> On Mon, 4 Feb 2008, Bjorn Helgaas wrote:
> > I think the problem here is that the PCI BAR is bigger and spans the > > region reported by ACPI:
> Ok, then it doesn't help that it's not busy.
> In that case, the only real fix is to simply do the ACPI reservations > *after* PCI probing. Which is what it should have done to begin with.
I'm sure you're right, but I don't understand why yet. Here's what I think is happening; please correct me where I'm going wrong:
1) enumerate PNP & ACPI devices 2) initialize PNP & ACPI drivers 2a) register ACPI PCI root bridge driver, which enumerates PCI devices behind the bridge 2b) register PNP system driver and reserve resources (this is where the current quirk skips some reservations) 3) initialize PCI drivers 3a) register intel8x0 sound driver and reserve conflicting resources
> > I really don't want to use the earlier quirk that scanned PCI devices > > from a PNP quirk. I think that's just wrong because PNP (which > > conceptually includes ACPI) is what tells us about PCI root bridges.
> So? Do the bridge listing separately from resource marking. Why tie the > two together? They have absolutely *nothing* to do with each other.
> The fact is, scanning devices should happen first. And AFTER the device > tree is scanned, we can then safely add all the special resources that > don't show up as normal devices.
I think you're suggesting that we should do 2a first, to enumerate all PCI devices, and only later do 2b. But I don't know how to accomplish that cleanly.
It does happen in that order today, but only because the ACPI drivers are registered before the PNP drivers. I think that's an artificial distinction, so I don't want to rely on it. If the PCI bridge driver became a PNP driver, we could use link ordering to make sure it still came first, although that seems a little fragile to me.
> I'm sure you're right, but I don't understand why yet. Here's what > I think is happening; please correct me where I'm going wrong:
> 1) enumerate PNP & ACPI devices > 2) initialize PNP & ACPI drivers > 2a) register ACPI PCI root bridge driver, which enumerates PCI > devices behind the bridge > 2b) register PNP system driver and reserve resources (this is > where the current quirk skips some reservations) > 3) initialize PCI drivers > 3a) register intel8x0 sound driver and reserve conflicting > resources
So where in this would you put the
pcibios_init() -> pcibios_resource_survey()
call (it's a subsys_initcall)?
THAT is the thing that actually registers the PCI resurces we've found into the resource tree!
It's very inconveniently placed as-is, since it literally depends on the whole initcall ordering (and the link order within that subsys_initcall thing), and all of this is architecture-driven rather than driven from some central place.
So this is the thing that I think should happen before any PnP or ACPI drivers actually start registerign themselves (but obviously needs to happen after the PCI buses have been enumerated).
The ACPI/PnP tables shouldn't be able to break the enumeration of the actual hardware devices, now should it?
> I think you're suggesting that we should do 2a first, to enumerate all > PCI devices, and only later do 2b. But I don't know how to accomplish > that cleanly.
We should enumerate the PCI devices, then register their resources (and no, I'm not at *all* convinced it should happen as a separate subsys_initcall), and then register the PnP resources.
So I think we should have roughly something like:
- arch_initcall: this could enumerate the ACPI/PnP devices (but not register anything). Alternatively, do it as subsys_initcall, and just make sure it happens early with link-order.
- subsys_initcall: this should do that pcibios_init() thing that surveys the resources (and the PCI enumeration needs to have happened before, probably in the same initcall thanks to link order)
- PnP/ACPI resource allocation *after* it, but before driver loading (which wll cause new resources to be allocated). This could be fs_initcall, or whatever (that's what things like "acpi_event_init" already do).
- regular drivers will come along much later, as part of driver_initcall, and by the time this happens, we've now reserved all resources we know about.
Basically, we just want to register the most trust-worthy resources before we register anything less trust-worthy. And actual device probing simply tends to be more trust-worthy than any randomly broken ACPI/PnP tables.
On Monday 04 February 2008 02:16:52 pm Linus Torvalds wrote:
> On Mon, 4 Feb 2008, Bjorn Helgaas wrote:
> So where in this would you put the
> pcibios_init() -> pcibios_resource_survey()
> call (it's a subsys_initcall)?
> THAT is the thing that actually registers the PCI resurces we've found > into the resource tree!
I think pcibios_init() currently happens after we register ACPI & PNP drivers, i.e., at 3 below:
1) enumerate PNP & ACPI devices 2) initialize PNP & ACPI drivers 2a) register ACPI PCI root bridge driver, which enumerates PCI devices behind the bridge 2b) register PNP system driver and reserve resources (this is where the current quirk skips some reservations) 3) pcibios_init() -> pcibios_resource_survey() 4) initialize PCI drivers 4a) register intel8x0 sound driver and reserve resources (conflict happens here)
> The ACPI/PnP tables shouldn't be able to break the enumeration of the > actual hardware devices, now should it?
Well, no :-) We have to make PNP & ACPI smart enough to not cause trouble, and I fully accept that the burden is on PNP.
But PNPBIOS and ACPI by definition are for devices that don't have their own enumeration protocol. Obviously, we have a lot of legacy drivers that blindly probe for devices at magic addresses, but that's validating guesswork, not actually enumerating anything.
In this particular case, we can easily enumerate all the PCI devices in domain 0. But for machines that have multiple PCI domains, I don't think we want to exhaustively scan all possible domains. ACPI tells us what root bridges exist and what domain each is in, so we can scan a little more efficiently.
> We should enumerate the PCI devices, then register their resources (and > no, I'm not at *all* convinced it should happen as a separate > subsys_initcall), and then register the PnP resources.
> So I think we should have roughly something like:
> - arch_initcall: this could enumerate the ACPI/PnP devices (but not > register anything). Alternatively, do it as subsys_initcall, and just > make sure it happens early with link-order.
Scanning PCI buses has to happen here, which currently means that we have to register the ACPI PCI root driver so we know which domains and buses to scan.
> - subsys_initcall: this should do that pcibios_init() thing that surveys > the resources (and the PCI enumeration needs to have happened before, > probably in the same initcall thanks to link order)
> - PnP/ACPI resource allocation *after* it, but before driver loading > (which wll cause new resources to be allocated). This could be > fs_initcall, or whatever (that's what things like "acpi_event_init" > already do).
If we put the PNP system driver here, we can easily do a quirk that ignores PNP resources that overlap PCI resources. But it's kind of ugly to have the ACPI PCI root driver early and other PNP drivers later because they're basically similar animals.
> - regular drivers will come along much later, as part of > driver_initcall, and by the time this happens, we've now reserved all > resources we know about.
> Basically, we just want to register the most trust-worthy resources before > we register anything less trust-worthy. And actual device probing simply > tends to be more trust-worthy than any randomly broken ACPI/PnP tables.
I agree that PCI BARs are likely more trustworthy than firmware tables. Maybe we could figure out a way to do the PNP reservations, then revert them if we find an overlapping PCI BAR.
Does anybody with this motherboard (or the Supermicro board with similar SATA problems) also have Windows on it? I'm curious to see how Windows deals with this conflict, e.g., what shows up in the device manager?
On Feb 4, 2008 11:03 PM, Bjorn Helgaas <bjorn.helg...@hp.com> wrote:
> Does anybody with this motherboard (or the Supermicro board with > similar SATA problems) also have Windows on it? I'm curious to > see how Windows deals with this conflict, e.g., what shows up in > the device manager?
Sorry, I don't own Windows. -- avuton -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
> > - PnP/ACPI resource allocation *after* it, but before driver loading > > (which wll cause new resources to be allocated). This could be > > fs_initcall, or whatever (that's what things like "acpi_event_init" > > already do).
> If we put the PNP system driver here, we can easily do a quirk that > ignores PNP resources that overlap PCI resources.
No, you don't need any quirks: you just do an "insert_resource()" and ignore the error return. If the (bogus) PnP resource clashes with the (correct) hardware PCI resource, the insert will simply fail. No quirks needed.
> But it's kind of > ugly to have the ACPI PCI root driver early and other PNP drivers > later because they're basically similar animals.
No they are not.
If one does just device enumeration, and the other does resource registrations, then they ARE NOT similar animals at all. Don't claim that they are.
> > > - PnP/ACPI resource allocation *after* it, but before driver loading > > > (which wll cause new resources to be allocated). This could be > > > fs_initcall, or whatever (that's what things like "acpi_event_init" > > > already do).
> > If we put the PNP system driver here, we can easily do a quirk that > > ignores PNP resources that overlap PCI resources.
> No, you don't need any quirks: you just do an "insert_resource()" and > ignore the error return. If the (bogus) PnP resource clashes with the > (correct) hardware PCI resource, the insert will simply fail. No quirks > needed.
> > But it's kind of > > ugly to have the ACPI PCI root driver early and other PNP drivers > > later because they're basically similar animals.
> No they are not.
> If one does just device enumeration, and the other does resource > registrations, then they ARE NOT similar animals at all. Don't claim that > they are.
Whoa, easy :-) I just meant they're similar in that we discover PCI root bridges and other PNP devices by traversing the ACPI namespace, so unless we make special arrangements, we bind drivers to them at roughly the same time.
I'll play with your insert_resource() idea and see if I can figure something out.
On Feb 5, 2008 12:12 PM, Bjorn Helgaas <bjorn.helg...@hp.com> wrote:
> I'll play with your insert_resource() idea and see if I can figure > something out.
Any word on this yet?
Thanks! -- avuton -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Tuesday 05 February 2008 01:12:46 pm Bjorn Helgaas wrote:
> On Tuesday 05 February 2008 11:15:12 am Linus Torvalds wrote: > > No, you don't need any quirks: you just do an "insert_resource()" and > > ignore the error return. If the (bogus) PnP resource clashes with the > > (correct) hardware PCI resource, the insert will simply fail. No quirks > > needed. > I'll play with your insert_resource() idea and see if I can figure > something out.
Sorry for the delay. I did work on this, but I don't see how this can work. pcibios_init() marks its reservations as not busy, so the subsequent PNP request doesn't fail, even if it clashes.
The PNP system driver is an fs_initcall(), so it already happens after pcibios_init():
1) register ACPI PCI root bridge driver, which enumerates PCI devices behind the bridge 2) pcibios_init() -> pcibios_resource_survey() -> request_resource() 3) register PNP system driver -> request_region() 4) register intel8x0 sound driver and reserve resources (conflict happens here)
We have reservations in this order:
febf8000-febfbfff : 0000:00:1b.0 -- from pcibios_resource_survey (!busy) febfa000-febfac00 : pnp 00:08 -- from PNP system driver (!busy) febf8000-febfbfff : ICH HD audio -- fails because it spans the PNP region
The PNP reservation succeeds even though the PCI reservation has already happened, so I don't see how we can do this without a quirk that ignores the bogus PNP resources.
> Sorry for the delay. I did work on this, but I don't see how this > can work. pcibios_init() marks its reservations as not busy, so the > subsequent PNP request doesn't fail, even if it clashes.
It *shouldn't* fail.
Things should fail only when two different drivers have requested the same region. NOT when something tells the system that a region _exists_.
On Thursday 14 February 2008 12:42:52 pm Linus Torvalds wrote:
> On Thu, 14 Feb 2008, Bjorn Helgaas wrote:
> > Sorry for the delay. I did work on this, but I don't see how this > > can work. pcibios_init() marks its reservations as not busy, so the > > subsequent PNP request doesn't fail, even if it clashes.
> It *shouldn't* fail.
> Things should fail only when two different drivers have requested the same > region. NOT when something tells the system that a region _exists_.
The sound driver doesn't fail because two different drivers have requested the same region; it fails because PNP told us a region exists, and the sound region crosses the edge of the PNP region.
You wrote earlier that:
> On Tue, 5 Feb 2008, Bjorn Helgaas wrote: > > > - PnP/ACPI resource allocation *after* it, but before driver > > > loading (which wll cause new resources to be allocated). This > > > could be fs_initcall, or whatever (that's what things like > > > "acpi_event_init" already do).
> > If we put the PNP system driver here, we can easily do a quirk > > that ignores PNP resources that overlap PCI resources.
> No, you don't need any quirks: you just do an "insert_resource()" > and ignore the error return. If the (bogus) PnP resource clashes > with the (correct) hardware PCI resource, the insert will simply > fail. No quirks needed.
I thought you were suggesting here that the PNP system driver would do an insert_resource(), and it would fail if it clashed with the PCI resource.
Can you be more explicit about how you think I should fix this?
On Thu, 14 Feb 2008, Bjorn Helgaas wrote: > On Thursday 14 February 2008 12:42:52 pm Linus Torvalds wrote:
> > It *shouldn't* fail.
> > Things should fail only when two different drivers have requested the same > > region. NOT when something tells the system that a region _exists_.
> The sound driver doesn't fail because two different drivers have > requested the same region; it fails because PNP told us a region > exists, and the sound region crosses the edge of the PNP region.
Right, and that was a bug.
It *shouldn't* fail. The PnP resource should be inserted _after_ the PCI region has been inserted, and _that_ should fail, since the PnP region is crap and cannot be inserted "half-way".
> > On Thursday 14 February 2008 12:42:52 pm Linus Torvalds wrote:
> > > It *shouldn't* fail.
> > > Things should fail only when two different drivers have requested the same > > > region. NOT when something tells the system that a region _exists_.
> > The sound driver doesn't fail because two different drivers have > > requested the same region; it fails because PNP told us a region > > exists, and the sound region crosses the edge of the PNP region.
> Right, and that was a bug.
> It *shouldn't* fail. The PnP resource should be inserted _after_ the > PCI region has been inserted, and _that_ should fail, since the PnP region > is crap and cannot be inserted "half-way".
That means the PNP system driver has to be registered after the PCI driver. We can't guarantee that, especially if the sound driver is a module.
> That means the PNP system driver has to be registered after the PCI > driver.
After the PCI *subsystem*
Here's the actual problem:
[ 31.133141] PCI: Unable to reserve mem region #1:4000@febf8000 for device 0000:00:1b.0
and here is what the resource tree *should* look like:
febf8000-febfbfff : 0000:00:1b.0 febf8000-febfbfff : ICH HD audio
that's with a working sound driver.
Notice how there is *two* resources there: there's the PCI bus resource itself, the one called 0000:00:1b.0 (which was active at boot), and there is the "driver resource" that nests inside of it ("ICH HD audio").
The PCI bus resource is created and inserted into the resource when the PCI bus discovery happens - long before the driver comes along at all.
And the problem is this ABSOLUTE CRAP that happened much earlier:
[ 22.906610] system 00:08: iomem range 0xfebfe000-0xfebfec00 has been reserved [ 22.906654] system 00:08: iomem range 0xfebfa000-0xfebfac00 has been reserved
which happens (a) before the PCI bus probing (b) despite the fact that the PCI bus probing already found something at that address, and PnP shouldn't pollute the *correct* resources.
and the fix is to move that crap PnP to _after_ the PCI bus has been probed, and make sure that if the PnP resource clashes with the known good ones, then PnP gets the h*ll out and doesn't insert it at all.
See?
> We can't guarantee that, especially if the sound driver is > a module.
This has *nothing* to do with the sound driver.
This has everything to do with the fact that the PnP layer is a piece of crap and overrides/messes with the *correct* resources that we found during PCI bus probing.
Is that really so hard to understand?
So here is (for the *fifth* time) what PnP should do:
- only try to insert its resources *after* the PCI bus probing has happened - and if that fails, LET THE CRAP FAIL instead of making the *good* code fail!
> > That means the PNP system driver has to be registered after the PCI > > driver.
> After the PCI *subsystem*
> Here's the actual problem:
> [ 31.133141] PCI: Unable to reserve mem region #1:4000@febf8000 for device 0000:00:1b.0
> and here is what the resource tree *should* look like:
> febf8000-febfbfff : 0000:00:1b.0 > febf8000-febfbfff : ICH HD audio
> that's with a working sound driver.
> Notice how there is *two* resources there: there's the PCI bus resource > itself, the one called 0000:00:1b.0 (which was active at boot), and there > is the "driver resource" that nests inside of it ("ICH HD audio").
> The PCI bus resource is created and inserted into the resource when the > PCI bus discovery happens - long before the driver comes along at all.
> And the problem is this ABSOLUTE CRAP that happened much earlier:
> [ 22.906610] system 00:08: iomem range 0xfebfe000-0xfebfec00 has been reserved > [ 22.906654] system 00:08: iomem range 0xfebfa000-0xfebfac00 has been reserved
> which happens > (a) before the PCI bus probing
I don't think so. pci_scan_bus_parented() happened earlier, here:
and pcibios_init() is a subsys_initcall() that happens before the PNP system driver registers via fs_initcall() (I had this order wrong in a previous email).
> This has everything to do with the fact that the PnP layer is a piece of > crap and overrides/messes with the *correct* resources that we found > during PCI bus probing.
There are clearly problems with PNP. I'm trying to help improve the situation.
> So here is (for the *fifth* time) what PnP should do:
> - only try to insert its resources *after* the PCI bus probing has > happened
That already happens.
> - and if that fails, LET THE CRAP FAIL instead of making the *good* code > fail!
The PNP resource fits entirely inside the PCI bus resource, so the PNP insertion will only fail if the sound driver has already been loaded.
It seems like we're talking past each other. Would anybody else like to step in and help explain this to me? Maybe a fresh viewpoint will help me find a clue.
> > [ 22.906610] system 00:08: iomem range 0xfebfe000-0xfebfec00 has been reserved > > [ 22.906654] system 00:08: iomem range 0xfebfa000-0xfebfac00 has been reserved
> The PNP resource fits entirely inside the PCI bus resource, so the PNP > insertion will only fail if the sound driver has already been loaded.
Ok, it does indeed fit entirely in (and the discussion about "clashing" misled me - the PCI resource doesn't actually clash, it's just a subset). And the problem then ends up that the PnP thing adds resources to inside the PCI resource. It shouldn't. It's crap.
It should insert the resource to the root resource (or a bridge resource), or not at all. If somebody else has already inserted a real device resource, we already know about it, and the PnP information is going to be just making things worse.
The *really* basic issue is that PnP and ACPI generally report utter crap. We should always totally ignore them EXCEPT AS A WAY TO AVOID _NEW_ ALLOCATIONS.
That's the only valid reason to believe in ACPI: we don't know what the hell it's talking about, but we _do_ know that we shouldn't be allocating new resources over it (because if it actually happens to be correct, it is some random scary stuff that we obviously didn't find out about).
But the moment we have better information (where "we actually scanned the hardware" is the very definition of better information), we should always totally discard any ACPI crud. It's guaranteed to be worse than what we already know about.
That's all I ever wanted. To have ACPI realize that it should never ever mess with something we know better about.
> It should insert the resource to the root resource (or a bridge resource), > or not at all. If somebody else has already inserted a real device > resource, we already know about it, and the PnP information is going to be > just making things worse.
Hmm. The approach I'd take is to always insert the thing into the root resource. If we do want to let PnP insert it into some lower-level bus, we'd need to have some way to distinguish "bus" from "device", and we don't.
So right now, how about just making PnP/ACPI just use
which is what we do for the e820 map and the other special resources we know about (ie the magic resources we make up ourselves like video ram and our standard PCI/ISA resource lists like the <0x100 DMA/PIC/FPU IO ports etc)
|
