Re: I did a test on a DEC AlphaStation 600 and the SCSI driver seems borked

> On Feb 16, 2026, at 5:33=E2=80=AFPM, Jason Thorpe <[email protected]> =
wrote:
>=20
>=20
>=20
>> On Feb 16, 2026, at 3:37=E2=80=AFPM, Jason Thorpe <[email protected]> =
wrote:
>=20
>> I=E2=80=99ll see if I can figure out what the unexpected 0x09 =
(=E2=80=9CRQSTYPE_A64=E2=80=9D) means later tonight.  Alas, no comments =
for those entry types in the deriver=E2=80=99s header files:
>>=20
>> #define RQSTYPE_A64             0x09
>> #define RQSTYPE_A64_CONT        0x0a
>=20
> Ok, I think I understand what is going on now.  I=E2=80=99ll follow up =
again later tonight.

Ok.

My initial analysis about why the OpenBSD driver is working for you was =
not quite correct, in the sense that while my statement was accurate, =
what=E2=80=99s actually happening in the OpenBSD case, as far as I can =
tell, is that it only ever issues the 32-bit DMA command to the ISP and =
thus don=E2=80=99t fall into this trap.

Now, that I can=E2=80=99t figure is why this is blowing up for you, but =
it didn=E2=80=99t for me.  I should to back and look at the 10.1 version =
of the NetBSD driver.  In any case, if my analysis is correct, I can=E2=80=
=99t figure why it would have ever worked at all (but I can 100% =
guarantee you that it did, because I was running NetBSD/alpha on =
AlphaServer 8200s with =E2=80=9Cisp=E2=80=9D SCSI and FibreChannel =
interfaces in them when this driver was written; I shared an office with =
the guy who wrote it).  Maybe a firmware difference?

In any case, there is an easy work-around, and a longer-term workaround.

What=E2=80=99s happening is that the PCI front-end =
(sys/dev/pci/isp_pci.c) is converting the normal RQSTYPE_REQUEST request =
into RQSTYPE_A64 (=E2=80=9Crequest, but using 64-bit DMA addressing=E2=80=9D=
).  It does this conditional on "sizeof (bus_addr_t) > 4=E2=80=9D, which =
at first glance is correct, but it=E2=80=99s actually not.  The NetBSD =
PCI infrastructure has two separate DMA =E2=80=9Ctags=E2=80=9D (mapping =
back-ends), the standard DMA tag, and the 64-bit DMA tag.  A device =
using the standard DMA tag does not need to use 64-bit DMA, and so this =
test that the PCI front-end is doing is incorrect; it doesn=E2=80=99t =
need to use 64-bit DMA at all.

(In fact, on most NetBSD/alpha systems, 64-bit PCI DMA is not necessary =
because the max RAM in the system is within the DMA window that fits =
into 32 address bits; the only one that supports a large 64-bit DMA =
window are the Titan-class systems, such as the DS25.). But even those =
systems have an IOMMU that supports 32-bit PCI devices.

In any case, this PCI front-end behavior would be fine except for the =
logic in sys/dev/ic/isp.c:isp_intr() does not properly handle the 64-bit =
flavor of the request.  It has a normal-completion handler for it that =
implies it should be handled exactly like the garden-variety =
RQSTYPE_REQUEST:

                case RQSTYPE_REQUEST:
                case RQSTYPE_A64:
                case RQSTYPE_T2RQS:
                case RQSTYPE_T3RQS:
                case RQSTYPE_T7RQS:
                        if (!IS_24XX(isp) && (sp->req_header.rqs_flags & =
RQSFLAG_FULL)) {
                                /*
                                 * Force Queue Full status.
                                 */
                                *XS_STSP(xs) =3D SCSI_QFULL;
                                XS_SETERR(xs, HBA_NOERROR);
                        } else if (XS_NOERR(xs)) {
                                XS_SETERR(xs, HBA_BOTCH);
                        }
                        XS_SET_RESID(xs, XS_XFRLEN(xs));
                        break;

BUT.  The problem is that RQSTYPE_A64 is not equated with =
RQSTYPE_REQUEST earlier in the function where it reports that error.  =
Looks like it was just a thiunk-o.

Unfortunate.

Anywho, I think the easiest short-term workaround is to ensure the =
=E2=80=9Cisp=E2=80=9D driver doesn=E2=80=99t use the 64-bit version of =
the command, which should be fine since:

        isp->isp_dmatag =3D pa->pa_dmat;

It=E2=80=99s only ever going to get 32-bit addresses anyway.

Longer term, fix the logic in isp_intr() to properly handle the =
RQSTYPE_A64 as an equivalent of RQSTYPE_REQUEST in all cases, and =
properly detect when to use the 64-bit DMA tag in the PCI front-end.

-- thorpej