Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Nov 2004 17:30:04 -0500
From:      John Baldwin <jhb@FreeBSD.org>
To:        freebsd-acpi@FreeBSD.org
Cc:        acpi@FreeBSD.org
Subject:   Re: ASUS P5A broken by ACPI black-list
Message-ID:  <200411041730.04081.jhb@FreeBSD.org>
In-Reply-To: <20041104222351.CA4B55D04@ptavv.es.net>
References:  <20041104222351.CA4B55D04@ptavv.es.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 04 November 2004 05:23 pm, Kevin Oberman wrote:
> > From: John Baldwin <jhb@FreeBSD.org>
> > Date: Mon, 1 Nov 2004 17:48:25 -0500
> >
> > On Wednesday 06 October 2004 01:20 pm, John Baldwin wrote:
> > > On Tuesday 05 October 2004 04:32 pm, Kevin Oberman wrote:
> > > > > From: John Baldwin <jhb@FreeBSD.org>
> > > > > Date: Tue, 5 Oct 2004 12:09:44 -0400
> > > > >
> > > > > On Tuesday 05 October 2004 11:54 am, Kevin Oberman wrote:
> > > > > > > From: John Baldwin <jhb@FreeBSD.org>
> > > > > > > Date: Mon, 4 Oct 2004 15:57:30 -0400
> > > > > > >
> > > > > > > On Monday 04 October 2004 02:33 pm, Nate Lawson wrote:
> > > > > > > > Kevin Oberman wrote:
> > > > > > > > > It looks like interrupts from the Ethernet are not
> > > > > > > > > delivered without ACPI, but that is hardly your problem. I
> > > > > > > > > have over-ridden the black-list and things are back to
> > > > > > > > > normal.
> > > > > > > >
> > > > > > > > The reason this system works in Windows without ACPI is that
> > > > > > > > irq routing in Windows uses multiple info sources including
> > > > > > > > _PIR and $PIR. John Baldwin has patches to do this for us
> > > > > > > > too.
> > > > > > >
> > > > > > > $PIR routing already works on FreeBSD and has worked for quite
> > > > > > > a while. The patches I have are to make the acpi_pci_link code
> > > > > > > work more like the $PIR code already does.  It doesn't change
> > > > > > > the ACPI code to actually use $PIR or the MPTable though.  I
> > > > > > > can try to look at why the ethernet device doesn't get
> > > > > > > interrupts correctly if you can provide verbose ACPI and
> > > > > > > non-ACPI dmesgs to look at.
> > > > > >
> > > > > > I am attaching the files. I do see some oddities with the
> > > > > > interrupts that I had not previously noted, but they seen to be
> > > > > > linked to sound, not the Ethernet. And, for whatever it's worth,
> > > > > > "vmstat -i" does not show my sound card, at all. dmesg indicates
> > > > > > it should be on IRQ 6. interrupt                          total
> > > > > > rate
> > > > > > irq0: clk                        4242251         99
> > > > > > irq1: atkbd0                           3          0
> > > > > > irq7: ppc0                             1          0
> > > > > > irq8: rtc                        5430044        127
> > > > > > irq10: xl0                         13699          0
> > > > > > irq13: npx0                            1          0
> > > > > > irq14: ata0                       166980          3
> > > > > > irq15: ata1                          136          0
> > > > > > Total                            9853115        232
> > > > >
> > > > > First, do you have a floppy drive?  IRQ 6 should be used for your
> > > > > floppy drive if so.  Note that $PIR says that IRQ 6 is not an
> > > > > option for your link devices but ACPI does.  In the non-APCI case
> > > > > we use IRQ 10 for both xl0 and pcm0. Are you saying that in that
> > > > > case pcm0 works but xl0 does not?
> > > >
> > > > The sound card works fine with ACPI but, without ACPI it fails. The
> > > > first tone in the file plays continuously, like there are no
> > > > interrupts from the sound card. :-)
> > >
> > > Ok, well, it seems your BIOS is too busted for non-ACPI to work out of
> > > the box, you can try setting a hint to force the link for your sound
> > > card to use IRQ 6.  Something like 'set hw.pci.link.0x4.irq=6', or
> > > maybe 'hw.pci.link.0x04.irq' if that doesn't work.
> >
> > Actually, the $PIR code won't let you use an invalid IRQ currently, but
> > this patch lets it do so.  I'm curious if you could try booting with this
> > patch with ACPI disabled and using an appropriate tunable (such as
> > 'hw.pci.link.0x4.irq=6') to route your links the way ACPI likes them
> > routed. If this does work, I'd like to try another patch as well that
> > would help it to work out-of-the-box for the non-ACPI case.  Thanks.
>
> John,
>
> I have not forgotten this, but remote testing when re-boots are required
> is a bit difficult. My wife helped me a bit yesterday, but she is a
> Solaris type and I need to step her through things command by command,
> so it's a bit tedious.

That's ok, take your time, this isn't super critical.

> I may get a chance to try again tonight, depending on when I get out of
> the convention center tonight. (Today we installed all of the hardware
> into the NOC... 2 big Juniper routers, a Force10 E1200, a Foundry
> NetIron, and  bunch of Cisco 6509s. I think we have 8 or 9 10 Gig.
> circuits coming inn this year. Lots of fiber patching!)

Heh, sounds like fun. :)

-- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200411041730.04081.jhb>