On Sat, Dec 29, 2012 at 9:30 AM, epsilon <epsilo...@t-online.de> wrote: > On Sat, Dec 29, 2012 at 04:10:05AM -0800, Philip Guenther wrote: >> Your case, as far as you described it, is not the same as frantisek holop's. > > Right. Not totally the same. But some similarities.
<sigh> The _value_ of finding something in common is that the fix or plan of attack to diagnose it may carry over. If they _aren't_ actually similar, then trying to do that will just mislead you and waste your time. Since your case doesn't exhibit the key factor of his, a kernel assertion panic, trying to debug yours as if it did isn't likely to be productive, IMNSHO. >> Most of the descriptions I've seen have been too imprecise to help in >> diagnosis. >> "It freezes somewhere after "starting network daemons" and "starting >> local daemons". I >> tried to disable services I do not essentially need or to substitute >> them with other solutions. So far no findings here." >> >> Freezes 'somewhere'? Hard to make hypotheses about the cause when >> we're not told what processes were started, or whether it's consistent >> from freeze to freeze. If you turn on ddb.console=1 in sysctl.conf > > ddb.console=1 turned on now. Will check the next time the freeze > occurs. > >> can you break into ddb when it hangs? > > Shout at me, but the magic key mentioned in the manpage is ctrl+c on > i386, right? No. Try the second and third paragraphs of "man ddb". ... > Now what did I mean with somewhere: Randomly. The freeze happens > randomly after starting one of the daemons. There is no pattern. > Sometimes it freezes after starting sshd, sometimes later. In one case > the freeze was after the loginprompt appears. In most cases it's > earlier. If it *ever* froze before ifstated/squid/dante/whatever was started, then they are not required for it to occur. Indeed, happening that early tends to make me think it's something in the network stack, its configuration, and/or the network traffic that the machine sees. ... >> The title of the original thread was "snapshots total freeze", but >> there were dmesg's in the thread showing Aug kernel builds; for those >> who haven't tried running a (recent) snapshot, does your problem >> reproduce or change symptoms when you do? > > For now I don't want to update the system to a snapshot. My primary > reason is this would imply a complete new installation when 5.3 comes > out. The updateprocess ist described from stable to stable and not > anything else. I hope it's possible to find something without > switching to current/snapshot. This box survived two months 5.2, so > maybe the next four month will be survived too :\ Shout at me, but I > am a -stable user. Hmm, you mention later that you _have_ reproduced it on other hardware; can you install the current snapshot on to that other hardware and test with it? You could then leave your current box as is... > What makes me wonder is the following: Why did those freezes occur on > 5.2 and on snapshots starting in November? My box runs as a gateway > useing pppoe(4). Again I guessed: Maybe something "from the evil > internets" like those nasty bug we had once with protocol 0 (maybe > you remember the guy running nmap protocol scans through PF). So I did > not power on the DSL modem during boot for some days. But no success. > The box froze after one or two days during boot and without powered > modem. > > I think this is really the only thing I can exclude for sure. Because > my modem was switched off, it cannot be something triggered from the > "evil internets". It must be triggered from my local site. And > additionally, it must be triggered from within this box, because for > some days I powered on this box alone, i.e. all other machines on my > local network were still switched off. Again: Freezes after some days. No traffic but it freezes. Does your building/area get power "brownouts"? > But the network is still on topic: Someone claimed he had no freezes > if he disabled logging in PF. pflogd is started _after_ PF is enabled. > Did anyone check what happens if pflogd is started before PF? Maybe I > give it a try. It's just I feel uncomfortable in hacking /etc/rc. This > file is not intended to be changed by users, right? That seems very unlikely. If it was something like that I would expect it to be more consistent. Philip Guenther
