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

> On Feb 17, 2026, at 6:57=E2=80=AFAM, Magnus Lindholm =
<[email protected]> wrote:
>=20
>> Hm, I added support for the monster window to NetBSD/alpha in:
>>=20
>> $NetBSD: tsp_dma.c,v 1.17 2021/05/27 22:11:31 thorpej Exp $
>>=20
>> (Only for Tsunami, etc. systems)
>>=20
>=20
> 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> =3D 1; all other bits =3D 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).
>>=20
>=20
> 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=E2=80=99re 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=E2=80=99t bother with Window =
3 yet.

PCI devices that can=E2=80=99t do 64-bit addressing on systems with > =
1GB <=3D 2GB will automagically use the SGMAP window if their DMA =
request doesn=E2=80=99t 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