> After a kernel panic you can't unsuspend XFree86 and ask it to do
> something for you.

Right.  That's why it's problematic.

> But it works fine on Solaris, and I think it worked at least for Xsun
> on NetBSD, right?

I don't think so, for the latter; any NetBSD port supporting Xsun
hasn't supported switching virtual consoles, so there's no issue.

> It is a software-rendered console, so if wscons knows where the
> framebuffer is mapped and the bit depth, shouldn't that be enough to
> print ddb> if the kernel takes a panic while X is running?

Actually, it does, if the framebuffer supports multiple resolutions
and/or colour spaces.  At the barest minimum the code in question has
to know the row-to-row stride.

Also, I have some personal experience that seems relevant.  I run a
cg14 on a SS20 as my main routine-use video head.  The ROM text code
talks to it using its 8bpp mode, and does not check to see whether it's
still in 8bpp mode before writing to it.  X, of course, runs in 24bpp
mode, in which mode the video RAM occupied by the 8bpp mode looks like
four tiny screens occuping the top ¼ of the screen.  I found that
breaking to ddb, or panicking, would end up with ddb displaying
(unreadably) there.  I finally added ddb switching hooks, so that when
the cg14 driver puts the card into 24bpp mode, it registers a hook
that's called before entering ddb (and another when leaving), to switch
the hardware.

While it's slightly risky - a panic in the cg14 code could end up
spiraling out of control - the benefit (usable ddb in all cases
encountered so far, and almost all possible cases) outweighs the cost
("infinite" recursive traps in case of a bug in a few very small pieces
of code).

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B