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