Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 07 Jan 2005 19:32:46 +0100
From:      Pawel Worach <pawel.worach@telia.com>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        Nate Lawson <nate@root.org>
Subject:   Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt
Message-ID:  <41DED5CE.2080005@telia.com>
In-Reply-To: <200501071101.02518.jhb@FreeBSD.org>
References:  <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <41DDBA4F.6010009@root.org> <41DDC941.9000609@telia.com> <200501071101.02518.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
> On Thursday 06 January 2005 06:26 pm, Pawel Worach wrote:
> 
>>Nate Lawson wrote:
>>
>>>A possible fix is to change each reference to LP* in the PICM and APIC
>>>packages to be \LPUS, \LP05, etc.  Then recompile and load your asl via
>>>the instructions for overriding it in acpi(4).
>>>
>>>I'm still not sure why this is broken though so I think it's a red
>>>herring and suspect the asl fix won't help.  I suspect the real reason
>>>is that \LPUS is not probed/attached before calling pci_add_child() on
>>>PCI0.  Pawel, can you stick a printf in acpi_pci_link_attach() right
>>>before the return (0) like this:
>>>
>>>printf("pci link attached: %s\n", acpi_name(acpi_get_handle(dev)));
>>>
>>>I suspect we won't see LPUS there before it panics.
>>
>>I do not even see the code enter acpi_pci_link_attach(), even added a dummy
>>printf at the top of the method.
> 
> 
> This is because the references don't work during the force-attach either 
> (which happens before pci_add_child() as I explained to Nate in my earlier 
> e-mail).
> 
> 
>>I modified the AML, changed all LP* to \LP* (except for the Device(LP*)
>>ones, should I change these too?) the result was a couple of errors during
>>boot. I broke something didn't I?
>>
>>can't fetch resources for \_SB_.PCI0 - AE_AML_INVALID_RESOURCE_TYPE
>>can't fetch resources for \_SB_.PCI0.ISA_.SIOM - AE_AML_NO_RESOURCE_END_TAG
>>can't fetch resources for \_SB_.PCI0.ISA_.PS2M - AE_AML_NO_RESOURCE_END_TAG
>>can't fetch resources for \_SB_.PCI0.ISA_.FDC0 - AE_AML_NO_RESOURCE_END_TAG
>>can't fetch resources for \_SB_.PCI0.ISA_.COM1 - AE_AML_NO_RESOURCE_END_TAG
>>can't fetch resources for \_SB_.PCI1 - AE_AML_INVALID_RESOURCE_TYPE
>>can't fetch resources for \_SB_.PCI2 - AE_AML_INVALID_RESOURCE_TYPE
>>can't fetch resources for \_SB_.PCI3 - AE_AML_INVALID_RESOURCE_TYPE
>>can't fetch resources for \_SB_.PCI4 - AE_AML_INVALID_RESOURCE_TYPE
>>..
>>Fatal trap 12: page fault while in kernel mode
>>[same old story]
>>...
> 
> 
> Only change the LPxx entries in the _PRT tables.  Specifically, find the PICM 
> package and change their entries.  Something like this:

[snip patch]

Yep, that was what I did which resulted in the errors above. I see now that
something else is wrong.
# acpidump -o cookie.aml
# iasl -d cookie.aml
# iasl cookie.dsl

If I now try to boot the DSDT.aml without changing the asl/dsl (damn this acpi
terminology is confusing) I get the same errors as above. Is this a problem with
the iasl compiler? I only get one warning when compiling the asl which seems 
unrelated.

Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20041119 [Dec  8 2004]
Copyright (C) 2000 - 2004 Intel Corporation
Supports ACPI Specification Revision 2.0c

ibm-x345.dsl  1796:     Method (\_WAK, 1, NotSerialized)
Warning  2026 -                     ^ Reserved method must return a value (_WAK)

ASL Input:  ibm-x345.dsl - 4859 lines, 134299 bytes, 2522 keywords
AML Output: DSDT.aml - 18410 bytes 739 named objects 1783 executable opcodes

Compilation complete. 0 Errors, 1 Warnings, 0 Remarks, 461 Optimizations

[ should we move this to acpi@? ]

-- 
Pawel



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