Re: 2.2.10 on Mac IIcx: SCSI doesn't work :-(
> > ARRRGH!!! I'm amazed how that works, but this is definitely the wrong way
> > to fix SCSI on Mac. Granted, there's no DMA so you can (in theory) get
> > away without interrupts for a while, but my guess is the first SCSI
> > command that disconnects will result in the target trying to reselect,
> > and that will fail without interrupts.
> >
>
> Sorry. I know it wasn't a real fix, but it was an improvement over no SCSI
> at all, and it actually booted to a login on my SE/30. But then it broke
> again in 2.2.16. Still, it gets farther than it did.
As I said, I'm still amazed it did work at all.
> The problem seems to be that there are no SCSI interrupts generated, or at
> least not enough, so if the driver looks for them, it's hosed. If it
> doesn't look for them, at least it can fake it long enough to get more
> interesting error messages. ;)
No SCSI ints generated, and that's on the old style VIA machines as you
say below. That rings a bell. That's precisely how it behaved when I had
written the PIO SCSI driver based on what I tried on my Falcon, and Alan
had plugged it into his code. Why was that? Because Apple had gotten
something backwards, and apparently set an inverter between the /IRQ line
of the NCR5380, and the VIA. The VIA needs to trigger on a positive edge
on these machines, and on a negative edge on all others. Controlled by the
PCR register.
Enough ancient history, let's have a look at the code. Before the big
interrupt rewrite, all was fine, and the VIA2 interrupt input CA2 (DRQ,
bit 0) and CB2 (IRQ, bit 3) settings were done early on, while the whole
via_init() set up all things VIA. Regardless of any SCSI interrupt being
registered or enabled yet, the vPCR set
After the rewrite, this is what happens in via_irq_enable() (irq_src is
the int level, 2 for VIA2, and irq_idx the interrupt flag/mask bit in the
VIA, 0 for the SCSI DRQ, 3 for the SCSI IRQ).
if (irq_src == 1) {
via_write(via1, vIER, irq_bit | 0x80);
} else if (irq_src == 2) {
/*
* Set vPCR for SCSI interrupts (but not on RBV)
*/
if ((irq_idx == 0) && !rbv_present) {
if (macintosh_config->scsi_type == MAC_SCSI_OLD) {
/* CB2 (IRQ) indep. input, positive edge
*/
/* CA2 (DRQ) indep. input, positive edge
*/
via_write(via2, vPCR, 0x66);
} else {
/* CB2 (IRQ) indep. input, negative edge
*/
/* CA2 (DRQ) indep. input, negative edge
*/
via_write(via2, vPCR, 0x22);
}
}
via_write(via2, gIER, irq_bit | 0x80);
At a first glance, it looks fine, the right code is there. Looking at
mac_scsi.c, it turns out that the SCSI DRQ (irq_idx 0) is never registered
though. I've never seen such a DRQ, it _might_ happen with pseudo DMA from
what I recall from the BSD source, but it never happened with PIO. So that
code is never executed, the vPCR is never explicitly set up right. That
seemed to be a problem on Alan's MacII, and it might be a problem now.
Change the (irq_idx == 0) to (irq_idx == 3) and try if you get better
interrupt behavior.
> See, I doubt that it's the SCSI driver that's hosed. I think it's probably
> the interrupt code, or maybe something else totally unrelated, that's
> causing the problems. The same SCSI driver works without a problem on
> other machines that have 5380 SCSI, but have IIci-style VIA's and
> 32-bit-clean ROMs. Also, SCSI _used to work_ on these old Macs, in May 99
> (that was kernel 2.2.6). Then, over May 20th-26th, it broke. The CVS logs
> indicate basically no changes to the SCSI driver, but a total interrupt
> code overhaul. That's why I suspect interrupt problems.
It seems you were right on there, see above.
> My latest unsubstantiated guess/bogus theory is that Mode32 might have
> something to do with it. What we know is this: The II, IIx, IIcx, and
> SE/30 are broken in many more ways than one (SCSI, Ramdisk, maybe others
> as well). What do these have in common? They are the only four that have
> Mac II-style VIA's. But that's 2 6522 controllers, which the Quadras also
> have. True, they're the only ones with VIA2 == 6522, and 5380 SCSI. Also,
> they're the only ones that are 32-bit dirty. That seems suspicious to me.
> Maybe there's also something different about various memory mappings? I
> don't know enough about that to say.
I recall I never could boot non 32 bit clean machines without Mode32, so
it's not always been a problem. But even with Mode32, I've seen funny
things like the booter passing a 24 bit address for SCCbase (the
0x50xxxxxx part missing) on some machines. ROM should not even be mapped
unless needed for poweroff functions - try removing the ROM mapping in
head.S, maybe that throws a bus error earlier.
> The logs full of db6... (== binary 110110110110... FWIW) make me
> suspicious. Either the kernels are messing up the memory mappings and
> going into some section of ROM (highly doubtful, now that I think about
> it. The stack pointer isn't right), or something is chewing away at the
> memory. Could that be Mode32?
Dunno, but what does that boot screen pattern look like on a Mac? Is that
stored in ROM? Another bogus idea.
Michael
Reply to: