[ 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:  Sun, 29 Oct 2006 22:59:16 -0500
Ok, good and bad news... The good one is that I setup PfSense 1.0 
replicating the same identical setup I had in Monowall and it has been 
running for more than 48 hours without any problem.

The bad news is that this confirms (to me at least) once more that there 
is a problem with Monowall. Unfortunately beside the kernel panic logs I 
already posted, I don't have much more information to add. I will try it 
again when/if 1.23 will be released.

Max


Max Cristin wrote:
> 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
> 
> 
> ---------------------------------------------------------------------
> 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