11.0 -r301815 builds based on xtoolchain tools targetting amd64 fail: error: redundant redeclaration of 'intel_fbc_enabled'

[Mark Millard]

[This is in essence a notice of bug 209924 --found after working around 209920 
in the cxgb and cxgbe areas.]

> --- all_subdir_drm2 ---
> In file included from 
> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/dvo.h:35:0,
>  from 
> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/dvo_ch7xxx.c:32:
> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_drv.h:671:13: 
> error: redundant redeclaration of 'intel_fbc_enabled' 
> [-Werror=redundant-decls]
>  extern bool intel_fbc_enabled(struct drm_device *dev);
>  ^
> In file included from 
> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_drv.h:31:0,
>  from 
> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/dvo.h:35,
>  from 
> /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/dvo_ch7xxx.c:32:
> /usr/src/sys/dev/drm2/i915/i915_drv.h:1676:13: note: previous declaration of 
> 'intel_fbc_enabled' was here
>  extern bool intel_fbc_enabled(struct drm_device *dev);
>  ^


Context details follow. . .

This was based on src.conf:

> # more ~/src.configs/src.conf.amd64-xtoolchain.amd64-host 
> TO_TYPE=amd64
> TOOLS_TO_TYPE=x86_64
> VERSION_CONTEXT=11.0
> #
> KERNCONF=GENERIC-NODEBUG
> TARGET=${TO_TYPE}
> .if ${.MAKE.LEVEL} == 0
> TARGET_ARCH=${TO_TYPE}
> .export TARGET_ARCH
> .endif
> #
> WITHOUT_CROSS_COMPILER=
> WITHOUT_SYSTEM_COMPILER=
> #
> WITH_LIBCPLUSPLUS=
> WITHOUT_BINUTILS_BOOTSTRAP=
> WITHOUT_CLANG_BOOTSTRAP=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_CLANG_EXTRAS=
> WITH_LLDB=
> #
> #WITH_BOOT= for amd64-xtoolschain-gcc/amd64-gcc gets... 
> # --- all_subdir_sys ---
> # -994 bytes available
> # *** [boot2] Error code 1
> WITHOUT_BOOT=
> WITH_LIB32=
> #
> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
> WITHOUT_GCC_BOOTSTRAP=
> WITHOUT_GCC=
> WITHOUT_GCC_IS_CC=
> WITHOUT_GNUCXX=
> #
> NO_WERROR=
> #WERROR=
> MALLOC_PRODUCTION=
> #
> WITH_DEBUG_FILES=
> #
> #
> # For TO (so-called "cross") stages . . .
> # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . .
> # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . .
> #
> CROSS_TOOLCHAIN=${TO_TYPE}-gcc
> X_COMPILER_TYPE=gcc
> CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/
> .if ${.MAKE.LEVEL} == 0
> XCC=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gcc
> XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g++
> XCPP=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-cpp
> .export XCC
> .export XCXX
> .export XCPP
> XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as
> XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar
> XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld
> XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm
> XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy
> XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump
> XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib
> XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size
> #NO-SUCH: XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings
> XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings
> .export XAS
> .export XAR
> .export XLD
> .export XNM
> .export XOBJCOPY
> .export XOBJDUMP
> .export XRANLIB
> .export XSIZE
> .export XSTRINGS
> .endif
> #
> #
> # From based on clang (via system). . .
> #
> .if ${.MAKE.LEVEL} == 0
> CC=/usr/bin/clang
> CXX=/usr/bin/clang++
> CPP=/usr/bin/clang-cpp
> .export CC
> .export CXX
> .export CPP
> .endif

and make.conf:

> # more ~/src.configs/make.conf 
> CFLAGS.gcc+= -v


===
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: The OpenBSD pledge

[Florian Ermisch]

Am 11. Juni 2016 18:31:25 MESZ, schrieb Alan Somers :
> On Sat, Jun 11, 2016 at 5:32 AM, Domagoj Stolfa
>  wrote:
> > Yes, it would maybe make sense to do so. I am not too familiar with
> > capsicum(4), but glancing over it, it might be possible. If
> anything, it
> > would allow for code reuse from the OpenBSD ports and increased
> portability
> > in the future. Maybe the people who have worked with capsicum(4) or
> have
> > developed it could give some more insight on this.
> >
> 
> I don't see how it would be possible.  Capsicum is all about file
> descriptors.  When you call cap_enter(), you give up the ability to
> access global namespaces.  For example, you can no longer open files
> (except using openat(2) for files in a subdirectory of a directory
> which is already opened).  OTOH, pledge is all about sycalls.  When
> you pledge, you give up the ability to use certain syscalls,
> regardless of what file descriptors they might involve.  So for
> example, a program that uses pledge(2) to prohibit networking syscalls
> can't simply replace pledge(2) with cap_enter(2), because it may need
> to open files after pledging.
> 
> -Alan

Thanks for the clarification, Alan.
So pledge(2) would, if implemented in
FreeBSD, complement capsicum.
They would only overlap around file
descriptors, where capsicum could 
enforce a processes pledge like to only
ever write to one file which is its logfile.

Florian
___
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  wrote:
> 
> 
> 
> On Sun, 12 Jun 2016 18:11:03 -0400
> Ngie Cooper  wrote:
> 
>>> 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
> 
> 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: The OpenBSD pledge

[Domagoj Stolfa]

On Mon, Jun 13, 2016 at 9:44 AM, Florian Ermisch <
florian.ermi...@alumni.tu-berlin.de> wrote:

>
>
> Am 11. Juni 2016 18:31:25 MESZ, schrieb Alan Somers :
> > On Sat, Jun 11, 2016 at 5:32 AM, Domagoj Stolfa
> >  wrote:
> > > Yes, it would maybe make sense to do so. I am not too familiar with
> > > capsicum(4), but glancing over it, it might be possible. If
> > anything, it
> > > would allow for code reuse from the OpenBSD ports and increased
> > portability
> > > in the future. Maybe the people who have worked with capsicum(4) or
> > have
> > > developed it could give some more insight on this.
> > >
> >
> > I don't see how it would be possible.  Capsicum is all about file
> > descriptors.  When you call cap_enter(), you give up the ability to
> > access global namespaces.  For example, you can no longer open files
> > (except using openat(2) for files in a subdirectory of a directory
> > which is already opened).  OTOH, pledge is all about sycalls.  When
> > you pledge, you give up the ability to use certain syscalls,
> > regardless of what file descriptors they might involve.  So for
> > example, a program that uses pledge(2) to prohibit networking syscalls
> > can't simply replace pledge(2) with cap_enter(2), because it may need
> > to open files after pledging.
> >
> > -Alan
>
> Thanks for the clarification, Alan.
> So pledge(2) would, if implemented in
> FreeBSD, complement capsicum.
> They would only overlap around file
> descriptors, where capsicum could
> enforce a processes pledge like to only
> ever write to one file which is its logfile.
>
> Florian
>

It indeed does seem like they could complement each other.
One could pledge the entire program and use capsicum(4)
to limit certain file descriptors even further, but not the rest
of the program, such as a TCP socket. This does seem like
increased simplicity in limiting the whole program using
pledge(2) and the additional benefit that capsicum(4) offers
in terms of file descriptors. The question remains though, how
would they interact with each other? A single pledge(2) call, as
Alan said could limit the operation of capsicum(4).

Domagoj
___
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 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? [still true of -r301815]

[Bryan Drewery]

