> >I'd just like to report that I applied Hr entropy's patch to my source
> >tree, and successfully built a kernel that works spiffy on the problem

There's one problem I've run across -- with these particular machines,
`shutdown -p' results in a uvm panic, while `shutdown -r' is fine.  I've
not connected a serial console to grab the data yet...

That shouldn't surprise me, since I saw identical panics with my two-
line hacks, but in addition with my hacks I got these panics elsewhere,
which I'm not seeing now, though I haven't really pounded this patch/machine.

Naturally since I never had a -current kernel that would even boot on
these machines, I have nothing as reference, but with the GENERIC 1.5.2
kernel, which *did* boot, I didn't get such a panic.  I got some message
at shutdown that I don't recall, which is to be expected -- since this
Piece of Hardware only has v1.0 APM goodies, it's possible that -current
is trying to do something that's guaranteed not to work.  Just a guess.


Speaking of 1.5.2, since I did have some issues with booting that GENERIC
kernel on this hardware (or at least, loader problems), I want to build a
custom kernel based on the 1.5.2 source.  So I'm wondering, is it likely
to be a problem using a more recent `config' from -current, or should I
make sure that I use only 1.5.2-vintage tools when going backwards in time
with kernels?


> Does this mean you have commit access and will commit the patch

bwahahaha.  the world shall end before anything like that is allowed


> yourself, or that you will find a developer and convince them to
> commit it?

I'll see what I can do, but no promises...


thanks
barry bouwsma