0 0 3 0x14200 bored softnet
>> 4749 0 0 0 3 0x14200 bored systqmp
>> 16058 0 0 0 3 0x14200 bored systq
>> 15954 0 0 0 3 0x40014200idle0
>>1 0 1
> panic: mtx_enter: locking against myself
> Starting stack trace...
> panic() at panic+0x10b
> mtx_enter() at mtx_enter+0x60
> sofree() at sofree+0xa0
> in_pcbdetach() at in_pcbdetach+0x40
> tcp_close() at tcp_close+0xad
> tcp_timer_2msl() at tcp_timer_2msl+0x90
> sof
0 -1 0 0 3 0x10200 scheduler swapper
>
>> On 4 feb. 2016, at 13:49, mxb wrote:
>>
>>
>> I was able to re-produce this panic with similar stack trace.
>> Unfortunately 'trace/show regs/ps' are not in txt format, but are
screenshots.
>>
>>
>> Hey,
>> see those again on 5.8-STABLE.
>>
>> This is a 2-node CARP setup within VMWare ESX.
>> Both machines are rebooting after this and it happens quite often.
>>
>> Any ideas?
>>
>> panic: mtx_enter: locking again
setup within VMWare ESX.
> Both machines are rebooting after this and it happens quite often.
>
> Any ideas?
>
> panic: mtx_enter: locking against myself
> Starting stack trace...
> panic() at panic+0x10b
> mtx_enter() at mtx_enter+0x60
> sofree() at sofree+0xa0
> in_pcb
Hey,
see those again on 5.8-STABLE.
This is a 2-node CARP setup within VMWare ESX.
Both machines are rebooting after this and it happens quite often.
Any ideas?
panic: mtx_enter: locking against myself
Starting stack trace...
panic() at panic+0x10b
mtx_enter() at mtx_enter+0x60
sofree() at
Looks like I found the root cause.
At least it is stable as it suppose to be.
In need to reproduce this in lab before making next move.
//mxb
> On 17 sep. 2015, at 10:35, mxb wrote:
>
>
> Hey,
> getting panics with 5.8-STABLE kernel.
>
> panic: mix_enter: locking against myself
> Starting sta
Seems to happen very random.
I have two systems which do this. Both are 2-node CARP.
It is only kernel which is -STABLE on those two. Userland is from a snap
approx. 14 days old.
Update to stable kernel is done recently, because of those crashes.
Kernel before is running OK on more heavily loaded
On 2015-09-17, mxb wrote:
> Hey,
> getting panics with 5.8-STABLE kernel.
>
> panic: mix_enter: locking against myself
> Starting stack trace…
> panic() at panic+0x10b
> mtx_enter() at mtx_enter+0x60
> sofree() at sofree+0xa0
> in_pcbdetach() at in_pcbdetach+0x40
> tcp_close() at tcp_close+0xad
>
It is from CVS.
dmesg below.
OpenBSD 5.8-stable (GENERIC.MP) #0: Tue Sep 15 22:38:07 CEST 2015
r...@fw1.home.unixconn.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17051418624 (16261MB)
avail mem = 16530747392 (15764MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at roo
On Thu, 17 Sep 2015 10:35:46 +0200
mxb wrote:
> getting panics with 5.8-STABLE kernel.
>
5.8-STABLE not released yet. you mean 5.8-CURRENT?
and this is for a crash just 10min ago.
(gdb) file /var/crash/bsd.0
Reading symbols from /var/crash/bsd.0...(no debugging symbols found)...done.
(gdb) target kvm /var/crash/bsd.0.core
#0 0x8131cae4 in dumpsys ()
(gdb) where
#0 0x8131cae4 in dumpsys ()
#1 0x00030272 in ??
Hey,
getting panics with 5.8-STABLE kernel.
panic: mix_enter: locking against myself
Starting stack trace…
panic() at panic+0x10b
mtx_enter() at mtx_enter+0x60
sofree() at sofree+0xa0
in_pcbdetach() at in_pcbdetach+0x40
tcp_close() at tcp_close+0xad
tcp_timer_2msl() at tcp_timer_2msl+0x90
softcloc
t ---
Bad frame pointer: 0x8000225a8af0
end trace frame: 0x8000225a8af0, count: -9
sysctl_dopool+0x16f:
ddb{0}> show panic
mtx_enter: locking against myself
ddb{0}> show registers
ds0x7c01
es0x86e0
fs
Those panics seems to be related to GRE.
I switched from using gre to gif and was unable to reproduce this panic.
On 4 jan 2013, at 00:01, mxb wrote:
>
> scp from within internal network (network2) does not trigger this panic,
eg.
>
> client_on_network2# scp fw2.int_ip:/bsd .
>
>
> On 3 jan 2013
scp from within internal network (network2) does not trigger this panic, eg.
client_on_network2# scp fw2.int_ip:/bsd .
On 3 jan 2013, at 20:15, mxb wrote:
> client does 'scp fw2.network2_ip:/bsd .' - results in panic.
> client does 'scp fw2.public_ip:/bsd .' - all fine.
bsd.gdb just freezes and tells nothing at all.
after 5min of waiting for it to drop into ddb, I made power cycle.
On 3 jan 2013, at 22:31, mxb wrote:
>
> Now, the -current SP kernel, while triggering, has a better speed and dies a
> bit later with:
>
> kernel: type -1342060160 trap, code 0
>
Now, the -current SP kernel, while triggering, has a better speed and dies a
bit later with:
kernel: type -1342060160 trap, code 0
Stopped at 0x3deba01b052507f:
at this point I expected it to drop to ddb, but it didn't.
my sysctl.conf says:
ddb.panic=1 # 0=Do not drop into
Here is an older kernel which seems to die the same way.
I actually can not see mtx_enter-loop, but I trigger crash the same way. Remote
console via IPMI just blinks like a X-mass tree.
OpenBSD 5.2-current (GENERIC.MP) #0: Tue Nov 6 17:03:43 CET 2012
r...@esx9.my.domain:/usr/src/sys/arch/amd
Now, after several tests I can state that problem is there.
I made sure that /usr/src is clean and up to date (I had Hennings diffs on
test).
The stock -current kernel crashes with this behavior, eg. panic and loop with
mtx_enter on console.
This bug is triggered then I transfer /bsd over IPSec.
On 2013-01-03, mxb wrote:
> Sorry for the noise. I think I'v found the problem.
Any more information on what it was??
Even if it was something you've done, that should't happen..
>> On 1 jan 2013, at 19:11, mxb wrote:
>>>
>>> I'v got yet another panic.
>>> This time, after applying Martin Pe
Sorry for the noise. I think I'v found the problem.
On 1 jan 2013, at 23:54, mxb wrote:
>
> I just was able to reproduce this with up to date kernel.
>
> On 1 jan 2013, at 19:11, mxb wrote:
>
>>
>> Hi misc@,
>>
>> I'v got yet another panic.
>> This time, after applying Martin Pelikans' dif
I just was able to reproduce this with up to date kernel.
On 1 jan 2013, at 19:11, mxb wrote:
>
> Hi misc@,
>
> I'v got yet another panic.
> This time, after applying Martin Pelikans' diff, catched a pointer.
> However, machine never drops to ddb, even sysctl.conf says it should.
>
> panic: m
Hi misc@,
I'v got yet another panic.
This time, after applying Martin Pelikans' diff, catched a pointer.
However, machine never drops to ddb, even sysctl.conf says it should.
panic: mxt_enter: locking against myself, 0x80a2d540
kernel: privileged instruction fault trap, code=0
kernel: dou
On Wed, Sep 12, 2012 at 02:18:06PM +0200, Maxim Bourmistrov wrote:
> Hi,
>
> I'm getting "panic: mtx_enter: locking against myself" on not so
> -current OpenBSD 5.2-current (snapshot).
>
> Machine is not dropping into ddb even if sysctl.conf says it should
Hi,
I'm getting "panic: mtx_enter: locking against myself" on not so
-current OpenBSD 5.2-current (snapshot).
Machine is not dropping into ddb even if sysctl.conf says it should.
Console is filled with "panic: mtx_enter: locking against myself"
and seems to loop.
OpenBS
On Mon, Jul 19, 2010 at 02:34:52PM +0200, Martin Pelik??n wrote:
> Hello everyone.
> Yesterday I compiled some stuff from ports, when my i386 -current (about
> two days old) paniced (onproc was one of those cc(1)):
> Debugger(), panic(),
> mtx_enter+0x5a(d0a2fc20, d2bae000, d2baf000, 0, 0)
> uvm_ps
Hello everyone.
Yesterday I compiled some stuff from ports, when my i386 -current (about
two days old) paniced (onproc was one of those cc(1)):
Debugger(), panic(),
mtx_enter+0x5a(d0a2fc20, d2bae000, d2baf000, 0, 0)
uvm_pseg_release+0x6b
uvm_swap_allocpages+0x8d9
uvm_swap_get+0x38
uvm_fault_anonget
28 matches
Mail list logo
