ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV

[David Wolfskill]

Yesterday's in-place src update (r318606 -> r318739) was a bit more
"interesting" than usual; as has been noted elsewhere, it really is
necessary to boot the new kernel before the "make installworld"
completes successfully.  That said, it ("make installworld") did
complete successfully, and a followup reboot/smoke test worked without
incident.

For today's update, sources are now at r318781; both laptop and build
machine fail identically during ">>> stage 4.2: building libraries":

...
Building /common/S4/obj/usr/src/lib/libc/strsignal.pico
Building /common/S4/obj/usr/src/lib/libc/libc.a
--- libc.a ---
building static c library
Building /common/S4/obj/usr/src/lib/libc/libc.so.7
Building /common/S4/obj/usr/src/lib/libc/libc_pic.a
--- libc.so.7 ---
building shared library libc.so.7
--- libc_pic.a ---
building special pic c library
--- libc.so.7 ---
cc: error: unable to execute command: Segmentation fault (core dumped)
cc: error: linker command failed due to signal (use -v to see invocation)
*** [libc.so.7] Error code 254

bmake[4]: stopped in /usr/src/lib/libc
.ERROR_TARGET='libc.so.7'
.ERROR_META_FILE='/common/S4/obj/usr/src/lib/libc/libc.so.7.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
.CURDIR='/usr/src/lib/libc'
.MAKE='/usr/obj/usr/src/make.amd64/bmake'
.OBJDIR='/usr/obj/usr/src/lib/libc'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/tmp'
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20160604'
PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
/usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf 
/usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf 
/usr/src/lib/libc/Makefile /usr/src/share/mk/src.opts.mk 
/usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.compiler.mk 
/usr/src/share/mk/bsd.compiler.mk /usr/src/lib/libc/amd64/Makefile.inc 
/usr/src/lib/libc/db/Makefile.inc /usr/src/lib/libc/db/btree/Makefile.inc 
/usr/src/lib/libc/db/db/Makefile.inc /usr/src/lib/libc/db/hash/Makefile.inc 
/usr/src/lib/libc/db/man/Makefile.inc /usr/src/lib/libc/db/mpool/Makefile.inc 
/usr/src/lib/libc/db/recno/Makefile.inc 
/usr/src/lib/libc/compat-43/Makefile.inc /usr/src/lib/libc/gdtoa/Makefile.inc 
/usr/src/lib/libc/gen/Makefile.inc /usr/src/lib/libc/amd64/gen/Makefile.inc 
/usr/src/lib/libc/gmon/Makefile.inc /usr/src/lib/libc/iconv/Makefile.inc 
/usr/src/lib/libc_nonshared/Makefile.iconv /usr/src/lib/libc/inet/Makefile.inc 
/usr/src/lib/libc/isc/Makefile.inc /usr/src/lib/libc/locale/Makefile.inc 
/usr/src/lib/libc/md/Makefile.inc /usr/src/lib/libc/nameser/Makefile.inc 
/usr/src/lib/libc/net/Makefile.inc /usr/src/lib/libc/nls/Makefile.inc 
/usr/src/lib/libc/posix1e/Makefile.inc /usr/src/lib/libc/regex/Makefile.inc 
/usr/src/lib/libc/resolv/Makefile.inc /usr/src/lib/libc/stdio/Makefile.inc 
/usr/src/lib/libc/stdlib/Makefile.inc 
/usr/src/lib/libc/amd64/stdlib/Makefile.inc 
/usr/src/lib/libc/stdlib/jemalloc/Makefile.inc 
/usr/src/lib/libc/stdtime/Makefile.inc /usr/src/lib/libc/string/Makefile.inc 
/usr/src/lib/libc/amd64/string/Makefile.inc /usr/src/lib/libc/sys/Makefile.inc 
/usr/src/sys/sys/syscall.mk /usr/src/lib/libc/amd64/sys/Makefile.inc 
/usr/src/lib/libc/secure/Makefile.inc /usr/src/lib/libc/rpc/Makefile.inc 
/usr/src/lib/libc/uuid/Makefile.inc /usr/src/lib/libc/xdr/Makefile.inc 
/usr/src/lib/libc/x86/sys/Makefile.inc /usr/src/lib/libc/yp/Makefile.inc 
/usr/src/lib/libc/capability/Makefile.inc /usr/src/share/mk/bsd.lib.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk 
/usr/src/share/mk/src.init.mk /usr/src/lib/libc/../Makefile.inc 
/usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk 
/usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk 
/usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk 
/usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk 
/usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk 
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk 
/usr/src/share/mk/bsd.sys.mk'
.PATH='. /usr/src/lib/libc /usr/src/lib/libc/db/btree /usr/src/lib/libc/db/db 
/usr/src/lib/libc/db/hash /usr/src/lib/libc/db/man /usr/src/lib/libc/db/mpool 
/usr/src/lib/libc/db/recno /usr/src/lib/libc/compat-43 /usr/src/lib/libc/gdtoa 
/usr/src/lib/libc/amd64/gen /usr/src/lib/libc/gen /usr/src/contrib/libc-pwcache 
/usr/src/contrib/libc-vis /usr/src/lib/libc/gmon /usr/src/lib/libc/iconv 
/usr/src/lib/libc/inet /usr/src/lib/libc/isc /usr/src/lib/libc/locale 
/usr/src/lib/libmd /usr/src/lib/libc/n

Re: filemon: weird full-time build although filemon enabled

[David Wolfskill]

On Mon, May 08, 2017 at 07:32:58PM +0200, O. Hartmann wrote:
> Am Mon, 8 May 2017 10:17:05 -0700
> "Simon J. Gerraty"  schrieb:
> ... 
> > bmake has a set of knobs for telling it to ignore things.
> > OP try
> > 
> > .MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d
> > 
> > --sjg
> 
> I suppose I have to set this flag in 
> 
> /etc/src-env.conf
> 
> ?
> 

I placed it in /etc/src.conf; thus:

g1-252(11.0-S)[1] cat /etc/src.conf 
KERNCONF=CANARY
PORTS_MODULES=x11/nvidia-driver-340
.MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d
WITHOUT_DEBUG_FILES=1
IWN_DEBUG=1
IEEE80211_DEBUG=1
WITH_ELFCOPY_AS_OBJCOPY=1
g1-252(11.0-S)[2] 

My morning updates (stable/11 & head, as well as installed ports (while
running stavble/11), which had been getting to around 2 hours, were
finished in 30 minutes this morning.  Thank you! :-)

For reference, this morning's updates were:

stable/11:
  from:
FreeBSD g1-252.catwhisker.org 11.0-STABLE FreeBSD 11.0-STABLE #336  
r318019M/318019:1100512: Tue May  9 04:46:49 PDT 2017 
r...@g1-252.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64

  to:
FreeBSD g1-252.catwhisker.org 11.0-STABLE FreeBSD 11.0-STABLE #337  
r318134M/318137:1100512: Wed May 10 04:09:32 PDT 2017 
r...@g1-252.catwhisker.org:/common/S1/obj/usr/src/sys/CANARY  amd64


Ports updated:
===>>> The following actions were performed:
Upgrade of librsvg2-2.40.16 to librsvg2-2.40.17
Upgrade of p5-Specio-0.36 to p5-Specio-0.37
Upgrade of spidermonkey170-17.0.0_5 to spidermonkey170-17.0.0_6
Upgrade of R-cran-bit64-0.9.5 to R-cran-bit64-0.9.7

head:
  from:
FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #340  
r318017M/318019:1200030: Tue May  9 05:46:27 PDT 2017 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

  to:
FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #341  
r318137M/318137:1200030: Wed May 10 04:23:30 PDT 2017 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Does "conflict of interest" mean anything in the Trump administration?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: make buildworld broken at r317821 (libsysdecode)

[David Wolfskill]

On Fri, May 05, 2017 at 07:05:14PM +0800, Alastair Hogge wrote:
> On Fri, 5 May 2017 12:31:41 PM Vladimir Zakharov wrote:
> > Hello!
> > 
> > Cannot build world due to error in compiling lib/libsysdecode. Cleaning
> > (make clean, make cleandepend and wiping out ccache data) does not help.
> > 
> > $ make -j 4 buildworld && make -j 4 buildkernel && make installkernel
> > ...
> 
> [removed build log & host configs]
> 
> I am having observing the same problem too.  I updated to r317713 & rebooted  
> the r317713 host, then I tried to build a release & it failed with the same 
> errors.
> 

I had no issues updating from r317789 to r317824 on my build machine
(amd64).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Does "conflict of interest" mean anything in the Trump administration?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: r316958: booting a server takes >10 minutes!

[David Wolfskill]

On Sat, Apr 15, 2017 at 02:24:05PM -0500, Larry Rosenman wrote:
> Current SVN seems to have fixed it (via sobomax@ syslogd commit). 
> 

Confirmed: I had experienced the issue running:

FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #315  
r316956M/316956:1200028: Sat Apr 15 08:13:46 PDT 2017 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

on my laptop, then cherry-picked r316973 and re-buit; no issue with
processes spinning in CPU.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Who would have thought that a "hotelier" would be so ... unwelcoming?  Sad.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: r316958: booting a server takes >10 minutes!

[David Wolfskill]

On Sat, Apr 15, 2017 at 04:41:28PM +, Poul-Henning Kamp wrote:
> 
> ...
> >And I understand that the Cloudflare/f-root server issue isn't quite
> >that recent: "The new f-root servers appeared around two weeks ago"
> 
> And isn't the zone cache expiry time around two weeks as well ?
> 

Regardless, I observe that my laptop was (somewhat) affected by this,
but my build machine did not appear to be affected.

The build machine has very few ports install, runs a GENERIC kernel,
and normally runs headless, while the laptop normally runs xdm and
has my (somewhat old-fashioned) set of ports for a user-facing
machine.  But among the ports on which X11 depends is dbus, and
dbus-daemon was one of the processes that was apparently spinning
in CPU without evidence of accomplishing much of anything, so the
X11 environment wasn't usable.  (I was able to login to and use a
vty on the laptop, though.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Who would have thought that a "hotelier" would be so ... unwelcoming?  Sad.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: r316958: booting a server takes >10 minutes!

[David Wolfskill]

On Sat, Apr 15, 2017 at 04:00:25PM +, Poul-Henning Kamp wrote:
> 
> 
> >Recent CURRENT running on a server makes the system booting in multiuser 
> >mode booting
> >incredibly slow! On a machine, before I interrupted the booting process 
> >hanging in
> >starting postgresql 9.6.2 server, it took > 10 minutes.
> 
> Maybe this ticket ?
> 
>   https://lists.freebsd.org/pipermail/freebsd-ports/2017-April/108144.html
> ...

I doubt it:  While I encountered the observed symptom, that was not
until today's build of head (r316956, in my case); yesterday's (r316823)
was fine.

And I understand that the Cloudflare/f-root server issue isn't quite
that recent: "The new f-root servers appeared around two weeks ago"

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Who would have thought that a "hotelier" would be so ... unwelcoming?  Sad.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: shutdown -r doesn't execute rc.d sequence

[David Wolfskill]

On Tue, Mar 28, 2017 at 10:38:53PM +0300, Andrey Chernov wrote:
> ...
> >> With latest -current amd64, reboot happens almost immediately, leaving
> >> FS dirty. No proper backward rc.d or /usr/local/etc/rc.d sequence
> >> execution is shown. No deactivating GELI swap too.
> > 
> > Hi Andrey,
> > Do you have a typescript demonstrating this? Adding rc_debug=yes to 
> > /etc/rc.conf would be super helpful, along with `boot -v`, to see whether 
> > the issue is in userspace or rc(5).
> > I’ll double check my amd64/i386 VMs too (if possible, redirect the 
> > output over serial to a typescript for analysis).
> > Are you using vanilla FreeBSD, a fork, or a packaged variant (mfsbsd, 
> > nanobsd, etc)?
> > Thanks!
> > -Ngie
> 
> I don't have serial, so typescript may not work treating as dirty, but
> I'll try. As I say, it is today's -current, vanilla. It looks like
> regression because few weeks ago all things works.
> 

FWIW, I did not see an issue either for my build machine of my laptop at
r316082:

FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #298  
r316082M/316093:1200027: Tue Mar 28 06:37:15 PDT 2017 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Who would have thought that a "hotelier" would be so ... unwelcoming?  Sad.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: dchlient does not autostart anymore?

[David Wolfskill]

On Fri, Mar 24, 2017 at 01:56:38AM -0700, Mark Millard wrote:
> Vladimir Zakharov zakharov.vv at gmail.com  wrote on Fri Mar 24 08:20:34 UTC 
> 2017:
> 
> > After upgrading from r315544 to r315880 network interface doesn't get IP
> > address using DHCP on boot anymore.
> > 
> > $ grep re0 /etc/rc.conf | grep -v "^#"
> > ifconfig_re0="DHCP"
> > 
> > "service netif restart" doesn't help either. Only manual dhclient
> > starting.
> 
> I have just updated two contexts to -r315870 just a bit ago
> and they both got that behavior as well:
> 
> A) An amd64 context (FreeBSD client in VirtualBox under macOS)
> B) An arm64 context (pine64+ 2GB with -mcpu=cortex-a53 )
> 
> Later I'll be updating powerpc64, powerpc, and armv6 (with
> -mcpu=cortex-a7 ) contexts but I'd expect they will all match
> the behavior.
> 
> (I started from earlier than -r315544 so your report provides
> a better lower bound -r315544. I ended earlier and so my
> report provides a better upper bound -r315870.)
> 

Well, I just updated my (amd64) laptop from:

FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #293  
r315853M/315854:1200027: Thu Mar 23 06:41:30 PDT 2017 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

to:

FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #294  
r315896M/315899:1200027: Fri Mar 24 06:36:28 PDT 2017 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

... and had no issues (with dhclient, mouse, or anything else).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Who would have thought that a "hotelier" would be so ... unwelcoming?  Sad.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Apparent build race(s), r315238 -> r315298

[David Wolfskill]

On Wed, Mar 15, 2017 at 03:40:42PM -0700, Ngie Cooper (yaneurabeya) wrote:
> ... 
> > This should fix it: https://svnweb.freebsd.org/changeset/base/315332 
> > 
> 
> Yeah, that would do it >_>…
> Thanks,
> -Ngie

After hand-applying r315332 to a head@r315298 set of sources, a "normal"
(well, in my environment) build completed without incident.

Thanks! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Claims that lack evidence are not a basis for rational decision-making.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Apparent build race(s), r315238 -> r315298

[David Wolfskill]

On Wed, Mar 15, 2017 at 11:09:05AM -0700, Bryan Drewery wrote:
> ...
> So where is /common/S4/obj coming from?
> 
> Is there a symlink involved here for /usr/obj?
> 

Yes; I've had /usr/obj as a symlink (to a different file system) for ...
a couple of decades, now

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Claims that lack evidence are not a basis for rational decision-making.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Apparent build race(s), r315238 -> r315298

[David Wolfskill]

Both the biuld machine ("freebeast") and my laptop encountered errors
during the "make -jN buildworld" -- each completed on restart, and the
(initially-detected) errors were different:

Build machine:
...
===> usr.bin/mkimg/tests (all)
--- all_subdir_gnu ---
Building /common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui
--- all_subdir_cddl ---
--- all_subdir_cddl/usr.bin ---
--- all_subdir_cddl/usr.bin/zinject ---
===> cddl/usr.bin/zinject (all)
--- all_subdir_gnu ---
--- gdbtui ---
cc: error: no such file or directory: 
'/usr/obj/usr/src/gnu/usr.bin/binutils/libbfd/libbfd.a'
*** [gdbtui] Error code 1

bmake[6]: stopped in /usr/src/gnu/usr.bin/gdb/gdbtui
.ERROR_TARGET='gdbtui'
.ERROR_META_FILE='/common/S4/obj/usr/src/gnu/usr.bin/gdb/gdbtui/gdbtui.meta'
.MAKE.LEVEL='6'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
.CURDIR='/usr/src/gnu/usr.bin/gdb/gdbtui'
.MAKE='/usr/obj/usr/src/make.amd64/bmake'
.OBJDIR='/usr/obj/usr/src/gnu/usr.bin/gdb/gdbtui'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/tmp'
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20160604'
PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
/usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf 
/usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf 
/usr/src/gnu/usr.bin/gdb/gdbtui/Makefile /usr/src/share/mk/bsd.prog.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk 
/usr/src/share/mk/src.init.mk /usr/src/gnu/usr.bin/gdb/gdbtui/../Makefile.inc 
/usr/src/gnu/usr.bin/gdb/arch/amd64/Makefile 
/usr/src/gnu/usr.bin/gdb/gdbtui/../../Makefile.inc 
/usr/src/gnu/usr.bin/gdb/gdbtui/../../../Makefile.inc 
/usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk 
/usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.libnames.mk 
/usr/src/share/mk/src.libnames.mk /usr/src/share/mk/src.opts.mk 
/usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk 
/usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk 
/usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk 
/usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk 
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk 
/usr/src/share/mk/bsd.sys.mk'
.PATH='. /usr/src/gnu/usr.bin/gdb/gdbtui /usr/src/contrib/gdb/gdb 
/usr/src/contrib/gdb/gdb/cli /usr/src/contrib/gdb/gdb/mi 
/usr/src/contrib/gdb/gdb/signals /usr/src/contrib/gdb/gdb/tui 
/usr/src/gnu/usr.bin/gdb/arch/amd64'
1 error

bmake[6]: stopped in /usr/src/gnu/usr.bin/gdb/gdbtui
.ERROR_TARGET='gdbtui'



Laptop:
...
===> usr.bin/mkcsmapper_static (obj,build-tools)
--- build-tools_share/syscons/scrnmaps ---
--- obj ---
...
--- obj_crunchdir_rcp ---
--- obj_crunchdir_sync ---
--- obj ---
--- obj_crunchdir_csh ---
--- obj_crunchdir_badsect ---
--- build-tools_usr.bin/mkcsmapper_static ---
--- lex.o ---
/usr/src/usr.bin/mkcsmapper/lex.l:56:25: error: use of undeclared identifier 
'R_LN'
{ linenumber++; return (R_LN); }
^
/usr/src/usr.bin/mkcsmapper/lex.l:70:3: error: use of undeclared identifier 
'yylval'
yylval.i_value = strtoul(yytext, NULL, 0);
^
/usr/src/usr.bin/mkcsmapper/lex.l:71:11: error: use of undeclared identifier 
'L_IMM'
return (L_IMM);
^
/usr/src/usr.bin/mkcsmapper/lex.l:74:11: error: use of undeclared identifier 
'R_TYPE'
{ return (R_TYPE); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:75:11: error: use of undeclared identifier 
'R_NAME'
{ return (R_NAME); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:76:11: error: use of undeclared identifier 
'R_SRC_ZONE'
{ return (R_SRC_ZONE); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:77:11: error: use of undeclared identifier 
'R_DST_INVALID'
{ return (R_DST_INVALID); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:78:11: error: use of undeclared identifier 
'R_DST_ILSEQ'
{ return (R_DST_ILSEQ); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:79:11: error: use of undeclared identifier 
'R_DST_UNIT_BITS'
{ return (R_DST_UNIT_BITS); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:80:11: error: use of undeclared identifier 
'R_BEGIN_MAP'
{ return (R_BEGIN_MAP); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:81:11: error: use of undeclared identifier 
'R_END_MAP'
{ return (R_END_MAP); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:82:11: error: use of undeclared identifier 
'R_INVALID'
{ return (R_INVALID); }
  ^
/usr/src/usr.bin/mkcsmapper/lex.l:83:11: error: use of undeclared identifier 
'R_ILSEQ'
{ ret

Re: how to SVN regenerate [ man awk ]

[David Wolfskill]

On Thu, Mar 09, 2017 at 07:00:13AM -0800, Jeffrey Bouquet wrote:
> For $giggles$ I svn up /usr/src/usr.bin/awk  or wherever, then
> man awk displays not the newer import per a recent SVN but
> the older 2015 [ it says ] one.  Stale file, or not all parts of
> the man page updated to include latest revision dat, or some
> other command to [g]unzip or whatever, besides 320.whatis
> in periodic--weekly, update the compressed latest installed
> files from /usr/obj to what one expects when one has just
> recompiled the  man page?

If you intend to use "svn up", you should probably review, and
follow the instructions in, /usr/src/UPDATING.

> This crops up quite a lot on this machine, so I am unschooled in
> some principle of updating this operating system.  
> 
> If it matters, I receive a 
> 
> WARNING manpath environment variable set
> 
> when starting an additional
> xterm & ... 

You may have code in your login shell's initialization file that sets
MANPATH

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: start-up failure at SVN r314889

[David Wolfskill]

On Wed, Mar 08, 2017 at 07:55:44AM -0500, Michael Butler wrote:
> My laptop usually starts like this ..
> 
> FreeBSD 12.0-CURRENT #21 r314812M: Mon Mar  6 19:34:51 EST 2017
> i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI amd64
> FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
> 4.0.0)
> ...
> 
> This morning, I get this :-(
> 
> FreeBSD 12.0-CURRENT #27 r314889M: Tue Mar  7 19:55:25 EST 2017
> i...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/sys/TOSHI
> FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
> 4.0.0)
> VT(vga): resolution 640x480
> panic: kthread_add called too soon
>  [ .. ]
> 
> Any thoughts?
> 

"uname -vp" output from my last several (successful) build/smoke-tests
for head:

FreeBSD 12.0-CURRENT #274  r314653M/314653:1200023: Sat Mar  4 06:46:18 PST 
2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

FreeBSD 12.0-CURRENT #275  r314700M/314700:1200023: Sun Mar  5 07:45:20 PST 
2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

FreeBSD 12.0-CURRENT #276  r314770M/314770:1200023: Mon Mar  6 05:45:44 PST 
2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

FreeBSD 12.0-CURRENT #277  r314842M/314842:1200023: Tue Mar  7 05:55:58 PST 
2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

FreeBSD 12.0-CURRENT #278  r314906M/314906:1200024: Wed Mar  8 06:05:49 PST 
2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

Sorry it's not more help.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: kernel trap 12 with interrupts disabled

[David Wolfskill]

On Sat, Mar 04, 2017 at 10:08:45PM -0800, Chris H wrote:
> Thanks for the reply.
> I rebooted to kernel.old, so I could get the exact
> src revision I built this on. It's r314640
> 
> Any news as to whether it's safe to update src, and
> build a usable kernel?
> 

I (try to -- and usually succeed in doing so) build & smoke test
stable/11 and head daily, on both a dedicated "build machine and the
laptop I use for day-to-day use.

Details are posted at
, including links to
pages with logs of the (daily) output of "uname -vp", so folks can see
what worked for me (along with a fair bit of other stuff that may be
useful for reality checks).

The last few lines of "uname" output for my laptop for head are:

...
FreeBSD 12.0-CURRENT #272  r314549M/314552:1200022: Thu Mar  2 05:52:54 PST 
2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
FreeBSD 12.0-CURRENT #273  r314592M/314592:1200023: Fri Mar  3 07:12:34 PST 
2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
FreeBSD 12.0-CURRENT #274  r314653M/314653:1200023: Sat Mar  4 06:46:18 PST 
2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

(but I just started another cycle, so I expect to be augmenting the list
fairly soon).

I didn't happen to build at r314640; I did so at r314592 and r314653 -- 
successfully -- though.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Possible overlooked "svn add" in r314192?

[David Wolfskill]

Updating head in place from r314136 -> r314200, I find I can't build the
kernel because:

...
===> iwifw/iwi_ibss (all)
--- all_subdir_iwifw/iwi_monitor ---
===> iwifw/iwi_monitor (all)
--- all_subdir_ipmi ---
--- all_subdir_ipmi/ipmi_linux ---
===> ipmi/ipmi_linux (all)
--- all_subdir_iwm ---
bmake[4]: bmake[4]: don't know how to make if_iwm_fw.c. Stop

bmake[4]: stopped in /usr/src/sys/modules/iwm
.ERROR_TARGET='if_iwm_fw.c'
.ERROR_META_FILE=''
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
.CURDIR='/usr/src/sys/modules/iwm'
.MAKE='/usr/obj/usr/src/make.amd64/bmake'
.OBJDIR='/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/iwm'
.TARGETS='all'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/common/S4/obj/usr/src/sys/GENERIC/modules'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20160604'
PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
/usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk /etc/make.conf 
/usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf 
/usr/src/sys/modules/iwm/Makefile /usr/src/share/mk/bsd.kmod.mk 
/usr/src/sys/conf/kmod.mk /usr/src/share/mk/bsd.init.mk 
/usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk 
/usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk 
/usr/src/sys/modules/iwm/../Makefile.inc /usr/src/share/mk/bsd.own.mk 
/usr/src/share/mk/bsd.compiler.mk /usr/src/sys/conf/kern.opts.mk 
/usr/src/sys/conf/config.mk /usr/src/share/mk/bsd.links.mk 
/usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk 
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk 
/usr/src/sys/conf/kern.mk'
.PATH='. /usr/src/sys/modules/iwm /usr/src/sys/modules/iwm/../../dev/iwm 
/common/S4/obj/usr/src/sys/GENERIC'
*** [all_subdir_iwm] Error code 2

bmake[3]: stopped in /usr/src/sys/modules
.


Looking at r314192, I see a couple of (new) references to
dev/iwm/if_iwm_fw.c, but nothing to indicate that it exists or how
to build it.

Overlooked "svn add", perhaps?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Laptop very sluggish diring smoke-test @r314036

[David Wolfskill]

On Tue, Feb 21, 2017 at 03:45:36PM +0100, Mateusz Guzik wrote:
> ...
> > stable/11 -- I had been waiting for it to finish the reboot for
> > around 5 minutes, watching:  "Syncing disks, vnodes remaining ..."
> > when the thought of noting the amount of elapsed time between reports
> > of the numbers of remaining vnodes occurred to me: it was about 10
> > seconds each.
> > 
> > Normally, it's closer to 2 seconds, if that, IIRC.
> > 
> > In any case, overall behavior seemed fairly consistent with that
> > magnitude of a slowdown overall.
> > 
> 
> Can you check if the problem IS NOT present on r313995 but IS present on
> r313996? Only rebuilding the kernel + modules is necessary.
> 
> If the problem was not introduced by r313996 I'm afraid you will have to
> bisect.
> 
> -- 
> Mateusz Guzik 

Well  I "cloned" my head slice (4) to slice 3, updating source on
slice 3 to r313995, rebooted to slice 3... and noticed that it didn't
seem slugglish at all (unlike the earlier "smoke-test").

So before I did anything else, I rebooted it... and the countdown after
"Syncing disks, vnodes remaining..." was about 1 second each.

So I'm not sure what happened, but it looks as if I can't (readily)
reproduce the symptom.  I'll try experimenting a bit more as time
permits today (but I actually use the laptop in my day-to-day work, so
that may prove challenging).

Sorry for the noise.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Laptop very sluggish diring smoke-test @r314036

[David Wolfskill]

This morning's daily "head" update & smoke-test was from:

FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #263  
r313988M/313991:1200021: Mon Feb 20 06:31:32 PST 2017 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

to

FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #264  
r314036M/314036:1200021: Tue Feb 21 05:52:20 PST 2017 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

On reboot, the system was very sluggish; unfortunately, I failed
to try to quantify that until I had already started the reboot to
stable/11 -- I had been waiting for it to finish the reboot for
around 5 minutes, watching:  "Syncing disks, vnodes remaining ..."
when the thought of noting the amount of elapsed time between reports
of the numbers of remaining vnodes occurred to me: it was about 10
seconds each.

Normally, it's closer to 2 seconds, if that, IIRC.

In any case, overall behavior seemed fairly consistent with that
magnitude of a slowdown overall.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: dhclient fails: can't open and lock /var/db/dhclient.leases.wlan0: Bad file descriptor

[David Wolfskill]

On Fri, Feb 10, 2017 at 04:10:41PM +0200, Konstantin Belousov wrote:
> ...
> Please try this.
> 
> diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c
> index 70cdcdc6f75..1f2cceaf7a6 100644
> --- a/sys/kern/vfs_vnops.c
> +++ b/sys/kern/vfs_vnops.c
> @@ -351,8 +351,8 @@ vn_open_vnode(struct vnode *vp, int fmode, struct ucred 
> *cred,
>  
>   while ((fmode & (O_EXLOCK | O_SHLOCK)) != 0) {
>   KASSERT(fp != NULL, ("open with flock requires fp"));
> - if (fp->f_type != DTYPE_VNODE) {
> - error = EBADF;
> + if (fp->f_type != DTYPE_NONE && fp->f_type != DTYPE_VNODE) {
> + error = EOPNOTSUPP;
>   break;
>   }
>   lock_flags = VOP_ISLOCKED(vp);
> diff --git a/sys/sys/file.h b/sys/sys/file.h
> index 353c92f365a..c51f26a41d2 100644
> --- a/sys/sys/file.h
> +++ b/sys/sys/file.h
> @@ -53,6 +53,7 @@ struct vnode;
>  
>  #endif /* _KERNEL */
>  
> +#define  DTYPE_NONE  0   /* not yet initialized */
>  #define  DTYPE_VNODE 1   /* file */
>  #define  DTYPE_SOCKET2   /* communications endpoint */
>  #define  DTYPE_PIPE  3   /* pipe */


That seems to have done it -- thank you! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

dhclient fails: can't open and lock /var/db/dhclient.leases.wlan0: Bad file descriptor

[David Wolfskill]

This was head @r313544; previous successful build/smoke test was
@r313467 (yesterday).

Here's an excerpt from a typescript I made of some "poking around";
subsequent to that, I was able to set the IP address, netmask, and
broadcast address on the NIC (wlano), then set the default route, and
once that was done, I was able to use the network:

wlan0: flags=8843 metric 0 mtu 1500
ether 00:24:d6:7a:03:ce
inet 0.0.0.0 netmask 0xff00 broadcast 255.255.255.255 
nd6 options=29
media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
status: associated
ssid lmdhw-net channel 1 (2412 MHz 11g ht/20) bssid 04:18:d6:22:22:1f
regdomain FCC country US authmode WPA2/802.11i privacy ON
deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 10 scanvalid 60
protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi
-stbc -ldpc wme roaming MANUAL
groups: wlan 
(12.0-C)[4] pgrep dhclient
(12.0-C)[5] dhclient wlan0
dhclient: /etc/dhclient-enter-hooks invoked with reason PREINIT
dhclient: Leaving hostname set to 
dhclient: /etc/dhclient-exit-hooks invoked with reason PREINIT
dhclient: reason was PREINIT; no action taken
dhclient: Exiting /etc/dhclient-exit-hooks (PREINIT) with exit_status 0
can't open and lock /var/db/dhclient.leases.wlan0: Bad file descriptor
exiting.
(12.0-C)[6] ls -lTio /var/db/dhclient.leases*
883105 --  1 root  wheel  - 4017 Jan  4 09:18:10 2017 
/var/db/dhclient.leases.em0
883280 --  1 root  wheel  -  856 Aug 11 04:52:54 2015 
/var/db/dhclient.leases.lagg0
883344 --  1 root  wheel  -  Jan 20 21:19:10 2015 
/var/db/dhclient.leases.vboxnet0
883108 --  1 root  wheel  - 1993 Feb 10 04:30:13 2017 
/var/db/dhclient.leases.wlan0
883079 --  1 root  wheel  - 2013 Jan 19 11:52:07 2017 
/var/db/dhclient.leases.wlan1


Moving /var/db/dhclient.leases.wlan0 aside did not change the behavior.

Stable/11 shows the iwn(4) device as:
g1-252(11.0-S)[4] pciconf -lv | grep -A 3 iwn
iwn0@pci0:3:0:0:class=0x028000 card=0x13218086 chip=0x42328086 rev=0x00 
hdr=0x00
vendor = 'Intel Corporation'
device = 'WiFi Link 5100'
class  = network
g1-252(11.0-S)[5] 

File system for /var is a fairly vanilla UFS2+SU.  I suppose I could have
tried ktrace (had I thought of it before switching back to the stable/11
slice).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Does someone keep track of how long it takes to buildworld/kernel?

[David Wolfskill]

On Fri, Jan 13, 2017 at 08:23:21PM +, Eric Joyner wrote:
> ^ Message ^
> 
> It takes forever, but I keep on forgetting to time how long it takes, so I
> don't know how long "forever" is.
> 

I don't have much historical information, but I do my builds within
script(1), so that provides a (crude) estimate.  ("Crude" because I use
a csh alias to do it, so I invoke it by hand -- and as noted below, that
also iincludes any manual mergemaster activities.)

This morning (on my laptop), the build from r311974 -> r312063 started
at Fri Jan 13 04:43:06 2017 and ended at Fri Jan 13 05:00:54 2017, which
included buildworld, buildkernel, installkernel, and installworld (as
well as assorted mergemaster, &c.)  So that was 17:48.

The equivalent yesterday, for r311926 -> r311974, started at Thu Jan 12
04:48:24 2017 and ended at Thu Jan 12 05:12:42 2017.  So that was 24:18.

My build machine was a fair bit faster, but its work is done for the
day, so it's powered off.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Possible race condiction during -j16 buildworld (r311640 -> r311678)

[David Wolfskill]

One (of four) in-place source-based updates of head/amd64 from r311640
-> r311678 failed twice for me in "make buildworld" (at slightly
different points during the build).  The first retry got a bit further;
the second completed successfully.

I have a typescript of the entire thing, so I'll make that available in
.

The reason that there were 4 updates is that I have to machines (my
laptop and a build machine, "freebeast"), each of which builds its
normal kernel ("CANARY" for the laptop; "GENERIC" for the build
machine), then I've also been testing building & running with the
EARLY_AP_TEST option enabled in the kernel.  And while I could do that
by merely building the additional kernel in the "normal" environment and
giving it a "smoke test" every once in a while, I chose to duplicate the
entire slice, then add the EARLY_AP_TEST option to the kernels in
questions.

In any case, it was the EARLY_AP_TEST on the build machine that had the
apparent issue.

So, in , you'll find
typescript_r311678 (9MB), as well as typescript_r311678.gz (780KB).

I use the "_bw" csh alias to do the builds; as described in
, that alias
(ultimately) expands to:

setenv TMPDIR /tmp && \
 id && \
 mount && \
 cd /usr/src && \
 uname -a && \
 date && \
 make -j16 buildworld && \
 date && \
 make -j16 buildkernel && \
 date && \
 rm -fr /boot/modules.old && \
 cp -pr /boot/modules{,.old} && \
 make installkernel && \
 date && \
 pushd /usr/ports && \
 pushd x11/nvidia-driver && \
 make clean ; popd ; popd && \
 date && \
 mergemaster -U -u 0022 -p && \
 date && \
 rm -fr /usr/include.old && \
 date && \
 mv /usr/include{,.old} && \
 date && \
 rm -fr /usr/share/man && \
 date && \
 make installworld && \
 date && \
 mergemaster -F -U -u 0022 -i && \
 date && \
 make delete-old && \
 date && \
 df -k

There's a copy of the machine's (verbose) dmesg.boot at
.

I have 2 local modifications to the tree:
1) The hack to src/sys/conf/newvers.sh, discussed on
   .

2) A change I had made several days ago to src/Makefile.inc1, augmenting
   ITOOLS with "env" (as some installation step apparently needed it).
   I hadn't got around to testing to determine if it's still needed.

As for why it seeme dto hit the EARLY_AP_TEST and not the GENERIC
one...?  No clue -- dumb luck, I suppose: that should have no effect
once the machine has attained multi-user mode

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Epistemology for post-truthers: How do we select parts of reality to ignore?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: every command segmentation faults after installworld

[David Wolfskill]

On Sat, Dec 31, 2016 at 01:11:50PM +0100, Ronald Klop wrote:
> Hi,
> 
> I just rebuild kernel+world (with NO_CLEAN=yes). Installworld failed:
> ===> libexec/rtld-elf (install)
> chflags -h noschg /usr/libexec/ld-elf.so.1
> install  -s -o root -g wheel -m 555  -C -b -fschg -S ld-elf.so.1  
> /libexec/ld-elf
> .so.1
> install  -o root -g wheel -m 444  ld-elf.so.1.debug  
> /usr/lib/debug/libexec/ld-el
> f.so.1.debug
> install  -o root -g wheel -m 444 rtld.1.gz  /usr/share/man/man1/
> rm -f /usr/share/man/man1/ld-elf.so.1.1  
> /usr/share/man/man1/ld-elf.so.1.1.gz;  i
> nstall -l h  /usr/share/man/man1/rtld.1.gz  
> /usr/share/man/man1/ld-elf.so.1.1.gz
> *** Signal 11
> 
> Stop.
> make[5]: stopped in /usr/src/libexec/rtld-elf
> *** Error code 1
> 
> 
> No every command I run segmentation faults.
> Can I recover this?
> 
> I run 12-CURRENT/amd64 and just svn upped an hour ago. I'll try to use  
> /rescue to copy ld-elf.so.1 from a snapshot.
> 

My source-based, in-placed update from:

FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #210  
r310809M/310809:1200019: Fri Dec 30 04:46:14 PST 2016 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

to

FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #211  
r310942M/310946:1200019: Sat Dec 31 04:54:03 PST 2016 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

this morning was ... uneventful -- as was the one from:

FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #33  
r310809M/310809:1200019: Fri Dec 30 05:10:16 PST 2016 
r...@g1-252.catwhisker.org:/common/S3/obj/usr/src/sys/EARLY_AP_TEST  amd64

to 

FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #34  
r310942M/310946:1200019: Sat Dec 31 05:17:59 PST 2016 
r...@g1-252.catwhisker.org:/common/S3/obj/usr/src/sys/EARLY_AP_TEST  amd64


Further details (for the "CANARY" kernel) may be found on the pages
linked from  --
including verbose dmesg.boot.

The above report is for my laptop; the build machine is still busy
with its Saturday "catch up" poudriere run (in preparation for
tomorrow's updates).  If I see issues when I build head on it, I'll
follow up; otherwise, the pages (ref. above) will be updated to reflect
its status.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Epistemology for post-truthers: How do we select parts of reality to ignore?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Install tools in src/Makefile.inc1 might need to be augmented

[David Wolfskill]

I found the attached patch (which augments ITOOLS in src/Makefile.inc1
with "env" and "mktemp") necessary to complete "make installworkd"
when updtaing from:

FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #197  
r310104M/310111:1200018: Thu Dec 15 04:20:23 PST 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

to:

FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #198  
r310154M/310154:1200019: Fri Dec 16 05:31:10 PST 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Epistemology for post-truthers: How do we select parts of reality to ignore?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
Index: Makefile.inc1
===
--- Makefile.inc1	(revision 310154)
+++ Makefile.inc1	(working copy)
@@ -915,8 +915,8 @@
 .endif
 
 ITOOLS=	[ awk cap_mkdb cat chflags chmod chown cmp cp \
-	date echo egrep find grep id install ${_install-info} \
-	ln make mkdir mtree mv pwd_mkdb \
+	date echo egrep env find grep id install ${_install-info} \
+	ln make mkdir mktemp mtree mv pwd_mkdb \
 	rm sed services_mkdb sh strip sysctl test true uname wc ${_zoneinfo} \
 	${LOCAL_ITOOLS}
 


signature.asc
Description: PGP signature

Re: CURRENT: pkg broken on r309320

[David Wolfskill]

On Wed, Nov 30, 2016 at 09:46:37PM +0100, Hartmann, O. wrote:
> ...
> I'm now on re09332. The problem still persists. It is serious, no
> packages can be installed and kernel building fails due to modules set
> to be rebuild every time kernel is built in /etc/src.conf.
> 
> Unfortunately, building kernel AND having x11/nvidia-driver being built
> every time kernel is build, makes the port x11/nvidia-driver vanish. It
> is reported installed (check via pkg info), but there are no binaries!
> 
> This is a serious situation.
> 
> Thanks in advance,
> 
> Oliver

This also bit me (@r309324), building the kmod for nvidia-driver-340.

So I applied the patch from https://reviews.freebsd.org/D8677, and tried
again -- worked.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Ref. 08 Nov 2016, let's see if the "winners" actually deliver on their slogans.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Panic @306337: Duplicate free of 0xfffff8000ef61500 from zone 0xfffff8000772b000(mbuf) slab 0xfffff8000ef61f90(5)

[David Wolfskill]

On Mon, Sep 26, 2016 at 08:48:19AM -0700, hiren panchasara wrote:
> On 09/26/16 at 05:11P, David Wolfskill wrote:
> > Source upgrade from r306307 to r306337 completed OK; this was on build
> > machine (laptop is "Installing everything" as I type).  Serial console
> > (on panicked build machine) reads:
> 
> Seems like my fault with r306337. Bruce also has some issues/concerns
> with it. I've reverted it for now with r306348 as I don't have time to
> deal with it right now.

OK; After (hand-)applying r306348 & rebuilding, I'm able to boot to
multi-user mode & login:

FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #118  
r306337M/306337:1200010: Mon Sep 26 09:31:45 PDT 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

Thanks for the fix!

> Apologies for the trouble.

It's head; I expect a certain amount of turbulence on (a rare) occasion.

At least it actually built! :-)

> Cheers,
> Hiren

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Panic @306337: Duplicate free of 0xfffff8000ef61500 from zone 0xfffff8000772b000(mbuf) slab 0xfffff8000ef61f90(5)

[David Wolfskill]

Source upgrade from r306307 to r306337 completed OK; this was on build
machine (laptop is "Installing everything" as I type).  Serial console
(on panicked build machine) reads:

...
Setting hostname: freebeast.catwhisker.org.
Setting up harvesting: 
[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
Feeding entropy: .
Starting Network: lo0 re0.
lo0: flags=8049 metric 0 mtu 16384
options=63 on usbus0
SUM_IPV6,TXCSUM_random: harvesting attach, 8 bytes (4 bits) from ubt0
IPV6>
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
inet 127.0.0.1 WARNING: attempt to domain_add(bluetooth) after 
domainfinalize()
netmask 0xffWARNING: attempt to domain_add(netgraph) after domainfinalize()
00 
nd6 options=21
groups: lo 
re0: flags=8843 metric 0 mtu 1500

options=8209b 

I can leave the machine in this state & perform "directed pokes" at it,
given appropriate clues.

I'm about to try rebooting laptop (just finished similar upgrade);
I'll report back whether it behaves similarly or not, but I don't
expect to be able to leave it panicked (as I use it to access
everything else ).

...

Eh; I decided to defer sending this until I tried the laptop: it
had a similar panic, just after starting powerd.  On the laptop,
when it's running stable/11, the next things to pop up are the
startup messages for hald (which the build machine does not have)
and then sshd (which each machine runs).

The build machine runs a GENERIC kernel; laptop runs a slightly-customized
kernel (includes GENERIC & tweaks from there).

I tried "panic" at the laptop's "db> " prompt, but I have no crash dump.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: [RFC] remove GNU rcs from FreeBSD 12

[David Wolfskill]

On Sun, Sep 11, 2016 at 03:38:04PM +0200, Baptiste Daroussin wrote:
> ...
> For long we are planning to remove GNU rcs from base, after a failed attempt
> before FreeBSD 10.0. Let see where we are to be able to remove it from FreeBSD
> 12.
> 
> GNU rcs is a GPLv2 software with newer version being GPLv3 preventing any
> updates/fixes.

Err... yeah. :-/  I was using RCS before it was GPLed :-(

> From previous discussions there were issues that has been raised in previous
> attempts:
> ...
> - people uses rcs to handle configuration files in /etc for example. for those
>   multiple compatible alternatives are available in ports:
>   * rcs57: a copy of the latest version of GNU rcs in base before removal
> (GPLv2)
>   * rcs: latest GNU rcs version (GPLv3)

Right; I'm one of those (folks who use RCS for local config files and
the like).  As well as Web pages, xfig files

> I haven't gone the direction of importing OpenRCS (BSD licensed version from
> OpenBSD) as it needs way more work to be 100% compatible with latest version 
> of
> GNU rcs.

Hmm  If there were a FreeBSD port for OpenRCS, I'd be interested in
poking at it  I'm not even at all sure that I need "100%
compatib[ility]" with any version of a GPLed RCS.  (Indeed; I may not
*want* such compatibility)

> How to proceed:
> - First turn off GNU rcs by default for a couple of month.
> - Totally remove GNU rcs if no blockers has been raised.
> 

OK; warning received. :-}  Thanks

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: buildworld fails @r305471: "cc: error: linker command failed with exit code 1"

[David Wolfskill]

On Tue, Sep 06, 2016 at 05:11:11AM -0700, David Wolfskill wrote:
> ...
> Laptop got through "buildworld" Just Fine; re-trying on build machine.
> We may have a race.
> 

OK; build machine succeeded on the second try.  (Laptop did so the first
time).

As that at least raises the possibility of a race condition during the
build, I have placed the typescripts from both builds in
<http://www.catwhisker.org/~david/FreeBSD/head/build_r305471/>.

The (csh) aliases that are used expand to:

* _bw
  setenv TMPDIR /tmp && \
  id && \
  mount && \
  cd /usr/src && \
  uname -a && \
  date && \
  make -j16 buildworld && \
  date && \
  make -j16 buildkernel && \
  date && \
  rm -fr /boot/modules.old && \
  cp -pr /boot/modules{,.old} && \
  make installkernel && \
  date && \
  pushd /usr/ports && \
  pushd x11/nvidia-driver && \
  make clean ; popd ; popd && \
  date && \
  mergemaster -U -u 0022 -p && \
  date && \
  rm -fr /usr/include.old && \
  date && \
  mv /usr/include{,.old} && \
  date && \
  rm -fr /usr/share/man && \
  date && \
  make installworld && \
  date && \
  mergemaster -F -U -u 0022 -i && \
  date && \
  make delete-old && \
  date && \
  df -k

* _do
  setenv TMPDIR /tmp && \
  id && \
  mount && \
  cd /usr/src && \
  uname -a && \
  date && \
  make delete-old-libs && \
  cp /var/run/dmesg.boot /var/tmp/dmesg.boot.12.0-CURRENT_amd64 && \
  log_uname && \
  date


"log_uname" is a little shell script that appends the output of "uname
-vp" to a file named:
/var/tmp/uname_${arch}.$( uname -r | sed -e 's/\..*$//' )

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: buildworld fails @r305471: "cc: error: linker command failed with exit code 1"

[David Wolfskill]

On Tue, Sep 06, 2016 at 04:36:18AM -0700, David Wolfskill wrote:
> Leading up to this; building on head/amd64 running:
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #96  
> r305415M/305415:126: Mon Sep  5 04:35:16 PDT 2016 
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
> 
> ...
> [things generally go downhill from this point] ...
> 
> I'll be repeating the experiment on my laptop shortly.
> 

Laptop got through "buildworld" Just Fine; re-trying on build machine.
We may have a race.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

buildworld fails @r305471: "cc: error: linker command failed with exit code 1"

[David Wolfskill]

Leading up to this; building on head/amd64 running:
FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #96  
r305415M/305415:126: Mon Sep  5 04:35:16 PDT 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

...
--- gnu/lib/libgcc__L ---
Building /common/S4/obj/usr/src/world32/usr/src/gnu/lib/libgcc/_libinstall
--- kerberos5/lib/libhx509__L ---
Building /common/S4/obj/usr/src/world32/usr/src/kerberos5/lib/libhx509/keyset.So
--- secure/lib/libssl__L ---
/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [libssl.so.8] Error code 1

bmake[4]: stopped in /usr/src/secure/lib/libssl
.ERROR_TARGET='libssl.so.8'
.ERROR_META_FILE='/common/S4/obj/usr/src/world32/usr/src/secure/lib/libssl/libssl.so.8.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
.CURDIR='/usr/src/secure/lib/libssl'
.MAKE='/usr/obj/usr/src/make.amd64/bmake'
.OBJDIR='/usr/obj/usr/src/world32/usr/src/secure/lib/libssl'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/lib32'
LD_LIBRARY_PATH=''
MACHINE='i386'
MACHINE_ARCH='i386'
MAKEOBJDIRPREFIX='/usr/obj/usr/src/world32'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20160604'
PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src/world32/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
/usr/src/share/mk/bsd.mkopt.mk /etc/make.conf /usr/src/share/mk/local.sys.mk 
/usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/secure/lib/libssl/Makefile 
/usr/src/secure/lib/libssl/Makefile.man 
/usr/src/secure/lib/libcrypto/Makefile.inc /usr/src/share/mk/bsd.own.mk 
/usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk 
/usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.endian.mk 
/usr/src/share/mk/bsd.lib.mk /usr/src/share/mk/bsd.init.mk 
/usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk 
/usr/src/secure/lib/libssl/../Makefile.inc 
/usr/src/secure/lib/libssl/../../Makefile.inc /usr/src/share/mk/src.opts.mk 
/usr/src/secure/lib/libssl/../../../lib/Makefile.inc 
/usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk 
/usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk 
/usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk 
/usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk 
/usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk 
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk 
/usr/src/share/mk/bsd.sys.mk'
.PATH='. /usr/src/secure/lib/libssl 
/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl 
/usr/src/secure/lib/libssl/man'
1 error

[things generally go downhill from this point] ...

I'll be repeating the experiment on my laptop shortly.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Panic @r305116 in transition to multi-user mode

[David Wolfskill]

On Wed, Aug 31, 2016 at 02:30:23PM +0200, Mateusz Guzik wrote:
> ...
> > db> dump
> > Dumping 1299 out of 32687 
> > MB:..2%..12%..21%..31%..41%..51%..61%..71%..81%..92%
> > Dump complete
> > db> 
> > 
> 
> This is most likely r305091 which I reverted in r305124, i.e. just
> upgrade and see if it helps.

Aye, that fixed it -- thank you! :-)

(And for reference, the laptop also exhibited the behavior -- as
expected.)

> Sorry for trouble,
> 

No problem -- I track head to find such things :-}

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Panic @r305116 in transition to multi-user mode

[David Wolfskill]

This was well into the transition from single- to multi-user mode,
so the following information is a re-creation after I rebooted to
single-user mode (verbosely), ran "fsck -p", then "exit" -- copy/pasted
from serial console:

# exit
Setting hostuuid: 80f1e964-dc63-0010-89d5-0030482d326a.
Setting hostid: 0xc74551dd.
Fast boot: skipping disk checks.
Mounting local filesystems:.
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib 
/usr/local/lib/compat /usr/local/lib/perl5/5.24/mach/CORE
32-bit compatibility ldconfig path: /usr/lib32 /usr/lib32/compat 
/usr/local/libre0: link state changed to DOWN
32/compat
Setting hostname: freebeast.catwhisker.org.
Setting up harvesting: 
[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
Feeding entropy: .
Starting Network: lo0 re0.
lo0: flags=8049 metric 0 mtu 16384
options=63
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
inet 127.0.0.1 netmask 0xff00 
nd6 options=21
groups: lo 
re0: flags=8843 metric 0 mtu 1500

options=8209b
ether 98:90:96:d6:c9:6d
inet 172.16.8.10 netmask 0xff00 

broadcast 172.16Fat.8.255 
nd6 opal ttions=29
: pamedia: Ethernetge f autoselect (nonaue)
status: no lt carrier
Startinwhilg devd.
add hose it 127.0.0.1: gatn keway lo0 fib 0: erneroute already inl mo table
add net de
default: gatewaycpuid = 6; a 172.16.8.1
addpic host ::1: gatew iday lo0 fib 0: ro = ute already in t06
able
add net fefaul80::: gateway ::t 1
add net ff02:vir:: gateway ::1
tuaadd net :::0l ad.0.0.0: gateway dre::1
add net ::0ss   .0.0.0: gateway = 0x::1
Creating and/or trimming lo80403037b7a8
fault g files.
Starticode  = supervisor read data, page not present
ing syslogd.
Stanstruction pointer   = 0x20:0x80ead57a
rting rpcbind.
stack pointer   = 0x28:0xfe085de368c0
fraNFS access cacheme  time=60
rpc.umpointall: grundoon:nte MOUNTPROG: RPC:r Unknown host
rpc.umntall: grun   doon: MOUNTPROG:= 0 RPC: Unknown hox28st
No core dump:0xs found.
Setting NIS domain: lmfe0dhw.com.
Starti85dng ypbind.
Cleae36ring /tmp (X rel900ated).
Starting
 mountd.
NFSv4 codis disabled
Stae srting nfsd.
Staegmrting statd.
Stentarting lockd.
R   =ecovering vi edi bastor sessions:.
e 0Starting lpd.
Ux0, pdating motd:.
limiMounting late fit 0lesystems:.
Staxffrting ntpd.
Staffrting powerd.
ype ttarting rsyncd.
0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
pConfiguring vt:ro blanktimecessor eflags   = interrupt enabled, r.
esume, IOPL = 0
current process = 567 (ntpd)
[ thread pid 567 tid 100201 ]
Stopped at  pmap_kextract+0x8a: movq(%rax,%rcx,1),%r13
db> bt
Tracing pid 567 tid 100201 td 0xf80010349a00
pmap_kextract() at pmap_kextract+0x8a/frame 0xfe085de36900
free() at free+0x5e/frame 0xfe085de36940
kern_close() at kern_close+0xd0/frame 0xfe085de369a0
amd64_syscall() at amd64_syscall+0x2db/frame 0xfe085de36ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe085de36ab0
--- syscall (6, FreeBSD ELF64, sys_close), rip = 0x8013ebf2a, rsp = 
0x7fffe7d8, rbp = 0x7fffe7f0 ---
db> dump
Dumping 1299 out of 32687 MB:..2%..12%..21%..31%..41%..51%..61%..71%..81%..92%
Dump complete
db> 

I can afford to leave this system in this state until this evening (local
time here is just after 05:00 as I type), so if there's something I can
poke to get more useful information, please let me know.

Once I reboot (either from yesterday's (r305058) kernel or from the
stable/11 or stable/10 slice), I should be able to make the dump
available via my Web server.

I'm about to build head@r305116 on my laptop (as well); I plan to
follow up to indicate whether it exhibits similar behavior (or not).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: build fails post SVN r304026

[David Wolfskill]

On Sat, Aug 13, 2016 at 09:54:02AM -0400, Michael Butler wrote:
> Is anyone else seeing this?
> 
> ===> usr.bin/nfsstat (all)
> Building /usr/obj/usr/src/usr.bin/nfsstat/nfsstat.o
> /usr/src/usr.bin/nfsstat/nfsstat.c:301:4: error: array index 72 is past
> the end of the array (which contains 49 elements) [-Werror,-Warray-bounds]
> ext_nfsstats.srvrpccnt[NFSV4OP_SYMLINK],
> 

I am, as of r304040 (src upgrading from r304004), yes.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Possible race condition building libraries: head/amd64 r303329 -> r303379

[David Wolfskill]

On Wed, Jul 27, 2016 at 04:34:39PM -0700, Bryan Drewery wrote:
> ...
> These shouldn't happen since libgcc is build in startup_libs and krb5 is
> built in prebuild_libs, which waits on startup_libs. Very strange.
> 
> Can you send me the typescript please?
> 

(For folks playing along at home, I sent Bryan the typescript. I've also
placed a copy at
http://www.catwhisker.org/~david/FreeBSD/head/typescript_r303379.gz.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Possible race condition building libraries: head/amd64 r303329 -> r303379

[David Wolfskill]

I track head daily on both my laptop and a "build machine;" I only saw a
problem on the latter -- not on my laptop.

(The build machine is a bit beefier, and uses an SSD as its non-volatile
storage; the laptop uses a hybrid disk -- in case that is useful.)

As indicated in the Subject, in each case I was performing a
source-based upgrade-in-place from r303329 to r303379.  (And I've
been doing this routinely for quite some time.)

The build failed (initially -- a restart worked):

...
>>> stage 4.2: building libraries
...
--- secure/lib/libcrypto__L ---
Building /common/S4/obj/usr/src/secure/lib/libcrypto/dso_openssl.o
--- lib/ncurses/ncursesw__L ---
/usr/lib/libtermlibw.so -> libncursesw.so
/usr/lib/libtinfow.so -> libncursesw.so
--- kerberos5/lib/libwind__L ---
Building /common/S4/obj/usr/src/kerberos5/lib/libwind/normalize_table.So
--- kerberos5/lib/libheimipcc__L ---
/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [libprivateheimipcc.so.11] Error code 1

bmake[4]: stopped in /usr/src/kerberos5/lib/libheimipcc
.ERROR_TARGET='libprivateheimipcc.so.11'
.ERROR_META_FILE='/common/S4/obj/usr/src/kerberos5/lib/libheimipcc/libprivateheimipcc.so.11.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
.CURDIR='/usr/src/kerberos5/lib/libheimipcc'
.MAKE='/usr/obj/usr/src/make.amd64/bmake'
.OBJDIR='/usr/obj/usr/src/kerberos5/lib/libheimipcc'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/tmp'
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20160604'
PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
/usr/src/share/mk/bsd.mkopt.mk /etc/make.conf /usr/src/share/mk/local.sys.mk 
/usr/src/share/mk/src.sys.mk /etc/src.conf 
/usr/src/kerberos5/lib/libheimipcc/Makefile /usr/src/share/mk/bsd.lib.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk 
/usr/src/share/mk/src.init.mk 
/usr/src/kerberos5/lib/libheimipcc/../Makefile.inc 
/usr/src/kerberos5/lib/libheimipcc/../../Makefile.inc 
/usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk 
/usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk 
/usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk 
/usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk 
/usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk 
/usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk 
/usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk 
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk 
/usr/src/share/mk/bsd.sys.mk'
.PATH='. /usr/src/kerberos5/lib/libheimipcc 
/usr/src/kerberos5/lib/libheimipcc/../../../crypto/heimdal/lib/ipc'
1 error

bmake[4]: stopped in /usr/src/kerberos5/lib/libheimipcc
.ERROR_TARGET='libprivateheimipcc.so.11'
.ERROR_META_FILE='/common/S4/obj/usr/src/kerberos5/lib/libheimipcc/libprivateheimipcc.so.11.meta'
.MAKE.LEVEL='4'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
.CURDIR='/usr/src/kerberos5/lib/libheimipcc'
.MAKE='/usr/obj/usr/src/make.amd64/bmake'
.OBJDIR='/usr/obj/usr/src/kerberos5/lib/libheimipcc'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/tmp'
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20160604'
PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk 
/usr/src/share/mk/src.sys.env.mk /etc/src-env.conf 
/usr/src/share/mk/bsd.mkopt.mk /etc/make.conf /usr/src/share/mk/local.sys.mk 
/usr/src/share/mk/src.sys.mk /etc/src.conf 
/usr/src/kerberos5/lib/libheimipcc/Makefile /usr/src/share/mk/bsd.lib.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk 
/usr/src/share/mk/src.init.mk 
/usr/src/kerberos5/lib/libheimipcc/../Makefile.inc 
/usr/src/kerberos5/lib/libheimipcc/../../Makefile.inc 
/usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk 
/usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk 
/usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk 
/usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk 
/usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk 
/usr/src/share/mk/bsd.confs.mk /usr/src/s

Re: r302773: non-removable files with "make delete-old"

[David Wolfskill]

On Wed, Jul 13, 2016 at 06:35:10PM +0200, O. Hartmann wrote:
> make delete-old removes these files on CURRENT (FreeBSD 12.0-CURRENT #12 
> r302773: Wed Jul
> 13 18:10:55 CEST 2016), but they seem not to disappear. They are present 
> after an
> installation of world again and again: 
> 
> [...]
> remove /usr/share/locale/kk_KZ.UTF-8/LC_COLLATE? y
> 

Please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211046

(Above applies to both head & stable/11.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

"_secure_path: cannot stat /etc/login.conf: Not permitted in capability mode"

[David Wolfskill]

After updating my (amd64) build machine from r302018 to r302026, things
work OK, but (now that I've re-connected the serial cable so I can
actually interact with the serial console -- i.e., this may have
occurred a while back, but I wouldn't have noticed), I see:

...
Starting devd.
add host 127.0.0.1: gateway lo0 fib 0: route already in table
add net default: gateway 172.16.8.1
add
FreeBSD/amd64 (freebeast.catwhisker.org) (ttyu0)

login: Jun 20 11:34:16 freebeast sshd[736]: _secure_path: cannot stat 
/etc/login.conf: Not permitted in capability mode
Jun 20 11:34:16 freebeast last message repeated 2 times
Jun 20 11:34:21 freebeast sshd[810]: _secure_path: cannot stat /etc/login.conf: 
Not permitted in capability mode
Jun 20 11:34:21 freebeast last message repeated 2 times
Jun 20 11:34:25 freebeast sshd[882]: _secure_path: cannot stat /etc/login.conf: 
Not permitted in capability mode



on the serial console.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[David Wolfskill]

On Tue, Jun 14, 2016 at 05:17:19PM -0700, Chris H wrote:
> ...
> Honestly, I think the best way to motivate people to do the right thing(tm)
> Would be to remove Yellow Pages from the tree, entirely. :-)
> It's been dead for *years*, and as you say, isn't safe, anyway..
> 

"Safe" for what, precisely?

It's a lookup service.  It is not limited to looking up authentication
information, and never has been.

And it's a mechanism that has been widely implemented.

The catchphrase "Tools, not policy" comes to mind.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: 11.0 -r300944 build attempted WITH_META_MODE failed [amd64 targeting powerpc64 via devel/powerpc64-gcc use]

[David Wolfskill]

On Mon, May 30, 2016 at 11:52:27AM -0700, David Wolfskill wrote:
> ...
> > > May 30 11:29:31 g1-252 root: /etc/rc: WARNING: Unable to load kernel 
> > > module linux64
> > > May 30 11:29:31 g1-252 kernel: KLD linux64.ko: depends on kernel - not 
> > > available or version mismatch
> > > May 30 11:29:31 g1-252 kernel: linker_load_file: Unsupported file type
> > 
> > Your kernel was built from older sources than you used to build the nvidia
> > module.  I mean, the kernel headers used for the module build where
> > updated comparing with binaries that are installed into /boot/kernel.
> 
> Hmmm...  I'm ... unlcear ... on how that could have happened.
> ...

Turns out that Bryan Drewery hit it (in a different thread):

On Mon, May 30, 2016 at 08:29:40AM -0700, Bryan Drewery wrote:
> This failure is not likely related to META_MODE.
> 
> I should have mentioned that to enable META_MODE after not having it on
> you should do a 'make cleanworld' first.
> 

Given that hint, in my r300994 source tree, I first did:

cd /usr/src && make cleanworld

then re-built everything again (while Spouse and I were at a neighbor's
place for a cookout)

On reboot, everything looks good, and linux64.ko (and nvidia.ko) are
loaded:

g1-252(11.0)[1] uname -a
FreeBSD g1-252.catwhisker.org 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #0  
r300994M/300994:1100115: Mon May 30 14:42:29 PDT 2016 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
g1-252(11.0)[2] kldstat 
Id Refs AddressSize Name
 1   37 0x8020 1e074a8  kernel
 21 0x82009000 232f8geom_eli.ko
 32 0x8202d000 9d6d8linux.ko
 44 0x820cb000 d1f0 linux_common.ko
 51 0x820d9000 4c50 coretemp.ko
 61 0x820de000 546b0iwn5000fw.ko
 71 0x82133000 b67b50   nvidia.ko
 81 0x82c9b000 b838 filemon.ko
 91 0x82e21000 f01c tmpfs.ko
101 0x82e31000 595a fdescfs.ko
111 0x82e37000 a9e8 linprocfs.ko
121 0x82e42000 39672linux64.ko
g1-252(11.0)[3] 


Sorry for the false alarm.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Unable to load freshly-built nvidia.ko @r300994.

[David Wolfskill]

On Mon, May 30, 2016 at 07:03:42PM +0300, Konstantin Belousov wrote:
> ...
> > May 30 11:29:31 g1-252 root: /etc/rc: WARNING: Unable to load kernel module 
> > linux64
> > May 30 11:29:31 g1-252 kernel: KLD linux64.ko: depends on kernel - not 
> > available or version mismatch
> > May 30 11:29:31 g1-252 kernel: linker_load_file: Unsupported file type
> 
> Your kernel was built from older sources than you used to build the nvidia
> module.  I mean, the kernel headers used for the module build where
> updated comparing with binaries that are installed into /boot/kernel.

Hmmm...  I'm ... unlcear ... on how that could have happened.

I've copied the typescript (from the build) to
http://www.catwhisker.org/~david/FreeBSD/head/typescript_r300994; the
"_bw" alias (ultimately) expands to:

setenv TMPDIR /tmp && \
 id && \
 mount && \
 cd /usr/src && \
 uname -a && \
 date && \
 make -j16 buildworld && \
 date && \
 make -j16 buildkernel && \
 date && \
 rm -fr /boot/modules.old && \
 cp -pr /boot/modules{,.old} && \
 make installkernel && \
 date && \
 pushd /usr/ports && \
 pushd x11/nvidia-driver && \
 make clean ; popd ; popd && \
 date && \
 mergemaster -U -u 0022 -p && \
 date && \
 rm -fr /usr/include.old && \
 date && \
 mv /usr/include{,.old} && \
 date && \
 rm -fr /usr/share/man && \
 date && \
 make installworld && \
 date && \
 mergemaster -F -U -u 0022 -i && \
 date && \
 make delete-old && \
 date && \
 df -k

I have some errands/chores to deal with so I won't be able to respond
right away, but I would like to resolve the issue.

I received one suggestion to try reverting r300990;, which I did
(without a change in the symptoms).

I then reverted the sources back to r300951 and performed exactly thhe
same type of build (that is, with 'WITH_META_MODE=yes' in
/etc/src-env.conf; no attempt to use -DNO_CLEAN; build world; build
kernel; install kernel; install world; mergemaster...).  That's working
Just fine; kldstat shows:

g1-252(11.0)[6] kldstat 
Id Refs AddressSize Name
 1   37 0x8020 1e0a3a8  kernel
 21 0x8200c000 232f8geom_eli.ko
 32 0x8203 9d6d8linux.ko
 44 0x820ce000 d1f0 linux_common.ko
 51 0x820dc000 4c58 coretemp.ko
 61 0x820e1000 546b0iwn5000fw.ko
 71 0x82136000 b67b50   nvidia.ko
 81 0x82c9e000 b838 filemon.ko
 91 0x82e21000 f01c tmpfs.ko
101 0x82e31000 5959 fdescfs.ko
111 0x82e37000 a9e8 linprocfs.ko
121 0x82e42000 39671linux64.ko
g1-252(11.0)[7] 

Note thaht linux64.ko shows up here, while in the r300994 case,
linux64.ko would not load (which, I believe, is why nvidia.ko wouldn't
load).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Unable to load freshly-built nvidia.ko @r300994.

[David Wolfskill]

Today's "daily update" for head was from:

FreeBSD g1-252.catwhisker.org 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #432  
r300951M/300951:1100114: Sun May 29 04:44:37 PDT 2016 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

to:

FreeBSD g1-252.catwhisker.org 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #433  
r300994M/300994:1100115: Mon May 30 04:21:30 PDT 2016 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

(See

for the update history for FreeBSD-11 on this laptop.)

The attempt to load nvidia.ko yielded (from dmesg.boot):

linker_load_file: Unsupported file type
lock order reversal:
 1st 0xfe05c2224420 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3512
 2nd 0xf80009619600 dirhash (dirhash) @ 
/usr/src/sys/ufs/ufs/ufs_dirhash.c:281
stack backtrace:
#0 0x80a6a0d0 at witness_debugger+0x70
#1 0x80a69fc4 at witness_checkorder+0xe54
#2 0x80a13242 at _sx_xlock+0x72
#3 0x80d02857 at ufsdirhash_remove+0x37
#4 0x80d05a27 at ufs_dirremove+0x127
#5 0x80d0d04e at ufs_rename+0x135e
#6 0x80f4c5a0 at VOP_RENAME_APV+0x100
#7 0x80ad7c78 at kern_renameat+0x4a8
#8 0x82c9e5b9 at filemon_wrapper_rename+0x19
#9 0x80e04c06 at amd64_syscall+0x2f6
#10 0x80de4bdb at Xfast_syscall+0xfb
acquiring duplicate lock of same type: "os.lock_sx"
 1st os.lock_sx @ nvidia_os.c:603
 2nd os.lock_sx @ nvidia_os.c:603
stack backtrace:
#0 0x80a6a0d0 at witness_debugger+0x70
#1 0x80a69fc4 at witness_checkorder+0xe54
#2 0x80a13242 at _sx_xlock+0x72
#3 0x826161e2 at os_acquire_mutex+0x32
#4 0x82600b38 at _nv010796rm+0x18
ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found 
[Buffer], ACPI requires [Package] (20160527/nsarguments-97)
ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found 
[Buffer], ACPI requires [Package] (20160527/nsarguments-97)
ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found 
[Buffer], ACPI requires [Package] (20160527/nsarguments-97)
ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found 
[Buffer], ACPI requires [Package] (20160527/nsarguments-97)
ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found 
[Buffer], ACPI requires [Package] (20160527/nsarguments-97)
ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found 
[Buffer], ACPI requires [Package] (20160527/nsarguments-97)
ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found 
[Buffer], ACPI requires [Package] (20160527/nsarguments-97)
ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found 
[Buffer], ACPI requires [Package] (20160527/nsarguments-97)
ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found 
[Buffer], ACPI requires [Package] (20160527/nsarguments-97)
ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found 
[Buffer], ACPI requires [Package] (20160527/nsarguments-97)
ACPI Warning: \134_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found 
[Buffer], ACPI requires [Package] (20160527/nsarguments-97)
acquiring duplicate lock of same type: "os.lock_mtx"
 1st os.lock_mtx @ nvidia_os.c:777
 2nd os.lock_mtx @ nvidia_os.c:777
stack backtrace:
#0 0x80a6a0d0 at witness_debugger+0x70
#1 0x80a69fc4 at witness_checkorder+0xe54
#2 0x809ec894 at __mtx_lock_flags+0xa4
#3 0x8261653b at os_acquire_spinlock+0x1b
#4 0x823bacc5 at _nv012401rm+0xd75


and from /var/log/messages I see:
...
May 30 11:29:31 g1-252 kernel: iwn0: iwn_read_firmware: ucode rev=0x08530501
May 30 11:29:31 g1-252 kernel: wlan0: link state changed to UP
May 30 11:29:31 g1-252 kernel: battery1: battery initialization failed, giving 
up
May 30 11:29:31 g1-252 root: /etc/rc: WARNING: Unable to load kernel module 
linux64
May 30 11:29:31 g1-252 kernel: KLD linux64.ko: depends on kernel - not 
available or version mismatch
May 30 11:29:31 g1-252 kernel: linker_load_file: Unsupported file type
May 30 11:29:32 g1-252 dbus[165]: [system] Activating service 
name='org.freedesktop.ConsoleKit' (using servicehelper)
May 30 11:29:32 g1-252 dbus[165]: [system] Activating service 
name='org.freedesktop.PolicyKit1' (using servicehelper)
May 30 11:29:32 g1-252 dbus[165]: [system] Successfully activated service 
'org.freedesktop.PolicyKit1'
May 30 11:29:32 g1-252 dbus[165]: [system] Successfully activated service 
'org.freedesktop.ConsoleKit'
May 30 11:29:32 g1-252 console-kit-daemon[1100]: WARNING: kvm_getenvv failed: 
May 30 11:29:33 g1-252 kernel: KLD rtc.ko: depends on kernel - not available or 
version mismatch
May 30 11:29:33 g1-252 kernel: linker_load_file: Unsupported file type
May 30 11:29:33 g1-252 kernel: lock order reversal:
May 30 11:29:33 g1-252 kernel: 1st 0xfe05c44508e0 bufwait (bufwait) @ 
/usr/src/sys/ke

Re: Interesting error during installworld

[David Wolfskill]

On Sun, May 22, 2016 at 04:02:43PM -0700, Conrad Meyer wrote:
> FreeBSD has tail(1).  Does HardenedBSD remove it?  Or is /usr/bin
> missing from your PATH?
> 

I noticed this with a straight vanilla FreeBSD build/install, but
have been busy with "other things" today.

It appears to me that the issue is that certain inistallation tools
(ITOOLS) are installed in a temporary directory -- see ca. lines 860 -
870 of head's src/Makefile.inc1 -- and "tail" hasn't been defined as one
of the required "installation tools."

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[David Wolfskill]

On Mon, May 09, 2016 at 12:43:42PM -0700, John Baldwin wrote:
> ...
> > I suppose there's probably some way to arrange things so the KERNCONF
> > specification in /etc/src.conf has one value during "buildkernel" and a
> > different value during "inistallkernel" -- but ... seriously...??!?
> 
> One could do some ugly things with .make() to change the default based on
> the target being invoked (kind of like folks storing port options in
> /etc/make.conf conditional on the current directory), but that would be
> hackish.

Right; "hackish" is probably a bit ... kinder than what came to mind.  :-}

> > Wouldn't it be cleaner to have different variables (e.g., that could
> > each default to the KERNCONF specification, but could be overridden in
> > a simple text file that doesn't require delving into make(1) arcana to
> > craft or understand)?
> 
> I think having separate variables is fine, and I think your suggestion of
> KERNCONF_BUILD and KERNCONF_INSTALL that default to KERNCONF would be
> fine.  From the thread, I think it would mean you would need to use the
> two settings in your /etc/src.conf but that other folks wanting to install
> both would just stick with KERNCONF, correct?

That is my understanding, yes.

I don't mind tweaking things a bit for an uncommon case; I'd rather
avoid twisting my mind into a pretzel to do something that's been quite
easy historically. :-)

> ...
> > Would that work?  It seems as if that would work for my case.
> 
> Yes.  I think that is also simpler than having a new WITH/WITHOUT variable
> to control how installkernel treats KERNCONF.
> 

Yay...!  :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[David Wolfskill]

On Mon, May 09, 2016 at 11:05:55AM -0700, John Baldwin wrote:
> On Saturday, May 07, 2016 06:50:05 AM David Wolfskill wrote:
> > [Recipient list trimmed a bit -- dhw]
> ... 
> > > 2 kernels get installed? Even if the old behaviour was to only install 1
> > > kernel, if you are listing 2 kernels in KERNCONF presumably that is 
> > > because
> > > you want to install 2 kernels?
> > 
> > Errr... no: I don't.  At least, not on the machine where I built them.
> 
> Then don't pass them to 'installkernel'?  That is, I think this makes sense
> if you want to build N kernels but only install 1:
> 
> make buildkernel KERNCONF="FOO BAR BAZ"
> 
> # only install the FOO kernel
> 
> make installkernel KERNCONF="FOO"
> 
> And then if you want to install multiple:
> 
> # install both FOO and BAR kernels
> 
> make installkernel KERNCONF="FOO BAR"

I suppose there's probably some way to arrange things so the KERNCONF
specification in /etc/src.conf has one value during "buildkernel" and a
different value during "inistallkernel" -- but ... seriously...??!?

Wouldn't it be cleaner to have different variables (e.g., that could
each default to the KERNCONF specification, but could be overridden in
a simple text file that doesn't require delving into make(1) arcana to
craft or understand)?

Why make things harder for folks who are trying to use the system?

> The runaround seems to be whether this last case now should require multiple
> explicit installkernel invocations which I find inconsistent since the build
> stage doesn't.  I would fully expect 'installkernel' to install all of the
> kernels listed in KERNCONF and would assume that it is up to the invoker to
> choose KERNCONF appropriately.
> 

Multiple installkernel invocations is certainly not something I would
advocate -- I do silly things sometimes, but I hope nothing I wrote was
interpreted thus. :-}

Suppose that src/Makefile.inc1 were modified so that:
* KERNCONF_BUILD is set to the value (explicit or otherwise) of KERNCONF
  unless it already has a value (in which case, the explicit value is
  used).
* KERNCONF_INSTALL is set to the value (explicit or otherwise) of KERNCONF
  unless it already has a value (in which case, the explicit value is
  used).

buildkernel then builds the kernel configs listed in KERNCONF_BUILD;
installkernel then installs the kernels listed in KERNCONF_INSTALL.

Folks who want to build & install the same set of kernels see no change.

Folks who want a difference between "buildkernel" and "installkernel" have
a simple way to specify it.

Only 1 invocation of installkernel is needed in any case.

Would that work?  It seems as if that would work for my case.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[David Wolfskill]

[Recipient list trimmed a bit -- dhw]

I'm speaking up here because IIRC, I whined to Gleb at what I perceived
to be a POLA violation a while back

On Sat, May 07, 2016 at 09:59:06AM +0200, Ben Woods wrote:
> On 7 May 2016 at 09:48, Ngie Cooper (yaneurabeya) 
> wrote:
> 
> > glebius changed the defaults to fix POLA, but the naming per the behavior
> > is confusing. Right now the behavior between ^/head and ^/stable/10
> > before/now match -- I just had to wrap my mind around the default being the
> > affirmative of a negative (i.e. only install one kernel, as opposed to
> > install all extra kernels by default).
> > -Ngie
> 
> 
> Indeed, I am not sure I understand the POLA violation entirely (ignoring
> the fact that this variable requires affirmation of a negative).
> 
> If you list 2 kernels in the KERNCONF variable, why is it astonishing that
> 2 kernels get installed? Even if the old behaviour was to only install 1
> kernel, if you are listing 2 kernels in KERNCONF presumably that is because
> you want to install 2 kernels?

Errr... no: I don't.  At least, not on the machine where I built them.

The process I've been using (with "variations on the theme" over the
years) since around 1999 or so for updating my "production" machines at
home is described in some detail at
; in summary, the
production machines (only) mount /usr/src & /usr/obj from a dedicated
"build machine" via NFS during the "upgrade window," during which time
the production machine's kernel & userland are installed (from the build
machine, which had built them).

The build machine does all of the compilation; each production machine
merely does installation.

There is no value in "installing" the production machine kernels on the
build machine -- and I never configured the build machine with the
expectation that the root filesystem would ever need to be big enough to
store kernels that would never be loaded on that machine.

Fundamentally, just as we separate "build{world,kernel}" targets from
"install{world,kernel}" targets, it is appopriate to separate -- and not
conflate -- building of a kernel on a machine from installing that kernel
on that machine.

Keeping them separate allows folks who want to do both on a machine to
do so, and it doesn't break those of us who want to do something else.

Now, I don't do this using head -- presently, it's stable/10.  And
when 11 is branched, I expect to start telling the build machine
to build not only its own (GENERIC) stable/11 kernel, but also the
role-specific stable/11 kernels for the production machines.  When
that happens, I (still) won't want to be installing those kernels
on the build machine.  (And my first experiments with installing
those kernels will be on a separate "test" machine that is configured
to be nearly isomorphic to one of the production machines.)

> Regardless, perhaps it is ok to leave behaviour on stable 9/10 unchanged,
> but to make the behaviour on head to install multiple kernels by default?
> That is the option that makes sense for PkgBase (build multiple kernel
> packages if more than one are listed in KERNCONF).

I'm not too fussed about the implementation or the default, as long as I
can set things up to preserve the distinction between the "build" and
"production" roles -- where the production machines don't have their own
(locally-mounted) src or obj, and don't do builds, while the build
machine doesn't install kernels that only run on other machines.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Panic after update from r297313 -> r297348

[David Wolfskill]

On Mon, Mar 28, 2016 at 03:57:01PM +0300, Konstantin Belousov wrote:
> ...
> Also, does anything change with the faulting kernel if you set
> hw.lapic_tsc_deadline to 0 in loader ?

Yes: the machine then boots succesfully:

freebeast(11.0-C)[1] uname -a
FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #2029  
r297348M/297348:1100104: Mon Mar 28 04:55:00 PDT 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
freebeast(11.0-C)[2] 


This was after appending the line:

hw.lapic_tsc_deadline="0"

to /boot/loader.conf.

(I have not -- yet, at least -- tried that with my laptop.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Panic after update from r297313 -> r297348

[David Wolfskill]

Unfortunately, the serial console only seemed to be echoing characters
in quasi-random spurts, yielding such things as:

...
r() at lcpu_initcpu_initclocks_bsp+0x37f/frame 0x820dbb40
initclocks() at initclocks+0x20/frame 0x820dbb50
mi_start+0x2c

Tracing  td 0xffc_et_start+0x2d9/frame 0x820dbaa0
loadtimer() at lrame 0xf configtsp() at clocks_bsp+0x37f/frame 
0x820dbb40
initclocks() at initclocks+0x20/
Tracing pid 0 tid 10 td 0x81d11200
lapic_et_start()c_et_start+0x2d9/frame 0x820dbaa0
+0x2cimeoadtimer+0x102/frame 0xf20dbac0
db> 
pid 0 tid 10 td 0x81d11200
lapic_et_start() at lapic_et_start+0x2d9x820dbaa0
loadtimer() at loadtimer+0x102/frame 0x8imer+0x239/frame 
0x820dbb10
cpu_initsp() at f820dbb7pid 0 ti td 0x81_start()c_et_staf820dbaa0
r() at loadtimer+0x102/8
configtimer() atcpu_initxfffpid 0 
tif820dbaa0| |___ _ __ ___  ___ | |_) | (___ | |  |   ___| '__/ _ \/ _ \|  _ < 
\___ \| |  | |dtimer() at loadtimer+0x102/frame 0x8 0x820dbb10
c| |   | | |  __/  __/| |_) |) | |__| |
b| |   | |  \___|\|200
configtimer() at configtimer+0x239/frame 0x820dbb10
cpu_initclocks_bcpu_initsp+0x37f/frame 0f820dbb40
initclocks() at initclocks+0x20/frame 0x820dbb50
mi_startup() at mi_startup+0x118/frame 0
Tracing d 10lapic_et_start() at lapic_et_start+0x2d9sp+0x37f+0x2c
db> 0
 0x820dbsp+0x37ff820dbb4ks() at 
mi_startup() at up+0x118/frame 0x820dbb70
btext() at btext+0x2c
db> bd 10+0x102/frame 0xfcpu_initframe 0x+0x2c
pic[K]ernel (1 of 2)
r|m 6.bConfigure Boot [O]ptions...
 H| vpanic+0x182/frame 0x820db4a0+
db_commaf0.-- 
sp+0x37f0/frame 0x820db6kdb_trapf820d.---..__   
   _ _   | |  _ \ / |  __ \ 
bte   
Uptime: 1s 
-c0+0x4db8+0x15eef8+0x8+0x]+-y+:.  `:`


