Date: Thu, 13 Mar 2008 07:17:16 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-acpi@freebsd.org, Leon Kos <leon.kos@lecad.uni-lj.si> Subject: Re: kern/121558: Supermicro X7SB4 Fatal trap 12 when ACPI disabled Message-ID: <200803130717.17071.jhb@freebsd.org> In-Reply-To: <200803131010.m2DAA2V0052515@freefall.freebsd.org> References: <200803131010.m2DAA2V0052515@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <leon.kos@lecad.uni-lj.si> > To: John Baldwin <jhb@freebsd.org> > Cc: Volker <volker@vwsoft.com>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200803130717.17071.jhb>