Re: ethercons updated for -CURRENT

On Fri, 9 Jul 2004, Andrew Gallatin wrote:

> Robert Watson writes:
>  > having console I/O on the wire isn't such a big deal).  The other major
>  > limitation is that it relies on the network stack functioning, so can't be
>  > used for very early boot stuff, debugging, etc.  Despite these
> 
> How far into a crash does it work?  Eg, will it print the panic string? 
> How about a DDB_TRACE?

Probably not very far -- the reason for this is that I can't do a direct
network dispatch of the console output from printf() (cnputc()) anymore --
the reason being that printf() is actually called quite early and while
holding low level spin locks.  Since the network stack also uses locks, I
do an asnynchronous dispatch.  I explored two methods of doing the
dispatch: first, I used a software interrupt thread (swi), but this didn't
work well because swi_sched() also doesn't operate well while holding
scheduler locks.  Then I moved to using a ring buffer that's pulled by a
callout(), which is the model ethercons is currently using.  Since
softclock stops running pretty quickly in the event you enter DDB, you
will likely only get a small part of the debugger output before it cuts
out.  When I was dispatching the stack directly from printf(), I would get
output up until the point where it formally entered the debugger, which
was after the panic string (and maybe the trace?).  It is possible to
imagine adding a cnflush() of some sort on entering the debugger but as
you can imagine, it would have some limitations.

In order to support really low level I/O, you basically need a polled
network API that doesn't really care where it's called from -- the
physical console and sio both fall into this category, but the current
ethernet stack pieces don't as well.  It's not impossible to imagine
writing one, but the tricks that are pulled in the 4.x gdb-over-ethernet
kernel debugging won't work -- they call into the mbuf allocator and
assume it's "safe" -- in 4.x, it was risky, in 5.x you would get a panic
for trying to acquire locks in the debugger.

If you assume panic() is really The End, you could also imagine adding an
ifp->if_the_end(char *) which would be responsible for spewing some last
fragments of data out the door using reserved memory and a low level
packet send routine.  This would work almost all of the time, assuming
that the panic didn't occur at a moment where the hardware isn't left in a
state inconsistent with the expectation of if_the_end().  I.e., we could
probably find a way to increase the reliability of ethercons in crash
scenarios.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Principal Research Scientist, McAfee Research