at which point I had already (semi-blindly) tried "panic", so I
tried "reset", then I was able to escape to the loader, unload the
new kernel, boot the previous one, move the various kernel*
difrectories around in /boot, then reboot again to old kernel:

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #2028  
r297313M/297313:1100104: Sun Mar 27 06:27:24 PDT 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

I'm still building on my laptop; while I hope I don't have the character-
dropping issues there (as I have no serial console on it), I also don't
have much of a way to communicate what it displays if it (also) panics.

Apparently my attempt at "panic" didn't get a crash dump.. :-(

Any suggestions for diagnosing this?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Possible race condition noted r295622 -> r295654

[David Wolfskill]

Given some of the reports of problems building head recently, my initial
attempts this morning (upgrading head/amd64) in place from r295622 to
r295654) were "clean" builds.

My "build machine" reported no trouble (using -j16).

On my laptop, also using -j16, the process terminated prematurely, with
whines about inability to find libopythagoras.

In a half-hearted attempt, I then immediately attempted an "unclean"
build ("make -j 16 --DNO_CLEAN buildworld"); unsurprisingly, that
failed.

On a bit of a whim, I then tried "make -j14 buildworld" -- that
succeeeded.

I've placed a typescript of all  of those efforts in
 -- ref "bw.txt" (or
"bw.txt.gz"), in case that's of interest or use.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: head/amd64 @r294411: panic: Assertion tty_gone(tp) failed at /usr/src/sys/sys/ttydevsw.h:191

