Any chance you could hook up a serial console, set BREAK_TO_DEBUGGER in kernel options, and see if a serial break drops you to DDB over serial? Under some circumstances a serial break can be more effective getting into the debugger than a console break.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories
I have tried this and the serial port looks hung as well. I can't get any response at all. A kernel from the 16th works fine though (and drops me into DDB via serial so this works fine). As were in a code freeze there have not been that many commits in the last week so not much could have changed I guess between 16th and now.
I am planning to try two things:
1) Try the latest kernel after sam's commits to various tcp/divert code. I run ipfw2 and ipdivert/natd so you never know :)
2) NFS is still not working and I can't backtrack to previous kernels to find the date it broke due to statfs. As I believe it's still only me and soren who are affected by the looks of it and nobody else I assume there is something very very specifically wrong with my system. Maybe an old library left around and something not recompiled properly against a new one etc. I have no idea.
Basically though when the final 5.2-RELEASE is actually available I plan on reinstalling both my desktop and server machines from scratch with a full format and then cvsup to HEAD again to get rid of any cruft left around from my exploits with 5.0-RELEASE all the way through to present. I need to recompile all my ports at some point anyway really so I may as well just install them from scratch I figure.
It's possible this might fix NFS. Though I've noticed the NFS thing has become added to the showstopper list for 5.2 so I might have to try this with a JPSNAP instead I guess.
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
