Date: Sat, 20 Aug 2005 11:56:56 +0200 From: "Hutterer Robert" <robert.hutterer@univie.ac.at> To: "Justin T. Gibbs" <gibbs@scsiguy.com>, <freebsd-stable@freebsd.org> Subject: Re: DELL SC430 & ahd0: <Adaptec 39320A Ultra320 SCSI adapter> Message-ID: <00b101c5a56d$83818910$0901a8c0@virtual> References: <00e901c5a1cd$94e1c9c0$0901a8c0@virtual> <1F21DAB5B24D156A1C27045D@aslan.scsiguy.com> <012f01c5a443$15a97b80$0901a8c0@virtual> <FE73C49493FF893FAEA81264@[10.0.0.90]>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Thank You for clarification. Contacted Seagate and it will need some days to get an answer and clarified if a new firmware is availabel and will fix this problem. Meanwhile I tested both methods you suggested 1. 'camcontrol tags da0 -N 64' in /etc/rc 2. lower the maxtags entry in (/usr/src/sys/cam/cam_xpr.c and rebuild kernel Both methods work. No problems even I keep the machine active (cvsup and buildworld, installing ports). Additional questions: 1. Is one method as good as the other (disadvantages/advanages of one compared to the other) 2. It seems to me that I have now a working but somehow "tinkered" system. Are there some disadvantages (performance reduction etc.) or side-effects I have to take care off. Thanks for sharing your knowledge Robert ----- Original Message ----- 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> Sent: Friday, August 19, 2005 12:53 AM Subject: Re: DELL SC430 & ahd0: <Adaptec 39320A Ultra320 SCSI adapter> > --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?00b101c5a56d$83818910$0901a8c0>