[ previous ] [ next ] [ threads ]
 
 From:  "Andrew Kemp" <akemp at iquest dot net>
 To:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall] Re: Rreboots and lock ups
 Date:  Fri, 27 Oct 2006 20:06:03 -0400
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