From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 26 19:05:47 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org 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 3DE5B16A4DA for ; Wed, 26 Jul 2006 19:05:47 +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 7841643D66 for ; Wed, 26 Jul 2006 19:05:46 +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.4/8.13.4) with ESMTP id k6QJ5gLe059327; Wed, 26 Jul 2006 15:05:44 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Steve Kargl Date: Wed, 26 Jul 2006 15:05:38 -0400 User-Agent: KMail/1.9.1 References: <20060724215014.GA89464@troutmask.apl.washington.edu> <200607241823.24477.jhb@freebsd.org> <20060725201556.GA97140@troutmask.apl.washington.edu> In-Reply-To: <20060725201556.GA97140@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607261505.38960.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]); Wed, 26 Jul 2006 15:05:44 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1621/Wed Jul 26 02:13:01 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.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: Alienware acpi problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2006 19:05:47 -0000 On Tuesday 25 July 2006 16:15, Steve Kargl wrote: > On Mon, Jul 24, 2006 at 06:23:24PM -0400, John Baldwin wrote: > > On Monday 24 July 2006 17:50, Steve Kargl wrote: > > > ACPI gurus, > > > > > > My colleague has installed FreeBSD 6.1-table onto his > > > Alienware MJ-12 laptop. During the boot process, we > > > see > > > > > > acpi0: [MPSAFE] > > > ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.PIB_.LNKH] in namespace, > > AE_NOT_FOUND > > > SearchNode 0xffffff000091c240 StartNode 0xffffff000091c240 ReturnNode 0 > > > ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.LNKH] in namespace, > > AE_NOT_FOUND > > > SearchNode 0xffffff00009084c0 StartNode 0xffffff00009084c0 ReturnNode 0 > > > ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.LNKH] in namespace, > > AE_NOT_FOUND > > > SearchNode 0xffffff00008eb200 StartNode 0xffffff00008eb200 ReturnNode 0 > > > ACPI-0438: *** Error: Looking up [\\_SB_.PCI0.LNKH] in namespace, > > AE_NOT_FOUND > > > SearchNode 0xffffff0000909d40 StartNode 0xffffff0000909d40 ReturnNode 0 > > > > Well, that's probably why cardbus is broken. Can you get the output of > > acpidump? Specifically I'd be interested in the parts that mention LNKH (as > > well as where it actually lives in the device tree). > > > > John, > > The pattern LNKH appears in multiple places throughout the asl file. > Instead of sending seemly random chucks to the list, the entire asl > can be found at (uncompressed and gzipped) > > http://troutmask.apl.washington.edu/~kargl/alienware.asl > http://troutmask.apl.washington.edu/~kargl/alienware.asl.gz You have some of the most incompetent BIOS writers I've ever seen working on your machine I'm afraid. First off, there is no LNKH device on your system. You do have various pci_link devices. Four for APIC: ALKA, ALKB, ALKC, and ALKD, and four for non-APIC: LNKA, LNKB, LNKC, LNKD. Not only that, but they all live in \_SB_.PCI0.PCIB. Some places refer to LNKH via \_SB_.PCI0.PCIB.LNKH (as do all places for LNKA - LNKD it seems) but others refer to it as \_SB_.PCI0.LNKH. Anyways, I think you might be fine if you always use 'device apic', as the PCI interrupt routing tables for the APIC case don't seem to reference LNKH. I think it will only go down in flames this way if you disable APIC (via hint or not including 'device apic' in your kernel config). -- John Baldwin