Alex Zepeda wrote:
> On Wed, 28 Jul 1999, Colin Wood wrote:
> 
> > > Well I managed to reliably hang my system with them.  Some spl frobing and
> > > setting the "completion variable" to zero has solved most of the problems. 
> > 
> > you've really gotta watch mucking with the spl in the ADB code.  you can
> > easily hang things that way, and rather screw up over interrupt latency as
> > well if you're not careful.
> 
> Sure, but that's why we have splx, right?

sort of...see below
 
> It just seems as if something was disabling interrupts, thus hanging
> (well, you can break out of this and go on your merry way with the
> debugger switch) the machine while the actual ADB command was being sent. 
> 
> Wrapping the "busy wait" loop with splsoft/splx seems to have alievated
> this, and cause no ill effects (I pounded on the caps lock key while the
> system was booting up and didn't notice anything).

here's the problem.  last i checked, splsoft() is not implemented via
splraise(), it's simply spl1().  this means that you're lowering the spl,
even if you shouldn't.  this could be kinda bad.
 
> > yeah, we probably don't have something quite right.  and it's also
> > probably worse on some machines than on others :-)
> 
> There's nothing like trying to debug the ADB code, with an ADB keyboard. :^)

yep.  you can turn on the debug printf()'s that are in there, tho.
they're quite verbose :-)

> Just out of curiosity, what macines are supported with the direct code,
> that aren't supported with the MRG?  Me, personally, I see less weirdness
> with the MRG code. 

well, it seems that the direct code has been a little less stable since
shortly before 1.4.  i'm not really all that sure what happened to make it
so.  the 1.4.1 release should be a little bit better, assuming that it's
built for mac68k.

as for support, the direct code should be able to handle anything except
the powerbooks, although they were supported as well at one point.  i'm
not positive about what is wrong with them now.  the MRG code should be
similar (i.e. everything except the powerbooks).  someone else please
correct me if i'm wrong.  oh, wait, toss out the IIfx and Q9x0 series as
well since they use IOP's.

> > well, the intention was to add a set of ioctl()'s to do it.  i doubt that
> > i've got it in there right now, but my local code has something like this:
> 
> Righto, but I've left this disabled (untouched).

cool.
 
> > keep in mind that a lot of the driver will need to change slightly when
> > we go to wscons (including a shared ADB driver between the macppc and
> > mac68k ports, i hope). 
> 
> qThis would be udoubtedly cool.  As long as the ADB driver is going to be
> re-organized, perhaps it would be a good idea to move adb_direct.c (say
> closer to macrom*), and split it up into a few different files.

well, it can probably stay 1 file, but it certainly needs to be cleaned
up.  ideally, we will have everything working under the direct drivers and
not have to use the rom drivers at all.  

as for changes to the direct driver, it doesn't need to be change for
wscons, just the kbd and ms drivers.  i think that scott has many of the
changes already on a branch, tho.

if i'm really feeling up to it, i may give cleaning up the direct driver a
shot, but that's rather far down on my plate at the moment.  of course, if
john's still maintaining the code, he might have some input on it as
well...

later.

colin