Re: [acpi-jp 3129] ACPI (_PRS has invalid type 7) problem / regression

On Mon, 22 Mar 2004, Ion-Mihai Tetcu wrote:
> Two days ago I've posted on current_at_ my problem about sound:

Thanks for posting to acpi-jp, as well as providing the full debugging
info requested.  It really saves time for us.

> When I try to play something, I'm getting
> pcm0:play:0: play interrupt timeout, channel dead
> and just noise with sources from 18 Mar; the motherboard is a Gigabyte
> GA-7VT600-L (VIA KT600 / 8237), on-board sound.
>
> I think the problem is acpi routing related, namely :
> -ioapic0: routing intpin 22 (IRQ 22) to cluster 0
> +ioapic0: routing intpin 11 (IRQ 11) to cluster 0
> -pcm0: <VIA VT8233X> port 0xe400-0xe4ff irq 22 at device 17.5 on pci0
> +pcm0: <VIA VT8233X> port 0xe400-0xe4ff irq 11 at device 17.5 on pci0
>
> Booting with acpi disabled "helps". Debug info (as per handbook
> instructions) can be found at: http://people.tecnik93.com/acpi/
>
> The change must have happen between 2004_03_04 and 2004_03_18.

I don't think it was the _PRS changes on 3/18 and 3/20.  I'm suspecting
the ACPI-CA import of 0311.  You can revert all changes to acpi_pcib.c by
copying this file over sys/dev/acpica/acpi_pcib.c and recompiling your
kernel:

http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/dev/acpica/acpi_pcib.c?rev=1.36&content-type=text/plain

I suspect it won't change anything for you but please test this to be
sure.

>  Dmesg snip:
>
>  pcib0: matched entry for 0.17.INTC (source \\_SB_.PCI0.ALKC)
>  pcib0: _PRS has invalid type 7
>  found-> vendor=0x1106, dev=0x3059, revid=0x60
>          bus=0, slot=17, func=5
>          class=04-01-00, hdrtype=0x00, mfdev=0
>          cmdreg=0x0001, statreg=0x0210, cachelnsz=0 (dwords)
>          lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
>          intpin=c, irq=11
>          powerspec 2  supports D0 D1 D2 D3  current D0
>          map[10]: type 4, range 32, base 0000e800, size  8, enabled
>          map[14]: type 1, range 32, base e2000000, size  8, enabled
>
>  pcm0: <VIA VT8233X> port 0xe400-0xe4ff irq 11 at device 17.5 on pci0
>  pcm0: <Avance Logic ALC655 AC97 Codec (id = 0x414c4760)>
>  pcm0: Codec features 5 bit master volume, no 3D Stereo Enhancement
>  pcm0: Primary codec extended features reserved 1, center DAC, surround DAC, LFE DAC, reserved 5
>  pcm0: sndbuf_setmap 27b000, 1000; 0xc4407000 -> 27b000
>  pcm0: sndbuf_setmap 2c0000, 1000; 0xc440c000 -> 2c0000
>  pcm0: sndbuf_setmap 2ac000, 1000; 0xc4438000 -> 2ac000
>  pcm0: sndbuf_setmap 28a000, 1000; 0xc4436000 -> 28a000
>  pcm0: sndbuf_setmap 288000, 1000; 0xc4434000 -> 288000
>  pcm0: sndbuf_setmap 266000, 1000; 0xc4432000 -> 266000
>
>  pciconf shows:
>  pcm0_at_pci0:17:5: class=0x040100 card=0xa0021458 chip=0x30591106 rev=0x60 hdr=0x00
>      vendor   = 'VIA Technologies Inc'
>      device   = 'VT8233/33A AC97 Enhanced Audio Controller'
>      class    = multimedia
>      subclass = audio
>
> Bellow is a diff between the "working: system dmeg and the new one.
> BTW, why does "TSC" frequency differ ?

TSC is calculated based on the i8254 system timer, which is only ~1 Mhz so
it's difficult to predict exactly.  You'll note that the variation in the
TSC will be approximately +/- 1 Mhz.

> --- dmesg_old   Mon Mar 22 16:16:01 2004
> +++ dmesg_new_r Mon Mar 22 17:00:27 2004
> _at__at_ -268,14 +269,13 _at__at_
>         powerspec 2  supports D0 D3  current D0
>         map[10]: type 4, range 32, base 0000e400, size  8, enabled
>  pcib0: matched entry for 0.17.INTC (source \\_SB_.PCI0.ALKC)
> -pcib0: possible interrupts:  22
> -pcib0: slot 17 INTC routed to irq 22 via \\_SB_.PCI0.ALKC
> +pcib0: _PRS has invalid type 7
>  found->        vendor=0x1106, dev=0x3059, revid=0x60
>         bus=0, slot=17, func=5
>         class=04-01-00, hdrtype=0x00, mfdev=0
>         cmdreg=0x0001, statreg=0x0210, cachelnsz=0 (dwords)
>         lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
> -       intpin=c, irq=22
> +       intpin=c, irq=11
>         powerspec 2  supports D0 D1 D2 D3  current D0
>         map[10]: type 4, range 32, base 0000e800, size  8, enabled
>         map[14]: type 1, range 32, base e2000000, size  8, enabled
> _at__at_ -468,12 +468,12 _at__at_
>  ioapic0: routing intpin 7 (IRQ 7) to cluster 0
>  ioapic0: routing intpin 8 (IRQ 8) to cluster 0
>  ioapic0: routing intpin 9 (IRQ 9) to cluster 0
> +ioapic0: routing intpin 11 (IRQ 11) to cluster 0
>  ioapic0: routing intpin 12 (IRQ 12) to cluster 0
>  ioapic0: routing intpin 13 (IRQ 13) to cluster 0
>  ioapic0: routing intpin 14 (IRQ 14) to cluster 0
>  ioapic0: routing intpin 15 (IRQ 15) to cluster 0
>  ioapic0: routing intpin 18 (IRQ 18) to cluster 0
> -ioapic0: routing intpin 22 (IRQ 22) to cluster 0
>  [0] f:00 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:20964762
>  [1] f:00 typ:165 s(CHS):1023/255/63 e(CHS):1023/254/63 s:20964825 l:163573830
>  [2] f:80 typ:165 s(CHS):1023/255/63 e(CHS):1023/254/63 s:184538655 l:20964825

Your ASL returns a different interrupt link resource based on an external
variable DEID.  It may be thinking it's in PIC mode and returning the IRQ
resource instead of APIC mode and the Interrupt resource.  See the section
for ALKC to see what I'm talking about.

I'll look into this more after you try reverting that one file.

-Nate