Constant mysterious SCSI errors

Anthony Atkielski atkielski.anthony at
Sun Feb 27 09:14:18 GMT 2005

Dan Nelson writes:

> Try lowering the max tags for that drive: "camcontrol tags da0 -N 32".

Tried it.  I still get the same error; it doesn't seem to have
diminished.  I get the "queue full" stuff in bursts, then the process
trying to do the I/O stalls, then after 30-40 seconds I get one of those
huge panel dumps I posted, then the process continues.  There doesn't
seem to be any data loss.  The rest of the system continues to run (it's
a 2-processor system, so I don't know if one of the processors is
halted when this happens).

The problem only seems to arise when there is heavy disk activity.

> If that works, you can stick it in rc.local, or add an entry to the
> xpt_quirk_table[] in /sys/cam/cam_xpt.c .  It probably needs something
> similar to the quantum quirk lines.

The change to cam_spt.c requires a rebuild of the kernel, right?

I found references to SCSI "quirks" on the Net, but not knowing much
about SCSI, I wasn't sure which might apply to my situation.

Can you explain what all these messages are actually saying?  What does
it all mean?

> I never know what to look for in this output, but most of the time, I
> think it's a cabling or termination problem.  Reseat all the plugs :)

Well, there haven't been any cabling or termination problems in the past
eight years, so it seems unlikely that they've appeared today. I think I
can safely rule out any type of actual hardware problem. It's either a
software configuration problem or a software bug (which might mean a
quirk, I suppose).  (Note also that these two drives and the controller
are on the internal connector of the controller, and although the
controller provides an external connector, too, there's nothing
connected to it--which further makes cabling or termination problems


More information about the freebsd-questions mailing list