Tyan Tiget S5351-i7322 hangs with ACPI (AMD64 or i386)
Robert Faulds
Robert.Faulds at voxify.com
Tue Dec 6 16:16:13 PST 2005
-----Original Message-----
From: Nate Lawson [mailto:nate at root.org]
Sent: Tuesday, December 06, 2005 3:10 PM
To: Robert Faulds
Cc: John Baldwin; freebsd-acpi at freebsd.org
Subject: Re: Tyan Tiget S5351-i7322 hangs with ACPI (AMD64 or i386)
Robert Faulds wrote:
>>From: John Baldwin [mailto:jhb at freebsd.org]
>>Sent: Tuesday, December 06, 2005 12:20 PM
>>To: Robert Faulds
>>Cc: freebsd-acpi at freebsd.org
>>Subject: Re: Tyan Tiget S5351-i7322 hangs with ACPI (AMD64 or i386)
>>
>>
>>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
>>
>
>
>
> Thanks. I had started doing that with no luck. Unfortunately, I'm at
the
> latest BIOS Tyan offers and it has no provision for forcing
interrupts.
> I had moved the disks to channel 2 because I had an older CDROM on the
> first (external connector) and thought it might be a conflict (SCSI3
vs
> SCSI1). No luck there either.
>
> At this point I believe the most efficient use of my time will be to
> ship these all back and get them replaced with something a bit more
> compliant.
> Wait, before you do that, try setting the hint John suggested or
moving
> the drives to mpt0. We need to work around this at least for other
users.
Sure... I did try that although not for the entire range. I got too
bored. This thing takes several minutes to POST and boot and I'm
crunched with other work.
I tried stepping through IRQ's from 24-30, and from 9-15, with drives on
both channels and with no drives connected, with no luck. I tried
setting INTA and INTB to different values in that range based off the
earlier probes and successes, and even a few of the failures, as
reported at the logs I posted earlier.
http://xocolatl.com/rfaulds/freebsd-acpi/
I'm willing to try anything you want to test. I'll hang on to one or two
of these boxes to use them to debug this. The other 6 need to go back to
be replaced so I can put something into service doing real work soon.
Let me know how I can help,
Robert
More information about the freebsd-acpi
mailing list