Date: Thu, 13 Mar 2008 12:50:02 GMT From: Leon Kos <leon.kos@lecad.uni-lj.si> To: freebsd-acpi@FreeBSD.org Subject: Re: kern/121558: Supermicro X7SB4 Fatal trap 12 when ACPI disabled Message-ID: <200803131250.m2DCo2W5068752@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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: 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 13:44:49 +0100 (CET)
From sys/dev/pci/pci.c I see that syntax in pci_assign_interrupt() for
7.0-STABLE is different that one provided:
/* Let the user override the IRQ with a tunable. */
irq = PCI_INVALID_IRQ;
snprintf(tunable_name, sizeof(tunable_name),
"hw.pci%d.%d.%d.INT%c.irq",
cfg->domain, cfg->bus, cfg->slot, cfg->intpin + 'A' - 1);
if (TUNABLE_INT_FETCH(tunable_name, &irq) && (irq >= 255 || irq <= 0))
irq = PCI_INVALID_IRQ;
This is the reason for hints not getting fetched. How should I change hints
to?
For linux logs and not seeing ethernet cards, it is shown in
http://www.lecad.uni-lj.si/~leon/other/x7sb4/img_1652.jpg
that ethernet devices are not configured and that dmesg outputs just 3
lines. Maybe this is the reason for a bootable linux in any case.
Suggestion that EHCI is a case for rebooting problems was correct.
I have disabled USB on the motherboard and now it reboots! It is in my
nature to disable things that I do not need, but after BIOS upgrade and
consequent BIOS reset to defaults I've overlooked this. So, I am taking back
my statement that reboot worked in 6.3-STABLE and not working in 7.0-STABLE.
It was just that I've had disabled USB previously and forgot to re-disable
it for 7.0.
But we can say that Supermicro X7SB4 board has broken EHCI controller.
Not mentioning troubles with onboard AIC7901 Ultra320 SCSI adapter
that spills out bunch of "Invalid Sequencer interrupt occurred" when trying
to run full speed.
Leon Kos, CAD lab, Mech.Eng., University of Ljubljana, Slovenia
(http://www.lecad.uni-lj.si/~leon)
On Thu, 13 Mar 2008, John Baldwin wrote:
> 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?200803131250.m2DCo2W5068752>