[David Wolfskill]

On Wed, Jan 20, 2016 at 02:40:29PM +0100, Hans Petter Selasky wrote:
> 
> > /etc/src.conf includes 'WITH_FAST_DEPEND=1', and world & kernel were built
> > in-place while the system had been running @r294319, using -DNO_CLEAN.
> >
> > I can probably get a crash dump; if so, I can make it available.  I am
> > also willing to poke at the debugger via serial console, given guidance.
> >
> 
> Can you "svn up" ?
> 
> https://svnweb.freebsd.org/changeset/base/294414
> 

I just hand-applied r294414, then re-built/installed the kernel; no
panic:

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1967  
r294411M/294411:1100095: Wed Jan 20 05:51:33 PST 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64


Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

head/amd64 @r294411: panic: Assertion tty_gone(tp) failed at /usr/src/sys/sys/ttydevsw.h:191

[David Wolfskill]

This is on my build machine (laptop is still building its kernel), so
kernel here is GENERIC.  Copy/paste from serial console:

panic: Assertion tty_gone(tp) failed at /usr/src/sys/sys/ttydevsw.h:191
cpuid = 7
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe085de54430
vpanic() at vpanic+0x182/frame 0xfe085de544b0
kassert_panic() at kassert_panic+0x126/frame 0xfe085de54520
tty_drain() at tty_drain+0x80/frame 0xfe085de54560
ttydev_leave() at ttydev_leave+0x8d/frame 0xfe085de54580
ttydev_close() at ttydev_close+0xaf/frame 0xfe085de545a0
devfs_close() at devfs_close+0x223/frame 0xfe085de54610
VOP_CLOSE_APV() at VOP_CLOSE_APV+0xf1/frame 0xfe085de54640
vn_close() at vn_close+0xcd/frame 0xfe085de546b0
vn_closefile() at vn_closefile+0x4a/frame 0xfe085de54730
devfs_close_f() at devfs_close_f+0x2c/frame 0xfe085de54760
_fdrop() at _fdrop+0x1a/frame 0xfe085de54780
closef() at closef+0x1e1/frame 0xfe085de54810
fdescfree_fds() at fdescfree_fds+0x9d/frame 0xfe085de54850
fdescfree() at fdescfree+0x46c/frame 0xfe085de54910
exit1() at exit1+0x4e6/frame 0xfe085de54990
ys_sys_exit() at sys_sys_exit+0xd/frame 0xfe085de549a0
amd64_syscall() at amd64_syscall+0x2db/frame 0xfe085de54ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe085de54ab0
--- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x80090801a, rsp = 
0x7fffc248, rbp = 0x7fffc260 ---
KDB: enter: panic
[ thread pid 305 tid 100103 ]
Stopped at  kdb_enter+0x3b: movq$0,kdb_why
db> 


/etc/src.conf includes 'WITH_FAST_DEPEND=1', and world & kernel were built
in-place while the system had been running @r294319, using -DNO_CLEAN.

I can probably get a crash dump; if so, I can make it available.  I am
also willing to poke at the debugger via serial console, given guidance.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: libcrypto.so.7 not found, needed (?) for X server

[David Wolfskill]

On Tue, Jan 19, 2016 at 12:44:16PM +, Thomas Mueller wrote:
> I just updated FreeBSD-current to r294248, and can no longer startx.
> 
> Error message is
> 
> xauth:  file /home/arlene/.serverauth.1177 does not exist
> 
> Shared object "libcrypto.so.7" not found, required by "X"
> xinit: giving up
> xinit: unable to connect to X server: Connection refused
> xinit: server error
> 
> There is /usr/lib/libcrypto.so but notlibcrypto.so.7.
> 

On my laptop, in the "head" environment, I have:

g1-252(10.3-P)[1] cd /S4
g1-252(10.3-P)[2] ls -ltrT usr/lib/libcrypto*
-r--r--r--  1 root  wheel  4281880 Dec 28 05:50:18 2015 usr/lib/libcrypto.a
-r--r--r--  1 root  wheel  4531590 Dec 28 05:50:18 2015 usr/lib/libcrypto_p.a
lrwxr-xr-x  1 root  wheel   24 Jan 19 05:02:24 2016 usr/lib/libcrypto.so -> 
../../lib/libcrypto.so.8
g1-252(10.3-P)[3] 

But I normally run -- and biuld my ports  -- in a stable/10 environment,
so:

g1-252(10.3-P)[1] ldd `which X` | grep crypto
libcrypto.so.7 => /lib/libcrypto.so.7 (0x800c84000)
g1-252(10.3-P)[2] ls -ltrT /lib/libcrypto*
-r--r--r--  1 root  wheel  2039072 Jan 19 04:28:19 2016 /lib/libcrypto.so.7
g1-252(10.3-P)[3] ls -ltrT /usr/lib/libcrypto*
-r--r--r--  1 root  wheel  3927330 Dec  4 04:36:08 2015 /usr/lib/libcrypto.a
-r--r--r--  1 root  wheel  4158890 Dec  4 04:36:08 2015 /usr/lib/libcrypto_p.a
lrwxr-xr-x  1 root  wheel   19 Jan 19 04:28:19 2016 /usr/lib/libcrypto.so 
-> /lib/libcrypto.so.7
g1-252(10.3-P)[4] 

Finally, something that you may find useful in all this nattering:

g1-252(10.3-P)[4] pkg which /usr/local/lib/compat/libcrypto.so.7 
/usr/local/lib/compat/libcrypto.so.7 was installed by package 
compat10x-amd64-10.2.1002000.20151116
g1-252(10.3-P)[5] pkg info -o compat10x-amd64-10.2.1002000.20151116
compat10x-amd64-10.2.1002000.20151116 misc/compat10x
g1-252(10.3-P)[6] 

That is, it looks as if you're trying to run X built under stable/10
while you're running head.  You will almost certainly want to install
misc/compat10x.

Alternatively, delete & re-build/install all ports/packages under head.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Inconsistent -DNO_CLEAN build failure r293913 -> r294086

[David Wolfskill]

On Fri, Jan 15, 2016 at 03:00:00PM -0800, Bryan Drewery wrote:
> ...
>  World build started on Fri Jan 15 04:28:48 PST 2016
> > ...
>  stage 5.1: building 32 bit shim libraries
> > ...
> > --- lib/libldns__L ---
> > --- libprivateldns.so.5 ---
> > /usr/obj/usr/src/tmp/usr/bin/ld: skipping incompatible 
> > /usr/obj/usr/src/tmp/usr/lib/libgcc_s.so when searching for -lgcc_s
> 
> This is odd...

Agreed; that's largely why I posted.  Well, that, and the apparently lack
of consistent behavior between the 2 machines.

> > --- secure/lib/libssl__L ---
> > --- libssl.a ---
> > --- kerberos5/lib/libhx509__L ---
> > --- keyset.po ---
> > --- secure/lib/libssl__L ---
> > building static ssl library
> > --- lib/libldns__L ---
> > /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s
> 
> By this point (lib/libldns__L) libgcc should be built and installed. I
> assume it says 'cannot find' since it is incompatible.

Apparently, yes.

> I don't think this is a build race or FAST_DEPEND issue.
> 
> It could be a -DNO_CLEAN issue. Nothing is standing out as an issue in
> the commit range given, except if you were building for arm.

In each case, it was a native build on amd64.

> ...
> > cc: error: linker command failed with exit code 1 (use -v to see invocation)
> > *** [libprivateldns.so.5] Error code 1
> > 
> > make[4]: stopped in /usr/src/lib/libldns
> > 
> > 
> > from which that process didn't recover at all well... though a
> > re-start without "-DNO_CLEAN" completed successfully.
> ...
> > One other (possibly-salient) point is that the build machine's disk
> > drive is an SSD.  (And yes, that does tend to help make it faster.)
> 

Well, I suppose I'll take some small comfort in knowing that I'm not the
only one perplexed by the behavior. :-}

Thanks for looking at it.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: r294070: KLD nvidia-modeset.ko: depends on kernel - not available or version mismatch linker_load_file: Unsupported file type

[David Wolfskill]

On Fri, Jan 15, 2016 at 07:19:43PM +0100, O. Hartmann wrote:
> On FreeBSD 11.0-CURRENT #1 r294070: Fri Jan 15 06:21:20 CET 2016 amd64,
> loading nvidia kernel module results in the error:
> 
> KLD nvidia-modeset.ko: depends on kernel - not available or version
> mismatch linker_load_file: Unsupported file type
> 
> This worked prior to r294070
> 

My most recent build of head was at r294086; I didn't see a problem with
nvidia -- but I have 'PORTS_MODULES=x11/nvidia-driver' in /etc/src.conf,
so it's rebuilt every time I rebuild the kernel.

Have you rebuilt nvidia-driver recently?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Inconsistent -DNO_CLEAN build failure r293913 -> r294086

[David Wolfskill]

OK, first: I realize that using "-DNO_CLEAN" is treading on somewhat
unstable ground.  I'm testing; the results I obtained this morning were
a bit unexpected, so I'm reporting them in case said results might be
of use or interest to others.

As indicated in the Subject, I started a couple of machines (a dedicated
"build machine" and my laptop) at r293913, updated source to r294086,
then proceeded to perform "make -j16 -DNO_CLEAN buildworld" on each.

Please note that in each case, I have "WITH_FAST_DEPEND=1" in
/etc/src.conf.

The laptop chugged along and completed normally; the build machine
encountered:

>>> World build started on Fri Jan 15 04:28:48 PST 2016
...
>>> stage 5.1: building 32 bit shim libraries
...
--- lib/libldns__L ---
--- libprivateldns.so.5 ---
/usr/obj/usr/src/tmp/usr/bin/ld: skipping incompatible 
/usr/obj/usr/src/tmp/usr/lib/libgcc_s.so when searching for -lgcc_s
--- secure/lib/libssl__L ---
--- libssl.a ---
--- kerberos5/lib/libhx509__L ---
--- keyset.po ---
--- secure/lib/libssl__L ---
building static ssl library
--- lib/libldns__L ---
/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lgcc_s
--- secure/lib/libssl__L ---
ar -crD libssl.a `NM='nm' NMFLAGS='' lorder bio_ssl.o d1_both.o d1_clnt.o 
d1_lib.o d1_meth.o d1_pkt.o d1_srtp.o d1_srvr.o s23_clnt.o s23_lib.o s23_meth.o 
s23_pkt.o s23_srvr.o s3_both.o s3_cbc.o s3_clnt.o s3_enc.o s3_lib.o s3_meth.o 
s3_pkt.o s3_srvr.o ssl_algs.o ssl_asn1.o ssl_cert.o ssl_ciph.o ssl_conf.o 
ssl_err.o ssl_err2.o ssl_lib.o ssl_rsa.o ssl_sess.o ssl_stat.o ssl_txt.o 
t1_clnt.o t1_enc.o t1_ext.o t1_lib.o t1_meth.o t1_reneg.o t1_srvr.o tls_srp.o  
| tsort -q` 
--- lib/libldns__L ---
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [libprivateldns.so.5] Error code 1

make[4]: stopped in /usr/src/lib/libldns


from which that process didn't recover at all well... though a
re-start without "-DNO_CLEAN" completed successfully.

Here are the relevant "uname -a" outputs:

FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #305  
r293913M/293913:1100093: Thu Jan 14 04:55:39 PST 2016 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #306  
r294086M/294086:1100094: Fri Jan 15 05:03:24 PST 2016 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64


FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1961  
r293913M/293913:1100093: Thu Jan 14 04:49:29 PST 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1962  
r294086M/294086:1100094: Fri Jan 15 05:33:30 PST 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64


One other (possibly-salient) point is that the build machine's disk
drive is an SSD.  (And yes, that does tend to help make it faster.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: panic: sbappendstream 1 [head/amd64 @r293419]

[David Wolfskill]

On Fri, Jan 08, 2016 at 06:33:40AM -0800, David Wolfskill wrote:
> ...
> > panic: sbappendstream 1
> > 
> 
> flo@ suggested reverting r293405; after doing that & rebuilding the
> kernel, the build machine boots to multi-user mode and I'm able to
> login:
> 
> FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1955  
> r293419M/293420:1100093: Fri Jan  8 06:26:38 PST 2016 
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
> 
> I'll try that for my laptop, as well.

That seems to have worked for thhe laptop, as well:

FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #299  
r293419M/293420:1100093: Fri Jan  8 06:44:01 PST 2016 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: panic: sbappendstream 1 [head/amd64 @r293419]

[David Wolfskill]

On Fri, Jan 08, 2016 at 06:05:18AM -0800, David Wolfskill wrote:
> After the first panic, I rebuilt the kernel without -DNO_CLEAN; the
> crash dump & other diagnostic info is from the clean build.
> 
> January  8, 2016 at 05:57:27 AM PST
> 
> FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1954  
> r293419M/293420:1100093: Fri Jan  8 05:09:57 PST 2016 
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
> 
> panic: sbappendstream 1
> 

flo@ suggested reverting r293405; after doing that & rebuilding the
kernel, the build machine boots to multi-user mode and I'm able to
login:

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1955  
r293419M/293420:1100093: Fri Jan  8 06:26:38 PST 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

I'll try that for my laptop, as well.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

panic: sbappendstream 1 [head/amd64 @r293419]

[David Wolfskill]

After the first panic, I rebuilt the kernel without -DNO_CLEAN; the
crash dump & other diagnostic info is from the clean build.

January  8, 2016 at 05:57:27 AM PST

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1954  
r293419M/293420:1100093: Fri Jan  8 05:09:57 PST 2016 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

panic: sbappendstream 1

...
Unread portion of the kernel message buffer:
panic: sbappendstream 1
cpuid = 7
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe085e0595b0
vpanic() at vpanic+0x182/frame 0xfe085e059630
kassert_panic() at kassert_panic+0x126/frame 0xfe085e0596a0
sbappendstream_locked() at sbappendstream_locked+0xa5/frame 0xfe085e0596d0
uipc_send() at uipc_send+0x942/frame 0xfe085e059780
sosend_generic() at sosend_generic+0x42f/frame 0xfe085e059840
kern_sendit() at kern_sendit+0x21b/frame 0xfe085e0598f0
sendit() at sendit+0x126/frame 0xfe085e059940
sys_sendmsg() at sys_sendmsg+0x61/frame 0xfe085e0599a0
amd64_syscall() at amd64_syscall+0x2db/frame 0xfe085e059ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe085e059ab0
--- syscall (28, FreeBSD ELF64, sys_sendmsg), rip = 0x801270dfa, rsp = 
0x7fffa098, rbp = 0x7fffa0d0 ---
KDB: enter: panic
...
Loaded symbols for /boot/kernel/autofs.ko
#0  doadump (textdump=0) at pcpu.h:221
221 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0  doadump (textdump=0) at pcpu.h:221
#1  0x8038205b in db_dump (dummy=, dummy2=false, 
dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533
#2  0x80381e4e in db_command (cmd_table=0x0)
at /usr/src/sys/ddb/db_command.c:440
#3  0x80381be4 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:493
#4  0x8038467b in db_trap (type=, code=0)
at /usr/src/sys/ddb/db_main.c:251
#5  0x80a5cfe3 in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:654
#6  0x80e6a2a8 in trap (frame=0xfe085e0594e0)
at /usr/src/sys/amd64/amd64/trap.c:549
#7  0x80e4a317 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:234
#8  0x80a5c6cb in kdb_enter (why=0x8137af3c "panic", 
msg=0x80 ) at cpufunc.h:63
#9  0x80a1fb8f in vpanic (fmt=, 
ap=) at /usr/src/sys/kern/kern_shutdown.c:750
#10 0x80a1f9e6 in kassert_panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:647
#11 0x80aa3375 in sbappendstream_locked (sb=0xf80044212378, 
m=0xf800108c7200, flags=0) at /usr/src/sys/kern/uipc_sockbuf.c:642
#12 0x80ab1a42 in uipc_send (so=0xf80044212000, flags=0, 
m=, nam=0x0, control=, 
td=0xf8001078e9a0) at /usr/src/sys/kern/uipc_usrreq.c:984
#13 0x80aa5f5f in sosend_generic (so=0xf80044212000, addr=0x0, 
uio=0xfe085e059890, top=, 
control=, flags=, 
td=0xfe085e059880) at /usr/src/sys/kern/uipc_socket.c:1349
#14 0x80aac36b in kern_sendit (td=0xf8001078e9a0, s=6, 
mp=, flags=0, control=0x0, segflg=UIO_USERSPACE)
at /usr/src/sys/kern/uipc_syscalls.c:906
#15 0x80aac666 in sendit (td=0xf8001078e9a0, 
s=, mp=0xfe085e059958, flags=0)
at /usr/src/sys/kern/uipc_syscalls.c:833
#16 0x80aac6f1 in sys_sendmsg (td=0xf8001078e9a0, 
uap=0xfe085e059a40) at /usr/src/sys/kern/uipc_syscalls.c:1035
#17 0x80e6b13b in amd64_syscall (td=0xf8001078e9a0, traced=0)
at subr_syscall.c:135
#18 0x80e4a5fb in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:394
#19 0x000801270dfa in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal
(kgdb) 
.

As indicated above, this is with a GENERIC kernel.  My laptop (running
a kernel built with the same sources, but a slightly customized kernel
config) gets to the point of allowing me to login (via xdm), but when I
fire off a command that creates xterms & tries to run tmux(1) in them,
locks up (as far as I can tell), and a power-cycle is needed to recover.

I can poke at the crash dump (given hints), make the dump and core.txt file
available.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: r 293304: BROKEN: buildkernel fails due to error: error: no member named 't_maxopd' in 'struct tcpcb'

[David Wolfskill]

On Thu, Jan 07, 2016 at 06:31:11AM +0100, O. Hartmann wrote:
> Recent r293304 fails to build kernel due to the error below:
> 
> [...]
> --- kern_testfrwk.o ---
> cc  -O2 -pipe -O3 -O3 -pipe -march=native  -fno-strict-aliasing -Werror
> -D_KERNEL -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS
> -include /usr/obj/usr/src/sys/FREYJA/opt_global.h -I. -I/usr/src/sys
> -fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
> -I/usr/obj/usr/src/sys/FREYJA  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
> -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
> -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
> -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs
> -fdiagnostics-show-option  -Wno-unknown-pragmas
> -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function
> -Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx
> -std=iso9899:1999
> -c 
> /usr/src/sys/modules/tests/framework/../../../tests/framework/kern_testfrwk.c
> -o kern_testfrwk.o --- all_subdir_tcp/fastpath
> --- 
> /usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:481:6:
> error: no member named 't_maxopd' in 'struct tcpcb' if (DELAY_ACK(tp, tlen))
> { ^
> ~~ 
> /usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:167:19:
> note: expanded from macro 'DELAY_ACK' (tlen <= tp->t_maxopd)
> &&   \
> ^ 
> /usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:606:8:
> error: no member named 't_maxopd' in 'struct tcpcb' if (DELAY_ACK(tp, tlen) &&
> tlen != 0) ^
> ~~ 
> /usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:167:19:
> note: expanded from macro 'DELAY_ACK' (tlen <= tp->t_maxopd)
> &&   \ ^ --- sctp_indata.o --- ctfconvert -L
> VERSION sctp_indata.o ERROR: ctfconvert: sctp_indata.o doesn't have type data
> to convert --- modules-all --- --- all_subdir_sfxge --- --- siena_vpd.o --- cc
> -O2 -pipe -O3 -O3 -pipe -march=native  -fno-strict-aliasing -Werror -D_KERNEL
> -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS
> -include /usr/obj/usr/src/sys/FREYJA/opt_global.h -I. -I/usr/src/sys
> -fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
> -I/usr/obj/usr/src/sys/FREYJA  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
> -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
> -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
> -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs
> -fdiagnostics-show-option  -Wno-unknown-pragmas
> -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function
> -Wno-error-pointer-sign -Wno-error-shift-negative-value  -mno-aes -mno-avx
> -std=iso9899:1999
> -c /usr/src/sys/modules/sfxge/../../dev/sfxge/common/siena_vpd.c -o 
> siena_vpd.o
> --- all_subdir_tcp/fastpath
> --- 
> /usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:1545:8:
> error: no member named 't_maxopd' in 'struct tcpcb' if (DELAY_ACK(tp, tlen))
> ^
> ~~ 
> /usr/src/sys/modules/tcp/fastpath/../../../netinet/tcp_stacks/fastpath.c:167:19:
> note: expanded from macro 'DELAY_ACK' (tlen <= tp->t_maxopd)
> &&   \ ^ 3 errors generated. *** [fastpath.o]
> Error code 1
> 
> make[4]: stopped in /usr/src/sys/modules/tcp/fastpath
> 1 error
> 
> make[4]: stopped in /usr/src/sys/modules/tcp/fastpath
> *** [all_subdir_tcp/fastpath] Error code 2
> 
> make[3]: stopped in /usr/src/sys/modules
> --- all_subdir_sfxge ---
> --- siena_sram.o ---
> ctfconvert -L VERSION siena_sram.o
> ERROR: ctfconvert: siena_sram.o doesn't have type data to convert
> --- all_subdir_tests/callout_test ---
> ctfconvert -L VERSION callout_test.o
> ERROR: ctfconvert: callout_test.o doesn't have type data to convert
> A failure has been detected in another branch of the parallel make
> 
> make[4]: stopped in /usr/src/sys/modules/tests/callout_test
> *** [all_subdir_tests/callout_test] Error code 2
> 
> make[3]: stopped in /usr/src/sys/modules
> --- sctp_input.o ---
> ctfconvert -L VERSION sctp_input.o
> ___
> 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"

The attached patch gets through the buildkernel.  After install &
reboot, I'm not seeing obvious issues -- I can still talk to the box
over TCP, at least.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catw

Re: Panic in ld_ldt() @r292914 (amd64) -- just after launching CPUs

[David Wolfskill]

On Wed, Dec 30, 2015 at 04:25:28PM +0200, Konstantin Belousov wrote:
> On Wed, Dec 30, 2015 at 05:54:07AM -0800, David Wolfskill wrote:
> > Found this on both my build machine and my laptop, each of which just
> > built head @r292914 (while running r292864 during the build) -- e.g.:
> > 
> > FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #287  
> > r292864M/292864:1100092: Tue Dec 29 05:01:42 PST 2015 
> > r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64
> > 
> > Unfortunately, the panic occurs early enough that I can't get a crash
> > dump (I'm don't think the swap device has yet been discovered), and
> > serial console isn't working for my build machine.
> ...
> 
> Try clean build first.  struct proc layout was changed recently, and the
> instruction at ld_ldt would fault if using the wrong offsets.
> 

OK; thanks -- that works:

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1944  
r292914M/292914:1100092: Wed Dec 30 06:51:53 PST 2015 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #289  
r292914M/292914:1100092: Wed Dec 30 06:50:13 PST 2015 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Panic in ld_ldt() @r292914 (amd64) -- just after launching CPUs

[David Wolfskill]

Found this on both my build machine and my laptop, each of which just
built head @r292914 (while running r292864 during the build) -- e.g.:

FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #287  
r292864M/292864:1100092: Tue Dec 29 05:01:42 PST 2015 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

Unfortunately, the panic occurs early enough that I can't get a crash
dump (I'm don't think the swap device has yet been discovered), and
serial console isn't working for my build machine.

I took some screen shots of the laptop, but I don't seem to be able
to connect the phone to the laptop in a way to allow data interchange,
so I'll try to hand-transcribe the more obviously-relevant bits:

...
SMP: AP CPU #5 Launched!
kernel trap 9 with interrupts disabled

Fatal trap 9: general protection fault while in kernel mode
cpuid = 6; apic id = 86
instruction pointer = 0x28:0x80d9b505
stack pointer   = 0x28:0xfe06015ca8f0
frame pointer   = 0x28:0xfe06015ca950
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 11 (idle: cpu6)
[ thread pid 11 tid 100010 ]
Stopped at  0x80d9b505 = ld_ldt:lldt%ax
db> bt
Tracing pid 11 tid 100010 td 0xf800067f69a0
ld_ldt() at 0x80d9b505 = ld_ldt/frame 0xfe06015ca900
sched_switch() at 0x80a176c5 = sched_switch+0x495/frame 
0xfe06015ca950
mi_switch() at 0x809f8759 = mi_switch+0x169/frame 0xfe06015ca980
sched_idletd() at 0x80a1a211 = sched_idletd+0x391/frame 
0xfe06015caa70
fork_exit() at 0x809b5324 = fork_exit+0x84/frame 0xfe06015aab0
fork_trampoline() at 0x80d9eade = fork_trampoline+0xe/frame 
0xfe06015caab0
--- trap 0, rip = 0, rsp = 0, rpb = 0 ---
db> 

I'm happy to try testing, but as I actually use the laptop for
day-to-day activities, I'm likely to need to do some priority-shifting.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: No X on Dell E6540

[David Wolfskill]

On Tue, Dec 15, 2015 at 12:57:00PM +0100, Carsten Kunze wrote:
> Hello,
> 
> X does not start.  For the error message I get (Number of created screens 
> does not match number of detected devices) there are many posts on 
> https://forums.freebsd.org but this URL seems to not work currently.  Xorg 
> log is (for dmesg see below):
> 

I had a similar issue with my Dell M4800 until I entered BIOS
configuration (vi F12 key at boot), selected "Video," then disabled
"Switchable Graphics."

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Best way to update FreeBSD 11 ?

[David Wolfskill]

On Wed, Dec 02, 2015 at 02:39:24PM -0700, Sergey Manucharian wrote:
> Hello,
> 
> What is the best way to update FreeBSD 11-CURRENT?
> Initially I've installed it from an image from [0] a couple of months ago.
> ...

That depends on why you are considering the update.

For me, I do in-place source updates "fairly" often (ref. src/UPDATING).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

[Resolved]: Panic: GPF in kernel mode in fork_exit() (prior to FS mouont)

[David Wolfskill]

On Mon, Nov 23, 2015 at 03:33:17PM +0200, Konstantin Belousov wrote:
> ...
> > I'm happy to test possible fixes.
> 
> The source line which paniced is kern_fork.c:1025, according to the kgdb
> backtrace.  The corresponding fragment is
> if (p->p_sysent->sv_schedtail != NULL)
> (p->p_sysent->sv_schedtail)(td);
> The revision 291171 changed layout of the dereferenced structure
> sysentvec. Was your kernel build clean, or did you used -DNO_CLEAN or
> similar option ? If yes, remove the kernel build directory and start
> from scratch.

A plain "make kernel" later (without -DNO_CLEAN) on the build machine, and:

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1910  
r291193M/291193:1100090: Mon Nov 23 05:53:43 PST 2015 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

Thanks!  :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Panic: GPF in kernel mode in fork_exit() (prior to FS mouont)

[David Wolfskill]

On Mon, Nov 23, 2015 at 03:33:17PM +0200, Konstantin Belousov wrote:
> ...
> The source line which paniced is kern_fork.c:1025, according to the kgdb
> backtrace.  The corresponding fragment is
> if (p->p_sysent->sv_schedtail != NULL)
> (p->p_sysent->sv_schedtail)(td);
> The revision 291171 changed layout of the dereferenced structure
> sysentvec. Was your kernel build clean, or did you used -DNO_CLEAN or
> similar option ? If yes, remove the kernel build directory and start
> from scratch.

OK.  And yes, I normally use -DNO_CLEAN.  Will do & report back.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Panic: GPF in kernel mode in fork_exit() (prior to FS mouont)

[David Wolfskill]

This was the "smoke test" boot after building:

FreeBSD  11.0-CURRENT FreeBSD 11.0-CURRENT #253  r291193M/291193:1100090: Mon 
Nov 23 04:43:34 PST 2015 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

and (as noted), it happened fairly early in the boot sequence --
before the file systems were mounted, but after the device probes.

It also affected my build machine (same source revision) the same way.

The most recent successful head built & booted on the machine was:

FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #252  
r291159M/291159:1100090: Sun Nov 22 05:16:34 PST 2015 
root@localhost:/common/S4/obj/usr/src/sys/CANARY  amd64


I was able to capture a crash dump (by issuing "panic" at the "db>
" prompt); I've copied the vmcore.8 & core.txt.8 to
.  Here's an excerpt from
the core.txt.8:

...
SMP: passed TSC synchronization test
TSC timecounter discards lower 1 bit(s)
Timecounter "TSC-low" frequency 1396804168 Hz quality 1000
WARNING: WITNESS option enabled, expect reduced performance.
WARNING: DIAGNOSTIC option enabled, expect reduced performance.
Expensive timeout(9) function: 0x808830d0(0x81761898) 
0.004704835 s
battery0: battery initialization done, tried 1 times
GEOM: new disk cd0
GEOM_PART: partition 1 on (diskid/DISK-W200TLZD, MBR) is not aligned on 4096 
bytes
GEOM_PART: partition 2 on (diskid/DISK-W200TLZD, MBR) is not aligned on 4096 
bytes
GEOM_PART: partition 3 on (diskid/DISK-W200TLZD, MBR) is not aligned on 4096 
bytes
start_init: trying /sbin/init


Fatal trap 9: general protection fault while in kernel mode
cpuid = 6; apic id = 06
instruction pointer = 0x20:0x809b049e
stack pointer   = 0x28:0xfe06015a2a70
frame pointer   = 0x28:0xfe06015a2ab0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1 (init)
Uptime: 3s


I'm happy to test possible fixes.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Wake on LAN broken (probably between r290542 - r290606)?

[David Wolfskill]

On Sun, Nov 15, 2015 at 10:57:06PM +0100, Marius Strobl wrote:
> ...
> > I've placed a copy of a verbose dmes.boot in
> > .
> > 
> > I'm happy to test suggested changes.
> > 
> 
> *sigh* Okay, could you please test whether the attached patch restores
> WOL capability for you?
> 

Aye; that worked for me.

I used the slice where I had tested r290566 and r290565 (most recently,
the latter), used "svn update -r290566" to update sources to r290566
first, then used "svn patch" to apply the aptch, then re-built world &
kernel & re-installed kernel & world, then rebooted, then "shutdown -p
now" to power off.

Once serial console reported:

...
re0: link state changed to DOWN
re0: link state changed to UP
acpi0: Powering system off


I used /usr/local/bin/wol on the machine that is supposed to wake the
build machine up, and it powered right up as it did before.

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Wake on LAN broken (probably between r290542 - r290606)?

[David Wolfskill]

On Wed, Nov 11, 2015 at 06:33:37AM -0800, David Wolfskill wrote:
> ...
> But a quick perusal of
> <https://docs.freebsd.org/mail/current/svn-src-head.html> doesn't show
> anything especially like a "smoking gun" -- to me, anyway.
> 
> Can anyone else confirm or refute my observations?  Or suggest a
> hint?  I'll try narrowing it down myself, but I need to do it during
> times I'm at home (so I can manually power the machine back up when
> it fails to respond to WoL), so it may be a few days before I can
> accomplish much that way.
> 

r290565 still works; r290566 fails -- in my case.  r290566 changed some
re(4) behavior, and the NIC on my affected machine is an re(4):

re0@pci0:3:0:0: class=0x02 card=0x05b71028 chip=0x816810ec rev=0x0c
hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet
Controller'
class  = network
subclass   = ethernet

from "pciconf -lv" while running:

D freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1904  
r290565M/290565:1100089: Sat Nov 14 09:44:33 PST 2015 
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC  amd64

I've placed a copy of a verbose dmes.boot in
<http://www.catwhisker.org/~david/FreeBSD/freebeast/>.

I'm happy to test suggested changes.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Wake on LAN broken (probably between r290542 - r290606)?

[David Wolfskill]

On Thu, Nov 12, 2015 at 05:02:27PM -0800, Yuri wrote:
> ...
> Did you confirm (for ex. with Wireshark) that wol actually sends the packet?
> If you are trying to wake the machine that is not booted, this is 
> primarily dependent on the BIOS of the target machine to wake it up.
> In my experience, BIOSes are prone to losing settings, due to low 
> battery, or other (sometimes mysterious) reasons.
> Please confirm that BIOS setting "Wake On LAN" is on on target.
> 

I confirmed it by successfully using the /usr/local/bin/wol program on
the target machine when the latter had last been booted to run FreeBSD
stable/10.

Previously, this worked whether the target machine had been running
stable/10 or head; now it only works if it had been running stable/10 at
the time the "shutdown -p now" command was issued.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Wake on LAN broken (probably between r290542 - r290606)?

[David Wolfskill]

My build machine ("freebeast") spends most of the time powered off.

One of my "always on" machines has a crontab entry for 23:47 to use
/usr/local/bin/wol (from ports/net/wol) to wake it up in time to do some
periodinc "daily" things, update its local mirror of the SVN repos, and
update it ports working copy; after I've updated stable/10 & head on it,
I set it to boot from the stable/10 slice & power it off -- and the
cycle repeats.

At least, that's what happened with this machine's predecessor for
several years, and with this one since its deployment several months
ago, until yesterday morning.

Yesterday morning, the machine did not power on; I figured someone had
managed to manually power it off (vs. "shutdown -p"), took evasive
action, and resumed normal operations.

Upon a recurrence this morning -- and after the evasive action &
resumption of normal operations, I decided to test a bit.  The machine
was last running:

FreeBSD 11.0-CURRENT #1897  r290667M/290668:1100089: Wed Nov 11 04:45:58 PST 
2015 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

I manually ran the /sur/local/bin/wol command... and Nothing Happened.

Went over to the machine; no lights.  Manualy turned it on (booting

FreeBSD 10.2-STABLE #1851  r290668M/290668:1002501: Wed Nov 11 04:20:05 PST 
2015 r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/GENERIC  amd64

-- just to be clear); once it came up, "shutdown -p now".  After seeing

...
acpi0: Powering system off

on serial console, re-issued /usr/local/bin/wol; machine came right up.

OK.  So /usr/local/bin/wol itself seems to be working, and freebeast's
hardware also seems OK.

Checking the log of builds for head on that machine, the last several
entries are:

FreeBSD 11.0-CURRENT #1892  r290439M/290439:1100086: Fri Nov  6 05:12:44 PST 
2015 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
FreeBSD 11.0-CURRENT #1893  r290486M/290488:1100087: Sat Nov  7 07:48:26 PST 
2015 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
FreeBSD 11.0-CURRENT #1894  r290542M/290542:1100089: Sun Nov  8 06:19:02 PST 
2015 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
FreeBSD 11.0-CURRENT #1895  r290606M/290609:1100089: Mon Nov  9 04:44:14 PST 
2015 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
FreeBSD 11.0-CURRENT #1896  r290647M/290647:1100089: Tue Nov 10 04:37:17 PST 
2015 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64
FreeBSD 11.0-CURRENT #1897  r290667M/290668:1100089: Wed Nov 11 04:45:58 PST 
2015 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

and since I'm pretty sure I would have recalled had the "wake on
LAN" failed on Monday (and I don't recall that), it seems likely that
some change made that day (thus, a commit between r290542 - r290606)
is what would have done it.

But a quick perusal of
 doesn't show
anything especially like a "smoking gun" -- to me, anyway.

Can anyone else confirm or refute my observations?  Or suggest a
hint?  I'll try narrowing it down myself, but I need to do it during
times I'm at home (so I can manually power the machine back up when
it fails to respond to WoL), so it may be a few days before I can
accomplish much that way.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: buildworld broken

