--On Friday, August 19, 2005 12:20 AM +0200 Hutterer Robert
<[EMAIL PROTECTED]> 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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
