Re: head -r320482 vs. TARGET_ARCH=powerpc production style kernel: jumps to non-code and traps (involves ->sol_upcall pointing to ->so_rdsel) bugzilla 220404
[It looks like the 2 anonymous structs
in the union in the new "struct socket"
are being abused such that the ->sol_upcall
from the 2nd struct is being access when it
has a value that was apparently assigned
via ->so_rcv->sb_sel . Details follow,
added to prior notes that I sent out.
I've submitted bugzilla 220404 for this.
The new detailed material is interlaced
with earlier material that I'd sent out.]
On 2017-Jun-30, at 2:07 AM, Mark Millard wrote:
> The -r320482 kernel build is via gcc 4.2.1.
> Both gcc 4.2.1 and clang based worlds show
> the same problems. TARGET_ARCH=powerpc64
> is not showing the problems.
>
> The production kernel build fails
> but the debug works --each built
> from the same /usr/src/ tree.
>
> I'll note what a normal boot does
> before getting to the login prompt but
> after "Starting nfsd." ("Updating motd:"
> can be mixed in the trap text: not shown
> below.)
>
> I use an example and note a lot about what
> varies and what stays the same from example
> boot to example boot of the production
> kernel.
>
> [Manually entered from camera pictures
> of the screen.]
>
> fatal kernel trap
> exception = 0x700 (program) (for "illegal instruction")
> srr0 = 0x70bf878 (note: this varies, for example: 0x5e37230)
>(note: r0 always matches srr0)
>(note: ctr always matches srr0)
> srr1 = 0x89032 (stays the same)
> lr= 0x5b7b94 (note: solisten_wakeup+0x4c) (stays the same)
> curthread = 0x5ab8ae0 (varies)
> pid = 920 (varies), comm = mountd (stays the same)
>
> Tracing command mountd pid 920 tid 100119 (varies) td 0x5ab8ae0 (varies)(CPU
> 1)
> (stack addr
> range varies)
> 0xd250a500: at soisconnected+0x21c (at stays the same)
> 0xd250a540: at unp_connect2+0xf0 (at stays the same)
> 0xd250a560: at unp_connectat+0x658 (at stays the same)
> 0xd250a770: at unp_connect+0x2c(at stays the same)
> 0xd250a790: at uipc_connect+0xc0 (at stays the same)
> 0xd250a7d0: at soconnectat+0xa0(at stays the same)
> 0xd250a800: at soconnect+0x2c (at stays the same)
> 0xd250a820: at kern_connect+0134 (at stays the same)
> 0xd250a870: at sys_connect+0x64(at stays the same)
> 0xd250a8b0: at trap+0x638 (at stays the same)
> 0xd250aa50: at powerpc_interrupt+0x1a0 (at stays the same)
> 0xd250aa80: at user SC trap (at stays the same)
>by 0x419db168 (stays the same)
>srr1=0xf032 (stays the same)
>r1 =0xd5e0 (stays the same)
>cr =0x24440840 (stays the same)
>xer =0x2000 (stays the same)
>ctr =0x419db160 (stays the same)
(these are
objdump
reported
addresses)
> 005b7b48 stwur1,-32(r1)
> 005b7b4c mflrr0
> 005b7b50 stw r29,20(r1)
> 005b7b54 stw r30,24(r1)
> 005b7b58 stw r31,28(r1)
> 005b7b5c stw r0,36(r1)
> 005b7b60 mr r31,r1
> 005b7b64 bcl-20,4*cr7+so,005b7b68
>
> 005b7b68 mflrr30
> 005b7b6c lwz r0,-36(r30)
> 005b7b70 add r30,r0,r30
> 005b7b74 mr r29,r3
> 005b7b78 lwz r0,232(r3)
> 005b7b7c cmpwi cr7,r0,0
> 005b7b80 beq-cr7,005b7b98
> 005b7b84 lwz r4,236(r3)
> 005b7b88 li r5,1
> 005b7b8c mtctr r0
> 005b7b90 bctrl
> lr:
> 005b7b94 b 005b7bb4
> . . .
>
> Apparently this means that sol->sol_upcall is not
> pointing to code at all yet is not null. Given the
> variability observed, it might be uninitialized
> --or sol itself is junk. . .
Note: r3 reported as: 0x70bf860
void
solisten_wakeup(struct socket *sol)
{
if (sol->sol_upcall != NULL)
(void )sol->sol_upcall(sol, sol->sol_upcallarg, M_NOWAIT);
else {
selwakeuppri(>so_rdsel, PSOCK);
KNOTE_LOCKED(>so_rdsel.si_note, 0);
}
SOLISTEN_UNLOCK(sol);
wakeup_one(>sol_comp);
}
(kgdb) print/x &((struct socket*)0x70bf860)->sol_upcall
$3 = 0x70bf948
(kgdb) print/x ((struct socket*)0x70bf860)->sol_upcall
$2 = 0x70bf878
(kgdb) print/x &((struct socket*)0x70bf860)->so_rdsel
$7 = 0x70bf878
(kgdb) print/x &((struct socket*)0x70bf860)->so_rdsel.si_tdlist
$8 = 0x70bf878
(kgdb) print/x &((struct socket*)0x70bf860)->so_rdsel.si_tdlist.tqh_first
$9 = 0x70bf878
But comparing to the first anonymous struct in
the union in the new "struct socket":
(kgdb) print/x &((struct socket*)0x70bf860)->sol_upcall
$15 = 0x70bf948
(kgdb) print/x &((struct socket*)0x70bf860)->so_rcv->sb_sel
$22 = 0x70bf948
->so_rcv is a struct sockbuf and
Final Call for 2017Q2 Quarterly Status Reports
Dear FreeBSD Community, Only one week remains before the July 7 deadline for submitting entries for the next FreeBSD Quarterly Status update, covering work done in April through June. Please consider submitting an entry for work you have done this quarter, even if it seems minor to you. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about work that is underway and completed. Submission of reports is not restricted to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at mont...@freebsd.org . (Do be sure, though, to save the form output and not the form itself!) There is also an XML template [2] that can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We look forward to seeing your 2017 reports! Thanks, Ben (on behalf of monthly@) [1] https://www.FreeBSD.org/cgi/monthly.cgi [2] https://www.FreeBSD.org/news/status/report-sample.xml [3] https://www.FreeBSD.org/news/status/howto.html [4] https://www.FreeBSD.org/news/status/report-2017-01-2017-03.html [5] https://www.FreeBSD.org/news/status/report-2016-10-2016-12.html signature.asc Description: PGP signature
Re: about history:)
On Fri, 2017-06-30 at 21:19 +0300, Toomas Soome wrote: > hi! > > there is an question about the tty line (canonical) mode — the > internal implementation is using 2k buffer, but the related (public) > constants are claiming buffer size about 255 chars. Why it is so - > any hints about the background there? > > #define MAX_CANON 255 /* max bytes in term canon > input line */ > #define MAX_INPUT 255 /* max bytes in terminal > input */ > > rgds, > toomas I don't have a direct answer to the question, but I do remember even before the rewrite that gave us the current kern/tty.c and friends, the old tty code had a #undef MAX_INPUT and then redefined it to 8K, with a comment that the value in limits.h was "wrong". From that I might surmise that people over the years were afraid of changing values in public header files that were handed down from the depths of unix history and that might break something if changed. I'm not sure MAX_CANON has a separate meaning from MAX_INPUT with the current code. I think both raw and canonical input use the same buffering scheme that's based on a linked list of 128-byte chunks. The total size of all the chunks on the list isn't compile-time constant, it's choosen at device open time to provide a buffer that is the smaller of 64K or 2 seconds of incoming data. (The code comment for years said 0.2 seconds of data, and perhaps that was the intent, but I corrected the comment rather than the code because .2s just isn't enough for slow embedded systems). You mention a 2k buffer... at the default input speed of 9600 baud the 2-seconds-size buffer is 1920 bytes. Pseudo-ttys and video consoles all seem to get this size. I just noticed there's nothing in the current code to prevent a pathologic buffer size of 0 if the input line speed is set to 0 but the CREAD flag is set (I think maybe a /dev/.init or .lock file could set the speed to 0). -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: column regression after https://svnweb.freebsd.org/base?view=revision=r320472
On Fri, Jun 30, 2017 at 09:34:42PM +0300, Oleg Ginzburg wrote: > Hi, > > This commit https://svnweb.freebsd.org/base?view=revision=r320472 > breaks column(1) (and can affect something else this way ). Try to execute > sample from man r320472: > > ( printf "PERM LINKS OWNER GROUP SIZE MONTH DAY " ; printf "HH:MM/YEAR > NAME\n" > ; ls -l | sed 1d ) | column -t > > column: line too long > Indeed, there is a typo. The following fixed the issue for me. diff --git a/lib/libc/stdio/fgetws.c b/lib/libc/stdio/fgetws.c index 83d697ea958..f47fea79934 100644 --- a/lib/libc/stdio/fgetws.c +++ b/lib/libc/stdio/fgetws.c @@ -116,7 +116,7 @@ ok: ret = ws; end: FUNLOCKFILE_CANCELSAFE(); - return (ws); + return (ret); error: ret = NULL; ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
column regression after https://svnweb.freebsd.org/base?view=revision=r320472
Hi, This commit https://svnweb.freebsd.org/base?view=revision=r320472 breaks column(1) (and can affect something else this way ). Try to execute sample from man r320472: ( printf "PERM LINKS OWNER GROUP SIZE MONTH DAY " ; printf "HH:MM/YEAR NAME\n" ; ls -l | sed 1d ) | column -t column: line too long ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
about history:)
hi! there is an question about the tty line (canonical) mode — the internal implementation is using 2k buffer, but the related (public) constants are claiming buffer size about 255 chars. Why it is so - any hints about the background there? #define MAX_CANON 255 /* max bytes in term canon input line */ #define MAX_INPUT 255 /* max bytes in terminal input */ rgds, toomas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEAD/i386 r320212: three reproducible panics
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 = 1; apic id = 01
> >> instruction pointer = 0x20:0xc6be2023
> >> stack pointer = 0x28:0xe13c39f4
> >> frame pointer = 0x28:0xe13c3a20
> >> code segment = base 0x0, limit 0xf, type 0x1b
> >>
> >> = DPL 0, pres 1, def32 1, gran 1
> >>
> >> processor eflags = interrupt enabled, resume, IOPL = 0
> >> current process = 11 (swi1: netisr 0)
> >> trap number= 1
> >> panic: privileged instruction fault
> >> cpuid = 1
> >> time = 1498206262
> >> Uptime: 6m19s
> >>
> >> The trace is:
> >> __curthread () at ./machine/pcpu.h:225
> >> 225 __asm("movl %%fs:%1,%0" : "=r" (td)
> >> (kgdb) #0 __curthread () at ./machine/pcpu.h:225
> >> #1 doadump (textdump=-968633472) at ../../../kern/kern_shutdown.c:318
> >> #2 0xc06e88c4 in kern_reboot (howto=)
> >>
> >> at ../../../kern/kern_shutdown.c:386
> >>
> >> #3 0xc06e8c5b in vpanic (fmt=,
> >>
> >> ap=0xe13c3874 "}\334\235\300H\254 \306\001")
> >> at ../../../kern/kern_shutdown.c:779
> >>
> >> #4 0xc06e8b1b in panic (fmt=0xc092e18e "%s")
> >>
> >> at ../../../kern/kern_shutdown.c:710
> >>
> >> #5 0xc08eed21 in trap_fatal (frame=0xe13c39b4, eva=)
> >>
> >> at ../../../i386/i386/trap.c:978
> >>
> >> #6 0xc08eea38 in trap (frame=)
> >>
> >> at ../../../i386/i386/trap.c:704
> >>
> >> #7
> >> #8 0xc6be2023 in ?? ()
> >> #9 0xc082ed53 in tcp_do_segment (m=, th=,
> >>
> >> so=, tp=, drop_hdrlen=,
> >> tlen=, iptos=,
> >> ti_locked= >> 0x1>)
> >>
> >> at ../../../netinet/tcp_input.c:2444
> >> #10 0xc082c181 in tcp_input (mp=, offp=,
> >>
> >> proto=) at ../../../netinet/tcp_input.c:1191
> >>
> >> #11 0xc0820878 in ip_input (m=0x0) at ../../../netinet/ip_input.c:823
> >> #12 0xc07d5d0f in netisr_process_workstream_proto (nwsp=,
> >>
> >> proto=) at ../../../net/netisr.c:899
> >>
> >> #13 swi_net (arg=) at ../../../net/netisr.c:946
> >> #14 0xc06bb3c5 in intr_event_execute_handlers (p=0x109, ie= >> out>)
> >>
> >> at ../../../kern/kern_intr.c:1336
> >>
> >> #15 0xc06bb5f0 in ithread_execute_handlers (ie=,
> >>
> >> p=) at ../../../kern/kern_intr.c:1349
> >>
> >> #16 ithread_loop (arg=0xc60e6d00) at ../../../kern/kern_intr.c:1430
> >> #17 0xc06b8a76 in fork_exit (callout=0xc06bb560 ,
> >>
> >> arg=, frame=)
> >> at ../../../kern/kern_fork.c:1038
> >>
> >> #18
> >> (kgdb)
> >>
> > Interesting enough that panic triggered by named shutdown ( well, 'rndc
> >
> > flush' is triggering this panic too )
> >
> > rndc calling isc__app_ctxrun function and finally panics the system:
> > lib/isc/unix/app.c ---
> >
> > return (ISC_R_UNEXPECTED);
> >
> > }
> >
> > #ifndef HAVE_UNIXWARE_SIGWAIT
> >
> > result = sigwait(, ); <--- panic
> > if (result == 0) {
> >
> >
> >
> > variables are set to:
> > sset= {__bits = {16387, 0, 0, 0}}
> > sig = 134533280
>
> Here:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220358
Subscribed && updated.
>
> Try to turn off hyperthreading to get a more sensible panic.
Done.
>
> 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 mentioned
in backtraces.
>
> --HPS
--
Науман Олег
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEAD/i386 r320212: three reproducible panics
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 = 1; apic id = 01
instruction pointer = 0x20:0xc6be2023
stack pointer = 0x28:0xe13c39f4
frame pointer = 0x28:0xe13c3a20
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 11 (swi1: netisr 0)
trap number= 1
panic: privileged instruction fault
cpuid = 1
time = 1498206262
Uptime: 6m19s
The trace is:
__curthread () at ./machine/pcpu.h:225
225 __asm("movl %%fs:%1,%0" : "=r" (td)
(kgdb) #0 __curthread () at ./machine/pcpu.h:225
#1 doadump (textdump=-968633472) at ../../../kern/kern_shutdown.c:318
#2 0xc06e88c4 in kern_reboot (howto=)
at ../../../kern/kern_shutdown.c:386
#3 0xc06e8c5b in vpanic (fmt=,
ap=0xe13c3874 "}\334\235\300H\254 \306\001")
at ../../../kern/kern_shutdown.c:779
#4 0xc06e8b1b in panic (fmt=0xc092e18e "%s")
at ../../../kern/kern_shutdown.c:710
#5 0xc08eed21 in trap_fatal (frame=0xe13c39b4, eva=)
at ../../../i386/i386/trap.c:978
#6 0xc08eea38 in trap (frame=)
at ../../../i386/i386/trap.c:704
#7
#8 0xc6be2023 in ?? ()
#9 0xc082ed53 in tcp_do_segment (m=, th=,
so=, tp=, drop_hdrlen=,
tlen=, iptos=,
ti_locked=)
at ../../../netinet/tcp_input.c:2444
#10 0xc082c181 in tcp_input (mp=, offp=,
proto=) at ../../../netinet/tcp_input.c:1191
#11 0xc0820878 in ip_input (m=0x0) at ../../../netinet/ip_input.c:823
#12 0xc07d5d0f in netisr_process_workstream_proto (nwsp=,
proto=) at ../../../net/netisr.c:899
#13 swi_net (arg=) at ../../../net/netisr.c:946
#14 0xc06bb3c5 in intr_event_execute_handlers (p=0x109, ie=)
at ../../../kern/kern_intr.c:1336
#15 0xc06bb5f0 in ithread_execute_handlers (ie=,
p=) at ../../../kern/kern_intr.c:1349
#16 ithread_loop (arg=0xc60e6d00) at ../../../kern/kern_intr.c:1430
#17 0xc06b8a76 in fork_exit (callout=0xc06bb560 ,
arg=, frame=)
at ../../../kern/kern_fork.c:1038
#18
(kgdb)
Interesting enough that panic triggered by named shutdown ( well, 'rndc
flush' is triggering this panic too )
rndc calling isc__app_ctxrun function and finally panics the system:
lib/isc/unix/app.c ---
return (ISC_R_UNEXPECTED);
}
#ifndef HAVE_UNIXWARE_SIGWAIT
result = sigwait(, ); <--- panic
if (result == 0) {
variables are set to:
sset= {__bits = {16387, 0, 0, 0}}
sig = 134533280
Here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220358
Try to turn off hyperthreading to get a more sensible panic.
Might look like an issue with 32-bit systems and iflib.
--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
head -r320482 vs. TARGET_ARCH=powerpc production style kernel: jumps to non-code and traps (but the debug kernel build works for the same world)
The -r320482 kernel build is via gcc 4.2.1.
Both gcc 4.2.1 and clang based worlds show
the same problems. TARGET_ARCH=powerpc64
is not showing the problems.
The production kernel build fails
but the debug works --each built
from the same /usr/src/ tree.
I'll note what a normal boot does
before getting to the login prompt but
after "Starting nfsd." ("Updating motd:"
can be mixed in the trap text: not shown
below.)
I use an example and note a lot about what
varies and what stays the same from example
boot to example boot of the production
kernel.
[Manually entered from camera pictures
of the screen.]
fatal kernel trap
exception = 0x700 (program) (for "illegal instruction")
srr0 = 0x70bf878 (note: this varies, for example: 0x5e37230)
(note: r0 always matches srr0)
(note: ctr always matches srr0)
srr1 = 0x89032 (stays the same)
lr= 0x5b7b94 (note: solisten_wakeup+0x4c) (stays the same)
curthread = 0x5ab8ae0 (varies)
pid = 920 (varies), comm = mountd (stays the same)
Tracing command mountd pid 920 tid 100119 (varies) td 0x5ab8ae0 (varies)(CPU 1)
(stack addr
range varies)
0xd250a500: at soisconnected+0x21c (at stays the same)
0xd250a540: at unp_connect2+0xf0 (at stays the same)
0xd250a560: at unp_connectat+0x658 (at stays the same)
0xd250a770: at unp_connect+0x2c(at stays the same)
0xd250a790: at uipc_connect+0xc0 (at stays the same)
0xd250a7d0: at soconnectat+0xa0(at stays the same)
0xd250a800: at soconnect+0x2c (at stays the same)
0xd250a820: at kern_connect+0134 (at stays the same)
0xd250a870: at sys_connect+0x64(at stays the same)
0xd250a8b0: at trap+0x638 (at stays the same)
0xd250aa50: at powerpc_interrupt+0x1a0 (at stays the same)
0xd250aa80: at user SC trap (at stays the same)
by 0x419db168 (stays the same)
srr1=0xf032 (stays the same)
r1 =0xd5e0 (stays the same)
cr =0x24440840 (stays the same)
xer =0x2000 (stays the same)
ctr =0x419db160 (stays the same)
005b7b48 stwur1,-32(r1)
005b7b4c mflrr0
005b7b50 stw r29,20(r1)
005b7b54 stw r30,24(r1)
005b7b58 stw r31,28(r1)
005b7b5c stw r0,36(r1)
005b7b60 mr r31,r1
005b7b64 bcl-20,4*cr7+so,005b7b68
005b7b68 mflrr30
005b7b6c lwz r0,-36(r30)
005b7b70 add r30,r0,r30
005b7b74 mr r29,r3
005b7b78 lwz r0,232(r3)
005b7b7c cmpwi cr7,r0,0
005b7b80 beq-cr7,005b7b98
005b7b84 lwz r4,236(r3)
005b7b88 li r5,1
005b7b8c mtctr r0
005b7b90 bctrl
lr:
005b7b94 b 005b7bb4
. . .
Apparently this means that sol->sol_upcall is not
pointing to code at all yet is not null. Given the
variability observed, it might be uninitialized
--or sol itself is junk. . .
void
solisten_wakeup(struct socket *sol)
{
if (sol->sol_upcall != NULL)
(void )sol->sol_upcall(sol, sol->sol_upcallarg, M_NOWAIT);
else {
selwakeuppri(>so_rdsel, PSOCK);
KNOTE_LOCKED(>so_rdsel.si_note, 0);
}
SOLISTEN_UNLOCK(sol);
wakeup_one(>sol_comp);
}
005b8548 li r10,1
005b854c b 005b8558
005b8550 stwcx. r10,0,r9
005b8554 li r10,0
005b8558 cmpwi cr7,r10,0
005b855c bne-cr7,005b8568
005b8560 addir3,r28,16
005b8564 bl 004d4218 <__mtx_unlock_sleep>
005b8568 mr r3,r27
at soisconnected+0x21c:
005b856c bl 005b7b48
005b8570 b 005b89f0
. . .
void
soisconnected(struct socket *so)
{
struct socket *head;
. . .
restart:
SOCK_LOCK(so);
if ((head = so->so_listen) != NULL &&
__predict_false(SOLISTEN_TRYLOCK(head) == 0)) {
SOCK_UNLOCK(so);
goto restart;
}
so->so_state &= ~(SS_ISCONNECTING|SS_ISDISCONNECTING|SS_ISCONFIRMING);
so->so_state |= SS_ISCONNECTED;
if (head != NULL && (so->so_qstate == SQ_INCOMP)) {
again:
if ((so->so_options & SO_ACCEPTFILTER) == 0) {
TAILQ_REMOVE(>sol_incomp, so, so_list);
Re: HEAD/i386 r320212: three reproducible panics
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 = 1; apic id = 01
> instruction pointer = 0x20:0xc6be2023
> stack pointer = 0x28:0xe13c39f4
> frame pointer = 0x28:0xe13c3a20
> code segment = base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 11 (swi1: netisr 0)
> trap number= 1
> panic: privileged instruction fault
> cpuid = 1
> time = 1498206262
> Uptime: 6m19s
>
> The trace is:
>
> __curthread () at ./machine/pcpu.h:225
> 225 __asm("movl %%fs:%1,%0" : "=r" (td)
> (kgdb) #0 __curthread () at ./machine/pcpu.h:225
> #1 doadump (textdump=-968633472) at ../../../kern/kern_shutdown.c:318
> #2 0xc06e88c4 in kern_reboot (howto=)
> at ../../../kern/kern_shutdown.c:386
> #3 0xc06e8c5b in vpanic (fmt=,
> ap=0xe13c3874 "}\334\235\300H\254 \306\001")
> at ../../../kern/kern_shutdown.c:779
> #4 0xc06e8b1b in panic (fmt=0xc092e18e "%s")
> at ../../../kern/kern_shutdown.c:710
> #5 0xc08eed21 in trap_fatal (frame=0xe13c39b4, eva=)
> at ../../../i386/i386/trap.c:978
> #6 0xc08eea38 in trap (frame=)
> at ../../../i386/i386/trap.c:704
> #7
> #8 0xc6be2023 in ?? ()
> #9 0xc082ed53 in tcp_do_segment (m=, th=,
> so=, tp=, drop_hdrlen=,
> tlen=, iptos=,
> ti_locked=)
> at ../../../netinet/tcp_input.c:2444
> #10 0xc082c181 in tcp_input (mp=, offp=,
> proto=) at ../../../netinet/tcp_input.c:1191
> #11 0xc0820878 in ip_input (m=0x0) at ../../../netinet/ip_input.c:823
> #12 0xc07d5d0f in netisr_process_workstream_proto (nwsp=,
> proto=) at ../../../net/netisr.c:899
> #13 swi_net (arg=) at ../../../net/netisr.c:946
> #14 0xc06bb3c5 in intr_event_execute_handlers (p=0x109, ie=)
> at ../../../kern/kern_intr.c:1336
> #15 0xc06bb5f0 in ithread_execute_handlers (ie=,
> p=) at ../../../kern/kern_intr.c:1349
> #16 ithread_loop (arg=0xc60e6d00) at ../../../kern/kern_intr.c:1430
> #17 0xc06b8a76 in fork_exit (callout=0xc06bb560 ,
> arg=, frame=)
> at ../../../kern/kern_fork.c:1038
> #18
> (kgdb)
Interesting enough that panic triggered by named shutdown ( well, 'rndc
flush' is triggering this panic too )
rndc calling isc__app_ctxrun function and finally panics the system:
lib/isc/unix/app.c ---
return (ISC_R_UNEXPECTED);
}
#ifndef HAVE_UNIXWARE_SIGWAIT
result = sigwait(, ); <--- panic
if (result == 0) {
variables are set to:
sset= {__bits = {16387, 0, 0, 0}}
sig = 134533280
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
