Re: Port lang/gcc build fails on current
Try "|LC_COLLATE="C" make| | | |See e.g. https://forums.freebsd.org/threads/54172/| || |Graham| ||| | On 7/06/2016 4:10 AM, Randy Westlund wrote: redefinition of enumerator 'OPT_C' ___ 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"
patch.termcap
Would someone please commit the attached termcap patch for Altos V terminals. Granted I may be the only person still using one but it'll save continual patching. Thanks for your consideration. -- Tim Rice t...@xinuos.com Index: share/termcap/termcap === --- share/termcap/termcap (revision 301538) +++ share/termcap/termcap (working copy) @@ -521,6 +521,30 @@ # # M: MISCELLANEOUS TERMINALS # +# +# Termcap for Altos V terminal +a5|altos5|alt5|altos 5|Altos V:\ + :cd=\E[J:ce=\E[K:cl=\E[;H\E[2J:\ + :up=\E[1A:do=\E[1B:nd=\E[1C:bc=\E[1D:cm=\E[%i%d;%dH:ho=\E[H:\ + :al=\E[L:dl=\E[M:ic=\E[@:dc=\E[P:im=:ei=:SP=\E[i:\ + :co#80:li#24:ug#0:sg#0:bs:pt:sr=\EM:\ + :so=\E[7m:se=\E[m:us=\E[4m:ue=\E[m:mb=\E[5p:me=\E[p:\ + :is=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h:if=/usr/share/lib/tabset/vt100:\ + :ku=\E[A:kd=\E[B:kr=\E[C:kl=\E[D:kh=\E[f:kb=^H:cr=^M:\ + :XU=^Aq\r:XD=^Ar\r:XR=^As\r:XL=^At\r:\ + :HL=^AP\r:\ + :IS=\E[@:DE=\E[P:IL=\E[L:NS=\E[S:PS=\E[T:\ + :k1=^A@\r:k2=^AA\r:k3=^AB\r:k4=^AC\r:\ + :k5=^AD\r:k6=^AE\r:k7=^AF\r:k8=^AG\r:\ + :k9=^AH\r:k0=^AI\r:kA=^AJ\r:kB=^AK\r:\ + :kC=^AL\r:kD=^AM\r:kE=^AN\r:kF=^AO\r:\ + :c0=^A`\r:c1=^Aa\r:c2=^Ab\r:c3=^Ac\r:\ + :c4=^Ad\r:c5=^Ae\r:c6=^Af\r:c7=^Ag\r:\ + :c8=^Ah\r:c9=^Ai\r:cA=^Aj\r:cB=^Ak\r:\ + :cC=^Al\r:cD=^Am\r:cE=^An\r:cF=^Ao\r:\ + :po=\E[5i:pf=\E[4i: +# end altos5 termcap +# # The tab 132 uses xon/xoff, so no padding needed. # ks/ke have nothing to do with arrow keys. # is sets 80 col mode, normal video, autowrap on (for am). ___ 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: thread suspension when dumping core
On Tue, Jun 07, 2016 at 07:29:56AM +0300, Konstantin Belousov wrote: > On Mon, Jun 06, 2016 at 09:17:41PM -0700, Mark Johnston wrote: > > Sure, see below. For reference: > > > > td_flags = 0xa84c = INMEM | SINTR | CANSWAP | ASTPENDING | SBDRY | > > NEEDSUSPCHK > > td_pflags = 0 > > td_inhibitors = 0x2 = SLEEPING > > td_locks = 0 > > > > stack: > > mi_switch+0x21e sleepq_catch_signals+0x377 sleepq_wait_sig+0xb _sleep+0x29d > > ... > > > > p_flag = 0x10080080 = INMEM | STOPPED_SINGLE | HADTHREADS > > p_flag2 = 0 > > > > The thread is sleeping interruptibly. The NEEDSUSPCHK flag is set, yet the > > SLEEPABORT flag is not, so the thread can not have been sleeping when > > thread_single() was called - else sleepq_abort() would have been > > invoked and set SLEEPABORT. We are at the second sleepq_switch() call in > > sleepq_catch_signals(), and no signal was pending, so we called > > thread_suspend_check(), which returned 0 because of SBDRY. So we went to > > sleep. > > This looks as if we should not ignore suspension requests in > thread_suspend_check() completely in TDF_SBDRY case, but return either > EINTR or ERESTART (most likely ERESTART). Note that the goal of > TDF_SBDRY is to avoid suspending in the protected region, not to make an > impression that the suspension does not occur at all. Thanks, that sounds right to me. It results in unified behaviour for TDF_SBDRY regardless of whether the suspension attempt took place before or after the thread went to sleep, and seems like it does the right thing in the single-threaded case as well. ___ 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: wlan/ifconfig stopped working sometime between 5/25 and 6/3
Hi, this is a recent change to the regulatory handling. I've emailed Andriy who wrote the code. :) Andriy, any ideas? -adrian On 6 June 2016 at 20:15, Yoshihiro Ota wrote: > Hi, > > I started getting the following error when I tried to bring up wireless > connection since June 3rd. I had last updated kernel and world on May 25th > before. > > "unable to get regulatory domain info: Device not configured" > > ifconfig starts working again after I reverted the user land backt May 25th > one; kernel don't seem to be a fact here. > > I use "ifconfig wlan create wlandev ath0 ssid wepmode on wepkey > weptxkey 1 up". > Is something changed in ifconfig? > Do I need to use different arguments? > > Thanks, > Hiro > ___ > 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" ___ 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: thread suspension when dumping core
On Mon, Jun 06, 2016 at 09:17:41PM -0700, Mark Johnston wrote: > Sure, see below. For reference: > > td_flags = 0xa84c = INMEM | SINTR | CANSWAP | ASTPENDING | SBDRY | NEEDSUSPCHK > td_pflags = 0 > td_inhibitors = 0x2 = SLEEPING > td_locks = 0 > > stack: > mi_switch+0x21e sleepq_catch_signals+0x377 sleepq_wait_sig+0xb _sleep+0x29d > ... > > p_flag = 0x10080080 = INMEM | STOPPED_SINGLE | HADTHREADS > p_flag2 = 0 > > The thread is sleeping interruptibly. The NEEDSUSPCHK flag is set, yet the > SLEEPABORT flag is not, so the thread can not have been sleeping when > thread_single() was called - else sleepq_abort() would have been > invoked and set SLEEPABORT. We are at the second sleepq_switch() call in > sleepq_catch_signals(), and no signal was pending, so we called > thread_suspend_check(), which returned 0 because of SBDRY. So we went to > sleep. > > I note that this couldn't have happened prior to r283320. That change > was apparently motivated by a similar hang, but in that case the thread > was suspended (with a vnode lock held) rather than asleep. It looks like > our internal fix also added a change to set TDF_SBDRY around > filesystem-specific syscalls, which often sleep interruptibly while > holding vnode locks. But I don't think that's the problem here, as you > noted with lf_advlock(). > > With r283320 reverted, P_STOPPED_SIG would not have been set, so > thread_suspend_check() would have suspended us, allowing the core dump > to proceed. I had thought that using SINGLE_BOUNDRY beforing coredumping > would fix both hangs, but I guess that wouldn't help SINGLE_ALLPROC, so > this is probably the wrong place to be solving the problem. This looks as if we should not ignore suspension requests in thread_suspend_check() completely in TDF_SBDRY case, but return either EINTR or ERESTART (most likely ERESTART). Note that the goal of TDF_SBDRY is to avoid suspending in the protected region, not to make an impression that the suspension does not occur at all. ___ 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: thread suspension when dumping core
On Tue, Jun 07, 2016 at 05:46:10AM +0300, Konstantin Belousov wrote:
> On Mon, Jun 06, 2016 at 10:13:11AM -0700, Mark Johnston wrote:
> > On Sat, Jun 04, 2016 at 12:32:36PM +0300, Konstantin Belousov wrote:
> What statement was not true: that your code sets TDF_SBDRY, or that
> the lf_advlock() function was called ?
The latter. It turns out that we've modified some of our
filesystem-specific syscalls to set TDF_SBDRY as well; see below.
> > I'm a bit confused by this. How does TDF_SBDRY prevent thread_single()
> > from waking up the thread? The sleepq_abort() call is only elided in the
> > SINGLE_ALLPROC case, so in other cases, I think we will still interrupt
> > the sleep. Thus, since thread_suspend_check() is only invoked prior to
> > going to sleep, the application I referred to must have attempted to
> > single-thread the process before the thread in question went to sleep.
> It does not prevent the wakeup, sorry.
>
> What I should have said, more precisely, is that thread_suspend_check()
> call before the thread is goes to sleep, is nop in case of TDF_SBDRY
> flag was set.
Ok, that's my understanding too.
> > > From what I see in the code, our NFS client has similar issue of calling
> > > lf_advlock() with TDF_SBDRY set. Below is the patch to fix that.
> > > Similar bug existed in our fifofs, see r277321.
> >
> > Thanks. It may be that a similar fix is appropriate in our locking code,
> > but I'll have to spend more time reading it.
>
> Still, I am confused now as well. If you can catch the process in that
> state, where a thread is sleeping while single-threading request cannot
> make the progress, I would like to see the struct thread and struct proc
> printouts. Esp. the thread flags are interesting.
Sure, see below. For reference:
td_flags = 0xa84c = INMEM | SINTR | CANSWAP | ASTPENDING | SBDRY | NEEDSUSPCHK
td_pflags = 0
td_inhibitors = 0x2 = SLEEPING
td_locks = 0
stack:
mi_switch+0x21e sleepq_catch_signals+0x377 sleepq_wait_sig+0xb _sleep+0x29d ...
p_flag = 0x10080080 = INMEM | STOPPED_SINGLE | HADTHREADS
p_flag2 = 0
The thread is sleeping interruptibly. The NEEDSUSPCHK flag is set, yet the
SLEEPABORT flag is not, so the thread can not have been sleeping when
thread_single() was called - else sleepq_abort() would have been
invoked and set SLEEPABORT. We are at the second sleepq_switch() call in
sleepq_catch_signals(), and no signal was pending, so we called
thread_suspend_check(), which returned 0 because of SBDRY. So we went to
sleep.
I note that this couldn't have happened prior to r283320. That change
was apparently motivated by a similar hang, but in that case the thread
was suspended (with a vnode lock held) rather than asleep. It looks like
our internal fix also added a change to set TDF_SBDRY around
filesystem-specific syscalls, which often sleep interruptibly while
holding vnode locks. But I don't think that's the problem here, as you
noted with lf_advlock().
With r283320 reverted, P_STOPPED_SIG would not have been set, so
thread_suspend_check() would have suspended us, allowing the core dump
to proceed. I had thought that using SINGLE_BOUNDRY beforing coredumping
would fix both hangs, but I guess that wouldn't help SINGLE_ALLPROC, so
this is probably the wrong place to be solving the problem.
CPU IDFUNCTION:NAME
1 1 :BEGIN struct thread {
struct mtx *volatile td_lock = 0x814a5148
struct proc *td_proc = 0xf80445c694d8
struct td_plist = {
struct thread *tqe_next = 0xf81a44186750
struct thread **tqe_prev = 0xf8047a027760
}
struct td_runq = {
struct thread *tqe_next = 0
struct thread **tqe_prev = 0x8147cd40
}
struct td_slpq = {
struct thread *tqe_next = 0
struct thread **tqe_prev = 0xf81c992b1d80
}
struct td_lockq = {
struct thread *tqe_next = 0
struct thread **tqe_prev = 0xfe2a1c727be8
}
struct td_hash = {
struct thread *le_next = 0
struct thread **le_prev = 0xfe0001076f98
}
struct cpuset *td_cpuset = 0xf80699b9b510
struct seltd *td_sel = 0xf80258307b80
struct sleepqueue *td_sleepqueue = 0
struct turnstile *td_turnstile = 0xf80d50a3fcc0
struct rl_q_entry *td_rlqe = 0xf8025dcf5988
struct umtx_q *td_umtxq = 0xf807c9adfd80
lwpid_t td_tid = 0x18df3
sigqueue_t td_sigqueue = {
sigset_t sq_signals = {
__uint32_t [4] __bits = [ 0, 0, 0, 0 ]
}
sigset_t sq_kill = {
__uint32_t [4] __bits = [ 0, 0, 0, 0 ]
}
struct sq_list = {
struct ksiginfo *tqh_first = 0
struct ksiginfo **tqh_last = 0xf814be2df808
}
struct proc *sq_proc = 0xf80445c694d8
int sq_flags = 0x1
}
u_char td_lend_user_pri = 0xff
int td_flags = 0xa84c
int td_inhibitors = 0x2
int td_pflags = 0
int td_dupfd = 0
Re: thread suspension when dumping core
On Mon, Jun 6, 2016 at 7:46 PM, Konstantin Belousov wrote: > On Mon, Jun 06, 2016 at 10:13:11AM -0700, Mark Johnston wrote: >> On Sat, Jun 04, 2016 at 12:32:36PM +0300, Konstantin Belousov wrote: >> > Does your fs both set TDF_SBDRY and call lf_advlock()/lf_advlockasync() ? >> >> It doesn't. This code belongs to a general framework for distributed FS >> locks; in this particular case, the application was using it to acquire >> a custom advisory lock. > What statement was not true: that your code sets TDF_SBDRY, or that > the lf_advlock() function was called ? We set TDF_SBDRY; we don't call lf_advlock(). I don't have the core yet, so I can't get the thread information, sorry. Best, Conrad ___ 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"
wlan/ifconfig stopped working sometime between 5/25 and 6/3
Hi, I started getting the following error when I tried to bring up wireless connection since June 3rd. I had last updated kernel and world on May 25th before. "unable to get regulatory domain info: Device not configured" ifconfig starts working again after I reverted the user land backt May 25th one; kernel don't seem to be a fact here. I use "ifconfig wlan create wlandev ath0 ssid wepmode on wepkey weptxkey 1 up". Is something changed in ifconfig? Do I need to use different arguments? Thanks, Hiro ___ 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: thread suspension when dumping core
On Mon, Jun 06, 2016 at 10:13:11AM -0700, Mark Johnston wrote: > On Sat, Jun 04, 2016 at 12:32:36PM +0300, Konstantin Belousov wrote: > > Does your fs both set TDF_SBDRY and call lf_advlock()/lf_advlockasync() ? > > It doesn't. This code belongs to a general framework for distributed FS > locks; in this particular case, the application was using it to acquire > a custom advisory lock. What statement was not true: that your code sets TDF_SBDRY, or that the lf_advlock() function was called ? > > > This cannot work, regardless of the mode of single-threading. TDF_SBDRY > > makes such sleep non-interruptible by any single-threading request, on > > the promise that the thread owns some resources (typically vnode locks). > > I.e. changing the mode would not help. > > I'm a bit confused by this. How does TDF_SBDRY prevent thread_single() > from waking up the thread? The sleepq_abort() call is only elided in the > SINGLE_ALLPROC case, so in other cases, I think we will still interrupt > the sleep. Thus, since thread_suspend_check() is only invoked prior to > going to sleep, the application I referred to must have attempted to > single-thread the process before the thread in question went to sleep. It does not prevent the wakeup, sorry. What I should have said, more precisely, is that thread_suspend_check() call before the thread is goes to sleep, is nop in case of TDF_SBDRY flag was set. > > > > > I see two reasons to use SINGLE_NO_EXIT for coredumping. It allows > > coredump writer to record more exact state of the process into the notes. > > > > Another one is that SINGLE_NO_EXIT is generally faster and more > > reliable than SINGLE_BOUNDARY. Some states are already good enough for > > SINGLE_NO_EXIT, while require more work to get into SINGLE_BOUNDARY. In > > other words, core dump write starts earlier. > > > > It might be not very significant reasons. > > > > From what I see in the code, our NFS client has similar issue of calling > > lf_advlock() with TDF_SBDRY set. Below is the patch to fix that. > > Similar bug existed in our fifofs, see r277321. > > Thanks. It may be that a similar fix is appropriate in our locking code, > but I'll have to spend more time reading it. Still, I am confused now as well. If you can catch the process in that state, where a thread is sleeping while single-threading request cannot make the progress, I would like to see the struct thread and struct proc printouts. Esp. the thread flags are interesting. Thanks. ___ 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"
Virtualbox kernel module on 11-CURRENT
Hello, I tried installing virtualbox from packages, building it from sources, trying the GENERIC kernel but everytime I can't start the kernel module 'vboxdrv', it says: "KLD vboxdrv.ko: depends on kernel - not available or version mismatch. linker_load_file: Unsupported file type" I'm using a custom kernel which I only turned off options for wireless and old drives, but the module is not working even with GENERIC. My sources in /usr/src are up-to-date and I tried building virtualbox-ose-kmod from ports (maybe it could use my sources) but no success. Is this a known problem? ___ 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"
Port lang/gcc build fails on current
I can't build lang/gcc on current, but it works fine on 10.3. I'm running r301482 after a full rebuild and nothing in /etc/make.conf. Any ideas? > c++ -c -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -DLIBICONV_PLUG > -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall > -Wno-narrowing -Wwrite-strings -Wcast-qual -Wm > issing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros > -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild > -I/usr/ports/lang/gcc/work/gcc-4.8.5/gcc -I/usr/ports > /lang/gcc/work/gcc-4.8.5/gcc/build > -I/usr/ports/lang/gcc/work/gcc-4.8.5/gcc/../include > -I/usr/ports/lang/gcc/work/gcc-4.8.5/gcc/../libcpp/include -DLIBICONV_PLUG \ > -o build/gencheck.o /usr/ports/lang/gcc/work/gcc-4.8.5/gcc/gencheck.c > c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is > deprecated > /bin/sh /usr/ports/lang/gcc/work/gcc-4.8.5/gcc/../move-if-change > tmp-gtype.state gtype.state > build/gengtype \ > -r gtype.state > In file included from /usr/ports/lang/gcc/work/gcc-4.8.5/gcc/gencheck.c:23: > In file included from ./tm.h:16: > ./options.h:4293:3: error: redefinition of enumerator 'OPT_C' > OPT_C = 129, /* -C */ > ^ > ./options.h:4290:3: note: previous definition is here > OPT_C = 126, /* -C */ > ^ > ./options.h:4301:3: error: redefinition of enumerator 'OPT_d' > OPT_d = 137, /* -d */ > ^ > ./options.h:4299:3: note: previous definition is here > OPT_d = 135, /* -d */ > ^ [snip several more like it] > ./options.h:5183:3: error: redefinition of enumerator 'OPT_v' > OPT_v = 1019, /* -v */ > ^ > ./options.h:5181:3: note: previous definition is here > OPT_v = 1017, /* -v */ > ^ > fatal error: too many errors emitted, stopping now [-ferror-limit=] > 20 errors generated. > Makefile:3840: recipe for target 'build/gencheck.o' failed > gmake[4]: *** [build/gencheck.o] Error 1 > gmake[4]: *** Waiting for unfinished jobs > echo timestamp > s-gtype > /usr/ports/lang/gcc/work/gcc-4.8.5/gcc/doc/passes.texi:7: warning: node next > `Passes' in menu `GENERIC' and in sectioning `RTL' differ > /usr/ports/lang/gcc/work/gcc-4.8.5/gcc/doc/rtl.texi:5: warning: node next > `RTL' in menu `Control Flow' and in sectioning `GENERIC' differ > /usr/ports/lang/gcc/work/gcc-4.8.5/gcc/doc/rtl.texi:5: warning: node prev > `RTL' in menu `Tree SSA' and in sectioning `Passes' differ > /usr/ports/lang/gcc/work/gcc-4.8.5/gcc/doc/generic.texi:9: warning: node prev > `GENERIC' in menu `Passes' and in sectioning `RTL' differ > /usr/ports/lang/gcc/work/gcc-4.8.5/gcc/doc/tree-ssa.texi:9: warning: node > next `Tree SSA' in menu `RTL' and in sectioning `Loop Analysis and > Representation' differ > /usr/ports/lang/gcc/work/gcc-4.8.5/gcc/doc/loop.texi:10: warning: node next > `Loop Analysis and Representation' in menu `Machine Desc' and in sectioning > `Control Flow' differ > /usr/ports/lang/gcc/work/gcc-4.8.5/gcc/doc/loop.texi:10: warning: node prev > `Loop Analysis and Representation' in menu `Control Flow' and in sectioning > `Tree SSA' differ > /usr/ports/lang/gcc/work/gcc-4.8.5/gcc/doc/cfg.texi:10: warning: node next > `Control Flow' in menu `Loop Analysis and Representation' and in sectioning > `Machine Desc' differ > /usr/ports/lang/gcc/work/gcc-4.8.5/gcc/doc/cfg.texi:10: warning: node prev > `Control Flow' in menu `RTL' and in sectioning `Loop Analysis and > Representation' differ > /usr/ports/lang/gcc/work/gcc-4.8.5/gcc/doc/md.texi:6: warning: node prev > `Machine Desc' in menu `Loop Analysis and Representation' and in sectioning > `Control Flow' differ > rm cpp.pod gfortran.pod gcc.pod > gmake[4]: Leaving directory '/usr/ports/lang/gcc/work/.build/gcc' > Makefile:3908: recipe for target 'all-gcc' failed > gmake[3]: *** [all-gcc] Error 2 > gmake[3]: Leaving directory '/usr/ports/lang/gcc/work/.build' > Makefile:856: recipe for target 'all' failed > gmake[2]: *** [all] Error 2 > gmake[2]: Leaving directory '/usr/ports/lang/gcc/work/.build' > ===> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > the maintainer. > *** Error code 1 > Stop. > make[1]: stopped in /usr/ports/lang/gcc > *** Error code 1 > Stop. > make: stopped in /usr/ports/lang/gcc signature.asc Description: PGP signature
Re: thread suspension when dumping core
On Sat, Jun 04, 2016 at 12:32:36PM +0300, Konstantin Belousov wrote: > On Fri, Jun 03, 2016 at 07:23:47PM -0700, Mark Johnston wrote: > > Hi, > > > > I've recently observed a hang in a multi-threaded process that had hit > > an assertion failure and was attempting to dump core. One thread was > > sleeping interruptibly on an advisory lock with TDF_SBDRY set (our > > filesystem sets VFCF_SBDRY). SIGABRT caused the receipient thread to > > suspend other threads with thread_single(SINGLE_NO_EXIT), which fails > > to interrupt the sleeping thread, resulting in the hang. > > > > My question is, why does the SA_CORE handler not force all threads to > > the user boundary before attempting to dump core? It must do so later > > anyway in order to exit. As I understand it, TDF_SBDRY is intended to > > avoid deadlocks that can occur when stopping a process, but in this > > case we don't stop the process with the intention of resuming it, so it > > seems erroneous to apply this flag. > > Does your fs both set TDF_SBDRY and call lf_advlock()/lf_advlockasync() ? It doesn't. This code belongs to a general framework for distributed FS locks; in this particular case, the application was using it to acquire a custom advisory lock. > This cannot work, regardless of the mode of single-threading. TDF_SBDRY > makes such sleep non-interruptible by any single-threading request, on > the promise that the thread owns some resources (typically vnode locks). > I.e. changing the mode would not help. I'm a bit confused by this. How does TDF_SBDRY prevent thread_single() from waking up the thread? The sleepq_abort() call is only elided in the SINGLE_ALLPROC case, so in other cases, I think we will still interrupt the sleep. Thus, since thread_suspend_check() is only invoked prior to going to sleep, the application I referred to must have attempted to single-thread the process before the thread in question went to sleep. > > I see two reasons to use SINGLE_NO_EXIT for coredumping. It allows > coredump writer to record more exact state of the process into the notes. > > Another one is that SINGLE_NO_EXIT is generally faster and more > reliable than SINGLE_BOUNDARY. Some states are already good enough for > SINGLE_NO_EXIT, while require more work to get into SINGLE_BOUNDARY. In > other words, core dump write starts earlier. > > It might be not very significant reasons. > > From what I see in the code, our NFS client has similar issue of calling > lf_advlock() with TDF_SBDRY set. Below is the patch to fix that. > Similar bug existed in our fifofs, see r277321. Thanks. It may be that a similar fix is appropriate in our locking code, but I'll have to spend more time reading it. ___ 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"
FreeBSD_HEAD_amd64_gcc - Build #1276 - Fixed
FreeBSD_HEAD_amd64_gcc - Build #1276 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1276/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1276/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc/1276/console Change summaries: 301498 by bz: Make the KASSERT message more helpful by also printing the ifp information which we are asserting. Obtained from: projects/vnet MFC after: 2 weeks Sponsored by: The FreeBSD Foundation 301497 by sgalabov: Remove erroneous lock assertions In mediatek etherswitch support, functions mtkswitch_reg_write32_mt7621 and mtkswitch_reg_read32_mt7621 are called without locks held, so lock assertions fail. Remove the lock assertions. Sponsored by: Smartcom - Bulgaria AD 301496 by araujo: Add support to priority code point (PCP) that is an 3-bit field which refers to IEEE 802.1p class of service and maps to the frame priority level. Values in order of priority are: 1 (Background (lowest)), 0 (Best effort (default)), 2 (Excellent effort), 3 (Critical applications), 4 (Video, < 100ms latency), 5 (Video, < 10ms latency), 6 (Internetwork control) and 7 (Network control (highest)). Example of usage: root# ifconfig em0.1 create root# ifconfig em0.1 vlanpcp 3 Note: The review D801 includes the pf(4) part, but as discussed with kristof, we won't commit the pf(4) bits for now. The credits of the original code is from rwatson. Differential Revision: https://reviews.freebsd.org/D801 Reviewed by:gnn, adrian, loos Discussed with: rwatson, glebius, kristof Tested by: many including Matthew Grooms Obtained from: pfSense Relnotes: Yes 301495 by arybchik: sfxge(4): update TX vFIFO ULL tag location to avoid merge conflict Sponsored by: Solarflare Communications, Inc. MFC after: 1 week 301494 by arybchik: sfxge(4): pick an RSS bucket for the packet enqueued and select TXQ accordingly Submitted by: Ivan Malov Reviewed by:gnn Sponsored by: Solarflare Communications, Inc. Differential Revision: https://reviews.freebsd.org/D6723 301493 by arybchik: sfxge(4): set up the indirection table using the kernel-driven RSS bucket ids Submitted by: Ivan Malov Reviewed by:gnn Sponsored by: Solarflare Communications, Inc. Differential Revision: https://reviews.freebsd.org/D6722 301492 by arybchik: sfxge(4): bind interrupts to CPUs in accordance with bucket to CPU map Submitted by: Ivan Malov Reviewed by:gnn Sponsored by: Solarflare Communications, Inc. Differential Revision: https://reviews.freebsd.org/D6721 301491 by arybchik: sfxge(4): restrict the maximum number of RSS channels by the number of RSS buckets This is done because one has no point to have more channels since they will be unused. Submitted by: Ivan Malov Reviewed by:gnn Sponsored by: Solarflare Communications, Inc. Differential Revision: https://reviews.freebsd.org/D6720 301490 by arybchik: sfxge(4): get RSS key to be programmed into NIC from the kernel Submitted by: Ivan Malov Reviewed by:gnn Sponsored by: Solarflare Communications, Inc. Differential Revision: https://reviews.freebsd.org/D6719 301489 by arybchik: sfxge(4): prepare sfxge to be RSS API aware This change is needed because 'opt_rss.h' is included by multiple source files and RSS macro is defined as 1 within the file during build process if option RSS is enabled in the kernel. Submitted by: Ivan Malov Reviewed by:gnn Sponsored by: Solarflare Communications, Inc. Differential Revision: https://reviews.freebsd.org/D6718 301488 by sephe: hyperv/vmbus: Constify channel message MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D6708 301487 by sephe: hyperv/vmbus: Factor out channel message processing This paves the way for further cleanup. MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D6707 301485 by adrian: [bwn] don't use a 1MB CCK RTS frame for 11a OFDM transmissions. 301484 by sephe: hyperv/vmbus: Define type for channel messages. And fix message processing; only channel messages are supported. MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D6706 301483 by sephe: hyperv: Move machine dependent bits into machine dependent files. MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D6701 301482 by araujo: For pointers use NULL instead of 0. 301481 by araujo: Connect ypldap(8) script on Makefile, forgotten on my previous commit r301480. 301480 by araujo: Add rc.d script for ypldap(8). 301479 by araujo: Install/Connect ypldap.conf(5) on examples. 301478 by gnn: Add missing constants from RFCs 4443 and 6550 301477 by bdrewery: legacy: Avoid building/installing headers twice. Sponsored by: EMC / Isilon Storage Division 301476 by bdrewery: Use th
Re: panic: destroying non-empty racct: 2113536 allocated for resource 4
I've just got the same panic again.
This time I didn't do anything unusual, just ran a poudriere build and the
systems paniced at the end of it:
Unread portion of the kernel message buffer:
panic: destroying non-empty racct: 2113536 allocated for resource 4
KDB: stack backtrace:
db_trace_self_wrapper() at 0x804131eb = db_trace_self_wrapper+0x2b/frame
0xfe051992a7f0
kdb_backtrace() at 0x806636d9 = kdb_backtrace+0x39/frame
0xfe051992a8a0
vpanic() at 0x8062dd9c = vpanic+0x14c/frame 0xfe051992a8e0
panic() at 0x8062dae3 = panic+0x43/frame 0xfe051992a940
racct_destroy_locked() at 0x8061eebc = racct_destroy_locked+0xac/frame
0xfe051992a960
racct_destroy() at 0x8061ede5 = racct_destroy+0x35/frame
0xfe051992a980
prison_racct_free_locked() at 0x805fdcdc =
prison_racct_free_locked+0x4c/frame 0xfe051992a9a0
prison_racct_free() at 0x805fdc2d = prison_racct_free+0x6d/frame
0xfe051992a9c0
prison_racct_detach() at 0x805fdd8e = prison_racct_detach+0x3e/frame
0xfe051992a9e0
prison_deref() at 0x805fb26b = prison_deref+0x23b/frame
0xfe051992aa10
prison_remove_one() at 0x805fc9c5 = prison_remove_one+0x125/frame
0xfe051992aa40
sys_jail_remove() at 0x805fc884 = sys_jail_remove+0x204/frame
0xfe051992aa90
syscallenter() at 0x80820cdd = syscallenter+0x31d/frame
0xfe051992ab00
amd64_syscall() at 0x808208af = amd64_syscall+0x1f/frame
0xfe051992abf0
Xfast_syscall() at 0x80808d5b = Xfast_syscall+0xfb/frame
0xfe051992abf0
It's interesting that the resource and the value are exactly the same.
I have a crash dump this time as well.
On 17/05/2016 09:22, Andriy Gapon wrote:
>
> To be fair I got this panic after some exotic sequence of events: running
> poudriere, sending SIGSTOP to one of build processes, forgetting about it,
> seeing poudriere timeout that job, sending SIGCONT...
>
> This is amd64 head r297350.
>
> Some details:
> (kgdb) bt
> #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:295
> #1 0x8062d7ef in kern_reboot (howto=) at
> /usr/src/sys/kern/kern_shutdown.c:363
> #2 0x8062de38 in vpanic (fmt=, ap=0xfe0519b73920)
> at
> /usr/src/sys/kern/kern_shutdown.c:639
> #3 0x8062db43 in panic (fmt=) at
> /usr/src/sys/kern/kern_shutdown.c:572
> #4 0x8061ef1c in racct_destroy_locked (racctp=) at
> /usr/src/sys/kern/kern_racct.c:478
> #5 0x8061ee45 in racct_destroy (racct=0xf802f6301518) at
> /usr/src/sys/kern/kern_racct.c:495
> #6 0x805fdd3c in prison_racct_free_locked (prr=0xf802f6301400) at
> /usr/src/sys/kern/kern_jail.c:4564
> #7 0x805fdc8d in prison_racct_free (prr=0xf802f6301400) at
> /usr/src/sys/kern/kern_jail.c:4583
> #8 0x805fddee in prison_racct_detach (pr=0xf802b073) at
> /usr/src/sys/kern/kern_jail.c:4658
> #9 0x805fb2cb in prison_deref (pr=, flags=3) at
> /usr/src/sys/kern/kern_jail.c:2663
> #10 0x805fca25 in prison_remove_one (pr=) at
> /usr/src/sys/kern/kern_jail.c:2358
> #11 0x805fc8e4 in sys_jail_remove (td=, uap= out>) at /usr/src/sys/kern/kern_jail.c:2313
> #12 0x80820ddd in syscallenter (td=0xf801146019e0,
> sa=0xfe0519b73b80) at
> /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135
> #13 0x808209af in amd64_syscall (td=0xf801146019e0, traced=0) at
> /usr/src/sys/amd64/amd64/trap.c:943
>
> RACCT_RSS is 4.
>
> (kgdb) p *prr
> $5 = {
> prr_next = {
> le_next = 0xf80382fe4400,
> le_prev = 0xf8017ac90600
> },
> prr_name = "basejail-default-job-03", '\000' ,
> prr_refcount = 0,
> prr_racct = 0xf802e3f520b0
> }
> (kgdb) p *prr->prr_racct
> $6 = {
> r_resources = {13884177072, 0, 0, 0, 2113536, 0 ,
> 13611325009, 0},
> r_rule_links = {
> lh_first = 0x0
> }
> }
>
> Could it be that somehow the CONT'd process failed to deduct its resources
> from
> the jail's resources because the jail was already marked for destruction or
> something like that?
>
--
Andriy Gapon
___
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"
