Re: Failing to build head@r292474 's rescue/rescue on 10.2-RELEASE-p7 / i386

[NGie Cooper]

(Fixed the subject line)

> On Dec 19, 2015, at 16:03, NGie Cooper <yaneurab...@gmail.com> wrote:
> 
> Hi,
>   I ran into the following error trying to build rescue/rescue as part of 
> buildworld on 10.2-RELEASE-p7 / i386. Has anyone seen this before?
> Thanks,
> -NGie
> 
> % git log --show-notes --grep svn -n 1
> commit 69774947bfffd5e16d26b60a82d880aa659abbf2
> Author: imp <i...@freebsd.org>
> Date:   Sat Dec 19 19:20:48 2015 +
> 
>   Move some MIPS specific flags to be more congruent with other
>   architectures.
> 
> Notes:
>   svn path=/head/; revision=292474
> 
> % env NO_CLEAN=1 make buildworld -j2
> ...
> --- rescue ---
> cc  -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo 
> date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo 
> kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo 
> rmdir.lo setfacl.lo sh.lo sleep.lo stty.lo sync.lo test.lo badsect.lo 
> camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo 
> dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo 
> geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo 
> ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo 
> mount_msdosfs.lo mount_nfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo 
> newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo 
> route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo 
> sysctl.lo tunefs.lo umount.lo ping6.lo zfs.lo zpool.lo bsdlabel.lo sconfig.lo 
> fdisk.lo dhclient.lo head.lo mt.lo nc.lo sed.lo tail.lo tee.lo gzip.lo 
> bzip2.lo less.lo xz.lo tar.lo id.lo zdb.lo chroot.lo chown.lo 
> /usr/obj/usr/src/git/rescue/rescue/../librescue/exec.o 
> /usr/obj/usr/src/git/rescue/rescue/../librescue/getusershell.o 
> /usr/obj/usr/src/git/rescue/rescue/../librescue/login_class.o 
> /usr/obj/usr/src/git/rescue/rescue/../librescue/popen.o 
> /usr/obj/usr/src/git/rescue/rescue/../librescue/rcmdsh.o 
> /usr/obj/usr/src/git/rescue/rescue/../librescue/sysctl.o 
> /usr/obj/usr/src/git/rescue/rescue/../librescue/system.o -lcrypt -ledit 
> -ljail -lkvm -lelf -ll -ltermcapw -lutil -lxo -l80211 -lalias -lcam 
> -lncursesw -ldevstat -lipsec -llzma -lavl -lzpool -lzfs_core -lzfs -lnvpair 
> -lpthread -luutil -lumem -lgeom -lbsdxml -lkiconv -lmt -lsbuf -lufs -lz -lbz2 
> -larchive -lcrypto -lmd -lm
> nc.lo: In function `_$$hide$$ nc.lo main':
> (.text+0x750): warning: warning: mktemp() possibly used unsafely; consider 
> using mkstemp()
> --- all_subdir_sbin ---
> --- ea.o ---
> cc  -O2 -pipe -O2 -pipe -I/usr/src/git/sbin/fsck_ffs 
> -I/usr/src/git/sbin/fsck_ffs/../mount   -g -MD -MP -MF.depend.ea.o -MTea.o 
> -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall 
> -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body 
> -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
> -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
> -Wno-knr-promoted-parameter -Qunused-arguments -c 
> /usr/src/git/sbin/fsck_ffs/ea.c -o ea.o
> --- fsutil.o ---
> cc  -O2 -pipe -O2 -pipe -I/usr/src/git/sbin/fsck_ffs 
> -I/usr/src/git/sbin/fsck_ffs/../mount   -g -MD -MP -MF.depend.fsutil.o 
> -MTfsutil.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror 
> -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body 
> -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
> -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
> -Wno-knr-promoted-parameter -Qunused-arguments -c 
> /usr/src/git/sbin/fsck_ffs/fsutil.c -o fsutil.o
> --- all_subdir_rescue ---
> /usr/obj/usr/src/git/tmp/usr/lib/libkvm.a(kvm.o): In function `_kvm_open':
> /usr/src/git/lib/libkvm/kvm.c:444: undefined reference to 
> `__start_set_kvm_arch'
> /usr/src/git/lib/libkvm/kvm.c:444: undefined reference to 
> `__stop_set_kvm_arch'
> /usr/src/git/lib/libkvm/kvm.c:444: undefined reference to 
> `__stop_set_kvm_arch'
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** [rescue] Error code 1
> 
> bmake[5]: stopped in /usr/obj/usr/src/git/rescue/rescue
> 1 error
> 
> bmake[5]: stopped in /usr/obj/usr/src/git/rescue/rescue
> *** [rescue] Error code 2
> 
> bmake[4]: stopped in /usr/src/git/rescue/rescue
> 1 error
> 
> bmake[4]: stopped in /usr/src/git/rescue/rescue
> *** [all] Error code 2
> 
> bmake[3]: stopped in /usr/src/git/rescue
> 1 error
> 
> bmake[3]: stopped in /usr/src/git/r

Re: clang/3.7.1/include/ does not exist?

[NGie Cooper]

> On Dec 28, 2015, at 18:39, Roger Marquis  wrote:
> 
> Anyone else seeing these buildworld errors?

...

>  /usr/obj/usr/src/tmp/usr/lib/clang/3.7.1/include/
>  install: target directory 
> `/usr/obj/usr/src/tmp/usr/lib/clang/3.7.1/include/' does not exist
>  usage: install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner]
> [-M log] [-D dest] [-h hash] [-T tags]
> [-B suffix] [-l linkflags] [-N dbdir]
> file1 file2
> install [-bCcpSsUv] [-f flags] [-g group] [-m mode] [-o owner]
> [-M log] [-D dest] [-h hash] [-T tags]
> [-B suffix] [-l linkflags] [-N dbdir]
> file1 ... fileN directory
> install -dU [-vU] [-g group] [-m mode] [-N dbdir] [-o owner]
> [-M log] [-D dest] [-h hash] [-T tags]
> directory ...
>  *** Error code 64
>  Stop.
>  make[4]: stopped in /usr/src/lib/clang/include
>  *** Error code 1

Hi Roger,
How are you executing buildworld? What’s your revision?
Thanks!
-NGie
___
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"

Bootstrapping from stable/9 to head?

[NGie Cooper]

Hi Ian and Warner,
I realize this isn’t a path that’s currently supported, but when I was 
running a test for jhb on stable/9 (ref9-amd64.freebsd.org to be exact), I ran 
into this error:

bmake[1]: "/scratch/tmp/ngie/svn/Makefile" line 466: "Target architecture for 
arm/conf/A20 unknown.  config(8) likely too old."
*** [universe_arm_kernels] Error code 1

bmake: stopped in /scratch/tmp/ngie/svn

I was wondering if there was a way where someone could more reliably 
bootstrap from stable/9 to stable/10, or if the directions just need to be 
changed to “upgrade to the latest release of 10, then upgrade to 11-CURRENT”?
Also, config is a build tool in Makefile.inc1… I was wondering if the 
check in Makefile is a bit too stringent / incorrect.
Thanks,
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Build from 9.3-RELEASE to 11.0-CURRENT fails for i386 (-Wsign-compare issues with gcc)

[NGie Cooper]

> On Dec 22, 2015, at 10:27, Garrett Cooper <yaneurab...@gmail.com> wrote:
> 
> 
>> On Dec 22, 2015, at 08:23, John Baldwin <j...@freebsd.org> wrote:
>> 
>>> On Monday, December 21, 2015 11:01:36 AM John Baldwin wrote:
>>>> On Saturday, December 19, 2015 01:05:36 PM NGie Cooper wrote:
>>>> Hi John,
>>>>   I tried bootstrapping 9.3-RELEASE to 11.0-CURRENT with i386 and ran into 
>>>> the -Wsign-compare issue below when running make libraries with 
>>>> buildworld, because it’s building libkvm with gcc 4.2.1 :/… I’ve tried 
>>>> bootstrapping with clang/clang37, but haven’t been able to yet. I’ll try 
>>>> installing 10.2-RELEASE via freebsd-update so I can use clang instead of 
>>>> gcc.
>>>> Thanks!
>>>> -NGie
>>> 
>>> We don't actually support going from 9 to 11.  However, these constants
>>> should probably be explicitly unsigned anyway.  I haven't tested this at
>>> all, but something like this:
>>> 
>>> Index: head/lib/libkvm/kvm_i386.h
>>> ===
>>> --- head/lib/libkvm/kvm_i386.h  (revision 292553)
>>> +++ head/lib/libkvm/kvm_i386.h  (working copy)
>>> @@ -57,8 +57,8 @@
>>> #defineI386_PG_PS  0x080
>>> #defineI386_PG_FRAME_PAE   (0x000ff000ull)
>>> #defineI386_PG_PS_FRAME_PAE(0x000fffe0ull)
>>> -#defineI386_PG_FRAME   (0xf000)
>>> -#defineI386_PG_PS_FRAME(0xffc0)
>>> +#defineI386_PG_FRAME   (0xf000u)
>>> +#defineI386_PG_PS_FRAME(0xffc0u)
>>> 
>>> #ifdef __i386__
>>> _Static_assert(PAGE_SHIFT == I386_PAGE_SHIFT, "PAGE_SHIFT mismatch");
>> 
>> This passed a universe build on HEAD.  If you can test that it fixes the 9.3 
>> -> 11.0
>> bootstrap I will commit it.
> 
> I'll fire up a 9.3 VM and give it a shot.
> Thanks :)!!

Hmm… no bueno on ref9-amd64. What likely needs to be done is that the directory 
needs to be built by itself with gcc on i386.
Thanks!
-NGie

cc1: warnings being treated as errors
In file included from /scratch/tmp/ngie/svn/lib/libkvm/kvm_i386.c:63:
/scratch/tmp/ngie/svn/lib/libkvm/kvm_i386.h:73: warning: comparison between 
signed and unsigned
*** [kvm_i386.So] Error code 1

bmake[5]: stopped in /scratch/tmp/ngie/svn/lib/libkvm
1 error

bmake[5]: stopped in /scratch/tmp/ngie/svn/lib/libkvm
*** [lib/libkvm__L] Error code 2

bmake[4]: stopped in /scratch/tmp/ngie/svn

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

Re: freebsd-current compile with clang & ccache

[NGie Cooper]

> On Nov 25, 2015, at 23:21, M - Krasznai András  
> wrote:
> 
> Thanks, but as far as I know WITH_CCACHE_BUILD is only for ports compilation 
> and novadays I use binary ports wherever I can.

It’s available in recent versions of FreeBSD CURRENT [1], [2] .
Cheers,
-NGie

1. https://lists.freebsd.org/pipermail/freebsd-arch/2015-November/017472.html
2. https://svnweb.freebsd.org/changeset/base/290526
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: r291443: 'ar9300/ar953x.ini' file not found #include "ar9300/ar953x.ini"

[NGie Cooper]

> On Nov 29, 2015, at 00:36, O. Hartmann  wrote:
> 
> CURRENT (At revision 291443.) fails building kernel with:
> 
> [...]
> make[2]: stopped in /usr/obj/usr/src/sys/GATE
> --- .depend ---
> /usr/src/sys/contrib/dev/ath/ath_hal/ar9300/ar9300_attach.c:45:10: fatal 
> error:
> 'ar9300/ar953x.ini' file not found #include "ar9300/ar953x.ini"

Some .ini files/directories seem to have been missed in the past few commits..
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Shared object "libelf.so.2" not found, required by "libkvm.so.6"

[NGie Cooper]

> On Nov 30, 2015, at 01:39, Konstantin Belousov  wrote:

…

> Just to explicitely state the obvious, the problem is that libkvm grown
> the dependency on libelf after r291406, and libelf lives in /usr. libkvm
> is used before /usr is mounted.
> 
> I do not know what is the best way to handle it. Most simple is to move
> libelf to /lib. How feasible is to move libkvm to /usr/lib (and all
> stuff in / which needs libkvm) is the open question.

This patch should fix the problem in theory: 
https://people.freebsd.org/~ngie/fix-libkvm-use-when-usr-and-root-split.patch
Thanks,
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r 291486: buildworld failure: ifieee80211.c:(.text+0xeb7b): undefined reference to

[NGie Cooper]

> On Nov 30, 2015, at 02:36, O. Hartmann  wrote:
> 
> It is hard to build a biuldworld buildkernel system these days :-(
> […]

…

Hi,
This issue should be fixed in r291491.
Thanks,
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Shared object "libelf.so.2" not found, required by "libkvm.so.6"

[NGie Cooper]

> On Nov 30, 2015, at 09:49, John Baldwin <j...@freebsd.org> wrote:
> 
> On Monday, November 30, 2015 09:33:49 AM NGie Cooper wrote:
>> 
>>> On Nov 30, 2015, at 01:39, Konstantin Belousov <kostik...@gmail.com> wrote:
>> 
>> …
>> 
>>> Just to explicitely state the obvious, the problem is that libkvm grown
>>> the dependency on libelf after r291406, and libelf lives in /usr. libkvm
>>> is used before /usr is mounted.
>>> 
>>> I do not know what is the best way to handle it. Most simple is to move
>>> libelf to /lib. How feasible is to move libkvm to /usr/lib (and all
>>> stuff in / which needs libkvm) is the open question.
>> 
>> This patch should fix the problem in theory: 
>> https://people.freebsd.org/~ngie/fix-libkvm-use-when-usr-and-root-split.patch
>> Thanks,
> 
> Looks fine to me if kib@ is ok with it.

I’ll run the patch through make tinderbox on ref11-amd64.
Thanks!
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Shared object "libelf.so.2" not found, required by "libkvm.so.6"

[NGie Cooper]

> On Nov 30, 2015, at 10:14, Konstantin Belousov <kostik...@gmail.com> wrote:
> 
> On Mon, Nov 30, 2015 at 09:49:00AM -0800, John Baldwin wrote:
>> On Monday, November 30, 2015 09:33:49 AM NGie Cooper wrote:
>>> 
>>>> On Nov 30, 2015, at 01:39, Konstantin Belousov <kostik...@gmail.com> wrote:
>>> 
>>> ???
>>> 
>>>> Just to explicitely state the obvious, the problem is that libkvm grown
>>>> the dependency on libelf after r291406, and libelf lives in /usr. libkvm
>>>> is used before /usr is mounted.
>>>> 
>>>> I do not know what is the best way to handle it. Most simple is to move
>>>> libelf to /lib. How feasible is to move libkvm to /usr/lib (and all
>>>> stuff in / which needs libkvm) is the open question.
>>> 
>>> This patch should fix the problem in theory: 
>>> https://people.freebsd.org/~ngie/fix-libkvm-use-when-usr-and-root-split.patch
>>> Thanks,
>> 
>> Looks fine to me if kib@ is ok with it.
> 
> I do not have objections.

Fix committed in r291566 — thanks :)!

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

