Thinkpad R60 hangs when booting recent 8.4-STABLE

[John Baldwin]

On Thursday, May 01, 2014 1:55:41 am Don Lewis wrote:
> On 30 Apr, John Baldwin wrote:
> 
> > Are you up for doing some printf sleuthing?  There are two odd things that I 
> > see so far:
> > 
> > 1) the base address of 0.  The question here is if pci_add_map() in 
> > sys/dev/pci/pci.c decides to set start to 0 explicitly, or if it happens 
> > further up the callchain (should be bus_alloc_resource calls in 
> > sys/dev/acpica/acpi_pcib_acpi.c, sys/x86/x86/nexus.c and then in the
> > rman code itself in sys/kern/subr_rman.c)
> > 
> > 2) The 'reserved' printfs during boot probe.  Those come from a printf in 
> > pci_alloc_resource() in sys/dev/pci/pci.c.  However, that should not be called 
> > until a driver attaches to a device and calls bus_alloc_resource().  It should 
> > not be called from pci_add_child() as it seems to be now.
> 
> The call graph for the four earlier ones that you previously pointed
> out (not hostb0) is:
> 	pci_add_child()
> 		pci_add_resources()
> 			*_early_takeover()
> 				[I suspect]
> 				bus_alloc_resource_any()
> 					pci_alloc_resource()
> 					
> These are the three system uhci controllers and the system ehci
> controller, which apparently pass this test:
> 	pci_get_class(dev) == PCIC_SERIALBUS &&
> 	pci_get_subclass(dev) == PCIS_SERIALBUS_USB

Oh, ok.  That is fine, and that explains why it was selective in the past (and
only for I/O resources).  That just leaves 1) then.  It would be especially good
to know what pci_add_map() does when it sees this BAR during the bus probe.

-- 
John Baldwin