Re: 2.2.10 on Mac IIcx: SCSI doesn't work :-(
On Fri, 11 Aug 2000, Michael Schmitz wrote:
[...]
>
> > 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).
>
Actually, FWIW, vPCR was set in mac_request_irq just before the interrupt
rewrite and not on bootup. However, for whatever reason, during the
rewrite, IRQ_IDX(IRQ_MAC_SCSI) transformed into (irq_idx == 0), which, as
you pointed out, don't mean the same thing. Here's some snippets from the
old code:
from via6522.c (version 1.6):
void via_init_clock(void (*func)(int, void *, struct pt_regs *))
{
[a bunch of stuff cut]
#if 0 /* gone to mac_init_IRQ */
/*
* Set vPCR for SCSI interrupts.
*
* That is: CA1 negative edge int., CA2 indep., positive edge int.;
* CB1 negative edge int., CB2 indep., positive edge int..
*/
via_write(via2,vPCR, 0x66);
#endif
}
And then in macints.c (version 1.4, when it encompassed via.c):
int mac_request_irq (unsigned int irq, void (*handler)(int, void *, struct pt_regs *),
unsigned long flags, const char *devname, void *dev_id)
{
[snip]
if (irq == IRQ_IDX(IRQ_MAC_SCSI)) {
/*
* Set vPCR for SCSI interrupts. (what about RBV here?)
* 980429 MS: RBV is ok, OSS seems to be different
*/
if (!via2_is_oss) {
if (macintosh_config->scsi_type == MAC_SCSI_OLD) {
/* CB2 (IRQ) indep. interrupt input, positive edge */
/* CA2 (DRQ) indep. interrupt input, positive edge */
via_write(via, vPCR, 0x66);
} else {
/* CB2 (IRQ) indep. interrupt input, negative edge */
/* CA2 (DRQ) indep. interrupt input, negative edge */
via_write(via, vPCR, 0x22);
}
}
#if 0
else {
/* CB2 (IRQ) indep. interrupt input, negative edge */
/* CA2 (DRQ) indep. interrupt input, negative edge */
via_write(via, vPCR, 0x22);
}
#endif
}
return 0;
}
So I guess that's the problem- the SCSI IRQ transformed into the SCSI DRQ
in the middle of the rewrite. Funny that it was never a problem on RBV
Macs.
[...]
>
> 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.
>
I'll do that. I can't believe that I never saw that, for the hours I've
spent staring at that code. Funny how if you look at something long
enough, you start to overlook the errors. :(
> > 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.
>
Well, I'll try it anyway. It seems like if the SCSI problems are due to
the PCR set wrong, then the ramdisk stuff has nothing to do with it. I've
booted 32-bit clean machines into Linux in 24-bit mode before, so I guess
it's not guaranteed to fail.
Unfortunately, I couldn't find anything in the way of technical info on
Mode32 online. All I could find was, "it lets you do 32-bit addressing on
old Macs." No mention of how it does that.
> > 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
>
I doubt it's the screen pattern. On B&W Macs, it would be 101010101010....
for most of the screen, which would be AAAAAAAAA. The icon would be
something different, but not repetitive like that. I don't know what that
pattern's supposed to mean.
-Andrew
Reply to: