Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Friday 18 March 2016 11:55:31 Konstantin Belousov wrote:
> On Fri, Mar 18, 2016 at 08:14:57AM +0200, Konstantin Belousov wrote:
> > Yes, please.  It would be significantly easier to diagnose the problem if
> > the minimal example is provided.  If not, please pack one crashing app
> > and all it non-system libraries and provide the tarball to me.
> 
> Meantime you could also try the following change.  I doubt that it would
> fix your issue, but it is possibly related.  Only libthr needs to be
> rebuilt.
> 
> diff --git a/lib/libthr/thread/thr_fork.c b/lib/libthr/thread/thr_fork.c
> index 7256b68..531e09c 100644
> --- a/lib/libthr/thread/thr_fork.c
> +++ b/lib/libthr/thread/thr_fork.c

 No it is still coredumping.
The only positive effect is that segfaults are quite occasional comparing to 
stock libthr

Loaded symbols for /libexec/ld-elf.so.1
#0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
[New Thread 809215000 (LWP 100253/)]
(gdb) bt
#0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
#1  0x0008041b2d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2  0x0008041b2ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#3  0x000803eda67c in _thread_exit (fname=,
lineno=, msg=)
at /usr/src/lib/libthr/thread/thr_exit.c:182
#4  0x000803ed56fc in mutex_lock_common (m=,
abstime=, cvattach=)
at /usr/src/lib/libthr/thread/thr_mutex.c:139
#5  0x000803ed4c20 in __pthread_mutex_timedlock (mutex=0x81828,
abstime=0x7fffc468) at /usr/src/lib/libthr/thread/thr_mutex.c:566


___
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: boot loaders got fatter in the last few days

[Allan Jude]

On 2016-03-18 14:01, Steven Hartland wrote:


On 18/03/2016 17:51, Guido Falsi wrote:

On 03/18/16 17:54, José Pérez wrote:

Hi Guido,
maybe it's because of this:
https://svnweb.freebsd.org/base?view=revision&revision=296963


I see.

There is a problem with this though, we have howtos suggesting 64K for
the size of the freebsd-boot gpt partition:

https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1

now that size isn't sufficient anymore. We should at least update these
information soon.

Also repartitioning could be problematic in certain scenarios. I think
this change should be at least published in UPDATING and maybe also in
the future release notes for 11.0.

Personally I'll find a way of reorganizing my disks to fit this change,
but it's something that could byte users.


Yes indeed I would suggest if we increase it we do by a decent amount
e.g. jump straight to 1MB.

 Regards
 Steve
___
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"


Due to limitations in the assembly bits (pmbr.S) the maximum size is 
545kb, so the zfsboot part of the install creates 512kb partitions by 
default


--
Allan Jude
___
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: xo_config.h missing?

[Simon J. Gerraty]

Jung-uk Kim  wrote:
> The attached patch fixed the build issues for me.

Since xo_config.h does not look like part of public api, this seems
appropriate.

I've committed this, while I check for other fallout.

Thanks

> Jung-uk Kim
___
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: boot loaders got fatter in the last few days

[Hans Petter Selasky]

Would the boot loaders be smaller if we had an amd64 linker with garbage 
collection?


--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"

FreeBSD_HEAD_i386 - Build #2619 - Fixed

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #2619 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2619/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2619/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2619/console

Change summaries:

296979 by sjg:
xo_config.h no longer in contrib, so -I's needed

PR: /homes/sjg/commit-logs/freebsd/libxo/xo_config.diff
Reviewed by:jkim

___
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: r296548 breaks external DP and HDMI on HD4000

[Jean-Sébastien Pédron]

On 14/03/2016 18:59, Ian FREISLICH wrote:
> Hi

Hi!

> With r296548 on the following hardware:
> 
> vgapci0@pci0:0:2:0: class=0x03 card=0x15171043 chip=0x01668086
> 
> I get the following console messages when X starts and my external
> monitor (Samsung U28E590) goes into epileptic fit attack mode.
> 
> [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0
> [drm:pid0:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting
> [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off
> [drm:pid0:intel_cpt_verify_modeset] *ERROR* mode set failed: pipe 0 stuck
> [drm:pid1100:ironlake_check_fdi_lanes] *ERROR* WARN ON:
> I915_READ(SOUTH_CHICKEN1) & FDI_BC_BIFURCATION_SELECT
> [drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail!
> [drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail!

On my Haswell laptop, the external DisplayPort doesn't work either. When
using Ultra HD, I get garbage. When using Full HD, the image is correct
for a few seconds, then the output connector is disabled (talking about
Panel status timeout in dmesg).

What resolution do you use with your monitor? If you're using Ultra HD,
could you please try Full HD?

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature

FreeBSD_HEAD_i386 - Build #2618 - Still Failing

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #2618 - Still Failing:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2618/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2618/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2618/console

Change summaries:

296975 by np:
cxgbe(4): Tidy up PAUSE frame accounting.

Figure out if the chip is counting PAUSE frames in the "normal" stats
and take them out if it is.  This fixes a bug in the tx stats because
the default hardware behavior is different for Tx and Rx but the driver
was treating both the same way.  The result was that OPACKETS, OBYTES,
and OMCASTS were under-reported (if tx_pause > 0) before this change.

Note that the mac_stats sysctl still gives you the raw value of these
statistics straight from the device registers.



The end of the build log:

[...truncated 118018 lines...]
--- xo_open_marker.3.gz ---
gzip -cn /usr/src/contrib/libxo/libxo/xo_open_marker.3 > xo_open_marker.3.gz
--- xo_parse_args.3.gz ---
gzip -cn /usr/src/contrib/libxo/libxo/xo_parse_args.3 > xo_parse_args.3.gz
--- xo_set_allocator.3.gz ---
gzip -cn /usr/src/contrib/libxo/libxo/xo_set_allocator.3 > xo_set_allocator.3.gz
--- xo_set_flags.3.gz ---
gzip -cn /usr/src/contrib/libxo/libxo/xo_set_flags.3 > xo_set_flags.3.gz
--- xo_set_info.3.gz ---
gzip -cn /usr/src/contrib/libxo/libxo/xo_set_info.3 > xo_set_info.3.gz
--- xo_set_options.3.gz ---
gzip -cn /usr/src/contrib/libxo/libxo/xo_set_options.3 > xo_set_options.3.gz
--- xo_set_style.3.gz ---
gzip -cn /usr/src/contrib/libxo/libxo/xo_set_style.3 > xo_set_style.3.gz
--- xo_set_syslog_enterprise_id.3.gz ---
gzip -cn /usr/src/contrib/libxo/libxo/xo_set_syslog_enterprise_id.3 > 
xo_set_syslog_enterprise_id.3.gz
--- xo_set_version.3.gz ---
gzip -cn /usr/src/contrib/libxo/libxo/xo_set_version.3 > xo_set_version.3.gz
--- xo_set_writer.3.gz ---
gzip -cn /usr/src/contrib/libxo/libxo/xo_set_writer.3 > xo_set_writer.3.gz
--- xo_syslog.3.gz ---
gzip -cn /usr/src/contrib/libxo/libxo/xo_syslog.3 > xo_syslog.3.gz
--- all_subdir_usr.sbin ---
--- exoparg6.o ---
cc  -O2 -pipe -DACPI_EXEC_APP -fno-strict-aliasing   
-I/usr/src/usr.sbin/acpi/acpidb/../../../sys -g -MD -MP -MF.depend.exoparg6.o 
-MTexoparg6.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror 
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef  
-Qunused-arguments -c 
/usr/src/usr.sbin/acpi/acpidb/../../../sys/contrib/dev/acpica/components/executer/exoparg6.c
 -o exoparg6.o
--- all_subdir_lib ---
--- xo_format.5.gz ---
gzip -cn /usr/src/contrib/libxo/libxo/xo_format.5 > xo_format.5.gz
--- all ---
===> lib/libxo/tests (all)
--- test_01 ---
(cd /usr/src/lib/libxo/tests &&  DEPENDFILE=.depend.test_01  NO_SUBDIR=1 make 
-f /usr/src/lib/libxo/tests/Makefile _RECURSING_PROGS=t  PROG=test_01 )
--- .depend.test_01 ---
echo test_01.full: /usr/obj/usr/src/tmp/usr/lib/libc.a 
/usr/obj/usr/src/tmp/usr/lib/libxo.a /usr/obj/usr/src/tmp/usr/lib/libutil.a >> 
.depend.test_01
--- test_01.o ---
cc  -O2 -pipe   -I/usr/src/contrib/libxo/libxo -g -MD -MP 
-MF.depend.test_01.test_01.o -MTtest_01.o -std=gnu99 -fstack-protector-strong   
 -Qunused-arguments -c /usr/src/contrib/libxo/tests/core/test_01.c -o test_01.o
--- all_subdir_usr.sbin ---
--- exprep.o ---
cc  -O2 -pipe -DACPI_EXEC_APP -fno-strict-aliasing   
-I/usr/src/usr.sbin/acpi/acpidb/../../../sys -g -MD -MP -MF.depend.exprep.o 
-MTexprep.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef  
-Qunused-arguments -c 
/usr/src/usr.sbin/acpi/acpidb/../../../sys/contrib/dev/acpica/components/executer/exprep.c
 -o exprep.o
--- all_subdir_usr.bin ---
--- m4.full ---
cc -O2 -pipe -DEXTENDED -I/usr/src/usr.bin/m4 
-I/usr/src/usr.bin/m4/../../lib/libopenbsd -g -std=gnu99 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Qunused-arguments  -o m4.full eval.o expr.o look.o 
main.o misc.o gnum4.o trace.o parser.o tokenizer.o   -ly  -ll  -lm 
-L/usr/obj/usr/src/lib/libopenbsd -lopenbsd
--- all_subdir_lib ---
--- test_01.full -

Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

 I'm experiencing issue with threaded applications ( including many KDE 
applications ) after recent CURRENT update. Attempt to start application cause 
Abort trap (6) with "Fatal error 'mutex is on list' at line 139 in file 
/usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)" output on console. 

FreeBSD 11.0-CURRENT amd64 r296887

Backtrace from application looks like

Application: KGpg (kgpg), signal: Abort trap
[Switching to Thread 810815000 (LWP 100865/kgpg)]
[KCrash Handler]
#8  0x000807176d6a in thr_kill () from /lib/libc.so.7
#9  0x000807176d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#10 0x000807176ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#11 0x000806e9e62c in _thread_exit (fname=, 
lineno=, msg=) at 
/usr/src/lib/libthr/thread/thr_exit.c:182
#12 0x000806e996fc in mutex_lock_common (m=, 
abstime=, cvattach=) at 
/usr/src/lib/libthr/thread/thr_mutex.c:139
#13 0x000806e98c20 in __pthread_mutex_timedlock (mutex=0x81468, 
abstime=0x7fff5a58) at /usr/src/lib/libthr/thread/thr_mutex.c:566
#14 0x00080568b560 in KSharedDataCache::setTimestamp () from 
/usr/local/lib/libkdecore.so.5
#15 0x00080568b7df in KSharedDataCache::setTimestamp () from 
/usr/local/lib/libkdecore.so.5
#16 0x00080568802e in KSharedDataCache::find () from 
/usr/local/lib/libkdecore.so.5
#17 0x0008038192db in KIconLoader::drawOverlays () from 
/usr/local/lib/libkdeui.so.5
#18 0x00080381596a in KIconLoader::loadIcon () from 
/usr/local/lib/libkdeui.so.5
#19 0x000803814366 in KIconEffect::overlay () from 
/usr/local/lib/libkdeui.so.5
#20 0x0008040aff3d in QIcon::pixmap () from 
/usr/local/lib/qt4/libQtGui.so.4
#21 0x00080431e9df in QCommonStyle::drawControl () from 
/usr/local/lib/qt4/libQtGui.so.4
#22 0x00080437011f in QPlastiqueStyle::drawControl () from 
/usr/local/lib/qt4/libQtGui.so.4
#23 0x00080431be51 in QCommonStyle::drawControl () from 
/usr/local/lib/qt4/libQtGui.so.4
#24 0x00080437011f in QPlastiqueStyle::drawControl () from 
/usr/local/lib/qt4/libQtGui.so.4
#25 0x00080396151b in KPushButton::paintEvent () from 
/usr/local/lib/libkdeui.so.5
#26 0x00080405916c in QWidget::event () from 
/usr/local/lib/qt4/libQtGui.so.4
#27 0x0008043b7fd0 in QAbstractButton::event () from 
/usr/local/lib/qt4/libQtGui.so.4
#28 0x00080400a43c in QApplicationPrivate::notify_helper () from 
/usr/local/lib/qt4/libQtGui.so.4
#29 0x00080400ca61 in QApplication::notify () from 
/usr/local/lib/qt4/libQtGui.so.4
#30 0x0008038724b7 in KApplication::notify () from 
/usr/local/lib/libkdeui.so.5
#31 0x000805f8eaa6 in QCoreApplication::notifyInternal () from 
/usr/local/lib/qt4/libQtCore.so.4
#32 0x000804053eaa in QWidgetPrivate::drawWidget () from 
/usr/local/lib/qt4/libQtGui.so.4
#33 0x000804054657 in QWidgetPrivate::paintSiblingsRecursive () from 
/usr/local/lib/qt4/libQtGui.so.4
#34 0x00080405404e in QWidgetPrivate::drawWidget () from 
/usr/local/lib/qt4/libQtGui.so.4
#35 0x000804054657 in QWidgetPrivate::paintSiblingsRecursive () from 
/usr/local/lib/qt4/libQtGui.so.4
#36 0x00080405404e in QWidgetPrivate::drawWidget () from 
/usr/local/lib/qt4/libQtGui.so.4
#37 0x00080422d7b6 in QWidgetPrivate::scrollRect () from 
/usr/local/lib/qt4/libQtGui.so.4
#38 0x0008040590cb in QWidget::event () from 
/usr/local/lib/qt4/libQtGui.so.4
#39 0x00080400a43c in QApplicationPrivate::notify_helper () from 
/usr/local/lib/qt4/libQtGui.so.4
#40 0x00080400ca61 in QApplication::notify () from 
/usr/local/lib/qt4/libQtGui.so.4
#41 0x0008038724b7 in KApplication::notify () from 
/usr/local/lib/libkdeui.so.5
#42 0x000805f8eaa6 in QCoreApplication::notifyInternal () from 
/usr/local/lib/qt4/libQtCore.so.4
#43 0x00080422ae07 in QPrinterInfo::supportedPaperSizes () from 
/usr/local/lib/qt4/libQtGui.so.4
#44 0x00080405b44f in QWidget::repaint () from 
/usr/local/lib/qt4/libQtGui.so.4
#45 0x00080405b384 in QWidget::repaint () from 
/usr/local/lib/qt4/libQtGui.so.4
#46 0x0008043b804c in QAbstractButton::mousePressEvent () from 
/usr/local/lib/qt4/libQtGui.so.4
#47 0x0008040590be in QWidget::event () from 
/usr/local/lib/qt4/libQtGui.so.4
#48 0x0008043b7fd0 in QAbstractButton::event () from 
/usr/local/lib/qt4/libQtGui.so.4
#49 0x00080400a43c in QApplicationPrivate::notify_helper () from 
/usr/local/lib/qt4/libQtGui.so.4
#50 0x00080400bdbc in QApplication::notify () from 
/usr/local/lib/qt4/libQtGui.so.4
#51 0x0008038724b7 in KApplication::notify () from 
/usr/local/lib/libkdeui.so.5
#52 0x000805f8eaa6 in QCoreApplication::notifyInternal () from 
/usr/local/lib/qt4/libQtCore.so.4
#53 0x00080400ae87 in QApplicationPrivate::sendMouseEvent () from 
/usr/local/lib/qt4/libQtGui.so.4
#54 0x000804081cf5 in qt_try_modal () from 
/usr/local/lib/qt4/libQtGui.so.4
#55 0x00080408043b in QApplication::x11ProcessEvent () from 
/usr/local/lib/qt4/libQtGui.so.4
#56 0x0008040a

Re: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Konstantin Belousov]

On Sat, Mar 19, 2016 at 09:03:56AM +0200, Oleg V. Nauman wrote:
> On Friday 18 March 2016 11:55:31 Konstantin Belousov wrote:
> > On Fri, Mar 18, 2016 at 08:14:57AM +0200, Konstantin Belousov wrote:
> > > Yes, please.  It would be significantly easier to diagnose the problem if
> > > the minimal example is provided.  If not, please pack one crashing app
> > > and all it non-system libraries and provide the tarball to me.
> > 
> > Meantime you could also try the following change.  I doubt that it would
> > fix your issue, but it is possibly related.  Only libthr needs to be
> > rebuilt.
> > 
> > diff --git a/lib/libthr/thread/thr_fork.c b/lib/libthr/thread/thr_fork.c
> > index 7256b68..531e09c 100644
> > --- a/lib/libthr/thread/thr_fork.c
> > +++ b/lib/libthr/thread/thr_fork.c
> 
>  No it is still coredumping.
> The only positive effect is that segfaults are quite occasional comparing to 
> stock libthr
> 
> Loaded symbols for /libexec/ld-elf.so.1
> #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> [New Thread 809215000 (LWP 100253/)]
> (gdb) bt
> #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> #1  0x0008041b2d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
> #2  0x0008041b2ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> #3  0x000803eda67c in _thread_exit (fname=,
> lineno=, msg=)
> at /usr/src/lib/libthr/thread/thr_exit.c:182
> #4  0x000803ed56fc in mutex_lock_common (m=,
> abstime=, cvattach=)
> at /usr/src/lib/libthr/thread/thr_mutex.c:139
> #5  0x000803ed4c20 in __pthread_mutex_timedlock (mutex=0x81828,
> abstime=0x7fffc468) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> 
Again, please show me
p *mutex
p m
p *m
from the frame 5.
___
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: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Konstantin Belousov]

On Sat, Mar 19, 2016 at 12:14:33PM +0200, Konstantin Belousov wrote:
> On Sat, Mar 19, 2016 at 09:03:56AM +0200, Oleg V. Nauman wrote:
> > On Friday 18 March 2016 11:55:31 Konstantin Belousov wrote:
> > > On Fri, Mar 18, 2016 at 08:14:57AM +0200, Konstantin Belousov wrote:
> > > > Yes, please.  It would be significantly easier to diagnose the problem 
> > > > if
> > > > the minimal example is provided.  If not, please pack one crashing app
> > > > and all it non-system libraries and provide the tarball to me.
> > > 
> > > Meantime you could also try the following change.  I doubt that it would
> > > fix your issue, but it is possibly related.  Only libthr needs to be
> > > rebuilt.
> > > 
> > > diff --git a/lib/libthr/thread/thr_fork.c b/lib/libthr/thread/thr_fork.c
> > > index 7256b68..531e09c 100644
> > > --- a/lib/libthr/thread/thr_fork.c
> > > +++ b/lib/libthr/thread/thr_fork.c
> > 
> >  No it is still coredumping.
> > The only positive effect is that segfaults are quite occasional comparing 
> > to 
> > stock libthr
> > 
> > Loaded symbols for /libexec/ld-elf.so.1
> > #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > [New Thread 809215000 (LWP 100253/)]
> > (gdb) bt
> > #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > #1  0x0008041b2d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
> > #2  0x0008041b2ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> > #3  0x000803eda67c in _thread_exit (fname=,
> > lineno=, msg=)
> > at /usr/src/lib/libthr/thread/thr_exit.c:182
> > #4  0x000803ed56fc in mutex_lock_common (m=,
> > abstime=, cvattach=)
> > at /usr/src/lib/libthr/thread/thr_mutex.c:139
> > #5  0x000803ed4c20 in __pthread_mutex_timedlock (mutex=0x81828,
> > abstime=0x7fffc468) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> > 
> Again, please show me
> p *mutex
> p m
> p *m
> from the frame 5.
and also please do
p *curthread
___
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: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Saturday 19 March 2016 12:14:33 Konstantin Belousov wrote:
> On Sat, Mar 19, 2016 at 09:03:56AM +0200, Oleg V. Nauman wrote:
> > On Friday 18 March 2016 11:55:31 Konstantin Belousov wrote:
> > > On Fri, Mar 18, 2016 at 08:14:57AM +0200, Konstantin Belousov wrote:
> > > > Yes, please.  It would be significantly easier to diagnose the problem
> > > > if
> > > > the minimal example is provided.  If not, please pack one crashing app
> > > > and all it non-system libraries and provide the tarball to me.
> > > 
> > > Meantime you could also try the following change.  I doubt that it would
> > > fix your issue, but it is possibly related.  Only libthr needs to be
> > > rebuilt.
> > > 
> > > diff --git a/lib/libthr/thread/thr_fork.c b/lib/libthr/thread/thr_fork.c
> > > index 7256b68..531e09c 100644
> > > --- a/lib/libthr/thread/thr_fork.c
> > > +++ b/lib/libthr/thread/thr_fork.c
> >  
> >  No it is still coredumping.
> > 
> > The only positive effect is that segfaults are quite occasional comparing
> > to stock libthr
> > 
> > Loaded symbols for /libexec/ld-elf.so.1
> > #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > [New Thread 809215000 (LWP 100253/)]
> > (gdb) bt
> > #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > #1  0x0008041b2d3b in __raise (s=6) at
> > /usr/src/lib/libc/gen/raise.c:52
> > #2  0x0008041b2ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> > #3  0x000803eda67c in _thread_exit (fname=,
> > 
> > lineno=, msg=)
> > at /usr/src/lib/libthr/thread/thr_exit.c:182
> > 
> > #4  0x000803ed56fc in mutex_lock_common (m=,
> > 
> > abstime=, cvattach=)
> > at /usr/src/lib/libthr/thread/thr_mutex.c:139
> > 
> > #5  0x000803ed4c20 in __pthread_mutex_timedlock (mutex=0x81828,
> > 
> > abstime=0x7fffc468) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> 
> Again, please show me
> p *mutex
> p m
> p *m
> from the frame 5.

 #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
[New Thread 809215000 (LWP 100253/)]
(gdb) f 5
#5  0x000803ed4c20 in __pthread_mutex_timedlock (mutex=0x81828,
abstime=0x7fffc468) at /usr/src/lib/libthr/thread/thr_mutex.c:566
566 ret = mutex_lock_common(m, abstime, 0);
Current language:  auto; currently minimal
(gdb) p *mutex
$1 = 0x8001
(gdb) p m
$2 = 
(gdb) p *m
Cannot access memory at address 0x130049
(gdb)

Thank you!


___
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: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Konstantin Belousov]

On Sat, Mar 19, 2016 at 12:24:11PM +0200, Oleg V. Nauman wrote:
> On Saturday 19 March 2016 12:14:33 Konstantin Belousov wrote:
> > On Sat, Mar 19, 2016 at 09:03:56AM +0200, Oleg V. Nauman wrote:
> > > On Friday 18 March 2016 11:55:31 Konstantin Belousov wrote:
> > > > On Fri, Mar 18, 2016 at 08:14:57AM +0200, Konstantin Belousov wrote:
> > > > > Yes, please.  It would be significantly easier to diagnose the problem
> > > > > if
> > > > > the minimal example is provided.  If not, please pack one crashing app
> > > > > and all it non-system libraries and provide the tarball to me.
> > > > 
> > > > Meantime you could also try the following change.  I doubt that it would
> > > > fix your issue, but it is possibly related.  Only libthr needs to be
> > > > rebuilt.
> > > > 
> > > > diff --git a/lib/libthr/thread/thr_fork.c b/lib/libthr/thread/thr_fork.c
> > > > index 7256b68..531e09c 100644
> > > > --- a/lib/libthr/thread/thr_fork.c
> > > > +++ b/lib/libthr/thread/thr_fork.c
> > >  
> > >  No it is still coredumping.
> > > 
> > > The only positive effect is that segfaults are quite occasional comparing
> > > to stock libthr
> > > 
> > > Loaded symbols for /libexec/ld-elf.so.1
> > > #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > > [New Thread 809215000 (LWP 100253/)]
> > > (gdb) bt
> > > #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > > #1  0x0008041b2d3b in __raise (s=6) at
> > > /usr/src/lib/libc/gen/raise.c:52
> > > #2  0x0008041b2ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> > > #3  0x000803eda67c in _thread_exit (fname=,
> > > 
> > > lineno=, msg=)
> > > at /usr/src/lib/libthr/thread/thr_exit.c:182
> > > 
> > > #4  0x000803ed56fc in mutex_lock_common (m=,
> > > 
> > > abstime=, cvattach=)
> > > at /usr/src/lib/libthr/thread/thr_mutex.c:139
> > > 
> > > #5  0x000803ed4c20 in __pthread_mutex_timedlock (mutex=0x81828,
> > > 
> > > abstime=0x7fffc468) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> > 
> > Again, please show me
> > p *mutex
> > p m
> > p *m
> > from the frame 5.
> 
>  #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> [New Thread 809215000 (LWP 100253/)]
> (gdb) f 5
> #5  0x000803ed4c20 in __pthread_mutex_timedlock (mutex=0x81828,
> abstime=0x7fffc468) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> 566 ret = mutex_lock_common(m, abstime, 0);
> Current language:  auto; currently minimal
> (gdb) p *mutex
> $1 = 0x8001
> (gdb) p m
> $2 = 
> (gdb) p *m
> Cannot access memory at address 0x130049
> (gdb)
Try devel/gdb.  Also, you could recompile libthr with DEBUG_FLAGS="-O0 -g"
to get rid of optimizations.
___
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: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Saturday 19 March 2016 12:23:45 Konstantin Belousov wrote:
> On Sat, Mar 19, 2016 at 12:14:33PM +0200, Konstantin Belousov wrote:
> > On Sat, Mar 19, 2016 at 09:03:56AM +0200, Oleg V. Nauman wrote:
> > > On Friday 18 March 2016 11:55:31 Konstantin Belousov wrote:
> > > > On Fri, Mar 18, 2016 at 08:14:57AM +0200, Konstantin Belousov wrote:
> > > > > Yes, please.  It would be significantly easier to diagnose the
> > > > > problem if
> > > > > the minimal example is provided.  If not, please pack one crashing
> > > > > app
> > > > > and all it non-system libraries and provide the tarball to me.
> > > > 
> > > > Meantime you could also try the following change.  I doubt that it
> > > > would
> > > > fix your issue, but it is possibly related.  Only libthr needs to be
> > > > rebuilt.
> > > > 
> > > > diff --git a/lib/libthr/thread/thr_fork.c
> > > > b/lib/libthr/thread/thr_fork.c
> > > > index 7256b68..531e09c 100644
> > > > --- a/lib/libthr/thread/thr_fork.c
> > > > +++ b/lib/libthr/thread/thr_fork.c
> > >  
> > >  No it is still coredumping.
> > > 
> > > The only positive effect is that segfaults are quite occasional
> > > comparing to stock libthr
> > > 
> > > Loaded symbols for /libexec/ld-elf.so.1
> > > #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > > [New Thread 809215000 (LWP 100253/)]
> > > (gdb) bt
> > > #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > > #1  0x0008041b2d3b in __raise (s=6) at
> > > /usr/src/lib/libc/gen/raise.c:52
> > > #2  0x0008041b2ca9 in abort () at
> > > /usr/src/lib/libc/stdlib/abort.c:65
> > > #3  0x000803eda67c in _thread_exit (fname=,
> > > 
> > > lineno=, msg=)
> > > at /usr/src/lib/libthr/thread/thr_exit.c:182
> > > 
> > > #4  0x000803ed56fc in mutex_lock_common (m=,
> > > 
> > > abstime=, cvattach=)
> > > at /usr/src/lib/libthr/thread/thr_mutex.c:139
> > > 
> > > #5  0x000803ed4c20 in __pthread_mutex_timedlock (mutex=0x81828,
> > > 
> > > abstime=0x7fffc468) at
> > > /usr/src/lib/libthr/thread/thr_mutex.c:566
> > 
> > Again, please show me
> > p *mutex
> > p m
> > p *m
> > from the frame 5.
> 
> and also please do
> p *curthread

(gdb) p *curthread
No symbol "curthread" in current context.

___
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_gcc4.9 - Build #1127 - Failure

[jenkins-admin]

FreeBSD_HEAD_amd64_gcc4.9 - Build #1127 - Failure:

Build information: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1127/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1127/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1127/console

Change summaries:

296934 by hselasky:
Fix crash in krping when run as a client due to NULL pointer access.
Initialize pointer in question which is used only when fast registers
mode is selected.

Sponsored by:   Mellanox Technologies
MFC after:  1 week

296933 by hselasky:
Improve the implementation and documentation of the
SYSCTL_COUNTER_U64_ARRAY() macro.

- Add proper asserts to the SYSCTL_COUNTER_U64_ARRAY() macro that checks
  the size of the first element of the array.
- Add an example to the counter(9) manual page how to use the
  SYSCTL_COUNTER_U64_ARRAY() macro.
- Add some missing symbolic links for counter(9) while at it.

296932 by kp:
pf: Improve forwarding detection

When we guess the nature of the outbound packet (output vs. forwarding) we need
to take bridges into account. When bridging the input interface does not match
the output interface, but we're not forwarding. Similarly, it's possible for the
interface to actually be the bridge interface itself (and not a member 
interface).

PR: 202351
MFC after:  2 weeks

296931 by adrian:
Display the VHT IE names.

This doesn't decode the IEs just yet.

Tested:

* Archer c2 AP:

TP-LINK_D579_5G  60:e3:27:e1:d5:78   44   54M   26:0 100 EP 
  SSID RATES DSPARMS<44> 
COUNTRY TIM<05040001> HTCAP HTINFO VHTCAP VHTOPMODE 
RSN WME BSSLOAD<0b0501127a> 
VEN

296930 by adrian:
Add initial VHT IE's and action codes.

Yes, there's more to 802.11ac than this.

296929 by cem:
fail.9: Bump Dd

296927 by cem:
fail(9): Upstreaming some fail point enhancements

This is several year's worth of fail point upgrades done at EMC Isilon. They
are interdependent enough that it makes sense to put a single diff up for them.
Primarily, we added:

- Changing all mainline execution paths to be lockless, which lets us use fail
  points in more sleep-sensitive areas, and allows more parallel execution
- A number of additional commands, including 'pause' that lets us do some
  interesting deterministic repros of race conditions
- The ability to dump the stacks of all threads sleeping on a fail point
- A number of other API changes to allow marking up the fail point's context in
  the code, and firing callbacks before and after execution
- A man page update

Submitted by:   Matthew Bryan 
Reviewed by:cem (earlier version), jhb, kib, pho
With feedback from: bdrewery
Sponsored by:   EMC / Isilon Storage Division
Differential Revision:  https://reviews.freebsd.org/D5427