Re: FYI: SVN to GIT converter currently broken, github is falling behind

[NGie Cooper]

Hi Ulrich,
This might be one of the reasons why the git converter was broken
recently: https://reviews.reviewboard.org/r/7617/diff (it seems that
svn is now reporting "nonexistent" for new files instead of "Revision
0"). It broke rbt with svn 1.9 :(...
Thanks!
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Failing buildword due to execution permission (with fix)

[NGie Cooper]

> On Nov 9, 2015, at 13:35, José Pérez  wrote:
> 
> Hello,
> I have this buildwordl failure:
> 
> ===> libexec/rbootd (depend)
> --- depend_subdir_lib ---
> --- aton_ether_subr.c ---
> /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr 
> /usr/src/sys/net/if_ethersubr.c ato
> n_ether_subr.c
> sh: /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr: Permission 
> denied
> *** [aton_ether_subr.c] Error code 126
> 
> 
> I fixed with:
> chmod +x /usr/src/contrib/netbsd-tests/lib/libc/net/gen_ether_subr
> 
> 
> This was from a fresh checkout of current on a new machine.
> 
> Is it me or shall I report a bug?

Hi José,
I’ve fixed the issue in r291172 (and no it wasn’t just you — I ran into 
the same problem from my git checkout later on, which was kind of interesting).
Thanks!
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Installworld fails with TMPDIR pointing to NFS mounted directory

[NGie Cooper]

> On Jan 12, 2016, at 08:42, Tom Vijlbrief  wrote:
> 
> If have this issue with 11-CURRENT on my raspberry 1 and 2, but I do not
> think it is raspberry related or even 11-CURRENT related.
> 
> export TMPDIR=/media/usbdisk/tmp
> 
> make installword MAKEOBJDIRPREFIX=/media/swan/obj

Hi Tom,
MAKEOBJDIRPREFIX should always be set via the environment, not the 
command line, e.g.

export MAKEOBJDIRPREFIX=/media/swan/obj
make installworld

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

Re: r301227: buildkernel fails in ibcore: error: too few arguments to function call, expected 7, have 6

[Ngie Cooper]

On Thu, Jun 2, 2016 at 1:15 PM, O. Hartmann  wrote:
>
> I receive this error while building a new kernel:

r301217 is the culprit. I've CCed gnn@ on another thread.
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: head r30140 - Panic String: _mtx_lock_sleep: recursed on non-recursive mutex vm page @ /usr/src/sys/vm/vm_page.c:774

[Ngie Cooper]

On Thu, Jun 2, 2016 at 3:05 PM, Michael Jung  wrote:
> On 2016-06-01 12:37, Michael Jung wrote:
>>
>> Since upgrading to head r301040 I have started to get the above panic
>> while running
>> poudriere while building packages for 10.3-STABLE r301107.
>>
>> Unfortuately I can't tell you the previous version of head but it was from
>> some
>> months ago.
>>
>>
>> https://charon.gopai.com/core.txt.7
>>
>> https://charon.gopai.com/info.7
>>
>> I also have the full core file if needed.
>>
>> Let me know what else I can provide.
>>
>> Thank you.
>
> Ideas? - there was another report of the same panic in vm_page.c
>
> http://postimg.org/image/r78vxopkb/
>
> I see from the web log 20+ people have looked at the core file
>
> I can bump my build server but I was awaiting a response to the panic
> before doing that.

It might have been fixed by r301212. CCing Kostik/Mark.
Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Streaming live tv over the udp protocol causes problems

[Ngie Cooper]

On Thu, Jun 2, 2016 at 3:25 PM, Oleg Lelchuk  wrote:
> I just solved this problem! I had to tweak the tunables
> net.inet.udp.recvspace and kern.ipc.maxsockbuf . After setting them to a
> larger value, I had no more problems streaming live tv. But it's
> interesting that I never had to tweak those tunables on 10.3-STABLE.

11.0-ALPHA1 might be running GENERIC (INVARIANTS, etc on). If so, it
kind of makes sense why the system was getting behind...
Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Virtualbox kernel module on 11-CURRENT

[Ngie Cooper]

> On Jun 7, 2016, at 01:04, Guido Falsi  wrote:
> 
>> On 06/07/16 02:23, Rafael Rodrigues Nakano wrote:
>> Hello,
>> 
>> I tried installing virtualbox from packages, building it from sources,
>> trying the GENERIC kernel but everytime I can't start the kernel module
>> 'vboxdrv', it says:
>> "KLD vboxdrv.ko: depends on kernel - not available or version mismatch.
>> linker_load_file: Unsupported file type"
> 
> The virtualbox module needs to be in full sync with the kernel. Most
> probably the sources being used by the cluster for building packages on
> head are a little different from yours, so the kernel module is not in sync.
> 
> You will need to build the kernel module yourself to actually match your
> kernel sources.
> 
> It's not really a problem or a bug, it's how it works. On head there is
> no warranty about the KBI. This cannot happen on releases and stable
> because the KBI is not going to change there.

Look for "PORTS_MODULES" (case sensitive) in "man 5 src.conf". I think that was 
the variable name for building ports during buildkernel and installing via 
installkernel. It's been a while though and it's harder to search for it on my 
smartphone..

Cheers,
-Ngie

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

Re: Borked 'pkg install xorg-minimal' on FreeBSD-11.0-ALPHA3-amd64-20160528-r301815-memstick.img

[Ngie Cooper]

> On Jun 12, 2016, at 14:42, Joe Ennis  wrote:
> 
> On a vinalla, first pkg added, zfs on root install:
> 
> # pkg install xorg-minimal
> ...
> ...
> ...
> [69/75] Extracting xf86-input-mouse-7.9.1_1: 100%
> [70/75] Installing linux_base-c6-6.7_3...
> sysctl: unknown oid 'compat.linux.release'
> linuxulator is not (kld) loaded, exiting
> pkg:PRE-INSTALL script failed
> #

Hi Joe,
Please file a port bug against linux_base-c6. At the very least the message 
should be more intuitive about what's trying to be achieved; you will need to 
"kldload linux", which was the status quo in old versions IIRC.
Thanks,
-Ngie

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

Re: Borked 'pkg install xorg-minimal' on FreeBSD-11.0-ALPHA3-amd64-20160528-r301815-memstick.img

[Ngie Cooper]

> On Jun 12, 2016, at 18:28, Michael Gmelin <free...@grem.de> wrote:
> 
> 
> 
> On Sun, 12 Jun 2016 18:11:03 -0400
> Ngie Cooper <yaneurab...@gmail.com> wrote:
> 
>>> On Jun 12, 2016, at 14:42, Joe Ennis <j...@boinkboink.org> wrote:
>>> 
>>> On a vinalla, first pkg added, zfs on root install:
>>> 
>>> # pkg install xorg-minimal
>>> ...
>>> ...
>>> ...
>>> [69/75] Extracting xf86-input-mouse-7.9.1_1: 100%
>>> [70/75] Installing linux_base-c6-6.7_3...
>>> sysctl: unknown oid 'compat.linux.release'
>>> linuxulator is not (kld) loaded, exiting
>>> pkg:PRE-INSTALL script failed
>>> #  
>> 
>> Hi Joe,
>>Please file a port bug against linux_base-c6. At the very least
>> the message should be more intuitive about what's trying to be
>> achieved; you will need to "kldload linux", which was the status quo
>> in old versions IIRC. Thanks, -Ngie
> 
> Requiring linux_base-c6 to install xorg-minimal seems wrong to me
> though.

Agreed. Are we adding nvidia-driver as a dependency, and is Linux support 
enabled by default?

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

Re: WITH_META_MODE vs. delete-old and delete-old-libs

[Ngie Cooper]

On Mon, Jun 13, 2016 at 2:12 PM, Mark Millard  wrote:
> I've been using the following script to run my make commands for amd64 builds 
> (as an example):
>
>> # more 
>> ~/sys_build_scripts.amd64-host/make_amd64_nodebug_clang_bootstrap-amd64-host.sh
>> kldload -n filemon && \
>> script 
>> ~/sys_typescripts/typescript_make_amd64_nodebug_clang_bootstrap-amd64-host-$(date
>>  +%Y-%m-%d:%H:%M:%S) \
>> env __MAKE_CONF="/root/src.configs/make.conf" 
>> SRC_ENV_CONF="/root/src.configs/src.conf.amd64-clang-bootstrap.amd64-host" \
>> WITH_META_MODE=yes \
>> MAKEOBJDIRPREFIX="/usr/obj/clang/amd64.amd64" \
>> make $*
>
> When the WITH_META_MODE=yes is present (as shown) delete-old and 
> delete-old-libs command line arguments to the script do not display the 
> prompts but the process does wait for the y/n answers. I've actually used top 
> in another window to see what it is waiting for an answer to. After I've 
> answered all the questions then the list of prompts finally is shown all at 
> once.
>
> Without WITH_META_MODE= each prompt text is displayed before it waits for the 
> answer to that prompt.
>
>
> This sort of fits in with my earlier questions about make usage that is in 
> the likes of, say, mergemaster and if/where care about WITH_META_MODE=yes use 
> vs. disuse might be important for such. For example: Should "env 
> WITH_META_MODE=yes" be used with mergemaster if it was used with buildworld, 
> buildkernel, installkernel, and installworld?

I generally do:

yes | sudo make delete-old

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

Re: WITH_META_MODE vs. delete-old and delete-old-libs

[Ngie Cooper]

On Mon, Jun 13, 2016 at 2:52 PM, Bryan Drewery  wrote:
...
> The problem is that the y/n prompt don't show at all.

Ah, I missed that critical point...

Maybe MK_META_MODE=no should be forced for those targets?
Thanks,
-Ngie
___
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"

exports(5) no longer allows multiple paths per line?

[Ngie Cooper]

Hi,
It seems like the following /etc/exports should work, but for some
odd reason specifying both paths on a single line doesn't work (I
swore it was working on a kernel/userland built in the past month,
i.e. ^/head@r297950, but I might be misremembering things).
exports(5) claims that 2 mountpoints (at least) can be used on a
single line, but my experiments prove otherwise.
Thanks,
-Ngie

Example from exports(5):

EXAMPLES
   /usr /usr/local -maproot=0:10 friends

Failing example:

# df -h /tftpboot /home/ngie
Filesystem SizeUsed   Avail Capacity  Mounted on
zroot/tftpboot 232G1.2G231G 1%/tftpboot
zroot/home/ngie236G5.5G231G 2%/home/ngie
# cat /etc/exports
/home/ngie/freebsd /tftpboot -maproot=0:0 -alldirs -ro
# stat -f '%d %r %N' /tftpboot/ /home/ngie
3945781817 4294967295 /tftpboot/
3049773785 4294967295 /home/ngie
# showmount -e
Exports list on localhost:
#

Working example:

# service mountd start
Starting mountd.
# showmount -e
Exports list on localhost:
/tftpboot  Everyone
/home/ngie/freebsd Everyone

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

Re: mfi timeouts at boot on ASUS Z97 motherboard with LSI 9240-4i

[Ngie Cooper]

On Thu, Apr 9, 2015 at 12:10 AM, Garrett Cooper  wrote:
...
> It booted both FreeBSD/Linux without my controller — the hardware 
> compatibility with it just sucks.
>
> Email back from ASUS, “it’s not in our compatibility list. Use another card”. 
> Uh, yeah… right. Not going to dump another $300 in an LSI card and redo my 
> RAID. Guess I’ll purchase another motherboard.
>
> Thank you for the input everyone. I’ll leave a helpful review on Newegg so 
> others don’t stumble on this either.

(following up/closing out the thread from last year on a more constructive note)

I recently had to replace my P6T-WS motherboard/CPU because it finally
bit the dust (it was 7 years old). I found a ASUS desktop board that
worked with the before mentioned LSI card -- ASUS Z170M-E D3. The
compatibility list didn't mention my LSI card specifically, but it
said that they validated the 9260-4i card, which was "close enough"
apparently.

