From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 16 12:43:53 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1E0316A406; Mon, 16 Jul 2007 12:43:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 9232E13C4BB; Mon, 16 Jul 2007 12:43:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.7b8) with ESMTP id 196926944 for multiple; Mon, 16 Jul 2007 08:36:29 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l6GCSBkD031595; Mon, 16 Jul 2007 08:28:11 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Mon, 16 Jul 2007 07:18:38 -0400 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707160718.40814.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]); Mon, 16 Jul 2007 08:28:11 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3680/Mon Jul 16 01:49:06 2007 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 X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: imp@freebsd.org Subject: Re: ACPI on Acer TravelMate 2483WXMi 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: Mon, 16 Jul 2007 12:43:53 -0000 On Friday 13 July 2007 11:52:05 am Oleg Lomaka wrote: > Hello. > > Could you please help to clear out some acpi problems on this laptop. > > When boot with acpi enabled, msk and ath interfaces doesn't work. And when > acpi is disabled, msk is staring up, but ath still doesn't. > Following is dmesg with acpi enabled. > Also there are some additional info: > pciconf -lv: http://www.openhills.com/acpi/pciconf_lv.txt > acpidump -dt: http://www.openhills.com/acpi/acpi.dmp > dmesg with acpi disabled: > http://www.openhills.com/acpi/dmesg-acpi-disabled.txt > dmesg with acpi enabled (the same as inlined): > http://www.openhills.com/acpi/dmesg-acpi-enabled.txt This is why msk(4) doesn't work when ACPI is disabled: > pcib1: irq 16 at device 28.0 on pci0 > pcib1: secondary bus 2 > pcib1: subordinate bus 2 > pcib1: I/O decode 0x0-0x0 > pcib1: memory decode 0x0-0x0 > pcib1: prefetched decode 0x0-0x0 > pci2: on pcib1 > pci2: physical bus=2 > found-> vendor=0x11ab, dev=0x4352, revid=0x14 > bus=2, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0000, statreg=0x4010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D1 D2 D3 current D0 > MSI supports 2 messages, 64 bit > map[10]: type 1, range 64, base 00000000, size 14, memory disabled > map[18]: type 4, range 32, base 00000000, size 8, port disabled > pcib1: matched entry for 2.0.INTA > pcib1: slot 0 INTA hardwired to IRQ 16 > mskc0: irq 16 at device 0.0 on pci2 > pcib1: mskc0 requested unsupported memory range 0x0-0xffffffff (decoding > 0x0-0x0, 0x0-0x0) > mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > mskc0: Lazy allocation of 0x4 bytes rid 0x14 type 4 at 0x1000 > mskc0: unknown device: id=0xff, rev=0x0f > device_attach: mskc0 attach returned 6 The BIOS hasn't assigned resources for the PCI-PCI bridge and FreeBSD isn't smart enough to alloc resources from the parent for this case (this one should be solvable in FreeBSD w/o too much pain since it's a matter of allocating resources for the bus rather than extending an existing resource). As far as ath(4), if you fix this problem then ath(4) on ACPI will likely run into the HAL issue that it runs into with ACPI disabled. That is a separate problem. -- John Baldwin