kern/121558: Supermicro X7SB4 Fatal trap 12 when ACPI disabled

John Baldwin jhb at
Thu Mar 13 11:39:57 UTC 2008

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 at>
> To: John Baldwin <jhb at>
> Cc: Volker <volker at>, freebsd-acpi at,
>         bug-followup at
> 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?


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

I would add printfs to the code above to make sure the tunable is being 

>  I've also tried to boot OpenSUSE 10.3 that has kernel and it
>  boots with or without ACPI.
> shows dmesg and
>  /proc/interrupts with acpi=off
> 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

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

More information about the freebsd-acpi mailing list