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.Received on Mon Nov 24 2003 - 03:22:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:30 UTC