Date: Thu, 20 Jun 2002 16:48:01 -0600 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Nick Colakovic <nickc@CORP.FirstIndustrial.com> Cc: 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 Message-ID: <200206202248.g5KMm1938462@aslan.scsiguy.com> In-Reply-To: Your message of "Thu, 20 Jun 2002 12:30:03 PDT." <200206201930.g5KJU3e54334@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> I did another test based on the above recommendations. I used a 3rd server > attached to this IFT-3102 that is not quite a critical as the other two. > This is system is another Intel CA810E system that runs NT 4.0. Upgraded > the Intel CA810E bios to latest version, upgraded the AHA2940U2W to bios > 2.57.2. Enabled the USB ports in the bios, left the IDE primary controller > disabled, secondary IDE enabled (for CD-ROM) and attempted to boot via the > 4.6R boot floppies. What do you need the USB ports for? Why not disable them to remove a possible cause of this problem? > Same result, the system does not get past the "Waiting > 15 seconds for SCSI devices to settle" phase of the kernel boot. Have you tried a verbose boot? This would at least let you see if the ahc driver is even attempting to talk to the device. > I would be very be inclined to point a finger at the ahc driver > since I have had problems w/ this driver and the IFT-3102 before. It > consistently has had a minor problem with sending a cache sync command to > the 3102 at shutdown. You mean that FreeBSD occasionally complains about the sync cache command failing? This has absolutely nothing to do with the ahc driver. There is some long standing bug in the da driver that causes it to complain about sync cache commands failing even though there is code in there to be quiet about them. The quirk table is just a hack around this problem that should actually be fixed. If you could spend a bit of time instrumenting the sync cache code in the da driver, you might be able to finally fix this bug. Unfortunately, all of the hardware available to the SCSI engineers actually supports the sync cache command correctly. 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 disturbing thing about your report is that there are no messages. The ahc driver sets a timeout for every command it issues. Does the num lock key toggle when you are in this condition? Please provide a verbose boot listing. You may have to use console redirection in order to get one. Many MB bios have this option. -- 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?200206202248.g5KMm1938462>