Oh, yeah, one or two other "gotcha's" with the SLOTMAN kernel:

1. There's still limited support for Mac models due to lack of input from
   our user community.  I still need to find some Mac ROM addresses for 
   most Mac models.  Although it _appears_ that most systems using the
   "Universal" ROMs like those on the IIci have the necessary routines at
   the same address, I'm a bit leery about making that assumption part of
   my source code.  So, I still need people to help confirm ROM addresses.

2. There's some "bad code" running around in at least one nubus card
   (mine!) that can cause strange things to happen.  I _think_ that the
   problem is continued use of a dynamically-allocated memory block after
   having free()d it (ie, _DisposPtr in MacOS speak).  I've worked in a
   little hack for my card (sends a beep to the console whenever the
   _HWPriv trap is called) but that's definitely not kosher for release
   quality software.  I plan on trying some less ugly ways to accomplish 
   the same result (temporarily altering the free memory list so that it
   can't agglomerate the free()d block with another and then re-use it),
   but I'm not there yet.

On Mon, 22 Sep 1997, Colin Wood wrote:

> Michael R Zucca wrote:
> > 
> > > > no clue what I'm doing with ld, so needless to say it hasn't helped.  I
> > > > did notice a caveat on the FAQ page which basically states that the LKM
> > > > *may* not work with -current setups, and *definitely* will not compile
> > > > under them (I can personally attest to both).  My question, basically,
> > > > is this:  what are my options here (and no, "don't run X in color" is
> > > > not acceptable :>), and what can I do about it?  I'm sure at *least*
> > > > one other person has run into this dilemma, given the popularity of
> > > > both the colorkit and of -current.  Thanks.
> > > 
> > > Yeah, the symbol that causes the problem is now a static variable so it
> > > doesn't show up in the symbol table anymore :-(  And due to extensive
> > > changes in the nubus code, the colorkit LKM doesn't recompile under
> > > -current sources.  However, I've managed to hack together a patch to get
> > > around this problem.  Please try the patches at the end of this message
> > > and let me know how it goes.
> > 
> > You shouldn't need the lkm anymore. Paul Goyette's (sp?) SLOTMAN kernels
> > should work on a wider variety of card than the colorkit and will
> > eventually become part of the official kernel.
> 
> This is definitely a Good Thing (tm) ;-)  Paul, how stable are your
> patches?  Have you had report of any trouble with them yet?  If I get a
> chance, I may compile a kernel with the patches in and try it this
> weekend.
> 
> > When I get the intvid code done I think we can finally look forward to a day
> > when color support is a standard feature.
> 
> So how is this coming along?  I really have no idea when the 1.3 code
> freeze will be (other than sooner than later :-) but it would be nice to
> make this much progress by the time that 1.3 rolls around.
> 
> Later.
> 
> -- 
> Colin Wood                                 cwood@ichips.intel.com
> Component Design Engineer - MD6                 Intel Corporation
> -----------------------------------------------------------------
> I speak only on my own behalf, not for my employer.
> 

-----------------------------------------------------------------------------
| Paul Goyette       | PGP Public Key fingerprint:  | E-mail addresses:     |
| Network Consultant |     0E 40 D2 FC 2A 13 74 A0  |  paul@whooppee.com    |
| and kernel hacker  |     E4 69 D5 BE 65 E4 56 C6  |  paul_goyette@ins.com |
-----------------------------------------------------------------------------