Created attachment 1687 [details]
dmesg (kernel-BK + 20031130031859-pci_link.patch)

2.4: 
> Applying VIA southbridge workaround. 
> PCI: Enabling Via external APIC routing 
> PCI: Via IRQ fixup for 00:07.5, from 10 to 9 
 
2.6: 
> Applying VIA southbridge workaround. 
> PCI: Enabling Via external APIC routing 
> PCI: Via IRQ fixup for 0000:00:07.5, from 10 to 11 
 
But we see sounds still on IRQ10 with ACPI -- so this Via quirk didn't work. 
As ACPI is edge triggered at IRQ10 on this board, that isn't going to work. 
 
Re: IRQ27 -- you'll need this patch too: 
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/test/2.6.0-test9/20031121014213-mpparse_es7000.patch 
 
Maybe simpler to just use the consolidated latest ACPI patch on top of 2.6: 
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.0-test11/ 
 
 

Created attachment 1688 [details]
patch to reserve SCI IRQ with high penalty to avoid sharing

Please test this ACPI patch to discourage sharing the SCI interrupt with PCI.
It should be over-kill, as it is necessary only when SCI is edge-triggered,
but if it works it will show that we're on the right track and perhaps we can
deal with this without VIA quirks.  attach full dmesg and /proc/interrupts
please.

thanks,
-Len

Created attachment 1689 [details]
dmesg outputs

I applied the patch 'acpi-20031203-2.6.0-test11.diff' and the patch
ID 1688 to get this dmesg outputs.

Can I include /proc/interrupts here?
$ cat /proc/interrupts
	   CPU0       
  0:	 568858    IO-APIC-edge  timer
  1:	   1244    IO-APIC-edge  i8042
  2:	      0 	 XT-PIC  cascade
  7:	      2    IO-APIC-edge  parport0
  8:	      1    IO-APIC-edge  rtc
  9:	      0   IO-APIC-level  uhci_hcd, uhci_hcd
 10:	      0    IO-APIC-edge  acpi
 11:	  45408   IO-APIC-level  VIA686A
 12:	  27749    IO-APIC-edge  i8042
 14:	  11856    IO-APIC-edge  ide0
 15:	     45    IO-APIC-edge  ide1
 16:	  34698   IO-APIC-level  nvidia
 18:	    619   IO-APIC-level  eth0
NMI:	      0 
LOC:	 568856 
ERR:	      0
MIS:	      0

As you can see in the dmesg output, I removed 'noirqdebug' and
'acpi_irq_isa=10' cmdline option.

what is the state of this box on 2.4.26 or 2.6.5, do we still have a problem? 
 

Created attachment 2683 [details]
2.6.5 debug patch showing PCI-id on fixups

This patch calls pci_fixup_device() directly from pci_acpi_init(), and squawks
it also still calls from pci_init & squawks.

Created attachment 2684 [details]
2.6.5 debug patch showing PCI-id on fixups - take 2

improved debug patch

Created attachment 2696 [details]
dmesg (Current Linus BK tree + patch-2684)

I lived with 'acpi_irq_isa=10'. Now, I apply the patch id=2684 and
removed 'acpi_irq_isa=10'. I think The problem still exists.

$ cat /proc/interrupts
...
  9:	      0   IO-APIC-level  uhci_hcd, uhci_hcd
 10:	    147   IO-APIC-level  acpi, VIA686A
 12:	   1575    IO-APIC-edge  i8042
...

The IOAPIC-edge issue is gone, IRQ10 is now IOAPIC-level, 
so that's a start;-) 
 
Sound is device 00:07.5 (please attach lspci -vv to confirm pin#) 
using LNKA, B, C, D; enabled at 11, 9, 10, 9, respectively. 
So lspci -vv will probably show this device on LNKC. 
 
At this point sound looks correctly programmed at IRQ10. 
The quirk runs, but it doesn't print anything because ACPI 
programmed the device at IRQ10 and the PCI config 
space matches IRQ10 and doesn't need to be updated. 
 
Does sound not respond on IRQ10? 
I assume that acpi_irq_isa=10 still moves sound off IRQ10 and it the device works there? 
 

Created attachment 2708 [details]
2.6.5 debug patch - take 3

Please apply this patch to 2.6.5
build with CONFIG_PCI_NAMES=y
and attach the resulting full dmesg and /proc/interrupts
for ACPI+IOAPIC mode.

If sound doesn't work on IRQ10, please reboot with
acpi_irq_isa=10, and again attach the full dmesg and /proc/interrupts
and report if sound works at the !=10 IRQ.

This patch tweaks the VIA quirk to always program pci config space,
even if ACPI did not move the interrupt.

When I wrote comment #8, I didn't test sound. I just checked the /proc/interrupts.
Because the acpi and VIA686A shares IRQ 10 like before, I thought the problem
still exists. Sorry!

And now, I just removed 'acpi_irq_isa=10' and reboot.
The /proc/interrupts shows me acpi and VIA686A shares IRQ 10.

$ cat /proc/interrupts
...
  9:          0   IO-APIC-level  uhci_hcd, uhci_hcd
 10:        132   IO-APIC-level  acpi, VIA686A
 12:       1251    IO-APIC-edge  i8042
...

And I have *NO* sound problem. XMMS plays sound well.

So, I don't need the debug patch and send you a dmesg msg any more.
Do you still need dmesg output for patch #2708?

The kernel is linus bk kernel.
$ bk changes
ChangeSet@1.1906, 2004-04-23 06:32:08-07:00, akpm@osdl.org
  [PATCH] writeback livelock fix
...

Here is additional information for the comment #9.
First of all, sound worked fine on IRQ 10.
When I used 'acpi_irq_isa=10', VIA686A used IRQ 11.
(Checked the comment #4).

$ lspci -vv
...

00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio
Controller (rev 50)
	Subsystem: Trigem Computer Inc.: Unknown device 315c
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
	Interrupt: pin C routed to IRQ 10
	Region 0: I/O ports at 1000 [size=256]
	Region 1: I/O ports at 1854 [size=4]
	Region 2: I/O ports at 1850 [size=4]
	Capabilities: <available only to root>

...

Sorry again. I didn't noticed acpi changed to 'IO-APIC-level'.

So everything works now, yes? 
Apparently the problem was that sound was sharing IRQ10 with ACPI 
in IOAPIC-edge mode.  
 
There is no INT_SRC_OVR for the SCI on this system. 
When we fixed the SCI default to be level/low (bug 1622) 
that fixed sound on this system when it shared IRQ10 
with ACPI. 
 
Apparently the VIA quirk part was a red herring. 
 
closing as duplicate of bug 1622. 
 

*** This bug has been marked as a duplicate of 1622 ***