[ previous ] [ next ] [ threads ]
 
 From:  Max Cristin <max dot cristin at rogers dot com>
 To:  Bernie O'Connor <Bernie dot OConnor at sas dot com>, m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: Rreboots and lock ups
 Date:  Fri, 27 Oct 2006 09:50:29 -0400
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...
> 
>