Date: Thu, 18 Aug 2005 16:53:41 -0600 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Hutterer Robert <robert.hutterer@univie.ac.at>, "Justin T. Gibbs" <gibbs@scsiguy.com>, freebsd-stable@freebsd.org Subject: Re: DELL SC430 & ahd0: <Adaptec 39320A Ultra320 SCSI adapter> Message-ID: <FE73C49493FF893FAEA81264@[10.0.0.90]> In-Reply-To: <012f01c5a443$15a97b80$0901a8c0@virtual> References: <00e901c5a1cd$94e1c9c0$0901a8c0@virtual> <1F21DAB5B24D156A1C27045D@aslan.scsiguy.com> <012f01c5a443$15a97b80$0901a8c0@virtual>
next in thread | previous in thread | raw e-mail | index | archive | help
--On Friday, August 19, 2005 12:20 AM +0200 Hutterer Robert <robert.hutterer@univie.ac.at> wrote: > Thank you very much for the reaction (about a dozen user reported similar > problems the last month -but there seems no answer/solution) > >>> From what I can tell from the full card dump state, the 39320 attempted >> to send 77 transactions to your drive during a single connection. This >> connection hung, and the timeout occurred. Since the drive controlls >> the connection, it can cut the initiator off at any time if too many >> commands are sent. > That seems plausilbe also for a non-expert > >> So, this looks like a drive firmware bug. You >> should contact Dell to find out if newer firmware is available for your >> drive > Contacted Dell but they have no idea to fix this - freebsd is not > supported by dell -directed me to adaptec. > So I used the latest bios for the 39320 adapter from adaptec. The problem is in the *drive* firmware. Updating or changing the Adaptec BIOS will have no impact on your problem. You could try contacting Seagate directly, but I'm guessing your system is using Dell OEM drive firmware which I think Seagate only releases through Dell. > ===================================================================== > = Adaptec Ultra320 Family SCSI Controller = > = PnP/BBS BIOS Version 4.30.0, P/N 2038403-00 Rev. AA = > ===================================================================== > Soon after a reboot I got similar but slightly different messages (see > below - hope you understand it). I will see if I will get it more > frequently The messages mean exactly the same as the last set. As expected, changing the BIOS made no difference. > If the failure occurs sometime after rc processing, >> you can make a call early in the transition to multi-user like so: >> >> camcontrol tags da0 -N 64 # or some lower number > > Unfortunately I am not that expert to understand what to do with this > "call": to put it on the command line? To ma a startup command ? shell prompt% man camcontrol shell prompt% camcontrol tags da0 -N 64 To make this command invocation take place during startup, place it in /etc/rc just after the PATH variable is exported. That's about as early in startup as you can make this happen. >> If that won't work for you, you can enter a quirk into sys/cam/cam_xpt.c >> or just modify the last quirk entry (the default) to have a lower tag >> depth (it is currently 255). > > Also this hint I do not understand (I found (/usr/src/sys/cam/cam_xpr.c > file) maybe you can give me an idea or direct me to some instruction pages > how to enter a quirl or modify the last quirk entry In that file, search for "/* Default tagged queuing parameters for all devices */". Just below that, you'll find an entry for "/*maxtags*/255". Lower the 255 to 64, recompile your kernel, retest. If the problem persists, lower the number again. > If nothing helps I will seriously think about changing to a SATA disk. > (But it is strange I have 39320 on a dell SC1420 and there is no problem) With what drive make, model, and firmware revision. Again, this is a *drive* problem, not a controller or system problem. -- Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FE73C49493FF893FAEA81264>