[David Wolfskill]

On Sun, Nov 08, 2015 at 10:28:17AM -0800, Steve Kargl wrote:
> ...
> Back to trying to build freebsd.  I  have discovered that 
> 'make buildworld' is simply broken if one attempts to use
> a symlink for /usr/obj.  At least doing doing
> 
> % rm -rf /usr/obj
> % ln -s /mnt/obj /usr/obj
> % cd /usr/src
> % nice make -j2 buildworld
> 
> with /mnt a UFS2 file system on a USB2 disk yields errors of the
> above form.

My laptop -- where I build stable/10 & head daily -- is set up so that:

g1-252(10.2-S)[1] ls -lT /usr/obj
lrwxr-xr-x  1 root  wheel  14 Jul 19 06:39:21 2015 /usr/obj -> /common/S1/obj
g1-252(10.2-S)[2] 

In this case, /tmp is tmpfs and all others are UFS2+SU.

> If one does
> 
> % rm -rf /usr/obj
> % setenv OBJDIR /mnt/obj
> % cd /usr/src
> % nice make -j2 buildworld
>  
> works.  So, it appears soemthing inside the make infrastructure cannot
> follow symlinks.  This used to work.

In such cases, my first suspect is (ab)use of realpath.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: IPFW panic on boot

[David Wolfskill]

On Tue, Nov 03, 2015 at 09:08:28PM -0600, Mark Felder wrote:
> Recent ipfw commits now cause my firewall to panic on boot. I had to
> revert them and only pull in Adrian's ath fix which was to fix yet a
> different panic I was encountering... :-)
> 
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe01226a33e0
> vpanic() at vpanic+0x182/frame 0xfe01226a3460
> kassert_panic() at kassert_panic+0x126/frame 0xfe01226a34d0
> ipfw_rewrite_rule_uidx() at ipfw_rewrite_rule_uidx+0x258/frame
> 0xfe01226a356
> 0
> 

Yes; ref. 
et seq.

For me, the problem was with r290334; r290345 fixed it (again, for me).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: panic: refcount inconsistency: found: 0 total: 1

[David Wolfskill]

On Wed, Nov 04, 2015 at 01:23:42AM +0300, Andrey V. Elsukov wrote:
> On 04.11.2015 00:10, David Wolfskill wrote:
> > So... with the change from r290334, what's the point of the KASSERT?
> 
> Yes, you are right. We changed this code and use it some time, but
> without INVARIANTS. I just removed this KASSERT in r290345. Can you try
> this revision? Sorry for the breakage.
> 

OK; I first did "svn revert /usr/src/sys/netpfil/ipfw/", then (having
saved a copy of r290345's commit message as /tmp/r290345), did "svn
patch --strip 1 /tmp/r290345 /usr/src", then built & installed a new
kernel, which booted without a panic:

FreeBSD  11.0-CURRENT FreeBSD 11.0-CURRENT #233  r290334M/290334:1100086: Tue 
Nov  3 17:18:26 PST 2015 root@localhost:/common/S4/obj/usr/src/sys/CANARY  
amd64

I was un the shuttle bus at the time; apparently the DHCP server
in the access point wasn't behaving itself, as I got a DHCPNAK from
it -- running either head or stable/10.  I booted up head here at
home, and DHCP works fine:

FreeBSD  11.0-CURRENT FreeBSD 11.0-CURRENT #233  r290334M/290334:1100086: Tue 
Nov  3 17:18:26 PST 2015 root@localhost:/common/S4/obj/usr/src/sys/CANARY  
amd64


So: looks like  awin to me! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.



-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: panic: refcount inconsistency: found: 0 total: 1

[David Wolfskill]

On Tue, Nov 03, 2015 at 08:39:52AM -0800, David Wolfskill wrote:
> On Tue, Nov 03, 2015 at 06:15:35PM +0300, Alexander V. Chernikov wrote:
> > ...
> > > I tried booting it, and during the transition to multi-user mode,
> > > once ipfw was being invoked, I got the above-cited panic. Circumvention
> > > was to leave it disconnected from a network (turn off the WiFi
> > > switch, in my case), so we don't get a chance to use the network.
> > It is most probably related with r290334. Would you mind reverting it and 
> > checking if ipfw works correctly ?
> > 
> 
>  ... [Reverting r290334 gets things working again -- dhw]
> 
> at a *guess*, we'll need a bit more effort to keep "found" and
> "ci->object_opcodes" in sync, at least by the time the KASSERT on
> src/sys/netpfil/ipfw/ip_fw_table.c:3395 looks at the values.
> ...

So... looking at the code a bit (and bearing in mind that I still am
unfamiliar with said code, and I hack more than I "write" code)...
here's the original bit of src/sys/netpfil/ipfw/ip_fw_table.c in
question, with the modification from r290334 shown:

...
/*
 * Finds and bumps refcount for objects referenced by given @rule.
 * Auto-creates non-existing tables.
 * Fills in @oib array with userland/kernel indexes.
 *
 * Returns 0 on success.
 */
static int
ref_rule_objects(struct ip_fw_chain *ch, struct ip_fw *rule,
struct rule_check_info *ci, struct obj_idx *oib, struct tid_info
*ti)
{
...
if (error != 0) {
/* Unref everything we have already done */
unref_oib_objects(ch, rule->cmd, oib, pidx);
IPFW_UH_WUNLOCK(ch);
return (error);
}

IPFW_UH_WUNLOCK(ch);

found = pidx - oib;
KASSERT(found == ci->object_opcodes,
("refcount inconsistency: found: %d total: %d",
found, ci->object_opcodes));
   
/* Perform auto-creation for non-existing objects */
if (numnew != 0)
error = create_objects_compat(ch, rule->cmd, oib, pidx, ti);
   
+   /* Calculate real number of dynamic objects */
+   ci->object_opcodes = (uint16_t)(pidx - oib);
+
return (error);
}
...


The added code to "Calculate real number of dynamic objects" is
apparently setting ci->object_opcodes to the same value that "found" was
just set to (pidx - oib -- cast to uint16_t in the case of the added
code).

But that appears to come a bit late for the KASSERT.

Moving the KASSERT relative to the added code (so the KASSERT comes
after) would be an option, but I'm not sure it makes sense to
actually do the KASSERT unless we have some reason to believe that
the difference between pidx and oib might change in the interval
represented by a couple lines of code AND we have not coded to
handle that situation any more "gracefully" than to panic.

So... with the change from r290334, what's the point of the KASSERT?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: panic: refcount inconsistency: found: 0 total: 1

[David Wolfskill]

On Tue, Nov 03, 2015 at 06:15:35PM +0300, Alexander V. Chernikov wrote:
> ...
> > I tried booting it, and during the transition to multi-user mode,
> > once ipfw was being invoked, I got the above-cited panic. Circumvention
> > was to leave it disconnected from a network (turn off the WiFi
> > switch, in my case), so we don't get a chance to use the network.
> It is most probably related with r290334. Would you mind reverting it and 
> checking if ipfw works correctly ?
> 

OK; after:

Script started on Tue Nov  3 08:22:37 2015
g1-252(10.2-S)[1] (cd /S4/usr/src/ && svn diff -c 290334 >/tmp/r290334)^M
g1-252(10.2-S)[2] (cd /S4/usr/src/ && svn patch --reverse-diff /tmp/r290334)^M
U sys/netpfil/ipfw/ip_fw_sockopt.c
U sys/netpfil/ipfw/ip_fw_table.c
g1-252(10.2-S)[3] exit

followed by a "make buildkernel", I now have:

FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #232  
r290334M/290334:1100086: Tue Nov  3 08:27:20 PST 2015 
root@localhost:/common/S4/obj/usr/src/sys/CANARY  amd64

and

localhost(11.0-C)[3] ifconfig wlan0 
wlan0: flags=8843 metric 0 mtu 1500
ether 00:24:d6:7a:03:ce
inet 198.135.49.33 netmask 0xfc00 broadcast 198.135.51.255 
...

as I type, and IPFW is isn use


at a *guess*, we'll need a bit more effort to keep "found" and
"ci->object_opcodes" in sync, at least by the time the KASSERT on
src/sys/netpfil/ipfw/ip_fw_table.c:3395 looks at the values.

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

panic: refcount inconsistency: found: 0 total: 1

[David Wolfskill]

This was on my laptop; yesterday, it built & booted:

FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #230  
r290270M/290270:1100085: Mon Nov  2 05:03:07 PST 2015 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64


OK; today, after building:

FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #231  
r290334M/290334:1100086: Tue Nov  3 04:51:24 PST 2015 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64


I tried booting it, and during the transition to multi-user mode,
once ipfw was being invoked, I got the above-cited panic.  Circumvention
was to leave it disconnected from a network (turn off the WiFi
switch, in my case), so we don't get a chance to use the network.

I was able to get a dump by explicitly typing "call doadump" -- an
earlier attempt at "panic" didn't capture one.  Stack trace:

#0  doadump (textdump=0) at pcpu.h:221
221 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0  doadump (textdump=0) at pcpu.h:221
#1  0x8037b6b6 in db_fncall (dummy1=, 
dummy2=, dummy3=, 
dummy4=) at /usr/src/sys/ddb/db_command.c:568
#2  0x8037b14e in db_command (cmd_table=0x0)
at /usr/src/sys/ddb/db_command.c:440
#3  0x8037aee4 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:493
#4  0x8037d97b in db_trap (type=, code=0)
at /usr/src/sys/ddb/db_main.c:251
#5  0x80a270f3 in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:654
#6  0x80db6668 in trap (frame=0xfe060bdde1d0)
at /usr/src/sys/amd64/amd64/trap.c:549
#7  0x80d961f7 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:234
#8  0x80a267db in kdb_enter (why=0x812a5566 "panic", 
msg=0x80 ) at cpufunc.h:63
#9  0x809ea01f in vpanic (fmt=, 
ap=) at /usr/src/sys/kern/kern_shutdown.c:750
#10 0x809e9e76 in kassert_panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:647
#11 0x80c2a788 in ipfw_rewrite_rule_uidx (chain=0x81be5310, 
ci=0xfe060bdde4b8) at /usr/src/sys/netpfil/ipfw/ip_fw_table.c:3395
#12 0x80c267c3 in commit_rules (chain=0x81be5310, 
rci=0xfe060bdde4b8, count=1)
at /usr/src/sys/netpfil/ipfw/ip_fw_sockopt.c:678
#13 0x80c25d80 in add_rules (chain=0x81be5310, 
op3=, sd=)
at /usr/src/sys/netpfil/ipfw/ip_fw_sockopt.c:2594
#14 0x80c232f4 in ipfw_ctl3 (sopt=0xfe060bdde920)
at /usr/src/sys/netpfil/ipfw/ip_fw_sockopt.c:3242
#15 0x80b3d8b1 in rip_ctloutput (so=, 
sopt=0xfe060bdde920) at /usr/src/sys/netinet/raw_ip.c:588
#16 0x80a72bc6 in sogetopt (so=0xf80009e658b8, 
sopt=0xfe060bdde920) at /usr/src/sys/kern/uipc_socket.c:2731
#17 0x80a7729e in kern_getsockopt (td=0xf800098119a0, 
s=, level=, 
name=, val=, valseg=464, 
valsize=0xfe060bdde98c) at /usr/src/sys/kern/uipc_syscalls.c:1540
#18 0x80a771a0 in sys_getsockopt (td=0xf800098119a0, 
uap=0xfe060bddea40) at /usr/src/sys/kern/uipc_syscalls.c:1486
#19 0x80db7519 in amd64_syscall (td=0xf800098119a0, traced=0)
at subr_syscall.c:140
#20 0x80d964db in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:394
#21 0x000800b2cbea in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal
(kgdb) 

I've copied the vmcore.z & core.txt.7 to
; gzipped
copies are also available:

Index of /~david/FreeBSD/head/ipfw

 Icon   NameLast modified  Size  Description
  _
 [PARENTDIR]  Parent Directory -
 [TXT]  core.txt.7  2015-11-03 05:22  155K
 [   ]  core.txt.7.gz   2015-11-03 05:22   35K
 [   ]  vmcore.72015-11-03 05:22  528M
 [   ]  vmcore.7.gz 2015-11-03 05:22   45M
  _


I'll start taking a closer look at recent changes (e.g., in
src/sys/netpfil/ipfw), but I'm not really all that familiar with
the code.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: Segmentation fault running ntpd

[David Wolfskill]

On Fri, Oct 30, 2015 at 09:42:07AM +0100, Dag-Erling Smørgrav wrote:
> David Wolfskill  writes:
> > ...
> > bound to 172.17.1.245 -- renewal in 43200 seconds.
> > pid 544 (ntpd), uid 0: exited on signal 11 (core dumped)
> > Starting Network: lo0 em0 iwn0 lagg0.
> > ...
> 
> Did you find a solution?  I'm wondering if the ntpd problems people are
> reporting on freebsd-security@ are related.  I vaguely recall hearing
> that this had been traced to a pthread bug, but can't find anything
> about it in commit logs or mailing list archives.
> 

I don't recall finding "a solution" per se; that said, I also don't
recall seeing an occurrence of the above for enough time that I'm not
sure when I sent that message. :-}

As a reality check:

