Date: Fri, 21 Jun 2002 04:40:03 -0700 (PDT) From: "Justin T. Gibbs" <gibbs@scsiguy.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: <200206211140.g5LBe3C54461@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: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Nick Colakovic <nickc@CORP.FirstIndustrial.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: Fri, 21 Jun 2002 05:33:24 -0600 >> BTW, if you are using the quirk even though your controller supports >> sync cache, you are removing a very important operation that ensures >> that your data remains valid across a power cycle. > >The controller has a NiMH battery designed to store cache information for a >week without power. Using sync cache is should be irrelevant with the >battery cache. In addition I disable APM in my kernel configs so the system >is not powering down at shutdown or reboot. Until you decide to change out the battery because it has failed its last reconditioning - or you ship the box to a trade show only to find that the batter is dead and your FS trashed. They don't call it batter "backup" for nothing. >I stand corrected after 10 minutes or so the kernel did boot. ... >ahc0: target 0 synchronous at 40.0MHz, offset = 0x1f >(probe0:ahc0:0:0:7): Vendor Specific Command. CDB: 1a e0 a 0 14 0 >(probe0:ahc0:0:0:7): NOT READY asc:4,0 >(probe0:ahc0:0:0:7): Logical unit not ready, cause not reportable ... Again, this has absolutly nothing to do with the ahc driver. Think of the ahc driver as a "conduit" for SCSI commands. The ahc driver doesn't build commands or even understand what they mean. It just delivers them to the device and reports the result. In this case, the infotrend is reporting "not ready" to a perfectly valid command CAM issues during the probing of devices. If you hand't compiled your kernel without cdb strings, the above message would indicate a standard MODE_SENSE_6 (CAM is trying to determine if tag queueing has been disabled in a mode page). Anyway, "LUN not ready" type errors are usually transient. CAM is waiting for this error to go away. CAM eventually gives up to the tune of aproximately 1 minute for each LUN that reports this error. When you change the peripheral type to 0x7F, CAM ignores the device, since 0x7F in the inquiry response means "device not present". Perhaps you should ask Infotrend why they constantly give not ready status for these devices. -- Justin 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?200206211140.g5LBe3C54461>