http://bugzilla.kernel.org/show_bug.cgi?id=6575
------- Additional Comments From [EMAIL PROTECTED] 2006-06-08 09:22 -------
Re: ACPI interrupt
"pci=noacpi" will break your ACPI interrupt if you run in IOAPIC mode.
This is a known limitation of the "pci=noacpi" workaround. Per comment
#4:
9: 0 IO-APIC-edge acpi
Which ignores the override telling the kernel that ACPI is
level sensitive on IOAPIC pin 21:
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 21 low level)
You can verify that the ACPI interrupt is working in the default case
this way:
Kill acpid
cat /proc/interrupts | grep acpi
cat /proc/acpi/event
press the power button a few times
you should see some power button event lines come out
cat /proc/interrupts |grep acpi
you should see the count increment at least onece for each power button
press
Based on this non-zero count, I expect that this is working:
169: 1079 IO-APIC-level acpi
Re: sound device
0000:00:14.5 Multimedia audio controller:
ATI Technologies Inc IXP SB400 AC'97 Audio Controller (rev 01)
Interrupt: pin B routed to IRQ 137
Sometimes different vector, depending on other use of vectors:
ACPI: PCI Interrupt 0000:00:14.5[B] -> GSI 17 (level, low) -> IRQ 209
ALSA sound/pci/atiixp.c:518: atiixp: codec reset timeout
But no indication that there is something wrong with pin 17.
Just to simplify, please build your kernel with
CONFIG_PCI_MSI=n
Please observe /proc/interruts
play sound so that you can hear it in the headphones
observe /proc/interrupts
You should see the line with "ATI IXP" increment
If that line is shared with something else, then unload
the driver for that something else. (I noticed this was the
case for the pci=noacpi case, but not for the ACPI case)
Re: windows
it would be interesting to get a dump of the IRQ assignments
from Windows to verify that it puts the devices the same place
that we do. Eg. If they run in PIC mode and we run in IOAPIC mode,
I'd take that as a big hint...
Re: IOAPIC on ATI
There are a number of things that are somewhat risky on this
system with the IOAPIC enabled, including a timer workaround,
sky2 running in MSI mode (does it work?), and APIC bus errors.
It might make sense to try to isolate the sound issue by
running only in the simpler "noapic" mode.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
acpi-bugzilla mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
