Ummmm- what's probably happening here is that the Qlogic f/w is sending
a WIDE DATA XFER message- and instead of just doing a message reject,
the HP drive is aborting the whole command.

Sigh. I have some unchecked in code that might deal with this. I'll try
and get it checked in very soon. The change here has to do with upgrading
Qlogic f/w and using a 'force narrow/async' option which will keep the
Qlogic from automatically trying to negotiate wide && synchronous.

As an interim solution, around line 494 in isp.c where it does
a MBOX_SET_TARGET_PARAMS, change the line that has:

	mbs.param[2] = sdp->isp_devparam[i].dev_flags << 8;

to

	mbs.param[2] = DPARM_DISC|DPARM_PARITY|DPARM_RENEG|DPARM_ARQ << 8;

you could also do a check against the targets and only make this change
for the target that the HP is at. This will turn off wide, sync and
tagged attempts. SCSI devices should cope automatically with attempts
to do any of the above, but sometimes they don't- and what I should be
doing is peeking at the Inquiry data for the support bits, as well
as paying attention to NVRAM settings, before enabling autopilot for
these features.

Let me know how it progresses.

On Sat, 29 Aug 1998, Neil Hoggarth wrote:

> I've got a Chaltech CATS system running NetBSD/arm32, current(ish). I've
> just added a Q Logic QLA1040 SCSI controller and an HP DDS tape drive.
> The system correctly recognises both the controller and the tape drive
> at boot. Any attempt to do anything with /dev/rst0 (or varients
> thereof) results in an input/output error and a console message:
> 
> st0(isp0:0:0):  Check Condition on opcode 0x0
>     SENSE KEY:  Aborted Command
>      ASC/ASCQ:  Invalid Message Error
> 
> (the kernel is compiled with the SCSIVERBOSE option).
> 
> The same tape drive works fine (with a different controller) under
> NetBSD/arm32-1.3F on an Acorn RiscPC.
> 
> The Q Logic controller drives a SCSI disk okay and I'm pretty confident
> that I've got all the cabling, termination and such sorted out.
> 
> Does anyone know off hand what sort of conditions in the st driver would
> trigger this sort of message, or have any suggestions as to what might
> be wrong? I've started looking at through the source but it's been a
> while since I did any SCSI, so if anyone out there has any bright ideas
> then I'd appreciate a shove in the right direction!
> 
> Regards,
> 
> +-------------------------------------------------------------------------+
> Neil Hoggarth                                 Departmental Computer Officer
> <neil.hoggarth@physiol.ox.ac.uk>                   Laboratory of Physiology
> http://www.physiol.ox.ac.uk/~njh/                     Oxford University, UK
> +-------------------------------------------------------------------------+
>