Bug 1139

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