The card's detected properly at POST, it attaches in FreeBSD, and the
volume looks AOK. The only thing that's slightly annoying is that the
chipset does some silly things with the onboard graphics when I plug
it in initially (I believe it thinks it's a graphics card..), so I had
to tweak some BIOS settings.

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

Re: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

[Ngie Cooper]

On Fri, Jun 24, 2016 at 9:50 PM, Mark Millard  wrote:
> On 2016-Jun-24, at 2:50 PM, Alan Somers  wrote:
>
>> As of r302180., the usr.sbin/rpcbind, sys/acl, and sys/sys/bitstring
>> tests should all be fixed.  I opened PR 210329 for the
>> usr.bin/lastcomm test.  I haven't investigated the others.

...

> This time the totals were 15 broken (down from 24) and 41 failed (down
> from 59).
>
> My results this time were. . .

Hi Mark,
Please file bugs for all of the individual component failures,
e.g. lib/msun, and CC me on the bugs.
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Packaging the FreeBSD base system with pkg(8)

[NGie Cooper]

> On Jan 28, 2016, at 08:06, Slawa Olhovchenkov  wrote:


...

> What about upgrade strongly outdated system?
> For example 11.0 at time 18.0? I.e. packages for 11.0 don't available,
> pkg from 11.0 don't undertund package base from 18.0 and etc.

This is an important question to ask and solve. There might be points in time 
where seamless upgrades are not possible, and instead you need to hop from 
release to release (this is not ideal, but it could happen).

For instance, at $work we're allowing upgrades from version X to Y, and Y to Z, 
but not direct upgrades from X to Z. Part of the rationale behind this change 
is, deprecation of platforms and the change in upgrade framework, which 
requires upgrading from blessed releases proven to work with the new framework.

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

Re: Packaging the FreeBSD base system with pkg(8)

[NGie Cooper]

> On Jan 28, 2016, at 08:09, Allan Jude  wrote:

...

> According to our current release schedule, FreeBSD 18.0 will not come
> out for 35 years (2051).
> 
> The general approach would appear to be just downloading new packages
> and updating the system. For a drastic upgrade like that, you'd likely
> have to build a newer version of pkg from ports.
> 
> The approach for offering an upgrade from 10.x to 11.0 will be the more
> interesting endeavour.

I would actually say "don't do that (upgrade from 10 to 11 via pkg). Use 
freebsd-update instead, then upgrade to 11.1 or 12.0 via pkg". The rationale 
for this is that if you install the package from 10.x, and need to downgrade 
for whatever reason, you'll likely be dealing with a reinstall or a VM/zfs 
rollback as opposed to being able to install a downgraded base system/kernel 
package.

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

Re: Packaging the FreeBSD base system with pkg(8)

[NGie Cooper]

> On Jan 28, 2016, at 09:38, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> 
>> On Thu, Jan 28, 2016 at 09:28:32AM -0800, NGie Cooper wrote:
>> 
>> 
>>> On Jan 28, 2016, at 08:06, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
>> 
>> 
>> ...
>> 
>>> What about upgrade strongly outdated system?
>>> For example 11.0 at time 18.0? I.e. packages for 11.0 don't available,
>>> pkg from 11.0 don't undertund package base from 18.0 and etc.
>> 
>> This is an important question to ask and solve. There might be
>> points in time where seamless upgrades are not possible, and instead
>> you need to hop from release to release (this is not ideal, but it
>> could happen).
> 
> I see two side of this problem: support in sofware and support in
> infrastructure (ftp.freebsd.org and etc.). Because pkg is not part of
> base FreeBSD and live in ports -- this hops need to preserve (and
> testing?) packages collections for all past releases and don't move it
> to archive. And regular resigning package databases. And I miss
> somewere.
> 
>> For instance, at $work we're allowing upgrades from version X to Y,
>> and Y to Z, but not direct upgrades from X to Z. Part of the
>> rationale behind this change is, deprecation of platforms and the
>> change in upgrade framework, which requires upgrading from blessed
>> releases proven to work with the new framework.
> 
> This is common practic, yes.
> This is acceptably if possible got all necessary in time 18.0 for
> upgrade from 11.0.

Yes. Given the hiccups going from pkg 1.4 to 1.6 with the plist stuff, this is 
going to be more entertaining across interface breaks; it might be that pkgng 
is at the point where it's stable enough that interfaces won't change 
(unlikely, software tends to be fluid), or backwards compatibility will need to 
be maintained for older versions of pkgng.

Also, consider that you're going to be allowing upgrades from older RELEASE 
versions of the OS which might be using a fixed copy of pkgng -- how are you 
going to support that?

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

Re: Realtek 8168/8111 if_re not working in current r295091

[NGie Cooper]

> On Feb 3, 2016, at 11:57, s@web.de wrote:
> 
> After updating -current at Jan, 31st (r295091) the Realtek ethernet device 
> driver of my Zotac ZBox RI323 mini pc seems to be broken: I can neither 
> connect to the host even though the interface is shown as active, nor can I 
> initiate connection from the host through re0.
> Reverting the kernel to my previous build -current r290151 (install date Nov 
> 1st, 2015) the re0 interface is working OK.
> 
> Looking through the svn logs regarding /head/sys/dev/re/if_re.c I supect, 
> that Revision 290566 might have someting to do with this and that I have to 
> include my Realtek Chipset to the exclusion list for "enabling RX/TX after 
> initial configuration (or viceversa; I am really confused here), but I havent 
> got a clue how; as I do not know how to find the right RL_HWREV_XXX flag for 
> my device.
> 
> dmesg shows RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet and 
> pciconf -l -v re0 shows:
> re0@pci0:2:0:0: class=0x02 card=0x816819da chip=0x816810ec rev=0x07 
> hdr=0x00
> vendor = 'Realtek Semiconductor Co., Ltd.'
> device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
> 
> I am grateful for any suggestion towards a solution and I am willing (and 
> able) to assist by patching or debugging my kernel or giving further hw 
> information about my system.
> 
> Regards, Stefan

Could you please file a bug and CC the relevant committer?
Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Requesting MFC's

[NGie Cooper]

On Wed, Feb 3, 2016 at 6:32 PM, Matthew Grooms  wrote:
> All,
>
> What is the correct way to request that patches be committed to STABLE? In
> particular, I'd really like to see these in 10.3-RELEASE as they have been
> required to build a working firewall in some cases. All are related to
> problems that were fixed in HEAD, but never MFC'd ...
>
> https://svnweb.freebsd.org/base?view=revision=264915
> https://svnweb.freebsd.org/base?view=revision=272695
> https://svnweb.freebsd.org/base?view=revision=288529
>
> Thanks in advance,

Email the committer about MFCing the change (or another party that has
sufficient means to understand the change and potentially test it)?
Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: buildworld failure due to nvmecontrol source error

[NGie Cooper]

> On Jan 30, 2016, at 04:10, Outback Dingo  wrote:
> 
> On Sat, Jan 30, 2016 at 12:39 PM, O. Hartmann 
> wrote:
> 
>> Buildworld (r295070) fails in building nvmecontrol patches correctly:
>> 
>> [...]
>> (cd /usr/src/lib/libc/tests/gen &&  DEPENDFILE=.depend.raise_test
>> NO_SUBDIR=1 make
>> -f /usr/src/lib/libc/tests/gen/Makefile _RECURSING_PROGS=t
>> PROG=raise_test ) ---
>> all_subdir_share --- ===> share/i18n/csmapper/APPLE (all)
>> --- all_subdir_usr.sbin ---
>> ===> usr.sbin/acpi/iasl (all)
>> --- all_subdir_sbin ---
>> /usr/src/sbin/nvmecontrol/power.c:44:16: error: invalid application of
>> 'sizeof' to an
>> incomplete type 'struct nvme_power_state' _Static_assert(sizeof(struct
>> nvme_power_state)
>> == 256 / NBBY, ^ ~
>> /usr/src/sbin/nvmecontrol/power.c:44:30: note: forward declaration of
>> 'struct
>> nvme_power_state' _Static_assert(sizeof(struct nvme_power_state) == 256 /
>> NBBY,
>> ^
>> /usr/src/sbin/nvmecontrol/power.c:60:14: error: incomplete definition of
>> type 'struct
>> nvme_power_state' mpower = nps->mp;
>> ~~~^
>> /usr/src/sbin/nvmecontrol/power.c:44:30: note: forward declaration of
>> 'struct
>> nvme_power_state' _Static_assert(sizeof(struct nvme_power_state) == 256 /
>> NBBY,
>> ^
>> /usr/src/sbin/nvmecontrol/power.c:61:9: error: incomplete definition of
>> type 'struct
>> nvme_power_state' if (nps->mps == 0)
> 
> same here to confirm
> cc  -pg  -O2 -pipe
> -I/backup/freebsd/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken
> -I.   -DHAVE_CONFIG_H
> -I/backup/freebsd/kerberos5/lib/libroken/../../include -std=gnu99 -fstack
> -protector-strong-Qunused-arguments -c
> /backup/freebsd/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken/eread.c
> -o eread.po
> --- all_subdir_secure ---
> cc  -pg  -O2 -pipe
>  -I/backup/freebsd/secure/lib/libcrypto/../../../crypto/openssl -DTERMIOS
> -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN
> -DOPENSSL_IA32_SSE2 -DAES
> _ASM -DBSAES_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DOPENSSL_BN_ASM_MONT
> -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DMD5_ASM -DGHASH_ASM
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DWHIRLPOOL_ASM
> -I/usr/obj/backup/freebsd/secure/lib/libcrypto
> -I/backup/freebsd/secure/lib/libcrypto/../../../crypto/openssl/crypto
> -I/backup/freebsd/secure/lib/libcrypto/../../../crypto/openssl/crypto/a
> sn1
> -I/backup/freebsd/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp
> -I/backup/freebsd/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes
> -std=gnu89 -fstack-protector-strong
> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conve
> rsion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum
> -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments -c
> /backup/freebsd/secure/lib/libcrypto/../../../crypto/openssl
> /crypto/evp/m_md5.c -o m_md5.po
> --- all_subdir_sbin ---
> /backup/freebsd/sbin/nvmecontrol/power.c:44:16: error: invalid application
> of 'sizeof' to an incomplete type 'struct nvme_power_state'
> _Static_assert(sizeof(struct nvme_power_state) == 256 / NBBY,
>  ^ ~
> /backup/freebsd/sbin/nvmecontrol/power.c:44:30: note: forward declaration
> of 'struct nvme_power_state'
> _Static_assert(sizeof(struct nvme_power_state) == 256 / NBBY,
>^
> /backup/freebsd/sbin/nvmecontrol/power.c:60:14: error: incomplete
> definition of type 'struct nvme_power_state'
>   mpower = nps->mp;
>~~~^
> /backup/freebsd/sbin/nvmecontrol/power.c:44:30: note: forward declaration
> of 'struct nvme_power_state'
> _Static_assert(sizeof(struct nvme_power_state) == 256 / NBBY,
>^
> /backup/freebsd/sbin/nvmecontrol/power.c:61:9: error: incomplete definition
> of type 'struct nvme_power_state'
>   if (nps->mps == 0)
>   ~~~^
> /backup/freebsd/sbin/nvmecontrol/power.c:44:30: note: forward declaration
> of 'struct nvme_power_state'
> _Static_assert(sizeof(struct nvme_power_state) == 256 / NBBY,
>^
> /backup/freebsd/sbin/nvmecontrol/power.c:63:14: error: incomplete
> definition of type 'struct nvme_power_state'
>   ipower = nps->idlp;
>~~~^
> /backup/freebsd/sbin/nvmecontrol/power.c:44:30: note: forward declaration
> of 'struct nvme_power_state'
> _Static_assert(sizeof(struct nvme_power_state) == 256 / NBBY,
>^
> /backup/freebsd/sbin/nvmecontrol/power.c:64:9: error: incomplete definition
> of type 'struct nvme_power_state'
>   if (nps->ips == 1)
>   ~~~^
> /backup/freebsd/sbin/nvmecontrol/power.c:44:30: note: forward declaration
> of 'struct nvme_power_state'
> _Static_assert(sizeof(struct 

Re: IoT OS

[NGie Cooper]

> On Jan 21, 2016, at 08:34, Jan Bramkamp  wrote:
> 
>> On 21/01/16 17:19, Mathieu Prevot wrote:
>> Dear all,
>> 
>> I would like to connect several connected object (with homogeneous or
>> heterogenous hardare: intel edison,  samsung artik, apple AX, intel core,
>> etc) so the calculation needs, the storage/memory, the connection, etc are
>> decoupled; hence we can reach an ecosystem with several clouds.
>> 
>> How do you recommend to reach that ? from the kernel, a module, or
>> eventually a software ?
> 
> Your message contains neither enough information nor a precise enough 
> question for anyone to provide you a helpful answer.
> 
> Please describe your problem in sufficient detail and reformulate your 
> question. If you still think these mailing lists (current@ and hackers@) are 
> a good audience for your question afterward ask them again.

It depends on your workload and hardware requirements (there isn't a simple 
answer to your question because you didn't describe what you needed with 
concrete requirements).

I would talk to cem@. He's working on ioat(4) on head for us ($work).
Thanks,
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: IoT OS

[NGie Cooper]

On Thu, Jan 21, 2016 at 8:38 AM, NGie Cooper <yaneurab...@gmail.com> wrote:
...
> I would talk to cem@. He's working on ioat(4) on head for us ($work).

I misunderstood the terms a bit. IoT (Internet of Things) != iaot(4) (
Intel I/O Acceleration Technology ).
Thanks,
-NGie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel ULE related breakage

[Ngie Cooper]

On Thu, Feb 18, 2016 at 2:10 PM, Michal Suszko  wrote:
>
> Hi,
> Got this error compiling GENERIC with s/4BSD/ULE/ on recent -CURRENT
> ( wrapped long lines )
>
> cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs
>   -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
>   -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I.
>   -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica
>   -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath
>   -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h
>   -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2
>   -ffreestanding -Werror /usr/src/sys/kern/sched_ule.c
> cc1: warnings being treated as errors
> /usr/src/sys/kern/sched_ule.c: In function `sched_setup':
> /usr/src/sys/kern/sched_ule.c:531: warning: unused variable `i'
> *** Error code 1
>
> Stop in /usr/obj/usr/src/sys/TEST.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
> Stop in /usr/src.

I'm not sure what you're running, but it doesn't look like untainted CURRENT.

1. Please post `TEST` somewhere in pastebin.
2. Please note what revision you're on, whether you're forked from
another version, etc.

Thanks,
-Ngie

 526 /*
 527  * Load is maintained for all threads RUNNING and ON_RUNQ.  Add the load
 528  * for this thread to the referenced thread queue.
 529  */
 530 static void
 531 tdq_load_add(struct tdq *tdq, struct thread *td)
 532 {
 533
 534 TDQ_LOCK_ASSERT(tdq, MA_OWNED);
 535 THREAD_LOCK_ASSERT(td, MA_OWNED);
 536
 537 tdq->tdq_load++;
 538 if ((td->td_flags & TDF_NOLOAD) == 0)
 539 tdq->tdq_sysload++;
 540 KTR_COUNTER0(KTR_SCHED, "load", tdq->tdq_loadname, tdq->tdq_load);
 541 SDT_PROBE2(sched, , , load__change, (int)TDQ_ID(tdq),
tdq->tdq_load);
 542 }
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Keeping OptionalObsoleteFiles.inc up to date

[Ngie Cooper]

On Thu, Apr 7, 2016 at 1:59 PM, Olivier Cochard-Labbé
 wrote:
> Hi,
>
> I'm trying to use "make delete-old" specifying WITHOUT_ keyword for
> removing some no-more used set of files.
>
> I've start by testing WITHOUT_TOOLCHAIN:
> - Some of files related to clang are correctly delete
> - But there are still lot's of others (like /usr/bin/cc)
>
> Then I've checked tools/build/mk/OptionalObsoleteFiles.in and found that
> lot's files are missing in the ".if ${MK_TOOLCHAIN} == no" section.
>
> I've started a new run of phk's build_options_survey script:
> https://people.freebsd.org/~olivier/build_option_survey_20160406/
>
> And wonder if it's possible to automatically generate the list of
> conditional files to be put in OptionalObsoleteFiles.in from the result of
> a build_option_survey script ?

amdmi3 had a method for doing this, but I think it was a bit of a
brute force approach (I could be wrong).

The release-pkg project branch method seems like the best way to go
about it though because it would kind of do the sanity checking for
us...

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

Re: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))

[NGie Cooper]

> On Apr 24, 2016, at 05:34, Daniel Eischen  wrote:
> 
>> On Sat, 23 Apr 2016, Warner Losh wrote:
>> 
>> On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen 
>> wrote:
>> 
>>> [CC trimmed]
>>> 
 On Fri, 22 Apr 2016, Warner Losh wrote:
 
 
 I personally will be refraining from engaging further. I plan on seeing
 what gaps there are by adding support to NanoBSD for packages. I'll be
 busy
 with that. In talking to Glen and others, we've already identified a few
 easy gaps to fill. Once they've done that, I'll get going on NanoBSD with
 the goal to be able to use it to build a bootable system of any
 architecture from packages with no root privs. I expect to find issues,
 but
 I don't expect to find any issue that's intractable. I expect after the
 issues are resolved, the end product will be better for everybody.
>>> 
>>> Thank you for working on NanoBSD.  Do you think it would be possible
>>> to add support for optionally building dump(8) images instead of dd?
>> 
>> 
>> What do you  mean by that, exactly? It would be relatively easy to add
>> a step that runs dump on the _.disk.image file and squirrel that away.
>> Last orders the code currently calls it, I believe. Is it something as
>> simple
>> as this, or is there some more complexity that I'm failing to understand
>> or grasp?
> 
> Perhaps I'm missing something, but when last_orders() is called,
> isn't the disk already unmounted and 'mdconfig -d -u' already
> run?

Yup.

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

Re: Followup on packaging base with pkg(8)

[Ngie Cooper]

On Thu, May 19, 2016 at 1:31 PM, Glen Barber  wrote:
> Dear FreeBSD community:

...

> Thank you to everyone who supported this effort, and we hope you will
> continue to support and test the forward development of packaging the
> base system with pkg(8).

Thank you too both bapt and gjb. This is a non-trivial effort to
achieve and what's been done so far is a really good first milestone.

I think it's a good idea to get beta feedback for 11.x... It'll allow
the design to get a wider audience and allows it to get some runtime
beyond CURRENT, that way it can mature and improve before too many of
the pieces are put in a place that it'll be hard to change once things
have been setup in a production way.

Thank you again!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT (r298939): kernelbuild failure: _cpuset.h:50:1: error: use of undeclared identifier 'NBBY'

[Ngie Cooper]

On Mon, May 2, 2016 at 1:10 PM, O. Hartmann  wrote:
> CURRENT (r298939) kernelbuild fails due to the error shown below:
>
> [...]
> In file included from /usr/src/lib/libdevctl/devctl.c:31:
> In file included from /usr/obj/usr/src/tmp/usr/include/sys/bus.h:35:
> /usr/obj/usr/src/tmp/usr/include/sys/_cpuset.h:50:1: error: use of undeclared 
> identifier
> 'NBBY' /usr/obj/usr/src/tmp/usr/include/sys/_bitset.h:52:24: note: expanded 
> from macro
> 'BITSET_DEFINE' long__bits[__bitset_words((_s))]; 
>   \
>^
> /usr/obj/usr/src/tmp/usr/include/sys/_bitset.h:41:41: note: expanded from 
> macro
> '__bitset_words' #define __bitset_words(_s)  (howmany(_s, _BITSET_BITS))

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

Re: CURRENT: memory leak?

[Ngie Cooper]

On Fri, Jul 29, 2016 at 12:03 PM, Allan Jude  wrote:
> On 2016-07-29 14:04, O. Hartmann wrote:
>>
>> I realise an exorbitant memory usage of FreeBSD CURRENT ( FreeBSD
>> 12.0-CURRENT #16
>> r303470: Fri Jul 29 05:58:42 CEST 2016 ). Swap space gets eaten up while
>> building
>> world/kernel and/or ports very quickly.
>>
>> I see this phenomenon on different CURRENT systems with different RAM (but
>> all ZFS!). No
>> box is less than 8 GB RAM: one 8GB, another 16, two 32 GB. An older XEON
>> Core2Duo server
>> with postgresql 9.5/postgis acting on some OSM data etas up all of its 32
>> GB and
>> additional 48GB swap - never seen before with 11-CURRENT.
>>
>> I didn't investigate the problem so far since I realized this memory
>> hunger of 12-CURRENT
>> just today on several boxes compiling world, eating up all the memory,
>> staring swapping
>> and never relax even after hours from the swapped memory.
>>
>> Is this a known phenomenon or am I seeing something mystique?
>>
>> Regards,
>>
>> Oliver
>>
>
> Do you have the output of 'top', the first few lines
>
> Specifically, is there very high 'Other' usage, on the ZFS ARC line?

`vmstat -Hm | sort -rnk 2,3 | head -n 10` might be helpful if the
memory used is in kernel space.
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: memory leak?

[Ngie Cooper]

On Fri, Jul 29, 2016 at 12:52 PM, O. Hartmann
 wrote:

...

> This is after starting VBox and a Win 7 pro guest (just started, no login) 
> with 3572 MB
> memory reserved and 4 logical CPUs (VBox 5.0.26):
>
> root@localhost: [ports] vmstat -Hm | sort -rnk 2,3 | head -n 10
>   solaris 53030 62088K   - 23000705
> 16,32,64,128,256,512,1024,2048,4096,8192,32768 devbuf 20600 39751K   -
> 21380
> 16,32,64,128,256,512,1024,2048,4096,8192,16384,65536 iprtheap  9335 16498K
>-
> 12303  32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536 nvidia  8162 
> 21261K
> -   549305  16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536 
> sysctloid  6004
> 309K   - 6125  16,32,64,128 acpica  5605   574K   -65245
> 16,32,64,128,256,512,1024,2048,4096 umtx  1728   216K   - 1728  128
>   ufs_dirhash  1543   678K   - 7175  16,32,64,128,256,512,1024,2048
>   pmc  1066  6679K   - 1066  
> 16,32,128,256,512,1024,4096,8192,65536
>   kdtrace   950   218K   -   113551  64,256

Could you please paste this in a pastebin or something? It's formatted
weird in my "mail client" (Gmail).
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Mosh regression between 10.x and 11-stable

[Ngie Cooper]

> On Aug 11, 2016, at 09:30, John Hood  wrote:
> 
> I still can't reproduce this on 3 different 11.0-BETA4 servers and a
> variety of clients and networks.  Can you try and identify a more
> portable repro or at least figure out why it fails on your system?
> 
> Please try applying this patch, too.  It's a shot in the dark, though.

Dumb question: what ssh key type(s) (dsa, rsa, etc) are you using Peter :)?
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Passwordless accounts vi ports!

[Ngie Cooper]

> On Aug 10, 2016, at 22:05, O. Hartmann  wrote:
> 
> I just checked the security scanning outputs of FreeBSD and found this
> surprising result:
> 
> [...]
> Checking for passwordless accounts:
> polkitd::565:565::0:0:Polkit Daemon User:/var/empty:/usr/sbin/nologin
> pulse::563:563::0:0:PulseAudio System User:/nonexistent:/usr/sbin/nologin
> saned::194:194::0:0:SANE Scanner Daemon:/nonexistent:/bin/sh
> clamav::106:106::0:0:Clamav Antivirus:/nonexistent:/usr/sbin/nologin
> bacula::910:910::0:0:Bacula Daemon:/var/db/bacula:/usr/sbin/nologin
> [...]
> 
> Obviously, some ports install accounts but do not secure them as there is an
> empty password.
> 
> I consider this not a feature, but a bug.

saned is the only one that might concern me because the login shell isn't 
nologin(1).

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

Re: 11.0-BETA1 make installworldworld fails

[Ngie Cooper]

> On Jul 17, 2016, at 12:58, Kim Culhan  wrote:
> 
> Seeing this on FreeBSD 11.0-BETA1 #0 r302963M
> 
> After make buildworld completes with no problem, then rebooted in
> single-user mode
> 
> in /usr/src:
> 
> make installworld
> 
> --
 Installing everything
> --
> cd /usr/src; make -f Makefile.inc1 install
> ===> lib (install)
> ===> lib/csu (install)
> ===> lib/csu/amd64 (install)
> cc -target x86_64-unknown-freebsd11.0 --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe
> -I/usr/src/lib/csu/amd64/../common
> -I/usr/src/lib/csu/amd64/../../libc/include -fno-omit-frame-pointer
> -std=gnu99  -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
> -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs
> -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wthread-safety
> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
> -Qunused-arguments  ERROR-tried-to-rebuild-during-make-install -S -o crt1.s
> /usr/src/lib/csu/amd64/crt1.c
> *** Error code 127
> Stop.
> make[6]: stopped in /usr/src/lib/csu/amd64
> *** Error code 1
> 
> Hope this helps.

Run "make buildworld -DNO_CLEAN" (see the error above about 
"ERROR-tried-to-rebuild-during-make-install".

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

Re: sr-iov's virtual function driver shipped broken?

[Ngie Cooper]

> On Jul 12, 2016, at 11:21, Ultima  wrote:
> 
> I'v mentioned this in the past, but I just want to verify. Will 11 be
> released with the virtual function driver unusable? Currently iovctl will
> only work in pass-through mode.

Hi,
Is there a bug open for this issue with a repro/more details?
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [Bug 210953] 11.0 -r302412 via powerpc64-xtoolchain-gcc fails to build: dev/ahci/ahci.c:288:22: error: unknown conversion type character 'b' in format; too many arguments for format

[Ngie Cooper]

> On Jul 9, 2016, at 23:03, Mark Millard <mar...@dsl-only.net> wrote:
> 
> On 2016-Jul-9, at 8:53 PM, Ngie Cooper  wrote:
> 
>>> On Jul 9, 2016, at 18:52, bugzilla-nore...@freebsd.org wrote:
>>> 
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210953
>>> 
>>> Mark Millard <mar...@dsl-only.net> changed:
>> 
>> I accidentally committed this regression to kern.mk. I don't have bugzilla 
>> login right now. Please assign the bug to me and I'll mark it fixed for the 
>> rev I did it in with head and stable/10.
>> 
>> Thanks!
>> -Ngie
> 
> So far as I know I've no control over the Assignee field for any bug via 
> bugzilla. Someone that has such can do what Ngie requested and assign 210953 
> to him.
> 
> A rebuild based on -r302457 completed fine for the powerpc64-gcc use, 
> confirming Ngie's note, at least for 11.0-STABLE.
> 
> I've no stable/10 context and so have not tested there. Otherwise I might 
> have just classified the report as "Overcome By Events" myself.
> 
> I have added a comment to 210953 about my rebuild test and Ngie's material 
> above.

stable/10 was a typo. I meant stable/11.

No worries.. I'll take care of it when I get home soon.

Thanks!

> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: LOR on 11.0-ALPHA5 amd64

[Ngie Cooper]

> On Jul 4, 2016, at 07:04, René Ladan  wrote:
> 
> Hi,
> 
> I got this LOR today on a 11.0-ALPHA5 amd64 (FTP installation)
> instance running in Virtualbox 5.0.24 r108355 with Windows 10 as a
> host:
> 
> 1st ufs (ufs) @ /usr/src/sys/ufs/ufs/ufs_vnops.c:1157
> 2nd bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:263
> 3rd ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2523
> 
> Perhaps this is a well-known LOR ? It happened when updating the src
> tree with svnlite.

Yup.. It's pretty well known.

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

Re: security/openvpn build failure on 12-CURRENT/amd64

[Ngie Cooper]

On Mon, Aug 1, 2016 at 7:31 AM, Shawn Webb  wrote:

...

> HardenedBSD's kernel and world matched and still had the very same
> build error.
>
> Here's the build log: http://pastebin.com/TEBih1Sx

Confirmed -- why's it looking for tcp6local/udp6local though (this
isn't a valid protocol, and for some odd reason it's being picked up
from the sample config file..?)? Looks like a port bug...
Thanks,
-Ngie

$ sudo make -C /usr/ports/security/openvpn build
...
PASS: t_lpback.sh
The following test will take about two minutes.
If the addresses are in use, this test will retry up to two times.
Options error: Bad protocol: 'udp6local'.  Allowed protocols with
--proto option: [proto-uninitialized] [udp] [tcp-server] [tcp-client]
[tcp] [udp6] [tcp6-server] [tcp6-client] [tcp6]
Use --help for more information.
Options error: Bad protocol: 'udp6local'.  Allowed protocols with
--proto option: [proto-uninitialized] [udp] [tcp-server] [tcp-client]
[tcp] [udp6] [tcp6-server] [tcp6-client] [tcp6]
Use --help for more information.
FAIL: t_cltsrv.sh

1 of 2 tests failed
(1 test was not run)
Please report to openvpn-us...@lists.sourceforge.net

*** [check-TESTS] Error code 1
$ grep -r udp6local work/
work/openvpn-2.3.11/sample/sample-config-files/loopback-client.test:proto
udp6local ::1
work/openvpn-2.3.11/sample/sample-config-files/loopback-server.test:proto
udp6local ::1
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 'Protocol not supported' on linux socket call ( r313313 amd64 )

[Ngie Cooper]

> On Feb 8, 2017, at 07:44, Oleg V. Nauman  wrote:
> 
> After upgrading of current on amd64 box to r313313 I noticed that skype has 
> stopped working.
> Below is the end of 'truss' output for skype:
> 
> 36723: linux_socketcall(1,{ LINUX_SOCKET, 0x0 }) ERR#-93 'Protocol not 
> supported'
> 36723: write(6,"@",1) = 1 (0x1)
> 36723: close(6)= 0 (0x0)
> 36723: close(5)= 0 (0x0)
> 36723: linux_rt_sigaction(0x11,0xbaf8,0xba6c,0x8) = 0 (0x0)
> 36723: linux_exit_group(0x1)
> 36723: process exit, rval = 1
> 
> My second current box ( r313090 i386 ) runs skype successfully.

Hi,
Please try reverting r312988.
Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

> On Jan 27, 2017, at 09:05, Warner Losh  wrote:

...

> I'm curious why you can't find the space for a bigger partition?
> Almost all drives these days are partitioned with a little wasted
> space, and that wasted space should be more than enough to cover us
> here. Also, most drives have a swap partition that can be shrunk a
> trivial amount to get space for this...

Unfortunately, in my infinite wisdom (IIRC) I put the zfs partition before the 
swap partition.

We have a similar problem at work with sys/boot unfortunately, but that's a 
side discussion for another time/place.

Thank you for the idea though -- I'll check when I get back to work.

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

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

> On Jan 27, 2017, at 12:23, Toomas Soome  wrote:

...

>> Unfortunately, in my infinite wisdom (IIRC) I put the zfs partition before 
>> the swap partition.
>> 
>> We have a similar problem at work with sys/boot unfortunately, but that's a 
>> side discussion for another time/place.
>> 
>> Thank you for the idea though -- I'll check when I get back to work.
>> 
>> -Ngie
> 
> Note the order of the partitions is not important, at least on paper anyhow. 
> Of course there are preferences in sense that it does look nice if 
> freebsd-boot is in front. Also, if you do have mirror setup, it is some work, 
> but you can re-arrange mirror side partitioning (with usual cautions like 
> having scrub done, having backup, having third disk would be helpful).

I have a raidz with 3 SSDs on it IIRC. Removing the SSD from the pool and 
readjusting partitions would probably be ok, but I'm not really keen on doing 
potentially destructive things like that, unless I absolutely have to do them 
:/..

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

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 10:57 AM, Allan Jude <allanj...@freebsd.org> wrote:
> On 2017-01-28 13:56, Ngie Cooper wrote:
>> On Sat, Jan 28, 2017 at 8:56 AM, Warner Losh <i...@bsdimp.com> wrote:
>>
>> ...
>>
>>> So? It literally doesn't matter where the freebsd-boot partition
>>> lives, or what it's number is. You can put it at the start or end of
>>> the swap partition after adjusting its size. I've done this on several
>>> systems...  NanoBSD plays games with this stuff as well to be bootable
>>> on old / new systems.
>>
>> True. Hopefully my BIOS/disk controller isn't dumb enough to not
>> support large disks properly.
>>
>> *sigh* Unfortunately, in my infinity cleverness I only put 2
>> partitions on the drive -- freebsd-boot and freebsd-zfs. I guess I'll
>> need to make backups of my workstation so I don't lose anything
>> critical.
>
> Did gptzfsboot not fall below 64kb when you used the
> LOADER_NO_GELI_SUPPORT knob?

It did, but unfortunately that's still way too small for my
freebsd-boot partition (which apparently is only 44kB large :/..):

Before:

$ ls -l `make -V.OBJDIR`/gptzfsboot
-rw-r--r--  1 ngie  wheel  111662 Jan 28 11:00
/usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot

After:

$ ls -l `make -V.OBJDIR`/gptzfsboot
-rw-r--r--  1 ngie  wheel  65371 Jan 28 11:05
/usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot

Time to do some more tricks to pare down the bootloader size.

Sidenote to the folks who drive the release notes and upgrade
instructions for FreeBSD 12.x -- it needs to be clearly explained that
gptzfsboot has grown considerably in size and mitigation instructions
should be provided for updating gptzfsboot -- in particular with folks
who might be using freebsd-update, so don't have the luxury of the
choice of bootloader build options when upgrading.

Thanks,
-Ngie

$ gpart list da0
Geom name: da0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 250069646
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: da0p1
   Mediasize: 45056 (44K)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 20480
   Mode: r0w0e0
   rawuuid: 29a79300-48b1-11e4-97ff-fc4dd43f2de9
   rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
   label: (null)
   length: 45056
   offset: 20480
   type: freebsd-boot
   index: 1
   end: 127
   start: 40
2. Name: da0p2
   Mediasize: 128035593728 (119G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 65536
   Mode: r1w1e1
   rawuuid: 4416180d-48b1-11e4-97ff-fc4dd43f2de9
   rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
   label: (null)
   length: 128035593728
   offset: 65536
   type: freebsd-zfs
   index: 2
   end: 250069646
   start: 128
Consumers:
1. Name: da0
   Mediasize: 128035676160 (119G)
   Sectorsize: 512
   Mode: r1w1e2
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

> What created a partition that small?

Me.

gpart up until last summer said that users should create 44kB
freebsd-boot partitions -- des@ corrected that in r303289:

-This example uses 88 blocks (44 kB) so the next partition will be
-aligned on a 64 kB boundary without the need to specify an explicit
-offset or alignment.
-The boot partition itself is aligned on a 4 kB boundary.
+We create a 472-block (236 kB) boot partition at offset 40, which is
+the size of the partition table (34 blocks or 17 kB) rounded up to the
+nearest 4 kB boundary.
 .Bd -literal -offset indent
-/sbin/gpart add -b 40 -s 88 -t freebsd-boot ada0
+/sbin/gpart add -b 40 -s 472 -t freebsd-boot ada0

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

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 12:17 PM, Ngie Cooper <yaneurab...@gmail.com> wrote:
...

> After some creative hacking... tada!
>
> # find /usr/obj/usr/src/sys/boot/ -type f -name \*zfsboot -exec ls -l {} \;
> -rw-r--r--  1 root  wheel  131584 Jan 28 12:07
> /usr/obj/usr/src/sys/boot/i386/zfsboot/zfsboot
> -rw-r--r--  1 root  wheel  47527 Jan 28 12:07
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot

Bah. It's still 2kB too big. I'll see if I can free up some more space
in the text area (there was a patch kicking around at $work that might
alleviate this a few more kB).
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 11:22 AM, Ngie Cooper <yaneurab...@gmail.com> wrote:
>> What created a partition that small?
>
> Me.
>
> gpart up until last summer said that users should create 44kB
> freebsd-boot partitions -- des@ corrected that in r303289:
>
> -This example uses 88 blocks (44 kB) so the next partition will be
> -aligned on a 64 kB boundary without the need to specify an explicit
> -offset or alignment.
> -The boot partition itself is aligned on a 4 kB boundary.
> +We create a 472-block (236 kB) boot partition at offset 40, which is
> +the size of the partition table (34 blocks or 17 kB) rounded up to the
> +nearest 4 kB boundary.
>  .Bd -literal -offset indent
> -/sbin/gpart add -b 40 -s 88 -t freebsd-boot ada0
> +/sbin/gpart add -b 40 -s 472 -t freebsd-boot ada0

After some creative hacking... tada!

# find /usr/obj/usr/src/sys/boot/ -type f -name \*zfsboot -exec ls -l {} \;
-rw-r--r--  1 root  wheel  131584 Jan 28 12:07
/usr/obj/usr/src/sys/boot/i386/zfsboot/zfsboot
-rw-r--r--  1 root  wheel  47527 Jan 28 12:07
/usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot

-- wait, why is the size of zfsboot vs gptzfsboot so different? Oh,
r304321 added that as `BOOT2SIZE`. Still, it seems a bit silly to only
increase the size of one bootloader and not the other 4 instances of
the bootloader :/. I don't understand the point in the size
restriction 100%, but I'll leave it be.

Patch will be available sometime next week if my testing goes well.

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

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 8:56 AM, Warner Losh  wrote:

...

> So? It literally doesn't matter where the freebsd-boot partition
> lives, or what it's number is. You can put it at the start or end of
> the swap partition after adjusting its size. I've done this on several
> systems...  NanoBSD plays games with this stuff as well to be bootable
> on old / new systems.

True. Hopefully my BIOS/disk controller isn't dumb enough to not
support large disks properly.

*sigh* Unfortunately, in my infinity cleverness I only put 2
partitions on the drive -- freebsd-boot and freebsd-zfs. I guess I'll
need to make backups of my workstation so I don't lose anything
critical.

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

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 12:21 PM, Allan Jude  wrote:

...

> The 'zfsboot' version, is dd's into the zfs boot code area. It is read
> by the assembly code there. It is important the file be the size that
> will be read, so it is padded out. That file is currently only used for
> MBR booting from ZFS.

Thank you for the info -- it would be really nice if this was noted in
the Makefile in more detail for the next soul who wonders why the
sizes are so different.
Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

[Ngie Cooper]

On Sat, Jan 28, 2017 at 1:03 PM, Ngie Cooper <yaneurab...@gmail.com> wrote:
> On Sat, Jan 28, 2017 at 12:17 PM, Ngie Cooper <yaneurab...@gmail.com> wrote:
> ...
>
>> After some creative hacking... tada!
>>
>> # find /usr/obj/usr/src/sys/boot/ -type f -name \*zfsboot -exec ls -l {} \;
>> -rw-r--r--  1 root  wheel  131584 Jan 28 12:07
>> /usr/obj/usr/src/sys/boot/i386/zfsboot/zfsboot
>> -rw-r--r--  1 root  wheel  47527 Jan 28 12:07
>> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
>
> Bah. It's still 2kB too big. I'll see if I can free up some more space
> in the text area (there was a patch kicking around at $work that might
> alleviate this a few more kB).

Ok, found the patch.

After applying all the changes, it's finally under 44kB and I can
write the bootcode to my disk:

$ sudo gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0
partcode written to da0p1
bootcode written to da0

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

Re: Possible overlooked "svn add" in r314192?

[Ngie Cooper]

> On Feb 24, 2017, at 05:39, David Wolfskill  wrote:
> 
> 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

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

Re: recent change to vim defaults?

[Ngie Cooper]

> On Jan 15, 2017, at 08:03, Julian Elischer  wrote:
> 
> I noticed that suddenly vim is grabbing mouse movements, which makes life 
> really hard.
> 
> Was there a specific revision that brought in this change, and can it be 
> removed?

"set mouse=" will disable the feature you're describing.
-Ngie

PS I find the new feature incredibly annoying and disable it on all FreeBSD 
clients where I install vim.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r312348: igb broken: reporting wrong linkspeed!

[Ngie Cooper]

> On Jan 17, 2017, at 11:54, Hartmann, O.  wrote:
> 
> 12-CURRENT (FreeBSD 12.0-CURRENT #74 r312348: Tue Jan 17 19:54:58 CET
> 2017 am64) reports the wrong linkspeed on a dualport Intel i350 NIC:
> 
> igb0: flags=8843 metric 0 mtu
> 1500
> options=653dbb
> ether xx:xx:xx:xx:xx:xx inet 192.168.0.111 netmask 0xff00 broadcast
> 192.168.0.255 nd6 options=29
>media: Ethernet autoselect (100baseTX )
>status: active
> 
> The swith the NIC is connected to reports 1 GBit. I checked with two
> switches, FreeBSD reports bullshit on that subject.
> 
> I also realised severe problems of this Intel i350 dual NIC cards with
> FreeBSD (we use this NIC type as a standard and so we have plenty, all
> with the same issue). When the NIC negotiates its linkspeed, it very
> often fall back to 100 MBit. This behaviour is not predictable, but it
> occurs with a SoHo smart managed Netgear GS110TBv2 and some of our
> Cisco Catalyst switches at work (some 35XX and 29XX, I do not know the
> exact type).

Hi,
One of the workarounds for igb wasn't ported to the new driver--I remember 
an issue like this being solved sometime in the 2015-2016 timeframe (I'm 
leaning towards 2016).
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: make universe and /etc/src.conf

[Ngie Cooper]

> On Aug 22, 2016, at 08:24, Eric van Gyzen  wrote:
> 
> I just tried a "make universe", and all the kernels failed because they 
> couldn't
> find the config files.  I had forgotten that I have this in /etc/src.conf:
> 
>KERNCONF=NUMA
>KERNCONFDIR=/etc

Alternatively, use KERNCONF?= and KERNCONFDIR?=..

A conditional will be needed to deal with MODULES_OVERRIDE, but it's trivial.. 
I'll dig up my old src.conf a bit later on today if needed. It's how I dealt 
with that caveat before I switched to GENERIC*.

> Since "make universe" is primarily used for build-testing changes in src,
> shouldn't it ignore /etc/src.conf (and possibly /etc/src-env.conf), like the
> following?  Or is "make universe" used for other purposes for which it really
> should read /etc/src*.conf?
> 
> --- Makefile(revision 304226)
> +++ Makefile(working copy)
> @@ -479,6 +479,7 @@
> universe_${target}_${target_arch}: universe_${target}_prologue .MAKE .PHONY
>@echo ">> ${target}.${target_arch} ${UNIVERSE_TARGET} started on `LC_ALL=C 
> date`"
>@(cd ${.CURDIR} && env __MAKE_CONF=/dev/null \
> +SRCCONF=/dev/null SRC_ENV_CONF=/dev/null \
>${SUB_MAKE} ${JFLAG} ${UNIVERSE_TARGET} \
>TARGET=${target} \
>TARGET_ARCH=${target_arch} \
> 
> Thanks,
> 
> Eric
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: warning errors with buildworld with llvm39

[Ngie Cooper]

On Tue, Aug 30, 2016 at 5:54 PM, Matthew Macy  wrote:
>
>
> I did a buildworld with llvm39. Unsurprisingly I had to pass NO_WERROR= as 
> the llvm has added additional warnings since 3.8.
>
> https://gist.github.com/mattmacy/5f0c994b7587a10e3f58e7fd9fc1dd01

dim's working on the issues on ^/projects/clang390-import . Some of
the issues you've noted have been resolved.
Cheers,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Destroy GPT partition scheme absolutely, how?

[Ngie Cooper]

> On Sep 26, 2016, at 22:48, Ernie Luzar  wrote:

...

> This little script has been posted before. Maybe it will be what your looking 
> for. Called gpart.nuke
> 
> #! /bin/sh
> echo "What disk do you want"
> echo "to wipe? For example - da1 :"
> read disk
> echo "OK, in 10 seconds I will destroy all data on $disk!"
> echo "Press CTRL+C to abort!"
> sleep 10
> diskinfo ${disk} | while read disk sectorsize size sectors other
> do
> # Delete MBR and partition table.
> dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1
> # Delete GEOM metadata.
> dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr $sectors - 2` 
> count=2
> done

Why not just use "gpart destroy -F provider"?

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

Re: CURRENT: "service netif restart" looses default route

[Ngie Cooper]

> On Oct 6, 2016, at 09:40, Pete Wright  wrote:
> 
>> On 10/6/16 12:27 AM, Oliver Peter wrote:
>>> On Wed, Oct 05, 2016 at 06:47:48PM +0200, O. Hartmann wrote:
>>> 
>>> Today, I checked on two servers of ours running both a recent CURRENT (i.e. 
>>> FreeBSD
>>> 12.0-CURRENT #43 r306701: Wed Oct  5 06:40:40 CEST 2016) via "service netif 
>>> restart" the
>>> upcoming network and realised that the default route is lost then!
>>> 
>>> I'm able to config the route via "service routing restart" - or manually as 
>>> I did
>>> otherwise. But I recall that I did a simple "service netif restart" in 
>>> 11-CURRENT
>>> recently and that worked.
>>> 
>>> Has there been a change? What is now the official way to restart network?
>> 
>> Since the past couple of years on every new FreeBSD I put this in motd for my
>> linux colleagues and coworkers:
>> 
>>Network:
>>To apply changes you have made to the network:
>># /etc/rc.d/netif restart && /etc/rc.d/routing restart
>> 
>> Perhaps we could introduce a wrapper to be used with:
>># service network restart
> 
> 
> 
> I think this is a great idea - especially as it would make it easier for 
> dev's and other novice admin's to use freebsd as a development platform.

Special casing would need to be done with DHCP, btw..

Also, what about IPv6 (rtsol/rtsold, etc)?

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

Re: New syscons bugs: shutdown -r doesn't execute rc.d sequence and others

[Ngie Cooper]

> On Mar 28, 2017, at 21:40, Bruce Evans  wrote:
> 
>> On Wed, 29 Mar 2017, Bruce Evans wrote:
>> 
>>> On Wed, 29 Mar 2017, Andrey Chernov wrote:
>>> ...
>>> Moreover, I can't enter KDB via Ctrl-Alt-ESC in the syscons only mode
>>> anymore - nothing happens. In the vt mode I can, but can't exit via "c"
>>> properly, all chars typed after "c" produce beep unless I switch to
>>> another screen and back.
>>> All it means that syscons becomes very broken now by itself and even
>>> damages the kernel operations.
>> 
>> ...
>> But I suspect it is a usb keyboard problem.  Syscons now does almost
>> correct locking for the screen, but not for the keyboard, and the usb
>> keyboard is especially fragile, especially in ddb mode.  Console input
>> is not used in normal operation except for checking for characters on
>> reboot.
>> 
>> Try using vt with syscons unconfigured.  Syscons shouldn't be used when
>> vt is selected, but unconfigure it to be sure.  vt has different bugs
>> using the usb keyboard.  I haven't tested usb keyboards recently.
> 
> I tested usb keyboards again.  They sometimes work, much the same as
> a few months ago after some fixes:
> - after booting with -d, they never work (give no input) at the ddb
>  prompt with either sc or vt.  usb is not initialized then, and no usb
>  keyboard is attached to sc or vt
> - after booting without loader with -a, sc rarely or never works (gives
>  no input) at the mountroot prompt
> - after booting with loader with -a, vt works at the mountroot prompt.
>  I don't normally use loader but need to use it to change the configuration.
>  This might be better than before.  There used to be a screen refresh bug.
> - after booting with loader with -a, sc works at the mountroot prompt too.
>  I previously debugged that vt worked better because it attaches the keyboard
>  before this point, while sc attaches it after.  Booting with loader
>  apparently fixes the order.
> - after any booting, sc works for user input (except sometimes after a
>  too-soft hard reset, the keyboard doesn't even work in the BIOS, and it
>  takes unplugging the keyboard to fix this)
> - after almost any booting, vt doesn't work for user input (gives no input).
>  However, if ddb is entered using a serial console, vt does work!  A few
>  months ago, normal input was fixed by configuring kbdmux (the default in
>  GENERIC).  It is not fixed by unplugging the keyboard.  kbdmux has a known
>  bug of not doing nested switching for the keyboard state.  Perhaps this
>  "fixes" ddb mode.  But I would have expected it to break ddb mode.
> - I didn't test sc after entering ddb, except early when it doesn't work.
> 
> The above testing is with a usb keyboard, no ps/2 keyboard, and no kbdmux.
> Other combinations and dynamic switching move the bugs around, and a
> serial console is needed to recover in cases where the bugs prevent any
> keyboard input.

I filed a bug a few years ago about USB keyboards and usability in ddb. If you 
increase the timeout so the USB hubs have enough time to probe/attach, they 
will work.

I haven't taken the time to follow up on that and fix the issue, or at least 
propose a bit more functional workaround.

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

Re: Building Current

[Ngie Cooper]

> On Mar 4, 2017, at 13:19, Roberto Rodriguez Jr  wrote:
> 
> Would make -DNO_CLEAN=NO also/maybe help as well?

Remove =NO from your invocation above. That would define a variable as: 
${NO_CLEAN=NO}=1
HTH,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Buildworld fails if WITHOUT_INET6=YES defined

[Ngie Cooper]

On Thu, Mar 2, 2017 at 11:40 AM, Alex Deiter  wrote:
> Hello,
>
> Please apply patch from upstream:
>
> https://github.com/the-tcpdump-group/libpcap/pull/541
>
> Fix compilation if INET6 isn't defined.
> Addresses GitHub issue #541, but differently from the pull request (it
> defines gen_gateway() with a function prototype rather than using a
> pre-prototype-style definition).
>
> https://github.com/the-tcpdump-group/libpcap/commit/470df104c6f55f6d6f390df7448d8eb65c7642b9#diff-021c0dd9e9ed7100b9e31d8d95c930f2

Hi Dieter,
Could you please open a bug and CC glebius@ and myself on it?
Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: effect of strip(1) on du(1)

[Ngie Cooper]

On Thu, Mar 2, 2017 at 4:31 PM, Rodney W. Grimes
 wrote:
...
> Even if that is the case file system cache effects should NOT be
> visible to a userland process.   This is NOT as if your running
> 2 different processing beating on a file.  Your test cases are
> serialially syncronous shell invoked commands seperated with
> && the results should be exact and predictable.
>
> When strip returns the operation from the userland perspecive
> is completed and any and all processeses started after that
> should have the view of the completed strip command.
>
> This IS a bug.

Would the same statement necessarily apply if the filesystem was
writing things asynchronously to the backing storage?
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: problem with ls, not show a correct list

[Ngie Cooper]

> On Apr 6, 2017, at 20:12, Nilton José Rizzo  wrote:
> 
>  Hi all 
> 
>  Look this command on a FreeBSD -current 
> 
> % ls -d /usr/ports/[a-z]*
> /usr/ports/accessibility /usr/ports/math
> /usr/ports/arabic /usr/ports/misc
> /usr/ports/archivers /usr/ports/Mk
> /usr/ports/astro /usr/ports/MOVED
> /usr/ports/audio /usr/ports/multimedia
> % echo /usr/ports/[a-z]*
> /usr/ports/accessibility /usr/ports/arabic /usr/ports/archivers
> /usr/ports/astro /usr/ports/audio /usr/ports/base /usr/ports/benchmarks
> /usr/ports/biology /usr/ports/cad /usr/ports/CHANGES /usr/ports/chinese
> /usr/ports/comms /usr/ports/CONT
> alguém sabe o motivo desse erro?
> % ls -d /usr/src/[a-z]*
> /usr/src/bin /usr/src/Makefile.libcompat
> /usr/src/cddl /usr/src/ObsoleteFiles.inc
> /usr/src/contrib /usr/src/README
> /usr/src/COPYRIGHT /usr/src/release 
> 
> What's I do wrong? 
> 
> % set 
> 
> addsuffix 
> anyerror 
> argv ()
> csubstnonl 
> cwd /home2/rizzo/src/repositorio/bsdday-2017
> dirstack /home2/rizzo/src/repositorio/bsdday-2017
> echo_style bsd
> edit 
> euid 1000
> euser rizzo
> gid 0
> group wheel
> history 100
> home /home2/rizzo
> killring 30
> loginsh 
> owd /home2/rizzo/src/repositorio/Rural
> path (/sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin
> /home2/rizzo/bin)
> prompt %# 
> prompt2 %R? 
> prompt3 CORRECT>%R (y|n|e|a)? 
> shell /bin/csh
> shlvl 1
> status 0
> tcsh 6.18.01
> term screen
> tty pts/4
> uid 1000
> user rizzoversion tcsh 6.18.01 (Astron) 2012-02-14 (x86_64-amd-FreeBSD)
> options wide,nls,dl,al,kan,sm,rh,color,filec
> % uname -a
> FreeBSD valfenda 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r313684: Sun Feb
> 12 20:52:19 BRST 2017 rizzo@valfenda:/usr/obj/usr/src/sys/VALFENDA amd64
> % 

Hi Nilton,
What's your locale set to and what's your filesystem?
Thanks!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ipfw kernel module not being built

[Ngie Cooper]

> On Aug 11, 2017, at 10:36, Bob Willcox  wrote:
> 
> When I rebuild my kernel on Jun 13th none of the previous ipfw kernel modules 
> were built:
> 
> ipfw.ko
> ipfw_nat.ko
> ipfw_nat64.ko
> ipfw_nptv6.ko
> ng_ipfw.ko
> 
> and only this ipfw module was built:
> 
> ng_ipfw.ko
> 
> However, the verson of /etc/rc.d/ipfw that I'm running (from the
> freebsd-base-graphics branch) is failing to load ipfw so my firewall isn't
> starting.
> 
> So, what am I missing? Is it possible that the freebsd-base-graphics branch
> that I'm running has an old or improper version of /etc/rc.d/ipfw?

Hi Bob,
Can you please provide your make.conf, src.conf, and KERNCONF?
Thank you!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ipfw kernel module not being built

[Ngie Cooper]

> On Aug 11, 2017, at 12:34, Bob Willcox  wrote:
> 
>> On Fri, Aug 11, 2017 at 12:21:49PM -0700, Mark Johnston wrote:
>> On Fri, Aug 11, 2017 at 02:06:02PM -0500, Bob Willcox wrote:
> On Aug 11, 2017, at 10:36, Bob Willcox  wrote:
> 
> When I rebuild my kernel on Jun 13th none of the previous ipfw kernel 
> modules were built:
> 
> ipfw.ko
> ipfw_nat.ko
> ipfw_nat64.ko
> ipfw_nptv6.ko
> ng_ipfw.ko
> 
> and only this ipfw module was built:
> 
> ng_ipfw.ko
> 
> However, the verson of /etc/rc.d/ipfw that I'm running (from the
> freebsd-base-graphics branch) is failing to load ipfw so my firewall isn't
> starting.
> 
> So, what am I missing? Is it possible that the freebsd-base-graphics 
> branch
> that I'm running has an old or improper version of /etc/rc.d/ipfw?
>> 
>> [...]
>> 
>>> include GENERIC_DRM
>> 
>> GENERIC_DRM sets MODULES_OVERRIDE, so only the specified modules are
>> built. In particular, ipfw*.ko does not get built. You'll need to either
>> remove the MODULES_OVERRIDE setting in GENERIC_DRM (which will make
>> kernel builds somewhat slower), or add
>> 
>> makeoptionsMODULES_OVERRIDE+= ipfw ...
>> 
>> to your custom config.

Or add "MODULES_OVERRIDE+= ipfw..." to your src.conf.
Cheers,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Run binary from test suite

[Ngie Cooper]

On Tue, Jul 11, 2017 at 10:38 AM, Panagiotes Mousikides
 wrote:
> (Resending due to moderation.)
>
> Hello!
>
> I'm a Google Summer of Code student, writing some tests for the FreeBSD test
> suite, and putting them under src/tests.  I need to run some binaries,
> specifically pfctl.
>
> How should I call pfctl from my test scripts?  Should I call it directly and
> let the shell find the binary in the path?  Or should I find where the build
> version got created (somewhere under /usr/obj) and call that? How do I find
> where the binary ended up getting created in that case?
>
> Best regards,
> Panagiotes

Hello Panagiotes,
Please call pfctl from $PATH -- don't hardcode the path, ever.
I'll be looking at making "make check" more developer friendly in the
next 3-6 months, so running "make check" from usr.sbin/pf/... will
automatically add a set path/environment which hooks in to *.test.mk.
The goal of this is to simplify developer use for "make check".
Also, if the tests (for whatever reason) aren't going to be
installed alongside pfctl, e.g., tests/sys/pf/... please add 'atf_set
"require.progs" "pfctl"' to the header to ensure that the test is
skipped if/when pfctl isn't installed on the system.
Cheers,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: i386 build fail

[Ngie Cooper]

Hi Shane,

> On Jul 25, 2017, at 23:25, Shane Ambler  wrote:
> 
> 
> Having just updated my testing bhyve system to 12-current r321405M I
> then started updating my poudriere 12-current jails, the amd64 jail
> built fine at r321457 and then building i386 (should have got r321457
> as well) failed with the following errors -

Please update to r321486--I accidentally introduced some build errors that 
I finally fixed on that revision.
Thanks,
-Ngie
___
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"

tools/tools/zfsboottest doesn't compile on ^/head

[Ngie Cooper]

Hi,
It looks like zfsboottest no longer compiles on ^/head (guessing it has 
to do with the clang upgrade).
If someone doesn’t fix this build breakage in the next few hours, I’ll 
take a stab at fixing it.
Thanks,
-Ngie

PS zfsboottest should really be compiled with world if MK_ZFS != no.

$ (cd tools/tools/zfsboottest/; make obj; make)
cc  -O1  -I/usr/src/tools/tools/zfsboottest/../../../sys/boot/zfs  
-I/usr/src/tools/tools/zfsboottest/../../../sys/cddl/boot/zfs  -I.  
-fdiagnostics-show-option  -W -Wextra -Wno-sign-compare -Wno-unused-parameter 
-m32   -g --coverage -MD  -MF.depend.zfsboottest.o -MTzfsboottest.o -std=gnu99 
-fstack-protector-strong-Qunused-arguments  -c 
/usr/src/tools/tools/zfsboottest/zfsboottest.c -o zfsboottest.o
In file included from /usr/src/tools/tools/zfsboottest/zfsboottest.c:56:
/usr/src/tools/tools/zfsboottest/../../../sys/boot/zfs/zfsimpl.c:797:9: error: 
returning 'void' from a function with incompatible result type 'int'
return (pager_output(line));
   ^~~~
/usr/src/tools/tools/zfsboottest/../../../sys/boot/zfs/zfsimpl.c:2356:17: 
warning: array index 264 is past the end of the array (which contains 192 
elements) [-Warray-bounds]
memcpy(path, >dn_bonus[sizeof(znode_phys_t)], psize);
  ^
/usr/src/tools/tools/zfsboottest/../../../sys/cddl/boot/zfs/zfsimpl.h:910:2: 
note: array 'dn_bonus' declared here
uint8_t dn_bonus[DN_MAX_BONUSLEN - sizeof (blkptr_t)];
^
1 warning and 1 error generated.
*** Error code 1

Stop.
make: stopped in /usr/src/tools/tools/zfsboottest

157873imp void
157873imp printf(const char *fmt,…)
104679phk static void printf(const char *,...);
___
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"

zfs.ko no longer loads after r320156: unresolved symbol: abd_is_linear

[Ngie Cooper]

Hi,
I tried upgrading my host from 11.1-STABLE to 12.0-CURRENT, and it 
didn’t work because abd_is_linear is an undefined symbol (it exists in 
sys/conf/files, but not sys/modules/zfs/Makefile). I tried adding abd.c to 
sys/modules/zfs/Makefile and it didn’t immediately fix my compilation problem 
(ran into a linker error instead).
If it isn’t fixed in the next few hours I’ll try my hand at fixing the 
problem.
Thank you,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: src/libexec/Makefile damaged fails to build rshd

[Ngie Cooper]

> On Aug 6, 2017, at 11:38, Julian H. Stacey <j...@berklix.com> wrote:
> 
> "Ngie Cooper (yaneurabeya)" wrote:
>> --Apple-Mail=_7653CBF4-A533-4B1C-8D92-2E3AF5958F08
>> Content-Transfer-Encoding: 7bit
>> Content-Type: text/plain;
>>charset=us-ascii
>> 
>> 
>>> On Aug 6, 2017, at 09:36, Julian H. Stacey <j...@berklix.com> wrote:
>>> 
>>> Hi freebsd-current@freebsd.org
>>> with current src
>>>.ctm_status src-cur 13120
>>>.svn_revision322111
>>> libexec/Makefile has been butchered, eg
>>> rshd & other builds silently omitted
>>> unless one debugs & learns to do eg
>>>setenv _rshd Something
>>> A find & grep of src/ shows no other ref. to _rshd except
>>>./libexec/Makefile: ${_rshd} \
>>>./libexec/Makefile:_rshd=   rshd
>>> 
>>> I sampled _pppoed same error !
>>>./libexec/Makefile: ${_pppoed} \
>>>./libexec/Makefile:_pppoed= pppoed
>>> 
>>> Others turned off are:
>>>   ${_atf} \ ${_atrun} \ ${_blacklistd-helper} \ ${_comsat} \
>>>   ${_dma} \ ${_mail.local} \ ${_makewhatis.local} \ ${_mknetid}
>>>   \ ${_pppoed} \ ${_rlogind} \ ${_rshd} \ ${_rtld-elf} \
>>>   ${_smrsh} \ ${_telnetd} \ ${_tests} \ ${_tftp-proxy} \ ${_ypxfr}
>>> 
>>> If src/ annoyingly insists to force everyone to silently Not build src/,
>>> there should at least be some switch & reference doc in eg
>>>src/share/mk
>>>src/share/man/man5/src.conf
>> 
>> Julian,
>>Could you please post your build error (in its entirety) somewhere?
>> Thank you,
>> -Ngie
> 
> Why ?  Problem is fully identified.  Please read source.
> The half baked mod. to src/libexec/Makefile could be backed out
> as it fails to be supported by src/share/mk & src.conf.

Hi Julian,
The reason why I need more context is that I was unable to repro the issue. 
I need more details to help isolate/fix the problem.
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: old snapshot install images?

[Ngie Cooper]

> On May 3, 2017, at 09:41, Michael W. Lucas <mwlu...@michaelwlucas.com> wrote:
> 
>> On Wed, May 03, 2017 at 09:37:04AM -0700, Ngie Cooper (yaneurabeya) wrote:
>> Ok. I was curious because there has been a period of time when 512b/sector 
>> disks have been broken and vice versa.
>> 
>> I’m going to operate under the impression that one of tsoome’s recent 
>> changes to zfsboot fixed things (there was some breakage over the past 
>> couple months based on posts to current@ and svn-src-*@), but I can’t count 
>> on it 100%.
> 
> 
> The most recent installer snapshot has the exact same problem.
> 
> Every installer snapshot on the FTP site has the exact same problem.
> 
> I've gotten some installer snapshots from October and from
> mid-2015. Trying those.
> 
> My goal is to find out when the problem appeared and include the time
> window in the PR.

Ok. How big is your freebsd-boot partition?
Thanks,
-Ngie
> 
> 
> -- 
> Michael W. LucasTwitter @mwlauthor 
> nonfiction: https://www.michaelwlucas.com/
> fiction: https://www.michaelwarrenlucas.com/
> blog: http://blather.michaelwlucas.com/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: make warning: ?: No such file or directory.

[Ngie Cooper]

On Wed, May 10, 2017 at 11:59 AM, Simon J. Gerraty  wrote:
> Bryan Drewery  wrote:
>> Oh now I get it too after updating system from head from r317177 to
>> r318116. So it seems to be a bug in bmake-20170420.
>
> What's in your env?
> Eg.
>
> env | grep MAKE
> ls

As I noted in the src commit, I think r318161 addresses the issue
(also identified by Coverity as CID: 1374641). Basically, buf2 was in
scope for the conditional as stack memory, `path` took the address
buf2 and used it out of scope (which may have triggered the compiler
to optimize/evaluate the code incorrectly since the case seemed
impossible).
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic @r319733: "mtx_lock() of spin mutex (null) @ /usr/src/sys/kern/sys_socket.c:305"

[Ngie Cooper]

On Fri, Jun 9, 2017 at 3:55 PM, David Wolfskill  wrote:

...

> Gleb committed r319754; I finally(!) had a chance to revert the
> reversion of r319722, then apply r319754 and rebuild; the follow-up
> smoke test was successful.

...

> [Apparently hald invokes stat(2) on a listening socket, which was ...
> unexpected.]

This might have been caught by lib/libc/sys/stat_test:stat_socket . If
only the compat stuff was working on ci.freebsd.org as well, or the
test(s) had been run...
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Bug in make setting wrong MAKESYSPATH

[Ngie Cooper]

On Sun, May 21, 2017 at 1:54 AM, Thomas Mueller  wrote:
> I tried building ports, starting with ports-mgmt/synth, on HEAD (12-current) 
> and ran into difficulties with syntax error in bsd.compiler.mk .
>
> With PORTSDIR on another partition, mounted as /BETA1, I got these errors, 
> but not when I null-mounted /BETA1/usr/ports as /usr/ports.
>
> I shouldn't have to resort to this kludge, didn't have to in the recent past.
>
> This bug shows in both 11.0-STABLE and 12.0-CURRENT.
>
> I looked into "man make" and found that make got the wrong path for 
> MAKESYSPATH, setting to /BETA1/usr/share/mk instead of what it should be, 
> /usr/share/mk .
>
> Going into /BETA1/usr/ports/archivers/zip (for a short and simple example),
> make all-depends-list   produced
>
> sh: Syntax error: ")" unexpected
> make: "/BETA1/usr/share/mk/bsd.compiler.mk" line 52: warning: "echo 4.0.0 
> 4.0.0) | awk -F. '{print $1 * 1 + $2 * 100 + $3;}'" returned non-zero 
> status
> sh: Syntax error: ")" unexpected
> make[1]: "/BETA1/usr/share/mk/bsd.compiler.mk" line 52: warning: "echo 4.0.0 
> 4.0.0) | awk -F. '{print $1 * 1 + $2 * 100 + $3;}'" returned non-zero 
> status
> /BETA1/usr/ports/ports-mgmt/pkg
>
> make -m /usr/share/mk all-depends-list produces
> /BETA1/usr/ports/ports-mgmt/pkg
>
> This looks like a bug that ought to be fixed, though there is a workaround 
> using "make -m /usr/share/mk ..." every time, or presumably, setting
> MAKESYSPATH=/usr/share/mk
> in the environment.
>
> Should I file a bug report?
>
> I could get much more verbose outputs when there are more dependencies, such 
> as in /BETA1/usr/ports/ports-mgmt/synth, or more so,
> /BETA1/usr/ports/www/seamonkey
>
> I also noticed that in newer versions of FreeBSD, 
> /usr/share/mk/bsd.compiler.mk has greatly increased in size (not a bug. 
> except when "make" goes to the wrong MAKESYSPATH.
>
> Maybe add in .cshrc and .profile
> MAKESYSPATH=/usr/share/mk
> ?

Hi Tom,

make isn't at fault here as much as there's something else leaking
bsd.compiler.mk into the ports build. That's not supposed to happen.

Are you including any bsd.*.mk or src.*.mk files from /etc/make.conf ,
/etc/src.conf , etc?

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

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

[Ngie Cooper]

> On May 24, 2017, at 08:15, David Wolfskill  wrote:

...

> It completed successfully and a reboot shows:
> 
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #354  
> r318781M/318781:1200031: Wed May 24 07:31:48 PDT 2017 
> r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC  amd64

Hi David!
There was another report on the list about a stale MAKEOBJDIRPREFIX causing 
someone grief. I think it's safe to say that meta mode and -DNO_CLEAN might not 
work across this transition--in particular meta mode tends to err on the side 
of not to rebuilding things.
Cheers,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: hwpmc and Xeon E5 v4

[Ngie Cooper]

On Thu, Jun 15, 2017 at 12:44 AM, Andriy Gapon  wrote:
>
> It seems that hwpmc does not support newer Xeon processors:
>   pmc: Unknown Intel CPU.

What FreeBSD version is this?
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: old snapshot install images?

[Ngie Cooper]

Hi Michael!

> On May 2, 2017, at 12:15, Michael W. Lucas  wrote:
> 
> Hi,
> 
> About a year ago, I did a clean install on my desktop. No problems.
> 
> I tried a clean install now, and it dies with:
> 
> gtpzfsboot: error 1 lba 32
> error 1
> gptzfsboot: error 1 lba 4294967288
> gptzfsboot: error 1 lba 1
> gptzfsboot: no ZFS pools located, can't boot
> 
> The pool is visible in the live CD, and I can import it. I want to
> file a PR.
> 
> The sensible thing for me to do is to use old snapshot installers to
> determine when this machine could no longer install.
> 
> Unfortunately, the FTP servers only keep a month or so of snapshots.
> 
> ftp-archive doesn't have the old snapshots.
> 
> Does anyone have an archive of -current install media, either CD or
> ISO? I need to get this box back fairly quickly, but I don't mind
> burning a couple days to nail it down.

- What sources are you using/revision are you at?
- Are your drives the 512 byte/sector or 4kB/sector variety?
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: make buildworld broken at r317821 (libsysdecode)

[Ngie Cooper]

On Fri, May 5, 2017 at 4:43 PM, Cy Schubert  wrote:

...

> You have a bad DIMM. I had this same problem on my laptop but not on my
> servers downstairs. That suggested that since all four machines were
> running the same software the difference between them was hardware.
> Replacing the memory in my laptop made this problem go away.
>
> I have a question for you. Do you use ZFS? ZFS exercises memory quite
> aggressively. I also had this problem when I replaced my UFS filesystems
> with ZFS on my testbed many moons ago. It even suffered random kernel
> panics. Here again, replacing the memory resolved the issue.

We need more information first before saying "bad hardware" -- in
particular, was the machine overtaxed, were the input files proper,
etc?

I'm asking because clang has a number of bugs in bugzilla where the
host ran out of memory trying to compile things and clang didn't fail
gracefully when allocating memory, handling inputs, etc.

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

Re: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory

[Ngie Cooper]

> On Jun 27, 2017, at 13:21, Cy Schubert  wrote:

...

> Yes. I've had issues with parallel installs breaking badly before this.

Be that what it may be, papering the issue over via poudriere is the wrong 
approach to fixing the problem imho.

Bryan's out for a few more days on vacation.. I'll see if I can look into this 
while he's gone.

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

Re: latest iwm patches don't work with my 8265 chip

[Ngie Cooper]

> not sure if this is the correct way to get things working, but this diff
>> fixes things up on my end (allows the firmware to load):
>> 
>> diff --git a/sys/modules/iwmfw/Makefile b/sys/modules/iwmfw/Makefile
>> index d38f5424153..73e401b3ea9 100644
>> --- a/sys/modules/iwmfw/Makefile
>> +++ b/sys/modules/iwmfw/Makefile
>> @@ -1,5 +1,5 @@
>>  # $FreeBSD$
>> 
>> -SUBDIR=iwm3160fw iwm7260fw iwm7265fw iwm8000Cfw iwm7265Dfw
>> +SUBDIR=iwm3160fw iwm7260fw iwm7265fw iwm8000Cfw iwm8265fw
>> iwm7265Dfw
>> 
>>  .include 
>> 
>> 
>> w/o the diff the iwm8265fw doesn't get built afaict.

Hi Pete,
I submitted your patch as r324470.
Take care!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: iwm not in GENERIC kernel

[Ngie Cooper]

> On Nov 2, 2017, at 09:53, Adrian Chadd  wrote:
> 
> ugh okay
> 
> So it's a chicken/egg problem.
> 
> You can't finish the device probe/attach until the firmware loads.
> 
> For iwn, you can read the chipset abilities and mac address from
> EPROM/flash on the chip without the firmware being loaded, so you can
> complete probe/attach before the root filesystem is mounted.
> 
> For iwm, you have to load the firmware before you can read the chipset
> abilities and MAC address so you can't complete probe/attach until
> AFTER the root filesystem is mounted.
> 
> If someone wants to go add all of that support in to have probe/attach
> deferred until after rootfs is available then please do so. Or, just
> support the firmware being 100% compiled in- but when I tried this the
> last time I ran out of some firmware arena size preventing other
> firmware for other chipsets from being loaded.
> 
> Otherwise this is the current hack. :)

It’s ok (better than nothing)!

Could you please write up bugs with your findings?

Thanks so much!
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD Documentation

[Ngie Cooper]

> On Oct 29, 2017, at 13:53, Rodney W. Grimes 
>  wrote:
> 
> -- Start of PGP signed section.
> [ Charset UTF-8 unsupported, converting... ]
>>> On 2017-10-29 11:00, Kurt Jaeger wrote:
>>> Hi!
>>> 
 How can we suggest edits for the docs?
>>> 
>>> Checkout the docs repo:
>>> 
>>> svn checkout https://svnweb.freebsd.org/doc/head/ .
>>> 
>>> Change the relevant files, create a new problem report on
>>> 
>>> https://bugs.freebsd.org/
>>> 
>>> and attach the svn diff to that problem report.
>> 
>> Since the document in question is a man page, it actually lives in the
>> src tree.
>> 
>> svn checkout https://svn.freebsd.org/base/head/ .
>> 
>> cd usr.sbin/jail
>> 
>> vi jail.8
>> 
>> svn diff > jail_manpage.patch
>> 
>> And then attach that patch to a bugzilla, or upload it to
>> reviews.freebsd.org
> 
> Lets make this MUCH easier on a user.
> cp /usr/share/man/man8/jail.8.gz /tmp
> cd /tmp
> gzip -d jail.8.gz
> cp -p jail.8 jail.8.orig
> vi jail.8
> diff -u jail.8.orig jail.8 >jail.8.patch
> 
> And then attach that patch to a bugzilla
> 
> More commands, but much shorter amount of time.
> 
> (Of cource broken if your system is not -current or close to it)

No. Just do a sparse checkout of share/man/man8 ... less error prone and one 
has a usable diff instead of a diff that might contain local modifications, or 
be a few revisions behind.

> -- 
> Rod Grimes rgri...@freebsd.org
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: smartmontools now broken on -current (by svn r301771, r301778?)

[Ngie Cooper (yaneurabeya)]

> On Jun 11, 2016, at 09:40, Michael Butler  wrote:
> 
> The recent nvme updates have broken smartmontools ..
> 
> imb@toshi:/home/imb> sudo smartctl -a /dev/ada0
> smartctl 6.5 2016-05-07 r4318 [FreeBSD 11.0-ALPHA2 amd64] (local build)
> Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
> 
> /dev/ada0: Inappropriate ioctl for device
> Please specify device type with the -d option.
> 
> Attempts to recompile the utility also fail:

Hi Michael,
Please file a bug — in ports first, and if necessary in the base system.
Thank you!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Ngie Cooper (yaneurabeya)]

> On Jun 13, 2016, at 06:57, Joel Dahl  wrote:
> 
> Hi,
> 
> I've just rebuilt and installed latest current on a machine here. I noticed
> the following message in dmesg after a reboot:
> 
> _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode
> 
> I don't remember seeing this before.

Hi Joe,
Try reverting r301867. Let Robert know if that fixes your issue.
Thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: installworld woes

[Ngie Cooper (yaneurabeya)]

> On May 28, 2016, at 17:31, Shawn Webb  wrote:

…

> No worries. No rush here. I appreciate the help! Can you add “Reported by: 
> HardenedBSD” to the commit log?

Fixed in r300922 — thanks!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: exports(5) no longer allows multiple paths per line?

[Ngie Cooper (yaneurabeya)]

> On May 26, 2016, at 23:28, Ed Schouten <e...@nuxi.nl> wrote:
> 
> Hi there,
> 
> 2016-05-27 4:12 GMT+02:00 Ngie Cooper <yaneurab...@gmail.com>:
>>It seems like the following /etc/exports should work, but for some
>> odd reason specifying both paths on a single line doesn't work (I
>> swore it was working on a kernel/userland built in the past month,
>> i.e. ^/head@r297950, but I might be misremembering things).
> 
> I'm not sure, but I seem to remember that an entry may only apply to a
> single filesystem. In your case, /tftpboot and /home/ngie are both on
> different filesystems, right? That's why you need two separate
> entries.

Hi Ed,
Oy, I was misreading things and likely changed my mount points between 
when I restarted mountd.. Rereading exports(4) it’s an NFSv3 exports/mountd 
implementation item on FreeBSD — NFSv4 doesn’t necessarily have the same 
limitations.
Thanks for clarifying that!
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r 300949: rpcbind rejects to start: couldn't create ip6 socket

[Ngie Cooper (yaneurabeya)]

> On May 29, 2016, at 00:32, O. Hartmann  wrote:
> 
> After updating sources and build- and installworld, I realize that all 
> rpcbind related
> services, so far NFS, are not working. On a client I check the start of 
> rpcbind by
> setting option -d and receive the output shown below.
> 
> Well, prior to r300949 rpcbind started without complains - as it did with 
> r300901.
> 
> [...]
> rpcbind not running?
> Starting rpcbind.
> rpcbind debugging enabled.
> can't get local ip6 address: hostname nor servname provided, or not known
> couldn't create ip6 socket/etc/rc.d/rpcbind: WARNING: failed to start rpcbind

Hi,
Could you please try this patch with -d (it’ll continue on instead of 
exiting… I’m curious as to why it was failing before).
Does IPv6 work in your environment?
Thanks!
-Ngie


ohartmann-rpcbind-util-break.patch
Description: Binary data


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: libarchive update SVN r299529 breaks "ezjail update"

[Ngie Cooper (yaneurabeya)]

> On May 14, 2016, at 16:29, Martin Matuska  wrote:
> 
> Ian, we are here talking about cpio, not libarchive. The flag in
> libarchive is not active by default.
> 
> On 14.05.2016 22:08, Ian Lepore wrote:

>> The real damage will happen to out-of-tree users.  I think this will
>> impact our software updater for $work for example, and it has to work
>> with both old and new versions of libarchive, and now the new version
>> will require a flag that the old version will reject as unknown.
>> 
>> Ick.

Ian’s comment was valid.. cpio doesn’t recognize the new switch on older 
versions, so something like cpio `cpio --help | grep -- switch && echo switch` 
would need to be employed everywhere for backwards compatibility — ew.
Thanks,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: please test your commits

[Ngie Cooper (yaneurabeya)]

> On May 4, 2016, at 17:56, Steve Kargl  
> wrote:
> 
> % make -j7  buildworld |& tee sgk.log
> 
> --- lib/libkvm__L ---
> In file included from /usr/src/lib/libkvm/kvm_pcpu.c:43:
> /usr/obj/usr/src/tmp/usr/include/sys/pcpu.h:163:2: error: unknown type name 
> 'device_t'
>device_tpc_device;
>^

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

Re: for the build aversed

[Ngie Cooper (yaneurabeya)]

> On May 4, 2016, at 18:13, Steve Kargl  
> wrote:
> 
> Index: lib/libkvm/kvm_cptime.c
> ===
> --- lib/libkvm/kvm_cptime.c (revision 299099)
> +++ lib/libkvm/kvm_cptime.c (working copy)
> @@ -35,6 +35,7 @@ __FBSDID("$FreeBSD$");
> #include 
> #include 
> #include 
> +#include 
> #include 
> #include 
> #include 
> Index: lib/libkvm/kvm_pcpu.c
> ===
> --- lib/libkvm/kvm_pcpu.c   (revision 299099)
> +++ lib/libkvm/kvm_pcpu.c   (working copy)
> @@ -42,6 +42,7 @@ __FBSDID("$FreeBSD$");
> #include 
> #include 
> #include 
> +#include 
> #include 
> #include 
> #include 

I hit this on my box too. I’m going to revert r299096 — it needs to be tested, 
and also probably needs an exp run to make sure it doesn’t break downstream 
consumers.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD_HEAD_i386 - Build #2857 - Still Failing

[Ngie Cooper (yaneurabeya)]

> On Apr 14, 2016, at 19:14, jenkins-ad...@freebsd.org wrote:
> 
> FreeBSD_HEAD_i386 - Build #2857 - Still Failing:
> 
> Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2857/
> Full change log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2857/changes
> Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/2857/console
> 
> Change summaries:
> 
> 298018 by araujo:
> Initialize pointer with NULL instead of 0.
> 
> Submitted by: pfg
> 
> 298017 by asomers:
> Add more debugging statements in vdev_geom.c
> 
> Log a debugging message whenever geom functions fail in vdev_geom_attach.
> Printing these messages is controlled by vfs.zfs.debug
> 
> MFC after:4 weeks
> Sponsored by: Spectra Logic Corp
> 

...

> ctfconvert -L VERSION -g ar5111.o
> --- all_subdir_cam ---
> /usr/src/sys/modules/cam/../../cam/scsi/scsi_da.c:1274:1: error: incompatible 
> pointer types initializing 'long *' with an expression of type 'sbintime_t *' 
> (aka 'long long *') [-Werror,-Wincompatible-pointer-types]
> TUNABLE_LONG("kern.cam.da.default_softtimeout", _default_softtimeout);
> ^~~~
> /usr/src/sys/sys/kernel.h:292:3: note: expanded from macro 'TUNABLE_LONG'
>(var),  \
>^
> --- all_subdir_ath ---
> --- ar5112.o ---
> cc  -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc  
> -I. -I/usr/src/sys/modules/ath/../../dev/ath 
> -I/usr/src/sys/modules/ath/../../dev/ath/ath_hal -I. 
> -I/usr/src/sys/modules/ath/../../contrib/dev/ath/ath_hal/ 
> -DHAVE_KERNEL_OPTION_HEADERS -include 
> /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g 
> -I/usr/obj/usr/src/sys/GENERIC  -MD  -MF.depend.ar5112.o -MTar5112.o -mno-mmx 
> -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -gdwarf-2 
> -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/ath/../../dev
> /ath/ath_hal/ar5212/ar5112.c -o ar5112.o
> --- all_subdir_cam ---
> 1 error generated.
> *** [scsi_da.o] Error code 1
> 
> bmake[4]: stopped in /usr/src/sys/modules/cam
> 1 error

Build’s still broken..
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ngie Cooper (yaneurabeya)]

