Re: 2.2.10 on Mac IIcx: SCSI doesn't work :-(
On Fri, 11 Aug 2000, Michael Schmitz wrote:
> > > What struck me as odd was the 'interrupts disabled' part in the SCSI
> > > controller probe message. What's that about? Not that SCSI would have
> > > worked with ints off, anyway.
> > >
> >
> > That was my "fix" for SCSI problems on my SE/30. And yes, it did fix it
> > for a while. When SCSI had interrupts turned on, it gave me an endless
> > string of SCSI errors, about commands timing out and coroutines not
> > running and whatnot. So I tried turning off interrupts, and that worked.
>
> 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.
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. ;)
> Better work on finding the interrupt problems in the SCSI driver
> (which were mostly sorted at some time in 98 or 99). Compare with the
> 2.0.36 driver which also produces command timeouts when the host queue is
> too long, but still works for all I know. Pay attention to where the old
> driver fully enables interrupts from within the interrupt routine (that's
> necessary to have a working timer interrupt), and check the interrupt is
> really enabled there on 2.2 as well (spin_unlock_irqrestore might only
> restore the IPL to what it was before entering the interrupt handler,
> which may be insufficient to enable the timer int).
>
> I'm not looking at the code, just venturing a few wild guesses. But that's
> all I can do without that Mac coming with plenty of spare time to start
> hacking myself...
>
> Michael
>
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.
Nonetheless, I'll try your suggestions and see what happens.
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.
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?
My guess is that all the problems we're having on these machines come from
the same source. SCSI won't get fixed until we find that source and nail
it.
-Andrew
Reply to: