From owner-freebsd-mobile@FreeBSD.ORG Thu Oct 12 20:06:17 2006 Return-Path: X-Original-To: freebsd-mobile@freebsd.org Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF7C016A412 for ; Thu, 12 Oct 2006 20:06:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1CA043D55 for ; Thu, 12 Oct 2006 20:06:16 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k9CK69HB008148; Thu, 12 Oct 2006 16:06:09 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Erik Norgaard Date: Thu, 12 Oct 2006 16:06:21 -0400 User-Agent: KMail/1.9.1 References: <452E3E0B.6040709@locolomo.org> <200610121501.48116.jhb@freebsd.org> <452E9DA7.9050008@locolomo.org> In-Reply-To: <452E9DA7.9050008@locolomo.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610121606.22200.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 12 Oct 2006 16:06:09 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/2027/Thu Oct 12 13:49:16 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-mobile@freebsd.org Subject: Re: ACPI Problems: IRQ conflicts on USB controllers and SATA controller X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2006 20:06:18 -0000 On Thursday 12 October 2006 15:55, Erik Norgaard wrote: > John Baldwin wrote: > > On Thursday 12 October 2006 12:42, Erik Norgaard wrote: > >> I have dumped dmesg and other stuff with different options at boot, > >> since this is pretty verbose I've placed it on my website: > >> > >> boot -v: > >> > >> http://www.locolomo.org/src/acpi/dmesg-GENERIC-v > >> http://www.locolomo.org/src/acpi/sysctl-GENERIC-v > >> http://www.locolomo.org/src/acpi/pciconf-GENERIC-v > >> http://www.locolomo.org/src/acpi/lspci-GENERIC-v > >> http://www.locolomo.org/src/acpi/vmstat-GENERIC-v > > > > Nothing here looks wrong. Can you break into the debugger when the box > > locks up? > > The box freezes when apic is disabled but pci_link is enabled. In the > above case, both apic and pci_link are enabled, this sucks out resources > of the box with 85% cpu on interrupt handling. Ok, so get vmstat -i output. There's not much flexibility here though as all the APIC IRQ's are hardcoded, so to guess which ones are routed incorrectly will be a pain. > I will try to see if I can get the debugger when apic is disabled and > pci_link enabled. Actually, I think I know what that is already. > >> boot -v, acpi disabled: > > > > Doesn't detect APIC. BIOS is too dumb to provide $PIR. That's a new > > low for incompetence on the part of BIOS writers. > > Strange - is ACPI required on this box to find APIC? Sounds wierd when > they are both enabled they each seem to fight for control over the > devices... ACPI and APIC are two _entirely_ different things. On your box, yes, ACPI is required to find APICs. > >> boot -v, apic disabled: > >> > >> http://www.locolomo.org/src/acpi/dmesg-GENERIC-v-no_apic > > > > The problem here is (again) really stupid BIOS writers. Maybe they can't > > read. Edit your ASL to change the resources to say that IRQ 10 (which > > the BIOS assigns) is ok instead of IRQ 11. You can probably get by just > > with fixing LNKD's resource: > > > > Device (LNKD) > > { > > Name (_HID, EisaId ("PNP0C0F")) > > Name (_UID, 0x04) > > Method (_DIS, 0, Serialized) > > { > > Store (0x80, PDRC) > > } > > > > Name (_PRS, ResourceTemplate () > > { > > IRQ (Level, ActiveLow, Shared) > > {1,3,4,5,6,7,11,12,14,15} > > }) > > > > Replace the '11' here with '10' and update it. In fact, you should > > fix the ones with IRQ's '10' and '12' to list '10' and '11' instead > > and the ones with '11' and '12' to list '10' and '11' instead. > > > > 12 is used by your PS/2 mouse/trackpad, so it isn't suitable. > > Thanks I will try that. I'm new on this, will loading a custom ASL > overwrite the existing permanently? I mean, I'm kind of worried that I > mess up and have a box that can't boot at all. No, you load it from the loader and the kernel just uses the one you load instead of the one from the BIOS. Check acpi(4) more. > Secondly, I see there is nothing on IRQ9 in the ASL, yet I have an > interrupt storm on IRQ9 also, should 9 be added to the list above? No. > Finally, previously I solved the interrupt storm on IRQ5 by setting > hw.pci6.10.INTA.irq=5 in the loader.conf, can this be corrected in the > ASL also? You really shouldn't use that hint, you should route an entire link (hw.pci.link.LNKD.irq = 5 for example) when using links. First try just fixing your ASL w/o using any settings in loader.conf. Hmm, you can also try just doing this w/o having to hack your ASL which might fix things: hw.pci.link.LNKB.irq=10 hw.pci.link.LNKD.irq=10 hw.pci.link.LNKF.irq=10 It will emit warnings about the IRQs not being valid but still use them, and this matches what your BIOS used. -- John Baldwin