(Replying because I kicked the hornet’s nest when my build failed)
Hi Ben,

> On May 7, 2016, at 00:27, Ben Woods  wrote:
> 
> On Saturday, 7 May 2016, Glen Barber  wrote:
> 
>> With 'installkernel', the first kernel listed in KERNCONF is installed
>> as the default (/boot/kernel), and subsequent kernels are installed with
>> the kernel name included in the path (/boot/kernel.${INSTKERNNAME}).  In
>> both cases (source-based upgrades and with pkgbase), the behavior will
>> remain the same.
>> 
>> Glen
>> 
> 
> Hi Glen,
> 
> With the recent commit mentioned previously, only the first kernel listed
> in KERNCONF is installed unless make.conf contains the following line:
> NO_INSTALLEXTRAKERNELS=no
> 
> This affects both source-based upgrades (make installkernel) and package
> building (make packages).
> 
> Is this the desired behaviour?

The naming is very confusing. It should be:

- MK_INSTALLEXTRAKERNELS=no -> only install one
- MK_INSTALLEXTRAKERNELS=yes -> install multiple, as gjb@ described above.

Since I kicked the hornet’s nest (and imp@ complained about the NO_*), I’ll 
introduce a new WITH/WITHOUT option for this and release/release.sh can use it.

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

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ngie Cooper (yaneurabeya)]