296926 by emaste:
kbdcontrol: add -P path option to add keymap search paths

PR: 193865
Reviewed by:cem
Sponsored by:   The FreeBSD Foundation
Differential Revision:  https://reviews.freebsd.org/D5645

296925 by adrian:
[net80211] Begin implementing rate control module stats.

* Implement a new ratectl method, which defaults to returning nothing;
* Add a top level sysctl (net.wlan.X.rate_stats) to extract it;
* Add ratectl info for the 'amrr' module.

Tested:

* urtwn(4), STA mode

Differential Revision:  https://reviews.freebsd.org/D5630

296922 by smh:
Prevent invalid ixgbe advertise setting warning

Prevent ixgbe outputting "Invalid advertised speed" warning on boot with
no customisations by moving test from sysctl handler to set handler.

PR: 208022
MFC after:  3 days
Sponsored by:   Multiplay

296921 by bdrewery:
Partially revert r266227 and stop stripping paths in ldscripts.

Specifically this fixes /usr/lib/libc.so stripping the paths to the
libraries.  The reason for this in r266227 was both likely because ld(1) did
not fully respect --sysroot until r291226 and because of the lib32
build.  The lib32 build does not use --sysroot into the /usr/lib32 path,
rather it only uses -L and -B into the /usr/lib32 path and --sysroot
into the normal (64bit) /usr/lib.  The _LDSCRIPTROOT was added with
the ldscript support in bsd.lib.mk so that it builds a 32-bit-sysrooted pathed
ldscript in the object directory and then installs a normal unprefixed
version in installworld.  This commit also fixes the rebuild during
install which was broken in r266227.  This commit would break DIRDEPS_BUILD
build of lib32 but it does not currently have a way to build it anyhow.

For example, before this change we had in /usr/lib/libc.so:
  GROUP ( libc.so.7 libc_nonshared.a libssp_nonshared.a )
Now it is restored to pre-r266227:
  GROUP ( /lib/libc.so.7 /usr/lib/libc_nonshared.a /usr/lib/libssp_nonshared.a )

The motivation for this is in testing of lld.
>From emaste:
  lld does not have built-in search paths (e.g. /lib, /usr/lib) and relies on
  -L arguments passed by the caller.  As the linker is nearly always invoked
  from the clang driver t

Re: boot loaders got fatter in the last few days

[Conrad Meyer]

On Fri, Mar 18, 2016 at 10:03 AM, Allan Jude  wrote:
> On 2016-03-18 12:33, Guido Falsi wrote:
>>
>> Hi,
>>
>> I have just update one of my machines and noticed the booloaders files
>> got quite fat in the last few days, some by a big margin.
>>
>> on an updated machine(r296993):
>>
>> -r--r--r--  1 root  wheel   85794 Mar 18 16:47 /boot/gptboot
>>
>> from a machine I still have not updated(r296719):
>>
>> -r--r--r--  1 root  wheel   16059 Mar 13 21:01 /boot/gptboot

So the loader grew 70 kB.  How big are your disks?

>> I noticed because mu gpt boot partition is 64K and gptzfsboot just
>> passed 100K.
>
> This is a side effect of the loader gaining the ability to boot from GELI
> encrypted partitions.
>
> ...
>
> Maybe we should be putting the GELI enabled boot blocks in a different
> filename? I generally wanted to avoid creating a new version of each
> bootcode with GELI support.


I think we should just suggest that boot partitions be much larger
than 64kB (1MB is still <0.1% of any disk sold today) and not worry
about it too much.  Embedded applications can disable GELI loader
support to save a few bytes.

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"

Re: r296548 breaks external DP and HDMI on HD4000

[Ian FREISLICH]

Hi,

It was running 2560x1440. I'm not sure if the chip can do 4k although tho 
Xorg probe suggests it might. Maybe the rest of the interface electronics 
can't support the higher clock rate.  r296547 does correctly run the 
external monitor at 2560x1440.


Sadly the monitor is an international flight away from me for the 1.5 
months so I can't test anything else until I'm back.


Ian


On 19 March 2016 01:10:54 Jean-Sébastien Pédron  wrote:


On 14/03/2016 18:59, Ian FREISLICH wrote:

Hi


Hi!


With r296548 on the following hardware:

vgapci0@pci0:0:2:0: class=0x03 card=0x15171043 chip=0x01668086

I get the following console messages when X starts and my external
monitor (Samsung U28E590) goes into epileptic fit attack mode.

[drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0
[drm:pid0:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting
[drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off
[drm:pid0:intel_cpt_verify_modeset] *ERROR* mode set failed: pipe 0 stuck
[drm:pid1100:ironlake_check_fdi_lanes] *ERROR* WARN ON:
I915_READ(SOUTH_CHICKEN1) & FDI_BC_BIFURCATION_SELECT
[drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail!
[drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail!


On my Haswell laptop, the external DisplayPort doesn't work either. When
using Ultra HD, I get garbage. When using Full HD, the image is correct
for a few seconds, then the output connector is disabled (talking about
Panel status timeout in dmesg).

What resolution do you use with your monitor? If you're using Ultra HD,
could you please try Full HD?

--
Jean-Sébastien Pédron





--


Cape Augusta Digital Properties, LLC a Cape Augusta Company

*Breach of confidentiality & accidental breach of confidentiality *

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.

___
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: boot loaders got fatter in the last few days

[Steven Hartland]

On 18/03/2016 17:42, Nikolai Lifanov wrote:

On 03/18/16 13:03, Allan Jude wrote:

On 2016-03-18 12:33, Guido Falsi wrote:

Hi,

I have just update one of my machines and noticed the booloaders files
got quite fat in the last few days, some by a big margin.

on an updated machine(r296993):


ls -l /boot/*boot*

-r--r--r--  1 root  wheel8192 Mar 18 16:47 /boot/boot
-r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot0
-r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot0sio
-r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot1
-r-xr-xr-x  1 root  wheel   72152 Mar 18 16:47 /boot/boot1.efi
-r--r--r--  1 root  wheel  819200 Mar 18 16:47 /boot/boot1.efifat
-r--r--r--  1 root  wheel7680 Mar 18 16:47 /boot/boot2
-r--r--r--  1 root  wheel1185 Mar 18 16:47 /boot/cdboot
-r--r--r--  1 root  wheel   85794 Mar 18 16:47 /boot/gptboot
-r--r--r--  1 root  wheel  110546 Mar 18 16:47 /boot/gptzfsboot
-r--r--r--  1 root  wheel  358400 Mar 18 16:47 /boot/pxeboot
-r--r--r--  1 root  wheel  341248 Mar 18 16:47 /boot/userboot.so
-r--r--r--  1 root  wheel   66048 Mar 18 16:47 /boot/zfsboot

from a machine I still have not updated(r296719):


ls -l /boot/*boot*

-r--r--r--  1 root  wheel8192 Mar 13 21:01 /boot/boot
-r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot0
-r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot0sio
-r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot1
-r-xr-xr-x  1 root  wheel   72152 Mar 13 21:01 /boot/boot1.efi
-r--r--r--  1 root  wheel  819200 Mar 13 21:01 /boot/boot1.efifat
-r--r--r--  1 root  wheel7680 Mar 13 21:01 /boot/boot2
-r--r--r--  1 root  wheel1185 Mar 13 21:01 /boot/cdboot
-r--r--r--  1 root  wheel   16059 Mar 13 21:01 /boot/gptboot
-r--r--r--  1 root  wheel   41511 Mar 13 21:01 /boot/gptzfsboot
-r--r--r--  1 root  wheel  288768 Mar 13 21:01 /boot/pxeboot
-r--r--r--  1 root  wheel  341208 Mar 13 21:01 /boot/userboot.so
-r--r--r--  1 root  wheel   66048 Mar 13 21:01 /boot/zfsboot

I noticed because mu gpt boot partition is 64K and gptzfsboot just
passed 100K.

Is this expected and I'm supposed to repartition or is this an unwanted
mistake?

Thanks in advance.


This is a side effect of the loader gaining the ability to boot from
GELI encrypted partitions.

You can compile with LOADER_NO_GELI_SUPPORT to disable this to get back
to a smaller one if you need.

Maybe we should be putting the GELI enabled boot blocks in a different
filename? I generally wanted to avoid creating a new version of each
bootcode with GELI support.

My goal somewhere down the road is to create a single bootcode that can
do UFS and ZFS, then maybe we can have gptboot and gptgeliboot or
something.



Maybe a single gptbootlite for minimum viable case of UFS+nothing fancy?
At some point in the near future users that want additional features
will re-partition and bsdinstall will create larger partitions for boot
and this won't be a problem.

P.S.: Allan, do you plan to enable GELI support for boot1.efi?

Makes it harder to use more features, so I would vote don't do this, 
keep a single boot image its bad enough we have separate zfs ufs loaders 
already.

___
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"

boot loaders got fatter in the last few days

[Guido Falsi]

Hi,

I have just update one of my machines and noticed the booloaders files
got quite fat in the last few days, some by a big margin.

on an updated machine(r296993):

> ls -l /boot/*boot*
-r--r--r--  1 root  wheel8192 Mar 18 16:47 /boot/boot
-r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot0
-r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot0sio
-r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot1
-r-xr-xr-x  1 root  wheel   72152 Mar 18 16:47 /boot/boot1.efi
-r--r--r--  1 root  wheel  819200 Mar 18 16:47 /boot/boot1.efifat
-r--r--r--  1 root  wheel7680 Mar 18 16:47 /boot/boot2
-r--r--r--  1 root  wheel1185 Mar 18 16:47 /boot/cdboot
-r--r--r--  1 root  wheel   85794 Mar 18 16:47 /boot/gptboot
-r--r--r--  1 root  wheel  110546 Mar 18 16:47 /boot/gptzfsboot
-r--r--r--  1 root  wheel  358400 Mar 18 16:47 /boot/pxeboot
-r--r--r--  1 root  wheel  341248 Mar 18 16:47 /boot/userboot.so
-r--r--r--  1 root  wheel   66048 Mar 18 16:47 /boot/zfsboot

from a machine I still have not updated(r296719):

> ls -l /boot/*boot*
-r--r--r--  1 root  wheel8192 Mar 13 21:01 /boot/boot
-r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot0
-r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot0sio
-r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot1
-r-xr-xr-x  1 root  wheel   72152 Mar 13 21:01 /boot/boot1.efi
-r--r--r--  1 root  wheel  819200 Mar 13 21:01 /boot/boot1.efifat
-r--r--r--  1 root  wheel7680 Mar 13 21:01 /boot/boot2
-r--r--r--  1 root  wheel1185 Mar 13 21:01 /boot/cdboot
-r--r--r--  1 root  wheel   16059 Mar 13 21:01 /boot/gptboot
-r--r--r--  1 root  wheel   41511 Mar 13 21:01 /boot/gptzfsboot
-r--r--r--  1 root  wheel  288768 Mar 13 21:01 /boot/pxeboot
-r--r--r--  1 root  wheel  341208 Mar 13 21:01 /boot/userboot.so
-r--r--r--  1 root  wheel   66048 Mar 13 21:01 /boot/zfsboot

I noticed because mu gpt boot partition is 64K and gptzfsboot just
passed 100K.

Is this expected and I'm supposed to repartition or is this an unwanted
mistake?

Thanks in advance.

-- 
Guido Falsi 
___
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: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Friday 18 March 2016 03:30:51 Konstantin Belousov wrote:
> On Thu, Mar 17, 2016 at 09:40:11PM +0200, Oleg V. Nauman wrote:
> >  I'm experiencing issue with threaded applications ( including many KDE
> > 
> > applications ) after recent CURRENT update. Attempt to start application
> > cause Abort trap (6) with "Fatal error 'mutex is on list' at line 139 in
> > file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)" output on
> > console.
> > 
> > FreeBSD 11.0-CURRENT amd64 r296887
> > 
> > Backtrace from application looks like
> > 
> > Application: KGpg (kgpg), signal: Abort trap
> > [Switching to Thread 810815000 (LWP 100865/kgpg)]
> > [KCrash Handler]
> > #8  0x000807176d6a in thr_kill () from /lib/libc.so.7
> > #9  0x000807176d3b in __raise (s=6) at
> > /usr/src/lib/libc/gen/raise.c:52
> > #10 0x000807176ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> > #11 0x000806e9e62c in _thread_exit (fname=,
> > lineno=, msg=) at
> > /usr/src/lib/libthr/thread/thr_exit.c:182
> > #12 0x000806e996fc in mutex_lock_common (m=,
> > abstime=, cvattach=) at
> > /usr/src/lib/libthr/thread/thr_mutex.c:139
> > #13 0x000806e98c20 in __pthread_mutex_timedlock (mutex=0x81468,
> > abstime=0x7fff5a58) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> 
> From the frame 13, please do
> p *mutex
> p *m
> p **mutex

 Got few cores today morning, for example:

gdb /usr/local/bin/akonadi_notes_agent akonadi_notes_agent.core
 ( list of many shared libraries loaded by application )

0  0x000805d08d6a in thr_kill () from /lib/libc.so.7
[New Thread 817615000 (LWP 100295/)]
(gdb) bt
#0  0x000805d08d6a in thr_kill () from /lib/libc.so.7
#1  0x000805d08d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2  0x000805d08ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#3  0x000805a3062c in _thread_exit (fname=, 
lineno=, msg=)
at /usr/src/lib/libthr/thread/thr_exit.c:182
#4  0x000805a2b6fc in mutex_lock_common (m=, 
abstime=, cvattach=)
at /usr/src/lib/libthr/thread/thr_mutex.c:139
#5  0x000805a2ac20 in __pthread_mutex_timedlock (mutex=0x81b28,
abstime=0x7fffd4f8) at /usr/src/lib/libthr/thread/thr_mutex.c:566
#6  0x00080448b560 in KSharedDataCache::setTimestamp ()
   from /usr/local/lib/libkdecore.so.5
#7  0x00080448b7df in KSharedDataCache::setTimestamp ()
   from /usr/local/lib/libkdecore.so.5
#8  0x000804487192 in KSharedDataCache::insert () from 
/usr/local/lib/libkdecore.so.5
#9  0x000802c1912e in KIconLoader::drawOverlays () from 
/usr/local/lib/libkdeui.so.5
#10 0x000802c15e3b in KIconLoader::loadIcon () from 
/usr/local/lib/libkdeui.so.5
#11 0x000802c14366 in KIconEffect::overlay () from 
/usr/local/lib/libkdeui.so.5
#12 0x0008034aff3d in QIcon::pixmap () from 
/usr/local/lib/qt4/libQtGui.so.4
#13 0x00080349d2d6 in QWidgetPrivate::setWindowIcon_sys ()
   from /usr/local/lib/qt4/libQtGui.so.4
#14 0x0008034590e7 in QWidget::event () from 
/usr/local/lib/qt4/libQtGui.so.4
#15 0x00080340a43c in QApplicationPrivate::notify_helper ()
   from /usr/local/lib/qt4/libQtGui.so.4
#16 0x00080340ca61 in QApplication::notify () from 
/usr/local/lib/qt4/libQtGui.so.4
#17 0x000802c724b7 in KApplication::notify () from 
/usr/local/lib/libkdeui.so.5
#18 0x000804d8eaa6 in QCoreApplication::notifyInternal ()
   from /usr/local/lib/qt4/libQtCore.so.4
#19 0x0008034084e1 in QApplication::setWindowIcon () from 
/usr/local/lib/qt4/libQtGui.so.4
#20 0x000802c74725 in KApplication::iceIOErrorHandler () from 
/usr/local/lib/libkdeui.so.5
#21 0x000802c72a9b in KApplication::KApplication () from 
/usr/local/lib/libkdeui.so.5
#22 0x000802c728f7 in KApplication::KApplication () from 
/usr/local/lib/libkdeui.so.5
#23 0x0040b10c in ?? ()
#24 0x0040a74f in ?? ()
#25 0x00080063a000 in ?? ()
#26 0x in ?? ()
(gdb) f 5
#5  0x000805a2ac20 in __pthread_mutex_timedlock (mutex=0x81b28,
abstime=0x7fffd4f8) at /usr/src/lib/libthr/thread/thr_mutex.c:566
566 ret = mutex_lock_common(m, abstime, 0);
Current language:  auto; currently minimal
(gdb) p *mutex
$1 = 0x8001
(gdb) p *m
$2 = {m_lock = {m_owner = 1, m_flags = 2147483648, m_ceilings = 0x81b200010,
m_spare = 0x81b200018}, m_flags = 0, m_owner = 0, m_count = 0, m_spinloops 
= 0,
  m_yieldloops = 0, m_qe = {tqe_next = 0x0, tqe_prev = 0x1}, m_pqe = {
tqe_next = 0x71100a0, tqe_prev = 0x1000}}
(gdb) p **mutex
Cannot access memory at address 0x8001


> 
> What non-KDE apps exhibit the behaviour ?

 I will try to find some simple application experiencing the same issue.
___
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"

USB disks attach after rootfs prompt

[Poul-Henning Kamp]

Running:

FreeBSD 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016

I tried "boot -a" and found that USB disks only attach *after* you
enter some root filesystem.

That's not terribly useful.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Saturday 19 March 2016 12:32:56 Konstantin Belousov wrote:
> On Sat, Mar 19, 2016 at 12:24:11PM +0200, Oleg V. Nauman wrote:
> > On Saturday 19 March 2016 12:14:33 Konstantin Belousov wrote:
> > > On Sat, Mar 19, 2016 at 09:03:56AM +0200, Oleg V. Nauman wrote:
> > > > On Friday 18 March 2016 11:55:31 Konstantin Belousov wrote:
> > > > > On Fri, Mar 18, 2016 at 08:14:57AM +0200, Konstantin Belousov wrote:
> > > > > > Yes, please.  It would be significantly easier to diagnose the
> > > > > > problem
> > > > > > if
> > > > > > the minimal example is provided.  If not, please pack one crashing
> > > > > > app
> > > > > > and all it non-system libraries and provide the tarball to me.
> > > > > 
> > > > > Meantime you could also try the following change.  I doubt that it
> > > > > would
> > > > > fix your issue, but it is possibly related.  Only libthr needs to be
> > > > > rebuilt.
> > > > > 
> > > > > diff --git a/lib/libthr/thread/thr_fork.c
> > > > > b/lib/libthr/thread/thr_fork.c
> > > > > index 7256b68..531e09c 100644
> > > > > --- a/lib/libthr/thread/thr_fork.c
> > > > > +++ b/lib/libthr/thread/thr_fork.c
> > > >  
> > > >  No it is still coredumping.
> > > > 
> > > > The only positive effect is that segfaults are quite occasional
> > > > comparing
> > > > to stock libthr
> > > > 
> > > > Loaded symbols for /libexec/ld-elf.so.1
> > > > #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > > > [New Thread 809215000 (LWP 100253/)]
> > > > (gdb) bt
> > > > #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > > > #1  0x0008041b2d3b in __raise (s=6) at
> > > > /usr/src/lib/libc/gen/raise.c:52
> > > > #2  0x0008041b2ca9 in abort () at
> > > > /usr/src/lib/libc/stdlib/abort.c:65
> > > > #3  0x000803eda67c in _thread_exit (fname=,
> > > > 
> > > > lineno=, msg=)
> > > > at /usr/src/lib/libthr/thread/thr_exit.c:182
> > > > 
> > > > #4  0x000803ed56fc in mutex_lock_common (m=,
> > > > 
> > > > abstime=, cvattach=)
> > > > at /usr/src/lib/libthr/thread/thr_mutex.c:139
> > > > 
> > > > #5  0x000803ed4c20 in __pthread_mutex_timedlock
> > > > (mutex=0x81828,
> > > > 
> > > > abstime=0x7fffc468) at
> > > > /usr/src/lib/libthr/thread/thr_mutex.c:566
> > > 
> > > Again, please show me
> > > p *mutex
> > > p m
> > > p *m
> > > from the frame 5.
> >  
> >  #0  0x0008041b2d6a in thr_kill () from /lib/libc.so.7
> > 
> > [New Thread 809215000 (LWP 100253/)]
> > (gdb) f 5
> > #5  0x000803ed4c20 in __pthread_mutex_timedlock (mutex=0x81828,
> > 
> > abstime=0x7fffc468) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> > 
> > 566 ret = mutex_lock_common(m, abstime, 0);
> > Current language:  auto; currently minimal
> > (gdb) p *mutex
> > $1 = 0x8001
> > (gdb) p m
> > $2 = 
> > (gdb) p *m
> > Cannot access memory at address 0x130049
> > (gdb)
> 
> Try devel/gdb.  Also, you could recompile libthr with DEBUG_FLAGS="-O0 -g"
> to get rid of optimizations.

Core was generated by `akonadi_baloo_index'.
Program terminated with signal SIGABRT, Aborted.
#0  0x000805630d6a in thr_kill () from /lib/libc.so.7
(gdb) bt
#0  0x000805630d6a in thr_kill () from /lib/libc.so.7
#1  0x000805630d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2  0x000805630ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#3  0x0008053564b4 in _thread_exit (
fname=0x805357b70 "/usr/src/lib/libthr/thread/thr_mutex.c", lineno=139,
msg=0x805357b97 "mutex is on list") at 
/usr/src/lib/libthr/thread/thr_exit.c:182
#4  0x00080534cddc in mutex_assert_not_owned (m=0x80064d000)
at /usr/src/lib/libthr/thread/thr_mutex.c:139
#5  0x00080534cfb9 in enqueue_mutex (curthread=0x80e015000, m=0x80064d000)
at /usr/src/lib/libthr/thread/thr_mutex.c:383
#6  0x00080534d213 in mutex_lock_common (m=0x80064d000, 
abstime=0x7fffd4e8,
cvattach=0) at /usr/src/lib/libthr/thread/thr_mutex.c:533
#7  0x00080534c6be in __pthread_mutex_timedlock (mutex=0x811c8,
abstime=0x7fffd4e8) at /usr/src/lib/libthr/thread/thr_mutex.c:566

(gdb) f 7
#7  0x00080534c6be in __pthread_mutex_timedlock (mutex=0x811c8,
abstime=0x7fffd4e8) at /usr/src/lib/libthr/thread/thr_mutex.c:566
566 ret = mutex_lock_common(m, abstime, 0);
(gdb) p *mutex
$1 = (pthread_mutex_t) 0x8001
(gdb) p m
$2 = (struct pthread_mutex *) 0x80064d000
(gdb) p *m
$3 = {m_lock = {m_owner = -2147383372, m_flags = 1, m_ceilings = {0, 0}, 
m_spare = {0, 0, 0,
  0}}, m_flags = 1, m_owner = 100276, m_count = 0, m_spinloops = 0, 
m_yieldloops = 0,
  m_qe = {tqe_next = 0x0, tqe_prev = 0x0}, m_pqe = {tqe_next = 0x0, tqe_prev = 
0x0}}
(gdb) p *curthread
No symbol "curthread" in current context.
(gdb)
 


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsu

Re: USB disks attach after rootfs prompt

[Ian Lepore]

On Sat, 2016-03-19 at 13:04 +, Poul-Henning Kamp wrote:
> Running:
> 
>   FreeBSD 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016
> 
> I tried "boot -a" and found that USB disks only attach *after* you
> enter some root filesystem.
> 
> That's not terribly useful.
> 

iirc, interrupts are disabled while you're at the mountroot prompt,
which freezes usb enumeration.  It should do a sleep/pause every time
you enter '.', which should allow the interrupt-driven enumeration to
finish.  It's been a long time since I've done it, but it seems to
still work... I just plugged in a usb drive while I was at the prompt
and it didn't show up until the second time I entered a '.'.

-- 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"

Current-11 slow

[Baho Utot]

Current-11 is slower than FreeBSD-10.2 on my dell lapfart

I fetched and complied current-11 r296326 following the handbook.
I used a custom kernel config, make.conf and src.conf trying to create a 
"released" install.


Is there any issues with my configuration or do I need to add anything.


FreeBSD dell.example.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r296326: 
Sat Mar  5 20:48:00 EST 2016 
r...@dell.bildanet.com:/usr/obj/usr/src/sys/OCTOTHORPE  amd64


octothorpe.conf
include GENERIC
nocpu   i486_CPU
ident   OCTOTHORPE

nooptions   INET6
nooptions   WITNESS
nooptions   INVARIANTS

nodevicefdc

/etc/src.conf
MALLOC_PRODUCTION="ON"
WITHOUT_ASSERT_DEBUG="ON"
MK_PROFILE=no

/etc/make.conf
MALLOC_PRODUCTION=TRUE
KERNCONF=OCTOTHORPE
MK_PROFILE=no

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"

Re: Current-11 slow

[Ultima]

Upgrade your source and reinstall, this issue was fixed sometime around
r296377.

On Sat, Mar 19, 2016 at 10:44 AM, Baho Utot 
wrote:

> Current-11 is slower than FreeBSD-10.2 on my dell lapfart
>
> I fetched and complied current-11 r296326 following the handbook.
> I used a custom kernel config, make.conf and src.conf trying to create a
> "released" install.
>
> Is there any issues with my configuration or do I need to add anything.
>
>
> FreeBSD dell.example.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r296326:
> Sat Mar  5 20:48:00 EST 2016 
> r...@dell.bildanet.com:/usr/obj/usr/src/sys/OCTOTHORPE
> amd64
>
> octothorpe.conf
> include GENERIC
> nocpu   i486_CPU
> ident   OCTOTHORPE
>
> nooptions   INET6
> nooptions   WITNESS
> nooptions   INVARIANTS
>
> nodevicefdc
>
> /etc/src.conf
> MALLOC_PRODUCTION="ON"
> WITHOUT_ASSERT_DEBUG="ON"
> MK_PROFILE=no
>
> /etc/make.conf
> MALLOC_PRODUCTION=TRUE
> KERNCONF=OCTOTHORPE
> MK_PROFILE=no
>
> 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"
>
___
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: USB disks attach after rootfs prompt

[Poul-Henning Kamp]

In message <1458397972.68920.69.ca...@freebsd.org>, Ian Lepore writes:
>On Sat, 2016-03-19 at 13:04 +, Poul-Henning Kamp wrote:
>> Running:
>> 
>>  FreeBSD 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016
>> 
>> I tried "boot -a" and found that USB disks only attach *after* you
>> enter some root filesystem.
>> 
>> That's not terribly useful.
>
>iirc, interrupts are disabled while you're at the mountroot prompt,
>which freezes usb enumeration.

I am somewhat certain that this used to work...


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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: boot loaders got fatter in the last few days

[Steven Hartland]

On 18/03/2016 17:51, Guido Falsi wrote:

On 03/18/16 17:54, José Pérez wrote:

Hi Guido,
maybe it's because of this:
https://svnweb.freebsd.org/base?view=revision&revision=296963


I see.

There is a problem with this though, we have howtos suggesting 64K for
the size of the freebsd-boot gpt partition:

https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1

now that size isn't sufficient anymore. We should at least update these
information soon.

Also repartitioning could be problematic in certain scenarios. I think
this change should be at least published in UPDATING and maybe also in
the future release notes for 11.0.

Personally I'll find a way of reorganizing my disks to fit this change,
but it's something that could byte users.

Yes indeed I would suggest if we increase it we do by a decent amount 
e.g. jump straight to 1MB.


Regards
Steve
___
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: xo_config.h missing?

[Jung-uk Kim]

On 03/16/16 09:28 PM, Larry Rosenman wrote:
> ll_subdir_usr.bin/xo ---
> /usr/src/contrib/libxo/xo/xo.c:16:10: fatal error: 'xo_config.h' file not 
> found
> #include "xo_config.h"
> 
> 
> 
> Path: /usr/src
> Working Copy Root Path: /usr/src
> URL: https://svn.freebsd.org/base/head
> Relative URL: ^/head
> Repository Root: https://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 296976
> Node Kind: directory
> Schedule: normal
> Last Changed Author: np
> Last Changed Rev: 296975
> Last Changed Date: 2016-03-16 20:15:16 -0500 (Wed, 16 Mar 2016)

It seems r296967 is the culprit:

https://svnweb.freebsd.org/changeset/base/296967
The attached patch fixed the build issues for me.

Jung-uk Kim
Index: lib/libxo/tests/Makefile
===
--- lib/libxo/tests/Makefile	(revision 296976)
+++ lib/libxo/tests/Makefile	(working copy)
@@ -241,6 +241,7 @@ PROGS+= test_10
 PROGS+= test_11
 
 CFLAGS+=	-I${LIBXOSRC}/libxo
+CFLAGS+=	-I${SRCTOP}/lib/libxo
 
 LIBADD=		xo util 
 
Index: usr.bin/xo/Makefile
===
--- usr.bin/xo/Makefile	(revision 296976)
+++ usr.bin/xo/Makefile	(working copy)
@@ -12,6 +12,9 @@ MAN=	xo.1
 # XXX For xoversion.h
 CFLAGS+=-I${LIBXOSRC}/libxo
 
+# XXX For xo_config.h
+CFLAGS+=-I${SRCTOP}/lib/libxo
+
 LIBADD=	xo
 
 .if ${MK_TESTS} != "no"


signature.asc
Description: OpenPGP digital signature

xo_config.h missing?

[Larry Rosenman]

ll_subdir_usr.bin/xo ---
/usr/src/contrib/libxo/xo/xo.c:16:10: fatal error: 'xo_config.h' file not found
#include "xo_config.h"



Path: /usr/src
Working Copy Root Path: /usr/src
URL: https://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 296976
Node Kind: directory
Schedule: normal
Last Changed Author: np
Last Changed Rev: 296975
Last Changed Date: 2016-03-16 20:15:16 -0500 (Wed, 16 Mar 2016)


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
___
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: USB disks attach after rootfs prompt

[Justin Hibbits]

On Sat, 19 Mar 2016 15:09:35 +
"Poul-Henning Kamp"  wrote:

> 
> In message <1458397972.68920.69.ca...@freebsd.org>, Ian Lepore writes:
> >On Sat, 2016-03-19 at 13:04 +, Poul-Henning Kamp wrote:  
> >> Running:
> >> 
> >>FreeBSD 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC
> >> 2016
> >> 
> >> I tried "boot -a" and found that USB disks only attach *after* you
> >> enter some root filesystem.
> >> 
> >> That's not terribly useful.  
> >
> >iirc, interrupts are disabled while you're at the mountroot prompt,
> >which freezes usb enumeration.  
> 
> I am somewhat certain that this used to work...
> 
> 

Tunable vfs.mountroot.timeout may be what you're looking for.  By
default it waits for 3 seconds, but for USB it's suggested 10s or more,
from what I recall.

- Justin
___
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: boot loaders got fatter in the last few days

[Allan Jude]

On 2016-03-18 13:42, Nikolai Lifanov wrote:

On 03/18/16 13:03, Allan Jude wrote:

On 2016-03-18 12:33, Guido Falsi wrote:

Hi,

I have just update one of my machines and noticed the booloaders files
got quite fat in the last few days, some by a big margin.

on an updated machine(r296993):


ls -l /boot/*boot*

-r--r--r--  1 root  wheel8192 Mar 18 16:47 /boot/boot
-r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot0
-r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot0sio
-r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot1
-r-xr-xr-x  1 root  wheel   72152 Mar 18 16:47 /boot/boot1.efi
-r--r--r--  1 root  wheel  819200 Mar 18 16:47 /boot/boot1.efifat
-r--r--r--  1 root  wheel7680 Mar 18 16:47 /boot/boot2
-r--r--r--  1 root  wheel1185 Mar 18 16:47 /boot/cdboot
-r--r--r--  1 root  wheel   85794 Mar 18 16:47 /boot/gptboot
-r--r--r--  1 root  wheel  110546 Mar 18 16:47 /boot/gptzfsboot
-r--r--r--  1 root  wheel  358400 Mar 18 16:47 /boot/pxeboot
-r--r--r--  1 root  wheel  341248 Mar 18 16:47 /boot/userboot.so
-r--r--r--  1 root  wheel   66048 Mar 18 16:47 /boot/zfsboot

from a machine I still have not updated(r296719):


ls -l /boot/*boot*

-r--r--r--  1 root  wheel8192 Mar 13 21:01 /boot/boot
-r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot0
-r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot0sio
-r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot1
-r-xr-xr-x  1 root  wheel   72152 Mar 13 21:01 /boot/boot1.efi
-r--r--r--  1 root  wheel  819200 Mar 13 21:01 /boot/boot1.efifat
-r--r--r--  1 root  wheel7680 Mar 13 21:01 /boot/boot2
-r--r--r--  1 root  wheel1185 Mar 13 21:01 /boot/cdboot
-r--r--r--  1 root  wheel   16059 Mar 13 21:01 /boot/gptboot
-r--r--r--  1 root  wheel   41511 Mar 13 21:01 /boot/gptzfsboot
-r--r--r--  1 root  wheel  288768 Mar 13 21:01 /boot/pxeboot
-r--r--r--  1 root  wheel  341208 Mar 13 21:01 /boot/userboot.so
-r--r--r--  1 root  wheel   66048 Mar 13 21:01 /boot/zfsboot

I noticed because mu gpt boot partition is 64K and gptzfsboot just
passed 100K.

Is this expected and I'm supposed to repartition or is this an unwanted
mistake?

Thanks in advance.



This is a side effect of the loader gaining the ability to boot from
GELI encrypted partitions.

You can compile with LOADER_NO_GELI_SUPPORT to disable this to get back
to a smaller one if you need.

Maybe we should be putting the GELI enabled boot blocks in a different
filename? I generally wanted to avoid creating a new version of each
bootcode with GELI support.

My goal somewhere down the road is to create a single bootcode that can
do UFS and ZFS, then maybe we can have gptboot and gptgeliboot or
something.




Maybe a single gptbootlite for minimum viable case of UFS+nothing fancy?
At some point in the near future users that want additional features
will re-partition and bsdinstall will create larger partitions for boot
and this won't be a problem.


'gptbootlite' would be what gptboot was until recently. I Agree with 
smh@ that we don't want to end up offering 10 different bootcode options.


The installer, since 10.1 has created 512kb freebsd-boot partitions, 
specifically to allow the boot loader to grow in the future.




P.S.: Allan, do you plan to enable GELI support for boot1.efi?


Yes, I hope to have this done and present it at BSDCan. Hopefully 
committed earlier than that, so it will ship as part of 11.0




- Nikolai Lifanov

___
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"




--
Allan Jude
___
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: boot loaders got fatter in the last few days

[Allan Jude]

On 2016-03-18 17:41, Freddie Cash wrote:


On Fri, Mar 18, 2016 at 10:39 AM, Conrad Meyer mailto:c...@freebsd.org>> wrote:

On Fri, Mar 18, 2016 at 10:03 AM, Allan Jude mailto:allanj...@freebsd.org>> wrote:
 > On 2016-03-18 12:33, Guido Falsi wrote:
 >>
 >> Hi,
 >>
 >> I have just update one of my machines and noticed the booloaders
files
 >> got quite fat in the last few days, some by a big margin.
 >>
 >> on an updated machine(r296993):
 >>
 >> -r--r--r--  1 root  wheel   85794 Mar 18 16:47 /boot/gptboot
 >>
 >> from a machine I still have not updated(r296719):
 >>
 >> -r--r--r--  1 root  wheel   16059 Mar 13 21:01 /boot/gptboot

So the loader grew 70 kB.  How big are your disks?

 >> I noticed because mu gpt boot partition is 64K and gptzfsboot just
 >> passed 100K.
 >
 > This is a side effect of the loader gaining the ability to boot
from GELI
 > encrypted partitions.
 >
 > ...
 >
 > Maybe we should be putting the GELI enabled boot blocks in a
different
 > filename? I generally wanted to avoid creating a new version of each
 > bootcode with GELI support.


I think we should just suggest that boot partitions be much larger
than 64kB (1MB is still <0.1% of any disk sold today) and not worry
about it too much.  Embedded applications can disable GELI loader
support to save a few bytes.


​The boot partition doesn't necessarily need ​
​to be 1 MB (and can't due to some issues with the assembler used right
now, or something like that).  We just need to make sure people have
slack space in their partition table to expand into in the future.

Using "-a 1M" in your gpart command to create your first data partition
gives you that slack space.

gpart create -s gpt ada0
gpart add -t freebsd-boot -s 256K -l boot ada0
gpart add -t freebsd-ufs  -s 10G  -l root -a 1M ada0

That leaves ~756 KB of free space between the end of the boot partition
and the start of the first data partition.  Increasing the size of the
boot partition in the future is as easy as (no formatting of disks
required):

gpart delete -i 1 ada0
gpart add -t freebsd-boot -s 512K -l boot ada0
gpart bootcode -b ... -p ... ada0

It's a handy pattern I've gotten used to over the years, ever since the
first 4K sector harddrives were advertised (as alignment of filesystems
was/is *very* important)​.

Even on disks that will be used solely for ZFS I've taken to creating
GPT partitions starting at 1 MB.  And it's saved me from having to
reformat disks when moving from a separate root filesystem (no USB
sticks) to root-on-ZFS as there was 1 MB of free space at the start of
every disk for creating boot partitions.  :)

--
Freddie Cash
fjwc...@gmail.com 


This also has the handy side effect of allowing you to switch to booting 
with UEFI, which currently uses an 800kb fat file system


--
Allan Jude
___
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: boot loaders got fatter in the last few days

[Guido Falsi]

On 03/18/16 19:05, Allan Jude wrote:
> On 2016-03-18 13:51, Guido Falsi wrote:
>> On 03/18/16 17:54, José Pérez wrote:
>>> Hi Guido,
>>> maybe it's because of this:
>>> https://svnweb.freebsd.org/base?view=revision&revision=296963
>>>
>>
>> I see.
>>
>> There is a problem with this though, we have howtos suggesting 64K for
>> the size of the freebsd-boot gpt partition:
>>
>> https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1
>>
>> now that size isn't sufficient anymore. We should at least update these
>> information soon.
>>
>> Also repartitioning could be problematic in certain scenarios. I think
>> this change should be at least published in UPDATING and maybe also in
>> the future release notes for 11.0.
>>
>> Personally I'll find a way of reorganizing my disks to fit this change,
>> but it's something that could byte users.
>>
> 
> Those old bits of the wiki should be burned with fire. The one you link
> to is from 2009 and is full of bad advice, and only covers how to
> install FreeBSD 8.x

I agree with you, having installed this one system following such advice
and having discovered also other problems.

Just yesterday I installed a ZFS system (using UEFI) straight from an
head snapshot and it did everything perfect, so I'm quite happy about
how things evolved.

What I was trying to express is that, just like me, other people could
get bitten by this change. Too me it's just an annoyance of shuffling
partitions around a little, but we should at least have a small warning
for the forthcoming release.

-- 
Guido Falsi 
___
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: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Friday 18 March 2016 11:55:31 Konstantin Belousov wrote:
> On Fri, Mar 18, 2016 at 08:14:57AM +0200, Konstantin Belousov wrote:
> > Yes, please.  It would be significantly easier to diagnose the problem if
> > the minimal example is provided.  If not, please pack one crashing app
> > and all it non-system libraries and provide the tarball to me.
> 
> Meantime you could also try the following change.  I doubt that it would
> fix your issue, but it is possibly related.  Only libthr needs to be
> rebuilt.

 I will try it tomorrow morning and will send the report.

Thank you!

> 
> diff --git a/lib/libthr/thread/thr_fork.c b/lib/libthr/thread/thr_fork.c
> index 7256b68..531e09c 100644
> --- a/lib/libthr/thread/thr_fork.c
> +++ b/lib/libthr/thread/thr_fork.c
> @@ -168,6 +168,7 @@ __thr_fork(void)
>   if (_thr_isthreaded() != 0) {
>   was_threaded = 1;
>   _malloc_prefork();
> + __thr_pshared_atfork_pre();
>   _rtld_atfork_pre(rtld_locks);
>   } else {
>   was_threaded = 0;
> @@ -202,8 +203,10 @@ __thr_fork(void)
> 
>   _thr_signal_postfork_child();
> 
> - if (was_threaded)
> + if (was_threaded) {
>   _rtld_atfork_post(rtld_locks);
> + __thr_pshared_atfork_post();
> + }
>   _thr_setthreaded(0);
> 
>   /* reinitalize library. */
> @@ -236,6 +239,7 @@ __thr_fork(void)
> 
>   if (was_threaded) {
>   _rtld_atfork_post(rtld_locks);
> + __thr_pshared_atfork_post();
>   _malloc_postfork();
>   }
> 
> diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c
> index 3c81299..5e7f01c 100644
> --- a/lib/libthr/thread/thr_init.c
> +++ b/lib/libthr/thread/thr_init.c
> @@ -466,7 +466,6 @@ init_private(void)
>   _thr_once_init();
>   _thr_spinlock_init();
>   _thr_list_init();
> - __thr_pshared_init();
>   _thr_wake_addr_init();
>   _sleepq_init();
>   _single_thread = NULL;
> @@ -477,6 +476,7 @@ init_private(void)
>* e.g. after a fork().
>*/
>   if (init_once == 0) {
> + __thr_pshared_init();
>   /* Find the stack top */
>   mib[0] = CTL_KERN;
>   mib[1] = KERN_USRSTACK;
> diff --git a/lib/libthr/thread/thr_private.h
> b/lib/libthr/thread/thr_private.h index 31f8e6c..7ee1fbf 100644
> --- a/lib/libthr/thread/thr_private.h
> +++ b/lib/libthr/thread/thr_private.h
> @@ -952,6 +952,8 @@ void  _tcb_dtor(struct tcb *);
>  void __thr_pshared_init(void) __hidden;
>  void *__thr_pshared_offpage(void *key, int doalloc) __hidden;
>  void __thr_pshared_destroy(void *key) __hidden;
> +void __thr_pshared_atfork_pre(void) __hidden;
> +void __thr_pshared_atfork_post(void) __hidden;
> 
>  __END_DECLS
> 
> diff --git a/lib/libthr/thread/thr_pshared.c
> b/lib/libthr/thread/thr_pshared.c index e8ccf1c..8371478 100644
> --- a/lib/libthr/thread/thr_pshared.c
> +++ b/lib/libthr/thread/thr_pshared.c
> @@ -252,3 +252,17 @@ __thr_pshared_destroy(void *key)
>   pshared_clean(key, val);
>   pshared_gc(curthread);
>  }
> +
> +void
> +__thr_pshared_atfork_pre(void)
> +{
> +
> + _thr_rwl_rdlock(&pshared_lock);
> +}
> +
> +void
> +__thr_pshared_atfork_post(void)
> +{
> +
> + _thr_rwl_unlock(&pshared_lock);
> +}

___
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: boot loaders got fatter in the last few days

[Allan Jude]

On 2016-03-18 17:48, Freddie Cash wrote:



On Fri, Mar 18, 2016 at 2:45 PM, Allan Jude mailto:allanj...@freebsd.org>> wrote:

On 2016-03-18 17:41, Freddie Cash wrote:


On Fri, Mar 18, 2016 at 10:39 AM, Conrad Meyer mailto:c...@freebsd.org>
>> wrote:

 On Fri, Mar 18, 2016 at 10:03 AM, Allan Jude
mailto:allanj...@freebsd.org>
 >> wrote:
  > On 2016-03-18 12:33, Guido Falsi wrote:
  >>
  >> Hi,
  >>
  >> I have just update one of my machines and noticed the
booloaders
 files
  >> got quite fat in the last few days, some by a big margin.
  >>
  >> on an updated machine(r296993):
  >>
  >> -r--r--r--  1 root  wheel   85794 Mar 18 16:47
/boot/gptboot
  >>
  >> from a machine I still have not updated(r296719):
  >>
  >> -r--r--r--  1 root  wheel   16059 Mar 13 21:01
/boot/gptboot

 So the loader grew 70 kB.  How big are your disks?

  >> I noticed because mu gpt boot partition is 64K and
gptzfsboot just
  >> passed 100K.
  >
  > This is a side effect of the loader gaining the ability
to boot
 from GELI
  > encrypted partitions.
  >
  > ...
  >
  > Maybe we should be putting the GELI enabled boot blocks in a
 different
  > filename? I generally wanted to avoid creating a new
version of each
  > bootcode with GELI support.


 I think we should just suggest that boot partitions be much
larger
 than 64kB (1MB is still <0.1% of any disk sold today) and
not worry
 about it too much.  Embedded applications can disable GELI
loader
 support to save a few bytes.


​The boot partition doesn't necessarily need ​
​to be 1 MB (and can't due to some issues with the assembler
used right
now, or something like that).  We just need to make sure people have
slack space in their partition table to expand into in the future.

Using "-a 1M" in your gpart command to create your first data
partition
gives you that slack space.

gpart create -s gpt ada0
gpart add -t freebsd-boot -s 256K -l boot ada0
gpart add -t freebsd-ufs  -s 10G  -l root -a 1M ada0

That leaves ~756 KB of free space between the end of the boot
partition
and the start of the first data partition.  Increasing the size
of the
boot partition in the future is as easy as (no formatting of disks
required):

gpart delete -i 1 ada0
gpart add -t freebsd-boot -s 512K -l boot ada0
gpart bootcode -b ... -p ... ada0

It's a handy pattern I've gotten used to over the years, ever
since the
first 4K sector harddrives were advertised (as alignment of
filesystems
was/is *very* important)​.

Even on disks that will be used solely for ZFS I've taken to
creating
GPT partitions starting at 1 MB.  And it's saved me from having to
reformat disks when moving from a separate root filesystem (no USB
sticks) to root-on-ZFS as there was 1 MB of free space at the
start of
every disk for creating boot partitions.  :)

--
Freddie Cash
fjwc...@gmail.com 
>


This also has the handy side effect of allowing you to switch to
booting with UEFI, which currently uses an 800kb fat file system


​And I'm pretty sure I read somewhere that the 10.x installer defaults
to using "-a 1M" when partitioning new disks, although I haven't installed ​
​any 10.x systems from scratch yet (just upgrades from 9.x).​

--
Freddie Cash
fjwc...@gmail.com 


Yes, when I built the 10.x 'ZFS' installer mode, I set it to do the 
right thing. I'll have to look into making sure UFS via 'sade' does the 
right thing though


--
Allan Jude
___
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: boot loaders got fatter in the last few days

[Freddie Cash]

On Fri, Mar 18, 2016 at 2:45 PM, Allan Jude  wrote:

> On 2016-03-18 17:41, Freddie Cash wrote:
>
>>
>> On Fri, Mar 18, 2016 at 10:39 AM, Conrad Meyer > > wrote:
>>
>> On Fri, Mar 18, 2016 at 10:03 AM, Allan Jude > > wrote:
>>  > On 2016-03-18 12:33, Guido Falsi wrote:
>>  >>
>>  >> Hi,
>>  >>
>>  >> I have just update one of my machines and noticed the booloaders
>> files
>>  >> got quite fat in the last few days, some by a big margin.
>>  >>
>>  >> on an updated machine(r296993):
>>  >>
>>  >> -r--r--r--  1 root  wheel   85794 Mar 18 16:47 /boot/gptboot
>>  >>
>>  >> from a machine I still have not updated(r296719):
>>  >>
>>  >> -r--r--r--  1 root  wheel   16059 Mar 13 21:01 /boot/gptboot
>>
>> So the loader grew 70 kB.  How big are your disks?
>>
>>  >> I noticed because mu gpt boot partition is 64K and gptzfsboot just
>>  >> passed 100K.
>>  >
>>  > This is a side effect of the loader gaining the ability to boot
>> from GELI
>>  > encrypted partitions.
>>  >
>>  > ...
>>  >
>>  > Maybe we should be putting the GELI enabled boot blocks in a
>> different
>>  > filename? I generally wanted to avoid creating a new version of
>> each
>>  > bootcode with GELI support.
>>
>>
>> I think we should just suggest that boot partitions be much larger
>> than 64kB (1MB is still <0.1% of any disk sold today) and not worry
>> about it too much.  Embedded applications can disable GELI loader
>> support to save a few bytes.
>>
>>
>> ​The boot partition doesn't necessarily need ​
>> ​to be 1 MB (and can't due to some issues with the assembler used right
>> now, or something like that).  We just need to make sure people have
>> slack space in their partition table to expand into in the future.
>>
>> Using "-a 1M" in your gpart command to create your first data partition
>> gives you that slack space.
>>
>> gpart create -s gpt ada0
>> gpart add -t freebsd-boot -s 256K -l boot ada0
>> gpart add -t freebsd-ufs  -s 10G  -l root -a 1M ada0
>>
>> That leaves ~756 KB of free space between the end of the boot partition
>> and the start of the first data partition.  Increasing the size of the
>> boot partition in the future is as easy as (no formatting of disks
>> required):
>>
>> gpart delete -i 1 ada0
>> gpart add -t freebsd-boot -s 512K -l boot ada0
>> gpart bootcode -b ... -p ... ada0
>>
>> It's a handy pattern I've gotten used to over the years, ever since the
>> first 4K sector harddrives were advertised (as alignment of filesystems
>> was/is *very* important)​.
>>
>> Even on disks that will be used solely for ZFS I've taken to creating
>> GPT partitions starting at 1 MB.  And it's saved me from having to
>> reformat disks when moving from a separate root filesystem (no USB
>> sticks) to root-on-ZFS as there was 1 MB of free space at the start of
>> every disk for creating boot partitions.  :)
>>
>> --
>> Freddie Cash
>> fjwc...@gmail.com 
>>
>
> This also has the handy side effect of allowing you to switch to booting
> with UEFI, which currently uses an 800kb fat file system


​And I'm pretty sure I read somewhere that the 10.x installer defaults to
using "-a 1M" when partitioning new disks, although I haven't installed ​

​any 10.x systems from scratch yet (just upgrades from 9.x).​

-- 
Freddie Cash
fjwc...@gmail.com
___
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: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Konstantin Belousov]

On Sat, Mar 19, 2016 at 04:03:06PM +0200, Oleg V. Nauman wrote:
> Core was generated by `akonadi_baloo_index'.
> Program terminated with signal SIGABRT, Aborted.
> #0  0x000805630d6a in thr_kill () from /lib/libc.so.7
> (gdb) bt
> #0  0x000805630d6a in thr_kill () from /lib/libc.so.7
> #1  0x000805630d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
> #2  0x000805630ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> #3  0x0008053564b4 in _thread_exit (
> fname=0x805357b70 "/usr/src/lib/libthr/thread/thr_mutex.c", lineno=139,
> msg=0x805357b97 "mutex is on list") at 
> /usr/src/lib/libthr/thread/thr_exit.c:182
> #4  0x00080534cddc in mutex_assert_not_owned (m=0x80064d000)
> at /usr/src/lib/libthr/thread/thr_mutex.c:139
> #5  0x00080534cfb9 in enqueue_mutex (curthread=0x80e015000, m=0x80064d000)
> at /usr/src/lib/libthr/thread/thr_mutex.c:383
> #6  0x00080534d213 in mutex_lock_common (m=0x80064d000, 
> abstime=0x7fffd4e8,
> cvattach=0) at /usr/src/lib/libthr/thread/thr_mutex.c:533
> #7  0x00080534c6be in __pthread_mutex_timedlock (mutex=0x811c8,
> abstime=0x7fffd4e8) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> 
> (gdb) f 7
> #7  0x00080534c6be in __pthread_mutex_timedlock (mutex=0x811c8,
> abstime=0x7fffd4e8) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> 566 ret = mutex_lock_common(m, abstime, 0);
> (gdb) p *mutex
> $1 = (pthread_mutex_t) 0x8001
> (gdb) p m
> $2 = (struct pthread_mutex *) 0x80064d000
> (gdb) p *m
> $3 = {m_lock = {m_owner = -2147383372, m_flags = 1, m_ceilings = {0, 0}, 
> m_spare = {0, 0, 0,
>   0}}, m_flags = 1, m_owner = 100276, m_count = 0, m_spinloops = 0, 
> m_yieldloops = 0,
>   m_qe = {tqe_next = 0x0, tqe_prev = 0x0}, m_pqe = {tqe_next = 0x0, tqe_prev 
> = 
> 0x0}}
> (gdb) p *curthread
> No symbol "curthread" in current context.
> (gdb)

curthread is available e.q. in the frame 5.

The content from the printout is reasonable, but now it contradicts to the
assertion fired, since both checked pointers are NULL, as reported by gdb.

Please add the following debugging patch on top of the previous change
and reproduce the issue.  I need the same info, but please also provide
exact gasp message from libthr, which is enchanced in the patch below.

diff --git a/lib/libthr/thread/thr_mutex.c b/lib/libthr/thread/thr_mutex.c
index 30a8be2..3342c9f 100644
--- a/lib/libthr/thread/thr_mutex.c
+++ b/lib/libthr/thread/thr_mutex.c
@@ -124,8 +124,14 @@ mutex_assert_is_owned(struct pthread_mutex *m)
 {
 
 #if defined(_PTHREADS_INVARIANTS)
-   if (__predict_false(m->m_qe.tqe_prev == NULL))
-   PANIC("mutex is not on list");
+   if (__predict_false(m->m_qe.tqe_prev == NULL)) {
+   char msg[128];
+   snprintf(msg, sizeof(msg),
+   "mutex %p own %#x %#x is not on list %p %p",
+   m, m->m_lock.m_owner, m->m_owner, m->m_qe.tqe_prev,
+   m->m_qe.tqe_next);
+   PANIC(msg);
+   }
 #endif
 }
 
@@ -135,8 +141,14 @@ mutex_assert_not_owned(struct pthread_mutex *m)
 
 #if defined(_PTHREADS_INVARIANTS)
if (__predict_false(m->m_qe.tqe_prev != NULL ||
-   m->m_qe.tqe_next != NULL))
-   PANIC("mutex is on list");
+   m->m_qe.tqe_next != NULL)) {
+   char msg[128];
+   snprintf(msg, sizeof(msg),
+   "mutex %p own %#x %#x is on list %p %p",
+   m, m->m_lock.m_owner, m->m_owner, m->m_qe.tqe_prev,
+   m->m_qe.tqe_next);
+   PANIC(msg);
+   }
 #endif
 }
 
___
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: xo_config.h missing?

[Larry Rosenman]

On Wed, Mar 16, 2016 at 08:28:26PM -0500, Larry Rosenman wrote:
> ll_subdir_usr.bin/xo ---
> /usr/src/contrib/libxo/xo/xo.c:16:10: fatal error: 'xo_config.h' file not 
> found
> #include "xo_config.h"
> 
> 
> 
> Path: /usr/src
> Working Copy Root Path: /usr/src
> URL: https://svn.freebsd.org/base/head
> Relative URL: ^/head
> Repository Root: https://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 296976
> Node Kind: directory
> Schedule: normal
> Last Changed Author: np
> Last Changed Rev: 296975
> Last Changed Date: 2016-03-16 20:15:16 -0500 (Wed, 16 Mar 2016)
> 

more info:
(cd /usr/src/lib/libxo/tests &&  DEPENDFILE=.depend.test_05  NO_SUBDIR=1 
/usr/obj/usr/src/make.amd64/bmake -f /usr/src/lib/libxo/tests/Makefile 
_RECURSING_PROGS=t  PROG=test_05 )
echo test_05.full: /usr/obj/usr/src/tmp/usr/lib/libc.a 
/usr/obj/usr/src/tmp/usr/lib/libxo.a /usr/obj/usr/src/tmp/usr/lib/libutil.a >> 
.depend.test_05
cc  -O2 -pipe   -I/usr/src/contrib/libxo/libxo -g -MD  
-MF.depend.test_05.test_05.o -MTtest_05.o -std=gnu99 -fstack-protector-strong   
 -Qunused-arguments -c /usr/src/contrib/libxo/tests/core/test_05.c -o test_05.o
/usr/src/contrib/libxo/tests/core/test_05.c:17:10: fatal error: 'xo_config.h' 
file not found
#include "xo_config.h"
 ^
1 error generated.
*** Error code 1

Stop.
bmake[6]: stopped in /usr/src/lib/libxo/tests
*** Error code 1

Stop.
bmake[5]: stopped in /usr/src/lib/libxo/tests
*** Error code 1

Stop.
bmake[4]: stopped in /usr/src/lib/libxo
*** Error code 1

Stop.
bmake[3]: stopped in /usr/src/lib
*** Error code 1

Stop.
bmake[2]: stopped in /usr/src
*** Error code 1

Stop.
bmake[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src
^C
[1]   Done(1) nohup make -DNO_CLEAN buildworld buildkernel 
>>make.cont.out 2>&1
# 

> 
> -- 
> Larry Rosenman http://www.lerctr.org/~ler
> Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961
___
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: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Oleg V. Nauman]

On Saturday 19 March 2016 21:47:57 Konstantin Belousov wrote:
> On Sat, Mar 19, 2016 at 04:03:06PM +0200, Oleg V. Nauman wrote:
> > Core was generated by `akonadi_baloo_index'.
> > Program terminated with signal SIGABRT, Aborted.
> > #0  0x000805630d6a in thr_kill () from /lib/libc.so.7
> > (gdb) bt
> > #0  0x000805630d6a in thr_kill () from /lib/libc.so.7
> > #1  0x000805630d3b in __raise (s=6) at
> > /usr/src/lib/libc/gen/raise.c:52
> > #2  0x000805630ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> > #3  0x0008053564b4 in _thread_exit (
> > 
> > fname=0x805357b70 "/usr/src/lib/libthr/thread/thr_mutex.c",
> > lineno=139,
> > msg=0x805357b97 "mutex is on list") at
> > 
> > /usr/src/lib/libthr/thread/thr_exit.c:182
> > #4  0x00080534cddc in mutex_assert_not_owned (m=0x80064d000)
> > 
> > at /usr/src/lib/libthr/thread/thr_mutex.c:139
> > 
> > #5  0x00080534cfb9 in enqueue_mutex (curthread=0x80e015000,
> > m=0x80064d000)> 
> > at /usr/src/lib/libthr/thread/thr_mutex.c:383
> > 
> > #6  0x00080534d213 in mutex_lock_common (m=0x80064d000,
> > abstime=0x7fffd4e8,
> > 
> > cvattach=0) at /usr/src/lib/libthr/thread/thr_mutex.c:533
> > 
> > #7  0x00080534c6be in __pthread_mutex_timedlock (mutex=0x811c8,
> > 
> > abstime=0x7fffd4e8) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> > 
> > (gdb) f 7
> > #7  0x00080534c6be in __pthread_mutex_timedlock (mutex=0x811c8,
> > 
> > abstime=0x7fffd4e8) at /usr/src/lib/libthr/thread/thr_mutex.c:566
> > 
> > 566 ret = mutex_lock_common(m, abstime, 0);
> > (gdb) p *mutex
> > $1 = (pthread_mutex_t) 0x8001
> > (gdb) p m
> > $2 = (struct pthread_mutex *) 0x80064d000
> > (gdb) p *m
> > $3 = {m_lock = {m_owner = -2147383372, m_flags = 1, m_ceilings = {0, 0},
> > m_spare = {0, 0, 0,
> > 
> >   0}}, m_flags = 1, m_owner = 100276, m_count = 0, m_spinloops = 0,
> > 
> > m_yieldloops = 0,
> > 
> >   m_qe = {tqe_next = 0x0, tqe_prev = 0x0}, m_pqe = {tqe_next = 0x0,
> >   tqe_prev => 
> > 0x0}}
> > (gdb) p *curthread
> > No symbol "curthread" in current context.
> > (gdb)
> 
> curthread is available e.q. in the frame 5.

