Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 06 Jan 2005 23:15:06 -0800
From:      Nate Lawson <nate@root.org>
To:        Pawel Worach <pawel.worach@telia.com>
Cc:        John Baldwin <jhb@FreeBSD.org>
Subject:   Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt
Message-ID:  <41DE36FA.6070805@root.org>
In-Reply-To: <41DDC941.9000609@telia.com>
References:  <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <200501061345.44146.jhb@FreeBSD.org> <41DD9806.6060301@telia.com> <200501061541.39673.jhb@FreeBSD.org> <41DDBA4F.6010009@root.org> <41DDC941.9000609@telia.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

That's a problem.  If the link isn't attached, you can't route 
interrupts by it.  Try adding this to  the if statemetns in 
sys/dev/acpica/acpi.c:acpi_probe_order() --

     /* attach pci links early */
     } else if (acpi_MatchHid(handle, "PNP0C0F")) {
	*order = 3;
	ret = 1;
     }

-- 
Nate



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