On Tue, Oct 18, 2011 at 09:58:39AM +0000, Stuart Henderson wrote: > On 2011-10-18, Leon Me?ner <l.mess...@physik.tu-berlin.de> wrote: > > On Mon, Oct 17, 2011 at 08:43:50PM +0000, Stuart Henderson wrote: > >> This is what a BREAK on a serial console looks like. > >> > > On Mon, Oct 17, 2011 at 07:02:07PM +0200, Leon Me_ner wrote: > > Thats the way i got the ddb output. What's the interesting output then > > in this case? As suggested i'll try to get another machine going and > > test with that. This one did unfreeze after an undetermined amount of > > time after i unplugged all network devices in the internal 192.x lan > > segment. > > Depending on the cause, besides ps/trace, these are some of the more > useful things you can type: > > sh reg > sh malloc > sh all pools > sh uvmexp > > Not sure what else to suggest from ddb, with this type of problem > it's sadly really difficult to get useful information. If you can't > take diagnosis further, giving as much information as possible about > the setup and what you're doing at the time in the hope that somebody > has the time/ability to reproduce and debug it is often all you can do.
Yes I see. I will try to minimize the setup and see if i can create some nice description of the problem. > On 2011-10-17, Leon Me?ner <l.mess...@physik.tu-berlin.de> wrote: > > we are running a backup firewall machine which regularly freezes since > > OpenBSD 4.6. The configuration also changed at this time. When frozen no > > input is accepted by serial or keyboard console. Breaking to ddb works > > though. The output of ps and trace are below. The machine is primarily > > working as a transparent firewalling bridge but also runs NAT, pf and > > dhcpd for a 192.168.x/24. The freeze can often be provoked by obtaining > > an IP in the 192.168.x/24 and immediately sshing from this network into > > a Host on the bridged network part. > > Is the natted network, 192.168.x, also involved in the bridge? If so, and > if that can be changed, that might be worth investigating. I think many of > us are generally trying to avoid bridges, so it's not going to be the best- > tested part of the network stack... The natted network has a dedicated NIC on the firewall (incoming). The IP that the network gets natted to is an alias on the management NIC (outgoing). The bridge is between two seperate NIC's that are not used for anything else and one of these NIC's is disabled by spanning-tree on the switch side. Thanks with all the help, Leon
