Date: Thu, 20 Jun 2002 18:30:04 -0700 (PDT) From: Nick Colakovic <nickc@CORP.FirstIndustrial.com> To: freebsd-bugs@FreeBSD.org Subject: RE: kern/39447: 4.5R &4.6R Kernels fail to boot w/ AHA2940U2W att ached to an IFT-3102 controller (in less than 10 minutes) Message-ID: <200206210130.g5L1U4718054@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/39447; it has been noted by GNATS. From: Nick Colakovic <nickc@CORP.FirstIndustrial.com> To: "'Justin T. Gibbs'" <gibbs@scsiguy.com> Cc: "'freebsd-gnats-submit@FreeBSD.org'" <freebsd-gnats-submit@FreeBSD.org> Subject: RE: kern/39447: 4.5R &4.6R Kernels fail to boot w/ AHA2940U2W att ached to an IFT-3102 controller (in less than 10 minutes) Date: Thu, 20 Jun 2002 20:20:08 -0500 I think I have been able to isolate the issue. If the IFT-3102 is set with it "Peripheral Device Type" parameter set to "0x1f" the 4.6R kernel is delayed in booting by about 10 minutes in my environment. This seems to be because the ahc driver seems to be scanning the pseudo devices the controller presents to its hosts to allow inband controller management and monitoring. Without looking the ahc sources I assume the driver paces the scan of these devices in such a way to cause a fairly long boot delay. If I set the "Peripheral Device Type" parameter to the default of "0x7f" (No Device Present according to the manual) the kernel boots normally. The setting of 0x1f is required if the managing system attached to the controller is running Windows NT 4.0. So is appears the problem can be classified as an environment specific bug or problem (depending on your point of view) when running a mix of OSes on the same IFT-3102 controller. Loss of GUI management of the controller is not a problem because I typically manage it from it serial interface anyhow. Of course patience on my part might have isolated the problem earlier. I will recompile sources on both affected systems and confirm that this 0x7f solution actually works. Thanks for the assistance and recommendations. -NRC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206210130.g5L1U4718054>