Date: Fri, 9 Jul 2004 10:23:33 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: current@FreeBSD.org Subject: Re: ethercons updated for -CURRENT Message-ID: <Pine.NEB.3.96L.1040709101417.60816J-100000@fledge.watson.org> In-Reply-To: <16622.41619.355522.170000@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040709101417.60816J-100000>