i386/89545: Compaq DL 360 ACPI boot problem
John Baldwin
jhb at freebsd.org
Wed Jan 4 10:15:08 PST 2006
On Wednesday 04 January 2006 11:40 am, Anders Nordby wrote:
> The following reply was made to PR i386/89545; it has been noted by GNATS.
>
> From: Anders Nordby <anders at FreeBSD.org>
> To: John Baldwin <jhb at freebsd.org>
> Cc: bug-followup at freebsd.org, uralmetal at gmail.com
> Subject: Re: i386/89545: Compaq DL 360 ACPI boot problem
> Date: Wed, 4 Jan 2006 17:36:21 +0100
>
> --ikeVEW9yuYc//A+q
> Content-Type: text/plain; charset=iso-8859-1
> Content-Disposition: inline
> Content-Transfer-Encoding: 8bit
>
> Hi,
>
> On Tue, Jan 03, 2006 at 05:06:26PM -0500, John Baldwin wrote:
> > It does reference 'FAKE' in one of the _PRT entries sadly. You can try
> > removing it and compiling a custom dsdt to work around it. You could
> > also beat up Compaq for the crap BIOS. Do these machines have APICs on
> > them? They'd probably be a lot happier with APIC enabled if so.
> >
> > Package (0x04)
> > {
> > 0x0004FFFF,
> > 0x00,
> > FAKE,
> > 0x00
> > },
>
> I removed the section above, but if fails to compile:
>
> root at anderstest:~# iasl anderstest.asl-fixed
>
> Intel ACPI Component Architecture
> ASL Optimizing Compiler / AML Disassembler version 20041119 [Dec 31
> 2005]
> Copyright (C) 2000 - 2004 Intel Corporation
> Supports ACPI Specification Revision 2.0c
>
> Non-ASCII character: 0xD2 at offset 0xBB
> Non-ASCII character: 0xD2 at offset 0x189
> Non-ASCII character: 0xD2 at offset 0x7B3
> 3 non-ASCII characters found in input file, appears to be binary
> Error 1082 - Invalid characters found in file anderstest.asl-fixed
>
> In the ASL, there is 0xD2 which is ز, used for Creator ID in the RSDT,
> FACP and SPCR sections. I changed that to just ASL like it looks like on
> my Dell laptop (Creator ID=ASL). Then I can compile. Booting with the
> custom dsdt, I get a page fault. Log attached.
>
> I will check to see if I can change anything useful in the BIOS
> tomorrow, but I doubt it. :-/
Hmm, ok. I'd really need to know what source file:line that page fault maps
to (you can use gdb to find that if you have a kernel.debug). OTOH, you can
also try this patch which just prints a warning for bogus _PRT entries when
we bump reference counts and only panics if we actually try to route an
interrupt via the busted link device. You can try this w/o the custom DSDT.
Index: acpi_pci_link.c
===================================================================
RCS file: /usr/cvs/src/sys/dev/acpica/acpi_pci_link.c,v
retrieving revision 1.51
diff -u -r1.51 acpi_pci_link.c
--- acpi_pci_link.c 5 Dec 2005 19:50:00 -0000 1.51
+++ acpi_pci_link.c 4 Jan 2006 18:07:17 -0000
@@ -625,8 +625,11 @@
/* Bump the reference count. */
ACPI_SERIAL_BEGIN(pci_link);
link = acpi_pci_link_lookup(dev, index);
- if (link == NULL)
- panic("%s: apparently invalid index %d", __func__, index);
+ if (link == NULL) {
+ device_printf(dev, "apparently invalid index %d\n", index);
+ ACPI_SERIAL_END(pci_link);
+ return;
+ }
link->l_references++;
if (link->l_routed)
pci_link_interrupt_weights[link->l_irq]++;
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x1c
> fault code = supervisor read, page not present
> instruction pointer = 0x20:0xc0a6d69d
Do a 'l *0xc0a6d69d' in 'gdb kernel.debug' if you can to see what this
corresponds to.
--
John Baldwin <jhb at FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
More information about the freebsd-acpi
mailing list