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

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

> On Feb 17, 2026, at 6:57 AM, Magnus Lindholm <linmag7%gmail.com@localhost> wrote:
> 
>> Hm, I added support for the monster window to NetBSD/alpha in:
>> 
>> $NetBSD: tsp_dma.c,v 1.17 2021/05/27 22:11:31 thorpej Exp $
>> 
>> (Only for Tsunami, etc. systems)
>> 
> 
> This is good news! I'll have a look at the code again, I forgot which version
> I tested this on. As I understand it, in order to actually use the
> monster window
> it first must be enabled byt setting  PCTL<MWIN>. Then in order for it to be
> actually used one must enable by generating physical addresses
> that have  TSUNAMI_DAC_OFFSET (1UL << 40) (bit 40 set).

That is correct!

I described it in a comment:

 * Quoting the 21272 programmer's reference manual:
 *
 * <quote>
 * 10.1.4.4 Monster Window DMA Address Translation
 *
 * In case of a PCI dual-address cycle command, the high-order PCI address
 * bits <63:40> are compared to the constant value 0x0000_01 (that is, bit
 * <40> = 1; all other bits = 0). If these bits match, a monster window hit
 * has occurred and the low-order PCI address bits <34:0> are used unchanged
 * as the system address bits <34:0>. PCI address bits <39:35> are ignored.
 * The high-order 32 PCI address bits are available on b_ad<31:0> in the
 * second cycle of a DAC, and also on b_ad<63:32> in the first cycle of a
 * DAC if b_req64_l is asserted.
 * </quote>

>> This suggests to me that I should probably change the tsp_dma code, then, to enable and advertise the monster direct-mapped window only on systems that actually could benefit from it (i.e. systems with > 2GB RAM).
>> 
> 
> I guess the 2GB mapping comes from how Linux has organized the memory on Alpha.
> It is possible that NetBSD is doing something different here. Either
> way, it is unlikely
> that using the monster window will have any benefit on systems with
> less than 2GB RAM.

Tsunami / Typhoon / Titan have 4 DMA windows in addition to the Monster Window, and this is how they’re used on NetBSD today:

Window 0: SGMAP 8MB @ 8MB, intended for use by ISA devices that do DMA due to 24-bit addressing restriction for ISA.  This window is never handed to PCI devices, only to ISA devices.  Floppy drives and audio for the most part.

Window 1: Direct-mapped 1GB @ 2GB.

Window 2: SGMAP 1GB @ 3GB.

Window 3: currently unused.  Window 3 supports dual address cycle.

Monster Window enabled, which is why I didn’t bother with Window 3 yet.

PCI devices that can’t do 64-bit addressing on systems with > 1GB <= 2GB will automagically use the SGMAP window if their DMA request doesn’t fit into the direct-mapped window.

> My issues with tsunami based systems and the ISP1040 card was that men
> using DAC/monster
> windows (i.e addressing bit 40 was set) I would see sporadic data
> corruptions.  Always occuring
> in chunks of 64-bytes, so some DMA transfers got through, but every
> now and then data would
> get corrupted.

Huh!  That is suspiciously the size of a cache line.

-- thorpej