Re: ethercons: ethernet console driver for 5-current

Robert Watson wrote:
> On Mon, 20 Oct 2003, Steve Kargl wrote:
> > This looks very interesting!  Can we run ddb over the ethercon to debug
> > a wedged machine?
[ ... ]
> To support ethernet debugging, the debugger would need to be able to drive
> polling of the network interface in an interrupt-thread-free environment,
> and reproduce more of the lower level network code (i.e., not use mbufs,
> etc).  This is feasible to do, but would probably require adding new
> interfaces to the ethernet driver, and supporting only ethernet cards that
> had these additional debugging interfaces.  Compared to serial console,
> you'd also have a lot more situations where the driver/hardware state
> would be sufficiently inconsistent as to make debugging network-related
> crashes difficult.  On the other hand, Darwin runs quite well with a
> network debugger; I believe they have a fairly complex UDP/IP
> implementation in the network debugger, although I haven't inspected it.
> Apple has the advantage, though, of providing very few ethernet drivers.

It's pretty nifty.  It's very infrequent that a hang results in
something that can't be debugged remotely.  The only cases are
when an IP address and default route are unknown to the machine
at the time of the crash.  This can be overridden by providing
Open Firmware values, up front, to avoid the need to wait until
DHCP is up enough to get the IP (the DHCP implementation is very
low level, and happens very early on).  Assuming the bug reproduces.

You're right about the card support: it's a polled mode driver;
on the other hand, it's not really that difficult, even though
many ethernet drivers are loaded into the kernel as kext's (Kernel
Extensions); FreeBSD boot code can do similar magic up front, in
loading drivers as kernel modules.  So this actually should not be
very hard to put into any/all drivers.  It could go in slowly, like
multicast, soft interrupt coelescing, or DEVICE_POLLING did, so it's
not that big an issue (IMO): at least it's not all or nothing.


> So I'm happy to look at it, but the level of time investment to get to
> network debugging from the current (and pretty simple) ethercons device
> will be fairly high.  I know Jonathan Lemon was looking at network console
> and debugging code previously, but I don't have copies of his patches.  If
> I had to guess, I'd assume he had modified the if_fxp driver, and perhaps
> others, to provide an appropriate polled interface for use with a
> debugger, but I don't know for sure.  If someone has copies of these
> patches, I'd be happy to take a look at them.

The Darwin code is available, and isn't much changed in that area
from Jaguar to Panther, so the sources should still be good (FWIW),
if you wanted to look there.  If anything gets done, I'd dearly
love it to get done so that there was binary compatability enough
to be able to cross-debug systems, but of course, that would be up
to whoever had the time to invest in doing the work.

A neat feature of Panther is the ability to actually do system
dumps over the wire, if you enable them (and set the magic values).
The graduate student who did the original network kernel debugging
code in Darwin did that work over the past summer (I did the code
for integrating the sysctl's for him).  This might be more valuable
to FreeBSD than actually running a source debugger (or not), but
it's a lot of fun to play with (it uses a dumping protocol based on
a modified TFTP).  It would at least be useful in shops with 10
or more BSD working machines and one monitoring box, which have the
occasional crash.

-- Terry