From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 28 20:30:59 2005 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 BBD3816A41F for ; Mon, 28 Nov 2005 20:30:59 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id C32E643D46 for ; Mon, 28 Nov 2005 20:30:50 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 2753120 for multiple; Mon, 28 Nov 2005 15:30:48 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jASKUWEa062288; Mon, 28 Nov 2005 15:30:33 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: George Mitchell Date: Mon, 28 Nov 2005 13:09:41 -0500 User-Agent: KMail/1.8.2 References: <200511281733.jASHXuSR015008@m5p.com> In-Reply-To: <200511281733.jASHXuSR015008@m5p.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511281309.42200.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-acpi@freebsd.org Subject: Re: ACPI + FIC VA-503+ = non-working fdc 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, 28 Nov 2005 20:30:59 -0000 On Monday 28 November 2005 12:33 pm, George Mitchell wrote: > > On Saturday 26 November 2005 02:18 pm, george+freebsd@m5p.com wrote: > > > On a FIC VA-503+ motherboard, ACPI does not play nice with the floppy > > > disk controller. In all versions of 5.x, and now 6.0, it cannot talk > > > to the fdc when ACPI is enabled. In 6.0-RELEASE, the message I get > > > if "No FDOUT register!". It works fine with ACPI disabled, and perhaps > > > I should just stick with that ... > > > > Can you post the fdc0 lines from both dmesg's to see what the resources > > look like? Sounds like a bug in your BIOS. > > http://www.m5p.com/~george/dmesg-6.0-no-acpi-verbose.txt > http://www.m5p.com/~george/dmesg-6.0-acpi-verbose.txt Note these messages: ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.ISA_.FDC0._CRS] (Node 0xc1e89540), AE_AML_BUFFER_LIMIT ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.ISA_.FDC0._CRS] (Node 0xc1e89540), AE_AML_BUFFER_LIMIT can't fetch resources for \\_SB_.PCI0.ISA_.FDC0 - AE_AML_BUFFER_LIMIT FDC0 is your floppy drive controller, and your BIOS is busted and doesn't return valid information in the ACPI tables to tell us which I/O ports, etc. to use, so that's why your floppy drive doesn't work with ACPI. You might be able to fix it by patching your ASL. > > > Also, in 6.0-RELEASE, enabling ACPI seems to cause the re driver to > > > get watchdog timeouts ... > > > > Are any of the IRQs different with ACPI enabled vs ACPI disabled? Also, > > do you get these times with ACPI enabled on 5.x? > > See above for 6.0. ACPI had enough other problems on 5.0 that I never > ran with it enabled, except a couple of times when I saw that the floppy > controller wasn't working. Thanks for your attention. -- George > > P.S. I got these dumps with 6.0-RC1, but the messages are the same with > 6.0-RELEASE. Well, the IRQs are the same for both. However, it is quite weird. With ACPI, we see from your BIOS that your ppc0 device is using IRQ 5, and several PCI devices are using IRQ 7 (include re0). Without ACPI, both the printer and the PCI devices end up using IRQ 7 (this should _not_ happen). Try removing the hints for ppc0 so it is probed by the PNP BIOS rather than via hints and see if the IRQ moves from 7 to 5 for your non-ACPI case. Then, check to see if you get the same timeout issues. You can also try going into your BIOS and changing the LPT settings to use IRQ 7 rather than IRQ 5 as IRQ 7 is more "standard". -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org