NetBSD Problem Report #53062
From www@NetBSD.org Wed Feb 28 10:33:35 2018
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id E42EC7A1CC
for <gnats-bugs@gnats.NetBSD.org>; Wed, 28 Feb 2018 10:33:34 +0000 (UTC)
Message-Id: <20180228103333.BF0957A227@mollari.NetBSD.org>
Date: Wed, 28 Feb 2018 10:33:33 +0000 (UTC)
From: joseyluis@gmail.com
Reply-To: joseyluis@gmail.com
To: gnats-bugs@NetBSD.org
Subject: panic: SPL NOT LOWERED ON SYSCALL EXIT
X-Send-Pr-Version: www-1.0
>Number: 53062
>Category: port-i386
>Synopsis: panic: SPL NOT LOWERED ON SYSCALL EXIT
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: port-i386-maintainer
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Feb 28 10:35:00 +0000 2018
>Last-Modified: Wed Mar 07 11:30:00 +0000 2018
>Originator: Jose Luis Rodriguez Garcia
>Release: NetBSD-8 2018-02-27
>Organization:
>Environment:
NetBSD localhost 8.0_BETA NetBSD 8.0_BETA (GENERIC.201802271630Z) i386
>Description:
Executing a java linux program (jmeter) the system panics. It always crash at the 10-15 secondos of the begining the jmeter (it doesn't produce a high load in the Operative System).
localhost# crash -M *core -N *3
Crash version 8.0_BETA, image version 8.0_BETA.
System panicked: SPL NOT LOWERED ON SYSCALL EXIT
Backtrace from time of crash is available.
crash>
(gdb) bt
#0 0xc011e2a5 in cpu_reboot ()
#1 0xc0947c10 in vpanic ()
#2 0xc0947c9a in panic ()
#3 0xc01006ee in Xsyscall ()
#4 0xc01006fd in Xsyscall ()
#5 0xa7e500b3 in ?? ()
#6 0xa7ea0023 in ?? ()
#7 0xa7ea0023 in ?? ()
#8 0x003d0023 in ?? ()
#9 0xa7d47000 in ?? ()
#10 0x805aa400 in ?? ()
#11 0xa7e5ac38 in ?? ()
#12 0x00000065 in ?? ()
#13 0xa7e5ab98 in ?? ()
#14 0x00008912 in ?? ()
#15 0x00000000 in ?? ()
(gdb)
>How-To-Repeat:
Executing JMETER under Java 8 from Oracle
>Fix:
I don't know
>Release-Note:
>Audit-Trail:
From: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-i386/53062: panic: SPL NOT LOWERED ON SYSCALL EXIT
Date: Thu, 1 Mar 2018 01:10:41 +0000
I'm not sure what is happening from this backtrace.
Will you consider running ktruss -i on one of the parent linux
processes, outputting to stdout or a file, and seeing what the last
messages before a panic are?
Thanks.
From: Jose Luis Rodriguez Garcia <joseyluis@gmail.com>
To: gnats-bugs@netbsd.org
Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-i386/53062: panic: SPL NOT LOWERED ON SYSCALL EXIT
Date: Fri, 2 Mar 2018 10:17:59 +0100
--001a1134ee64dbcfc705666a73a5
Content-Type: text/plain; charset="UTF-8"
I am runing NetBSD i386 under VirtualBox 5.2.6 r120293
After the system panics, if I don't power off the server on VirtualBox, I
can't reproduce the panic after the system reboot (altough I am not sure
that it works 100% reliable).
This is the copied output from a screen capture (copied by hand) with
ktruss -i
568 679 java clock_gettime(0x1, 0xa8904f60) = 0
568 679 java clock_gettime(0x1, 0xa8904ea8) = 0
568 749 java futex(0x81632728, 0x81, 0x1, 0x8163728, 0, 0xa76fea38) = 0
568 749 java clock_gettime(0x1, 0xa76feab0) = 0
568 749 java clock_gettime(0x1, 0xa76fea18) = 0
568 602 java futex(0xbac2c428, 0x81, 0x1, 0xbac2c428, 0, 0xb8aaf0d8) = 0
568 602 java clock_gettime(0x1, 0xb8aaf0b8) = 0
568 645 java futex(0xbac44328, 0x81, 0x1, 0xbac44328, 0, 0xa89d4ee8) = 0
568 645 java clock_gettime(0x1, 0xa89d4ec8) = 0
568 940 java clock_gettime = 0
568 940 java clock_gettime(0x1, 0xa7e5b6bc) = 0
568 940 java clock_gettime(0x1, 0xa7e5b6cc) = 0
panic: SPL NOT LOWERED ON SYSCALL EXIT
cpu0 Begin traceback....
vpanic(c01006fd,db258fa8,a7e5ab38,c01006ee,c01006fd,a7e500b3,a7ea0023,a7ea0023,3d0023,a7d42c00)
at netbsd:vpanic+0x121
snprintf(c01006fd,a7e500b3,a7e500b3,a7ea0023,a7ea0023,3d0023,a7d42c00,805aa400,a7e5ab38,65,a7e5aa98)
at netbsd:snprintf
cpu0: End of traceback...
dumping to dev 0,1 offset 2099624
dump 69 68 67 66 65 64 63 62 61 60 59 58 57 ......
From: Jose Luis Rodriguez Garcia <joseyluis@gmail.com>
To: gnats-bugs@netbsd.org
Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-i386/53062: panic: SPL NOT LOWERED ON SYSCALL EXIT
Date: Wed, 7 Mar 2018 08:32:28 +0100
--001a113ec948ba7cef0566cd8fbc
Content-Type: text/plain; charset="UTF-8"
With a kernel compiled with DEBUG and LOCKDEBUG I obtain this error from
kernel (green color):
execve_loadvm: check exec failed 8
execve_loadvm: check exec failed 8
execve_loadvm: check exec failed 8
execve_loadvm: check exec failed 8
It is just at beginning and several seconds before of the crash. I don't
know if it can be related to the panic.
On Fri, Mar 2, 2018 at 10:17 AM, Jose Luis Rodriguez Garcia <
joseyluis@gmail.com> wrote:
> I am runing NetBSD i386 under VirtualBox 5.2.6 r120293
> After the system panics, if I don't power off the server on VirtualBox, I
> can't reproduce the panic after the system reboot (altough I am not sure
> that it works 100% reliable).
>
> This is the copied output from a screen capture (copied by hand) with
> ktruss -i
>
> 568 679 java clock_gettime(0x1, 0xa8904f60) = 0
> 568 679 java clock_gettime(0x1, 0xa8904ea8) = 0
> 568 749 java futex(0x81632728, 0x81, 0x1, 0x8163728, 0, 0xa76fea38) = 0
> 568 749 java clock_gettime(0x1, 0xa76feab0) = 0
> 568 749 java clock_gettime(0x1, 0xa76fea18) = 0
> 568 602 java futex(0xbac2c428, 0x81, 0x1, 0xbac2c428, 0, 0xb8aaf0d8) = 0
> 568 602 java clock_gettime(0x1, 0xb8aaf0b8) = 0
> 568 645 java futex(0xbac44328, 0x81, 0x1, 0xbac44328, 0, 0xa89d4ee8) = 0
> 568 645 java clock_gettime(0x1, 0xa89d4ec8) = 0
> 568 940 java clock_gettime = 0
> 568 940 java clock_gettime(0x1, 0xa7e5b6bc) = 0
> 568 940 java clock_gettime(0x1, 0xa7e5b6cc) = 0
> panic: SPL NOT LOWERED ON SYSCALL EXIT
>
> cpu= Begin traceback....
> vpanic(c01006fd,db258fa8,a7e5ab38,c01006ee,c01006fd,
> a7e500b3,a7ea0023,a7ea0023,3d0023,a7d42c00) at netbsd:vpanic+0x121
> snprintf(c01006fd,a7e500b3,a7e500b3,a7ea0023,a7ea0023,
> 3d0023,a7d42c00,805aa400,a7e5ab38,65,a7e5aa98) at netbsd:snprintf
> cpu: End of traceback...
> dumping to dev 0,1 offset 2099624
> dump 69 68 67 66 65 64 63 62 61 60 59 58 57 ......
>
>
>
>
>
> On Thu, Mar 1, 2018 at 2:15 AM, <coypu@sdf.org> wrote:
>
>> The following reply was made to PR port-i386/53062; it has been noted by
>> GNATS.
>>
>> From: coypu@sdf.org
>> To: gnats-bugs@NetBSD.org
>> Cc:
>> Subject: Re: port-i386/53062: panic: SPL NOT LOWERED ON SYSCALL EXIT
>> Date: Thu, 1 Mar 2018 01:10:41 +0000
>>
>> I'm not sure what is happening from this backtrace.
>>
>> Will you consider running ktruss -i on one of the parent linux
>> processes, outputting to stdout or a file, and seeing what the last
>> messages before a panic are?
>>
>> Thanks.
>>
>>
>
--001a113ec948ba7cef0566cd8fbc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>With a kernel compiled with DEBUG and LOCKDEBUG =
I obtain this error from kernel (green color):<br></div>execve_loadvm: chec=
k exec failed 8<br>
execve_loadvm: check exec failed 8
<br>
execve_loadvm: check exec failed 8
<br>
execve_loadvm: check exec failed 8
<br><br></div>It is just at beginning and several seconds before of the cra=
sh. I don't know if it can be related to the panic.<br></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Mar 2, 2018 at 10:1=
7 AM, Jose Luis Rodriguez Garcia <span dir=3D"ltr"><<a href=3D"mailto:jo=
seyluis@gmail.com" target=3D"_blank">joseyluis@gmail.com</a>></span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><div>=
<div><div><div><div><div><div><div><div><div><div>I am runing NetBSD i386 u=
nder VirtualBox 5.2.6 r120293<br></div>After the system panics, if I don=
9;t power off the server on VirtualBox, I can't reproduce the panic aft=
er the system reboot (altough I am not sure that it works 100% reliable).<b=
r><br></div>This is the copied output from a screen capture (copied by hand=
) with ktruss -i<br><br></div>568 679 java clock_gettime(0x1, 0xa8904f60) =
=3D 0<br></div>568 679 java clock_gettime(0x1, 0xa8904ea8) =3D 0<br></div>5=
68 749 java futex(0x81632728, 0x81, 0x1, 0x8163728, 0, 0xa76fea38) =3D 0<br=
></div>568 749 java clock_gettime(0x1, 0xa76feab0) =3D 0<br></div>568 749 j=
ava clock_gettime(0x1, 0xa76fea18) =3D 0<br></div>568 602 java futex(0xbac2=
c428, 0x81, 0x1, 0xbac2c428, 0, 0xb8aaf0d8) =3D 0<br></div>568 602 java clo=
ck_gettime(0x1, 0xb8aaf0b8) =3D 0<br></div>568 645 java futex(0xbac44328, 0=
x81, 0x1, 0xbac44328, 0, 0xa89d4ee8)=C2=A0 =3D 0<br></div>568 645 java cloc=
k_gettime(0x1, 0xa89d4ec8) =3D 0<br></div>568 940 java clock_gettime=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0<wbr>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=3D 0<br></div>568 940 java clock_gettime(0x1, 0xa7e5b6bc) =3D 0<br></div>5=
68 940 java clock_gettime(0x1, 0xa7e5b6cc) =3D 0<br><div><div><span class=
=3D""><div>panic: SPL NOT LOWERED ON SYSCALL EXIT<br></div></span><div><br>=
cpu=3D Begin traceback....<br></div><div><div><div><div><div><div><div><div=
><div><div><div><div><div><div>vpanic(c01006fd,db258fa8,<wbr>a7e5ab38,c0100=
6ee,c01006fd,<wbr>a7e500b3,a7ea0023,a7ea0023,<wbr>3d0023,a7d42c00) at netbs=
d:vpanic+0x121<br></div><div>snprintf(c01006fd,a7e500b3,<wbr>a7e500b3,a7ea0=
023,a7ea0023,<wbr>3d0023,a7d42c00,805aa400,<wbr>a7e5ab38,65,a7e5aa98) at ne=
tbsd:snprintf<br></div><div>cpu: End of traceback...<br></div><div>dumping =
to dev 0,1 offset 2099624<br></div><div>dump 69 68 67 66 65 64 63 62 61 60 =
59 58 57 ......<br></div><div><br><br><br><br></div></div></div></div></div=
></div></div></div></div></div></div></div></div></div></div></div></div><d=
iv class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Thu, Mar 1, 2018 at 2:15 AM, <span dir=3D"ltr"><=
;<a href=3D"mailto:coypu@sdf.org" target=3D"_blank">coypu@sdf.org</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">The following reply was made=
to PR port-i386/53062; it has been noted by GNATS.<br>
<br>
From: <a href=3D"mailto:coypu@sdf.org" target=3D"_blank">coypu@sdf.org</a><=
br>
To: gnats-bugs@NetBSD.org<br>
Cc:<br>
Subject: Re: port-i386/53062: panic: SPL NOT LOWERED ON SYSCALL EXIT<br>
Date: Thu, 1 Mar 2018 01:10:41 +0000<br>
<br>
=C2=A0I'm not sure what is happening from this backtrace.<br>
<br>
=C2=A0Will you consider running ktruss -i on one of the parent linux<br>
=C2=A0processes, outputting to stdout or a file, and seeing what the last<b=
r>
=C2=A0messages before a panic are?<br>
<br>
=C2=A0Thanks.<br>
<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
--001a113ec948ba7cef0566cd8fbc--
From: Jose Luis Rodriguez Garcia <joseyluis@gmail.com>
To: gnats-bugs@netbsd.org
Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-i386/53062: panic: SPL NOT LOWERED ON SYSCALL EXIT
Date: Wed, 7 Mar 2018 08:41:49 +0100
The execve_loadvm: check exec failed 8 error is a cosmetic messages
when debug kernel is used: kern/52744. It is a different problem.
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-i386/53062: panic: SPL NOT LOWERED ON SYSCALL EXIT
Date: Wed, 07 Mar 2018 18:27:29 +0700
Date: Wed, 7 Mar 2018 07:35:01 +0000 (UTC)
From: Jose Luis Rodriguez Garcia <joseyluis@gmail.com>
Message-ID: <20180307073501.8E5C97A221@mollari.NetBSD.org>
| With a kernel compiled with DEBUG and LOCKDEBUG I obtain this error from
| kernel (green color):
| execve_loadvm: check exec failed 8
That's just from having DEBUG enabled, when an attempt is made to exec
something which is not executable - which, while not all that common, is also
not that unusual or special. On NetBSD -current the message would include
the path that failed to exec, but that's not in the message in -7 or -8. The
"8" in the message is ENOEXEC (NetBSD -current won't print the debug message
in that case - but -7 and -8 still do - it was deleted as it is really not
interesting.)
You should be able to recreate it easily enough by copying some random
binary file (not an executable or .o file etc) to /tmp/foo making sure 'x'
permission is set, then simply try to run /tmp/foo - that message should
appear (from a DEBUG kernel) without any other effects (obviously no
attempt will actually be made to run /tmp/foo - though depending upon
which shell you use, it might try to interpret it as a script - in fact that
is probably the easiest demo, use
echo I ran
(just that one line, no #! at the start) as /tmp/foo. You should see the
message from the kernel (the DEBUG message) followed by "I ran" when
the shell interprets the script.
Sorry this is no help with the actual cause of the probem, but it might help
by avoiding wasting time on irrelevant issues.
kre
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home