Hi John-Mark, On 2015-07-14 15:27 -0700, John-Mark Gurney <jmg_at_funkthat.com> wrote: >Pawel Pekala wrote this message on Tue, Jul 14, 2015 at 22:47 +0200: >> On 2015-07-13 23:28 +0200, Mateusz Guzik <mjguzik_at_gmail.com> wrote: >> >On Mon, Jul 13, 2015 at 11:12:05PM +0200, Pawel Pekala wrote: >> >> Hi >> >> >> >> I'm getting 100% reproducible kernel crash while trying build >> >> ports with poudriere on my system. This started to show up about >> >> 2-3 weeks ago. I upgrade my system on weekly basis usually on >> >> saturday. Here's backtrace: >> >> >> >> (kgdb) bt >> >[..] >> >> at /hdd/src/sys/amd64/amd64/trap.c:201 >> >> #25 0xffffffff80dace32 in calltrap () >> >> at /hdd/src/sys/amd64/amd64/exception.S:235 #26 0xffffffff80941430 >> >> in knote (list=0xfffff801a2589408, hint=2147483648, >> >> lockflags=<value optimized out>) >> >> at /hdd/src/sys/kern/kern_event.c:1920 #27 0xffffffff80946a51 in >> >> exit1 (td=0xfffff801b84014d0, rv=<value optimized out>) >> >> at /hdd/src/sys/kern/kern_exit.c:560 #28 0xffffffff80945f1e in >> >> sys_sys_exit (td=0x0, uap=<value optimized >> >> out>) at /hdd/src/sys/kern/kern_exit.c:178 #29 0xffffffff80dcdaa2 >> >> out>in amd64_syscall (td=0xfffff801b84014d0, traced=0) >> >> at subr_syscall.c:133 >> >> #30 0xffffffff80dad11b in Xfast_syscall () >> >> at /hdd/src/sys/amd64/amd64/exception.S:395 #31 0x0000000800922eea >> >> in ?? () Previous frame inner to this frame (corrupt stack?) >> >> Current language: auto; currently minimal >> >> >> >> Let me know if you need more details. >> > >> > >> >Well, if the problem is really that reproducible it would be best if >> >you narrowed it down to the exact commit. >> > >> >However, quick look suggests you may be a "victim" of r284861. >> >> After further testing I can confirm that this panic was introduced in >> r284861, thanks for the hint! > >Can you tell me what your line 1920 of kern_event.c is? (and the >context around it? Or at least the $FreeBSD$ line from >kern_event.c? Because in HEAD, the line is: > } else if ((lockflags & KNF_NOKQLOCK) != 0) { > >and there isn't a way to fault on that code... Yes, this is strange. if ((kn->kn_status & (KN_INFLUX | KN_SCAN)) == KN_INFLUX) { /* * Do not process the influx notes, except for * the influx coming from the kq unlock in the * kqueue_scan(). In the later case, we do * not interfere with the scan, since the code * fragment in kqueue_scan() locks the knlist, * and cannot proceed until we finished. */ KQ_UNLOCK(kq); ===> line 1920 } else if ((lockflags & KNF_NOKQLOCK) != 0) { kn->kn_status |= KN_INFLUX; KQ_UNLOCK(kq); error = kn->kn_fop->f_event(kn, hint); KQ_LOCK(kq); kn->kn_status &= ~KN_INFLUX; if (error) KNOTE_ACTIVATE(kn, 1); KQ_UNLOCK_FLUX(kq); } else { Id line: __FBSDID("$FreeBSD: head/sys/kern/kern_event.c 284215 2015-06-10 10:48:12Z mjg $"); -- pozdrawiam / with regards Paweł PękalaReceived on Wed Jul 15 2015 - 13:44:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:58 UTC