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>