Distribution: Debian testing/unstable Problem Description: 2.6.0-test4 now has a function to act like pci=noacpi, used in K7V. My ASUS P5AB also needs pci=noacpi, so it would be a good idea to add it to the blacklist (I know the BIOS is old, but finding out you need pci=noacpi to make ISA devices work on it with acpi=force is hard, and it works fine with acpi=force (I didn't test suspending yet)). I will attach the output of dmidecode so you can find the right values to add.
Created attachment 708 [details] dmidecode output
Something happened in 2.6.0-test7. It no longer needs pci=noacpi. I can't figure why. Anyway, this bug is no longer relevant. The relevant lines of a diff of /var/log/dmesg for test6 and test7 follows: -Linux version 2.6.0-test6-seed (root@seed) (gcc version 3.3.2 20030908 (Debian prerelease)) #1 Sun Sep 28 22:19:55 BRT 2003 +Linux version 2.6.0-test7-seed (root@seed) (gcc version 3.3.2 20030908 (Debian prerelease)) #1 Fri Oct 10 06:49:29 BRT 2003 [...] -Kernel command line: root=/dev/hda3 ro rootfstype=reiserfs resume=/dev/hda2 pmdisk=/dev/hda2 pci=noacpi acpi=force +Kernel command line: root=/dev/hda3 ro rootfstype=reiserfs resume=/dev/hda2 pmdisk=/dev/hda2 acpi=force [...] -ACPI: Subsystem revision 20030813 +ACPI: Subsystem revision 20030918 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing -ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 11 12 14 15, disabled) +ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 9 *10 11 12 14 15) -ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 9 10 11 12 14 15, disabled) -ACPI: PCI Interrupt Link [LNKE] (IRQs 1 3 4 5 6 7 9 10 11 12 14 15, disabled) +ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 9 10 11 12 14 15) +ACPI: PCI Interrupt Link [LNKE] (IRQs 1 3 4 5 6 7 9 10 11 12 14 15) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [...] -PCI: Probing PCI hardware -PCI: Using IRQ router ALI [10b9/1533] at 0000:00:07.0 +ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10 +ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11 +ACPI: No IRQ known for interrupt pin A of device 0000:00:0f.0 +PCI: Using ACPI for IRQ routing +PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off' My SB AWE ISA now works fine without pci=noacpi. I didn't close the bug because I couldn't figure what should the right resolution be.
This system will not be added to the blacklist because the BIOS is from 1998 so it is already blacklisted because of its age. YMMV using acpi=force on systems like this one. I think the reason that -test7 works is because of the fix for bug #1186 which doesn't re-program IRQs that are already active. But the current fix for 1186 is really a workaround, and will probably require a boot flag in the future to enable it since it impacts systems that don't require the workaround. That said, I'm interested to see the /proc/interrupts and complete dmesg for this system when it worked vs when it fails. I'd like to know what IRQ the sound-blaster is on, and if/why ACPI causes that device to fail. To verify that I'm correct about what fixed this box, (and what is about to break it;-) please take your recent working kernel and back out the patch for 1186 (patch -Rp1 < fix.diff) thanks, -Len
The ISA SoundBlaster has always been on IRQ5: CPU0 0: 224319438 XT-PIC timer 1: 2687 XT-PIC i8042 2: 0 XT-PIC cascade 4: 438512 XT-PIC serial 5: 107681 XT-PIC SoundBlaster 8: 4 XT-PIC rtc 9: 0 XT-PIC acpi 10: 167130 XT-PIC eth0 14: 689426 XT-PIC ide0 15: 51 XT-PIC ide1 NMI: 0 ERR: 0 state = active io 0x220-0x22f io 0x388-0x38b irq 5 dma 1 dma 5 Dependent: 01 - Priority preferred port 0x220-0x220, align 0x0, size 0x10, 16-bit address decoding port 0x330-0x330, align 0x0, size 0x2, 16-bit address decoding port 0x388-0x3f8, align 0x0, size 0x4, 16-bit address decoding irq 5 High-Edge dma 1 8-bit byte-count compatible dma 5 16-bit word-count compatible I can't give you a dmesg of when it fails, because it locks up when it fails (sound is not compiled as a module, and at some point it started locking up when some driver is loaded). An older kernel (-test2) didn't lock up (it just didn't play any sound longer than the buffer). I have the dmesgs for -test2 with and without pci=noacpi (acpi=force wasn't needed then) and will attach them here. If you add a boot flag, please tell me which one it was ;-) (or make it appear on the long changelog, I read that) Is the patch you want me to revert and test http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.6.0-test5/20030930005112-acpi_pci_link_allocate.patch ?
Created attachment 1343 [details] dmesg with 2.6.0-test9 and acpi=force
Created attachment 1344 [details] dmesg with 2.6.0-test2 and no pci=noacpi
Created attachment 1345 [details] dmesg with 2.6.0-test2 and pci=noacpi
Oh, you also wanted to know why it fails... With 2.6.0-test2 and without pci=noacpi, the IRQ count in /proc/interrupts is stuck at zero, /usr/bin/play (from sox) gets stuck (but is killable with ^C), and only the first half-second or so of sound gets out. With later kernels (I forget with which one it started), it hangs on boot. I can't remember if the hang is on the sound driver or on the IDE driver. With pci=noacpi or a kernel >= 2.6.0-test7, it simply works.
Yes, that's the patch to revert. If it causes -test9 to fail then that will confirm that is why -test7 started working. Also, if -test9 is well behaved with that patch reverted, (ie. we can get at dmesg and /proc/interrupts) we can use that as a base to debug a real fix. Re: -test9 dmesg > ACPI: IRQ 9 was Edge Triggered, setting to Level Triggerd Does /proc/interrupts register an acpi interrupt for each time you press the power button? > ALI15X3: IDE controller at PCI slot 0000:00:0f.0 > ACPI: No IRQ known for interrupt pin A of device 0000:00:0f.0 > ALI15X3: chipset revision 193 > ALI15X3: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0xd400-0xd407, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0xd408-0xd40f, BIOS settings: hdc:pio, hdd:pio > hda: ST36531A, ATA DISK drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > hdc: CREATIVECD3621E, ATAPI CD/DVD-ROM drive > ide1 at 0x170-0x177,0x376 on irq 15 hda and hdc are working okay? please attach the lspci, acpidmp, and dmidecode output. > Advanced Linux Sound Architecture Driver Version 0.9.7 (Thu Sep 25 19:16:36 2003 UTC). > request_module: failed /sbin/modprobe -- snd-card-0. error = -16 > pnp: Device 01:01.00 activated. > pnp: Device 01:01.02 activated. > sbawe: no OPL device at 0x388-0x38a > ALSA device list: > #0: Sound Blaster 16 at 0x220, irq 5, dma 1&5 the modprobe failure is a red herring and sound is working okay? Re: -test2 dmesg > ACPI: Using PIC for interrupt routing > ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 11 12 14 15, disabled) > ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) > ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 9 *10 11 12 14 15) > ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 9 10 11 12 14 15, disabled) > ACPI: PCI Interrupt Link [LNKE] (IRQs 1 3 4 5 6 7 9 10 11 12 14 15, disabled) > ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 9 > ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 5 > ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 11 > w83781d 0-002d: Subclient 0 registration at address 0x49 failed. > Advanced Linux Sound Architecture Driver Version 0.9.4 (Mon Jun 09 12:01:18 2003 UTC). > request_module: failed /sbin/modprobe -- snd-card-0. error = -16 > pnp: Device 01:01.00 activated. > pnp: Device 01:01.02 activated. > sbawe: no OPL device at 0x388-0x38a > ALSA device list: > #0: Sound Blaster 16 at 0x220, irq 5, dma 1&5 Here sound does not work, right? ACPI assigned LNKD to IRQ5, and so I expect when the sound driver requested exclusive access to IRQ5 then would have failed. The underlying problem is that ACPI has no idea that the ISA sound card exists, and that it will request exclusive access to an IRQ that is fair game for PCI links. it may be sheer luck that there are not enough pci devices to cause all the PCI links to fill up the available IRQs. Re: -test2 dmesg w/ pci=noacpi did sound work in this scenario? -- I think we need to add a cmdline flag to tell ACPI to avoid the IRQ that the sound driver is going to request. Conversely, > ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 9 *10 11 12 14 15) This is an extremely flexible system, able to direct PCI interrupts almost anywhere. If there were a lot of PCI devices, they'd end up sharing IRQs when other IRQs hard-coded to be reserved for ISA would go unused). So we should probably also have a cmdline flag to say that some IRQs are available to PCI.
Wow, lots of questions. Will start compiling soon, should have the answer by tomorrow. As to the other questions... > Does /proc/interrupts register an acpi interrupt for each time you press the power button? Adding an "exit" to the top of /etc/acpi/powerbtn.sh (to prevent it from shutting down) and pressing the button, I saw 2 extra interrupts on that line. Every time I press the power button it adds two extra interrupts (not one, but _two_. No clue why. Maybe press/release?) Here is the output from acpid (I pressed the button two times, not four): [Tue Nov 4 20:03:50 2003] received event "button/power PWRF 00000080 00000001" [Tue Nov 4 20:03:51 2003] executing action "/etc/acpi/powerbtn.sh" [Tue Nov 4 20:03:51 2003] BEGIN HANDLER MESSAGES [Tue Nov 4 20:03:52 2003] END HANDLER MESSAGES [Tue Nov 4 20:03:52 2003] action exited with status 0 [Tue Nov 4 20:03:52 2003] completed event "button/power PWRF 00000080 00000001" [Tue Nov 4 20:03:52 2003] received event "button/power PWRF 00000080 00000002" [Tue Nov 4 20:03:52 2003] executing action "/etc/acpi/powerbtn.sh" [Tue Nov 4 20:03:52 2003] BEGIN HANDLER MESSAGES [Tue Nov 4 20:03:52 2003] END HANDLER MESSAGES [Tue Nov 4 20:03:52 2003] action exited with status 0 [Tue Nov 4 20:03:52 2003] completed event "button/power PWRF 00000080 00000002" [Tue Nov 4 20:06:40 2003] received event "button/power PWRF 00000080 00000003" [Tue Nov 4 20:06:40 2003] executing action "/etc/acpi/powerbtn.sh" [Tue Nov 4 20:06:40 2003] BEGIN HANDLER MESSAGES [Tue Nov 4 20:06:40 2003] END HANDLER MESSAGES [Tue Nov 4 20:06:40 2003] action exited with status 0 [Tue Nov 4 20:06:40 2003] completed event "button/power PWRF 00000080 00000003" [Tue Nov 4 20:06:40 2003] received event "button/power PWRF 00000080 00000004" [Tue Nov 4 20:06:40 2003] executing action "/etc/acpi/powerbtn.sh" [Tue Nov 4 20:06:40 2003] BEGIN HANDLER MESSAGES [Tue Nov 4 20:06:40 2003] END HANDLER MESSAGES [Tue Nov 4 20:06:40 2003] action exited with status 0 [Tue Nov 4 20:06:40 2003] completed event "button/power PWRF 00000080 00000004" > hda and hdc are working okay? Yes. hda is the root (and only) disk. hdc is not used much, but works. > please attach the lspci, acpidmp, and dmidecode output. Will do. > the modprobe failure is a red herring and sound is working okay? Yes, it's a red herring. Looks like the core looks for the module as soon as it's initialized, but it's not a module, it's built in. The next line is the right module being initialized, so it works. > Re: -test2 dmesg > Here sound does not work, right? Yes. In that one the sound gets stuck, looking like the sound driver never gets a single interrupt (and so does not know it has to switch buffers or something like that). > Re: -test2 dmesg w/ pci=noacpi > did sound work in this scenario? Yes, it was the solution. After I noticed the interrupt counter was not being incremented, I tried that and it worked.
Created attachment 1348 [details] lspci -v with 2.6.0-test9
Created attachment 1349 [details] acpidmp output
Created attachment 1350 [details] biosdecode output
I won't attach the output of dmidecode again, as it hasn't changed. It's attachment 708 [details].
Finally tested with 2.6.0-test9 and that patch reverted. It hangs on boot (complete hang, fails the "num lock" test (press numlock and see if it lights) and with no way to scroll up and see the IRQ routing lines. I have no serial console :| ). The hang is after the following line: pnp: Device 01:01.02 activated. Which points to the sound driver as the cause of the lockup (look at the following line in the normal dmesg -- it's still the sound driver ("sbawe: no OPL device at 0x388-0x38a")). So, you were right. That was the patch which made things work without pci=noacpi.
please apply the patch from bug #430 attachment (id=1353) and boot with (acpi=force and) "acpi_irq_isa=5" and let me know how it goes. Also, please try booting with (acpi=force and) "acpi_irq_static". if it boots, please attach the dmesg and /proc/interrupts. thanks, -Len
No change. All three work as good as 2.6.0-test9 (normal, acpi_irq_isa=5 and acpi_irq_static). All three play sound. Are you sure that is the right patch? (Yes, I double checked I applied it. Why do people never add extra printks in experimental patches? Just checked again to make sure.) The only lines which changed are the ones that always change on boot, and the obvious ones (the one which outputs the uname, and the command line). Not even the Memory: line changed (which means the code size change was smaller than a page). The changed lines are the one with the CPU speed, the one with the gameport speed, and the obscure "Disabled Privacy Extensions on device" with a random memory address. Do I still need to attach the dmesgs and /proc/interrupts, even with no change to plain -test9? (btw, "Triggerd" sounds kinda strange)
Created attachment 1374 [details] patch to leave SCI in edge mode Please apply this patch and see if you still get two acpi interrupts for each button press. Thanks, -Len
Created attachment 1375 [details] debug pci_link patch Hmmm, I would have expected the new pci_link patch to make 2.6 fail, just like reverting the old pci_link pach did. Here's another go -- this one has some debug output that we should see in dmesg. Maybe it will tell us why the new patch doesn't fail under any conditions. Please try it with 1. acpi=force 2. acpi=force acpi_irq_static 3. acpi=force acpi_irq_isa=5 let me know if sound is working properly, and attach the dmesg and /proc/interrupts thanks, -Len
If 2.4.26 or 2.6.5 don't work, please re-open. thanks, -Len