Distribution: Debian Sid Hardware Environment: Asus M2400N Centrino Laptop Software Environment: Tested with 2.6.10-ac8,ac6,ac2. Should happen with any 2.6.10. Problem Description: Using "Plug and Play ACPI support" breaks the soundcard as IRQ 7 is assigned to parport. Without PnP ACPI: -------------------- Advanced Linux Sound Architecture Driver Version 1.0.6 (Sun Aug 15 07:17:53 2004 UTC). PCI: Enabling device 0000:00:1f.5 (0005 -> 0007) ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 7 (level, low) -> IRQ 7 PCI: Setting latency timer of device 0000:00:1f.5 to 64 ieee1394: Host added: ID:BUS[0-00:1023] GUID[00e01800030be9ec] intel8x0_measure_ac97_clock: measured 49479 usecs intel8x0: clocking to 48000 ALSA device list: #0: Intel 82801DB-ICH4 with STAC9721/23 at 0x2f800400, irq 7 ------------------- With PnP ACPI: ------------------- Advanced Linux Sound Architecture Driver Version 1.0.6 (Sun Aug 15 07:17:53 2004 UTC). PCI: Enabling device 0000:00:1f.5 (0005 -> 0007) ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 7 (level, low) -> IRQ 7 unable to grab IRQ 7 Intel ICH: probe of 0000:00:1f.5 failed with error -16 ALSA device list: No soundcards found. -------------- Without PnP ACPI parport is used in polling mode. Steps to reproduce: 1.Enable PnP ACPI in the kernel.
Thanks your report this. Could you please attach the completed dmesg? Looks like the PNPACPI said the parport is in interrupt mode and PNPBIOS said it's in polling mode.
Created attachment 4370 [details] Kernel log The kernel ouput is attatched. I grabbed it from /var/log/kern.log. If you want one taken with dmesg, just ask.
Thanks the message. Looks like the ACPI link device used legacy IRQ. We will provide a fix soon. But please also provide the output of 'find /sys/devices/pnp0 -type f|xargs cat', so we have more information.
Created attachment 4371 [details] The output of the command 'find /sys/devices/pnp0 -type f|xargs cat' Here's the output of 'find /sys/devices/pnp0 -type f|xargs cat'.
I don't have PnP BIOS enabled. Should I?
Not necessary. We have understand the problem. In this case, IRQ 1, 3, 6, 7, 8, 12, 13 are used by legacy IRQ, ACPI should not assigned them to PCI devices. Changing an IRQ penalty will solve your problem. Please wait for a patch. Thanks.
Created attachment 4373 [details] patch for the issue Please try this patch.
This patch fixes it. /proc/interrupts: 0: 438038 XT-PIC timer 1: 1369 XT-PIC i8042 2: 0 XT-PIC cascade 3: 1707 XT-PIC irda0 4: 0 XT-PIC Intel 82801DB-ICH4 5: 21937 XT-PIC ohci1394, eth0, uhci_hcd, uhci_hcd, uhci_hcd 7: 1 XT-PIC parport0 8: 14 XT-PIC rtc 9: 661 XT-PIC acpi 12: 2863 XT-PIC i8042 14: 17216 XT-PIC ide0 15: 3789 XT-PIC ide1 I don't know if IRQ 5 should be so crowded but that has always been like that.
Do all devices (especially with IRQ 5) work with the patch? Thanks.
I think so. I haven't tested firewire recently but otherwise I didn't notice anything wrong.
applied to acpi-test tree
shipped in 2.6.13-rc3 -- closing.