> On May 7, 2016, at 00:46, Ben Woods  wrote:
> 
> 
> On 7 May 2016 at 09:41, Glen Barber  wrote:
> I think this raises a larger question - did "something" change that
> otherwise violates POLA?  The commit recently was intended to revert
> a POLA violation, so maybe I am not entirely clear on what branch this
> affects.
> 
> Are we talking about head or stable/10 here?
> 
> Glen
> 
> I am talking about head, which no longer installs/packages multiple kernels 
> by default.
> https://svnweb.freebsd.org/base/head/Makefile.inc1?revision=299088=markup
> 
> Whilst the r299088 commit is referring to a stable POLA violation, the commit 
> itself is a change to head with a proposed MFC after 3 days. Its interesting, 
> because this has surprised me when testing PkgBase on head, as the behaviour 
> has changed from the initial announcement.

The behavior in and of itself (to me) is unintuitive. I use a different wrapper 
script [*] to install kernels with a different name because I want them to be 
versioned based on $KERNCONF + revision data. I only fixed building multiple 
kernels because the change that glebius tested didn’t work with more than one 
KERNCONF (hence the double commit).

I think the default behavior should be “yes” (not “no”) as many folks use a 
single KERNCONF, not multiple (on head), but I’m biased in this thinking...

Thanks!
-Ngie

