[alsa-devel] a7839e96 (PNP: increase max resources) breaks my ALSA intel8x0 sound card
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.zhao@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.
[akpm@linux-foundation.org: fix text and coding-style a bit] Signed-off-by: Li Shaohua shaohua.li@intel.com Signed-off-by: Zhao Yakui yakui.zhao@intel.com Cc: Bjorn Helgaas bjorn.helgaas@hp.com Cc: Thomas Renninger trenn@suse.de Cc: stable@kernel.org Signed-off-by: Andrew Morton akpm@linux-foundation.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org
The audio device is 00:1b.0 (see my lspci -vvv output), the other audio device works fine.
http://avuton.googlepages.com/v2.6-before (dmesg revision before) http://avuton.googlepages.com/v2.6-after (dmesg broken revision) http://avuton.googlepages.com/lspci-vvv http://avuton.googlepages.com/config (from the broken revision) http://avuton.googlepages.com/iomem http://avuton.googlepages.com/ioports
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..
Linus
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.
participants (3)
-
Avuton Olrich -
Linus Torvalds -
Shaohua Li