g1-252(11.0-C)[1] ls -lT /*.core
-rw-r--r--  1 root  wheel  13783040 Aug 18 04:19:03 2015 /ntpd.core
g1-252(11.0-C)[2] 

So -- among other points -- my last sighting of whatever was causing
that was the day I built:

FreeBSD 11.0-CURRENT #157  r286880M/286880:1100079: Tue Aug 18 04:45:25 PDT 
2015 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

Note that the machines where I run head get updated daily (unless
there's enough of a problem with head that I can't build it or can't
boot it (and I'm unable to circumvent the issue within a reasonable
time)) -- and while I do attempt to run ntpd on the machines, the above
failure is more "annoying" than "crippling" in my particular case.

And I'm presently running:

FreeBSD 11.0-CURRENT #227  r290138M/290138:1100084: Thu Oct 29 05:12:58 PDT 
2015 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

and building head @r290190 as I type.

And FWIW, I *suspect* that one of the issues involved (in my case)
was a ... lack of determinism ... in events involving getting the
(wireless) network connectivity into a usable state as part of the
initial transition to multi-user mode.  (I only have evidence at
the moment of the issue on my laptop; my build machine, which only
uses a wired NIC, has no /ntpd.core file.  It and my laptop are updated
pretty much in lock-step; it runs a completely GENERIC kernel, while
the laptop runs a modestly customized one based on GENERIC.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: head/amd64 @r288358: panic: lock (sleep mutex) iwn0_com_lock not locked @ /usr/src/sys/dev/iwn/if_iwn.c:5356

[David Wolfskill]

On Tue, Sep 29, 2015 at 12:12:02PM -0700, Adrian Chadd wrote:
> hi
> 
> (please subscribe and email freebsd-wireless@ these things, I'm more
> likely to notice!)
> 
> It looks due to my recent taskqueue change for updateedca. I'll go fix
> that today.
> 
> Thanks,
> ...

Looks as if you did:

FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #199  
r288418M/288418:1100079: Wed Sep 30 04:51:56 PDT 2015 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64

Thanks!  :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

head/amd64 @r288358: panic: lock (sleep mutex) iwn0_com_lock not locked @ /usr/src/sys/dev/iwn/if_iwn.c:5356

[David Wolfskill]

No known/observed issues with:
FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #197  
r288335M/288335:1100079: Mon Sep 28 04:14:47 PDT 2015 
root@localhost:/common/S4/obj/usr/src/sys/CANARY  amd64

on my laptop, but:
FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #198  
r288358M/288358:1100079: Tue Sep 29 04:46:49 PDT 2015 
root@localhost:/common/S4/obj/usr/src/sys/CANARY  amd64

was OK up to the point of attempting to establish a link using the
wlan0 interface (the underlying hardware for which is iwn on the laptop).

I was able to get a crash dump, and am presently copying it to
 (along with the
core.txt, which has already made it over).  (I am 3 time zones east
of home, and will be spending the bulk of the day returning home
-- and thus, without ability to respond to email for a while).

Here's an excerpt from the core.txt.5:

localhost dumped core - see /var/crash/vmcore.5

Tue Sep 29 05:14:30 PDT 2015

FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #198  
r288358M/288358:1100079: Tue Sep 29 04:46:49 PDT 2015 
root@localhost:/common/S4/obj/usr/src/sys/CANARY  amd64

panic: lock (sleep mutex) iwn0_com_lock not locked @ 
/usr/src/sys/dev/iwn/if_iwn.c:5356

GNU gdb 6.1.1 [FreeBSD]
...
Unread portion of the kernel message buffer:
d:
ACPI: SSDT 0xF80006E30800 0005AA (v01 PmRef  ApIst3000 INTL 
20120711)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0xF800067F6A00 000119 (v01 PmRef  ApCst3000 INTL 
20120711)
random: harvesting attach, 8 bytes (4 bits) from cpu1
cpu2: Processor \_PR_.CPU2 (ACPI ID 3) -> APIC ID 4
cpu2:  on acpi0
random: harvesting attach, 8 bytes (4 bits) from cpu2
cpu3: Processor \_PR_.CPU3 (ACPI ID 4) -> APIC ID 6
cpu3:  on acpi0
random: harvesting attach, 8 bytes (4 bits) from cpu3
cpu4: Processor \_PR_.CPU4 (ACPI ID 5) -> APIC ID 1
cpu4:  on acpi0
random: harvesting attach, 8 bytes (4 bits) from cpu4
cpu5: Processor \_PR_.CPU5 (ACPI ID 6) -> APIC ID 3
cpu5:  on acpi0
random: harvesting attach, 8 bytes (4 bits) from cpu5
cpu6: Processor \_PR_.CPU6 (ACPI ID 7) -> APIC ID 5
cpu6:  on acpi0
random: harvesting attach, 8 bytes (4 bits) from cpu6
cpu7: Processor \_PR_.CPU7 (ACPI ID 8) -> APIC ID 7
cpu7:  on acpi0
random: harvesting attach, 8 bytes (4 bits) from cpu7
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 8 timers, legacy route
hpet0:  t0: irqs 0x00f0 (0), MSI, 64bit, periodic
hpet0:  t1: irqs 0x00f0 (0), MSI
hpet0:  t2: irqs 0x00f00800 (0), MSI
hpet0:  t3: irqs 0x00f01000 (0), MSI
hpet0:  t4: irqs 0x (0), MSI
hpet0:  t5: irqs 0x (0), MSI
hpet0:  t6: irqs 0x (0), MSI
hpet0:  t7: irqs 0x (0), MSI
Timecounter "HPET" frequency 14318180 Hz quality 950
msi: routing MSI-X IRQ 256 to local APIC 0 vector 49
msi: routing MSI-X IRQ 257 to local APIC 0 vector 50
msi: routing MSI-X IRQ 258 to local APIC 0 vector 51
msi: routing MSI-X IRQ 259 to local APIC 0 vector 52
msi: routing MSI-X IRQ 260 to local APIC 0 vector 53
msi: routing MSI-X IRQ 261 to local APIC 0 vector 54
msi: routing MSI-X IRQ 262 to local APIC 0 vector 55
msi: routing MSI-X IRQ 263 to local APIC 0 vector 56
Event timer "HPET" frequency 14318180 Hz quality 550
random: harvesting attach, 8 bytes (4 bits) from hpet0
atrtc0:  port 0x70-0x77 irq 8 on acpi0
atrtc0: Warning: Couldn't map I/O.
atrtc0: registered as a time-of-day clock (resolution 100us, adjustment 
0.5s)
ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 57
Event timer "RTC" frequency 32768 Hz quality 0
random: harvesting attach, 8 bytes (4 bits) from atrtc0
attimer0:  port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 58
Event timer "i8254" frequency 1193182 Hz quality 100
random: harvesting attach, 8 bytes (4 bits) from attimer0
ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
random: harvesting attach, 8 bytes (4 bits) from acpi_timer0
acpi_ec0:  port 0x930,0x934 on acpi0
random: harvesting attach, 8 bytes (4 bits) from acpi_ec0
pci_link0:Index  IRQ  Rtd  Ref  IRQs
  Initial Probe   0   11   N 0  3 4 5 6 10 11 12 14 15
  Validation  0   11   N 0  3 4 5 6 10 11 12 14 15
  After Disable   0  255   N 0  3 4 5 6 10 11 12 14 15
random: harvesting attach, 8 bytes (4 bits) from pci_link0
pci_link1:Index  IRQ  Rtd  Ref  IRQs
  Initial Probe   0   10   N 0  3 4 5 6 10 11 12 14 15
  Validation  0   10   N 0  3 4 5 6 10 11 12 14 15
  After Disable   0  255   N 0  3 4 5 6 10 11 12 14 15
random: harvesting attach, 8 bytes (4 bits) from pci_link1
pci_link2:Index  IRQ  Rtd  Ref  IRQs
  Initial Probe   0   10   N 0  3 4 5 6 10 11 12 14 15
  Validation  0   10   N 0  3

Re: acpi suspend debugging techniques?

[David Wolfskill]

[Much trimming, both of older content and recipient addresses -- dhw]

On Thu, Sep 03, 2015 at 06:18:52PM -0400, Jung-uk Kim wrote:
> ...
> AFAICT, the whole suspend/resume code looks incomplete and very messy.
>  In fact, I'll be very surprised if it ever worked. :-(
> 
> Jung-uk Kim
> ...

While I bow to your expertise in the area, I point out that I
routinely suspend my laptop before putting it in my backpack, then
cycling between the shuttle stop and my house during my daily
commutes to & from work -- usually running stable/10, but I'm
sometimes running head at the time.

And I track both stable/10 and head daily on that laptop (in different
slices).

While I do encounter "issues" from time to time, those are rare enough
that I'd call them "unusual."  (To quantify that, I think I've had 3 - 5
such incidents since November 2014, while generally commuting 5
days/week.)

I'll be happy to test. :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who would murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgp19ZWuLnU87.pgp
Description: PGP signature

Re: panic in sysctl code in recent head

[David Wolfskill]

On Thu, Jul 30, 2015 at 12:11:22PM -0700, Navdeep Parhar wrote:
> A kernel built from head as of today panics with this on loading a module.
> Does anyone else see this too?
> 

Sorry for the delay -- but no; I have not seen it.

Each of the builds listed in

also involves loading (at minimum) nvidia.ko and geom_eli.ko; usually, a
few more -- successfully.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpiej4P1X3xk.pgp
Description: PGP signature

Re: Segmentation fault running ntpd

[David Wolfskill]

On Tue, Jul 28, 2015 at 04:25:45PM -0700, Adrian Chadd wrote:
> ...
> Hm, is there any way you can get symbols for it?

Well, I could "CFLAGS+= -g" in /etc/make.conf & to a "clean" build, then
try to re-create it (& point gdb at the objects in /usr/obj/obj/*) --
would that do?

> I don't think I can easily get symbols for the crash we have, but my
> crash is also deep in malloc code..
> 

Coincidence?  Inquiring minds want to know :-}

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpe1oC0HgQsj.pgp
Description: PGP signature

Re: Segmentation fault running ntpd

[David Wolfskill]

On Tue, Jul 28, 2015 at 04:05:33PM -0700, Adrian Chadd wrote:
> Is this still happening for you?
> 

g1-245(10.2-P)[4] ls -lT /S4/ntpd.core 
-rw-r--r--  1 root  wheel  13783040 Jul 28 04:56:28 2015 /S4/ntpd.core

Apparently so, yes.

(/S4 is where I have the head root file system mounted when I'm not
running from slice 4.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpDpAhZQ_vQX.pgp
Description: PGP signature

Re: Segmentation fault running ntpd

[David Wolfskill]

On Sun, Jul 19, 2015 at 11:36:00AM -0700, David Wolfskill wrote:
> On Sun, Jul 19, 2015 at 10:24:11AM -0600, Ian Lepore wrote:
> > ...
> > Was there anything (at all) in /var/log/messages about ntpd?  Even the
> > routine messages (such as what interfaces it binds to) might give a bit
> > of a clue about how far it got in its init before it died. 
> > 
> 
> Sorry; there might have been something yesterday...
> If I do get another recurrence, I'll try to gather a bit more
> information.
> 

OK; got another one.

This time, I have the complete /var/log/messages for a verbose boot,
from that boot to just a bit after the ntpd crash; it's in
<http://www.catwhisker.org/~david/FreeBSD/head>; as of the moment, that
contains:

[PARENTDIR] Parent Directory -   
[   ] CANARY  2015-03-22 10:03   15K  
[   ] CANARY.gz   2015-03-22 10:03  6.3K  
[   ] ntpd.core   2015-07-24 05:31   13M  
[   ] ntpd.core.gz2015-07-24 05:31  124K  
[TXT] ntpd_crash_msgs.txt 2015-07-24 05:40  138K  
[   ] ntpd_crash_msgs.txt.gz  2015-07-24 05:40   19K  

This was running:

FreeBSD g1-245.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #133  
r285836M/285836:1100077: Fri Jul 24 05:24:41 PDT 2015 
r...@g1-245.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  amd64


Trying "gdb /usr/obj/usr/src/usr.sbin/ntp/ntpd/ntpd ntpd.core" still
doesn't help much:

This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols 
found)...
Core was generated by `ntpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.
...
Loaded symbols for /libexec/ld-elf.so.1
#0  0x0008011cd6a0 in sbrk () from /lib/libc.so.7
[New Thread 801c07400 (LWP 100133/)]
[New Thread 801c06400 (LWP 100132/)]
(gdb) bt
#0  0x0008011cd6a0 in sbrk () from /lib/libc.so.7
#1  0x0008ccbd4f34 in ?? ()
#2  0x0005 in ?? ()
#3  0x000801800448 in ?? ()
#4  0x0008011ca888 in sbrk () from /lib/libc.so.7
#5  0x0008018000c8 in ?? ()
#6  0x0008018000c0 in ?? ()
#7  0x0208 in ?? ()
#8  0x000801c32fb0 in ?? ()
#9  0x0001 in ?? ()
#10 0x000801cc20c8 in ?? ()
#11 0x0030 in ?? ()
#12 0x000801cc20c8 in ?? ()
#13 0x7fffe480 in ?? ()
#14 0x0008011cd240 in sbrk () from /lib/libc.so.7
#15 0x0280 in ?? ()
#16 0x0008014bbc70 in malloc_message () from /lib/libc.so.7
#17 0x0008018000c0 in ?? ()
#18 0x000801800448 in ?? ()
#19 0x0032 in ?? ()
#20 0x000801800458 in ?? ()
#21 0x0008014bbc68 in malloc_message () from /lib/libc.so.7
#22 0x000801cc2000 in ?? ()
#23 0x0008014bba60 in malloc_message () from /lib/libc.so.7
#24 0x000801cc20d8 in ?? ()
#25 0x00a0 in ?? ()
#26 0x0208 in ?? ()
#27 0x7fffe4d0 in ?? ()
#28 0x0008011bdd7a in _malloc_thread_cleanup () from /lib/libc.so.7
Previous frame inner to this frame (corrupt stack?)
(gdb) 


I am presently suspecting that it's a bit dependent on ... well, "timing".

I have my ~/.xsession set up so that once I've entered the passphrase(s)
for my SSH private key(s), scripts start running to establish
connections to other machines -- e.g., open an xterm locally, ssh
over to my mailhub and (re-)establish a tmux session on that machine
where I run mutt to read & write email (such as this message).

While that almost always Just Works in stable/10, it's rather ...
spottier ... in head -- I'd say it's about a 50% probability that it will
work, vs. the ssh connection attempt hanging, and eventually timing out.
But if I've waited (say) 30 seconds or so, I can establish such a
connection easily.

Granted, I am using wireless (802.11), but I get a sense that "things"
are claimed to be "ready to go" a bit prematurely -- at least sometimes.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgptpn4GcpGjF.pgp
Description: PGP signature

Re: panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

[David Wolfskill]

On Tue, Jul 21, 2015 at 03:21:16PM -0500, Eric van Gyzen wrote:
> ...
> >> So it looks like net swi, leaking some udp6 lock.
> > Curiouser and curiouser...  While I'm not taking any special pains to
> > avoid building IPv6, I'm not actively actually doing anything with it
> > (IPv6), either (for both the failing machine and my laptop).
> >
> > Once I'm back home, I should be able to poke around in ddb after
> > re-creating the panic, if that would be a useful thing for me to do (and
> > given some hints as to what to poke).
> >
> > Naturally, I'm also happy to change bits of sources, rebuild, and
> > smoke-test.
> >
> > A quick check from the SVN update output only shows r285710, r285711, and
> > r285740 in the range from (r285685,r285741] -- as the kernel running
> > r285685 had no known issues -- that touched sys/netinet6/*.
> 
> It's a multicast destination.  Maybe something is using mDNS?
> 
> Randall, does the test on line 406 of udp6_usrreq.c need to be inverted?
> 
> Eric
> 

  We have a winner!

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1789  
r285741M/285741:1100077: Tue Jul 21 14:50:59 PDT 2015 
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC  amd64

freebeast(11.0-C)[3] cd /usr/src
freebeast(11.0-C)[4] svn diff sys/netinet
netinet/  netinet6/ 
freebeast(11.0-C)[4] svn diff sys/netinet*
Index: sys/netinet6/udp6_usrreq.c
===
--- sys/netinet6/udp6_usrreq.c  (revision 285741)
+++ sys/netinet6/udp6_usrreq.c  (working copy)
@@ -403,7 +403,7 @@
INP_RLOCK(last);
INP_INFO_RUNLOCK(pcbinfo);
UDP_PROBE(receive, NULL, last, ip6, last, uh);
-   if (udp6_append(last, m, off, &fromsa)) 
+   if (! udp6_append(last, m, off, &fromsa)) 
INP_RUNLOCK(last);
inp_lost:
return (IPPROTO_DONE);
freebeast(11.0-C)[5] 

Thanks! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpJj1IlX26b0.pgp
Description: PGP signature

Re: panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

[David Wolfskill]

On Tue, Jul 21, 2015 at 10:28:32PM +0300, Konstantin Belousov wrote:
> ...
> Indeed, thank you.
> ithread_loop() at ithread_loop+0xa6/frame 0xfe083b9c0a70
> fork_exit() at fork_exit+0x84/frame 0xfe083b9c0ab0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe083b9c0ab0
> --- trap 0, rip = 0, rsp = 0xfe083b9c0b70, rbp = 0 ---
> suspending ithread with the following locks held:
> shared rw udpinp (udpinp) r = 3 (0xf80010c7d7b0) locked @ 
> /usr/src/sys/netinet6/in6_pcb.c:1174
> panic: witness_warn
> cpuid = 3
> 
> So it looks like net swi, leaking some udp6 lock.

Curiouser and curiouser...  While I'm not taking any special pains to
avoid building IPv6, I'm not actively actually doing anything with it
(IPv6), either (for both the failing machine and my laptop).

Once I'm back home, I should be able to poke around in ddb after
re-creating the panic, if that would be a useful thing for me to do (and
given some hints as to what to poke).

Naturally, I'm also happy to change bits of sources, rebuild, and
smoke-test.

A quick check from the SVN update output only shows r285710, r285711, and
r285740 in the range from (r285685,r285741] -- as the kernel running
r285685 had no known issues -- that touched sys/netinet6/*.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpQ_E2uiyznk.pgp
Description: PGP signature

Re: panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

[David Wolfskill]

On Tue, Jul 21, 2015 at 04:39:07PM +0300, Konstantin Belousov wrote:
> On Tue, Jul 21, 2015 at 05:57:34AM -0700, David Wolfskill wrote:
> > My laptop had no problems, but the build machine has a panic that
> > appears quite reproducible (4 "successes" out of 4 tries); here's a bit
> > from the core.txt file:
> 
> There must be kernel messages before the panic string.  They are crusial
> to understand what is going on.
> ...

Sorry I wasn't able to capture those before I needed to do Other Things.

The machine had a (PCI-attached) serial console that was working
for FreeBSD (thanks mostly to sbruno's help), but Somthing seems
to Have Happened, and that's not presently working (even in stable/10,
where I first got it working).

I will try to get it working again, but I doubt I will have time to
focus on that until about 9 hours from now.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpXNNyz_zCPR.pgp
Description: PGP signature

panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

[David Wolfskill]

My laptop had no problems, but the build machine has a panic that
appears quite reproducible (4 "successes" out of 4 tries); here's a bit
from the core.txt file:

freebeast.catwhisker.org dumped core - see /var/crash/vmcore.1

Tue Jul 21 05:36:11 PDT 2015

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1787  
r285741M/285741:1100077: Tue Jul 21 04:48:37 PDT 2015 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

panic: witness_warn

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
panic: witness_warn
cpuid = 3
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe083b9c0860
vpanic() at vpanic+0x189/frame 0xfe083b9c08e0
kassert_panic() at kassert_panic+0x132/frame 0xfe083b9c0950
witness_warn() at witness_warn+0x498/frame 0xfe083b9c0a20
ithread_loop() at ithread_loop+0x165/frame 0xfe083b9c0a70
fork_exit() at fork_exit+0x84/frame 0xfe083b9c0ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe083b9c0ab0
--- trap 0, rip = 0, rsp = 0xfe083b9c0b70, rbp = 0 ---
...
(kgdb) #0  doadump (textdump=0) at pcpu.h:221
#1  0x80377dfe in db_dump (dummy=, dummy2=false, 
dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:533
#2  0x80377971 in db_command (cmd_table=0x0)
at /usr/src/sys/ddb/db_command.c:440
#3  0x80377604 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:493
#4  0x8037a19b in db_trap (type=, code=0)
at /usr/src/sys/ddb/db_main.c:251
#5  0x80a56624 in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:654
#6  0x80e61bd1 in trap (frame=0xfe083b9c0790)
at /usr/src/sys/amd64/amd64/trap.c:540
#7  0x80e41e02 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:235
#8  0x80a55cfe in kdb_enter (why=0x8136f098 "panic", 
msg=0x80a5bee0 
"UH\211AWAVATSH\203PI\211A\211H\213\004%\201H\211E\201<%x\201")
 at cpufunc.h:63
#9  0x80a19739 in vpanic (fmt=, 
ap=) at /usr/src/sys/kern/kern_shutdown.c:737
#10 0x80a19582 in kassert_panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:634
#11 0x80a74908 in witness_warn (flags=2, lock=, 
fmt=0x81367827 "suspending ithread")
at /usr/src/sys/kern/subr_witness.c:1757
#12 0x809e2985 in ithread_loop (arg=0xf8000770c820)
at /usr/src/sys/kern/kern_intr.c:1345
#13 0x809df874 in fork_exit (
callout=0x809e2820 , arg=0xf8000770c820, 
frame=0xfe083b9c0ac0) at /usr/src/sys/kern/kern_fork.c:1006
#14 0x80e4233e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:610
#15 0x in ?? ()
Current language:  auto; currently minimal
(kgdb) 


On boot, it dropped into the debugger; it was on the most recent
instantiation that I manually issued a "dump" command from that
environment, then rebooted under the previous kernel:

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1786  
r285715M/285715:1100077: Mon Jul 20 04:22:26 PDT 2015 
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC  amd64

(And yes, it runs an unmodified GENERIC kernel.)

The machine has been deployed only for a couple of months or so,
but has been building stable/10 and head daily during that time.
Until a couple of weeks ago, it was doing this for both i386 and
amd64; since then, I dropped i386 from my home infrastructure, so
it's been only amd64.

In the stable/10 environment, it also make use of a 3-spindle zraid for
running poudriere (to build the ports for my "production" machines), and
it's been doing that quite well, also.

Only other thing that I think of that's noteworthy is that its boot
drive is an SSD (where I have not yet enabled TRIM, as it's a Crucial
M500, and I need to be sure we don't try to use the queued TRIM commands
on it, as there are reports that queued TRIM commands on the M500 will
corrupt data).

OK; please see  for the
dump(-related) files.  (It's on a residential ADSL, so it's going to be
slow.  Sorry; I have a limited amount of bandwidth.)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgp4y7XWYoZPA.pgp
Description: PGP signature

Re: -current broken when src is on NFS

[David Wolfskill]

On Sun, Jul 19, 2015 at 10:31:36AM -0600, Ian Lepore wrote:
> 
> I've been following this saga (on irc and here) as much as I have time
> for, and I can't escape the feeling that it is the directory structure
> at fault somehow, but I can't quite put my finger on it.
> 
> I never (ever) build from /usr/src or use /usr/obj as an object dir
> (they're both empty dirs on all my machines).  But one thing that is
> always true for me is that the source dir and its related object dir are
> siblings in the same parent dir.  That is, it's always
>  
>/any/path/here
>   obj/
>   src/

Well, as counterpoint  The systems where I do FreeBSD builds are
usually set up (and have been since about 1999) so that:

* The sources reside in /usr/src.

* The file system layput is such that:
  + /usr is on a different file system from /, but these reside in
partitions 4 and 1 (respectively) of the same slice.
  + /var is a file system that resides on a partition on slice 4.
  + swap is on slice 4, partition 2.
  + /tmp is a swap-backed tmpfs.  (Well, the implementation of that has
changed over the years -- used to be mfs.)
  + My home directory resides in a file system on a partition in slice
4 mounted on /common -- along with quite a few other things that do
not need to physically be on the same slice that I booted from.
  + /usr/ports is a symlink to an SVN working copy (was a CVS working
directory once upon a time) that's in the same file system as
my home directory.
  + Historically, /usr/local was also a symlink to a hierarchy in that
same file system.  (I only built ports under stable, but used them
under both stable and head.)
  + /usr/obj is also a symlink to a hierarchy in that same file system
(/common) -- I had one for each slice (/common/S{1,2,3,4}).

* Each of slices 1, 2, and 3 has a / and a /usr file system (as
  described above); slice 4 has those, as well as swap, /var, /common, and
  (often) a few others (e.g., /repo or /bkp).

* If I'm merely booting to single-user mode, each of the 4 slices is
  independent of the others, and I can boot any of them.  As soon as I
  start setting up swap, I become dependent on slice 4 (if I wasn't
  already booted from it).

It is not at all uncommon for me to "clone" one slice to another using a
'dump | restore' pipeline; by having the actual contents of /usr/obj in a
separate file system, it is easy to make copying that optional -- and if
my intent is to move it (vs. copy), renaming a directory is pretty fast
and cheap.

> Given that we have (or at least had at one time) some of those magical
> "..." paths that cause bmake to search up the hierarchy for its .mk
> files, I wonder if an odd relationship between src and obj dir confuses
> it, or if it somehow wanders into a wrong src tree while searching?
> ...

Well, I suspect that if that were an issue, I'd likely have encountered
it (while muttering further deprecation against realpath all the while).
:-}

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpsYPDXAjyiE.pgp
Description: PGP signature

Re: Segmentation fault running ntpd

[David Wolfskill]

On Sun, Jul 19, 2015 at 10:24:11AM -0600, Ian Lepore wrote:
> ...
> Was there anything (at all) in /var/log/messages about ntpd?  Even the
> routine messages (such as what interfaces it binds to) might give a bit
> of a clue about how far it got in its init before it died. 
> 

Sorry; there might have been something yesterday, but what with the
(verbose) reboots after builds, I, rolled over all of my
/var/log/messages* files; the earliest recrd I still have is from Jul
19 06:00:00 (UTC-0700), and I did not get a recurrence today.

(The one from yesterday wasn't the first I had seen -- I wanted to wait
until I had some hope that the issue was reproducible before whining
about it. :-})

If I do get another recurrence, I'll try to gather a bit more
information.

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgp1uXovIDi31.pgp
Description: PGP signature

Segmentation fault running ntpd

[David Wolfskill]

Lousy timing (no pun intended -- it's early in the day for me),
given the recent MFC, but as I was booting my laptop to yesterday's
head:

FreeBSD g1-245.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #127  
r285652M/285652:1100077: Fri Jul 17 04:30:16 PDT 2015 
r...@g1-245.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64

to build today's head (@r285670; still in progress as I type), I
happened to note [Oh, great -- we can no longer copy/paste from
console now??!?  Fine, I'll transcribe by hand :-(]:

...
bound to 172.17.1.245 -- renewal in 43200 seconds.
pid 544 (ntpd), uid 0: exited on signal 11 (core dumped)
Starting Network: lo0 em0 iwn0 lagg0.
...

Trying to examine the /ntpd.core, I see:
root@g1-245:/ # gdb `which ntpd` ntpd.core 
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols 
found)...
Core was generated by `ntpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libcrypto.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypto.so.7
Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x0008011cd6a0 in sbrk () from /lib/libc.so.7
[New Thread 801c07400 (LWP 100122/)]
[New Thread 801c06400 (LWP 100120/)]
(gdb) bt
#0  0x0008011cd6a0 in sbrk () from /lib/libc.so.7
#1  0x0008ccbd4f34 in ?? ()
#2  0x0005 in ?? ()
#3  0x000801800448 in ?? ()
#4  0x0008011ca888 in sbrk () from /lib/libc.so.7
#5  0x0008018000c8 in ?? ()
#6  0x0008018000c0 in ?? ()
#7  0x0208 in ?? ()
#8  0x000801c32fb0 in ?? ()
#9  0x0001 in ?? ()
#10 0x000801cc20c8 in ?? ()
#11 0x0030 in ?? ()
#12 0x000801cc20c8 in ?? ()
#13 0x7fffe480 in ?? ()
#14 0x0008011cd240 in sbrk () from /lib/libc.so.7
#15 0x0280 in ?? ()
#16 0x0008014bbc70 in malloc_message () from /lib/libc.so.7
#17 0x0008018000c0 in ?? ()
#18 0x000801800448 in ?? ()
#19 0x0032 in ?? ()
#20 0x000801800458 in ?? ()
#21 0x0008014bbc68 in malloc_message () from /lib/libc.so.7
#22 0x000801cc2000 in ?? ()
---Type  to continue, or q  to quit---
#23 0x0008014bba60 in malloc_message () from /lib/libc.so.7
#24 0x000801cc20d8 in ?? ()
#25 0x00a0 in ?? ()
#26 0x0208 in ?? ()
#27 0x7fffe4d0 in ?? ()
#28 0x0008011bdd7a in _malloc_thread_cleanup () from /lib/libc.so.7
Previous frame inner to this frame (corrupt stack?)
(gdb) 

which seems... well, not especially useful, as far as I can tell.


This is (as mentioned above) on my laptop; as such, it is expected to
"wander" from one network to another.  Accordingly:

* Since it could be connected to a network I do not control, I use a
  packet filter (IPFW, in my case) to reduce my exposure from a
  possibly-hostile network.

* Rather than enabling ntpd in /etc/rc.conf, I use
  /etc/dhclient-exit-hooks to start ntpd after the laptop has a DHCP
  lease.  (For networks I control, I also set up the DHCP server to
  advertise what NTP server the DHCP clients should use, but the code in
  dhclient-exit-hooks merely prefers that, rather han requiring it.)

* In my world-view -- at least for networks I control -- DNS zone files
  are the Source of Truth with respect to hostname <-> IP address
  correspondence, and Dynamic DNS is Evil.  I populate my zone files
  with appropriate A & PTR records so that every assignable DHCP
  address has a PTR record, and the hostname to which it points has
  an A record that points back to that IP address.  Accordingly, I
  also use /etc/dhclient-exit-hooks so the laptop can find out what
  its hostname is, and set it accordingly.

Mind, I've been doing the above for well over a decade, so that doesn't
qualify as "new."

And most of the time, it Just Works (which is a significant reason I
keep doing it).

A couple of other things that are more recent, and possibly of
relevance:

* As alluded to above, I have the em0 & wlan0 (iwn(4)) NICs set up using
  Link Aggregation in "failover" mode.  In practice, I rarely use
  the em0 (wired) NIC -- I had originally done that based on a
  misperception of how I thought things were set up at work, and
  then just left the configuration alone and relied on the wi

Re: Error building x11/nvidia-driver kernel module @r284408

[David Wolfskill]

On Mon, Jun 15, 2015 at 11:33:47AM -0700, Simon J. Gerraty wrote:
> Garrett Cooper  wrote:
> > > Now that "vanilla" head @284408 builds (& boots):
> 
> 
> I fixed this the other day - just realized I haven't committed it.
> 
> > > make[6]: don't know how to make 
> > > /common/S3/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src/machine.
> > >  Stop
> > > 

OK; following up: I see Simon committed r284420; after hand-appling that
(1-line fix); I performed:

make -DNOCLEAN -j16 buildkernel
make installkernel
... [mergemaster &c...]
make installworld
...
make delete-old

for each of head/amd64 & head/i386 on my laptop; since /etc/src.conf is:

KERNCONF=CANARY
PORTS_MODULES=x11/nvidia-driver
PORTS_MODULES+=multimedia/cuse4bsd-kmod
PORTS_MODULES+=emulators/virtualbox-ose-kmod
WITHOUT_DEBUG_FILES=1
IWN_DEBUG=1
IEEE80211_DEBUG=1

the above process also built kernel modules for x11/nvidia-driver,
multimedia/cuse4bsd-kmod, and emulators/virtualbox-ose-kmod.

Each was successful:

FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #95  
r284408M/284408:1100077: Mon Jun 15 06:09:41 PDT 2015 
r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64

FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #30  
r284408M/284408:1100077: Mon Jun 15 07:25:43 PDT 2015 
r...@g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpUnWygLUADo.pgp
Description: PGP signature

Error building x11/nvidia-driver kernel module @r284408

[David Wolfskill]

Now that "vanilla" head @284408 builds (& boots):

FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1751  
r284408M/284408:1100077: Mon Jun 15 05:51:00 PDT 2015 
r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC  amd64

I find that for my laptop, I encounter an error while trying to build
the x11/nvidia-driver kernel module (courtesy of /etc/src.conf:

g1-254(11.0-C)[2] cat /etc/src.conf 
KERNCONF=CANARY
PORTS_MODULES=x11/nvidia-driver
PORTS_MODULES+=multimedia/cuse4bsd-kmod
PORTS_MODULES+=emulators/virtualbox-ose-kmod
WITHOUT_DEBUG_FILES=1
IWN_DEBUG=1
IEEE80211_DEBUG=1
g1-254(11.0-C)[3] 

-- which has heretofore been working for my daily refreshes for years):

...
objcopy --strip-debug --add-gnu-debuglink=kernel.symbols kernel.debug kernel
--- all ---
===> Ports module x11/nvidia-driver (all)
cd ${PORTSDIR:-/usr/ports}/x11/nvidia-driver; 
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
  SRC_BASE=/usr/src  OSVERSION=1100077  
WRKDIRPREFIX=/usr/obj/usr/src/sys/CANARY make -B clean all
...
===>  Configuring for nvidia-driver-346.47
===>  Building for nvidia-driver-346.47
===> src (all)
make[6]: don't know how to make 
/common/S3/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src/machine.
 Stop

make[6]: stopped in 
/common/S3/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src
.CURDIR='/common/S3/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src'
.MAKE='/usr/bin/make'
.OBJDIR='/common/S3/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src'
.TARGETS='all'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH=''
MAKE_VERSION='20150606'
SRCTOP='/usr/src'
OBJTOP=''
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/bsd.mkopt.mk 
/etc/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk 
/etc/src.conf /usr/src/share/mk/bsd.cpu.mk Makefile 
/usr/src/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk 
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/local.init.mk /usr/src/share/mk/src.opts.mk 
/usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk 
/usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/config.mk 
/usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk 
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk 
/usr/src/sys/conf/kern.mk'
.PATH='. 
/common/S3/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src'
*** Error code 2

Stop.



A full typescript of the svn update and build may be found at
; it's
about 51MB.

Please note that the (similar) refreshes for stable/10 (@r284404)
had no problems; I have typescripts of them accessible (but I haven't
put'them up on the Web server, as they're pretty boring).

Perhaps some changes need to be made for (some?) ports to adjust for
recent make & mk changes in head?

I note that in the stable/10 case, the 
.../obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src/machine
 "file"
is a symlink to /usr/src/sys/amd64/include -- and that it doesn't
exist in the i386 case (and that doesn't appear to be a problem).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgp0kFTiet_yB.pgp
Description: PGP signature

Re: Those at BSDCan 2015: please test: iwn(4) patch to buffer 5ghz frames before transmitting

[David Wolfskill]

On Mon, Jun 08, 2015 at 08:29:17AM -0700, Adrian Chadd wrote:
> Sigh.
> 
> This patch:
> 
> https://people.freebsd.org/~adrian/net80211/20150524-iwn-delay-xmit-passive-1.diff
> 
> along with the latest net80211 tree in -HEAD will buffer frames until
> the first beacon is received after association. It doesn't (yet!)
> purge frames in all the right places, but it should be enough to at
> least get you associated to the 5GHz networks at bsdcan.
> ...

Seems to work so far for me

I started with:

FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #87  
r284149M/284150:1100076: Mon Jun  8 04:54:51 PDT 2015 
r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64

Then:

Script started on Mon Jun  8 18:43:54 2015
command: svn patch /home/david/tmp/20150524-iwn-delay-xmit-passive-1.diff
U sys/dev/iwn/if_iwn.c
U sys/dev/iwn/if_iwnvar.h

Script done on Mon Jun  8 18:43:54 2015

Rebuilt/installed the kernel, rebooted:

FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #88  
r284149M/284150:1100076: Mon Jun  8 18:47:07 PDT 2015 
r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64

And laptop associated on channel 1.  Then I remembered that I had set
the priority of the 2.4 & 5 GHz radios the same, so I bumped the 5 GHz
one up, tolkd it to "reconnect," now it's on channel 149:

g1-254(11.0-C)[5] ifconfig wlan0
wlan0: flags=8843 metric 0 mtu 1500
ether 34:e6:d7:3c:4a:93
nd6 options=29
media: IEEE 802.11 Wireless Ethernet MCS mode 11na
status: associated
ssid lmdhw-net channel 149 (5745 MHz 11a ht/40+) bssid 0a:18:d6:21:22:1f
country US authmode WPA2/802.11i privacy ON deftxkey UNDEF
AES-CCM 2:128-bit txpower 15 bmiss 10 mcastrate 6 mgmtrate 6
scanvalid 60 ampdulimit 64k -amsdutx amsdurx shortgi wme
roaming MANUAL
groups: wlan 
g1-254(11.0-C)[6] 

If I get a chance, I'll see if I can try it at work tomorrow -- we have a
bit higher bandwidth to the Internet there :-}

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpgR0oPMEl5q.pgp
Description: PGP signature

Re: Seeing about 4K "exec: No such file or directory" msgs in installworld

[David Wolfskill]

On Thu, Jun 04, 2015 at 07:19:38AM -0700, Sean Bruno wrote:
> ...
> Bapt fixed this in head, so you should not see this anymore.
> 

Confirmed:

g1-254(10.1-S)[1] grep -c 'exec: No such file or directory' s3
0
g1-254(10.1-S)[2] 

FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #83  
r283985M/283985:1100076: Thu Jun  4 06:14:47 PDT 2015 
r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64

(Thanks, Bapt!)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpaNmK69l6A0.pgp
Description: PGP signature

Re: Seeing about 4K "exec: No such file or directory" msgs in installworld

[David Wolfskill]

On Mon, Jun 01, 2015 at 07:31:53PM +0200, Dimitry Andric wrote:
> ...
> > 87386:exec: No such file or directory
> 
> Yep, I saw these too.  Hundreds of them.

Ah; well, I'm fairly relived that I'm not either hallucinating (about
this, anyway) or the only one seeing it.  So thanks for that!  :-)

> At this point, I think it
> should run makewhatis on /usr/share/openssl/man?

Hmmm...

> I suspect this has to do with some of the recent mandoc changes, but
> which one... no idea. :)
> ...

At least it doesn't seem to be causing observable harm -- it just seemed
a bit odd to me.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgp8rQiq08gOF.pgp
Description: PGP signature

Seeing about 4K "exec: No such file or directory" msgs in installworld

[David Wolfskill]

I don't have evidence that this is a problem, per se.

I just noticed this during this morning's build/install, but checking
yesterday's typescripts, I see that it occurred then, as well.  (I only
keep the last pair of typescripts for a given branch & architecture, so
I don't know if it had been happening earlier.)

For amd64, I'm seeing 3983 of them; for i386, I'm seeing 4014.

Here's an excerpt (for amd64; source updated to r283870 while running
@r283811):

g1-254(10.1-S)[6] grep -nC 3 'exec: No such file or directory' s3 | head
87382-install -o root -g wheel -m 644  laptop.cf /etc/mail/sendmail.cf
87383-cd /usr/src/etc/../share/man; make makedb
87384-makewhatis /usr/share/man
87385:exec: No such file or directory
87386:exec: No such file or directory
87387:exec: No such file or directory
87388:exec: No such file or directory
87389:exec: No such file or directory
87390:exec: No such file or directory
87391:exec: No such file or directory
g1-254(10.1-S)[7] grep -nC 3 'exec: No such file or directory' s3 | tail
91362:exec: No such file or directory
91363:exec: No such file or directory
91364:exec: No such file or directory
91365:exec: No such file or directory
91366:exec: No such file or directory
91367:exec: No such file or directory
91368:exec: No such file or directory
91369-cd /usr/src; make -f Makefile.inc1 install32
91370-cd /usr/src/lib; MACHINE=i386 MACHINE_ARCH=i386 MACHINE_CPU="i686 mmx sse 
sse2" MAKEOBJDIRPREFIX=/usr/obj/usr/src/world32 
_SHLIBDIRPREFIX=/usr/obj/usr/src/lib32 VERSION="FreeBSD 11.0-CURRENT amd64 
1100075" 
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/tmp/install.jSEEVgsG
 LIBDIR=/usr/lib32 SHLIBDIR=/usr/lib32 LIBPRIVATEDIR=/usr/lib32/private 
DTRACE="dtrace -32" make AS="as --32" LD="ld -m elf_i386_fbsd -Y 
P,/usr/obj/usr/src/lib32/usr/lib32" OBJCOPY="objcopy" CC="cc -m32 -march=i686 
-mmmx -msse -msse2 -DCOMPAT_32BIT  -isystem /usr/obj/usr/src/lib32/usr/include/ 
 -L/usr/obj/usr/src/lib32/usr/lib32  -B/usr/obj/usr/src/lib32/usr/lib32" 
CXX="c++ -m32 -march=i686 -mmmx -msse -msse2 -DCOMPAT_32BIT  -isystem 
/usr/obj/usr/src/lib32/usr/include/  -L/usr/obj/usr/src/lib32/usr/lib32  
-B/usr/obj/usr/src/lib32/usr/lib32" -DCOMPAT_32BIT -DLIBRARIES_ONLY 
-DNO_CPU_CFLAGS MK_CTF=no -DNO_LINT MK_TESTS=no MK_MAN=no MK_HTML=no  
MK_TOOLCHAIN=no  install
91371-===> csu (install)
g1-254(10.1-S)[8] 


Before/after "uname -a" output corresponding to the above:

FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #79  
r283811M/283811:1100075: Sun May 31 05:07:40 PDT 2015 
r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64

FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #80  
r283870M/283878:1100075: Mon Jun  1 05:08:45 PDT 2015 
r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64


g1-254(10.1-S)[8] grep -c 'exec: No such file or directory' s?
s1:0
s2:0
s3:3983
s4:4014
g1-254(10.1-S)[9] 

[s1: stable/10 i386; s2: stable/10 amd64; s3: head amd64; s4: head i386]


I have no evidence of problems with the build in other respects, and I
find that my (i386) "build machine" also shows 4014 occurrences in
yesterday's build.  (It's still working on today's.)  On my laptop
(source of the rest of the numbers cited above, as well as the excerpt),
the numbers from yesterday to today (for each architecture) are the same.

It seemed ... odd enough to mention, anyway.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpohU96vfKAV.pgp
Description: PGP signature

Re: [283136]: buildworld failure: usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lproc

[David Wolfskill]

On Wed, May 20, 2015 at 06:50:24AM +0200, O. Hartmann wrote:
> Current sources (r283136) die on buildworld with the following error:
> 
> [...]
> --- cddl/lib__L ---
> /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lproc
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** [libdtrace.so.2] Error code 1
> 

I was able to perform a source update from:

FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #67  
r283104M/283104:1100073: Tue May 19 05:02:57 PDT 2015 
r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64

to:

FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #68  
r283142M/283142:1100073: Wed May 20 05:02:58 PDT 2015 
r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64

without incident.

Checking ,
it looks as if r283139 is intended to address what you saw, and
r283143  - 283145 are additional clean-up.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgp3sghqgZ0Cs.pgp
Description: PGP signature

Re: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again

[David Wolfskill]

On Sat, May 16, 2015 at 03:50:00PM +0200, Hans Petter Selasky wrote:
> ...
> Send output from bootverbose! Let's hunt this bug down :-)
> 

OK; after restoring r282650 & r282651, clearing /usr/obj, and performing
a clean buildworld, kernel, and installworld, the "smoke test" reboot
yielded (a recurrence of) the panic that has been the topic of this
thread.

I then appended:

hint.hdac.0.disabled=1

to /boot/device.hints, and was then able to complete a boot of:

FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #0  
r283005M/283005:1100073: Sat May 16 08:17:05 PDT 2015 
r...@g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386

to multi-user mode.

As noted earlier, there's a fair amount of information about the system
at , including verbose
dmesg.boot copies from {head,stable10}{amd64,i386}.  I will be  happy to
provide anything else I can

The panic information appears to be  the same as I originally reported;
ref.  for
that.

What's next?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpNX9jZXylA5.pgp
Description: PGP signature

Re: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again

[David Wolfskill]

On Sat, May 16, 2015 at 03:46:18PM +0200, Hans Petter Selasky wrote:
> ...
> 
> Can you collect output from booting with bootverbose set? From current 
> amd64 as of today.

OK; I just copied it over; please see
; the dmesg in question
is dmesg.boot.11.0-CURRENT_amd64.  It is for:

FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #63  
r283005M/283005:1100073: Sat May 16 06:04:16 PDT 2015 
r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64

> Then repeat using i386.

For now, I've copied yesterday's head/i386 dmesg.  I'll copy over
my stable/10 dmesg.boot files, as well -- same directory; the names
will be similarly verbosely unambiguous. :-}  I'll copy today's head/i386
once I've generated it (which should be within a few minutes).

> Possibly some array is out of bounds or code has not been compiled
> properly. I just quickly counted the fmtlist size and from what I
> can see we are using 30 of 32 entries at least.

OK.

> Before that ensure /usr/obj is clean: "rm -rf /usr/obj"
> ...

OK.

On Sat, May 16, 2015 at 03:50:00PM +0200, Hans Petter Selasky wrote:
> ...
> > I'll admit that the vast bulk of my builds are done with -DNOCLEAN -- I
> > actually want to use my laptop for things other than rebuilding FreeBSD
> > (4x/day) and rebuilding updated installed ports (2x/day).
> 
> Then it will possibly trigger bad, because AFMT_CHANNELS() returns part 
> of the old EXT channels, which is used in the HDAA driver. If you want 
> to save time, you need to rebuild all of "modules/sound" only, w/o 
> -DNO_CLEAN and doing "clean" first. The rest of the kernel is fine with 
> -DNO_CLEAN.

To make things easier to understand and explain, I think it's best to 
go ahead and just do a clean build this time.  That should reduce
uncertainty a fair bit.

> ...
> Send output from bootverbose! Let's hunt this bug down :-)
> 

As above (along with a fair bit more information).

And hunting the bug down and ... disposing of it ... is my intent all
along -- thanks for your efforts!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgp7RTHuK7lfr.pgp
Description: PGP signature

Re: Deja vu: panic in hdaa_coonfigure() for i386, but not amd64 -- again

[David Wolfskill]

On Sat, May 16, 2015 at 03:27:57PM +0200, Hans Petter Selasky wrote:
> ...
> > After reverting both 282650 & 282651, the resulting kernel built.
> >
> 
> Hi,
> 
> I'm seeing two of my commits mentioned here, r282650 & r282651. Are 
> these what is causing the problem? You are sure the built the kernel and 
> all modules from clean, hence some structures are changed, panic would 
> be expected if you don't.
> 

I'll admit that the vast bulk of my builds are done with -DNOCLEAN -- I
actually want to use my laptop for things other than rebuilding FreeBSD
(4x/day) and rebuilding updated installed ports (2x/day).

After I finish the build I'm presently doing, I will try re-doing
r282650 & r282651, then rebuilding cleanly.

I noted that r282650 included a bump to param.h to force all modules to
be rebuilt.

I also note that the panic was only seen in head/i386 -- head/amd64 on
the same hardware, using the same procedures, sources updated from the
same local private mirror of the SVN repo, using a copy of the same
"CANARY" kernel config file, had no issue.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpWLhA_SFtda.pgp
Description: PGP signature