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

On Mon, 22 Mar 2004 11:33:36 -0800 (PST)
Nate Lawson <nate_at_root.org> wrote:

> 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.

:-) Since I'm not able to debug this myself, it the least I could do.

> > 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.

I'm doing it right now, thank you.
(Recompiling the acpi.ko wouldn't be enough ?)

[..]

> > --- 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
> 
> 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.

Where do I find this section ?

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

Will report results in about 30 minutes, thanks.



-- 
IOnut
Unregistered ;) FreeBSD user