DELL SC430 & ahd0: <Adaptec 39320A Ultra320 SCSI adapter>

[Hutterer Robert]

> 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 at scsiguy.com>
To: "Hutterer Robert" <robert.hutterer at univie.ac.at>; "Justin T. Gibbs" 
<gibbs at scsiguy.com>; <freebsd-stable at 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 at 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
>