Date: Wed, 20 Mar 2002 13:05:21 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Doug Rabson <dfr@nlsystems.com> Cc: Mike Smith <msmith@FreeBSD.org>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: RE: cvs commit: src/sys/contrib/dev/acpica - Imported sources Message-ID: <XFMail.20020320130521.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.33.0203201612360.16239-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 20-Mar-2002 Doug Rabson wrote:
> On Wed, 20 Mar 2002, John Baldwin wrote:
>
>>
>> On 20-Mar-2002 Doug Rabson wrote:
>> > On Tue, 19 Mar 2002, John Baldwin wrote:
>> >
>> >>
>> >> On 16-Mar-2002 Mike Smith wrote:
>> >> > msmith 2002/03/15 18:18:15 PST
>> >> >
>> >> > src/sys/contrib/dev/acpica - Imported sources
>> >> > Update of /home/ncvs/src/sys/contrib/dev/acpica
>> >> > In directory freefall.freebsd.org:/d/home/msmith/acpi_ca_destination
>> >> >
>> >> > Log Message:
>> >> > Import of the 20020308 Intel ACPI CA update.
>> >>
>> >> Still doesn't work for a machine with multiple PCI busses as reported
>> >> earlier
>> >> on the ACPI list:
>> >>
>> >> pci0: <display, VGA> at device 12.0 (no driver attached)
>> >> acpi_pcib1: <Host-PCI bridge> on acpi0
>> >
>> > It does at least partly work with multiple host-pci bridges since this
>> > ia64 box has about four (!). Something "special" about your machine?
>>
>> Not sure. My guess is that since %bp is getting zero'd and since it is
>> saved
>> on the stack just above local variables on the i386, there is a buffer
>> overflow
>> in the ACPI code somewhere that is trashing the stack. :(
>
> Oops. Unfortunately I don't have an i386 machine with more than one host
> birdge to look at it with.
Well, it blows up with a hosed frame pointer here:
(kgdb) l *acpi_pcib_attach+0x1c0
0xc015aec4 is in acpi_pcib_attach (../../../dev/acpica/acpi_pcib.c:208).
205 /*
206 * Attach the PCI bus proper.
207 */
208 if ((child = device_add_child(dev, "pci", sc->ap_bus)) == NULL) {
209 device_printf(device_get_parent(dev), "couldn't attach pci
bus");
Just before this is:
/*
* Get the PCI interrupt routing table for this bus.
*/
sc->ap_prt.Length = ACPI_ALLOCATE_BUFFER;
if (ACPI_FAILURE(status = AcpiGetIrqRoutingTable(sc->ap_handle, &sc->ap_prt)
)) {
device_printf(dev, "could not get PCI interrupt routing table - %s\n", A
cpiFormatException(status));
/* this is not an error, but it may reduce functionality */
}
Thus, the likely candidate is AcpiGetIrqRoutingTable().
The only changes in the last import were to use AcpiUtValidateBuffer() rather
than testing the result buffer to see if it was null. I don't see how that
function could be a problem though. Hmm, looking at AcpiGetPrtMethodData(), it
seems that the code changed to no longer check that the destination buffer was
long enough assuming that the caller does that. Except that
AcpiUtBufferValidate() doesn't do that AFAICT, so now nothing checks to see if
the buffer is long enough. I'll play around with reverting part of that and
see if it works ok. FWIW, here's the _PRT for the PCI busses in this machine:
Err, actually, it's a bit long, so only if someone asks for it. :)
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020320130521.jhb>