Date: Wed, 30 Apr 2014 22:55:41 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: jhb@FreeBSD.org Cc: stable@FreeBSD.org Subject: Re: Thinkpad R60 hangs when booting recent 8.4-STABLE Message-ID: <201405010555.s415tfL6034493@gw.catspoiler.org> In-Reply-To: <201404301738.26632.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201405010555.s415tfL6034493>