[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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);


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)


	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);

	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

> 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.


Reply to: