matt at xtaz.net
Mon Nov 24 04:22:01 PST 2003
Robert Watson wrote:
> 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
> robert at fledge.watson.org 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.
More information about the freebsd-current