On Sun, 27 Jan 2008 12:17:17 -0600 Robert Hancock <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > 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. > > > > [EMAIL PROTECTED]: fix text and coding-style a bit] > > Signed-off-by: Li Shaohua <[EMAIL PROTECTED]> > > Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]> > > Cc: Bjorn Helgaas <[EMAIL PROTECTED]> > > Cc: Thomas Renninger <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > 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 I don't think anything has happened yet on this? > Here's why the driver fails to load: > > [ 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:[EMAIL PROTECTED] 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: > > https://bugzilla.redhat.com/show_bug.cgi?id=313491 Thanks. If we were to remove the supermicro-specificity, would this be a sufficiently general solution? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
