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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"