|
||||||||
It happened again. 1t didn't last more than 2 hours this time before it locked up again. Now I setup PfSense with the same configuration so I'll find out soon it this is really the hardware or not. I'm keeping my finger crossed. Andrew Kemp wrote: > The first problem looks exactly like the problem that everyone else who > experiences this is having. My m0n0 would lock up and would have to be > manually rebooted, no error messages or logs, no keyboard input would > work, just flat out hard locked. A reboot always fixed the issue. > > I have since switched to pfsense to test it out and have not had a > single lockup yet. It has currently been running for around 30 days with > no issues. > > > Andrew > > -----Original Message----- > From: Max Cristin [mailto:max dot cristin at rogers dot com] > Sent: Friday, October 27, 2006 9:50 AM > To: Bernie O'Connor; m0n0wall at lists dot m0n0 dot ch > Subject: [m0n0wall] Re: Rreboots and lock ups > > I apologize if I didn't explain the problem well, but I was in a rush at > the time. I'm running 1.22 and the problems I've been experiencing are > essentially 2: > > - Monowall locks up and require a manual reboot (nothing logged about > this) > - Monowall sometimes automatically reboots (kernel panic log I posted) > > I found evidence the 2nd problem in the kernel logs only after I started > investigating the 1st one. Anyway, I successfully ran memtest86 > overnight for more than 8 hours on the host machine as suggested by > Craig) and when I originally built the host box few months ago I ran > prime95 for more than 24 hours without errors. > > Monowall is up and running now for a couple of hours and I'll keep an > eye on it. I'll post an update later. I also have another VM with > pfSense (not running). I'll try that if Monowall locks up again. Thanks. > > Max > > Bernie O'Connor wrote: >> Which image/version of m0n0wall are you running? >> >> Note - these are just my opinions and I'm not a freebsd expert - I'm > sure freebsd kernel experts would give you a better response but here > goes: >> I don't think this is a memory problem on your machine unless you get > some message in the windows event log: (Start->run->eventvwr then > look in system log). You may have captured the first hard evidence of a > kernel fault that has been causing m0n0wall reported lockups. Did your > system automatically reboot as the log appears to indicate? If if did, > this isn't like the reported problems, but if didn't ... >> Question- how did you capture the /kernel messages? Were they in the > virtual console of the vmware machine? If yes, then this is the type of > logging that no one's reported from syslogs and it seems very rare for a > typical m0n0wall system user to keep a console running so that may be > why no one else sees this type of error. Of course this could be a bug > in vmware and that would make it a new problem that hasn't been reported > before. >> bernie >> >> >> -----Original Message----- >> From: Max Cristin [mailto:max dot cristin at rogers dot com] >> Sent: Thursday, October 26, 2006 10:30 PM >> To: m0n0wall at lists dot m0n0 dot ch >> Subject: Rreboots and lock ups >> >> I'm running Monowall in a VMWare Server VM. I'm having problems with > the VM locking up quite frequently in the last few days. When it > happens, the host OS (Win XP) is working perfectly, but the VM where > monowall is running does not respond and I have to restart it. Nothing > out of the ordinary is logged at the time it locks up, but while > checking all the logs I found this logged few times a day: >> >> Oct 26 19:52:10 dmzgate /kernel: >> Oct 26 19:52:10 dmzgate /kernel: >> Oct 26 19:52:10 dmzgate /kernel: Fatal trap 12: page fault while in > kernel mode Oct 26 19:52:10 dmzgate /kernel: fault virtual address^I= > 0x6d657420 Oct 26 19:52:10 dmzgate /kernel: fault code^I^I= supervisor > read, page not present Oct 26 19:52:10 dmzgate /kernel: instruction > pointer^I= 0x8:0xc023329a >> Oct 26 19:52:10 dmzgate /kernel: stack pointer^I = > 0x10:0xc03f1988 >> Oct 26 19:52:10 dmzgate /kernel: frame pointer^I = > 0x10:0xc03f1990 >> Oct 26 19:52:10 dmzgate /kernel: code segment^I^I= base 0x0, limit > 0xfffff, type 0x1b Oct 26 19:52:10 dmzgate /kernel: = DPL 0, pres 1, > def32 1, gran 1 Oct 26 19:52:10 dmzgate /kernel: processor eflags^I= > interrupt enabled, resume, IOPL = 0 Oct 26 19:52:10 dmzgate /kernel: > current process^I^I= Idle Oct 26 19:52:10 dmzgate /kernel: interrupt > mask^I^I= net Oct 26 19:52:10 dmzgate /kernel: trap number^I^I= 12 Oct > 26 19:52:10 dmzgate /kernel: panic: page fault Oct 26 19:52:10 dmzgate > /kernel: >> Oct 26 19:52:10 dmzgate /kernel: syncing disks... >> Oct 26 19:52:10 dmzgate /kernel: >> Oct 26 19:52:10 dmzgate /kernel: Fatal trap 12: page fault while in > kernel mode Oct 26 19:52:10 dmzgate /kernel: fault virtual address^I= > 0x10 Oct 26 19:52:10 dmzgate /kernel: fault code^I^I= supervisor read, > page not present Oct 26 19:52:10 dmzgate /kernel: instruction pointer^I= > 0x8:0xc0307af6 >> Oct 26 19:52:10 dmzgate /kernel: stack pointer^I = > 0x10:0xc03f15fc >> Oct 26 19:52:10 dmzgate /kernel: frame pointer^I = > 0x10:0xc03f1654 >> Oct 26 19:52:10 dmzgate /kernel: code segment^I^I= base 0x0, limit > 0xfffff, type 0x1b Oct 26 19:52:10 dmzgate /kernel: = DPL 0, pres 1, > def32 1, gran 1 Oct 26 19:52:10 dmzgate /kernel: processor eflags^I= > interrupt enabled, resume, IOPL = 0 Oct 26 19:52:10 dmzgate /kernel: > current process^I^I= Idle Oct 26 19:52:10 dmzgate /kernel: interrupt > mask^I^I= net Oct 26 19:52:10 dmzgate /kernel: trap number^I^I= 12 Oct > 26 19:52:10 dmzgate /kernel: panic: page fault Oct 26 19:52:10 dmzgate > /kernel: Uptime: 1h36m20s Oct 26 19:52:10 dmzgate /kernel: Automatic > reboot in 15 seconds - press a key on the console to abort Oct 26 > 19:52:10 dmzgate /kernel: Rebooting... >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch |