[ previous ] [ next ] [ threads ]
 
 From:  Max Cristin <max dot cristin at rogers dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Re: Rreboots and lock ups
 Date:  Sat, 28 Oct 2006 00:51:23 -0400
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