From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 13 11:39:57 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B01E106566B for ; Thu, 13 Mar 2008 11:39:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 798A58FC16 for ; Thu, 13 Mar 2008 11:39:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id 5F7711A4D7C; Thu, 13 Mar 2008 04:39:01 -0700 (PDT) From: John Baldwin To: freebsd-acpi@freebsd.org, Leon Kos Date: Thu, 13 Mar 2008 07:17:16 -0400 User-Agent: KMail/1.9.7 References: <200803131010.m2DAA2V0052515@freefall.freebsd.org> In-Reply-To: <200803131010.m2DAA2V0052515@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803130717.17071.jhb@freebsd.org> Cc: Subject: Re: kern/121558: Supermicro X7SB4 Fatal trap 12 when ACPI disabled 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: Thu, 13 Mar 2008 11:39:57 -0000 On Thursday 13 March 2008 06:10:02 am Leon Kos wrote: > The following reply was made to PR kern/121558; it has been noted by GNATS. > > From: Leon Kos > To: John Baldwin > Cc: Volker , freebsd-acpi@freebsd.org, > bug-followup@freebsd.org > Subject: Re: kern/121558: Supermicro X7SB4 Fatal trap 12 when ACPI disabled > Date: Thu, 13 Mar 2008 11:07:41 +0100 (CET) > > Previously I've added hints to /boot/loader.conf and booted GENERIC with > ACPI disabled. Moving hints to /boot/device.hints does not help! > That's why I've asked if the syntax: > hw.pci13.0.INTA.irq="16" > hw.pci15.0.INTA.irq="17" > hw.pci5.0.INTA.irq="19" > is correct? Yes. The code looks like this: /* Let the user override the IRQ with a tunable. */ irq = PCI_INVALID_IRQ; snprintf(tunable_name, sizeof(tunable_name), "hw.pci%d.%d.INT%c.irq", cfg->bus, cfg->slot, cfg->intpin + 'A' - 1); if (TUNABLE_INT_FETCH(tunable_name, &irq) && (irq >= 255 || irq <= 0)) irq = PCI_INVALID_IRQ; /* * If we didn't get an IRQ via the tunable, then we either use the * IRQ value in the intline register or we ask the bus to route an * interrupt for us. If force_route is true, then we only use the * value in the intline register if the bus was unable to assign an * IRQ. */ if (!PCI_INTERRUPT_VALID(irq)) { if (!PCI_INTERRUPT_VALID(cfg->intline) || force_route) irq = PCI_ASSIGN_INTERRUPT(bus, dev); if (!PCI_INTERRUPT_VALID(irq)) irq = cfg->intline; } The PCI_ASSIGN_INTERRUPT routine is the one that ends up invoking the mptable_pci_route_interrupt() function. > I am still getting "No I/O APIC 0 to route interrupt to" as shown in > http://www.lecad.uni-lj.si/~leon/other/x7sb4/img_1650.jpg I would add printfs to the code above to make sure the tunable is being triggered. > I've also tried to boot OpenSUSE 10.3 that has kernel 2.6.21.5-31 and it > boots with or without ACPI. > http://www.lecad.uni-lj.si/~leon/other/x7sb4/img_1651.jpg shows dmesg and > /proc/interrupts with acpi=off > http://www.lecad.uni-lj.si/~leon/other/x7sb4/img_1652.jpg is the same with > enabled ACPI (default) Neither of the /proc/interrupts show the eth devices for any of the IRQs. Perhaps it is just not setting up interrupts at all for the eth devices in this case? You would need the dmesg lines for the actual eth devices to see what IRQs they are using. > Linux appears to work well with this board. Even handles reboot well while > FreeBSD 7.0 after upgrade does not as I staded before and shown in photo > http://www.lecad.uni-lj.si/~leon/other/x7sb4/img_1637.jpg You can debug why it hangs, but you will need to do some work to figure it out. I would start by adding printfs around the 'device_shutdown()' of root_bus in sys/kern/subr_bus.c as well as printfs for in bus_generic_shutdown() of each device name before invoking its shutdown routine to see if it hangs on a device driver's shutdown routine. I committed a hang on reboot fix yesterday to HEAD involving some busted BIOSes handling of ehci(4) controllers. -- John Baldwin