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

Re: 2.2.10 on Mac IIcx: SCSI doesn't work :-(

On Wed, 9 Aug 2000, Michael Schmitz wrote:

> > <SLAP!> Maybe I should actually _read_ the message before posting dumb
> > responses =). Although, it's really the same thing. Basically, IIcx == IIx
> > == SE/30, as far as the important hardware is concerned. I'd expect the
> > IIcx to have the same problems as the SE/30- it also has the Mac II-style
> > via's.
> Something must have been broken horribly since I last tried a 2.2 kernel
> on eithe SE/30 or IIcx somewhat more than a year ago. Maybe I'm just being
> mean here but I'd suspect the interrupt rewrite. Was the SE/30 tested
> during or after that rewrite? Can we figure out what happened when from
> CVS? I used cvsweb a lot for that while it was available...
> 	Michael

Yes, it was the interrupt rewrite. I traced back through all the old 2.2
kernels, and the last one that worked was 2.2.6 from May 20th. The 21st
and 23rd wouldn't boot, and then on the 26th, SCSI was broken and has been
ever since. I did a bunch of "cvs logs" and discovered that May 20th
coincided with a ton of stuff from JMT modifying the interrupt code.
The SCSI driver didn't change that much; only the RBV_HACK disappeared,
with a comment that it didn't work under the new interrupt code.

The files to look at are in arch/m68k/mac: macints.c changed
substantially, and via6522.[ch] was replaced by via.c and
include/asm/mac_via.h. psc.c and oss.c were created during that time as
well, but they shouldn't affect mac-II style VIA's.

I've done a lot of hacking trying to restore conditions to as close as
possible to before the rewrite. I've commented out code that I couldn't
find before the rewrite, and changed the order things happened. I even
restored *via_memory_bogon, which disappeared about a month after the
rewrite. (It was used to slow down via_read and via_write). Nothing

I've done some debugging messages as well. The problem is, SCSI interrupts
aren't generated correctly. What I found was that immediately after
via_irq_enable(IRQ_MAC_SCSI), one interrupt would be generated and then
nothing. Whether or not I called the handler at the point didn't matter,
nor did it matter if I turned off interrupts while calling it.
Predictably, if I didn't clear the interrupt, it would keep coming back
and put the machine in a nasty loop.

What's crazier is that immediately after via_irq_disable(IRQ_MAC_SCSI), an
interrupt would also be generated. That seems bogus to me. Finally, I've
recently noticed that occasionally another SCSI interrupt will show up
even when SCSI doesn't use interrupts, often locking the machine when it
comes in.

Anyway, I thought the disable-IRQ fix would work well enough, but
apparently not. This should be motivation to fix it correctly. I figure
that the problem is in via2 somewhere, since that's where SCSI is, and
it's also what distinguishes MacII-style via's from RBV machines, which
encompasses the rest of the 5380 SCSI Macs.

I'll keep messing around with it. Suggestions welcome.


Reply to: