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

[Jason Thorpe <thorpej%me.com@localhost>]

> On Feb 16, 2026, at 5:33 PM, Jason Thorpe <thorpej%me.com@localhost> wrote:
> 
> 
> 
>> On Feb 16, 2026, at 3:37 PM, Jason Thorpe <thorpej%me.com@localhost> wrote:
> 
>> I’ll see if I can figure out what the unexpected 0x09 (“RQSTYPE_A64”) means later tonight.  Alas, no comments for those entry types in the deriver’s header files:
>> 
>> #define RQSTYPE_A64             0x09
>> #define RQSTYPE_A64_CONT        0x0a
> 
> Ok, I think I understand what is going on now.  I’ll 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’s 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’t fall into this trap.

Now, that I can’t figure is why this is blowing up for you, but it didn’t 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’t 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 “isp” 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’s happening is that the PCI front-end (sys/dev/pci/isp_pci.c) is converting the normal RQSTYPE_REQUEST request into RQSTYPE_A64 (“request, but using 64-bit DMA addressing”).  It does this conditional on "sizeof (bus_addr_t) > 4”, which at first glance is correct, but it’s actually not.  The NetBSD PCI infrastructure has two separate DMA “tags” (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’t 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) = 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 “isp” driver doesn’t use the 64-bit version of the command, which should be fine since:

        isp->isp_dmatag = pa->pa_dmat;

It’s 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