On 6/12/2016 7:14 PM, Simon J. Gerraty wrote:
> Mark Millard  wrote:
>> Cross builds work just fine based on the FreeBSD tree when omitting 
>> WITH_META_MODE=.
>>
> 
> Hmm must do something odd then.
> 
>> As of -r301825 there is almost no use of HOST_CC at the upper levels or in 
>> share/mk/*:
> 
> Yes, which means if cross-building works it must be requring a separate
> walk of the tree or similar dance.

Yeah it's done in 2 walks with a shared objdir.  I am going to rework
these build-tools files to store their native binaries in BTOOLSDIR
(like DIRDEPS does for these for bootstrap-tools target actually).  Then
always use the one from the BTOOLSDIR, avoiding the chance of a target
one being built and ran from './'.

> It cannot work by building tools like make_keys in the same pass as the
> library, since that would require use of something other than CC.
> 
> 
>>> # grep HOST_CC /usr/src/Makefile*
>>> # grep HOST_CC /usr/src/share/mk/*
>>> /usr/src/share/mk/bsd.compiler.mk:.for var in CC CXX HOST_CC HOST_CXX
>>
>> where that last does:
> 
> Yes, that's for ccache, but I don't see HOST_CC used anywhere.
> 
> Sorry, guess I have no clue how cross-building currently works in
> FreeBSD, but as is it won't work with DIRDEPS - which pretty much
> expects to be able to build the tree in a single pass.
> 
> META_MODE should be orgthogonal, but that appears not to be so.
> 

It's mostly orthogonal. Since there is a shared objdir for both the
'build-tools' and 'lib' and 'everything' walks, the CFLAGS/CC does
change and cause rebuilds.  I have some hacks in there now that I'm not
happy with and am going to rework.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

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

[Mark Millard]

With the newly less strict alignment requirements "kyua test -k 
/usr/tests/Kyuafile" runs to completion, unlike before.

> ===> Summary
> Results read from 
> /root/.kyua/store/results.usr_tests.20160613-080302-120731.db
> Test cases: 5694 total, 54 skipped, 21 expected failures, 24 broken, 59 failed
> Total time: 8723.243s


I only list the one line summaries below. Then I list various context details.

> ===> Broken tests
> lib/msun/cexp_test:main  ->  broken: Received signal 6  [1.054s]
> lib/msun/ctrig_test:main  ->  broken: Received signal 6  [1.074s]
> lib/msun/exponential_test:main  ->  broken: Received signal 6  [1.045s]
> lib/msun/fenv_test:main  ->  broken: Received signal 6  [1.048s]
> lib/msun/fma_test:main  ->  broken: Received signal 6  [1.080s]
> lib/msun/invctrig_test:main  ->  broken: Received signal 6  [1.091s]
> lib/msun/invtrig_test:main  ->  broken: Received signal 6  [1.086s]
> lib/msun/logarithm_test:main  ->  broken: Received signal 6  [1.054s]
> lib/msun/lrint_test:main  ->  broken: Received signal 6  [1.069s]
> lib/msun/nearbyint_test:main  ->  broken: Received signal 6  [1.066s]
> lib/msun/rem_test:main  ->  broken: Received signal 6  [1.069s]
> lib/msun/trig_test:main  ->  broken: Received signal 6  [1.070s]
> sbin/growfs/legacy_test:main  ->  broken: Reported plan differs from actual 
> executed tests  [0.459s]
> sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test case timed out  
> [1200.082s]
> sys/geom/class/eli/integrity_hmac_test:main  ->  broken: Test case timed out  
> [600.138s]
> sys/geom/class/eli/onetime_a_test:main  ->  broken: Test case timed out  
> [600.044s]
> sys/sys/bitstring_test:bit_clear  ->  broken: Test case body timed out  
> [300.032s]
> sys/sys/bitstring_test:bit_count  ->  broken: Premature exit; test case 
> received signal 11 (core dumped)  [1.080s]
> sys/sys/bitstring_test:bit_ffc  ->  broken: Premature exit; test case 
> received signal 11 (core dumped)  [1.077s]
> sys/sys/bitstring_test:bit_ffc_at  ->  broken: Premature exit; test case 
> received signal 11 (core dumped)  [1.081s]
> sys/sys/bitstring_test:bit_ffs  ->  broken: Premature exit; test case 
> received signal 11 (core dumped)  [1.082s]
> sys/sys/bitstring_test:bit_ffs_at  ->  broken: Premature exit; test case 
> received signal 11 (core dumped)  [1.077s]
> sys/sys/bitstring_test:bit_nclear  ->  broken: Premature exit; test case 
> received signal 11 (core dumped)  [1.083s]
> sys/sys/bitstring_test:bit_nset  ->  broken: Premature exit; test case 
> received signal 11 (core dumped)  [1.079s]


> ===> Failed tests
> lib/libc/c063/fstatat_test:fstatat_fd  ->  failed: 
> /usr/src/contrib/netbsd-tests/lib/libc/c063/t_fstatat.c:74: memcmp(, 
> , sizeof(st1)) == 0 not met  [0.
> 027s]
> lib/libc/nss/gethostby_test:getipnodebyname_getaddrinfo_ipv4  ->  failed: 
> /usr/src/lib/libc/tests/nss/gethostby_test.c:1335: run_tests(_hostlist_file, 
> _snapshot
> _file, 2, TEST_GETHOSTBYNAME2_GETADDRINFO, 0) == 0 not met  [15.315s]
> lib/libc/ssp/ssp_test:fgets  ->  failed: Test case body returned a non-ok 
> exit code, but this is not allowed  [0.153s]
> lib/libc/ssp/ssp_test:gets  ->  failed: Test case body returned a non-ok exit 
> code, but this is not allowed  [0.158s]
> lib/libc/ssp/ssp_test:memcpy  ->  failed: atf-check failed; see the output of 
> the test for details  [0.148s]
> lib/libc/ssp/ssp_test:memmove  ->  failed: atf-check failed; see the output 
> of the test for details  [0.147s]
> lib/libc/ssp/ssp_test:memset  ->  failed: atf-check failed; see the output of 
> the test for details  [0.147s]
> lib/libc/ssp/ssp_test:read  ->  failed: Test case body returned a non-ok exit 
> code, but this is not allowed  [0.154s]
> lib/libc/ssp/ssp_test:readlink  ->  failed: atf-check failed; see the output 
> of the test for details  [0.155s]
> lib/libc/ssp/ssp_test:snprintf  ->  failed: atf-check failed; see the output 
> of the test for details  [0.149s]
> lib/libc/ssp/ssp_test:sprintf  ->  failed: atf-check failed; see the output 
> of the test for details  [0.149s]
> lib/libc/ssp/ssp_test:stpcpy  ->  failed: atf-check failed; see the output of 
> the test for details  [0.149s]
> lib/libc/ssp/ssp_test:stpncpy  ->  failed: atf-check failed; see the output 
> of the test for details  [0.147s]
> lib/libc/ssp/ssp_test:strcat  ->  failed: atf-check failed; see the output of 
> the test for details  [0.147s]
> lib/libc/ssp/ssp_test:strcpy  ->  failed: atf-check failed; see the output of 
> the test for details  [0.147s]
> lib/libc/ssp/ssp_test:strncat  ->  failed: atf-check failed; see the output 
> of the test for detail

Re: GPIO driver for Intel Atom SoC

[Lundberg, Johannes]

Hi Imre

This is great information. Thank you!

My device have an emmc chip on the pcb (non-removable).
Have you tested you code on that kind of system?

Current unmodified FreeBSD can detect the sdhci_pci controller and a mmc
card on slot0 but timeouts when trying to init the mmc. Not sure why it is
failing. I assumed it needed activating through some gpios but maybe it's
not that easy..


On Mon, Jun 13, 2016 at 2:38 AM, Imre Vadasz  wrote:

> Hi,
>
> Microsoft has some documentation on GPIO handling with SD card controllers,
> which should apply to most Cherryview devices:
>
> https://msdn.microsoft.com/windows/hardware/drivers/bringup/other-acpi-namespace-objects#sd
>
> I did some work on Cherryview SoC support in DragonFlyBSD.
> In DragonFly master, there is a simple GPIO driver for cherryview in
> /sys/bus/gpio/gpio_intel. In master, it's currently only used for
> handling the ACPI GeneralPurposeIo operation regions, and
> Acpi-Event-Interrupts (which replace GPE interrupts on reduced-hardware
> platforms).
>
> I have some further (more prototype level) code which also contains some
> code for Intel sdhci controller integration:
>
> https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/shortlog/refs/heads/cherryview
>
> With this branch everything sdcard/eMMC related works quite nicely, e.g.
> it properly handles plugging in/out the sd-card on my HP X2 210 detachable
> on DragonFlyBSD.
>
> To handle everything properly this contains a bit of work on mostly ACPI
> related stuff:
>
> ACPI device initialization order needs to be according to the ACPI _DEP
> methods:
>
> https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/commitdiff/25dec08cafa3ce9089eb5b216700f4e678b3356d
>
> We need to map ACPI nodes to the device objects (and at least track a
> reference count for debugging):
>
> https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/commitdiff/23135590ffb33b40f170c786ea95fc133358ebdb
>
> Then some kind of API is needed for handling the GeneralPurposeIo resources
> declared for the device in the ACPI tables (e.g. the sdhci controller).
> (i.e. some way of attempting to "map" the resource from the device driver):
>
> https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/commitdiff/d5b3d3447bbdd42a68359aebd61f271bfa830951
>
> And I have a prototype of adapting the sdhci driver to handle the GPIO
> ACPI resources, as described in "
> https://msdn.microsoft.com/windows/hardware/drivers/bringup/other-acpi-namespace-objects#sd
> ":
>
> https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/commitdiff/5d2844c280211cbb256a5ecc3ea27f952149e452
>
> Regards,
> Imre Vadász
>

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
___
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

[Alan Somers]

Please open a bug for the bitstring test failures and assign it to me.
Also, since I don't have any arm hardware, please provide instructions
on how to run this code in a VM, or where I can get access to the
hardware.

-Alan

On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard <mar...@dsl-only.net> wrote:
> With the newly less strict alignment requirements "kyua test -k 
> /usr/tests/Kyuafile" runs to completion, unlike before.
>
>> ===> Summary
>> Results read from 
>> /root/.kyua/store/results.usr_tests.20160613-080302-120731.db
>> Test cases: 5694 total, 54 skipped, 21 expected failures, 24 broken, 59 
>> failed
>> Total time: 8723.243s
>
>
> I only list the one line summaries below. Then I list various context details.
>
>> ===> Broken tests
>> lib/msun/cexp_test:main  ->  broken: Received signal 6  [1.054s]
>> lib/msun/ctrig_test:main  ->  broken: Received signal 6  [1.074s]
>> lib/msun/exponential_test:main  ->  broken: Received signal 6  [1.045s]
>> lib/msun/fenv_test:main  ->  broken: Received signal 6  [1.048s]
>> lib/msun/fma_test:main  ->  broken: Received signal 6  [1.080s]
>> lib/msun/invctrig_test:main  ->  broken: Received signal 6  [1.091s]
>> lib/msun/invtrig_test:main  ->  broken: Received signal 6  [1.086s]
>> lib/msun/logarithm_test:main  ->  broken: Received signal 6  [1.054s]
>> lib/msun/lrint_test:main  ->  broken: Received signal 6  [1.069s]
>> lib/msun/nearbyint_test:main  ->  broken: Received signal 6  [1.066s]
>> lib/msun/rem_test:main  ->  broken: Received signal 6  [1.069s]
>> lib/msun/trig_test:main  ->  broken: Received signal 6  [1.070s]
>> sbin/growfs/legacy_test:main  ->  broken: Reported plan differs from actual 
>> executed tests  [0.459s]
>> sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test case timed out 
>>  [1200.082s]
>> sys/geom/class/eli/integrity_hmac_test:main  ->  broken: Test case timed out 
>>  [600.138s]
>> sys/geom/class/eli/onetime_a_test:main  ->  broken: Test case timed out  
>> [600.044s]
>> sys/sys/bitstring_test:bit_clear  ->  broken: Test case body timed out  
>> [300.032s]
>> sys/sys/bitstring_test:bit_count  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.080s]
>> sys/sys/bitstring_test:bit_ffc  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.077s]
>> sys/sys/bitstring_test:bit_ffc_at  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.081s]
>> sys/sys/bitstring_test:bit_ffs  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.082s]
>> sys/sys/bitstring_test:bit_ffs_at  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.077s]
>> sys/sys/bitstring_test:bit_nclear  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.083s]
>> sys/sys/bitstring_test:bit_nset  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.079s]
>
>
>> ===> Failed tests
>> lib/libc/c063/fstatat_test:fstatat_fd  ->  failed: 
>> /usr/src/contrib/netbsd-tests/lib/libc/c063/t_fstatat.c:74: memcmp(, 
>> , sizeof(st1)) == 0 not met  [0.
>> 027s]
>> lib/libc/nss/gethostby_test:getipnodebyname_getaddrinfo_ipv4  ->  failed: 
>> /usr/src/lib/libc/tests/nss/gethostby_test.c:1335: run_tests(_hostlist_file, 
>> _snapshot
>> _file, 2, TEST_GETHOSTBYNAME2_GETADDRINFO, 0) == 0 not met  [15.315s]
>> lib/libc/ssp/ssp_test:fgets  ->  failed: Test case body returned a non-ok 
>> exit code, but this is not allowed  [0.153s]
>> lib/libc/ssp/ssp_test:gets  ->  failed: Test case body returned a non-ok 
>> exit code, but this is not allowed  [0.158s]
>> lib/libc/ssp/ssp_test:memcpy  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.148s]
>> lib/libc/ssp/ssp_test:memmove  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.147s]
>> lib/libc/ssp/ssp_test:memset  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.147s]
>> lib/libc/ssp/ssp_test:read  ->  failed: Test case body returned a non-ok 
>> exit code, but this is not allowed  [0.154s]
>> lib/libc/ssp/ssp_test:readlink  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.155s]
>> lib/libc/ssp/ssp_test:snprintf  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.149s]
>> lib/libc/ssp/ssp_test:sprintf  ->  failed: atf-check failed; see the output 
>> 

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

[Conrad Meyer]

FYI, this implies the ulong-accessed bitstring change is ABI-breaking
for ARM userspace and maybe shouldn't go to stable/10.

Best,
Conrad

On Mon, Jun 13, 2016 at 11:04 AM, Conrad Meyer <c...@freebsd.org> wrote:
> I expect it's because:
>
> 1. bitstr_size() is just bytes (doesn't round up to sizeof(bitstr_t ==
> unsigned long))
> 2. The userspace version of bit_alloc() uses calloc(bitstr_size(), 1)
> (an array of nmemb=bitstr_size() size=bytes, doesn't have to be
> 'unsigned long' sized or aligned).
> 3. Various bit_* functions access the result as if it's an array of
> 'unsigned long', when it was allocated as a single-byte array (no
> ulong alignment or size).
> 4. ARM isn't as happy about unaligned accesses as x86.
>
> I'd make the following change (needs sys/param.h, not compile tested)
> and see if it fixes it:
>
> --- sys/bitstring.h (revision 301805)
> +++ sys/bitstring.h (working copy)
> @@ -119,7 +119,8 @@
>  static inline bitstr_t *
>  bit_alloc(int _nbits)
>  {
> -   return ((bitstr_t *)calloc(bitstr_size(_nbits), 1));
> +   return (calloc(howmany(bitstr_size(_nbits), sizeof(bitstr_t)),
> +   sizeof(bitstr_t)));
>  }
>  #endif
>
>
>
>
>
>
> On Mon, Jun 13, 2016 at 10:49 AM, Alan Somers <asom...@freebsd.org> wrote:
>> Please open a bug for the bitstring test failures and assign it to me.
>> Also, since I don't have any arm hardware, please provide instructions
>> on how to run this code in a VM, or where I can get access to the
>> hardware.
>>
>> -Alan
>>
>> On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard <mar...@dsl-only.net> wrote:
>>> With the newly less strict alignment requirements "kyua test -k 
>>> /usr/tests/Kyuafile" runs to completion, unlike before.
>>>
>>>> ===> Summary
>>>> Results read from 
>>>> /root/.kyua/store/results.usr_tests.20160613-080302-120731.db
>>>> Test cases: 5694 total, 54 skipped, 21 expected failures, 24 broken, 59 
>>>> failed
>>>> Total time: 8723.243s
>>>
>>>
>>> I only list the one line summaries below. Then I list various context 
>>> details.
>>>
>>>> ===> Broken tests
>>>> lib/msun/cexp_test:main  ->  broken: Received signal 6  [1.054s]
>>>> lib/msun/ctrig_test:main  ->  broken: Received signal 6  [1.074s]
>>>> lib/msun/exponential_test:main  ->  broken: Received signal 6  [1.045s]
>>>> lib/msun/fenv_test:main  ->  broken: Received signal 6  [1.048s]
>>>> lib/msun/fma_test:main  ->  broken: Received signal 6  [1.080s]
>>>> lib/msun/invctrig_test:main  ->  broken: Received signal 6  [1.091s]
>>>> lib/msun/invtrig_test:main  ->  broken: Received signal 6  [1.086s]
>>>> lib/msun/logarithm_test:main  ->  broken: Received signal 6  [1.054s]
>>>> lib/msun/lrint_test:main  ->  broken: Received signal 6  [1.069s]
>>>> lib/msun/nearbyint_test:main  ->  broken: Received signal 6  [1.066s]
>>>> lib/msun/rem_test:main  ->  broken: Received signal 6  [1.069s]
>>>> lib/msun/trig_test:main  ->  broken: Received signal 6  [1.070s]
>>>> sbin/growfs/legacy_test:main  ->  broken: Reported plan differs from 
>>>> actual executed tests  [0.459s]
>>>> sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test case timed 
>>>> out  [1200.082s]
>>>> sys/geom/class/eli/integrity_hmac_test:main  ->  broken: Test case timed 
>>>> out  [600.138s]
>>>> sys/geom/class/eli/onetime_a_test:main  ->  broken: Test case timed out  
>>>> [600.044s]
>>>> sys/sys/bitstring_test:bit_clear  ->  broken: Test case body timed out  
>>>> [300.032s]
>>>> sys/sys/bitstring_test:bit_count  ->  broken: Premature exit; test case 
>>>> received signal 11 (core dumped)  [1.080s]
>>>> sys/sys/bitstring_test:bit_ffc  ->  broken: Premature exit; test case 
>>>> received signal 11 (core dumped)  [1.077s]
>>>> sys/sys/bitstring_test:bit_ffc_at  ->  broken: Premature exit; test case 
>>>> received signal 11 (core dumped)  [1.081s]
>>>> sys/sys/bitstring_test:bit_ffs  ->  broken: Premature exit; test case 
>>>> received signal 11 (core dumped)  [1.082s]
>>>> sys/sys/bitstring_test:bit_ffs_at  ->  broken: Premature exit; test case 
>>>> received signal 11 (core dumped)  [1.077s]
>>>> sys/sys/bitstring_test:bit_nclear  ->  broken: Premature exit; test case 
>>>> received signal 11 (core d

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

[Jan Bramkamp]

On 10/06/16 16:29, Peter Wemm wrote:

On 6/9/16 6:49 PM, Matthew Seaman wrote:

On 09/06/2016 18:34, Craig Rodrigues wrote:

There is still value to ypldap as it is now, and getting feedback from
users (especially Active Directory) would be very useful.
If someone could document a configuration which uses IPSEC or OpenSSH
forwarding, that would be nice.

In future, maybe someone in OpenBSD or FreeBSD will implement things
like
LDAP over SSL.


What advantages does ypldap offer over nss-pam-ldapd (in ports) ?
nss-pam-ldapd can use both ldap+STARTTLS or ldaps to encrypt data in
transit, and I find it works very well for using OpenLDAP as a central
account database.  I believe it works with AD, but haven't tried that
myself.

Cheers,

Matthew




We used nss-pam-ldapd quite successfully in the freebsd.org cluster
during our transition away from YP/NIS, for what it's worth.


Did you try the OpenLDAP nssov overlay? It replaces nslcd by 
reimplementing the protocol spoken between nslcd and nss_ldap/pam_ldap 
directly inside slapd. This allows slapd to cache or replicate the data 
locally without resorting to the broken nscd.

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

rtwn connection stops working on CURRENT

[Marcus von Appen]

Hi,

I'm running into a somewhat weird issue with the rtwn driver
on CURRENT. It usually works for a couple of minutes (if there's
not too much of troughput happening) before the downstream and
upstream rates just "dry up" and the interface stops working.
It happens faster, if there are multiple connections open at the
same time, e.g. having a browser open or fetching mail and doing
a portsnap update.

Once the connection stopped working, dhclient will report the
following:

  Jun 11 12:22:22 athena dhclient[474]: send_packet: no buffer space available
  Jun 11 12:24:08 athena last message repeated 4 times
  ...

wpa_supplicant reports:

  Jun 11 12:22:20 athena wpa_supplicant[335]: wlan0: CTRL-EVENT-DISCONNECTED 
bssid=... reason=3 locally_generated=1
  Jun 11 12:22:20 athena wpa_supplicant[335]: wlan0: WPA: 4-Way Handshake 
failed - pre-shared key may be incorrect
  Jun 11 12:22:20 athena wpa_supplicant[335]: wlan0: 
CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="..." auth_failures=8 duration=100 
reason=WRONG_KEY
  Jun 11 12:22:20 athena wpa_supplicant[335]: wlan0: 
CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="..." auth_failures=9 duration=152 
reason=CONN_FAILED

pciconf -lv:

rtwn0@pci0:3:0:0: class=0x028000 card=0x819510ec chip=0x817610ec rev=0x01 
hdr=0x00
  vendor = 'Realtek Semiconductor Co., Ltd.'
  device = 'RTL8188CE 802.11b/g/n WiFi Adapter'
  class  = network

An pointers on tracking this issue down and getting it fixed are
highly appreciated.

Cheers
Marcus
___
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: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode

[Robert N. M. Watson]

On 13 Jun 2016, at 12:09, Joel Dahl  wrote:
> 
>> On Mon, Jun 13, 2016 at 07:00:46AM -0400, Ngie Cooper (yaneurabeya) wrote:
>> 
>>> 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.
> 
> Hi,
> 
> This is with r301857. Forgot to mention that in my previous mail. Sorry.

I can't see that these are in any way related to the error message. In fact, I 
saw the same login.conf message (and wondered about it) before committing the 
BSM fix. This sounds like an sshd or login issue? The former is more likely as 
I don't think the latter uses sandboxing.

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

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

[Mark Millard]

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?

===
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: WITH_META_MODE vs. delete-old and delete-old-libs

[Bryan Drewery]

On 6/13/2016 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 thought I had fixed this but I see I did not. There's a few similar
bugs here to fix.  WITH_META_MODE=yes is intended to be safe to always
set.  Mergemaster is special since it is building private targets rather
than only public targets.  So I'll likely have to patch it.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

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

[Bryan Drewery]

On 6/13/2016 2:51 PM, Ngie Cooper wrote:
> 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
> 

The problem is that the y/n prompt don't show at all.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

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

[Bryan Drewery]

On 6/13/2016 2:54 PM, Ngie Cooper wrote:
> 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?


I'm trying to decide between whitelist and blacklist on this.  Both have
problems for downstream vendors who have custom targets. However, only
buildworld and SUBDIR_OVERRIDE/all really needs meta mode.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

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

[Mark Millard]

On 2016-Jun-13, at 2:51 PM, Ngie Cooper  wrote:

> 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

For my amd64, rpi2, and powerpc (non-64) activities I can do such things rather 
than answer prompts individually --and have sometimes.

But for my libc++/xtoolchain based powerpc64 environment I've got a couple of 
things it lists for delete-old that I do not want deleted because I've got 
special things in place. If the check-old list is fairly short I answer 
delete-old individually. If the check-old list is really long I delete all and 
run a script that puts back my couple of oddities (which happen to be symbolic 
links).

Thus I tend to expect and use the individual delete-old prompts at least for 
one of my contexts.

I do have a tendency to work similarly across contexts even when local 
optimizations could be made. So I tend to treat amd64, armv6, powerpc similar 
to powerpc64 for check-old/delete-old use. [Another example: I'm unlikely to 
use ports-mgmt/synth on amd64 because I can not use it on armv6, powerpc, or 
powerpc64.]

And that explains why I noticed the issue even though I currently do not have 
access to the powerpc64 or powerpc machines.

===
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: mergemaster internally using make [for example] vs. WITH_META_MODE?

[Mark Millard]

On 2016-Jun-13, at 3:27 PM, Bryan Drewery  wrote:

> On 6/11/2016 7:28 PM, Mark Millard wrote:
>> mergemaster [as an example] has code like:
>> 
>>> # grep -i make /usr/sbin/mergemaster | more
>> . . .
>>> MM_MAKE="make ${ARCHSTRING} -m ${SOURCEDIR}/share/mk"
>>>${MM_MAKE} DESTDIR=${DESTDIR} distrib-dirs >/dev/null
>>>  ${MM_MAKE} DESTDIR=${TEMPROOT} distrib-dirs >/dev/null &&
>>>  ${MM_MAKE} _obj SUBDIR_OVERRIDE=etc >/dev/null &&
>>>  ${MM_MAKE} everything SUBDIR_OVERRIDE=etc >/dev/null &&
>>>  ${MM_MAKE} DESTDIR=${TEMPROOT} distribution >/dev/null;} ||
>> . . .
>> 
>> If one is using WITH_META_MODE= for buildworld, buidlkernel, installkernel, 
>> installworld what is appropriate for scripts or other uses of make for other 
>> makefile-targets?
>> 
>> Are there explicit mixes of using WITH_META_MODE= for some makefile targets 
>> and not using WITH_META_MODE= for other makefile targets that need to be 
>> avoided? Does one need to force some scripts to use [or not use] 
>> WITH_META_MODE= for their "internal" make usage?
>> 
> 
> Is there an actual bug with mergemaster with WITH_META_MODE?
> 
> 
> -- 
> Regards,
> Bryan Drewery

I do not know. I was not sure if lack of WITH_META_MODE=yes for mergemaster's 
internal make uses might mess up later make commands that use 
WITH_META_MODE=yes for explicit make activities. Overall that would be a mix of 
with and without.

As stands I use the following script for mergemaster (TARGET_ARCH=amd64 
example):

# more ~/sys_build_scripts.amd64-host/mergemaster_amd64-amd64-host.sh 
script ~/sys_typescripts/typescript_mergemaster_amd64-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" \
MAKEOBJDIRPREFIX="/usr/obj/clang/amd64.amd64" \
mergemaster -A amd64 $*

I've not added WITH_META_MODE=yes to the env yet.


I've been wondering if I should add WITH_META_MODE=yes to such scripts when the 
matching "make" script uses WITH_META_MODE=yes --such as:

# 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 $*


[Based on current behavior I normally only use WITH_META_MODE=yes for the host 
targeting its own architecture.]


===
Mark Millard
mar...@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: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? [still true of -r301815]

[Bryan Drewery]

On 6/11/2016 9:55 PM, Mark Millard wrote:
> Doing cleanworld instead of "-j 5 buildworld buildkernel" and then retrying 
> "-j 5 buildworld buildkernel" resulted in the same sort of thing but for 
> maketab instead:

The cleanworld likely fixed an issue of a stale file sitting in the
objdir.  I was able to reproduce the maketab bug though and am fixing that.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

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"

Re: mergemaster internally using make [for example] vs. WITH_META_MODE?

[Bryan Drewery]

On 6/11/2016 7:28 PM, Mark Millard wrote:
> mergemaster [as an example] has code like:
> 
>> # grep -i make /usr/sbin/mergemaster | more
> . . .
>> MM_MAKE="make ${ARCHSTRING} -m ${SOURCEDIR}/share/mk"
>> ${MM_MAKE} DESTDIR=${DESTDIR} distrib-dirs >/dev/null
>>   ${MM_MAKE} DESTDIR=${TEMPROOT} distrib-dirs >/dev/null &&
>>   ${MM_MAKE} _obj SUBDIR_OVERRIDE=etc >/dev/null &&
>>   ${MM_MAKE} everything SUBDIR_OVERRIDE=etc >/dev/null &&
>>   ${MM_MAKE} DESTDIR=${TEMPROOT} distribution >/dev/null;} ||
> . . .
> 
> If one is using WITH_META_MODE= for buildworld, buidlkernel, installkernel, 
> installworld what is appropriate for scripts or other uses of make for other 
> makefile-targets?
> 
> Are there explicit mixes of using WITH_META_MODE= for some makefile targets 
> and not using WITH_META_MODE= for other makefile targets that need to be 
> avoided? Does one need to force some scripts to use [or not use] 
> WITH_META_MODE= for their "internal" make usage?
> 

Is there an actual bug with mergemaster with WITH_META_MODE?


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: 11.0 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? [still true of -r301815]

[Simon J. Gerraty]

Bryan Drewery  wrote:
> > eg. in our internal tree - which cross builds fine:
> > 
> > make_keys: make_keys.c names.c ncurses_def.h ${HEADERS}
> > ${HOST_CC} -o $@ ${HOST_CFLAGS} 
> > ${NCURSES_DIR}/ncurses/tinfo/make_keys.c
> 
> I like this method but am going to put it off for a while.  The

The above is a reasonably non-intrusive way of dealing with targets like
that.

For tools which are more expensive to build, having a separate dir is
best, since (with DIRDEPS at least) it is then easier to build them
only once and at the right time.
___
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

[Mark Millard]

[I've added a list of core files generated and a few other notes.]

On 2016-Jun-13, at 10:29 AM, Mark Millard  wrote:

> With the newly less strict alignment requirements "kyua test -k 
> /usr/tests/Kyuafile" runs to completion, unlike before.
> 
>> ===> Summary
>> Results read from 
>> /root/.kyua/store/results.usr_tests.20160613-080302-120731.db
>> Test cases: 5694 total, 54 skipped, 21 expected failures, 24 broken, 59 
>> failed
>> Total time: 8723.243s
> 
> 
> I only list the one line summaries below. Then I list various context details.
> 
>> ===> Broken tests
>> lib/msun/cexp_test:main  ->  broken: Received signal 6  [1.054s]
>> lib/msun/ctrig_test:main  ->  broken: Received signal 6  [1.074s]
>> lib/msun/exponential_test:main  ->  broken: Received signal 6  [1.045s]
>> lib/msun/fenv_test:main  ->  broken: Received signal 6  [1.048s]
>> lib/msun/fma_test:main  ->  broken: Received signal 6  [1.080s]
>> lib/msun/invctrig_test:main  ->  broken: Received signal 6  [1.091s]
>> lib/msun/invtrig_test:main  ->  broken: Received signal 6  [1.086s]
>> lib/msun/logarithm_test:main  ->  broken: Received signal 6  [1.054s]
>> lib/msun/lrint_test:main  ->  broken: Received signal 6  [1.069s]
>> lib/msun/nearbyint_test:main  ->  broken: Received signal 6  [1.066s]
>> lib/msun/rem_test:main  ->  broken: Received signal 6  [1.069s]
>> lib/msun/trig_test:main  ->  broken: Received signal 6  [1.070s]
>> sbin/growfs/legacy_test:main  ->  broken: Reported plan differs from actual 
>> executed tests  [0.459s]
>> sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test case timed out 
>>  [1200.082s]
>> sys/geom/class/eli/integrity_hmac_test:main  ->  broken: Test case timed out 
>>  [600.138s]
>> sys/geom/class/eli/onetime_a_test:main  ->  broken: Test case timed out  
>> [600.044s]
>> sys/sys/bitstring_test:bit_clear  ->  broken: Test case body timed out  
>> [300.032s]
>> sys/sys/bitstring_test:bit_count  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.080s]
>> sys/sys/bitstring_test:bit_ffc  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.077s]
>> sys/sys/bitstring_test:bit_ffc_at  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.081s]
>> sys/sys/bitstring_test:bit_ffs  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.082s]
>> sys/sys/bitstring_test:bit_ffs_at  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.077s]
>> sys/sys/bitstring_test:bit_nclear  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.083s]
>> sys/sys/bitstring_test:bit_nset  ->  broken: Premature exit; test case 
>> received signal 11 (core dumped)  [1.079s]
> 
> 
>> ===> Failed tests
>> lib/libc/c063/fstatat_test:fstatat_fd  ->  failed: 
>> /usr/src/contrib/netbsd-tests/lib/libc/c063/t_fstatat.c:74: memcmp(, 
>> , sizeof(st1)) == 0 not met  [0.
>> 027s]
>> lib/libc/nss/gethostby_test:getipnodebyname_getaddrinfo_ipv4  ->  failed: 
>> /usr/src/lib/libc/tests/nss/gethostby_test.c:1335: run_tests(_hostlist_file, 
>> _snapshot
>> _file, 2, TEST_GETHOSTBYNAME2_GETADDRINFO, 0) == 0 not met  [15.315s]
>> lib/libc/ssp/ssp_test:fgets  ->  failed: Test case body returned a non-ok 
>> exit code, but this is not allowed  [0.153s]
>> lib/libc/ssp/ssp_test:gets  ->  failed: Test case body returned a non-ok 
>> exit code, but this is not allowed  [0.158s]
>> lib/libc/ssp/ssp_test:memcpy  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.148s]
>> lib/libc/ssp/ssp_test:memmove  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.147s]
>> lib/libc/ssp/ssp_test:memset  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.147s]
>> lib/libc/ssp/ssp_test:read  ->  failed: Test case body returned a non-ok 
>> exit code, but this is not allowed  [0.154s]
>> lib/libc/ssp/ssp_test:readlink  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.155s]
>> lib/libc/ssp/ssp_test:snprintf  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.149s]
>> lib/libc/ssp/ssp_test:sprintf  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.149s]
>> lib/libc/ssp/ssp_test:stpcpy  ->  failed: atf-check failed; see the output 
>> of the test for details  [0.149s]
>> lib

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

[Alan Somers]

This isn't an ABI issue.  Since there's no dynamic library, there's no
ABI to break except for weird circumstances like writing the in-memory
representation of a bitstring to a file, rebuilding world, and reading
that file back in.  The ATF tests aren't doing anything like that.

On Mon, Jun 13, 2016 at 12:05 PM, Conrad Meyer <c...@freebsd.org> wrote:
> FYI, this implies the ulong-accessed bitstring change is ABI-breaking
> for ARM userspace and maybe shouldn't go to stable/10.
>
> Best,
> Conrad
>
> On Mon, Jun 13, 2016 at 11:04 AM, Conrad Meyer <c...@freebsd.org> wrote:
>> I expect it's because:
>>
>> 1. bitstr_size() is just bytes (doesn't round up to sizeof(bitstr_t ==
>> unsigned long))
>> 2. The userspace version of bit_alloc() uses calloc(bitstr_size(), 1)
>> (an array of nmemb=bitstr_size() size=bytes, doesn't have to be
>> 'unsigned long' sized or aligned).
>> 3. Various bit_* functions access the result as if it's an array of
>> 'unsigned long', when it was allocated as a single-byte array (no
>> ulong alignment or size).
>> 4. ARM isn't as happy about unaligned accesses as x86.
>>
>> I'd make the following change (needs sys/param.h, not compile tested)
>> and see if it fixes it:
>>
>> --- sys/bitstring.h (revision 301805)
>> +++ sys/bitstring.h (working copy)
>> @@ -119,7 +119,8 @@
>>  static inline bitstr_t *
>>  bit_alloc(int _nbits)
>>  {
>> -   return ((bitstr_t *)calloc(bitstr_size(_nbits), 1));
>> +   return (calloc(howmany(bitstr_size(_nbits), sizeof(bitstr_t)),
>> +   sizeof(bitstr_t)));
>>  }
>>  #endif
>>
>>
>>
>>
>>
>>
>> On Mon, Jun 13, 2016 at 10:49 AM, Alan Somers <asom...@freebsd.org> wrote:
>>> Please open a bug for the bitstring test failures and assign it to me.
>>> Also, since I don't have any arm hardware, please provide instructions
>>> on how to run this code in a VM, or where I can get access to the
>>> hardware.
>>>
>>> -Alan
>>>
>>> On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard <mar...@dsl-only.net> wrote:
>>>> With the newly less strict alignment requirements "kyua test -k 
>>>> /usr/tests/Kyuafile" runs to completion, unlike before.
>>>>
>>>>> ===> Summary
>>>>> Results read from 
>>>>> /root/.kyua/store/results.usr_tests.20160613-080302-120731.db
>>>>> Test cases: 5694 total, 54 skipped, 21 expected failures, 24 broken, 59 
>>>>> failed
>>>>> Total time: 8723.243s
>>>>
>>>>
>>>> I only list the one line summaries below. Then I list various context 
>>>> details.
>>>>
>>>>> ===> Broken tests
>>>>> lib/msun/cexp_test:main  ->  broken: Received signal 6  [1.054s]
>>>>> lib/msun/ctrig_test:main  ->  broken: Received signal 6  [1.074s]
>>>>> lib/msun/exponential_test:main  ->  broken: Received signal 6  [1.045s]
>>>>> lib/msun/fenv_test:main  ->  broken: Received signal 6  [1.048s]
>>>>> lib/msun/fma_test:main  ->  broken: Received signal 6  [1.080s]
>>>>> lib/msun/invctrig_test:main  ->  broken: Received signal 6  [1.091s]
>>>>> lib/msun/invtrig_test:main  ->  broken: Received signal 6  [1.086s]
>>>>> lib/msun/logarithm_test:main  ->  broken: Received signal 6  [1.054s]
>>>>> lib/msun/lrint_test:main  ->  broken: Received signal 6  [1.069s]
>>>>> lib/msun/nearbyint_test:main  ->  broken: Received signal 6  [1.066s]
>>>>> lib/msun/rem_test:main  ->  broken: Received signal 6  [1.069s]
>>>>> lib/msun/trig_test:main  ->  broken: Received signal 6  [1.070s]
>>>>> sbin/growfs/legacy_test:main  ->  broken: Reported plan differs from 
>>>>> actual executed tests  [0.459s]
>>>>> sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test case timed 
>>>>> out  [1200.082s]
>>>>> sys/geom/class/eli/integrity_hmac_test:main  ->  broken: Test case timed 
>>>>> out  [600.138s]
>>>>> sys/geom/class/eli/onetime_a_test:main  ->  broken: Test case timed out  
>>>>> [600.044s]
>>>>> sys/sys/bitstring_test:bit_clear  ->  broken: Test case body timed out  
>>>>> [300.032s]
>>>>> sys/sys/bitstring_test:bit_count  ->  broken: Premature exit; test case 
>>>>> received signal 11 (core dumped)  [1.080s]
>>>>> sys/sys/bitstrin

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

[Conrad Meyer]

I expect it's because:

1. bitstr_size() is just bytes (doesn't round up to sizeof(bitstr_t ==
unsigned long))
2. The userspace version of bit_alloc() uses calloc(bitstr_size(), 1)
(an array of nmemb=bitstr_size() size=bytes, doesn't have to be
'unsigned long' sized or aligned).
3. Various bit_* functions access the result as if it's an array of
'unsigned long', when it was allocated as a single-byte array (no
ulong alignment or size).
4. ARM isn't as happy about unaligned accesses as x86.

I'd make the following change (needs sys/param.h, not compile tested)
and see if it fixes it:

--- sys/bitstring.h (revision 301805)
+++ sys/bitstring.h (working copy)
@@ -119,7 +119,8 @@
 static inline bitstr_t *
 bit_alloc(int _nbits)
 {
-   return ((bitstr_t *)calloc(bitstr_size(_nbits), 1));
+   return (calloc(howmany(bitstr_size(_nbits), sizeof(bitstr_t)),
+   sizeof(bitstr_t)));
 }
 #endif






On Mon, Jun 13, 2016 at 10:49 AM, Alan Somers <asom...@freebsd.org> wrote:
> Please open a bug for the bitstring test failures and assign it to me.
> Also, since I don't have any arm hardware, please provide instructions
> on how to run this code in a VM, or where I can get access to the
> hardware.
>
> -Alan
>
> On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard <mar...@dsl-only.net> wrote:
>> With the newly less strict alignment requirements "kyua test -k 
>> /usr/tests/Kyuafile" runs to completion, unlike before.
>>
>>> ===> Summary
>>> Results read from 
>>> /root/.kyua/store/results.usr_tests.20160613-080302-120731.db
>>> Test cases: 5694 total, 54 skipped, 21 expected failures, 24 broken, 59 
>>> failed
>>> Total time: 8723.243s
>>
>>
>> I only list the one line summaries below. Then I list various context 
>> details.
>>
>>> ===> Broken tests
>>> lib/msun/cexp_test:main  ->  broken: Received signal 6  [1.054s]
>>> lib/msun/ctrig_test:main  ->  broken: Received signal 6  [1.074s]
>>> lib/msun/exponential_test:main  ->  broken: Received signal 6  [1.045s]
>>> lib/msun/fenv_test:main  ->  broken: Received signal 6  [1.048s]
>>> lib/msun/fma_test:main  ->  broken: Received signal 6  [1.080s]
>>> lib/msun/invctrig_test:main  ->  broken: Received signal 6  [1.091s]
>>> lib/msun/invtrig_test:main  ->  broken: Received signal 6  [1.086s]
>>> lib/msun/logarithm_test:main  ->  broken: Received signal 6  [1.054s]
>>> lib/msun/lrint_test:main  ->  broken: Received signal 6  [1.069s]
>>> lib/msun/nearbyint_test:main  ->  broken: Received signal 6  [1.066s]
>>> lib/msun/rem_test:main  ->  broken: Received signal 6  [1.069s]
>>> lib/msun/trig_test:main  ->  broken: Received signal 6  [1.070s]
>>> sbin/growfs/legacy_test:main  ->  broken: Reported plan differs from actual 
>>> executed tests  [0.459s]
>>> sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test case timed 
>>> out  [1200.082s]
>>> sys/geom/class/eli/integrity_hmac_test:main  ->  broken: Test case timed 
>>> out  [600.138s]
>>> sys/geom/class/eli/onetime_a_test:main  ->  broken: Test case timed out  
>>> [600.044s]
>>> sys/sys/bitstring_test:bit_clear  ->  broken: Test case body timed out  
>>> [300.032s]
>>> sys/sys/bitstring_test:bit_count  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.080s]
>>> sys/sys/bitstring_test:bit_ffc  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.077s]
>>> sys/sys/bitstring_test:bit_ffc_at  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.081s]
>>> sys/sys/bitstring_test:bit_ffs  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.082s]
>>> sys/sys/bitstring_test:bit_ffs_at  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.077s]
>>> sys/sys/bitstring_test:bit_nclear  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.083s]
>>> sys/sys/bitstring_test:bit_nset  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.079s]
>>
>>
>>> ===> Failed tests
>>> lib/libc/c063/fstatat_test:fstatat_fd  ->  failed: 
>>> /usr/src/contrib/netbsd-tests/lib/libc/c063/t_fstatat.c:74: memcmp(, 
>>> , sizeof(st1)) == 0 not met  [0.
>>> 027s]
>>> lib/libc/nss/gethostby_test:getipnodebyname_getaddrinfo_ipv4  ->  failed: 
>>> /usr/src/lib/libc/tests/nss/gethostby_test.c:1335: 
>>> run_t

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

[Mark Millard]

On 2016-Jun-13, at 10:49 AM, Alan Somers  wrote:

> Please open a bug for the bitstring test failures and assign it to me.
> Also, since I don't have any arm hardware, please provide instructions
> on how to run this code in a VM, or where I can get access to the
> hardware.
> 
> -Alan

I have created https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210260 for the 
broken kyua bitstring tests.

I do not seem to have any control over the Assignee. (I  have no FreeBSD status 
of any kind so this is not surprising to me.)

I've never used QEMU or any arm-hardware based virtual machines. I've only used 
an rpi2 for armv6. So far the only VM's I've used are for amd64 running on 
amd64 hardware --and I run those under Mac OS X (VirtualBox, Parallels).

I'm not set up to give remote access to the rpi2 that I'm using.

So at this point I'm not much help for those arm-specific instructions that you 
asked for. Sorry.

===
Mark Millard
markmi at dsl-only.net

> On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard  wrote:
>> With the newly less strict alignment requirements "kyua test -k 
>> /usr/tests/Kyuafile" runs to completion, unlike before.
>> 
>>> ===> Summary
>>> Results read from 
>>> /root/.kyua/store/results.usr_tests.20160613-080302-120731.db
>>> Test cases: 5694 total, 54 skipped, 21 expected failures, 24 broken, 59 
>>> failed
>>> Total time: 8723.243s
>> 
>> 
>> I only list the one line summaries below. Then I list various context 
>> details.
>> 
>>> ===> Broken tests
. . .
>>> sys/sys/bitstring_test:bit_clear  ->  broken: Test case body timed out  
>>> [300.032s]
>>> sys/sys/bitstring_test:bit_count  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.080s]
>>> sys/sys/bitstring_test:bit_ffc  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.077s]
>>> sys/sys/bitstring_test:bit_ffc_at  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.081s]
>>> sys/sys/bitstring_test:bit_ffs  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.082s]
>>> sys/sys/bitstring_test:bit_ffs_at  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.077s]
>>> sys/sys/bitstring_test:bit_nclear  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.083s]
>>> sys/sys/bitstring_test:bit_nset  ->  broken: Premature exit; test case 
>>> received signal 11 (core dumped)  [1.079s]
>> 
. . .
___
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 -r301139: WITH_META_MODE=yes vs. "sh: ./make_keys: Exec format error"? [still true of -r301815]

[Bryan Drewery]

On 6/12/2016 5:39 AM, Simon J. Gerraty wrote:
> eg. in our internal tree - which cross builds fine:
> 
> make_keys: make_keys.c names.c ncurses_def.h ${HEADERS}
> ${HOST_CC} -o $@ ${HOST_CFLAGS} 
> ${NCURSES_DIR}/ncurses/tinfo/make_keys.c

I like this method but am going to put it off for a while.  The
confusion of CC vs XCC is bad enough without introducing a HOST_CC.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: 11.0 -r301815 to -r310873 using WITH_META_MODE=yes : an empty filename failure

[Bryan Drewery]

On 6/13/2016 7:26 PM, Mark Millard wrote:
> [The following is after the svnltie update -r301873 /usr/src .]
> 
> For the following in a amd64 rebuild on amd64 (a WITH_META_MODE=yes 
> buidlworld buidlkernel just after a without meta mode buildworld buildkernel 
> [no install]). . .
> 
>> # more sys/modules/drm2/radeonkmsfw/Makefile.inc 
>> # $FreeBSD: head/sys/modules/drm2/radeonkmsfw/Makefile.inc 254885 2013-08-25 
>> 19:37:15Z dumbbell $
>> #
>> # Common rules for building firmware.  Note this gets auto-included
>> # by the subdir Makefile's as a consequence of included bsd.kmod.mk.
>>
>> _FIRM=  ${IMG}.bin
>>
>> CLEANFILES+=${_FIRM}
>>
>> FIRMWS= ${_FIRM}:${KMOD}
>>
>> #
>> # Note that a license ack is not needed for iwn.
>> #
>> #FIRMWARE_LICENSE=
>>
>> ${_FIRM}: ${.CURDIR}/../../../../contrib/dev/drm2/radeonkmsfw/${_FIRM}.uu
>> uudecode -p $? > ${.TARGET}
> 
> 
> I just had . . .
> (Note the uudecode line in the .meta file, the reference to stdin, and the 
> resultant "begin" line error.)
> 
>> # more 
>> /usr/obj/clang/amd64.amd64/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_me/ARUBA_me.bin.meta
>>  
>> # Meta data file 
>> /usr/obj/clang/amd64.amd64/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_me/ARUBA_me.bin.meta
>> CMD uudecode -p  > ARUBA_me.bin
>> CWD 
>> /usr/obj/clang/amd64.amd64/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_me
>> TARGET ARUBA_me.bin
>> -- command output --
>> uudecode: stdin: missing or bad "begin" line
>> *** Error code 1
>>
>> -- filemon acquired metadata --
>> # filemon version 5
>> # Target pid 7146
>> # Start 1465867565.855820
>> V 5
>> E 7163 /bin/sh
>> R 7163 /etc/libmap.conf
>> R 7163 /var/run/ld-elf.so.hints
>> R 7163 /lib/libedit.so.7
>> R 7163 /lib/libc.so.7
>> R 7163 /lib/libncursesw.so.8
>> F 7163 7164
>> W 7164 ARUBA_me.bin
>> E 7164 /usr/bin/uudecode
>> R 7164 /etc/libmap.conf
>> R 7164 /var/run/ld-elf.so.hints
>> R 7164 /lib/libc.so.7
>> X 7164 1 0
>> X 7163 1 0
>> # Stop 1465867565.868045
>> # Bye bye
> 
> 

I don't know what's going on here at first glance but it doesn't look
related to META_MODE.  I'm not too familiar with $?.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: 11.0 -r301815 to -r310873 using WITH_META_MODE=yes : an empty filename failure

[Bryan Drewery]

On 6/13/16 7:56 PM, Bryan Drewery wrote:
> On 6/13/2016 7:26 PM, Mark Millard wrote:
>> [The following is after the svnltie update -r301873 /usr/src .]
>>
>> For the following in a amd64 rebuild on amd64 (a WITH_META_MODE=yes 
>> buidlworld buidlkernel just after a without meta mode buildworld buildkernel 
>> [no install]). . .
>>
>>> # more sys/modules/drm2/radeonkmsfw/Makefile.inc 
>>> # $FreeBSD: head/sys/modules/drm2/radeonkmsfw/Makefile.inc 254885 
>>> 2013-08-25 19:37:15Z dumbbell $
>>> #
>>> # Common rules for building firmware.  Note this gets auto-included
>>> # by the subdir Makefile's as a consequence of included bsd.kmod.mk.
>>>
>>> _FIRM=  ${IMG}.bin
>>>
>>> CLEANFILES+=${_FIRM}
>>>
>>> FIRMWS= ${_FIRM}:${KMOD}
>>>
>>> #
>>> # Note that a license ack is not needed for iwn.
>>> #
>>> #FIRMWARE_LICENSE=
>>>
>>> ${_FIRM}: ${.CURDIR}/../../../../contrib/dev/drm2/radeonkmsfw/${_FIRM}.uu
>>> uudecode -p $? > ${.TARGET}
>>
>>
>> I just had . . .
>> (Note the uudecode line in the .meta file, the reference to stdin, and the 
>> resultant "begin" line error.)
>>
>>> # more 
>>> /usr/obj/clang/amd64.amd64/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_me/ARUBA_me.bin.meta
>>>  
>>> # Meta data file 
>>> /usr/obj/clang/amd64.amd64/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_me/ARUBA_me.bin.meta
>>> CMD uudecode -p  > ARUBA_me.bin
>>> CWD 
>>> /usr/obj/clang/amd64.amd64/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_me
>>> TARGET ARUBA_me.bin
>>> -- command output --
>>> uudecode: stdin: missing or bad "begin" line
>>> *** Error code 1
>>>
>>> -- filemon acquired metadata --
>>> # filemon version 5
>>> # Target pid 7146
>>> # Start 1465867565.855820
>>> V 5
>>> E 7163 /bin/sh
>>> R 7163 /etc/libmap.conf
>>> R 7163 /var/run/ld-elf.so.hints
>>> R 7163 /lib/libedit.so.7
>>> R 7163 /lib/libc.so.7
>>> R 7163 /lib/libncursesw.so.8
>>> F 7163 7164
>>> W 7164 ARUBA_me.bin
>>> E 7164 /usr/bin/uudecode
>>> R 7164 /etc/libmap.conf
>>> R 7164 /var/run/ld-elf.so.hints
>>> R 7164 /lib/libc.so.7
>>> X 7164 1 0
>>> X 7163 1 0
>>> # Stop 1465867565.868045
>>> # Bye bye
>>
>>
> 
> I don't know what's going on here at first glance but it doesn't look
> related to META_MODE.  I'm not too familiar with $?.
> 

Actually it does seem to be meta-missing bug since $? (.OODATE) is empty
and yet it is requiring a .meta file.

Easy way to recreate it:

cd sys/modules/drm2/radeonkmsfw/ARUBA_me
make cleandir
make obj
make
make -dM # it notes that ARUBA_me.bin cannot be compared due to .OODATE
rm $(make whereobj)/ARUBA_me.bin.meta
make -dM

> /usr/obj/root/git/freebsd/sys/modules/drm2/radeonkmsfw/ARUBA_me/ARUBA_me.bin.meta:
>  required but missing
> Building 
> /usr/obj/root/git/freebsd/sys/modules/drm2/radeonkmsfw/ARUBA_me/ARUBA_me.bin
> 
> load: 17.72  cmd: uudecode 86777 [ttyin] 9.98r 0.00u 0.00s 0% 2052k




-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: 11.0 -r301815 to -r310873 using WITH_META_MODE=yes : an empty filename failure

[Simon J. Gerraty]

Bryan Drewery  wrote:
> >> ${_FIRM}: ${.CURDIR}/../../../../contrib/dev/drm2/radeonkmsfw/${_FIRM}.uu
> >> uudecode -p $? > ${.TARGET}

Targets like this that use $? or ${.OODATE} are a bad fit with META mode.

If the normal make rules think the target is up to date, .OODATE will be
empty, thus if meta_oodate says the target is out-of-date, the script
will run with no args - because $? expands to nothing.

So either the use of $? should be replaced with ${.ALLSRC} or something
else that will be consistent, or the target should be marked .NOMETA

FYI we can [ab]use ${.OODATE} as a token to prevent a line of a script
from being compared - meta mode knows that the value of .OODATE is
inconsistent so should not be compared... thus putting
${.OODATE:MNO_META_CMP} on a line expands to nothing - no impact on the
command but still tells meta_oodate to ignore that line for comparison
purposes. 
___
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 to -r310873 using WITH_META_MODE=yes : an empty filename failure

[Bryan Drewery]

On 6/13/16 8:18 PM, Simon J. Gerraty wrote:
> Bryan Drewery  wrote:
 ${_FIRM}: ${.CURDIR}/../../../../contrib/dev/drm2/radeonkmsfw/${_FIRM}.uu
 uudecode -p $? > ${.TARGET}
> 
> Targets like this that use $? or ${.OODATE} are a bad fit with META mode.
> 
> If the normal make rules think the target is up to date, .OODATE will be
> empty, thus if meta_oodate says the target is out-of-date, the script
> will run with no args - because $? expands to nothing.
> 
> So either the use of $? should be replaced with ${.ALLSRC} or something
> else that will be consistent, or the target should be marked .NOMETA
> 
> FYI we can [ab]use ${.OODATE} as a token to prevent a line of a script
> from being compared - meta mode knows that the value of .OODATE is
> inconsistent so should not be compared... thus putting
> ${.OODATE:MNO_META_CMP} on a line expands to nothing - no impact on the
> command but still tells meta_oodate to ignore that line for comparison
> purposes. 
> 

The problem is missing-meta requiring a .meta file here.  The $?/.OODATE
comparison exception is only used meta_oodate() if there is already a
.meta file, not for the new missing .meta logic.

-- 
Regards,
Bryan Drewery
___
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: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode

[Joel Dahl]

On Mon, Jun 13, 2016 at 07:00:46AM -0400, Ngie Cooper (yaneurabeya) wrote:
> 
> > 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.

Hi,

This is with r301857. Forgot to mention that in my previous mail. Sorry.

-- 
Joel
___
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: _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: GPIO driver for Intel Atom SoC

[Imre Vadasz]

Hi,

Microsoft has some documentation on GPIO handling with SD card controllers,
which should apply to most Cherryview devices:

https://msdn.microsoft.com/windows/hardware/drivers/bringup/other-acpi-namespace-objects#sd

I did some work on Cherryview SoC support in DragonFlyBSD.
In DragonFly master, there is a simple GPIO driver for cherryview in
/sys/bus/gpio/gpio_intel. In master, it's currently only used for
handling the ACPI GeneralPurposeIo operation regions, and
Acpi-Event-Interrupts (which replace GPE interrupts on reduced-hardware
platforms).

I have some further (more prototype level) code which also contains some
code for Intel sdhci controller integration:

https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/shortlog/refs/heads/cherryview

With this branch everything sdcard/eMMC related works quite nicely, e.g.
it properly handles plugging in/out the sd-card on my HP X2 210 detachable
on DragonFlyBSD.

To handle everything properly this contains a bit of work on mostly ACPI
related stuff:

ACPI device initialization order needs to be according to the ACPI _DEP methods:

https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/commitdiff/25dec08cafa3ce9089eb5b216700f4e678b3356d

We need to map ACPI nodes to the device objects (and at least track a
reference count for debugging):

https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/commitdiff/23135590ffb33b40f170c786ea95fc133358ebdb

Then some kind of API is needed for handling the GeneralPurposeIo resources
declared for the device in the ACPI tables (e.g. the sdhci controller).
(i.e. some way of attempting to "map" the resource from the device driver):

https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/commitdiff/d5b3d3447bbdd42a68359aebd61f271bfa830951

And I have a prototype of adapting the sdhci driver to handle the GPIO
ACPI resources, as described in 
"https://msdn.microsoft.com/windows/hardware/drivers/bringup/other-acpi-namespace-objects#sd":

https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/commitdiff/5d2844c280211cbb256a5ecc3ea27f952149e452

Regards,
Imre Vadász
___
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"

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

[Joel Dahl]

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.

-- 
Joel
___
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: GPIO driver for Intel Atom SoC

[Lundberg, Johannes]

Hi Imre

I got the device in /dev/mmcsd0. I think the reason was that mmcsd wasn't
loaded (need to load manually it seems..)

Do you think your patch in mmc is something that should be pushed upstream
in FreeBSD or is it more of a hack?
I am talking about
https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/commitdiff/444adb3eab64539da816dc292a2ad058918c


On Mon, Jun 13, 2016 at 2:56 PM, Imre Vadasz  wrote:

> Hi,
>
> Having the SDHCI controller in ACPI space won't help, because FreeBSD
> doesn't have the code for attaching sdhci(4) via acpi yet.
>
> You should try setting the hw.mmc.debug tunable in the bootloader.
> You should probably try booting with hw.mmc.debug=3 to get as much
> debugging output as possible from mmc(4). It should at least tell you
> if/how it recognizes the eMMC disk, and maybe something helpful for
> further debugging.
>
> Imre
>
> On 13:44 Mon 13 Jun , Lundberg, Johannes wrote:
> > Hi Imre
> >
> >
> > I have attached the logs.
> > The board is this: http://www.up-board.org/
> >
> > Since we don't have sdhci_acpi.c (yet) I select the SDHCI controller to
> be
> > on PCI in BIOS.
> > Would it be better to have it in ACPI space because of the MMC/GPIO
> stuff?
> >
> >
> > I tried your patch and amazingly identification of the mmc card now
> works!!
> > I can't believe it was that simple...
> > However, I do not get any /dev/mmc* devices.
> >
> > sdhci_pci0:  mem
> > 0x91927000-0x91927fff at device 16.0 on pci0
> > sdhci_pci0: 1 slot(s) allocated
> > mmc0:  on sdhci_pci0
> >
> > Thanks!
> >
> >
> >
> > --
> > Name: Johannes Lundberg
> > Position: Mirama project leader
> > Phone:+1-408-636-2161
> > Skype:brilliantjohannes
> > Online:   LinkedIn  Facebook
> >  Reddit
> >  Twitter
> >  GitHub <
> https://github.com/yohanesu75>
> > GitLab 
> > Company:  Mirama  Brilliantservice US
> >  Brilliantservice JP
> > 
> >
> > On Mon, Jun 13, 2016 at 12:36 PM, Imre Vadasz  wrote:
> >
> > > Hi,
> > >
> > > If possible, it would be quite interesting and helpful if you could
> post
> > > the ACPI tables of your device (i.e. by running "acpidump -b" and
> uploading
> > > the output files), as well as the list of pci devices from "pciconf
> -lcvb".
> > >
> > > The HP X2 210 detachable I'm running DragonFly on, has an internal eMMC
> > > on its pcb, as well as an external micro-sdcard slot, and both work
> for me.
> > > I forgot to mention that I need a small workaround to make the eMMC
> work,
> > > which you could try out:
> > >
> > >
> https://gitweb.dragonflybsd.org/~ivadasz/dragonfly.git/commitdiff/444adb3eab64539da816dc292a2ad058918c
> > >
> > > It seems quite unlikely that the mmc would need activating through a
> gpio,
> > > assuming your device can boot from that internal mmc.
> > >
> > > My HP detachable can boot from the internal eMMC, but not from the
> external
> > > micro-sd slot. The micro-sd slot is powered on by the _PS0 ACPI method
> of
> > > the corresponding ACPI device, and that _PS0 method does some I2C
> > > transactions through an I2cSerialBus ACPI operation-region Field. For
> that
> > > part I added a helper driver which installs the necessary handler
> function
> > > in the ACPICA framework:
> > >
> > >
> https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/98eefd6fca52090fe45779e35c41f4b15942517f
> > >
> > > Imre
> > >
> > > On 11:24 Mon 13 Jun , Lundberg, Johannes wrote:
> > > > Hi Imre
> > > >
> > > > This is great information. Thank you!
> > > >
> > > > My device have an emmc chip on the pcb (non-removable).
> > > > Have you tested you code on that kind of system?
> > > >
> > > > Current unmodified FreeBSD can detect the sdhci_pci controller and a
> mmc
> > > > card on slot0 but timeouts when trying to init the mmc. Not sure why
> it
> > > is
> > > > failing. I assumed it needed activating through some gpios but maybe
> it's
> > > > not that easy..
> > > >
> > > >
> > > > On Mon, Jun 13, 2016 at 2:38 AM, Imre Vadasz  wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Microsoft has some documentation on GPIO handling with SD card
> > > controllers,
> > > > > which should apply to most Cherryview devices:
> > > > >
> > > > >
> > >
> https://msdn.microsoft.com/windows/hardware/drivers/bringup/other-acpi-namespace-objects#sd
> > > > >
> > > > > I did some work on Cherryview SoC support in DragonFlyBSD.
> > > > > In DragonFly master, there is a simple GPIO driver for cherryview
> in
> > > > > /sys/bus/gpio/gpio_intel. In master, it's currently only used for
> > > > > handling the ACPI GeneralPurposeIo operation regions, and
> > > > > Acpi-Event-Interrupts (which replace GPE interrupts on
> reduced-hardware
> > > > > platforms).
> 

11.0 -r301815 to -r310873 using WITH_META_MODE=yes : an empty filename failure

[Mark Millard]

[The following is after the svnltie update -r301873 /usr/src .]

For the following in a amd64 rebuild on amd64 (a WITH_META_MODE=yes buidlworld 
buidlkernel just after a without meta mode buildworld buildkernel [no 
install]). . .

> # more sys/modules/drm2/radeonkmsfw/Makefile.inc 
> # $FreeBSD: head/sys/modules/drm2/radeonkmsfw/Makefile.inc 254885 2013-08-25 
> 19:37:15Z dumbbell $
> #
> # Common rules for building firmware.  Note this gets auto-included
> # by the subdir Makefile's as a consequence of included bsd.kmod.mk.
> 
> _FIRM=  ${IMG}.bin
> 
> CLEANFILES+=${_FIRM}
> 
> FIRMWS= ${_FIRM}:${KMOD}
> 
> #
> # Note that a license ack is not needed for iwn.
> #
> #FIRMWARE_LICENSE=
> 
> ${_FIRM}: ${.CURDIR}/../../../../contrib/dev/drm2/radeonkmsfw/${_FIRM}.uu
> uudecode -p $? > ${.TARGET}


I just had . . .
(Note the uudecode line in the .meta file, the reference to stdin, and the 
resultant "begin" line error.)

> # more 
> /usr/obj/clang/amd64.amd64/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_me/ARUBA_me.bin.meta
>  
> # Meta data file 
> /usr/obj/clang/amd64.amd64/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_me/ARUBA_me.bin.meta
> CMD uudecode -p  > ARUBA_me.bin
> CWD 
> /usr/obj/clang/amd64.amd64/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_me
> TARGET ARUBA_me.bin
> -- command output --
> uudecode: stdin: missing or bad "begin" line
> *** Error code 1
> 
> -- filemon acquired metadata --
> # filemon version 5
> # Target pid 7146
> # Start 1465867565.855820
> V 5
> E 7163 /bin/sh
> R 7163 /etc/libmap.conf
> R 7163 /var/run/ld-elf.so.hints
> R 7163 /lib/libedit.so.7
> R 7163 /lib/libc.so.7
> R 7163 /lib/libncursesw.so.8
> F 7163 7164
> W 7164 ARUBA_me.bin
> E 7164 /usr/bin/uudecode
> R 7164 /etc/libmap.conf
> R 7164 /var/run/ld-elf.so.hints
> R 7164 /lib/libc.so.7
> X 7164 1 0
> X 7163 1 0
> # Stop 1465867565.868045
> # Bye bye


===
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: 11.0 -r301815 "kyua test -k /usr/tests/Kyuafile" on rpi2 [armv7-a/cortex-a7]: broken (24) and failing (59) lists

[Ian Lepore]

On Mon, 2016-06-13 at 11:04 -0700, Conrad Meyer wrote:
> I expect it's because:
> 
> 1. bitstr_size() is just bytes (doesn't round up to sizeof(bitstr_t ==
> unsigned long))

This might result in allocating too-few bytes, but that's something
you'd only notice if you have something like valgrind watching out for
accesses beyond the allocated size.

> 2. The userspace version of bit_alloc() uses calloc(bitstr_size(), 1)
> (an array of nmemb=bitstr_size() size=bytes, doesn't have to be
> 'unsigned long' sized or aligned).
> 3. Various bit_* functions access the result as if it's an array of
> 'unsigned long', when it was allocated as a single-byte array (no
> ulong alignment or size).

malloc and related functions (including calloc) always return memory
"...suitably aligned for storage of any type of object."  Last time I
checked that basically meant all allocations, even a single byte, are
aligned on a 16-byte boundary on arm.

> 4. ARM isn't as happy about unaligned accesses as x86.
> 

That's mostly not the case anymore.  Using load/store-doubleword or
load/store-multiple instructions requires 4-byte-aligned values (not a
typo: doubleword access requires word alignment).  Everything smaller
than doubleword access in userland these days can be unaligned.  The
optimizer can combine adjacent 32-bit accesses into doubleword
-instruction accesses, leading to alignment faults with unaligned data,
but that shouldn't be the case here because malloc'd memory is aligned.

-- Ian

> I'd make the following change (needs sys/param.h, not compile tested)
> and see if it fixes it:
> 
> --- sys/bitstring.h (revision 301805)
> +++ sys/bitstring.h (working copy)
> @@ -119,7 +119,8 @@
>  static inline bitstr_t *
>  bit_alloc(int _nbits)
>  {
> -   return ((bitstr_t *)calloc(bitstr_size(_nbits), 1));
> +   return (calloc(howmany(bitstr_size(_nbits),
> sizeof(bitstr_t)),
> +   sizeof(bitstr_t)));
>  }
>  #endif
> 
> 
> 
> 
> 
> 
> On Mon, Jun 13, 2016 at 10:49 AM, Alan Somers <asom...@freebsd.org>
> wrote:
> > Please open a bug for the bitstring test failures and assign it to
> > me.
> > Also, since I don't have any arm hardware, please provide
> > instructions
> > on how to run this code in a VM, or where I can get access to the
> > hardware.
> > 
> > -Alan
> > 
> > On Mon, Jun 13, 2016 at 11:29 AM, Mark Millard <mar...@dsl-only.net
> > > wrote:
> > > With the newly less strict alignment requirements "kyua test -k
> > > /usr/tests/Kyuafile" runs to completion, unlike before.
> > > 
> > > > ===> Summary
> > > > Results read from /root/.kyua/store/results.usr_tests.20160613
> > > > -080302-120731.db
> > > > Test cases: 5694 total, 54 skipped, 21 expected failures, 24
> > > > broken, 59 failed
> > > > Total time: 8723.243s
> > > 
> > > 
> > > I only list the one line summaries below. Then I list various
> > > context details.
> > > 
> > > > ===> Broken tests
> > > > lib/msun/cexp_test:main  ->  broken: Received signal 6 
> > > >  [1.054s]
> > > > lib/msun/ctrig_test:main  ->  broken: Received signal 6 
> > > >  [1.074s]
> > > > lib/msun/exponential_test:main  ->  broken: Received signal 6 
> > > >  [1.045s]
> > > > lib/msun/fenv_test:main  ->  broken: Received signal 6 
> > > >  [1.048s]
> > > > lib/msun/fma_test:main  ->  broken: Received signal 6  [1.080s]
> > > > lib/msun/invctrig_test:main  ->  broken: Received signal 6 
> > > >  [1.091s]
> > > > lib/msun/invtrig_test:main  ->  broken: Received signal 6 
> > > >  [1.086s]
> > > > lib/msun/logarithm_test:main  ->  broken: Received signal 6 
> > > >  [1.054s]
> > > > lib/msun/lrint_test:main  ->  broken: Received signal 6 
> > > >  [1.069s]
> > > > lib/msun/nearbyint_test:main  ->  broken: Received signal 6 
> > > >  [1.066s]
> > > > lib/msun/rem_test:main  ->  broken: Received signal 6  [1.069s]
> > > > lib/msun/trig_test:main  ->  broken: Received signal 6 
> > > >  [1.070s]
> > > > sbin/growfs/legacy_test:main  ->  broken: Reported plan differs
> > > > from actual executed tests  [0.459s]
> > > > sys/geom/class/eli/integrity_copy_test:main  ->  broken: Test
> > > > case timed out  [1200.082s]
> > > > sys/geom/class/eli/integrity_hmac_test:main  ->  broken: Test
> > > > case timed out  [600.138s]
> > >