Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Dec 2005 16:16:10 -0800
From:      "Robert Faulds" <Robert.Faulds@voxify.com>
To:        "Nate Lawson" <nate@root.org>
Cc:        freebsd-acpi@freebsd.org
Subject:   RE: Tyan Tiget S5351-i7322 hangs with ACPI (AMD64 or i386)
Message-ID:  <331CA3AB8A236A488C92DEC289C7D04D016425D7@Deliverance.voxify.com>

next in thread | raw e-mail | index | archive | help
-----Original Message-----
From: Nate Lawson [mailto:nate@root.org]=20
Sent: Tuesday, December 06, 2005 3:10 PM
To: Robert Faulds
Cc: John Baldwin; freebsd-acpi@freebsd.org
Subject: Re: Tyan Tiget S5351-i7322 hangs with ACPI (AMD64 or i386)

Robert Faulds wrote:
>>From: John Baldwin [mailto:jhb@freebsd.org]
>>Sent: Tuesday, December 06, 2005 12:20 PM
>>To: Robert Faulds
>>Cc: freebsd-acpi@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,
>=20
> it seems
> =20
>=20
>>that you have problems if you use APIC, and don't have problems if you
>=20
>=20
>>disable APIC, and ACPI has no real bearing.  It sounds like perhaps
>=20
> your BIOS
>=20
>>is not giving us the right information about how the interrupts are=20
>>connected.  Have you tried plugging the devices into mpt0 rather than
>=20
> mpt1
>=20
>>btw?  As it is, you can try to override your BIOS to set the IRQ for
>=20
> mpt1=20
>=20
>>manually to try to figure out what IRQ it is really routed to.  (If
>=20
> there is
>=20
>>a BIOS update that might also fix this problem.)  I'd try IRQs 24-47
>=20
> (on your
>=20
>>second ioapic) first.  You can try an IRQ by setting this in the
>=20
> loader
>=20
>>before boot (this would use IRQ 24 for mpt1):
>>
>>hw.pci3.3.INTB.irq=3D24
>>
>=20
>=20
>=20
> 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.
>=20
> 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=20
> 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



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