(gdb) f 5
#5  0x00080534cfb9 in enqueue_mutex (curthread=0x80e015000, m=0x80064d000)
at /usr/src/lib/libthr/thread/thr_mutex.c:383
383 mutex_assert_not_owned(m);
(gdb) p *curthread
$4 = {tid = 100276, lock = {m_owner = 0, m_flags = 0, m_ceilings = {0, 0}, 
m_spare = {0, 0,
  0, 0}}, cycle = 0, locklevel = 0, critical_count = 0, sigblock = 0, tle 
= {
tqe_next = 0x0, tqe_prev = 0x80555df40 <_thread_list>}, gcle = {tqe_next = 
0x0,
tqe_prev = 0x0}, hle = {le_next = 0x0, le_prev = 0x805568340}, wle = 
{tqe_next = 0x0,
tqe_prev = 0x0}, refcount = 0, start_routine = 0x0, arg = 0x0, attr = 
{sched_policy = 2,
sched_inherit = 4, prio = 0, suspend = 0, flags = 258, stackaddr_attr = 
0x7dfff000,
stacksize_attr = 33554432, guardsize_attr = 4096, cpuset = 0x0, cpusetsize 
= 0},
  cancel_enable = 1, cancel_pending = 0, cancel_point = 0, no_cancel = 0, 
cancel_async = 0,
  cancelling = 0, sigmask = {__bits = {0, 0, 0, 0}}, unblock_sigcancel = 0,
  in_sigsuspend = 0, deferred_siginfo = {si_signo = 0, si_errno = 0, si_code = 
0, si_pid = 0,
si_uid = 0, si_status = 0, si_addr = 0x0, si_value = {sival_int = 0, 
sival_ptr = 0x0,
  sigval_int = 0, sigval_ptr = 0x0}, _reason = {_fault = {_trapno = 0}, 
_timer = {
_timerid = 0, _overrun = 0}, _mesgq = {_mqd = 0}, _poll = {_band = 0}, 
__spare__ = {
__spare1__ = 0, __spare2__ = {0, 0, 0, 0, 0, 0, 0, 
deferred_sigmask = {__bits = {
  0, 0, 0, 0}}, deferred_sigact = {__sigaction_u = {__sa_handler = 0x0,
  __sa_sigaction = 0x0}, sa_flags = 0, sa_mask = {__bits = {0, 0, 0, 0}}},
  deferred_run = 0, force_exit = 0, state = PS_RUNNING, error = 0, joiner = 
0x0, flags = 0,
  tlflags = 2, mq = {{tqh_first = 0x0, tqh_last = 0x80e0151a0}, {tqh_first = 
0x0,
  tqh_last = 0x80e0151b0}, {tqh_first = 0x0, tqh_last = 0x80e0151c0}, 
{tqh_first = 0x0,
  tqh_last = 0x80e0151d0}}, ret = 0x0, specific = 0x80064c000, 
specific_data_count = 4,
  rdlock_count = 0, rtld_bits = 0, tcb = 0x8006fd158, cleanup = 0x0, ex = {
exception_class = 0, exception_cleanup = 0x0, private_1 = 0, private_2 = 
0},
  unwind_stackend = 0x7000, unwind_disabled = 0, magic = 3499860245,
  report_events = 0, event_mask = 0, event_buf = {event = TD_EVENT_NONE, th_p 
= 0, data = 0},
  wchan = 0x0, mutex_obj = 0x0, will_sleep = 0, nwaiter_defer = 0, 
defer_waiters = {
0x0 }, wake_addr = 0x805568048, sleepqueue = 
0x80e014040}



> 
> The content from the printout is reasonable, but now it contradicts to the
> assertion fired, since both checked pointers are NULL, as reported by gdb.
> 
> Please add the following debugging patch on top of the previous change
> and reproduce the issue.  I need the same info, but please also provide
> exact gasp message from l

FreeBSD_HEAD_amd64_gcc4.9 - Build #1128 - Fixed

[jenkins-admin]

FreeBSD_HEAD_amd64_gcc4.9 - Build #1128 - Fixed:

Build information: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1128/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1128/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/1128/console

Change summaries:

296983 by mav:
Add paragraph about isp(4) improvements.

296982 by mmel:
A20: Gpiobus can be attached only after full gpio driver initialization.
While i'm in, remove now unused global variable.

Submited by:Emmanuel Vadot 

296981 by andrew:
Make it an error to build an ARM kernel with COMPAT_FREEBSDn where n < 10.
We changed the ABI for ARM in 10, an removed support for the old ABI in 11,
as such binaries from these releases are unable to be run on a head kernel.

Reviewed by:bz, emast
Sponsored by:   ABT Systems Ltd
Differential Revision:  https://reviews.freebsd.org/D5652

296980 by loos:
Fixes a few style(9) issues, remove extra blank lines.

No functional changes.

Sponsored by:   Rubicon Comunications (Netgate)

296979 by sjg:
xo_config.h no longer in contrib, so -I's needed

PR: /homes/sjg/commit-logs/freebsd/libxo/xo_config.diff
Reviewed by:jkim

296975 by np:
cxgbe(4): Tidy up PAUSE frame accounting.

Figure out if the chip is counting PAUSE frames in the "normal" stats
and take them out if it is.  This fixes a bug in the tx stats because
the default hardware behavior is different for Tx and Rx but the driver
was treating both the same way.  The result was that OPACKETS, OBYTES,
and OMCASTS were under-reported (if tx_pause > 0) before this change.

Note that the mac_stats sysctl still gives you the raw value of these
statistics straight from the device registers.

296974 by adrian:
[net80211] Add some more missing IEs.

There are a /lot/ more missing; I'll chase these down over time.

Obtained from:  802.11-2012 standard

296973 by cem:
fail(9): Only gather/print stacks if STACK is enabled

This is a follow-up fix to the earlier r296927.

Reported by:bz
Sponsored by:   EMC / Isilon Storage Division

296970 by sjg:
We need libutil

and make it feasible to at least build the tests in situ

296968 by obrien:
Bring down 0.4.5 vendor files and other catchups with the distribution tarball.

Reviewed by:phil

296967 by phil:
Move generated file from contrib to build directory.

Reviewed by:obrien
Approved by:sjg

296966 by obrien:
Block the r296965 vendor/Juniper/libxo cleanup (to match the release tarball)
from being merged in -- backing out FreeBSD localizations.

296963 by allanjude:
Implement GELI (AES-XTS and AES-CBC only) in gptboot and gptzfsboot

Allows booting from a GELI encrypted root file system, via UFS or ZFS

Reviewed by:gnn, smh (previous version), delphij (previous version)
Relnotes:   yes
Sponsored by:   ScaleEngine Inc.
Differential Revision:  https://reviews.freebsd.org/D4593

296956 by glebius:
Due to invalid use of a signed intermediate value in the bounds checking
during argument validity verification, unbound zero'ing of the process LDT
and adjacent memory can be initiated from usermode.

Submitted by:   CORE Security
Patch by:   kib
Security:   SA-16:15

296952 by np:
cxgbe(4): Enable PFs 0-3, and allow creation of SR-IOV VFs on these PFs
in the default configuration files.

296951 by np:
cxgbe(4): Enable additional capabilities in the default configuration
files.  All features with FreeBSD drivers of some kind are now in the
default configuration.

296950 by np:
cxgbe(4): Update some register settings in the default configuration
files to match the "uwire" configuration.

296949 by np:
cxgbe(4): Remove a couple of pointless assignments in sysctl_meminfo.
Do not display range if start = stop (this is a workaround for some
unused regions).

296948 by emaste:
Remove armeb FreeBSD 6 compat shim

r296861 addressed a build failure due to undefined SYS_freebsd6_lseek
by adding a COMPAT_FREEBSD6 conditional, but we do not support FreeBSD 6
compatibility on armeb anyway so remove it completely.

Reviewed by:andrew, bz
Differential Revision:  https://reviews.freebsd.org/D5643

296947 by bdrewery:
Remove incorrect BUGS entry about asserting lock not held.

For non-WITNESS< assertion support for SA_UNLOCKED was added in r125421 and
made to panic in r126316.

MFC after:  1 week

296944 by imp:
Fix debug printf

296938 by andrew:
Remove old COMPAT_FREEBSD options from the ARM kernel configs. We replaced
the ABI in 10.0, and have removed support for the old ABI in 11. As such
any of these options to provide compatibility prior to 10 are unneeded.

Sponsored by:   ABT Systems Ltd

296937 by trasz:
Pacify Coverity in a better way, to avoid write-only variable when building
without INVARIANTS.

MFC after:  1 month
Sponsored by:   The FreeBSD Foundation

296936 by mmel:
Import basic support for Nvidia Jetson TK1 board and tegra124 SoC.
The following pheripherals are supported: UART, MMC, AHCI, EHCI, PCIe,

Panic on r297039 with nvidia-driver-340.93 and KDE5

[Florian Limberger]

Hi,

I updated today to:
> FreeBSD 11.0-CURRENT (GENERIC) #2 r297039+43ceb1f(master):
> Sat Mar 19 12:06:37 CET 2016

and as always I recompiled the nvidia-driver-340, which updated from 
340.76 to 340.93  Now I get reliable panics when starting KDE5 (from 
area51).  An older version of dwm (self-compiled) is running fine.


I omitted the later frame adresses, I typed this off a photo, I missed 
to create a crash dump, but I can provide one if it is needed:

> panic: ufs_dirbad: /usr/home: bad dir ino 6742590 at offset 512:
> mangled entry
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe01174954a0
> vpanic()
> ufs_lookup_ino()
> VOP_CACHEDLOOKUP_APV()
> vfs_cache_lookup()
> VOP_LOOKUP_APV()
> lookup()
> namei()
> kern_statat()
> sys_stat()
> amd64_syscall()
> xfast_syscall()

The hardware is a Lenovo ThinkPad T410 with a NVIDIA NVS 3100M, dmesg is 
provided below.

Is anyone else seeing this and how could I fix this?

Regards,


florian


> Copyright (c) 1992-2016 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 11.0-CURRENT #2 r297039+43ceb1f(master): Sat Mar 19 12:06:37 
CET 2016
> r...@nachtschatten.purplekraken.com:/usr/obj/usr/src/sys/GENERIC 
amd64
> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on 
LLVM 3.8.0)

> WARNING: WITNESS option enabled, expect reduced performance.
> VT(vga): resolution 640x480
> can't re-use a leaf (hwpstate_verbose)!
> module_register: cannot register cpu/ichss from kernel; already 
loaded from cpufreq.ko

> Module cpu/ichss failed to register: 17
> module_register: cannot register cpu/powernow from kernel; already 
loaded from cpufreq.ko

> Module cpu/powernow failed to register: 17
> module_register: cannot register cpu/est from kernel; already loaded 
from cpufreq.ko

> Module cpu/est failed to register: 17
> module_register: cannot register cpu/hwpstate from kernel; already 
loaded from cpufreq.ko

> Module cpu/hwpstate failed to register: 17
> module_register: cannot register cpu/p4tcc from kernel; already 
loaded from cpufreq.ko

> Module cpu/p4tcc failed to register: 17
> CPU: Intel(R) Core(TM) i5 CPU   M 560  @ 2.67GHz (2660.07-MHz 
K8-class CPU)

>   Origin="GenuineIntel"  Id=0x20655  Family=0x6  Model=0x25  Stepping=5
> 
Features=0xbfebfbff
> 
Features2=0x29ae3ff

>   AMD Features=0x28100800
>   AMD Features2=0x1
>   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> real memory  = 4294967296 (4096 MB)
> avail memory = 3929866240 (3747 MB)
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads
>  cpu0 (BSP): APIC ID:  0
>  cpu1 (AP): APIC ID:  1
>  cpu2 (AP): APIC ID:  4
>  cpu3 (AP): APIC ID:  5
> random: unblocking device.
> ACPI BIOS Warning (bug): 32/64X length mismatch in 
FADT/Pm1aControlBlock: 16/32 (20150818/tbfadt-649)
> ACPI BIOS Warning (bug): Invalid length for FADT/Pm1aControlBlock: 
32, using default 16 (20150818/tbfadt-730)

> ioapic0: Changing APIC ID to 1
> ioapic0  irqs 0-23 on motherboard
> random: entropy device external interface
> kbd1 at kbdmux0
> netmap: loaded module
> module_register_init: MOD_LOAD (vesa, 0x80f00bf0, 0) error 19
> vtvga0:  on motherboard
> cryptosoft0:  on motherboard
> acpi0:  on motherboard
> acpi_ec0:  port 0x62,0x66 on acpi0
> acpi0: Power Button (fixed)
> cpu0:  on acpi0
> cpu1:  on acpi0
> cpu2:  on acpi0
> cpu3:  on acpi0
> attimer0:  port 0x40-0x43 irq 0 on acpi0
> Timecounter "i8254" frequency 1193182 Hz quality 0
> Event timer "i8254" frequency 1193182 Hz quality 100
> hpet0:  iomem 0xfed0-0xfed003ff on acpi0
> Timecounter "HPET" frequency 14318180 Hz quality 950
> Event timer "HPET" frequency 14318180 Hz quality 550
> Event timer "HPET1" frequency 14318180 Hz quality 440
> Event timer "HPET2" frequency 14318180 Hz quality 440
> Event timer "HPET3" frequency 14318180 Hz quality 440
> Event timer "HPET4" frequency 14318180 Hz quality 440
> atrtc0:  port 0x70-0x71 irq 8 on acpi0
> Event timer "RTC" frequency 32768 Hz quality 0
> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
> acpi_lid0:  on acpi0
> acpi_button0:  on acpi0
> pcib0:  on acpi0
> pci0:  on pcib0
> pcib1:  port 0xcf8-0xcff on acpi0
> pci1:  on pcib1
> pcib2:  irq 16 at device 1.0 on pci1
> pci2:  on pcib2
> vgapci0:  port 0x2000-0x207f mem 
0xcc00-0xccff,0xd000-0xdfff,0xce00-0xcfff irq 16 
at device 0.0 on pci2

> nvidia0:  on vgapci0
> vgapci0: child nvidia0 requested pci_enable_io
> vgapci0: child nvidia0 requested pci_enable_io
> vgapci0: Boot video device
> hdac0:  mem 0xcdefc000-0xcdef at 
device 0.1 on pci2

> pci1:  at device 22.0 (no d

Re: boot loaders got fatter in the last few days

[Freddie Cash]

On Fri, Mar 18, 2016 at 10:39 AM, Conrad Meyer  wrote:

> On Fri, Mar 18, 2016 at 10:03 AM, Allan Jude 
> wrote:
> > On 2016-03-18 12:33, Guido Falsi wrote:
> >>
> >> Hi,
> >>
> >> I have just update one of my machines and noticed the booloaders files
> >> got quite fat in the last few days, some by a big margin.
> >>
> >> on an updated machine(r296993):
> >>
> >> -r--r--r--  1 root  wheel   85794 Mar 18 16:47 /boot/gptboot
> >>
> >> from a machine I still have not updated(r296719):
> >>
> >> -r--r--r--  1 root  wheel   16059 Mar 13 21:01 /boot/gptboot
>
> So the loader grew 70 kB.  How big are your disks?
>
> >> I noticed because mu gpt boot partition is 64K and gptzfsboot just
> >> passed 100K.
> >
> > This is a side effect of the loader gaining the ability to boot from GELI
> > encrypted partitions.
> >
> > ...
> >
> > Maybe we should be putting the GELI enabled boot blocks in a different
> > filename? I generally wanted to avoid creating a new version of each
> > bootcode with GELI support.
>
>
> I think we should just suggest that boot partitions be much larger
> than 64kB (1MB is still <0.1% of any disk sold today) and not worry
> about it too much.  Embedded applications can disable GELI loader
> support to save a few bytes.
>

​The boot partition doesn't necessarily need ​

​to be 1 MB (and can't due to some issues with the assembler used right
now, or something like that).  We just need to make sure people have slack
space in their partition table to expand into in the future.

Using "-a 1M" in your gpart command to create your first data partition
gives you that slack space.

gpart create -s gpt ada0
gpart add -t freebsd-boot -s 256K -l boot ada0
gpart add -t freebsd-ufs  -s 10G  -l root -a 1M ada0

That leaves ~756 KB of free space between the end of the boot partition and
the start of the first data partition.  Increasing the size of the boot
partition in the future is as easy as (no formatting of disks required):

gpart delete -i 1 ada0
gpart add -t freebsd-boot -s 512K -l boot ada0
gpart bootcode -b ... -p ... ada0

It's a handy pattern I've gotten used to over the years, ever since the
first 4K sector harddrives were advertised (as alignment of filesystems
was/is *very* important)​.

Even on disks that will be used solely for ZFS I've taken to creating GPT
partitions starting at 1 MB.  And it's saved me from having to reformat
disks when moving from a separate root filesystem (no USB sticks) to
root-on-ZFS as there was 1 MB of free space at the start of every disk for
creating boot partitions.  :)

-- 
Freddie Cash
fjwc...@gmail.com
___
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: USB disks attach after rootfs prompt

[Edward Tomasz Napierała]

On 0319T1509, Poul-Henning Kamp wrote:
> 
> In message <1458397972.68920.69.ca...@freebsd.org>, Ian Lepore writes:
> >On Sat, 2016-03-19 at 13:04 +, Poul-Henning Kamp wrote:
> >> Running:
> >> 
> >>FreeBSD 11.0-CURRENT #32 r296137: Sat Feb 27 11:34:01 UTC 2016
> >> 
> >> I tried "boot -a" and found that USB disks only attach *after* you
> >> enter some root filesystem.
> >> 
> >> That's not terribly useful.
> >
> >iirc, interrupts are disabled while you're at the mountroot prompt,
> >which freezes usb enumeration.
> 
> I am somewhat certain that this used to work...

That might be my fault.  I've modified the root mount mechanism to only
wait for the root mount tokens (ie USB) if the root device isn't already
there; basically this makes the kernel not wait for USB if rootfs is
on SATA.

Does the following fix things for you?  (Note there's something
seriously wrong with character echo, but it doesn't seem related.)

Index: svn/head/sys/kern/vfs_mountroot.c
===
--- svn/head/sys/kern/vfs_mountroot.c   (revision 297053)
+++ svn/head/sys/kern/vfs_mountroot.c   (working copy)
@@ -89,6 +89,7 @@ __FBSDID("$FreeBSD$");
 static int parse_mount(char **);
 static struct mntarg *parse_mountroot_options(struct mntarg *, const char *);
 static int sysctl_vfs_root_mount_hold(SYSCTL_HANDLER_ARGS);
+static void vfs_mountroot_wait(void);
 static int vfs_mountroot_wait_if_neccessary(const char *fs, const char *dev);
 
 /*
@@ -488,6 +489,8 @@ parse_dir_ask(char **conf)
char *mnt;
int error;
 
+   vfs_mountroot_wait();
+
printf("\nLoader variables:\n");
parse_dir_ask_printenv("vfs.root.mountfrom");
parse_dir_ask_printenv("vfs.root.mountfrom.options");

___
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: boot loaders got fatter in the last few days

[José Pérez]

Hi Guido,
maybe it's because of this:
https://svnweb.freebsd.org/base?view=revision&revision=296963

Regards,

---
José Pérez

El 2016-03-18 17:33, Guido Falsi escribió:

Hi,

I have just update one of my machines and noticed the booloaders files
got quite fat in the last few days, some by a big margin.

on an updated machine(r296993):


ls -l /boot/*boot*

-r--r--r--  1 root  wheel8192 Mar 18 16:47 /boot/boot
-r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot0
-r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot0sio
-r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot1
-r-xr-xr-x  1 root  wheel   72152 Mar 18 16:47 /boot/boot1.efi
-r--r--r--  1 root  wheel  819200 Mar 18 16:47 /boot/boot1.efifat
-r--r--r--  1 root  wheel7680 Mar 18 16:47 /boot/boot2
-r--r--r--  1 root  wheel1185 Mar 18 16:47 /boot/cdboot
-r--r--r--  1 root  wheel   85794 Mar 18 16:47 /boot/gptboot
-r--r--r--  1 root  wheel  110546 Mar 18 16:47 /boot/gptzfsboot
-r--r--r--  1 root  wheel  358400 Mar 18 16:47 /boot/pxeboot
-r--r--r--  1 root  wheel  341248 Mar 18 16:47 /boot/userboot.so
-r--r--r--  1 root  wheel   66048 Mar 18 16:47 /boot/zfsboot

from a machine I still have not updated(r296719):


ls -l /boot/*boot*

-r--r--r--  1 root  wheel8192 Mar 13 21:01 /boot/boot
-r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot0
-r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot0sio
-r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot1
-r-xr-xr-x  1 root  wheel   72152 Mar 13 21:01 /boot/boot1.efi
-r--r--r--  1 root  wheel  819200 Mar 13 21:01 /boot/boot1.efifat
-r--r--r--  1 root  wheel7680 Mar 13 21:01 /boot/boot2
-r--r--r--  1 root  wheel1185 Mar 13 21:01 /boot/cdboot
-r--r--r--  1 root  wheel   16059 Mar 13 21:01 /boot/gptboot
-r--r--r--  1 root  wheel   41511 Mar 13 21:01 /boot/gptzfsboot
-r--r--r--  1 root  wheel  288768 Mar 13 21:01 /boot/pxeboot
-r--r--r--  1 root  wheel  341208 Mar 13 21:01 /boot/userboot.so
-r--r--r--  1 root  wheel   66048 Mar 13 21:01 /boot/zfsboot

I noticed because mu gpt boot partition is 64K and gptzfsboot just
passed 100K.

Is this expected and I'm supposed to repartition or is this an unwanted
mistake?

Thanks in advance.

___
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: boot loaders got fatter in the last few days

[Guido Falsi]

On 03/18/16 17:54, José Pérez wrote:
> Hi Guido,
> maybe it's because of this:
> https://svnweb.freebsd.org/base?view=revision&revision=296963
> 

I see.

There is a problem with this though, we have howtos suggesting 64K for
the size of the freebsd-boot gpt partition:

https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1

now that size isn't sufficient anymore. We should at least update these
information soon.

Also repartitioning could be problematic in certain scenarios. I think
this change should be at least published in UPDATING and maybe also in
the future release notes for 11.0.

Personally I'll find a way of reorganizing my disks to fit this change,
but it's something that could byte users.

-- 
Guido Falsi 
___
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: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Konstantin Belousov]

On Thu, Mar 17, 2016 at 09:40:11PM +0200, Oleg V. Nauman wrote:
> 
>  I'm experiencing issue with threaded applications ( including many KDE 
> applications ) after recent CURRENT update. Attempt to start application 
> cause 
> Abort trap (6) with "Fatal error 'mutex is on list' at line 139 in file 
> /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)" output on console. 
> 
> FreeBSD 11.0-CURRENT amd64 r296887
> 
> Backtrace from application looks like
> 
> Application: KGpg (kgpg), signal: Abort trap
> [Switching to Thread 810815000 (LWP 100865/kgpg)]
> [KCrash Handler]
> #8  0x000807176d6a in thr_kill () from /lib/libc.so.7
> #9  0x000807176d3b in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
> #10 0x000807176ca9 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
> #11 0x000806e9e62c in _thread_exit (fname=, 
> lineno=, msg=) at 
> /usr/src/lib/libthr/thread/thr_exit.c:182
> #12 0x000806e996fc in mutex_lock_common (m=, 
> abstime=, cvattach=) at 
> /usr/src/lib/libthr/thread/thr_mutex.c:139
> #13 0x000806e98c20 in __pthread_mutex_timedlock (mutex=0x81468, 
> abstime=0x7fff5a58) at /usr/src/lib/libthr/thread/thr_mutex.c:566

>From the frame 13, please do
p *mutex
p *m
p **mutex

What non-KDE apps exhibit the behaviour ?
___
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: boot loaders got fatter in the last few days

[Warren Block]

On Fri, 18 Mar 2016, Guido Falsi wrote:


On 03/18/16 17:54, José Pérez wrote:

Hi Guido,
maybe it's because of this:
https://svnweb.freebsd.org/base?view=revision&revision=296963



I see.

There is a problem with this though, we have howtos suggesting 64K for
the size of the freebsd-boot gpt partition:

https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1

now that size isn't sufficient anymore. We should at least update these
information soon.


I have always recommended using the largest possible size for the 
bootcode partition, 512K.  There is no reason to go with a smaller size, 
the space savings are insignificant.  It is safe to guess that bootcode 
will never get smaller.


I also recommend starting the first real partition at 1M.  This also is 
frequently ignored.


Here are my instructions:

http://www.wonkity.com/~wblock/docs/html/disksetup.html

The wiki should be updated.  Better yet, that section should be removed 
and the corrected procedure shown in the Handbook.



Also repartitioning could be problematic in certain scenarios. I think
this change should be at least published in UPDATING and maybe also in
the future release notes for 11.0.

Personally I'll find a way of reorganizing my disks to fit this change,
but it's something that could byte users.

___
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: boot loaders got fatter in the last few days

[Nikolai Lifanov]

On 03/18/16 13:03, Allan Jude wrote:
> On 2016-03-18 12:33, Guido Falsi wrote:
>> Hi,
>>
>> I have just update one of my machines and noticed the booloaders files
>> got quite fat in the last few days, some by a big margin.
>>
>> on an updated machine(r296993):
>>
>>> ls -l /boot/*boot*
>> -r--r--r--  1 root  wheel8192 Mar 18 16:47 /boot/boot
>> -r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot0
>> -r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot0sio
>> -r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot1
>> -r-xr-xr-x  1 root  wheel   72152 Mar 18 16:47 /boot/boot1.efi
>> -r--r--r--  1 root  wheel  819200 Mar 18 16:47 /boot/boot1.efifat
>> -r--r--r--  1 root  wheel7680 Mar 18 16:47 /boot/boot2
>> -r--r--r--  1 root  wheel1185 Mar 18 16:47 /boot/cdboot
>> -r--r--r--  1 root  wheel   85794 Mar 18 16:47 /boot/gptboot
>> -r--r--r--  1 root  wheel  110546 Mar 18 16:47 /boot/gptzfsboot
>> -r--r--r--  1 root  wheel  358400 Mar 18 16:47 /boot/pxeboot
>> -r--r--r--  1 root  wheel  341248 Mar 18 16:47 /boot/userboot.so
>> -r--r--r--  1 root  wheel   66048 Mar 18 16:47 /boot/zfsboot
>>
>> from a machine I still have not updated(r296719):
>>
>>> ls -l /boot/*boot*
>> -r--r--r--  1 root  wheel8192 Mar 13 21:01 /boot/boot
>> -r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot0
>> -r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot0sio
>> -r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot1
>> -r-xr-xr-x  1 root  wheel   72152 Mar 13 21:01 /boot/boot1.efi
>> -r--r--r--  1 root  wheel  819200 Mar 13 21:01 /boot/boot1.efifat
>> -r--r--r--  1 root  wheel7680 Mar 13 21:01 /boot/boot2
>> -r--r--r--  1 root  wheel1185 Mar 13 21:01 /boot/cdboot
>> -r--r--r--  1 root  wheel   16059 Mar 13 21:01 /boot/gptboot
>> -r--r--r--  1 root  wheel   41511 Mar 13 21:01 /boot/gptzfsboot
>> -r--r--r--  1 root  wheel  288768 Mar 13 21:01 /boot/pxeboot
>> -r--r--r--  1 root  wheel  341208 Mar 13 21:01 /boot/userboot.so
>> -r--r--r--  1 root  wheel   66048 Mar 13 21:01 /boot/zfsboot
>>
>> I noticed because mu gpt boot partition is 64K and gptzfsboot just
>> passed 100K.
>>
>> Is this expected and I'm supposed to repartition or is this an unwanted
>> mistake?
>>
>> Thanks in advance.
>>
> 
> This is a side effect of the loader gaining the ability to boot from
> GELI encrypted partitions.
> 
> You can compile with LOADER_NO_GELI_SUPPORT to disable this to get back
> to a smaller one if you need.
> 
> Maybe we should be putting the GELI enabled boot blocks in a different
> filename? I generally wanted to avoid creating a new version of each
> bootcode with GELI support.
> 
> My goal somewhere down the road is to create a single bootcode that can
> do UFS and ZFS, then maybe we can have gptboot and gptgeliboot or
> something.
> 
> 

Maybe a single gptbootlite for minimum viable case of UFS+nothing fancy?
At some point in the near future users that want additional features
will re-partition and bsdinstall will create larger partitions for boot
and this won't be a problem.

P.S.: Allan, do you plan to enable GELI support for boot1.efi?

- Nikolai Lifanov

___
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: Fatal error 'mutex is on list' at line 139 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno = 35)

[Konstantin Belousov]

On Fri, Mar 18, 2016 at 08:14:57AM +0200, Konstantin Belousov wrote:
> Yes, please.  It would be significantly easier to diagnose the problem if
> the minimal example is provided.  If not, please pack one crashing app
> and all it non-system libraries and provide the tarball to me.

Meantime you could also try the following change.  I doubt that it would
fix your issue, but it is possibly related.  Only libthr needs to be
rebuilt.

diff --git a/lib/libthr/thread/thr_fork.c b/lib/libthr/thread/thr_fork.c
index 7256b68..531e09c 100644
--- a/lib/libthr/thread/thr_fork.c
+++ b/lib/libthr/thread/thr_fork.c
@@ -168,6 +168,7 @@ __thr_fork(void)
if (_thr_isthreaded() != 0) {
was_threaded = 1;
_malloc_prefork();
+   __thr_pshared_atfork_pre();
_rtld_atfork_pre(rtld_locks);
} else {
was_threaded = 0;
@@ -202,8 +203,10 @@ __thr_fork(void)
 
_thr_signal_postfork_child();
 
-   if (was_threaded)
+   if (was_threaded) {
_rtld_atfork_post(rtld_locks);
+   __thr_pshared_atfork_post();
+   }
_thr_setthreaded(0);
 
/* reinitalize library. */
@@ -236,6 +239,7 @@ __thr_fork(void)
 
if (was_threaded) {
_rtld_atfork_post(rtld_locks);
+   __thr_pshared_atfork_post();
_malloc_postfork();
}
 
diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c
index 3c81299..5e7f01c 100644
--- a/lib/libthr/thread/thr_init.c
+++ b/lib/libthr/thread/thr_init.c
@@ -466,7 +466,6 @@ init_private(void)
_thr_once_init();
_thr_spinlock_init();
_thr_list_init();
-   __thr_pshared_init();
_thr_wake_addr_init();
_sleepq_init();
_single_thread = NULL;
@@ -477,6 +476,7 @@ init_private(void)
 * e.g. after a fork().
 */
if (init_once == 0) {
+   __thr_pshared_init();
/* Find the stack top */
mib[0] = CTL_KERN;
mib[1] = KERN_USRSTACK;
diff --git a/lib/libthr/thread/thr_private.h b/lib/libthr/thread/thr_private.h
index 31f8e6c..7ee1fbf 100644
--- a/lib/libthr/thread/thr_private.h
+++ b/lib/libthr/thread/thr_private.h
@@ -952,6 +952,8 @@ void_tcb_dtor(struct tcb *);
 void __thr_pshared_init(void) __hidden;
 void *__thr_pshared_offpage(void *key, int doalloc) __hidden;
 void __thr_pshared_destroy(void *key) __hidden;
+void __thr_pshared_atfork_pre(void) __hidden;
+void __thr_pshared_atfork_post(void) __hidden;
 
 __END_DECLS
 
diff --git a/lib/libthr/thread/thr_pshared.c b/lib/libthr/thread/thr_pshared.c
index e8ccf1c..8371478 100644
--- a/lib/libthr/thread/thr_pshared.c
+++ b/lib/libthr/thread/thr_pshared.c
@@ -252,3 +252,17 @@ __thr_pshared_destroy(void *key)
pshared_clean(key, val);
pshared_gc(curthread);
 }
+
+void
+__thr_pshared_atfork_pre(void)
+{
+
+   _thr_rwl_rdlock(&pshared_lock);
+}
+
+void
+__thr_pshared_atfork_post(void)
+{
+
+   _thr_rwl_unlock(&pshared_lock);
+}
___
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"