Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 Jun 2017 18:50:19 +0300
From:      "Oleg V. Nauman" <oleg@theweb.org.ua>
To:        Hans Petter Selasky <hps@selasky.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: HEAD/i386 r320212: three reproducible panics
Message-ID:  <3084228.CZavzcor0p@asus.theweb.org.ua>
In-Reply-To: <8a501e11-6bf8-4b38-c1d1-937c4b2f6745@selasky.org>
References:  <9394534.k5lyWsM15G@asus.theweb.org.ua> <6682061.Xu753KpcSl@asus.theweb.org.ua> <8a501e11-6bf8-4b38-c1d1-937c4b2f6745@selasky.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 30 June 2017 12:44:37 Hans Petter Selasky wrote:

 Hello Hans,

> On 06/30/17 11:01, Oleg V. Nauman wrote:
> > On Friday 23 June 2017 19:42:55 Oleg V. Nauman wrote:
> >>   a) Panic on shutdown:
> >> Fatal trap 1: privileged instruction fault while in kernel mode
> >> cpuid =3D 1; apic id =3D 01
> >> instruction pointer  =3D 0x20:0xc6be2023
> >> stack pointer          =3D 0x28:0xe13c39f4
> >> frame pointer          =3D 0x28:0xe13c3a20
> >> code segment      =3D base 0x0, limit 0xfffff, type 0x1b
> >>=20
> >>           =3D DPL 0, pres 1, def32 1, gran 1
> >>=20
> >> processor eflags  =3D interrupt enabled, resume, IOPL =3D 0
> >> current process      =3D 11 (swi1: netisr 0)
> >> trap number    =3D 1
> >> panic: privileged instruction fault
> >> cpuid =3D 1
> >> time =3D 1498206262
> >> Uptime: 6m19s
> >>=20
> >>   The trace is:
> >> __curthread () at ./machine/pcpu.h:225
> >> 225      __asm("movl %%fs:%1,%0" : "=3Dr" (td)
> >> (kgdb) #0  __curthread () at ./machine/pcpu.h:225
> >> #1  doadump (textdump=3D-968633472) at ../../../kern/kern_shutdown=
.c:318
> >> #2  0xc06e88c4 in kern_reboot (howto=3D<optimized out>)
> >>=20
> >>      at ../../../kern/kern_shutdown.c:386
> >>=20
> >> #3  0xc06e8c5b in vpanic (fmt=3D<optimized out>,
> >>=20
> >>      ap=3D0xe13c3874 "}\334\235\300H\254 \306\001")
> >>      at ../../../kern/kern_shutdown.c:779
> >>=20
> >> #4  0xc06e8b1b in panic (fmt=3D0xc092e18e "%s")
> >>=20
> >>      at ../../../kern/kern_shutdown.c:710
> >>=20
> >> #5  0xc08eed21 in trap_fatal (frame=3D0xe13c39b4, eva=3D<optimized=
 out>)
> >>=20
> >>      at ../../../i386/i386/trap.c:978
> >>=20
> >> #6  0xc08eea38 in trap (frame=3D<optimized out>)
> >>=20
> >>      at ../../../i386/i386/trap.c:704
> >>=20
> >> #7  <signal handler called>
> >> #8  0xc6be2023 in ?? ()
> >> #9  0xc082ed53 in tcp_do_segment (m=3D<optimized out>, th=3D<optim=
ized out>,
> >>=20
> >>      so=3D<optimized out>, tp=3D<optimized out>, drop_hdrlen=3D<op=
timized out>,
> >>      tlen=3D<optimized out>, iptos=3D<optimized out>,
> >>      ti_locked=3D<error reading variable: Cannot access memory at =
address
> >>      0x1>)
> >>=20
> >> at ../../../netinet/tcp_input.c:2444
> >> #10 0xc082c181 in tcp_input (mp=3D<optimized out>, offp=3D<optimiz=
ed out>,
> >>=20
> >>      proto=3D<optimized out>) at ../../../netinet/tcp_input.c:1191=

> >>=20
> >> #11 0xc0820878 in ip_input (m=3D0x0) at ../../../netinet/ip_input.=
c:823
> >> #12 0xc07d5d0f in netisr_process_workstream_proto (nwsp=3D<optimiz=
ed out>,
> >>=20
> >>      proto=3D<optimized out>) at ../../../net/netisr.c:899
> >>=20
> >> #13 swi_net (arg=3D<optimized out>) at ../../../net/netisr.c:946
> >> #14 0xc06bb3c5 in intr_event_execute_handlers (p=3D0x109, ie=3D<op=
timized
> >> out>)
> >>=20
> >>      at ../../../kern/kern_intr.c:1336
> >>=20
> >> #15 0xc06bb5f0 in ithread_execute_handlers (ie=3D<optimized out>,
> >>=20
> >>      p=3D<optimized out>) at ../../../kern/kern_intr.c:1349
> >>=20
> >> #16 ithread_loop (arg=3D0xc60e6d00) at ../../../kern/kern_intr.c:1=
430
> >> #17 0xc06b8a76 in fork_exit (callout=3D0xc06bb560 <ithread_loop>,
> >>=20
> >>      arg=3D<optimized out>, frame=3D<optimized out>)
> >>      at ../../../kern/kern_fork.c:1038
> >>=20
> >> #18 <signal handler called>
> >> (kgdb)
> >>=20
> >   Interesting enough that panic triggered by named shutdown ( well,=
 'rndc
> >=20
> > flush' is triggering this panic too )
> >=20
> >   rndc calling isc__app_ctxrun function and finally panics the syst=
em:
> > ---- lib/isc/unix/app.c ---
> >=20
> >              return (ISC_R_UNEXPECTED);
> >          =20
> >           }
> >=20
> > #ifndef HAVE_UNIXWARE_SIGWAIT
> >=20
> >           result =3D sigwait(&sset, &sig); <--- panic
> >           if (result =3D=3D 0) {
> >=20
> > ----------------------------
> >=20
> > variables are set to:
> >   sset=3D {__bits =3D {16387, 0, 0, 0}}
> >   sig =3D 134533280
>=20
> Here:
>=20
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220358

 Subscribed && updated.

>=20
> Try to turn off hyperthreading to get a more sensible panic.

 Done.

>=20
> Migh-t look like an issue with 32-bit systems and iflib.

 I do not know if this related to iflib ; iflib functions were not ment=
ioned=20
in backtraces.

>=20
> --HPS

--=20
=D0=9D=D0=B0=D1=83=D0=BC=D0=B0=D0=BD =D0=9E=D0=BB=D0=B5=D0=B3




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3084228.CZavzcor0p>