From owner-freebsd-acpi@FreeBSD.ORG Thu Nov 4 22:23:52 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBCD416A4CE; Thu, 4 Nov 2004 22:23:52 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5679A43D3F; Thu, 4 Nov 2004 22:23:52 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP id IBA74465; Thu, 04 Nov 2004 14:23:52 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id CA4B55D04; Thu, 4 Nov 2004 14:23:51 -0800 (PST) To: John Baldwin In-reply-to: Your message of "Mon, 01 Nov 2004 17:48:25 EST." <200411011748.25052.jhb@FreeBSD.org> Date: Thu, 04 Nov 2004 14:23:51 -0800 From: "Kevin Oberman" Message-Id: <20041104222351.CA4B55D04@ptavv.es.net> cc: acpi@FreeBSD.org cc: freebsd-acpi@FreeBSD.org Subject: Re: ASUS P5A broken by ACPI black-list X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Nov 2004 22:23:53 -0000 > From: John Baldwin > 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 > > > > Date: Tue, 5 Oct 2004 12:09:44 -0400 > > > > > > > > On Tuesday 05 October 2004 11:54 am, Kevin Oberman wrote: > > > > > > From: John Baldwin > > > > > > 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. 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!) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634