kern/154432: [xpt] run_interrupt_driven_hooks: still waiting after 60-300 seconds for xpt_config

[Jason Wolfe]

The following reply was made to PR kern/154432; it has been noted by GNATS.

From: Jason Wolfe <nitroboost at gmail.com>
To: bug-followup at FreeBSD.org
Cc:  
Subject: Re: kern/154432: [xpt] run_interrupt_driven_hooks: still waiting
 after 60-300 seconds for xpt_config
Date: Mon, 14 Nov 2011 12:36:37 -0700

 --f46d044468d3369bc304b1b6fd26
 Content-Type: text/plain; charset=ISO-8859-1
 
 This is happening to me also on a Supermicro X8DTT-H chasis with an LSI2008
 SAS2 controller and 12 drives on 8.2-RELEASE-p4 with the mps driver from
 STABLE.
 
 mps0 at pci0:4:0:0:        class=0x010700 card=0x040015d9 chip=0x00721000
 rev=0x02 hdr=0x00
     vendor     = 'LSI Logic (Was: Symbios Logic, NCR)'
     class      = mass storage
     subclass   = SAS
 
 Though the dmesg output is indentical, my problem is a bit different as the
 300 second timeout passes, but it still in some cases takes the server 24+
 _hours_ to finally continue booting.  It hangs after the 300 second message
 until the time it manages to continue booting, and then all messages appear
 as normal.  The cause of this is surely drives stuck in a transient state
 that makes them still look alive to the kernel.  When the drive is popped
 out the server boots immediately.  300 seconds to wait for a drive that you
 think might be alive does seem a bit high, but I would even be happy if
 even that was being honored in my case.  This is an issue across a large
 pool of servers and I have seen the behavior on ~20 different machines from
 different batches of chasis and drives in unique locations.
 
 --f46d044468d3369bc304b1b6fd26
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 This is happening to me also on a Supermicro X8DTT-H chasis with an LSI2008=
  SAS2 controller and 12 drives on 8.2-RELEASE-p4 with the mps driver from S=
 TABLE.<br><br>mps0 at pci0:4:0:0:=A0=A0=A0=A0=A0=A0=A0 class=3D0x010700 card=
 =3D0x040015d9 chip=3D0x00721000 rev=3D0x02 hdr=3D0x00<br>
 =A0=A0=A0 vendor=A0=A0=A0=A0 =3D &#39;LSI Logic (Was: Symbios Logic, NCR)&#=
 39;<br>=A0=A0=A0 class=A0=A0=A0=A0=A0 =3D mass storage<br>=A0=A0=A0 subclas=
 s=A0=A0 =3D SAS<br><br>Though the dmesg output is indentical, my problem is=
  a bit different as the 300 second timeout passes, but it still in some cas=
 es takes the server 24+ _hours_ to finally continue booting.=A0 It hangs af=
 ter the 300 second message until the time it manages to continue booting, a=
 nd then all messages appear as normal.=A0 The cause of this is surely drive=
 s stuck in a transient state that makes them still look alive to the kernel=
 .=A0 When the drive is popped out the server boots immediately.=A0 300 seco=
 nds to wait for a drive that you think might be alive does seem a bit high,=
  but I would even be happy if even that was being honored in my case.=A0 Th=
 is is an issue across a large pool of servers and I have seen the behavior =
 on ~20 different machines from different batches of chasis and drives in un=
 ique locations.<br>
 
 --f46d044468d3369bc304b1b6fd26--