Well, here I am, replying to my own message...

On Mar 12, 21:20, Bernard Gardner wrote:
> Subject: Re: A couple of questions re my problem...
> On Mar 12, 20:02, Russ Evans wrote:
> > Subject: Re: A couple of questions re my problem...
> 
> light is on. I did some experiments last night in regard to file sizes, and
> found that it was OK to write reasonably small files, but that larger ones
hung
> the system. I should hopefully be able to quantify large and small fairly
soon.

Well, it seems that small is files less than 16384 bytes, and large is
16384 bytes and up. At 16384 bytes, I sometimes got away with it, but it
usually hung the machine.

> solid, mouse tracking stops in X, serial echo on a logged in tty stops, and I
> can't even use the "programmers switch".
> 
> Can anyone suggest what I can do to get into the debugger on a IIsi when
> commmand power doesn't work?

Whoops, the programmers switch needs Macsbug doesn't it? I was booting from
a zip with a stripped out system, and I didn't have Macsbug installed. It
works OK now. Furphy! Red Herring!

> I'm working on the assumption that this is a file system problem, rather than
> solely the fault of the SCSI driver.

Having the debugger running again, the system seems to be getting a
stream of level 2 interrupts such that on re-enabling interrupts after
handling one, it immediately gets another.

The stack looks basically like
_Debugger
_nmihand
_lev7intr
_ncr5380_drq_intr
_ncr5380_show_scsi_cmd
_ncr5380_show_scsi_cmd
_ncr5380_show_scsi_cmd
_pdma_cleanup
_ncr5380_drq_intr
_rbv_intr
_lev2intr
and then whatever the machine was doing when it got confused below here.

I was able to observer the stack with not all of these functions on it
sometimes, but from steping through the code, when _lev2intr returned,
the debugger would hang, and NMI'ing again, would show a stack somewhere
in exactly the same sequence...

> Hmm, I've just remebered that I was planning on power cycling the Zip to
break
> out of the apparent deadlock, I must try that tonight.

This does indeed break the deadlock. By power cycling the drive when
the system is hung, I'm able to get back to a usable system, but it
gets upset when I try to use the device that was power cycled.

I've also tried a quick hack to switch off linked commands, and if that
worked, the system was still showing this behaviour with linked
commands off. Basically, I set ncr_test_link to 0xff in mac68k5380.c in
an attempt to fool the driver into thinking it had already tested the
drives fro linked command support and that they had failed, should that
do what I wanted?

Just putting all this on the record before I go to sleep, so that I
have some hope of remembering some of it tomorrow.

Bernard.