--On Friday, August 19, 2005 12:20 AM +0200 Hutterer Robert
> 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
> 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
> = 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
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
Just below that, you'll find an entry for "/*maxtags*/255". Lower the 255
64, recompile your kernel, retest. If the problem persists, lower the
> 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
problem, not a controller or system problem.