Subject: Re: scsi/rz lossage in 1.3 branch.
To: Thor Lancelot Simon <tls@panix.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-pmax
Date: 11/18/1998 00:07:19
>Just out of curiosity, how much work would it be to move just the TC
>DECstations to use the ordinary NetBSD SCSI?
``A lot''.
I tried years ago and ran smack head-on into some interrupt handling
problems. Tohru has finally found the time to look at those.
Meanwhile I handed off some truly awful code to Michal, which reworked
the existing pmax `asc' scsi driver to use MI scsi. It sort of worked,
but only if you limited scsi transfers to no more than 8k.
Micheal Hitch redid it from scratch and now has it working properly,
save for kernel coredumps. We already have device numbers reserved for
this. Look for it in 1.4. it still uses the pmax asc driver, tho'.
>Don't some of them have
>more or less exactly the same TC SCSI hardware as the Alphas?
No. Not at all. its only similar enough to confuse the unwary.
They both use ncr 53c94s (aka esp), but the glue between the
TurboChannel and the 53c94 is completely difrerent--- both for option
boards and the baseboard hardware. Alphas useso mething called a
`tcds', sorta a DMA bridge-chip with support for two 53c94s.
The decstations use an ioctl asic if you're lucky, and PIO to and from
an onboard 12kbb SRAM buffer if you're not.
The plan, medium-term, is to do a bus-space/bus-dma for the ioctl asic
chip with its (i quote) `sexy' DMA support. that is where the
interrupt support comes in: the DMA engine has one, double-buffered
DMA pointer, and interrupts for a reload. the current interrupt
structure cannot avoid DMA overruns.
To fix that, we need to keep the spls in the ioctl asic which,
logically, is a child of the TC; except on one model the option-card
interrupt lines are wired direcly to the CPU, and there's no other way
mask them out.
Anytime I look at this i end up wanting to use more than 32 bits of
interrupt-mask state around, and that just doesn't fit in an int. Ted
Lemon proposed introducing an an `spl_t' (which on a mips could be an
int64_t or some such) a couple of years back, but that got nixed.
The recommended alternative was to keep a table of `enabled' bits
around, with 64 bits for each spl level. Slower, but I understand
that's on Tohru's branch.
once we get that then we should be able to use the mi 53c94 driver.