Dell Optiplex 755 hangs every other boot before 82801 Family Hub Interface to PCI Bridge probed

[John Baldwin]

On Wednesday 19 March 2008 04:41:48 pm David Wolfskill wrote:
> On Wed, Mar 19, 2008 at 09:17:17AM -0400, John Baldwin wrote:
> > ...
> > Do a verbose boot.  It might be enumerating the PCI bus when it hangs or 
some 
> > such and a verbose boot would tell us more of where it is at when it 
hangs.  
> > Other than that, you'll have to add printfs to track down exactly where it 
> > hangs. :-/
> 
> OK; I switched it to boot (verbosely) from slice 4 (HEAD/CURRENT
> as of a couple weeks ago) -- figuring that there might be more
> "interesting" information available that way, then ran tip(1) within
> script(1) to capture the output.
> 
> I edited the typescript file in a couple of ways:
> 
> * I removed the ^M characters (saving about 2K in file size)
> * I split the file into "console_755-hang" and "console_755-nohang" to
>   make comparing the results of the experiments a bit easier.  In the
>   same spirit, I removed the beginning and ending script- and
>   tip-generated stuff that wasn't relevant.
> 
> I've attached both files.
> 
> The last bit of stuff in the "hang" case was:
> 
> usb6: USB revision 2.0
> uhub6: <Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb6
> uhub6: 6 ports with 6 removable, self powered
> pcib2: <ACPI PCI-PCI bridge> at device 30.0 on pci0
> pcib2:   domain            0
> pcib2:   secondary bus     2
> pcib2:   subordinate bus   2
> pcib2:   I/O decode        0xf000-0xfff
> pcib2:   no prefetched decode
> pcib2:   Subtractively decoded bridge.
> 
> 
> and in the "nohang" case, that bit was followed by:
> 
> pci2: <ACPI PCI bus> on pcib2
> pci2: domain=0, physical bus=2

Ok.  Please apply the patch below and report back which printfs you see.

> I note, too, that running diff(1) to compare the 2 files shows that the
> "nohang" case is missing some curious lines that show up in the "hang"
> case, e.g.:
> 
>  ioapic0: routing intpin 22 (PCI IRQ 22) to vector 53
>  ehci0: [GIANT-LOCKED]
>  ehci0: [ITHREAD]
> -usb2: waiting for BIOS to give up control
>  usb2: EHCI version 1.0
>  usb2: wrong number of companions (3 != 2)
>  usb2: companion controllers, 2 ports each: usb0 usb1
> ...
>  ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xff980800
>  ehci1: [GIANT-LOCKED]
>  ehci1: [ITHREAD]
> -usb6: waiting for BIOS to give up control
> -usb6: timed out waiting for BIOS
>  usb6: EHCI version 1.0
>  usb6: companion controllers, 2 ports each: usb3 usb4 usb5
>  usb6: <EHCI (generic) USB 2.0 controller> on ehci1

This is due to the ehci(4) boot time hangs fixed in the last commit to 
ehci_pci.c.  You can ignore it.

Index: acpi_pcib.c
===================================================================
RCS file: /usr/cvs/src/sys/dev/acpica/acpi_pcib.c,v
retrieving revision 1.60
diff -u -r1.60 acpi_pcib.c
--- acpi_pcib.c	3 Dec 2005 21:17:17 -0000	1.60
+++ acpi_pcib.c	21 Mar 2008 15:00:34 -0000
@@ -147,6 +147,7 @@
      * are several valid bridges in the field that do not have a _PRT, so
      * only warn about missing tables if bootverbose is set.
      */
+    device_printf(dev, "fetching _PRT\n");
     prt->Length = ACPI_ALLOCATE_BUFFER;
     status = AcpiGetIrqRoutingTable(acpi_get_handle(dev), prt);
     if (ACPI_FAILURE(status) && (bootverbose || status != AE_NOT_FOUND))
@@ -157,6 +158,7 @@
     /*
      * Attach the PCI bus proper.
      */
+    device_printf(dev, "adding pci bus child device\n");
     if ((child = device_add_child(dev, "pci", busno)) == NULL) {
 	device_printf(device_get_parent(dev), "couldn't attach pci bus\n");
 	return_VALUE(ENXIO);
@@ -165,8 +167,10 @@
     /*
      * Now go scan the bus.
      */
+    device_printf(dev, "force attaching PCI link devices found in _PRT\n");
     prt_walk_table(prt, prt_attach_devices, dev);
 
+    device_printf(dev, "attaching the PCI child bus device\n");
     return_VALUE (bus_generic_attach(dev));
 }
 

-- 
John Baldwin