* 
https://github.com/yaneurabeya/scratch/blob/master/bayonetta/root/bin/installkernel.sh
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ngie Cooper (yaneurabeya)]

> On May 7, 2016, at 00:59, Ben Woods <woods...@gmail.com> wrote:
> 
> On 7 May 2016 at 09:48, Ngie Cooper (yaneurabeya) <yaneurab...@gmail.com> 
> 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).

It’s tricky… KERNCONF with multiple kernel configurations wasn’t properly 
supported at install time until 2016 AFAIK (r291611, r293391), so again (AFAIK) 
it’s a new [functional] feature, even though make.conf(5) says one can specify 
multiple kernel configurations in KERNCONF at build time.

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

From a literal perspective, it makes perfect sense. From a usability 
perspective though, or in terms of actual behavior, it makes less sense.

If FreeBSD required more explicit pathing for kernels like Linux in the boot 
loader (e.g. grub) on many distros (e.g. CentOS), this would likely be a 
non-issue.

> 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).

Yes, but the knob should be renamed for clarity. imp@ had a very good point — 
NO_* options aren’t as flexible/intuitive as MK_* options and lead to confusing 
behavior.

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

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ngie Cooper (yaneurabeya)]

> On May 7, 2016, at 00:41, Glen Barber <g...@freebsd.org> wrote:
> 
> On Sat, May 07, 2016 at 12:35:10AM -0700, Ngie Cooper (yaneurabeya) wrote:
>> (Replying because I kicked the hornet’s nest when my build failed)
>> Hi Ben,
>> 
>>> On May 7, 2016, at 00:27, Ben Woods <woods...@gmail.com> wrote:
>>> 
>>> On Saturday, 7 May 2016, Glen Barber <g...@freebsd.org> wrote:
>>> 
>>>> With 'installkernel', the first kernel listed in KERNCONF is installed
>>>> as the default (/boot/kernel), and subsequent kernels are installed with
>>>> the kernel name included in the path (/boot/kernel.${INSTKERNNAME}).  In
>>>> both cases (source-based upgrades and with pkgbase), the behavior will
>>>> remain the same.
>>>> 
>>>> Glen
>>>> 
>>> 
>>> Hi Glen,
>>> 
>>> With the recent commit mentioned previously, only the first kernel listed
>>> in KERNCONF is installed unless make.conf contains the following line:
>>> NO_INSTALLEXTRAKERNELS=no
>>> 
>>> This affects both source-based upgrades (make installkernel) and package
>>> building (make packages).
>>> 
>>> Is this the desired behaviour?
>> 
>> The naming is very confusing. It should be:
>> 
>> - MK_INSTALLEXTRAKERNELS=no -> only install one
>> - MK_INSTALLEXTRAKERNELS=yes -> install multiple, as gjb@ described above.
>> 
>> Since I kicked the hornet’s nest (and imp@ complained about the
>> NO_*), I’ll introduce a new WITH/WITHOUT option for this and
>> release/release.sh can use it.
>> 
> 
> I think this raises a larger question - did "something" change that
> otherwise violates POLA?  The commit recently was intended to revert
> a POLA violation, so maybe I am not entirely clear on what branch this
> affects.
> 
> Are we talking about head or stable/10 here?

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