Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Dec 2005 15:19:36 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        "Robert Faulds" <Robert.Faulds@voxify.com>
Cc:        freebsd-acpi@freebsd.org
Subject:   Re: Tyan Tiget S5351-i7322 hangs with ACPI (AMD64 or i386)
Message-ID:  <200512061519.36848.jhb@freebsd.org>
In-Reply-To: <331CA3AB8A236A488C92DEC289C7D04D016423FF@Deliverance.voxify.com>
References:  <331CA3AB8A236A488C92DEC289C7D04D016423FF@Deliverance.voxify.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 05 December 2005 11:00 pm, Robert Faulds wrote:
> What I did for these tests:
>
> installed 6.0-RELEASE/i386 (booted with with apic disabled)
> cd /usr/src; make kernel KERNCONF=SMP
> connect a serial console
> reboot
> at the boot menu I hit 6
> OK set console=comconsole
>
> Then disable apic:
> The dmesg is in
> http://xocolatl.com/rfaulds/freebsd-acpi/test2-SMP-dmesg-apic-disabled
> This boots ok.
>
> I repeat the same procedure but this time I disable acpi:
> http://xocolatl.com/rfaulds/freebsd-acpi/test2-SMP-dmesg-acpi-disabled
>
> This won't boot, but I left it for about 20 minutes and it printed the
> message that it had attached pass0 and da0. After an hour or so, it was
> still sitting complaining that "mpt1: Timedout requests already
> complete. Interrupts may not be functioning."
>
> I repeated these steps with an Adaptec 2130SLP controller and I get the
> same behavior.
>
> I also discovered the error I made originally WRT disabling APIC along
> with ACPI. Choosing option 2 from the boot menu (or setting
> hint.acpi.0.disabled=1 at the loader prompt) of amd64 6.0-REL also
> disables APIC. I do not know why but it turned out to be a feature in my
> case.

Well, option 2 does disable APIC.  The acpi hint alone does not.  So, it seems 
that you have problems if you use APIC, and don't have problems if you 
disable APIC, and ACPI has no real bearing.  It sounds like perhaps your BIOS 
is not giving us the right information about how the interrupts are 
connected.  Have you tried plugging the devices into mpt0 rather than mpt1 
btw?  As it is, you can try to override your BIOS to set the IRQ for mpt1 
manually to try to figure out what IRQ it is really routed to.  (If there is 
a BIOS update that might also fix this problem.)  I'd try IRQs 24-47 (on your 
second ioapic) first.  You can try an IRQ by setting this in the loader 
before boot (this would use IRQ 24 for mpt1):

hw.pci3.3.INTB.irq=24

-- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200512061519.36848.jhb>