Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

[Rainer Hurling]

Am 09.04.24 um 09:20 schrieb Baptiste Daroussin:

On Sat 06 Apr 09:23, Rainer Hurling wrote:

Am 06.04.24 um 09:05 schrieb FreeBSD User:

Hello,

after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 
on CURRENT and
14-STABLE, I can't update several ports:

www/apache24
databases/redis

pkg core dumps while performing installation. apache24 and redis are ports I 
realized this
misbehaviour on ALL 14-STABLE and CURRENT boxes (both OS variants latest 
builds, i.e. FreeBSD
15.0-CURRENT #32 main-n269135-da2b732288c7: Fri Apr  5 20:30:39 CEST 2024 
amd64).

After some updates on a poudriere builder (CURRENT base host, 14.0-RELENG jail 
with poudriere)
building packages for 14.0-RELENG, I observed the same behaviour when updating 
packages on
target hosts where pkg is first updated, on those hosts, nextcloud-server and 
icinga2 host
utilizing also databases/redis and www/apache24, pkg fails the same way.

I do not dare to update our poudriere hosts since the problem seems to pop up 
when pkg 1.21.0
is installed, no matter whether I use poudriere built ports (from our own 
builder hosts) or
recent source tree with portmaster/make build process.

Looks like a serious bug to me and not a site/user specific problem. Hopefully 
others do
realize the same ...

Thanks in advance,

oh



Hmm, I just tried to reproduce that. Both ports mentioned, databases/redis
and www/apache24, can be built and installed with Portmaster. The box is a
15.0-CURRENT with pkg-1.21.0.

Maybe 'pkg check -Bn' or 'portmaster --check-depends --check-port-dbdir'
show some inconsistencies?

Best wishes,
Rainer



using portmaster or not are strictly unlikely to be helpful here.

The right way to test if to report running with pkg - and also to recommand
testing with default options in pkg.conf.

Best regards,
Bapt


This is correct and certainly better. I was not aware of this.

Fortunately, my less optimal suggestions helped O. Hartmann in this case 
to find the missing and outdated dependencies.


In any case, many thanks for this helpfull advice.

Regards,
Rainer

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

[Rainer Hurling]

Am 06.04.24 um 09:56 schrieb FreeBSD User:

Am Sat, 6 Apr 2024 09:23:30 +0200
Rainer Hurling  schrieb:


Am 06.04.24 um 09:05 schrieb FreeBSD User:

Hello,

after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 
on CURRENT
and 14-STABLE, I can't update several ports:

www/apache24
databases/redis

pkg core dumps while performing installation. apache24 and redis are ports I 
realized this
misbehaviour on ALL 14-STABLE and CURRENT boxes (both OS variants latest 
builds, i.e.
FreeBSD 15.0-CURRENT #32 main-n269135-da2b732288c7: Fri Apr  5 20:30:39 CEST 
2024 amd64).

After some updates on a poudriere builder (CURRENT base host, 14.0-RELENG jail 
with
poudriere) building packages for 14.0-RELENG, I observed the same behaviour 
when updating
packages on target hosts where pkg is first updated, on those hosts, 
nextcloud-server and
icinga2 host utilizing also databases/redis and www/apache24, pkg fails the 
same way.

I do not dare to update our poudriere hosts since the problem seems to pop up 
when pkg
1.21.0 is installed, no matter whether I use poudriere built ports (from our 
own builder
hosts) or recent source tree with portmaster/make build process.

Looks like a serious bug to me and not a site/user specific problem. Hopefully 
others do
realize the same ...

Thanks in advance,

oh



Hmm, I just tried to reproduce that. Both ports mentioned,
databases/redis and www/apache24, can be built and installed with
Portmaster. The box is a 15.0-CURRENT with pkg-1.21.0.

Maybe 'pkg check -Bn' or 'portmaster --check-depends --check-port-dbdir'
show some inconsistencies?

Best wishes,
Rainer



Hello,

thanks for the quick response.

I checked on the CURRENT systems here at hand and must confess - it is a mess! 
pkg check -Bn
dropped a lot of missing shared objects missing from autotools and missing 
guile2 :-(

Thank you very much,
oh



You're really welcome. I myself have failed several times precisely 
because some dependencies were not in order. And that's not always 
obvious :)


Best wishes,
Rainer

Re: pkg-1.21.0: after upgrade 1.20.9_1 -> 1.21.0: pkg core dumps on specific ports

[Rainer Hurling]

Am 06.04.24 um 09:05 schrieb FreeBSD User:

Hello,

after updating (portmaster and make) ports-mgmt/ports from 1.20.9_1 -> 1.21.0 
on CURRENT and
14-STABLE, I can't update several ports:

www/apache24
databases/redis

pkg core dumps while performing installation. apache24 and redis are ports I 
realized this
misbehaviour on ALL 14-STABLE and CURRENT boxes (both OS variants latest 
builds, i.e. FreeBSD
15.0-CURRENT #32 main-n269135-da2b732288c7: Fri Apr  5 20:30:39 CEST 2024 
amd64).

After some updates on a poudriere builder (CURRENT base host, 14.0-RELENG jail 
with poudriere)
building packages for 14.0-RELENG, I observed the same behaviour when updating 
packages on
target hosts where pkg is first updated, on those hosts, nextcloud-server and 
icinga2 host
utilizing also databases/redis and www/apache24, pkg fails the same way.

I do not dare to update our poudriere hosts since the problem seems to pop up 
when pkg 1.21.0
is installed, no matter whether I use poudriere built ports (from our own 
builder hosts) or
recent source tree with portmaster/make build process.

Looks like a serious bug to me and not a site/user specific problem. Hopefully 
others do
realize the same ...

Thanks in advance,

oh



Hmm, I just tried to reproduce that. Both ports mentioned, 
databases/redis and www/apache24, can be built and installed with 
Portmaster. The box is a 15.0-CURRENT with pkg-1.21.0.


Maybe 'pkg check -Bn' or 'portmaster --check-depends --check-port-dbdir' 
show some inconsistencies?


Best wishes,
Rainer

Re: kernel: fatal trap 12 on CURRENT, when using WireGuard

[Rainer Hurling]

Am 09.01.24 um 21:40 schrieb Gleb Smirnoff:

   Rainer,

On Tue, Jan 09, 2024 at 09:23:54PM +0100, Rainer Hurling wrote:
R> I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a very
R> recent commit. The build and install went fine. After booting with new
R> base, I got a page fault with the following error:

Sorry for that, my fault. Can you please test this patch?



Hi Gleb,

Thanks for the very fast response.

I tried your patch and it seems to work as expected. I have a running 
system, with WireGuard on, at commit main-n267469-0013741108bc-dirty.


Many thanks again and best wishes,
Rainer

kernel: fatal trap 12 on CURRENT, when using WireGuard

[Rainer Hurling]

I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a 
very recent commit. The build and install went fine. After booting with 
new base, I got a page fault with the following error:



Kernel page fault with the following non-sleepable locks held:
shared rm netlink lock (netlink lock) r = 0 (0xf8005fc8ca20) locked 
@ /usr/src/sys/netlink/netlink_domain.c:241
exclusive rw lle (lle) r = 0 (0xf801951dce90) locked @ 
/usr/src/sys/netinet/in.c:1716

stack backtrace:
#0 0x80bc6c45 at witness_debugger+0x65
#1 0x80bc7d89 at witness_warn+0x3e9
#2 0x81056b18 at trap_pfault+0x88
#3 0x81028708 at calltrap+0x8
#4 0x80dbd6a2 at nl_send_group+0x1d2
#5 0x80dc0e27 at _nlmsg_flush+0x37
#6 0x80dc4fdc at rtnl_lle_event+0x10c
#7 0x80d15e32 at arp_mark_lle_reachable+0xd2
#8 0x80d15b43 at arp_check_update_lle+0x293
#9 0x80d151c5 at arpintr+0xa65
#10 0x80caaaed at netisr_dispatch_src+0xad
#11 0x80c8d57a at ether_demux+0x0x17a
#12 0x80c8ec53 at ether_nh_input+0x403
#13 0x80caaaed at netisr_dispatch_src+0xad
#14 0x80c8d9c9 at ether_input+0xd9
#15 0x80ca66ac at iflib_rxeof+0xe4c
#16 0x80ca0b5a at _task_fn_rx+0x7a
#17 0x80ba0118 at gtaskqueue_run_locked+0xa8

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x3
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80dc0a10
stack pointer   = 0x28:0xfe006a3a8760
frame pointer   = 0x28:0xfe006a3a8790
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1. def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (if_io_tqg_0)
rdi: fe006a3a8850 rsi: fe006a3a86f0 rdx: fe006a3a87b0
rcx: f80001f88740  r8: 83210090  r9: 
rax:  rbx: 0003 rbp: fe006a3a8790
r10: 0001 r11:  r12: f8005fc8ca00
r13: f8005fc8ca20 r14: fe006a3a8850 r15: 
trap number = 12
panic: page fault
cpuid = 0
time = 1704824328
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe006a3a8430

vpanic() at vpanic+0x131/frame 0xfe006a3a8560
panic() at panic+0x43/frame 0xfe006a3a85c0
trap_fatal() at trap_fatal+0x40f/frame 0xfe006a3a8620
trap_pfault() at trap_pfault+0xae/frame 0xfe006a3a8690
calltrap() at calltrap+0x8/frame 0xfe006a3a8690
--- trap 0xc, rip = 0x80dc0a10, rsp = 0xfe006a3a8760, rbp = 
0xfe006a3a8790 ---

nl_send_one() at nl_send_one+0x20/frame 0xfe006a3a8790
nl_send_group() at nl_send_group+0x1d2/frame 0xfe006a3a8820
_nlmsg-flush() at _nlmsg_flush+0x37/frame 0xfe006a3a8840
rtnl_lle_event() at rtnl_lle_event+0x10c/frame 0xfe006a3a88e0
arp_mark_lle_reachable() at arp_mark_lle_reachable+0xd2/frame 
0xfe006a3a8930
arp_check_update_lle() at arp_check_update_lle+0x293/frame 
0xfe006a3a8a00

arpintr() at arpintr+0xa65/frame 0xfe006a3a8b60
netisr_dispatch_src() at netisr_dispatch_src+0xad/frame 0xfe006a3a8bc8
ether_demux() at ether_demux+0x17a/frame 0xfe006a4a8bf0
ether_nh_input() at ether_nh_input+0x403/frame 0xfe006a3a8c40
netisr_dispatch_src() at netisr_dispatch_src+0xad/frame 0xfe006a3a8ca0
ether_input() at ehter_input+0xd9/frame 0xfe006a3a8d00
iflib_rxeof() at iflib_rxeof+0xe4c/frame 0xfe006a3a8e00
_task_fn_rx() at _task_fn_rx+0x7a/frame 0xfe006a3a8e40
gtaskqueue_run_locked() at gtaskqueue_run_locked+0xa8/frame 
0xfe006a3a8ec0
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xd3/frame 
0xfe006a3a8ef0

fork_exit() at fork_exit+0x82/frame 0xfe006a3a8f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfe006a3a8f30
--- trap 0xf2b9f109, rip = 0x7afef8a176bef8a5, rsp = 0xddc963edd18963e9, 
rbp = 0x61f64fc36db64fc7

KDB: enter: panic
[ thread pid 0 tid 100067 ]
Stopped at  kdb_enter+0x33: movq$0,0xe3a582(%rip)
db>


Since the current process 'if_io_tqg_0' and problems with netlink are 
mentioned, I searched in the area of my network connections. I 
discovered that this page fault only occurs when a connection is 
established with WireGuard (wg-quick up wg0). Without using WireGuard, 
this error does not occur.


I was able to find out at which commit this behavior occurs with my box:
- Up to commit main-n267347-660bd40a598a everything is fine.
- The two following commits n267348-67d9023f07a4 and 
n267349-0ad011ececb9 do not build on my box (module/netlink broken ...).
- From commit n267349-0ad011ececb9 (netlink) onwards this page fault 
occurs when WireGuard is started.


Any help is greatly appreciated.
CC'ed Gleb Smirnoff due to the affected commits.

Regards,
Rainer Hurling

[Bug 267671] Unnecessary printf to stderr in stdlib/cxa_thread_atexit_impl.c

[Rainer Hurling]

Could someone please take a look at bug 267671 [1]?

Numerous 'printf to stderr' make it difficult to read terminal output 
important for ports like graphics/qgis ...


Thanks for an assessment!

Regards,
Rainer Hurling


[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267671

Re: 15.0-CURRENT build broken in lib/libmagic

[Rainer Hurling]

Am 10.09.23 um 05:18 schrieb Dag-Erling Smørgrav:

Rainer Hurling  writes:

Unfortunately, here it breaks with:
[...]
/usr/src/lib/libc/gdtoa/machdep_ldisx.c:40:10: fatal error: 'sys/cdefs.h' file 
not found


That's because you wiped /usr/obj before starting.  Try running 'make
buildincludes' inside the buildenv before building libc.  If that still
fails, just run buildworld; it will fail in libmagic as before but it
will have built libc before failing, and you can install libc and
restart the build.

DES


Yes, that works! Now I have a working, most recent 15.0-CURRENT again :D

I think now I understand how to use the buildenv to build individual 
parts. Many thanks for that and for your help and patience.


Regards,
Rainer

Re: 15.0-CURRENT build broken in lib/libmagic

[Rainer Hurling]

Am 09.09.23 um 20:28 schrieb Dag-Erling Smørgrav:

Rainer Hurling  writes:

After removing /usr/obj and 'make cleanworld',


That was unnecessary.


I tried to build libc like the following, but it fails:
[...]


$ cd /usr/src
$ make buildenv


done


inside the buildenv, run:

$ make -C lib/libc -j$(nproc)


Unfortunately, here it breaks with:

make -C lib/libc
cc -target x86_64-unknown-freebsd15.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common 
-DNO__SCCSID -DNO__RCSID -I/usr/src/lib/libc/include -I/usr/src/include 
-I/usr/src/lib/libc/amd64 -DNLS  -ftls-model=initial-exec 
-DCRT_IRELOC_RELA  -DINIT_IRELOCS="init_cpu_features()" 
-I/usr/src/lib/libc/csu/amd64 -D__DBINTERFACE_PRIVATE 
-I/usr/src/contrib/gdtoa -I/usr/src/contrib/libc-vis -DINET6 
-I/usr/obj/usr/src/amd64.amd64/lib/libc -I/usr/src/lib/libc/resolv 
-D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libmd 
-I/usr/src/contrib/jemalloc/include -I/usr/src/lib/libc/locale 
-DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc 
-DWANT_HYPERV -DYP -DNS_CACHING -DSYMBOL_VERSIONING -g -gz=zlib -MD 
-MF.depend.machdep_ldisx.o -MTmachdep_ldisx.o -std=gnu99 
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers 
-Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign 
-Wdate-time -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-error=unused-but-set-parameter 
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter  -Qunused-arguments 
-I/usr/src/lib/libutil -I/usr/src/lib/msun/amd64 -I/usr/src/lib/msun/x86 
-I/usr/src/lib/msun/src -c /usr/src/lib/libc/gdtoa/machdep_ldisx.c -o 
machdep_ldisx.o
/usr/src/lib/libc/gdtoa/machdep_ldisx.c:40:10: fatal error: 
'sys/cdefs.h' file not found

#include 
 ^
1 error generated.
*** Error code 1

Stop.
make[2]: stopped in /usr/src/lib/libc



then exit the buildenv and run

$ sudo make -C lib/libc install

then buildworld as usual.

DES


Thanks for this description. Seems, that something more is odd here?

Re: 15.0-CURRENT build broken in lib/libmagic

[Rainer Hurling]

Am 09.09.23 um 19:04 schrieb Dag-Erling Smørgrav:

Rainer Hurling  writes:

If I try to build world from todays c1b26df2972d with 15.0-CURRENT
(main-n265063-e0752f431b01), it aborts with an error.


Either update your source tree or apply aca3bd160257, then build and
install libc before attempting buildworld.

DES


Hi Dag-Erling,

Many  thanks for your answer and the tip with libc!

Source tree was updated already to c1b26df2972d, so aca3bd160257 is 
already included. I checked for its contents.


After removing /usr/obj and 'make cleanworld', I tried to build libc 
like the following, but it fails:


cd /usr/src/lib/libc
make


[..]
building shared library libc.so.7
cc  -nodefaultlibs -Wl,-zrelro -Wl,--version-script=Version.map 
-Wl,-znoexecstack   -shared -Wl,-x -Wl,--fatal-warnings 
-Wl,--warn-shared-textrel  -o libc.so.7.full -Wl,-soname,libc.so.7 
machdep_ldisx.pico libc_start1.pico bt_close.pico bt_conv.pico 
bt_debug.pico bt_delete.pico bt_get.pico bt_open.pico bt_overflow.pico 
bt_page.pico bt_put.pico bt_search.pico bt_seq.pico bt_split.pico 
bt_utils.pico db.pico hash.pico hash_bigkey.pico hash_buf.pico 
hash_func.pico hash_log2.pico hash_page.pico ndbm.pico mpool.pico 
mpool-compat.pico rec_close.pico rec_delete.pico rec_get.pico 
rec_open.pico rec_put.pico rec_search.pico rec_seq.pico rec_utils.pico 
creat.pico gethostid.pico getwd.pico killpg.pico sethostid.pico 
setpgrp.pico setrgid.pico setruid.pico sigcompat.pico 
__getosreldate.pico __pthread_mutex_init_calloc_cb_stub.pico 
__xuname.pico _once_stub.pico _pthread_stubs.pico _rand48.pico 
_spinlock_stub.pico _thread_init.pico alarm.pico arc4random.pico 
arc4random-compat.pico arc4random_uniform.pico assert.pico auxv.pico 
basename.pico basename_compat.pico cap_sandboxed.pico 
check_utility_compat.pico clock.pico clock_getcpuclockid.pico 
closedir.pico confstr.pico cpuset_alloc.pico cpuset_free.pico crypt.pico 
ctermid.pico daemon.pico devname.pico devname-compat11.pico dirfd.pico 
dirname.pico dirname_compat.pico disklabel.pico dlfcn.pico drand48.pico 
dup3.pico elf_utils.pico erand48.pico err.pico errlst.pico errno.pico 
eventfd.pico exec.pico exect.pico fdevname.pico feature_present.pico 
fmtcheck.pico fmtmsg.pico fnmatch.pico fpclassify.pico frexp.pico 
fstab.pico ftok.pico fts.pico fts-compat.pico fts-compat11.pico ftw.pico 
ftw-compat11.pico getbootfile.pico getbsize.pico getcap.pico getcwd.pico 
getdomainname.pico getentropy.pico getgrent.pico getgrouplist.pico 
gethostname.pico getloadavg.pico getlogin.pico getmntinfo.pico 
getmntinfo-compat11.pico getnetgrent.pico getosreldate.pico 
getpagesize.pico getpagesizes.pico getpeereid.pico getprogname.pico 
getpwent.pico getttyent.pico getusershell.pico getutxent.pico 
getvfsbyname.pico glob.pico glob-compat11.pico initgroups.pico 
isatty.pico isinf.pico isnan.pico jrand48.pico kqueue1.pico lcong48.pico 
libc_dlopen.pico lockf.pico lrand48.pico memalign.pico mrand48.pico 
nftw.pico nftw-compat11.pico nice.pico nlist.pico nrand48.pico 
opendir.pico pause.pico pmadvise.pico popen.pico posix_spawn.pico 
psignal.pico pututxline.pico pw_scan.pico raise.pico readdir.pico 
readdir-compat11.pico readpassphrase.pico recvmmsg.pico rewinddir.pico 
scandir.pico scandir_b.pico scandir-compat11.pico sched_getaffinity.pico 
sched_setaffinity.pico seed48.pico seekdir.pico semctl.pico 
sendmmsg.pico setdomainname.pico sethostname.pico setjmperr.pico 
setmode.pico setproctitle.pico setprogname.pico siginterrupt.pico 
siglist.pico signal.pico sigsetops.pico sleep.pico srand48.pico 
statvfs.pico stringlist.pico strtofflags.pico sysconf.pico sysctl.pico 
sysctlbyname.pico sysctlnametomib.pico syslog.pico telldir.pico 
termios.pico time.pico times.pico timespec_get.pico timespec_getres.pico 
timezone.pico tls.pico ttyname.pico ttyslot.pico ualarm.pico ulimit.pico 
uname.pico unvis-compat.pico usleep.pico utime.pico utxdb.pico 
valloc.pico wait.pico wait3.pico waitpid.pico waitid.pico wordexp.pico 
pwcache.pico unvis.pico vis.pico cancelpoints_sem.pico 
cancelpoints_sem_new.pico _setjmp.pico rfork_thread.pico setjmp.pico 
sigsetjmp.pico fabs.pico infinity.pico ldexp.pico makecontext.pico 
signalcontext.pico flt_rounds.pico fpgetmask.pico fpsetmask.pico 
fpgetprec.pico fpsetprec.pico fpgetround.pico fpsetround.pico 
fpgetsticky.pico gmon.pico mcount.pico citrus_bcs.pico 
citrus_bcs_strtol.pico citrus_bcs_strtoul.pico citrus_csmapper.pico 
citrus_db.pico citrus_db_factory.pico citrus_db_hash.pico 
citrus_esdb.pico citrus_hash.pico citrus_iconv.pico citrus_lookup.pico 
citrus_lookup_factory.pico citrus_mapper.pico citrus_memstream.pico 
citrus_mmap.pico citrus_module.pico citrus_none.pico 
citrus_pivot_factory.pico citrus_prop.pico citrus_stdenc.pico 
bsd_iconv.pico iconv_compat.pico inet_addr.pico inet_cidr_ntop.pico 
inet_cidr_pton.pico inet_lnaof.pico inet_makeaddr.pico 
inet_net_ntop.pico inet_net_pton.pico inet_neta.pico inet_netof.pico 
inet_network.pico inet_ntoa.pico inet_ntop.pico inet_pton.pico

Re: 15.0-CURRENT build broken in lib/libmagic

[Rainer Hurling]

Just an update.

This also happens in Poudriere, when I try to update my jails for 13.2, 
14.0 and 15.0-CURRENT.


It seems, that my installed version of 15.0-CURRENT 
(main-n265063-e0752f431b01) is the culprit :(



Am 09.09.23 um 13:52 schrieb Rainer Hurling:
If I try to build world from todays c1b26df2972d with 15.0-CURRENT 
(main-n265063-e0752f431b01), it aborts with an error.


Seems it is not able to handle line 4979 of the magic file (Microsoft 
Advanced Streaming Format ASF):



===> lib/libmagic (all)
echo libmagic.so.4: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libz.a >> 
.depend
cc -target x86_64-unknown-freebsd15.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common 
-DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H 
-I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic 
-I/usr/src/contrib/file/src   -MD  -MF.depend.apprentice.o 
-MTapprentice.o -std=gnu99 -Wno-format-zero-length 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k 
-W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes 
-Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wdate-time 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-parameter -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member  -Qunused-arguments    -c 
/usr/src/contrib/file/src/apprentice.c -o apprentice.o
cc -target x86_64-unknown-freebsd15.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common 
-DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H 
-I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic 
-I/usr/src/contrib/file/src   -MD  -MF.depend.apptype.o -MTapptype.o 
-std=gnu99 -Wno-format-zero-length -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-parameter -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member  -Qunused-arguments    -c 
/usr/src/contrib/file/src/apptype.c -o apptype.o
cc -target x86_64-unknown-freebsd15.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common 
-DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H 
-I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic 
-I/usr/src/contrib/file/src   -MD  -MF.depend.ascmagic.o -MTascmagic.o 
-std=gnu99 -Wno-format-zero-length -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-parameter -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member  -Qunused-arguments    -c 
/usr/src/contrib/file/src/ascmagic.c -o ascmagic.o
cc -target x86_64-unknown-freebsd15.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common 
-DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H 
-I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic 
-I/usr/src/contrib/file/src   -MD  -MF.depend.buffer.o -MTbuffer.o 
-std=gnu99 -Wno-format-zero-length -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-parameter -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member  -Qunused-arguments    -c 
/usr/src/contrib/file/src/buffer.c -o buffer.o
cc -target x86_64-unknown-freebsd15.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common 
-DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H 
-I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic 
-I/usr/src/contrib/file/src   -MD  -MF.depend.cdf.o -MTcdf.o -std=gnu99 
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers 
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body 
-Wno-string-plu

15.0-CURRENT build broken in lib/libmagic

[Rainer Hurling]

If I try to build world from todays c1b26df2972d with 15.0-CURRENT 
(main-n265063-e0752f431b01), it aborts with an error.


Seems it is not able to handle line 4979 of the magic file (Microsoft 
Advanced Streaming Format ASF):



===> lib/libmagic (all)
echo libmagic.so.4: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libz.a >> 
.depend
cc -target x86_64-unknown-freebsd15.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common 
-DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H 
-I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic 
-I/usr/src/contrib/file/src   -MD  -MF.depend.apprentice.o 
-MTapprentice.o -std=gnu99 -Wno-format-zero-length 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k 
-W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes 
-Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wdate-time 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-parameter -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member  -Qunused-arguments-c 
/usr/src/contrib/file/src/apprentice.c -o apprentice.o
cc -target x86_64-unknown-freebsd15.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common 
-DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H 
-I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic 
-I/usr/src/contrib/file/src   -MD  -MF.depend.apptype.o -MTapptype.o 
-std=gnu99 -Wno-format-zero-length -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-parameter -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member  -Qunused-arguments-c 
/usr/src/contrib/file/src/apptype.c -o apptype.o
cc -target x86_64-unknown-freebsd15.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common 
-DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H 
-I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic 
-I/usr/src/contrib/file/src   -MD  -MF.depend.ascmagic.o -MTascmagic.o 
-std=gnu99 -Wno-format-zero-length -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-parameter -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member  -Qunused-arguments-c 
/usr/src/contrib/file/src/ascmagic.c -o ascmagic.o
cc -target x86_64-unknown-freebsd15.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common 
-DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H 
-I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic 
-I/usr/src/contrib/file/src   -MD  -MF.depend.buffer.o -MTbuffer.o 
-std=gnu99 -Wno-format-zero-length -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-parameter -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member  -Qunused-arguments-c 
/usr/src/contrib/file/src/buffer.c -o buffer.o
cc -target x86_64-unknown-freebsd15.0 
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe -fno-common 
-DMAGIC='"/usr/share/misc/magic"' -DHAVE_CONFIG_H 
-I/usr/src/lib/libmagic -I/usr/obj/usr/src/amd64.amd64/lib/libmagic 
-I/usr/src/contrib/file/src   -MD  -MF.depend.cdf.o -MTcdf.o -std=gnu99 
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers 
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -Wdate-time -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-parameter -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef 
-Wno-address-of-packed-member  -Qunused-arguments-c 
/usr/src/contrib/file/src/cdf.c -o cdf.o
cc -target 

Re: OpenSSL 3.0 is in the tree

[Rainer Hurling]

Am 03.07.23 um 16:53 schrieb Guido Falsi:

On 03/07/23 15:27, Rainer Hurling wrote:

Am 29.06.23 um 18:27 schrieb Pierre Pronchery:

 Hi Guido, freebsd-current@,

On 6/29/23 15:14, Guido Falsi wrote:

On 24/06/23 16:22, Ed Maste wrote:

Last night I merged OpenSSL 3.0 to main. This, along with the update
to Clang 16 and other recent changes may result in some challenges
over the next few days or weeks for folks following -CURRENT, such as
ports that need to be updated or unanticipated issues in the base
system.

We need to get this work done so that we can continue moving on with
FreeBSD 14; I apologize for the trouble it might cause in the short
term. Please follow up to report any trouble you encounter.


Not sure where to ask this, following up to this announcement looks 
like a reasonable choice.


After updating head to this version I have had some ports provided 
software fail with messages including: "Unable to load legacy 
provider."


Most of the time I am able to workaround it by forcing newer 
algorithms via some configuration. Some other times I have no direct 
control of what is being asked (like values hardcoded in npm modules)/


This is also happening to me with node, for example, has happened 
with RDP (looks like windows by default prefers RC4 for RDP 
sessions), where I was able to fix it though.


Question is, does FreeBSD provide this legacy provider module? Or is 
it available via ports or some other solution? Or maybe it can be 
provided via a port? Would make the transition much easier!


The legacy provider module is part of OpenSSL 3.0, it should be 
installed in /usr/lib/ossl-modules/legacy.so alongside fips.so as 
part Iddd

of the base system.

It's possible that some programs leveraging capsicum will fail to 
load it, if the initialization of legacy algorithms in OpenSSL is 
performed past entering capabilities mode (since it now requires a 
dlopen() to access the module).


Let me know if you have any additional details regarding issues with 
the module.


HTH,


If this thread is not the appropriate one for my problem, I apologize.

I am the maintainer of the graphics/qgis port. Now that my system 
14.0-CURRENT is updated to clang16 and OpenSSL-3.0, I get the 
following abort message when starting qgis:


#qgis
Failed to load Legacy provider

Apparently there is now also a problem with the legacy provider here. 
As I understand it, QGIS uses the port devel/qca for authorization and 
encryption, so it is also possible that devel/qca is not able to 
provide the legacy provider. Therefore I have taken kde@ into CC.


Please let me know, if you need more information or some testing.


This is being worked on by Pierre.

He pointed me to a patch from him, which I tested successfully:

https://github.com/freebsd/freebsd-src/pull/787

I'm now running head with this patch and the legacy provider works fine.

Hope this helps.



I applied the patch. After rebuilding my system, now the legacy provider 
also works fine for me. graphics/qgis starts again and seems to work as 
expected.


Interestingly, when I start QGIS, I now get the following warnings:

Warning: Incompatible version of OpenSSL (built with OpenSSL 1.x, 
runtime version is >= 3.x)

Warning: QSslSocket: cannot call unresolved function d2i_X509
Warning: QSslSocket::connectToHostEncrypted: TLS initialization failed

These warnings disappeared after rebuilding net/qt5-network and 
net/qt5-networkauth :)


Many thanks for the link with the patch!

Best wishes,
Rainer

Re: OpenSSL 3.0 is in the tree

[Rainer Hurling]

Am 29.06.23 um 18:27 schrieb Pierre Pronchery:

     Hi Guido, freebsd-current@,

On 6/29/23 15:14, Guido Falsi wrote:

On 24/06/23 16:22, Ed Maste wrote:

Last night I merged OpenSSL 3.0 to main. This, along with the update
to Clang 16 and other recent changes may result in some challenges
over the next few days or weeks for folks following -CURRENT, such as
ports that need to be updated or unanticipated issues in the base
system.

We need to get this work done so that we can continue moving on with
FreeBSD 14; I apologize for the trouble it might cause in the short
term. Please follow up to report any trouble you encounter.


Not sure where to ask this, following up to this announcement looks 
like a reasonable choice.


After updating head to this version I have had some ports provided 
software fail with messages including: "Unable to load legacy provider."


Most of the time I am able to workaround it by forcing newer 
algorithms via some configuration. Some other times I have no direct 
control of what is being asked (like values hardcoded in npm modules)/


This is also happening to me with node, for example, has happened with 
RDP (looks like windows by default prefers RC4 for RDP sessions), 
where I was able to fix it though.


Question is, does FreeBSD provide this legacy provider module? Or is 
it available via ports or some other solution? Or maybe it can be 
provided via a port? Would make the transition much easier!


The legacy provider module is part of OpenSSL 3.0, it should be 
installed in /usr/lib/ossl-modules/legacy.so alongside fips.so as part Iddd

of the base system.

It's possible that some programs leveraging capsicum will fail to load 
it, if the initialization of legacy algorithms in OpenSSL is performed 
past entering capabilities mode (since it now requires a dlopen() to 
access the module).


Let me know if you have any additional details regarding issues with the 
module.


HTH,


If this thread is not the appropriate one for my problem, I apologize.

I am the maintainer of the graphics/qgis port. Now that my system 
14.0-CURRENT is updated to clang16 and OpenSSL-3.0, I get the following 
abort message when starting qgis:


#qgis
Failed to load Legacy provider

Apparently there is now also a problem with the legacy provider here. As 
I understand it, QGIS uses the port devel/qca for authorization and 
encryption, so it is also possible that devel/qca is not able to provide 
the legacy provider. Therefore I have taken kde@ into CC.


Please let me know, if you need more information or some testing.

Thanks for your work,
Rainer

Re: dmesg: ACPI Warning: Firmware issue warning spaming

[Rainer Hurling]

Am 14.06.22 um 04:00 schrieb Jung-uk Kim:

On 22. 6. 13., Jung-uk Kim wrote:

On 22. 6. 13., Jung-uk Kim wrote:

On 22. 6. 13., Jung-uk Kim wrote:

On 22. 6. 13., Masachika ISHIZUKA wrote:

What do you think opening a review about this fix/tweak to stop this
spamming that blinds dmesg?


I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg

warnings:

---
ACPI Warning: Firmware issue: Excessive sleep time 
(0x0010

ms >

10 ms) in ACPI Control Method (20220331/exsystem-347)
---
Is there a way to silence it?


   I think this spam message is from linux.
   So, I think we should discuss on linux forum but I don't familier
to linux.


FYI, both FreeBSD and Linux use ACPICA to implement ACPI.

https://acpica.org

This message was added by this commit:

https://github.com/acpica/acpica/commit/2a0d1d475e7ea1c815bee1e0692d81db9a7c909c 



You can file your complaints here if it is really bothering you.

https://github.com/acpica/acpica/issues


BTW, it seems it was discussed on Linux ML.

https://lore.kernel.org/lkml/cajz5v0gwyz_bsonhlgt7l4wpqvxlvyobppte1nx6ponsgn4...@mail.gmail.com/T/#mae6a816bbcebb01dea9e5c19c81e9be872cad521 



I am not sure what happened after that.


I found the author actually filed a pull request to revert the commit.

https://github.com/acpica/acpica/pull/780


FYI, I removed the message.

https://cgit.freebsd.org/src/commit/?id=c7f14adfda21dfacab1895015b4c78bf7c2febb6 


Thank you! This message bothered me a lot on two notebooks, Dell 
Latitude 6520 and Dell Latitude 5521.


Greetings,
Rainer




Jung-uk Kim

Re: Build faulure of editors/libreoffice only on src main (stable/13 is OK)

[Rainer Hurling]

Am 26.02.22 um 14:14 schrieb Tomoaki AOKI:

Thanks.
But unfortunately, as I've described at Comment 21 [2] of Bug 262008,
setting kern.elf64.aslr.enable=0 didn't help.
As I'm building on amd64 and not built for compat32, I've not touched
kern.elf32.aslr.enable.
And as these are regular writable sysctl (and also are tunables, too),
setting these in /boot/loader.conf and reboot before build is not
tested.


I just tried building _after a reboot_ whith kern.elf64.aslr.enable=0 on 
recent CURRENT and it doesn't work for me.


14.0-CURRENT #0 main-n253393-2bfdc1ee9b1 amd64

Best wishes,
Rainer



Should I set more sysctl's? I thought setting above actually disable
all aslr related features (for 64bit), regardless its 1 ro 0.

Error messages (with "MAKE_JOBS_UNSAFE=yes") and backtraces are
described at Comment 20 [3].

[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262008#c21

[3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262008#c20


On Sat, 26 Feb 2022 13:29:26 +0100
Michael Gmelin  wrote:


Maybe it’s related to ASLR? (or is it also enabled in 13/stable?)


On 26. Feb 2022, at 13:05, Tomoaki AOKI  wrote:

〓(Re-sent as not yet delivered in more than 5 hours)

Hi.

I have a build failure of editors/libreoffice on src main, amd64.
As I've reported on Bug 262008 [1], problems on stable/13 is already
fixed, but still fails on main with different faulure mode.

A tool gengal.bin, built within whole libreoffice build, coredumps but
it went OK on stable/13.

Port options are now default on both main and stable/13.

I now come to suspect the differences about toolchains within main and
stable/13, but as editors/libreoffivce is giant and this failure
happenes almost at the end of build, usual bisecting is not realistic.
(Would require tens of weekends, maybe.)

Any thoughts? Or am I missing something to check for?

Regards.


[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262008

--
Tomoaki AOKI

Re: What happen to mailing list archives?

[Rainer Hurling]

Hi Steve,

Am 06.06.21 um 01:13 schrieb Steve Kargl:
> On Sun, Jun 06, 2021 at 01:00:40AM +0200, Michael Gmelin wrote:
>>
>>
>>> On 6. Jun 2021, at 00:53, Steve Kargl  
>>> wrote:
>>>
>>> It seems someone has tried to migrate the mailing list archives
>>> from mailman to some new fangle code.  This has broken the archives
>>> for at least freebsd-numerics@, freebsd-office@, freebsd-net@
>>>
>>> As a comparison, simply go to
>>>
>>> https://lists.freebsd.org/mailman/listinfo
>>>
>>> and follow the links to freebsd-numerics and freebsd-toolchain.
>>>
>>> Can this be fixed?
>>>
>>
>> New archives are here:
>> https://lists.freebsd.org/archives/
>>
> 
> If I go to https://www.freebsd.org/community/mailinglists/
> 
> I see the lines
> 
>   Mailing list archives
> 
>   You can search or browse the mailing list archives at www.FreeBSD.org.
>   It is also possible to browse the mailing lists via the Mailman Web
>   interface.
> 
> Both instances of the word "browse" are hyperlinks.  If I click of the
> second "browse" link, then I end up at
> 
> https://lists.freebsd.org/mailman/listinfo
> 
> which presents a list of archives, you'll see freebsd-numerics
> is a hyperlink (as well as many others).  If I click on freebsd-numerics,
> this takes me to
> 
> https://lists.freebsd.org/subscription/freebsd-numerics
> 
> which displays
> 
>   Subscription for freebsd-numerics
> 
>  Browse the archives: here
>  (and 6 hyperlinks for subscribing and unsubscribing).
> 
> If I click on "here", I get

When I click on "here" I also get a "404 Not Found" at first, but only
for about 5 seconds. This is followed by a redirect to the archive list.
Maybe try it again?

If that doesn't work for you: I have saved some threads with Bruce Evans
locally. I could provide them, hoping that there is something useful?

Regards,
Rainer


> 
> 404 Not Found
> 
> Ergo, the freebsd-numerics archive is unreachable from the "here" link.
> Shouldn't this redirect to the new fangle way?
> 

Re: sys/sys/param.h: 'main' instead of 'Master'?

[Rainer Hurling]

Am 16.04.21 um 18:38 schrieb Kyle Evans:
> n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling  wrote:
>>
>> While viewing sys/sys/param.h I noticed that the comment of the
>> definition of __FreeBSD_version is probably out of date.
>>
>> Since the switch to Git, doesn't it have to be 'main' instead of 'master'?
>>
> 
> This isn't based on a branch name, though I guess if one were going to
> touch it anyways then "Authoritative" would be a better descriptor.

Sounds reasonable. Thanks for the explanation.

> 
>> #cd /usr/src
>> #diff -urN sys/sys/param.h.orig sys/sys/param.h | colordiff
>> --- sys/sys/param.h.orig2021-04-09 12:59:25.363286000 +0200
>> +++ sys/sys/param.h 2021-04-16 18:28:46.621429000 +0200
>> @@ -60,7 +60,7 @@
>>   * in the range 5 to 9.
>>   */
>>  #undef __FreeBSD_version
>> -#define __FreeBSD_version 147  /* Master, propagated to newvers */
>> +#define __FreeBSD_version 147  /* main, propagated to newvers */
>>
>>  /*
>>   * __FreeBSD_kernel__ indicates that this system uses the kernel of
>> FreeBSD,
>>
___
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"

sys/sys/param.h: 'main' instead of 'Master'?

[Rainer Hurling]

While viewing sys/sys/param.h I noticed that the comment of the
definition of __FreeBSD_version is probably out of date.

Since the switch to Git, doesn't it have to be 'main' instead of 'master'?

#cd /usr/src
#diff -urN sys/sys/param.h.orig sys/sys/param.h | colordiff
--- sys/sys/param.h.orig2021-04-09 12:59:25.363286000 +0200
+++ sys/sys/param.h 2021-04-16 18:28:46.621429000 +0200
@@ -60,7 +60,7 @@
  * in the range 5 to 9.
  */
 #undef __FreeBSD_version
-#define __FreeBSD_version 147  /* Master, propagated to newvers */
+#define __FreeBSD_version 147  /* main, propagated to newvers */

 /*
  * __FreeBSD_kernel__ indicates that this system uses the kernel of
FreeBSD,

___
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: Waiting for bufdaemon

[Rainer Hurling]

Am 20.01.21 um 15:36 schrieb Rainer Hurling:
> Am 20.01.21 um 14:52 schrieb Konstantin Belousov:
>> On Wed, Jan 20, 2021 at 02:35:59PM +0100, Rainer Hurling wrote:
>>> Am 20.01.21 um 14:12 schrieb Konstantin Belousov:
>>>> On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote:
>>>>> Am 20.01.21 um 13:34 schrieb Konstantin Belousov:
>>>>>> On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote:
>>>>>>> Am 20.01.21 um 11:18 schrieb Konstantin Belousov:
>>>>>>>> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote:
>>>>>>>>> This patch hides the problem for me. The system seems to work better 
>>>>>>>>> now.
>>>>>>>>>
>>>>>>>>> No waiting on reboot, and the webcam works better.
>>>>>>>> I am curious what do you mean by the above reference to webcam.
>>>>>>>> Can you explain it with more details, even if only the impressions?
>>>>>>>
>>>>>>> I should mention, that beside the already discussed timing problem with
>>>>>>> bufdaemon, I also have problems with several apps:
>>>>>>>
>>>>>>>
>>>>>>> After a high system load, several programs only react very slowly (e.g.
>>>>>>> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do
>>>>>>> not update their windows anymore, they freeze. After some time, Firefox
>>>>>>> updates its screen content only after switching back from another 
>>>>>>> window ...
>>>>>>>
>>>>>>> When such frozen programs are killed and restarted, they run normally
>>>>>>> again for an indefinite time before they freeze again.
>>>>>>>
>>>>>>> These symptoms completely disappeared, after I patched the Ryzen box as
>>>>>>> suggested on 01/17:
>>>>>>
>>>>>> Do you load latest microcode update from devcpu-data?
>>>>>
>>>>> Yes, sysutils/devcpu-data is installed and the following to lines are in
>>>>> /boot/loader.conf
>>>>>
>>>>> cpu_microcode_load="YES"
>>>>> cpu_microcode_name="/boot/firmware/intel-ucode.bin"
>>>>>
>>>>> But isn't this just for Intel (i387 and amd64), not AMD cpus?
>>>> You need microcode_update_enable="YES" in /etc/rc.conf for late microcode
>>>> update.
>>>>
>>>> I think that early boot update should work on AMD, bit for this you need to
>>>> select and put right blob.  It is enough to load late to answer my 
>>>> question.
>>>
>>> Ah, ok. Thanks for clarification. I also put cpu_microcode_load="YES" in
>>> /etc/rc.conf for a late update.
>>>
>>> Should I try again without your patch of sys/x86/tsc.c, whether the
>>> problem still occurs?
> 
> Unfornately, without the patch from 01/17 the problem is _not_ solved.
> 
> Next I will try your patch from today, f lib/libc/x86/sys/__vdso_gettc.c
> an lib/libc/x86/sys/__vdso_gettc.c ...

I can confirm that this patch also works for me on Ryzen 3950X. No more
bufdaemon waitings, no frozen apps, ...

> 
> 
>> Yes.
>>
>>>
>>>
>>> And for the early boot update, how do I know about the right blob?
>> I am not aware of the mechanism.  My best suggestion is that you match
>> the blob against your CPU family/model id manually.
>>
>>>
>>>>
>>>>>
>>>>>> It might be not enough, which means that additionally latest BIOS needs
>>>>>> to be flushed.
>>>>>>
>>>>>
>>>>> I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite"
>>>>> mainboard.

___
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: Waiting for bufdaemon

[Rainer Hurling]

Am 20.01.21 um 15:42 schrieb Mark Johnston:
> On Wed, Jan 20, 2021 at 03:12:27PM +0200, Konstantin Belousov wrote:
>> On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote:
>>> Am 20.01.21 um 13:34 schrieb Konstantin Belousov:
>>>> On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote:
>>>>> Am 20.01.21 um 11:18 schrieb Konstantin Belousov:
>>>>>> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote:
>>>>>>> This patch hides the problem for me. The system seems to work better 
>>>>>>> now.
>>>>>>>
>>>>>>> No waiting on reboot, and the webcam works better.
>>>>>> I am curious what do you mean by the above reference to webcam.
>>>>>> Can you explain it with more details, even if only the impressions?
>>>>>
>>>>> I should mention, that beside the already discussed timing problem with
>>>>> bufdaemon, I also have problems with several apps:
>>>>>
>>>>>
>>>>> After a high system load, several programs only react very slowly (e.g.
>>>>> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do
>>>>> not update their windows anymore, they freeze. After some time, Firefox
>>>>> updates its screen content only after switching back from another window 
>>>>> ...
>>>>>
>>>>> When such frozen programs are killed and restarted, they run normally
>>>>> again for an indefinite time before they freeze again.
>>>>>
>>>>> These symptoms completely disappeared, after I patched the Ryzen box as
>>>>> suggested on 01/17:
>>>>
>>>> Do you load latest microcode update from devcpu-data?
>>>
>>> Yes, sysutils/devcpu-data is installed and the following to lines are in
>>> /boot/loader.conf
>>>
>>> cpu_microcode_load="YES"
>>> cpu_microcode_name="/boot/firmware/intel-ucode.bin"
>>>
>>> But isn't this just for Intel (i387 and amd64), not AMD cpus?
>> You need microcode_update_enable="YES" in /etc/rc.conf for late microcode
>> update.
>>
>> I think that early boot update should work on AMD, bit for this you need to
>> select and put right blob.  It is enough to load late to answer my question.
> 
> The early microcode loader still doesn't support AMD.  I did not do it
> for lack of a test system at the time.
> 

Thanks for the info. So for now, I can remove
microcode_update_enable="YES" in /boot/loader.conf ...

Is there anything, I can test for you (without having skills in the area
;) )?
___
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: Waiting for bufdaemon

[Rainer Hurling]

Am 20.01.21 um 14:52 schrieb Konstantin Belousov:
> On Wed, Jan 20, 2021 at 02:35:59PM +0100, Rainer Hurling wrote:
>> Am 20.01.21 um 14:12 schrieb Konstantin Belousov:
>>> On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote:
>>>> Am 20.01.21 um 13:34 schrieb Konstantin Belousov:
>>>>> On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote:
>>>>>> Am 20.01.21 um 11:18 schrieb Konstantin Belousov:
>>>>>>> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote:
>>>>>>>> This patch hides the problem for me. The system seems to work better 
>>>>>>>> now.
>>>>>>>>
>>>>>>>> No waiting on reboot, and the webcam works better.
>>>>>>> I am curious what do you mean by the above reference to webcam.
>>>>>>> Can you explain it with more details, even if only the impressions?
>>>>>>
>>>>>> I should mention, that beside the already discussed timing problem with
>>>>>> bufdaemon, I also have problems with several apps:
>>>>>>
>>>>>>
>>>>>> After a high system load, several programs only react very slowly (e.g.
>>>>>> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do
>>>>>> not update their windows anymore, they freeze. After some time, Firefox
>>>>>> updates its screen content only after switching back from another window 
>>>>>> ...
>>>>>>
>>>>>> When such frozen programs are killed and restarted, they run normally
>>>>>> again for an indefinite time before they freeze again.
>>>>>>
>>>>>> These symptoms completely disappeared, after I patched the Ryzen box as
>>>>>> suggested on 01/17:
>>>>>
>>>>> Do you load latest microcode update from devcpu-data?
>>>>
>>>> Yes, sysutils/devcpu-data is installed and the following to lines are in
>>>> /boot/loader.conf
>>>>
>>>> cpu_microcode_load="YES"
>>>> cpu_microcode_name="/boot/firmware/intel-ucode.bin"
>>>>
>>>> But isn't this just for Intel (i387 and amd64), not AMD cpus?
>>> You need microcode_update_enable="YES" in /etc/rc.conf for late microcode
>>> update.
>>>
>>> I think that early boot update should work on AMD, bit for this you need to
>>> select and put right blob.  It is enough to load late to answer my question.
>>
>> Ah, ok. Thanks for clarification. I also put cpu_microcode_load="YES" in
>> /etc/rc.conf for a late update.
>>
>> Should I try again without your patch of sys/x86/tsc.c, whether the
>> problem still occurs?

Unfornately, without the patch from 01/17 the problem is _not_ solved.

Next I will try your patch from today, f lib/libc/x86/sys/__vdso_gettc.c
an lib/libc/x86/sys/__vdso_gettc.c ...


> Yes.
> 
>>
>>
>> And for the early boot update, how do I know about the right blob?
> I am not aware of the mechanism.  My best suggestion is that you match
> the blob against your CPU family/model id manually.
> 
>>
>>>
>>>>
>>>>> It might be not enough, which means that additionally latest BIOS needs
>>>>> to be flushed.
>>>>>
>>>>
>>>> I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite"
>>>> mainboard.

___
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: Waiting for bufdaemon

[Rainer Hurling]

Am 20.01.21 um 14:12 schrieb Konstantin Belousov:
> On Wed, Jan 20, 2021 at 01:56:57PM +0100, Rainer Hurling wrote:
>> Am 20.01.21 um 13:34 schrieb Konstantin Belousov:
>>> On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote:
>>>> Am 20.01.21 um 11:18 schrieb Konstantin Belousov:
>>>>> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote:
>>>>>> This patch hides the problem for me. The system seems to work better now.
>>>>>>
>>>>>> No waiting on reboot, and the webcam works better.
>>>>> I am curious what do you mean by the above reference to webcam.
>>>>> Can you explain it with more details, even if only the impressions?
>>>>
>>>> I should mention, that beside the already discussed timing problem with
>>>> bufdaemon, I also have problems with several apps:
>>>>
>>>>
>>>> After a high system load, several programs only react very slowly (e.g.
>>>> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do
>>>> not update their windows anymore, they freeze. After some time, Firefox
>>>> updates its screen content only after switching back from another window 
>>>> ...
>>>>
>>>> When such frozen programs are killed and restarted, they run normally
>>>> again for an indefinite time before they freeze again.
>>>>
>>>> These symptoms completely disappeared, after I patched the Ryzen box as
>>>> suggested on 01/17:
>>>
>>> Do you load latest microcode update from devcpu-data?
>>
>> Yes, sysutils/devcpu-data is installed and the following to lines are in
>> /boot/loader.conf
>>
>> cpu_microcode_load="YES"
>> cpu_microcode_name="/boot/firmware/intel-ucode.bin"
>>
>> But isn't this just for Intel (i387 and amd64), not AMD cpus?
> You need microcode_update_enable="YES" in /etc/rc.conf for late microcode
> update.
> 
> I think that early boot update should work on AMD, bit for this you need to
> select and put right blob.  It is enough to load late to answer my question.

Ah, ok. Thanks for clarification. I also put cpu_microcode_load="YES" in
/etc/rc.conf for a late update.

Should I try again without your patch of sys/x86/tsc.c, whether the
problem still occurs?


And for the early boot update, how do I know about the right blob?

> 
>>
>>> It might be not enough, which means that additionally latest BIOS needs
>>> to be flushed.
>>>
>>
>> I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite"
>> mainboard.

___
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: Waiting for bufdaemon

[Rainer Hurling]

Am 20.01.21 um 13:34 schrieb Konstantin Belousov:
> On Wed, Jan 20, 2021 at 01:17:51PM +0100, Rainer Hurling wrote:
>> Am 20.01.21 um 11:18 schrieb Konstantin Belousov:
>>> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote:
>>>> This patch hides the problem for me. The system seems to work better now.
>>>>
>>>> No waiting on reboot, and the webcam works better.
>>> I am curious what do you mean by the above reference to webcam.
>>> Can you explain it with more details, even if only the impressions?
>>
>> I should mention, that beside the already discussed timing problem with
>> bufdaemon, I also have problems with several apps:
>>
>>
>> After a high system load, several programs only react very slowly (e.g.
>> Firefox). Several dockable apps from WindowMaker, but also e.g. conky do
>> not update their windows anymore, they freeze. After some time, Firefox
>> updates its screen content only after switching back from another window ...
>>
>> When such frozen programs are killed and restarted, they run normally
>> again for an indefinite time before they freeze again.
>>
>> These symptoms completely disappeared, after I patched the Ryzen box as
>> suggested on 01/17:
> 
> Do you load latest microcode update from devcpu-data?

Yes, sysutils/devcpu-data is installed and the following to lines are in
/boot/loader.conf

cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"

But isn't this just for Intel (i387 and amd64), not AMD cpus?

> It might be not enough, which means that additionally latest BIOS needs
> to be flushed.
> 

I am running latest Firmware F31 on a "Gigabyte\ Aorus\ X570\ Elite"
mainboard.
___
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: Waiting for bufdaemon

[Rainer Hurling]

Am 20.01.21 um 11:18 schrieb Konstantin Belousov:
> On Wed, Jan 20, 2021 at 11:02:21AM +0100, Jakob Alvermark wrote:
>> This patch hides the problem for me. The system seems to work better now.
>>
>> No waiting on reboot, and the webcam works better.
> I am curious what do you mean by the above reference to webcam.
> Can you explain it with more details, even if only the impressions?

I should mention, that beside the already discussed timing problem with
bufdaemon, I also have problems with several apps:


After a high system load, several programs only react very slowly (e.g.
Firefox). Several dockable apps from WindowMaker, but also e.g. conky do
not update their windows anymore, they freeze. After some time, Firefox
updates its screen content only after switching back from another window ...

When such frozen programs are killed and restarted, they run normally
again for an indefinite time before they freeze again.

These symptoms completely disappeared, after I patched the Ryzen box as
suggested on 01/17:

diff --git a/sys/x86/tsc.c b/sys/x86/tsc.c
index 85924df98312..5700a8ca98e5 100644
--- a/sys/x86/x86/tsc.c
+++ b/sys/x86/x86/tsc.c
@@ -639,7 +639,7 @@ init_TSC_tc(void)
 * on Intel, and MFENCE;RDTSC on AMD.
 * - For really old CPUs, just use RDTSC.
 */
- if ((cpu_vendor_id == CPU_VENDOR_AMD ||
+ if (false && (cpu_vendor_id == CPU_VENDOR_AMD ||
cpu_vendor_id == CPU_VENDOR_HYGON) &&
CPUID_TO_FAMILY(cpu_id) >= 0x17) {
tsc_timecounter.tc_get_timecount = shift > 0 ?


HTH,
Rainer


> 
> I probably going to commit the following patch in the next 24 hours.
> 
> commit 02505d07bca320a638c96918ac9076c6eece2fff
> Author: Konstantin Belousov 
> Date:   Wed Jan 20 11:32:21 2021 +0200
> 
> AMD Zen CPUs: switch TSC timecounter to RDTSCP
> 
> Reported by:many
> MFC after:  1 weel
> Sponsored by:   The FreeBSD Foundation
> 
> diff --git a/lib/libc/x86/sys/__vdso_gettc.c b/lib/libc/x86/sys/__vdso_gettc.c
> index 7f224f8758cb..7a64f2a0b556 100644
> --- a/lib/libc/x86/sys/__vdso_gettc.c
> +++ b/lib/libc/x86/sys/__vdso_gettc.c
> @@ -125,7 +125,7 @@ struct tsc_selector_tag {
>  };
>  
>  static const struct tsc_selector_tag tsc_selector[] = {
> - [0] = { /* Intel or AMD Zen+, LFENCE */
> + [0] = { /* Intel, LFENCE */
>   .ts_rdtsc32 =   rdtsc32_mb_lfence,
>   .ts_rdtsc_low = rdtsc_low_mb_lfence,
>   },
> @@ -164,9 +164,6 @@ tsc_selector_idx(u_int cpu_feature)
>   do_cpuid(1, p);
>   cpu_id = p[0];
>  
> - if (amd_cpu && CPUID_TO_FAMILY(cpu_id) >= 0x17)
> - return (0);
> -
>   if (cpu_feature != 0) {
>   do_cpuid(0x8000, p);
>   cpu_exthigh = p[0];
> diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
> index 85924df98312..de0a1505c2f6 100644
> --- a/sys/x86/x86/tsc.c
> +++ b/sys/x86/x86/tsc.c
> @@ -633,19 +633,12 @@ init_TSC_tc(void)
>  
>   /*
>* Timecounter implementation selection, top to bottom:
> -  * - For AMD Zens and newer, use LFENCE;RDTSC.
>* - If RDTSCP is available, use RDTSCP.
>* - If fence instructions are provided (SSE2), use LFENCE;RDTSC
>*   on Intel, and MFENCE;RDTSC on AMD.
>* - For really old CPUs, just use RDTSC.
>*/
> - if ((cpu_vendor_id == CPU_VENDOR_AMD ||
> - cpu_vendor_id == CPU_VENDOR_HYGON) &&
> - CPUID_TO_FAMILY(cpu_id) >= 0x17) {
> - tsc_timecounter.tc_get_timecount = shift > 0 ?
> - tsc_get_timecount_low_lfence :
> - tsc_get_timecount_lfence;
> - } else if ((amd_feature & AMDID_RDTSCP) != 0) {
> + if ((amd_feature & AMDID_RDTSCP) != 0) {
>   tsc_timecounter.tc_get_timecount = shift > 0 ?
>   tscp_get_timecount_low : tscp_get_timecount;
>   } else if ((cpu_feature & CPUID_SSE2) != 0 && mp_ncpus > 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: Waiting for bufdaemon

[Rainer Hurling]

Am 17.01.21 um 10:49 schrieb Konstantin Belousov:
> On Sun, Jan 17, 2021 at 10:37:18AM +0100, Rainer Hurling wrote:
>> Am 17.01.21 um 05:33 schrieb Konstantin Belousov:
>>> On Sat, Jan 16, 2021 at 07:41:01PM +0100, Rainer Hurling wrote:
>>>> During another shutdown after heavy usage of the box, the following
>>>> messages were also seen:
>>>>
>>>>
>>>> [...]
>>>> Syncing disks, vnodes remaining... 22 EFI rt_settime call faulted, error 14
>>>> efirtc0: CLOCK_SETTIME error 14
>>>
>>> This means that BIOS code faulted during RTC settime call.  I doubt that
>>> it is related.
>>>
>>> On the other hand, it is good that the onfault EFI RT code got tested 
>>> finally.
>>>
>>
>> Thanks for clarification :)
>>
>>
>> Any chance of getting a fix for the AMD CPUs in the foreseeable future?
>>
>> Or should I revert commit 9e680e4005b7 on affected boxes until further
>> notice (as a workaround)?
> 
> I am working on it, no ETA.
> 
> Interesting point would be to check on machines of other testers,
> if the following hides the problem.
> 
> diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
> index 85924df98312..5700a8ca98e5 100644
> --- a/sys/x86/x86/tsc.c
> +++ b/sys/x86/x86/tsc.c
> @@ -639,7 +639,7 @@ init_TSC_tc(void)
>*   on Intel, and MFENCE;RDTSC on AMD.
>* - For really old CPUs, just use RDTSC.
>*/
> - if ((cpu_vendor_id == CPU_VENDOR_AMD ||
> + if (false && (cpu_vendor_id == CPU_VENDOR_AMD ||
>   cpu_vendor_id == CPU_VENDOR_HYGON) &&
>   CPUID_TO_FAMILY(cpu_id) >= 0x17) {
>   tsc_timecounter.tc_get_timecount = shift > 0 ?
> 

I tried the above patch on a Ryzen 3950X.

After reboot (again with long waiting for bufdaemon and more) the box
had some heavy load with several jobs (llvm on Poudriere, building
qt5-webengine, libreoffice and some more in parallel). All went fine.

Afterwards I rebooted again. This time, the shutdown was fast  without
any unusual delays :)

Many 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: Waiting for bufdaemon

[Rainer Hurling]

Am 17.01.21 um 05:33 schrieb Konstantin Belousov:
> On Sat, Jan 16, 2021 at 07:41:01PM +0100, Rainer Hurling wrote:
>> During another shutdown after heavy usage of the box, the following
>> messages were also seen:
>>
>>
>> [...]
>> Syncing disks, vnodes remaining... 22 EFI rt_settime call faulted, error 14
>> efirtc0: CLOCK_SETTIME error 14
> 
> This means that BIOS code faulted during RTC settime call.  I doubt that
> it is related.
> 
> On the other hand, it is good that the onfault EFI RT code got tested finally.
> 

Thanks for clarification :)


Any chance of getting a fix for the AMD CPUs in the foreseeable future?

Or should I revert commit 9e680e4005b7 on affected boxes until further
notice (as a workaround)?
___
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: Waiting for bufdaemon

[Rainer Hurling]

Am 15.01.21 um 19:48 schrieb Rainer Hurling:
> Am 15.01.21 um 16:45 schrieb Konstantin Belousov:
>> On Fri, Jan 15, 2021 at 04:30:19PM +0100, Mikaël Urankar wrote:
>>> On 15/01/2021 16:02, Konstantin Belousov wrote:
>>>> On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote:
>>>>> On 15/01/2021 11:26, Jakob Alvermark wrote:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> When rebooting my thinkpad the 'bufdaemon' times out:
>>>>>>
>>>>>> Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed
>>>>>> out
>>>>>>
>>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop
>>>>>> ... timed out
>>>>>>
>>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop
>>>>>> ... timed out
>>>>>>
>>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop
>>>>>> ... timed out
>>>>>>
>>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop
>>>>>> ... timed out
>>>>>>
>>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop
>>>>>> ... timed out
>>>>>>
>>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop
>>>>>> ... timed out
>>>>>>
>>>>>>
>>>>>> This started happening recently (within the last week I think).
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal.
>>>>>
>>>>> 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of 
>>>>> orphaned
>>>>> groups) "seems" ok
>>>>>
>>>>> cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP
>>>>> support), affected by the timeout.
>>>>>
>>>>> I haven't tried the intermediate commit yet.
>>>>>
>>>>> My intel machine doesn't seem to be affected
>>>>
>>>> If you revert only 9e680e4005b7, is it fixed ?
>>>>
>>> Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 tests,
>>> I can do more if you want)
>> Please show me the output from sysctl
>> kern.timecounter
>> kern.eventtimer
>> and first 100 lines of dmesg from the verbose boot (that contains the CPU
>> ident lines).
> 
> 
> I also have this timeout issue only on AMD, here Ryzen 3950X:
> 
> [...]
> Waiting for PIDS: 2905
> 90 seconds watchdog timeout expired. Shutdown terminated.
> Fri Jan 15 19:21:01 xx init[1]: /etc/rc.shutdown terminated
> abnormally, going to single user mode
> Fri Jan 15 19:21:01 xx syslogd: exiting on signal 15
> wg0: link state changed to DOWN
> Waiting (max 69 seconds) for system process `vnlru' to stop... done
> Waiting (max 60 seconds) for system process `syncer' to stop...
> Syncing disks, vnodes remaining... 22 23 23 1 1 0 0 0 done
> Waiting (max 60 seconds) for system thread `bufdaemon' to stop... done
> Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop...
> done
> Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop...
> done
> Waiting (max 60 seconds) for system thread `bufspacedaemon-2' to stop...
> done
> Waiting (max 60 seconds) for system thread `bufspacedaemon-3' to stop...
> timeout
> Waiting (max 60 seconds) for system thread `bufspacedaemon-4' to stop...
> timeout
> Waiting (max 60 seconds) for system thread `bufspacedaemon-5' to stop...
> done
> Waiting (max 60 seconds) for system thread `bufspacedaemon-6' to stop...
> 
> 
> You will find the wanted output from sysctl and boot -v in the attachment.
> 
> HTH,
> Rainer Hurling
> 

During another shutdown after heavy usage of the box, the following
messages were also seen:


[...]
Syncing disks, vnodes remaining... 22 EFI rt_settime call faulted, error 14
efirtc0: CLOCK_SETTIME error 14

___
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: Waiting for bufdaemon

[Rainer Hurling]

Am 15.01.21 um 16:45 schrieb Konstantin Belousov:
> On Fri, Jan 15, 2021 at 04:30:19PM +0100, Mikaël Urankar wrote:
>> On 15/01/2021 16:02, Konstantin Belousov wrote:
>>> On Fri, Jan 15, 2021 at 03:56:01PM +0100, Mikaël Urankar wrote:
>>>> On 15/01/2021 11:26, Jakob Alvermark wrote:
>>>>> Hi,
>>>>>
>>>>>
>>>>> When rebooting my thinkpad the 'bufdaemon' times out:
>>>>>
>>>>> Waiting (max 60 seconds) for system thread 'bufdaemon' to stop ... timed
>>>>> out
>>>>>
>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-0' to stop
>>>>> ... timed out
>>>>>
>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-1' to stop
>>>>> ... timed out
>>>>>
>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-2' to stop
>>>>> ... timed out
>>>>>
>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-3' to stop
>>>>> ... timed out
>>>>>
>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-4' to stop
>>>>> ... timed out
>>>>>
>>>>> Waiting (max 60 seconds) for system thread 'bufspacedaemon-5' to stop
>>>>> ... timed out
>>>>>
>>>>>
>>>>> This started happening recently (within the last week I think).
>>>>
>>>> Hi,
>>>>
>>>> I'm also affected. I have an AMD Ryzen 9 3900X cpu, running bare metal.
>>>>
>>>> 5844bd058aed6f3d0c8cbbddd6aa95993ece0189 (jobc: rework detection of 
>>>> orphaned
>>>> groups) "seems" ok
>>>>
>>>> cd240c9cf100bec3def38ceb4a320611b1d02693 (x86 vdso gettc: Add RDTSCP
>>>> support), affected by the timeout.
>>>>
>>>> I haven't tried the intermediate commit yet.
>>>>
>>>> My intel machine doesn't seem to be affected
>>>
>>> If you revert only 9e680e4005b7, is it fixed ?
>>>
>> Yes it seems to be fixed with 9e680e4005b7 reverted (I've only done 2 tests,
>> I can do more if you want)
> Please show me the output from sysctl
> kern.timecounter
> kern.eventtimer
> and first 100 lines of dmesg from the verbose boot (that contains the CPU
> ident lines).


I also have this timeout issue only on AMD, here Ryzen 3950X:

[...]
Waiting for PIDS: 2905
90 seconds watchdog timeout expired. Shutdown terminated.
Fri Jan 15 19:21:01 xx init[1]: /etc/rc.shutdown terminated
abnormally, going to single user mode
Fri Jan 15 19:21:01 xx syslogd: exiting on signal 15
wg0: link state changed to DOWN
Waiting (max 69 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining... 22 23 23 1 1 0 0 0 done
Waiting (max 60 seconds) for system thread `bufdaemon' to stop... done
Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop...
done
Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop...
done
Waiting (max 60 seconds) for system thread `bufspacedaemon-2' to stop...
done
Waiting (max 60 seconds) for system thread `bufspacedaemon-3' to stop...
timeout
Waiting (max 60 seconds) for system thread `bufspacedaemon-4' to stop...
timeout
Waiting (max 60 seconds) for system thread `bufspacedaemon-5' to stop...
done
Waiting (max 60 seconds) for system thread `bufspacedaemon-6' to stop...


You will find the wanted output from sysctl and boot -v in the attachment.

HTH,
Rainer Hurling
#sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 1
kern.timecounter.invariant_tsc: 1
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) 
dummy(-100)
kern.timecounter.hardware: TSC-low
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 3355373301
kern.timecounter.tc.ACPI-fast.mask: 4294967295
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.counter: 3626460971
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 21196
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.TSC-low.quality: 1000
kern.timecounter.tc.TSC-low.frequency: 1746752087
kern.timecounter.tc.TSC-low.counter: 86914443

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

[Rainer Hurling]

Am 23.12.20 um 21:55 schrieb Ulrich Spörlein:
> On Wed, 2020-12-23 at 12:19:47 -0800, John Kennedy wrote:
>> On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote:
>>> On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
>>> > The FreeBSD project will be moving it's source repo from subversion
>>> to git
>>> > starting this this weekend. The docs repo was moved 2 weeks ago.
>>> The ports
>>> > repo will move at the end of March, 2021 due to timing issues. ...
>>>
>>>   I filed Bug 252028 (sys/conf/newvers.sh: git "-dirty" even when
>>> clean),
>>> but that's just a trivial issue with my source tree being marked -dirty
>>> when it isn't, and that would have been part of r368709 anyway.  All my
>>> other git nits have been my own (refs/notes and origin name).
>>
>>  Warner/others, up to r368820, we had log entries that looked like this:
>>
>> commit 3cc0c0d66a065554459bd2f9b4f80cc07426464a
>> Author: Li-Wen Hsu 
>> Date:   Sun Dec 20 02:59:44 2020 +
>> 
>>     Mark the repository as being converted to Git.
>> 
>>     This is the last Subversion commit to src.
>> 
>>     Sponsored by:   The FreeBSD Foundation
>> 
>> Notes:
>>     svn path=/head/; revision=368820
>>
>>  Now, our git logs look like this:
>>
>> commit 17eba5e32a2cf7a217bb9f1e5dcca351f2b71cfc
>> Author: Ed Maste 
>> Date:   Tue Dec 22 23:31:15 2020 -0500
>> 
>>     newvers.sh: fix sense of git dirty check
>> 
>>     Previously we reported -dirty for an unmodified tree, and no
>> -dirty if
>>     there were changes.
>> 
>>     PR: 252028
>>     Reported by:    John Kennedy
>>
>>  (Specifically, no Notes: with revision= value)
> 
> Yes, these notes are merely pointers to the SVN revisions. Without SVN,
> we will of course not get any new notes.
> 
>>  For the kernel I compiled today, the uname output dumps out:
>>
>> FreeBSD 13.0-CURRENT #245 r368820+878d53410f75-c255274(main): ...
>>
>>  Last kernel was (-dirty since fixed):
>>
>> FreeBSD 13.0-CURRENT #244
>> r368820+3cc0c0d66a06-c255241(main)-dirty: ...
>>
>>  So, the r368820-value isn't being updated for it to find anymore. 
>> The middle
>> value corresponds to the git commit and does have value (878d53410f75
>> is your
>> "UPDATING: Announce git transition", 3cc0c0d66a06 was the "Mark the
>> repository
>> as being converted to Git" r368820 commit).
> 
> Yeah, that's a bug in newvers.sh, thanks for pointing that out. It finds
> "some" note in the last 10k revs and then uses that, instead of properly
> falling back to counting from HEAD, which would result in -c255126 or
> something around that.

I built HEAD this afternoon and got 'FreeBSD 13.0-CURRENT #0
92be2847e84-c255272(main): Wed Dec 23 17:39:31 CET 2020'. The counting
seems more correct here?

> We'll fix it ...
> 
> Cheers
> Uli
___
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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

On 23.09.20 00:51, Mark Johnston wrote:
> On Tue, Sep 22, 2020 at 01:13:29AM +0300, Konstantin Belousov wrote:
>> On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote:
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 31; apic id = 1f
>>> fault virtual address   = 0x25407efa
>> This address is very suspicious.
>>
>> I cannot claim it as the fact, but most likely cause for such garbage
>> pointer value is mismatched ABI between kernel and module.  In other
>> words, the module was built against headers from different kernel.
> 
> For some reason clang is not complaining about a missing declaration for
> vm_pager_allocate(), despite -Wmissing-prototypes in the CFLAGS...
> 
> This patch is required on top of a patched extract of the vbox sources:
> 
> --- the-freebsd-kernel.h.orig 2020-09-22 18:49:26.499329000 -0400
> +++ the-freebsd-kernel.h  2020-09-22 18:49:55.317615000 -0400
> @@ -68,6 +68,7 @@
>  #include 
>  #include /* KERN_SUCCESS ++ */
>  #include 
> +#include 
>  #include  /* vm_phys_alloc_* */
>  #include/* kmem_alloc_attr */
>  #include   /* vm_contig_grow_cache */
> --- memobj-r0drv-freebsd.c.orig   2020-09-22 18:49:25.010456000 -0400
> +++ memobj-r0drv-freebsd.c2020-09-22 18:49:47.462276000 -0400
> @@ -323,7 +323,8 @@
>  size_t  cPages = atop(pMemFreeBSD->Core.cb);
>  int rc;
>  
> -pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, cPages);
> +pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL,
> +pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred);
>  
>  /* No additional object reference for auto-deallocation upon unmapping. 
> */
>  #if __FreeBSD_version >= 155
> @@ -457,7 +458,8 @@
>  return VERR_NO_MEMORY;
>  }
>  
> -pMemFreeBSD->pObject = vm_object_allocate(OBJT_PHYS, atop(cb));
> +pMemFreeBSD->pObject = vm_pager_allocate(OBJT_PHYS, NULL,
> +pMemFreeBSD->Core.cb, VM_PROT_ALL, 0, curthread->td_ucred);
>  
>  if (PhysHighest != NIL_RTHCPHYS)
>  VmPhysAddrHigh = PhysHighest;
> 

I can confirm that these patches (two files) work for me. The system
reboots with loaded vbox kernel modules.

Many thanks for your help and investigations!

Best regards,
Rainer
___
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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

On 22.09.20 07:51, monochrome wrote:
> Rainer, I'm all up and running and clean with the latest again, if it
> still doesn't work after your next try, send me your step-by-step to
> patch and i'll try it here. I'm using ryzen video so I have to disable
> stuff to even see the fault messages.

Hi monochrome,

The attached file is the patched version, I put in the files dir of
emulators/virtualbox-ose (the main port, not the kernel modules one).

Then I rebuilt and reinstall the ports mulators/virtualbox-ose-kmod and
mulators/virtualbox-ose and rebooted the box.

In my case, the boot process freezes after the page fault messages.


> 
> On 9/22/20 1:06 AM, Rainer Hurling wrote:
>> Am 22.09.20 um 00:13 schrieb Konstantin Belousov:
>>> On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote:
>>>> Fatal trap 12: page fault while in kernel mode
>>>> cpuid = 31; apic id = 1f
>>>> fault virtual address   = 0x25407efa
>>> This address is very suspicious.
>>>
>>> I cannot claim it as the fact, but most likely cause for such garbage
>>> pointer value is mismatched ABI between kernel and module.  In other
>>> words, the module was built against headers from different kernel.
>>
>> Hmm, thanks for the pointer. I will double check this evening and
>> reporting back.
>>
>> Normally, this module should have been built and installed with the
>> kernel build.
>>
>>>
>>>> fault code  = supervisor read data, page not present
>>>> instruction pointer = 0x20:0x80ec0b63
>>>> stack pointer   = 0x28:0x826018b0
>>>> frame pointer   = 0x28:0x82601940
>>>> code segment    = base 0x0, limit 0xf, type 0x1b
>>>>  = DPL 0, pres 1, long 1, def32 0, gran 1
>>>> processor eflags    = interrupt enabled, resume, IOPL = 0
>>>> current process = 0 (swapper)
>>>> trap number = 12
>>>> panic: page fault
>>>> cpuid = 31
>>>> time = 1
>>>> KDB: stack backtrace:
>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>>> 0x82601560
>>>> vpanic() at vpanic+0x182/frame 0x826015b0
>>>> panic() at panic+0x43/frame 0x82601610
>>>> trap_fatal() at trap_fatal+0x387/frame 0x82601670
>>>> trap_pfault() at trap_pfault+0x97/frame 0x826016d0
>>>> trap() at trap+0x2ab/frame 0x826017e0
>>>> calltrap() at calltrap+0x8/frame 0x826017e0
>>>> --- trap 0xc, rip = 0x80ec0b63, rsp = 0x826018b0, rbp =
>>>> 0x82601940 ---
>>>> vm_map_insert() at vm_map_insert+0x2f3/framw 0x82601940
>>>> vm_map_find() at vm_map_find+0x4a4/frame 0x82601a00
>>>> rtR0MemObjFreeBSDAllocHelper() at
>>>> rtR0MemObjFreeBSDAllocHelper+0x96/frame 0x82601a70
>>>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame
>>>> 0x82601ac0
>>>> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60
>>>> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0
>>>> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame
>>>> 0x82601bf0
>>>> module_register_init() at module_register_init+0xbd/frame
>>>> 0x82601c20
>>>> mi_startup() at mi_startup+0xec/frame 0x82601c70
>>>> btext() at btext+0x2c
>>>> KDB: enter: panic
>>>> [ thread pid 0 tid 10 ]
>>>> Stopped at  kdb_enter+0x37: movq    $0,0x10b5616(%rip)
>>>> db>
>>>>
>>>>
>>>> Perhaps this gives some more insight into the problem? I can't assess,
>>>> sorry.
>>

___
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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

On 22.09.20 07:06, Rainer Hurling wrote:
> Am 22.09.20 um 00:13 schrieb Konstantin Belousov:
>> On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote:
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 31; apic id = 1f
>>> fault virtual address   = 0x25407efa
>> This address is very suspicious.
>>
>> I cannot claim it as the fact, but most likely cause for such garbage
>> pointer value is mismatched ABI between kernel and module.  In other
>> words, the module was built against headers from different kernel.
> 
> Hmm, thanks for the pointer. I will double check this evening and
> reporting back.
> 
> Normally, this module should have been built and installed with the
> kernel build.

As I said, the module was rebuild and reinstalled with the kernel build,
and I double checked, the module was the patched version.

So the boot messages about the page fault should be created by the
rebuild, patched module.

> 
>>
>>> fault code  = supervisor read data, page not present
>>> instruction pointer = 0x20:0x80ec0b63
>>> stack pointer   = 0x28:0x826018b0
>>> frame pointer   = 0x28:0x82601940
>>> code segment    = base 0x0, limit 0xf, type 0x1b
>>>  = DPL 0, pres 1, long 1, def32 0, gran 1
>>> processor eflags    = interrupt enabled, resume, IOPL = 0
>>> current process = 0 (swapper)
>>> trap number = 12
>>> panic: page fault
>>> cpuid = 31
>>> time = 1
>>> KDB: stack backtrace:
>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>> 0x82601560
>>> vpanic() at vpanic+0x182/frame 0x826015b0
>>> panic() at panic+0x43/frame 0x82601610
>>> trap_fatal() at trap_fatal+0x387/frame 0x82601670
>>> trap_pfault() at trap_pfault+0x97/frame 0x826016d0
>>> trap() at trap+0x2ab/frame 0x826017e0
>>> calltrap() at calltrap+0x8/frame 0x826017e0
>>> --- trap 0xc, rip = 0x80ec0b63, rsp = 0x826018b0, rbp =
>>> 0x82601940 ---
>>> vm_map_insert() at vm_map_insert+0x2f3/framw 0x82601940
>>> vm_map_find() at vm_map_find+0x4a4/frame 0x82601a00
>>> rtR0MemObjFreeBSDAllocHelper() at
>>> rtR0MemObjFreeBSDAllocHelper+0x96/frame 0x82601a70
>>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame
>>> 0x82601ac0
>>> supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60
>>> supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0
>>> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame
>>> 0x82601bf0
>>> module_register_init() at module_register_init+0xbd/frame
>>> 0x82601c20
>>> mi_startup() at mi_startup+0xec/frame 0x82601c70
>>> btext() at btext+0x2c
>>> KDB: enter: panic
>>> [ thread pid 0 tid 10 ]
>>> Stopped at  kdb_enter+0x37: movq    $0,0x10b5616(%rip)
>>> db>
>>>
>>>
>>> Perhaps this gives some more insight into the problem? I can't assess,
>>> sorry.

___
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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

Am 22.09.20 um 00:13 schrieb Konstantin Belousov:

On Mon, Sep 21, 2020 at 08:57:46PM +0200, Rainer Hurling wrote:

Fatal trap 12: page fault while in kernel mode
cpuid = 31; apic id = 1f
fault virtual address   = 0x25407efa

This address is very suspicious.

I cannot claim it as the fact, but most likely cause for such garbage
pointer value is mismatched ABI between kernel and module.  In other
words, the module was built against headers from different kernel.


Hmm, thanks for the pointer. I will double check this evening and 
reporting back.


Normally, this module should have been built and installed with the 
kernel build.





fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80ec0b63
stack pointer   = 0x28:0x826018b0
frame pointer   = 0x28:0x82601940
code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
cpuid = 31
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0x82601560
vpanic() at vpanic+0x182/frame 0x826015b0
panic() at panic+0x43/frame 0x82601610
trap_fatal() at trap_fatal+0x387/frame 0x82601670
trap_pfault() at trap_pfault+0x97/frame 0x826016d0
trap() at trap+0x2ab/frame 0x826017e0
calltrap() at calltrap+0x8/frame 0x826017e0
--- trap 0xc, rip = 0x80ec0b63, rsp = 0x826018b0, rbp =
0x82601940 ---
vm_map_insert() at vm_map_insert+0x2f3/framw 0x82601940
vm_map_find() at vm_map_find+0x4a4/frame 0x82601a00
rtR0MemObjFreeBSDAllocHelper() at
rtR0MemObjFreeBSDAllocHelper+0x96/frame 0x82601a70
rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame
0x82601ac0
supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60
supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0
VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame
0x82601bf0
module_register_init() at module_register_init+0xbd/frame 0x82601c20
mi_startup() at mi_startup+0xec/frame 0x82601c70
btext() at btext+0x2c
KDB: enter: panic
[ thread pid 0 tid 10 ]
Stopped at  kdb_enter+0x37: movq$0,0x10b5616(%rip)
db>


Perhaps this gives some more insight into the problem? I can't assess,
sorry.


___
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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

On 20.09.20 22:35, Rainer Hurling wrote:
> On 20.09.20 22:07, Konstantin Belousov wrote:
>> On Sun, Sep 20, 2020 at 10:55:26PM +0300, Konstantin Belousov wrote:
>>> On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote:
>>>> Am 20.09.20 um 11:38 schrieb Konstantin Belousov:
>>>>> On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote:
>>>>>> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
>>>>>>> On 2020-09-20 10:05, Rainer Hurling wrote:
>>>>>>>> Hi monochrome,
>>>>>>>>
>>>>>>>> back to keyboard, it tried newest CURRENT (r365920) on my box and even
>>>>>>>> with newest sources the error occurs.
>>>>>>>>
>>>>>>>> After looking around somewhat more, I found some hints about Virtualbox
>>>>>>>> kernel module having problems with r365488. Unfortunately, I am not 
>>>>>>>> able
>>>>>>>> to find the thread again :(
>>>>>>>>
>>>>>>>> What seems to help as a workaround is to disable the loading of
>>>>>>>> VirtualBox in /boot/loader.conf
>>>>>>>>
>>>>>>>> #vboxdrv_load="YES"
>>>>>>>>
>>>>>>>> and in /etc/rc.conf
>>>>>>>>
>>>>>>>> #vboxnet_enable="YES"
>>>>>>>> #vboxguest_enable="YES"
>>>>>>>>
>>>>>>>>
>>>>>>>> So probably, this page fault is not restricted to AMD Ryzen?
>>>>>>>>
>>>>>>>
>>>>>>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD
>>>>>>> version was not bumped correctly.
>>>>>>>
>>>>>>> --HPS
>>>>>>>
>>>>>>
>>>>>> Thanks for the hint. But I did rebuild all kernel modules before
>>>>>> rebooting, in my case vbox*.ko, nvidia*.ko.
>>>>>
>>>>> Provide backtrace of the panic.
>>>>>
>>>>
>>>> Hi Konstantin,
>>>>
>>>> Thanks for your response.
>>>>
>>>> After trying several ways to produce a core dump or a working kdb prompt
>>>> without success, all I can offer is the following screen contents. I
>>>> built a GENERIC kernel with debugging enabled, enable loading of vboxdrv
>>>> via /boot/loader.conf and /etc/rc.conf as described above:
>>>>
>>>>
>>>> [..snip..]
>>>> procfs registered
>>>> modulte_register_init: MOD_LOAD (tmpfs, 0x80caa060,
>>>> 0x82520a70) error 17
>>>> Timecounters tick every 1.000 msec
>>>> lo0: bpf attached
>>>> vlan: initialized, using hash tables with chaining
>>>>
>>>>
>>>> Fatal trap 12: page fault while in kernel mode
>>>> cpuid = 31; apic id = 1f
>>>> fault virtual address   = 0x0
>>>> fault code  = supervisor read data, page not present
>>>> instruction pointer = 0x20:0x80ea889b
>>>> stack pointer   = 0x20:0x826017e0
>>>> frame pointer   = 0x20:0x826017e0
>>>> code segment= base 0x0, limit 0xf, type 0x1b
>>>> = DPL 0, pres 1, long 1, def32 0, gran 1
>>>> processor eflags= interrupt enabled, resume, IOPL = 0
>>>> current process = 0 (swapper)
>>>> trap number = 12
>>>> panic: page fault
>>>> cpuid = 31
>>>> time = 1
>>>> KDB: stack backtrace:
>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>>> 0x82601490
>>>> vpanic() at vpanic+0x182/frame 0x826014e0
>>>> panic() at panic+0x43/frame 0x82601540
>>>> trap_fatal() at trap_fatal+0x387/frame 0x826015a0
>>>> trap_pfault() at trap_pfault+0x97/frame 0x82601600
>>>> calltrap() at calltrap+0x8/frame 0x82601710
>>>> --- trap 0xc, rip = 0x80ea889b, rsp = 0x826017e0, rbp =
>>>> 0x826017e0 ---
>>>> phys_pager_getpages() at phys_pager_getpages+0xb/frame 0x826017e0
>>>> vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0x82601830
&g

Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

On 20.09.20 22:07, Konstantin Belousov wrote:
> On Sun, Sep 20, 2020 at 10:55:26PM +0300, Konstantin Belousov wrote:
>> On Sun, Sep 20, 2020 at 03:11:26PM +0200, Rainer Hurling wrote:
>>> Am 20.09.20 um 11:38 schrieb Konstantin Belousov:
>>>> On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote:
>>>>> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
>>>>>> On 2020-09-20 10:05, Rainer Hurling wrote:
>>>>>>> Hi monochrome,
>>>>>>>
>>>>>>> back to keyboard, it tried newest CURRENT (r365920) on my box and even
>>>>>>> with newest sources the error occurs.
>>>>>>>
>>>>>>> After looking around somewhat more, I found some hints about Virtualbox
>>>>>>> kernel module having problems with r365488. Unfortunately, I am not able
>>>>>>> to find the thread again :(
>>>>>>>
>>>>>>> What seems to help as a workaround is to disable the loading of
>>>>>>> VirtualBox in /boot/loader.conf
>>>>>>>
>>>>>>> #vboxdrv_load="YES"
>>>>>>>
>>>>>>> and in /etc/rc.conf
>>>>>>>
>>>>>>> #vboxnet_enable="YES"
>>>>>>> #vboxguest_enable="YES"
>>>>>>>
>>>>>>>
>>>>>>> So probably, this page fault is not restricted to AMD Ryzen?
>>>>>>>
>>>>>>
>>>>>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD
>>>>>> version was not bumped correctly.
>>>>>>
>>>>>> --HPS
>>>>>>
>>>>>
>>>>> Thanks for the hint. But I did rebuild all kernel modules before
>>>>> rebooting, in my case vbox*.ko, nvidia*.ko.
>>>>
>>>> Provide backtrace of the panic.
>>>>
>>>
>>> Hi Konstantin,
>>>
>>> Thanks for your response.
>>>
>>> After trying several ways to produce a core dump or a working kdb prompt
>>> without success, all I can offer is the following screen contents. I
>>> built a GENERIC kernel with debugging enabled, enable loading of vboxdrv
>>> via /boot/loader.conf and /etc/rc.conf as described above:
>>>
>>>
>>> [..snip..]
>>> procfs registered
>>> modulte_register_init: MOD_LOAD (tmpfs, 0x80caa060,
>>> 0x82520a70) error 17
>>> Timecounters tick every 1.000 msec
>>> lo0: bpf attached
>>> vlan: initialized, using hash tables with chaining
>>>
>>>
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 31; apic id = 1f
>>> fault virtual address   = 0x0
>>> fault code  = supervisor read data, page not present
>>> instruction pointer = 0x20:0x80ea889b
>>> stack pointer   = 0x20:0x826017e0
>>> frame pointer   = 0x20:0x826017e0
>>> code segment= base 0x0, limit 0xf, type 0x1b
>>> = DPL 0, pres 1, long 1, def32 0, gran 1
>>> processor eflags= interrupt enabled, resume, IOPL = 0
>>> current process = 0 (swapper)
>>> trap number = 12
>>> panic: page fault
>>> cpuid = 31
>>> time = 1
>>> KDB: stack backtrace:
>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>> 0x82601490
>>> vpanic() at vpanic+0x182/frame 0x826014e0
>>> panic() at panic+0x43/frame 0x82601540
>>> trap_fatal() at trap_fatal+0x387/frame 0x826015a0
>>> trap_pfault() at trap_pfault+0x97/frame 0x82601600
>>> calltrap() at calltrap+0x8/frame 0x82601710
>>> --- trap 0xc, rip = 0x80ea889b, rsp = 0x826017e0, rbp =
>>> 0x826017e0 ---
>>> phys_pager_getpages() at phys_pager_getpages+0xb/frame 0x826017e0
>>> vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0x82601830
>>> vm_fault() at vm_fault+0x5d6/frame 0x82601940
>>> vm_map_wire_locked() at vm_map_wire_locked+0x3a6/framw 0x826019f0
>>> vm_map_wire() at vm_map_wire+0x6b/frame 0x82601a20
>>> rtR0MemObjFreeBSDAllocHelper() at
>>> rtR0MemObjFreeBSDAllocHelper+0xdc/frame 0x82601a70
>>> rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame
>>&

Re: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

Am 20.09.20 um 11:38 schrieb Konstantin Belousov:
> On Sun, Sep 20, 2020 at 10:26:11AM +0200, Rainer Hurling wrote:
>> Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
>>> On 2020-09-20 10:05, Rainer Hurling wrote:
>>>> Hi monochrome,
>>>>
>>>> back to keyboard, it tried newest CURRENT (r365920) on my box and even
>>>> with newest sources the error occurs.
>>>>
>>>> After looking around somewhat more, I found some hints about Virtualbox
>>>> kernel module having problems with r365488. Unfortunately, I am not able
>>>> to find the thread again :(
>>>>
>>>> What seems to help as a workaround is to disable the loading of
>>>> VirtualBox in /boot/loader.conf
>>>>
>>>> #vboxdrv_load="YES"
>>>>
>>>> and in /etc/rc.conf
>>>>
>>>> #vboxnet_enable="YES"
>>>> #vboxguest_enable="YES"
>>>>
>>>>
>>>> So probably, this page fault is not restricted to AMD Ryzen?
>>>>
>>>
>>> Possibly you need to rebuild that kernel module. Maybe the FreeBSD
>>> version was not bumped correctly.
>>>
>>> --HPS
>>>
>>
>> Thanks for the hint. But I did rebuild all kernel modules before
>> rebooting, in my case vbox*.ko, nvidia*.ko.
> 
> Provide backtrace of the panic.
> 

Hi Konstantin,

Thanks for your response.

After trying several ways to produce a core dump or a working kdb prompt
without success, all I can offer is the following screen contents. I
built a GENERIC kernel with debugging enabled, enable loading of vboxdrv
via /boot/loader.conf and /etc/rc.conf as described above:


[..snip..]
procfs registered
modulte_register_init: MOD_LOAD (tmpfs, 0x80caa060,
0x82520a70) error 17
Timecounters tick every 1.000 msec
lo0: bpf attached
vlan: initialized, using hash tables with chaining


Fatal trap 12: page fault while in kernel mode
cpuid = 31; apic id = 1f
fault virtual address   = 0x0
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80ea889b
stack pointer   = 0x20:0x826017e0
frame pointer   = 0x20:0x826017e0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
cpuid = 31
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0x82601490
vpanic() at vpanic+0x182/frame 0x826014e0
panic() at panic+0x43/frame 0x82601540
trap_fatal() at trap_fatal+0x387/frame 0x826015a0
trap_pfault() at trap_pfault+0x97/frame 0x82601600
calltrap() at calltrap+0x8/frame 0x82601710
--- trap 0xc, rip = 0x80ea889b, rsp = 0x826017e0, rbp =
0x826017e0 ---
phys_pager_getpages() at phys_pager_getpages+0xb/frame 0x826017e0
vm_pager_get_pages() at vm_pager_get_pages+0x4f/frame 0x82601830
vm_fault() at vm_fault+0x5d6/frame 0x82601940
vm_map_wire_locked() at vm_map_wire_locked+0x3a6/framw 0x826019f0
vm_map_wire() at vm_map_wire+0x6b/frame 0x82601a20
rtR0MemObjFreeBSDAllocHelper() at
rtR0MemObjFreeBSDAllocHelper+0xdc/frame 0x82601a70
rtR0MemObjNativeAllocCont() at rtR0MemObjNativeAllocCont+0x50/frame
0x82601ac0
supdrvGipCreate() at supdrvGipCreate+0x97/frame 0x82601b60
supdrvInitDevExt() at supdrvInitDevExt+0x19a/frame 0x82601bd0
VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x46/frame
0x82601bf0
module_register_init() at module_register_init+0xbd/frame 0x82601c20
mi_startup() at mi_startup+0xec/frame 0x82601c70
btext() at btext+0x2c
KDB: enter: panic
[ thread pid 0 tid 10 ]
Stopped at  kdb_enter+0x37: movq$0,0x10b5796(%rip9
db>


The system freezes at this point, no core dump is generated ;)  This
does not happen without loading VBoxDrv.

At least, the screen dump shows VBoxDrvFreeBSDModuleEvent(). I hope,
this is of some help.

Best regards,
Rainer
___
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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

Am 20.09.20 um 10:20 schrieb Hans Petter Selasky:
> On 2020-09-20 10:05, Rainer Hurling wrote:
>> Hi monochrome,
>>
>> back to keyboard, it tried newest CURRENT (r365920) on my box and even
>> with newest sources the error occurs.
>>
>> After looking around somewhat more, I found some hints about Virtualbox
>> kernel module having problems with r365488. Unfortunately, I am not able
>> to find the thread again :(
>>
>> What seems to help as a workaround is to disable the loading of
>> VirtualBox in /boot/loader.conf
>>
>> #vboxdrv_load="YES"
>>
>> and in /etc/rc.conf
>>
>> #vboxnet_enable="YES"
>> #vboxguest_enable="YES"
>>
>>
>> So probably, this page fault is not restricted to AMD Ryzen?
>>
> 
> Possibly you need to rebuild that kernel module. Maybe the FreeBSD
> version was not bumped correctly.
> 
> --HPS
> 

Thanks for the hint. But I did rebuild all kernel modules before
rebooting, in my case vbox*.ko, nvidia*.ko.

Best wishes,
Rainer
___
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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

Hi monochrome,

back to keyboard, it tried newest CURRENT (r365920) on my box and even
with newest sources the error occurs.

After looking around somewhat more, I found some hints about Virtualbox
kernel module having problems with r365488. Unfortunately, I am not able
to find the thread again :(

What seems to help as a workaround is to disable the loading of
VirtualBox in /boot/loader.conf

#vboxdrv_load="YES"

and in /etc/rc.conf

#vboxnet_enable="YES"
#vboxguest_enable="YES"


So probably, this page fault is not restricted to AMD Ryzen?

HTH,
Rainer


Am 20.09.20 um 08:04 schrieb monochrome:
> I have confirmed that r365487 is the last kernel that will boot on my
> 2400G. These are the files changed between r365487 and r365488:
> 
> U    sys/vm/phys_pager.c
> U    sys/vm/vm_object.c
> U    sys/vm/vm_object.h
> U    sys/vm/vm_pager.h
> 
> 
> 
> On 9/18/20 8:57 AM, Rainer Hurling wrote:
>> Hi,
>> I am AFK until Sunday, so can't investigate ATM.
>> And no, I haven't solved it until now. Thanks for your report.
>> Rainer
>>
>> Am 18. September 2020 00:38:31 MESZ schrieb monochrome
>> :
>>>
>>> forgot you
>>>
>>>  Forwarded Message 
>>> Subject: Re: r365488 page faults on AMD Ryzen 9 3950X
>>> Date: Thu, 17 Sep 2020 17:03:49 -0400
>>> From: monochrome 
>>> To: freebsd-current@freebsd.org
>>>
>>> I am also having this problem. Have you resolved it? Mine is a Ryzen
>>> 5 2400G
>>>
>>> On 9/12/20 5:22 AM, Rainer Hurling wrote:
>>>> Since r365488 (and above until recent) my box breaks with the following
>>>> error when starting:
>>>>
>>>> Fatal trap 12: page fault while in kernel mode
>>>> cpuid = 31; apic id = 1f
>>>> fault virtual address   = 0x0
>>>> fault code  = supervisor read data, page not present
>>>> instruction pointer = 0x20:0x808f452b
>>>> stack pointer   = 0x28:0x81711800
>>>> frame pointer   = 0x28:0x81711800
>>>> code segment    = base 0x0, limit 0xf, type 0x1b
>>>>   = DPL 0, pres 1, long 1, def32 0, gran 1
>>>> processor eflags    = interrupt enabled, resume, IOPL = 0
>>>> current process = 0 (swapper)
>>>> trap number = 12
>>>> panic: page fault
>>>> cpuid = 31
>>>> time = 1
>>>>
>>>>
>>>>
>>>> Some infos about the system, the page fault occurs:
>>>>
>>>> CPU: AMD Ryzen 9 3950X 16-Core Processor (3493.50-MHz
>>>> K8-class CPU)
>>>>     Origin="AuthenticAMD"  Id=0x870f10  Family=0x17  Model=0x71 
>>>> Stepping=0
>>>> Features=0x178bfbff
>>>>
>>>> Features2=0x7ed8320b
>>>>
>>>>     AMD Features=0x2e500800
>>>>     AMD
>>>> Features2=0x75c237ff
>>>>
>>>>     Structured Extended
>>>> Features=0x219c91a9
>>>>
>>>>     Structured Extended Features2=0x44
>>>>     XSAVE Features=0xf
>>>>     AMD Extended Feature Extensions ID
>>>> EBX=0x108b657
>>>>     SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
>>>>     TSC: P-state invariant, performance statistics
>>>> real memory  = 68717379584 (65534 MB)
>>>> avail memory = 66756149248 (63663 MB)
>>>> Event timer "LAPIC" quality 600
>>>>
>>>>
>>>> #cat /etc/sysctl.conf
>>>> security.bsd.map_at_zero=1
>>>> kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules
>>>> kern.evdev.rcpt_mask=6
>>>> kern.maxfiles=49312
>>>> kern.ipc.shm_allow_removed=1
>>>> kern.ipc.maxsockbuf=16777216
>>>> vfs.usermount=1
>>>> net.inet.tcp.rfc1323=1
>>>> net.inet.tcp.sack.enable=1
>>>> net.inet.tcp.sendbuf_auto=1
>>>> net.inet.tcp.recvbuf_auto=1
>>>> net.inet.tcp.sendbuf_max=16777216
>>>> net.inet.tcp.recvbuf_max=16777216
>>>> net.inet6.ip6.use_tempaddr=1
>>>> net.inet6.ip6.prefer_tempaddr=1
>>>> net.local.stream.recvspace=65536
>>>> net.local.stream.sendspace=65536
>>>>
>>>>
>>>> Please let me know, if I should provide more info or test something.
>>>> Thanks in advance,
>>>> Rainer
>>>> ___
>>>> 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"

___
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: Fwd: Re: r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

Hi, 
I am AFK until Sunday, so can't investigate ATM. 
And no, I haven't solved it until now. Thanks for your report.
Rainer

Am 18. September 2020 00:38:31 MESZ schrieb monochrome 
:
>
>forgot you
>
> Forwarded Message 
>Subject: Re: r365488 page faults on AMD Ryzen 9 3950X
>Date: Thu, 17 Sep 2020 17:03:49 -0400
>From: monochrome 
>To: freebsd-current@freebsd.org
>
>I am also having this problem. Have you resolved it? Mine is a Ryzen 5 2400G
>
>On 9/12/20 5:22 AM, Rainer Hurling wrote:
>> Since r365488 (and above until recent) my box breaks with the following
>> error when starting:
>> 
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 31; apic id = 1f
>> fault virtual address   = 0x0
>> fault code  = supervisor read data, page not present
>> instruction pointer = 0x20:0x808f452b
>> stack pointer   = 0x28:0x81711800
>> frame pointer   = 0x28:0x81711800
>> code segment= base 0x0, limit 0xf, type 0x1b
>>  = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags= interrupt enabled, resume, IOPL = 0
>> current process = 0 (swapper)
>> trap number = 12
>> panic: page fault
>> cpuid = 31
>> time = 1
>> 
>> 
>> 
>> Some infos about the system, the page fault occurs:
>> 
>> CPU: AMD Ryzen 9 3950X 16-Core Processor (3493.50-MHz
>> K8-class CPU)
>>Origin="AuthenticAMD"  Id=0x870f10  Family=0x17  Model=0x71  Stepping=0
>> Features=0x178bfbff
>> Features2=0x7ed8320b
>>AMD Features=0x2e500800
>>AMD
>> Features2=0x75c237ff
>>Structured Extended
>> Features=0x219c91a9
>>Structured Extended Features2=0x44
>>XSAVE Features=0xf
>>AMD Extended Feature Extensions ID
>> EBX=0x108b657
>>SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
>>TSC: P-state invariant, performance statistics
>> real memory  = 68717379584 (65534 MB)
>> avail memory = 66756149248 (63663 MB)
>> Event timer "LAPIC" quality 600
>> 
>> 
>> #cat /etc/sysctl.conf
>> security.bsd.map_at_zero=1
>> kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules
>> kern.evdev.rcpt_mask=6
>> kern.maxfiles=49312
>> kern.ipc.shm_allow_removed=1
>> kern.ipc.maxsockbuf=16777216
>> vfs.usermount=1
>> net.inet.tcp.rfc1323=1
>> net.inet.tcp.sack.enable=1
>> net.inet.tcp.sendbuf_auto=1
>> net.inet.tcp.recvbuf_auto=1
>> net.inet.tcp.sendbuf_max=16777216
>> net.inet.tcp.recvbuf_max=16777216
>> net.inet6.ip6.use_tempaddr=1
>> net.inet6.ip6.prefer_tempaddr=1
>> net.local.stream.recvspace=65536
>> net.local.stream.sendspace=65536
>> 
>> 
>> Please let me know, if I should provide more info or test something.
>> Thanks in advance,
>> Rainer
>> ___
>> 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"
___
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"

r365488 page faults on AMD Ryzen 9 3950X

[Rainer Hurling]

Since r365488 (and above until recent) my box breaks with the following
error when starting:

Fatal trap 12: page fault while in kernel mode
cpuid = 31; apic id = 1f
fault virtual address   = 0x0
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x808f452b
stack pointer   = 0x28:0x81711800
frame pointer   = 0x28:0x81711800
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (swapper)
trap number = 12
panic: page fault
cpuid = 31
time = 1



Some infos about the system, the page fault occurs:

CPU: AMD Ryzen 9 3950X 16-Core Processor (3493.50-MHz
K8-class CPU)
  Origin="AuthenticAMD"  Id=0x870f10  Family=0x17  Model=0x71  Stepping=0
Features=0x178bfbff
Features2=0x7ed8320b
  AMD Features=0x2e500800
  AMD
Features2=0x75c237ff
  Structured Extended
Features=0x219c91a9
  Structured Extended Features2=0x44
  XSAVE Features=0xf
  AMD Extended Feature Extensions ID
EBX=0x108b657
  SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
  TSC: P-state invariant, performance statistics
real memory  = 68717379584 (65534 MB)
avail memory = 66756149248 (63663 MB)
Event timer "LAPIC" quality 600


#cat /etc/sysctl.conf
security.bsd.map_at_zero=1
kern.module_path=/boot/kernel;/boot/modules;/usr/local/modules
kern.evdev.rcpt_mask=6
kern.maxfiles=49312
kern.ipc.shm_allow_removed=1
kern.ipc.maxsockbuf=16777216
vfs.usermount=1
net.inet.tcp.rfc1323=1
net.inet.tcp.sack.enable=1
net.inet.tcp.sendbuf_auto=1
net.inet.tcp.recvbuf_auto=1
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
net.inet6.ip6.use_tempaddr=1
net.inet6.ip6.prefer_tempaddr=1
net.local.stream.recvspace=65536
net.local.stream.sendspace=65536


Please let me know, if I should provide more info or test something.
Thanks in advance,
Rainer
___
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: "cp: /dev/null: Invalid argument"

[Rainer Hurling]

Am 12.09.20 um 11:05 schrieb Hartmann, O.:
> On Sat, 12 Sep 2020 10:03:18 +0200
> Michael Gmelin  wrote:
> 
>>> On 12. Sep 2020, at 09:55, Hartmann, O. 
>>> wrote:
>>>
>>> On Fri, 11 Sep 2020 07:18:33 -0600
>>> Alan Somers  wrote:
>>>   
> On Fri, Sep 11, 2020 at 1:57 AM O. Hartmann
>  wrote:
>
> On Thu, 10 Sep 2020 10:44:08 -0600
> Alan Somers  wrote:
>   
>> No, it's devfs.  I'll fix it.
>>
>> On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone 
>> wrote:   
>>> I'm curious: does this give a similar issue?
>>>
>>> touch /tmp/foo
>>> cp /tmp/foo /tmo/foo2
>>>
>>> I'm wondering if the issue is that copy_file_range isn't
>>> handling empty files, or if it's a devfs issue.
>>>
>>>
>>> On Thu, Sep 10, 2020 at 11:45 AM Michael Butler
>>>  wrote:

 It seems that SVN r365549 broke "cp /dev/null ..."

imb

 On 9/10/20 10:35 AM, Michael Butler wrote:
> Is anyone else seeing failures like this in building world
> and, in
> my
> case, cron jobs as well?
>
>
> Building
> /usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr
> --- all_subdir_sbin ---
> Building /usr/obj/usr/src/amd64.amd64/sbin/bsdlabel/bsdlabel
> --- all_subdir_stand ---
> --- zfsboot.ldr ---
> cp: /dev/null: Invalid argument
> *** [zfsboot.ldr] Error code 1
> make[5]: *** zfsboot.ldr removed
> --- all_subdir_kerberos5 ---
> Building
>>> /usr/obj/usr/src/amd64.amd64/kerberos5/usr.sbin/iprop-log/iprop-log
>>>   
> --- all_subdir_stand ---
>
> make[5]: stopped in /usr/src/stand/i386/zfsboot
> .ERROR_TARGET='zfsboot.ldr'
>   
>>>   
> .ERROR_META_FILE='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot/zfsboot.ldr.meta'
>   
>>>   
> .MAKE.LEVEL='5'
> MAKEFILE=''
> .MAKE.MODE='meta missing-filemon=yes missing-meta=yes
> silent=yes
>>> verbose'
> _ERROR_CMD='cp /dev/null zfsboot.ldr;'
> .CURDIR='/usr/src/stand/i386/zfsboot'
> .MAKE='make'
> .OBJDIR='/usr/obj/usr/src/amd64.amd64/stand/i386/zfsboot'
> .TARGETS='all'
> DESTDIR='/usr/obj/usr/src/amd64.amd64/tmp'
> LD_LIBRARY_PATH=''
> MACHINE='amd64'
> MACHINE_ARCH='amd64'
> MAKEOBJDIRPREFIX=''
> MAKESYSPATH='/usr/src/share/mk'
> MAKE_VERSION='20200902'
>
> ___
> 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"
>>>   
>> ___
>> 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"
>
> I still get this error on a couple of boxes, while others seem to
> buildworld
> fine. All boxes are at CURRENT revision 365625. It is a bit
> looking weird to
> me. Running now a make cleanworld/cleandir on the specific boxes
> and start building OS again.
>
> oh
>   

 I don't know why it's intermittent, but in any case this patch
 should fix it:
 https://reviews.freebsd.org/D26395
 -Alan  
>>>
>>> I checked on ALL CURRENT boxes. After "make cleanworld cleandir" (or
>>> just deleting usr/obj/) and starting a fresh build, those boxes
>>> with an newer kernel all fail at the very same point. We use
>>> META_MODE on some boxes, switched to WITHOUT_CLEAN these days and
>>> cleanded up on some systems therefore. That might be the reason why
>>> the problem occurs not consistently on all systems.
>>>
>>> When will the pacth be committed?
>>>   
>>
>> Alan already committed it:
>>
>> https://svnweb.freebsd.org/base?view=revision=365643
>>
>> -m
>>
>>> Thanks in advance,
>>>
>>> oh  
>> ___
>> 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"
> 
> Sources at:
> 
> At revision 365652.
> 
> Host is running kernel FreeBSD 13.0-CURRENT #20 r365382: Fri Sep 11
> 19:01:26 CEST 2020 amd64.
> 
> make -j4 buildworld buildkernel
> 
> quit with same error as shown below.
> 
> Is there anything that has to prepared 

Re: r349100: buildworld does not compile (ld: error: duplicate symbol: sse42_crc32c)

[Rainer Hurling]

Am 19.06.19 um 21:20 schrieb Bryan Drewery:
> On 6/19/19 11:05 AM, Bryan Drewery wrote:
>> On 6/19/19 11:02 AM, Bryan Drewery wrote:
>>> On 6/16/19 9:33 AM, Warner Losh wrote:
>>>> On Sun, Jun 16, 2019, 9:51 AM Rainer Hurling  wrote:
>>>>
>>>>> If I try to build world almost recent sources (r349100) on HEAD amd64
>>>>> (r348775), it stops with the following error:
>>>>>
>>>>>
>>>>> [..snip..]
>>>>> (cd /usr/src/tests/sys/kern &&  DEPENDFILE=.depend.libkern_crc32
>>>>> NO_SUBDIR=1 make -f /usr/src/tests/sys/kern/Makefile _RECURSING_PROGS=t
>>>>> PROG=libkern_crc32 )
>>>>> echo libkern_crc32: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc.a
>>>>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libprivateatf-c.a >>
>>>>> .depend.libkern_crc32
>>>>> cc -target x86_64-unknown-freebsd13.0
>>>>> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
>>>>> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe
>>>>> -DUSERSPACE_TESTING -MD  -MF.depend.libkern_crc32.libkern_crc32.o
>>>>> -MTlibkern_crc32.o -std=gnu99 -fstack-protector-strong -Wsystem-headers
>>>>> -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
>>>>> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
>>>>> -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body
>>>>> -Wno-string-plus-int -Wno-unused-const-variable
>>>>> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
>>>>> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
>>>>> -Wno-address-of-packed-member   -Qunused-arguments   -c
>>>>> /usr/src/tests/sys/kern/libkern_crc32.c -o libkern_crc32.o
>>>>> cc -target x86_64-unknown-freebsd13.0
>>>>> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
>>>>> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -DUSERSPACE_TESTING
>>>>> -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall
>>>>> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
>>>>> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
>>>>> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
>>>>> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
>>>>> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
>>>>> -Wno-unused-local-typedef -Wno-address-of-packed-member
>>>>> -Qunused-arguments -DUSERSPACE_TESTING-o libkern_crc32
>>>>> libkern_crc32.o  /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
>>>>> /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
>>>>> ld: error: duplicate symbol: sse42_crc32c
>>>>>>>> defined at crc32_sse42.c
>>>>>>>>/tmp/crc32_sse42-2988bd.o:(sse42_crc32c)
>>>>>>>> defined at crc32_sse42.c
>>>>>>>>/tmp/crc32_sse42-bcf3d2.o:(.text+0x3C0)
>>>>> cc: error: linker command failed with exit code 1 (use -v to see
>>>>> invocation)
>>>>> *** [libkern_crc32] Error code 1
>>>>> make[6]: stopped in /usr/src/tests/sys/kern
>>>>> 1 error
>>>>> make[6]: stopped in /usr/src/tests/sys/kern
>>>>> *** [libkern_crc32] Error code 2
>>>>>
>>>>>
>>>>> This happens with two older cpus, Intel (Core 17-4770) and AMD (Phenom
>>>>> II X6 1090T).
>>>>>
>>>>> Am I the only one, who observes this breakage? Thanks for any hint.
>>>>>
>>>>
>>>> Try adding -DWITHOUT_TESTS to buildworld...
>>>>
>>>> Warner
>>>>
>>>
>>> ~/git/freebsd2/tests/sys/kern # env|grep TEST
>>> MK_TESTS=no
>>>
>>>
>>> Doh. Turns out I've had TESTS disabled in some of my recent build tests
>>> / commits. This is likely my fault.
>>>
>>
>> Yup it is from my r349065.
>>
>> It's an ambiguity between LDADD. and my newly added
>> LDADD..
>>
>> LDADD.libkern_crc32+=   ${SRCTOP}/sys/libkern/x86/crc32_sse42.c
>>
>> So it's added in twice.
>>
>>
> 
> This should be fixed in r349202. Sorry for the trouble.
> 

Many thanks for this fix. It works fine for me on the box with Intel
Core 17-4770, but it fails on AMD Phenom II X6 1090T (both systems
mentioned in the initial mail):


[..

Re: r349100: buildworld does not compile (ld: error: duplicate symbol: sse42_crc32c)

[Rainer Hurling]

Am 16.06.19 um 18:33 schrieb Warner Losh:
> 
> 
> On Sun, Jun 16, 2019, 9:51 AM Rainer Hurling  <mailto:rhur...@gwdg.de>> wrote:
> 
> If I try to build world almost recent sources (r349100) on HEAD amd64
> (r348775), it stops with the following error:
> 
> 
> [..snip..]
> (cd /usr/src/tests/sys/kern &&  DEPENDFILE=.depend.libkern_crc32
> NO_SUBDIR=1 make -f /usr/src/tests/sys/kern/Makefile _RECURSING_PROGS=t
> PROG=libkern_crc32 )
> echo libkern_crc32: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc.a
> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libprivateatf-c.a >>
> .depend.libkern_crc32
> cc -target x86_64-unknown-freebsd13.0
> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe
> -DUSERSPACE_TESTING -MD  -MF.depend.libkern_crc32.libkern_crc32.o
> -MTlibkern_crc32.o -std=gnu99 -fstack-protector-strong -Wsystem-headers
> -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body
> -Wno-string-plus-int -Wno-unused-const-variable
> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
> -Wno-address-of-packed-member   -Qunused-arguments   -c
> /usr/src/tests/sys/kern/libkern_crc32.c -o libkern_crc32.o
> cc -target x86_64-unknown-freebsd13.0
> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp
> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -DUSERSPACE_TESTING
> -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall
> -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
> -Wno-unused-local-typedef -Wno-address-of-packed-member
> -Qunused-arguments -DUSERSPACE_TESTING    -o libkern_crc32
> libkern_crc32.o  /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
> /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
> ld: error: duplicate symbol: sse42_crc32c
> >>> defined at crc32_sse42.c
> >>>            /tmp/crc32_sse42-2988bd.o:(sse42_crc32c)
> >>> defined at crc32_sse42.c
> >>>            /tmp/crc32_sse42-bcf3d2.o:(.text+0x3C0)
> cc: error: linker command failed with exit code 1 (use -v to see
> invocation)
> *** [libkern_crc32] Error code 1
> make[6]: stopped in /usr/src/tests/sys/kern
> 1 error
> make[6]: stopped in /usr/src/tests/sys/kern
> *** [libkern_crc32] Error code 2
> 
> 
> This happens with two older cpus, Intel (Core 17-4770) and AMD (Phenom
> II X6 1090T).
> 
> Am I the only one, who observes this breakage? Thanks for any hint.
> 
> 
> Try adding -DWITHOUT_TESTS to buildworld...
> 
> Warner
> 
> 
> Regards,
> Rainer Hurling



Many thanks Warner,

With -DWITHOUT_TESTS buildworld was able to finish. Is it secure to also
install it now?

BTW, in Poudriere, the same breakage seems to happen.

Regards,
Rainer
___
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"

r349100: buildworld does not compile (ld: error: duplicate symbol: sse42_crc32c)

[Rainer Hurling]

If I try to build world almost recent sources (r349100) on HEAD amd64
(r348775), it stops with the following error:


[..snip..]
(cd /usr/src/tests/sys/kern &&  DEPENDFILE=.depend.libkern_crc32
NO_SUBDIR=1 make -f /usr/src/tests/sys/kern/Makefile _RECURSING_PROGS=t
PROG=libkern_crc32 )
echo libkern_crc32: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc.a
/usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libprivateatf-c.a >>
.depend.libkern_crc32
cc -target x86_64-unknown-freebsd13.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -O2 -pipe
-DUSERSPACE_TESTING -MD  -MF.depend.libkern_crc32.libkern_crc32.o
-MTlibkern_crc32.o -std=gnu99 -fstack-protector-strong -Wsystem-headers
-Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-uninitialized -Wno-pointer-sign -Wno-empty-body
-Wno-string-plus-int -Wno-unused-const-variable
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
-Wno-address-of-packed-member   -Qunused-arguments   -c
/usr/src/tests/sys/kern/libkern_crc32.c -o libkern_crc32.o
cc -target x86_64-unknown-freebsd13.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -DUSERSPACE_TESTING
-std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wno-uninitialized
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion
-Wno-unused-local-typedef -Wno-address-of-packed-member
-Qunused-arguments -DUSERSPACE_TESTING-o libkern_crc32
libkern_crc32.o  /usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
/usr/src/sys/libkern/x86/crc32_sse42.c -lprivateatf-c
ld: error: duplicate symbol: sse42_crc32c
>>> defined at crc32_sse42.c
>>>/tmp/crc32_sse42-2988bd.o:(sse42_crc32c)
>>> defined at crc32_sse42.c
>>>/tmp/crc32_sse42-bcf3d2.o:(.text+0x3C0)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [libkern_crc32] Error code 1
make[6]: stopped in /usr/src/tests/sys/kern
1 error
make[6]: stopped in /usr/src/tests/sys/kern
*** [libkern_crc32] Error code 2


This happens with two older cpus, Intel (Core 17-4770) and AMD (Phenom
II X6 1090T).

Am I the only one, who observes this breakage? Thanks for any hint.

Regards,
Rainer Hurling
___
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: r336921 broke booting on MBP 2017, EFIRT related

[Rainer Hurling]

Am 31.08.18 um 10:27 schrieb Konstantin Belousov:
> On Thu, Aug 30, 2018 at 10:12:33PM +0300, Konstantin Belousov wrote:
>> On Thu, Aug 30, 2018 at 12:22:36PM +0300, Yuri Pankov wrote:
>>> Sorry, I accidentally took the discussion off-list, where Konstantin 
>>> provided some more patches.  I'm attaching the one that finally worked 
>>> for me.  It also adds some diagnostic prints which require bootverbose 
>>> to be enabled.
>>
>> This patch requires some more work to make it committable.
>> Do not try to build it with efirt device in the kernel config,
>> only efirt.ko works, but it can be preloaded from loader.
> 
> A version of the patch which finishes items which I wanted
> to handle, is available both for review and for testing at
> https://reviews.freebsd.org/D16972 .
> 

I tried the patches from D16972 and it seems to work on a DELL Latitude
E6520. It now boots with OPTIONS EFIRT and without efi.rt.disabled=1.

Many 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: r336921 broke booting on MBP 2017, EFIRT related

[Rainer Hurling]

Am 29.08.18 um 16:12 schrieb Kyle Evans:
> On Wed, Aug 29, 2018 at 6:53 AM Yuri Pankov  wrote:
>>
>> Yuri Pankov wrote:
>>> Konstantin Belousov wrote:
>>>> On Wed, Aug 29, 2018 at 12:37:52PM +0300, Yuri Pankov wrote:
>>>>> Hi,
>>>>>
>>>>> I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
>>>>> 20180802) fail to boot on MBP 2017:
>>>>>
>>>>> kbd0 at kbdmux0
>>>>> netmap: loaded module
>>>>> nexus0
>>>>>
>>>>> Fatal trap 12: page fault while in kernel mode
>>>>> cpuid = 2: apic id = 02
>>>>> fault virtual address  = 0x74c64a50
>>>>> fault code = supervisor read data, page not present
>>>>> instruction pointer= 0x20: 0x7abece31
>>>>> stack pointer  = 0x28: 0x82b2f7c0
>>>>> frame pointer  = 0x28: 0x82b2f810
>>>>> code segment   = base 0x0, limit 0xf, type 0x1b
>>>>>  = DPL 0, pres 1, long 1, def32 0, gran 1
>>>>> processor eflags   = interrupt enabled, resume, IOPL = 0
>>>>> current process= 0 (swapper)
>>>>> [ thread pid 0 tid 10 ]
>>>>> Stopped at  0x7abece31:calll   *0x18(%rax)
>>>>> db>
>>>>>
>>>>> Sadly, there's no support for internal keyboard yet (it's connected via
>>>>> SPI), and external USB one stops working.
>>>>>
>>>>> A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
>>>>>
>>>>> Some questions here:
>>>>> - is this something that can/should be fixed?
>>>>> - can we print some "enabling EFIRT" message to the console to make
>>>>> guesses about the problem source a bit easier?
>>>>
>>>> It is not in 'enabling'.  Looking at the faulting VA, I believe that
>>>> it occurs inside the BIOS code.
>>>>
>>>> Disable efirt by removing the kernel option, then try to load the module
>>>> at runtime.  Does it still fault ?  Also, get the efi mem map for the
>>>> machine and look at which region the faulting address and the faulting
>>>> instruction belong.
>>>
>>> kldload'ing the efirt module gets the same fault.  Several top lines of
>>> backtrace:
>>>
>>> kernphys() at 0x7abece31
>>> efi_get_time() at efi_get_time+0xd9
>>> efirtc_probe() at efirtc_probe+0x17
>>
>> For the efi mem map, if I'm understanding it correctly, there's the
>> following:
>>
>> ...
>> BootServicesData 7421d000  0a8b UC WC WT WB
>> ...
>> RuntimeServicesCode 7ab9f000  0070 UC WC WT WB
>> ...
>>
> 
> Hi,
> 
> I guess this patch might do it:
> https://people.freebsd.org/~kevans/efi-bootmap.diff
> 
> Linux commit messages depict a tale in which they used to also only
> map RUNTIME entries, but they were effectively forced to back down on
> that because of buggy firmware that does exactly what you've described
> and they later reintroduced the restrictive mapping for i386-only
> where they'd not found such bugs.
> 
> Thanks,
> 
> Kyle Evans

Hi Kyle,

After Yuri had no success with the patches of kib, I tried your patch on
a DELL Latitude E6520 with BIOS version A21.

Kernel config file contains OPTIONS EFIRT, efi.rt.disabled is commented
out in /boot/loader.conf.

Unfortunately, it also does not work. My trap message is this:


[..snip..]
netmap: loaded module
kbd1 at kbdmux0
nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX
platforms 390.77  Tue Jul. 10 21:54:30 PDT 2018
nexus0

Fatal trap 12: page fault while in kernel mode
cpuid = 0: apic id = 00
fault virtual address  = 0xce09ee60
fault code = supervisor read data, page not present
instruction pointer= 0x20: 0xcf58334d
stack pointer  = 0x28: 0x83252920
frame pointer  = 0x28: 0x832529a0
code segment   = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags   = interrupt enabled, resume, IOPL = 0
current process= 0 (swapper)
trap number= 12
panic: page fault
cpuid = 0
time = 1
Uptime: 1s
Automatic reboot in 15 seconds ...


Regards,
Rainer Hurling
___
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: r336921 broke booting on MBP 2017, EFIRT related

[Rainer Hurling]

Am 29.08.18 um 15:25 schrieb Kyle Evans:
> On Wed, Aug 29, 2018 at 8:20 AM Rainer Hurling  wrote:
>>
>> Am 29.08.18 um 11:37 schrieb Yuri Pankov:
>>> Hi,
>>>
>>> I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
>>> 20180802) fail to boot on MBP 2017:
>>>
>>> kbd0 at kbdmux0
>>> netmap: loaded module
>>> nexus0
>>>
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 2: apic id = 02
>>> fault virtual address  = 0x74c64a50
>>> fault code = supervisor read data, page not present
>>> instruction pointer= 0x20: 0x7abece31
>>> stack pointer  = 0x28: 0x82b2f7c0
>>> frame pointer  = 0x28: 0x82b2f810
>>> code segment   = base 0x0, limit 0xf, type 0x1b
>>>= DPL 0, pres 1, long 1, def32 0, gran 1
>>> processor eflags   = interrupt enabled, resume, IOPL = 0
>>> current process= 0 (swapper)
>>> [ thread pid 0 tid 10 ]
>>> Stopped at  0x7abece31:calll   *0x18(%rax)
>>> db>
>>>
>>> Sadly, there's no support for internal keyboard yet (it's connected via
>>> SPI), and external USB one stops working.
>>>
>>> A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
>>>
>>> Some questions here:
>>> - is this something that can/should be fixed?
>>> - can we print some "enabling EFIRT" message to the console to make
>>>   guesses about the problem source a bit easier?
>>
>>
>> I have almost exactly the same trap on a DELL Latitude E6520 with ALPHA3.
> 
> Hmm... that's a good data point. I might have a nearby Dell on-hand
> with same firmware to reproduce with, then.
> 
>> Only _with_ 'OPTIONS EFIRT' enabled in the kernel _and_ deactivating it
>> via efi.rt.disabled=1 in /boot/loader.conf, it works for me.
>>
>> An oddity is, that the spelling of the loader tuneable has to be
>> efi.rt.disabled, not efi.rt_disabled (note the dot instead of an
>> underscore!). The one with the underscore, as mentioned in UPDATING,
>> does not work for me. Isn't this a typo somewhere in the code?
>>
> 
> The UPDATING entry was later amended to reflect the new spelling
> ("efi.rt.disabled")

Oops, I must have missed it. Thanks for the update.

> 
> Thanks,
> 
> Kyle Evans
> 

___
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: r336921 broke booting on MBP 2017, EFIRT related

[Rainer Hurling]

Am 29.08.18 um 11:37 schrieb Yuri Pankov:
> Hi,
> 
> I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
> 20180802) fail to boot on MBP 2017:
> 
> kbd0 at kbdmux0
> netmap: loaded module
> nexus0
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2: apic id = 02
> fault virtual address  = 0x74c64a50
> fault code = supervisor read data, page not present
> instruction pointer    = 0x20: 0x7abece31
> stack pointer  = 0x28: 0x82b2f7c0
> frame pointer  = 0x28: 0x82b2f810
> code segment   = base 0x0, limit 0xf, type 0x1b
>    = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags   = interrupt enabled, resume, IOPL = 0
> current process    = 0 (swapper)
> [ thread pid 0 tid 10 ]
> Stopped at  0x7abece31:    calll   *0x18(%rax)
> db>
> 
> Sadly, there's no support for internal keyboard yet (it's connected via
> SPI), and external USB one stops working.
> 
> A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
> 
> Some questions here:
> - is this something that can/should be fixed?
> - can we print some "enabling EFIRT" message to the console to make
>   guesses about the problem source a bit easier?


I have almost exactly the same trap on a DELL Latitude E6520 with ALPHA3.

Only _with_ 'OPTIONS EFIRT' enabled in the kernel _and_ deactivating it
via efi.rt.disabled=1 in /boot/loader.conf, it works for me.

An oddity is, that the spelling of the loader tuneable has to be
efi.rt.disabled, not efi.rt_disabled (note the dot instead of an
underscore!). The one with the underscore, as mentioned in UPDATING,
does not work for me. Isn't this a typo somewhere in the code?

Regards,
Rainer Hurling
___
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: pkg does not recognize correct kernel version

[Rainer Hurling]

Am 19.02.2018 um 21:24 schrieb Ronald Klop:
> On Mon, 19 Feb 2018 21:10:48 +0100, Rainer Hurling <rhur...@gwdg.de> wrote:
> 
>> Hi Ronald,
>>
>> Am 19.02.2018 um 20:27 schrieb Ronald Klop:
>>> I just did this.
>>>
>>> root@sjakie ~]# pkg upgrade
>>> Updating FreeBSD repository catalogue...
>>> Fetching meta.txz: 100%    944 B   0.9kB/s    00:01
>>> Fetching packagesite.txz: 100%    6 MiB   6.0MB/s    00:01
>>> Processing entries:   0%
>>> pkg: Newer FreeBSD version for package gnome-menus:
>>> - package: 1200058
>>> - running kernel: 1200056
>>> pkg: repository FreeBSD contains packages for wrong OS version:
>>> FreeBSD:12:amd64
>>> Processing entries: 100%
>>> Unable to update repository FreeBSD
>>> Error updating repositories!
>>>
>>> [root@sjakie ~]# uname -UK
>>> 1200058 1200058
>>>
>>> [root@sjakie ~]# uname -a
>>> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18
>>> 12:37:36 CET 2018  
>>> ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUGamd64
>>>
>>>
>>>
>>> So uname gives a different version than pkg detects.
>>>
>>> What is happening? pkg update -f gives the same result. -o
>>> OSVERSION=1200058 helps, but does not feel like the right solution.
>>>
>>> Regards,
>>> Ronald.
>>
>> Please try
>>
>> #sysctl kern.osreldate
>> kern.osreldate: 1200058
>>
>> HTH,
>> Rainer Hurling
> 
> 
> [root@sjakie ~]# sysctl kern.osreldate
> kern.osreldate: 1200058
> 
> Regards,
> Ronald.

On my kernel patchlevel 1200058 (r329446) I get:

#pkg update -f
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%944 B   0.9kB/s00:01
Fetching packagesite.txz: 100%6 MiB   1.2MB/s00:05
Processing entries: 100%
FreeBSD repository update completed. 28645 packages processed.
All repositories are up to date.


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

Re: pkg does not recognize correct kernel version

[Rainer Hurling]

Hi Ronald,

Am 19.02.2018 um 20:27 schrieb Ronald Klop:
> I just did this.
> 
> root@sjakie ~]# pkg upgrade
> Updating FreeBSD repository catalogue...
> Fetching meta.txz: 100%    944 B   0.9kB/s    00:01
> Fetching packagesite.txz: 100%    6 MiB   6.0MB/s    00:01
> Processing entries:   0%
> pkg: Newer FreeBSD version for package gnome-menus:
> - package: 1200058
> - running kernel: 1200056
> pkg: repository FreeBSD contains packages for wrong OS version:
> FreeBSD:12:amd64
> Processing entries: 100%
> Unable to update repository FreeBSD
> Error updating repositories!
> 
> [root@sjakie ~]# uname -UK
> 1200058 1200058
> 
> [root@sjakie ~]# uname -a
> FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18
> 12:37:36 CET 2018
> ronald@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG
>  
> amd64
> 
> 
> So uname gives a different version than pkg detects.
> 
> What is happening? pkg update -f gives the same result. -o
> OSVERSION=1200058 helps, but does not feel like the right solution.
> 
> Regards,
> Ronald.

Please try

#sysctl kern.osreldate
kern.osreldate: 1200058

HTH,
Rainer Hurling
___
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: devd in r329188M don't start

[Rainer Hurling]

Am 16.02.2018 um 07:17 schrieb Warner Losh:



On Thu, Feb 15, 2018 at 11:12 PM, Rainer Hurling <rhur...@gwdg.de 
<mailto:rhur...@gwdg.de>> wrote:


Am 13.02.2018 um 13:50 schrieb Hans Petter Selasky:

On 02/13/18 10:47, Jakob Alvermark wrote:

+1

My USB mouse was working fine before the switch to devmatch.
Now I have to 'kldload ums' manually.

Same for USB audio, snd_uaudio.ko was loaded by devd before.


Hi,

This is a known issue.

Can you try the attached patch?

Rebuild devmatch(8) and reinstall /etc/devd/devmatch.conf and
/etc/rc.d/devmatch only.

--HPS



Is there any chance to get this committed into base in the near future?


Yes.

Warner


Nice, 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: devd in r329188M don't start

[Rainer Hurling]

Am 13.02.2018 um 13:50 schrieb Hans Petter Selasky:

On 02/13/18 10:47, Jakob Alvermark wrote:

+1

My USB mouse was working fine before the switch to devmatch. Now I 
have to 'kldload ums' manually.


Same for USB audio, snd_uaudio.ko was loaded by devd before.



Hi,

This is a known issue.

Can you try the attached patch?

Rebuild devmatch(8) and reinstall /etc/devd/devmatch.conf and 
/etc/rc.d/devmatch only.


--HPS



Is there any chance to get this committed into base in the near future?

Thanks for any answer,
Rainer Hurling
___
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: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832

[Rainer Hurling]

Am 12.01.2018 um 00:03 schrieb Sean Bruno:
> https://reviews.freebsd.org/D13832  <--- test this update
> 
> I'd like to get some feedback from AMD cpu users on this update.  I've
> restructured and undone a few things that may have been keeping folks
> using this port from getting their runtime cpu microcode updates.
> 
> After installing the port, grab your microcode version via
> sysutils/x86info.  If you don't see an update, that only means there is
> no update available for your system.
> 
> x86info -a | grep Microcode
> 
> Run the microcode_update and repeat.  Check /var/log/messages for a
> notification that the code was updated.  You should be able to get
> something like the following for your system if it executed an update:
> 
> root@lab:/home/sbruno # x86info -a | grep "CPU Model"
> CPU Model (x86info's best guess): AMD FX Series Processor (OR-B2)
> 
> root@lab:/home/sbruno # x86info -a | grep Microcode
> Microcode patch level: 0x6000629
> 
> root@lab:/home/sbruno # /usr/local/etc/rc.d/microcode_update onestart
> Updating CPU Microcode...
> Done.
> 
> root@lab:/home/sbruno # x86info -a | grep Microcode
> Microcode patch level: 0x600063d
> 
> root@lab:/home/sbruno # grep microcode_update /var/log/messages
> Jan 10 16:52:26 lab microcode_update:
> /usr/local/share/cpucontrol/microcode_amd_fam15h.bin: updating cpu
> /dev/cpuctl0 to revision 0x600063d... done.
> 

Just for the record, for an older Phenom with dmesg:

CPU: AMD Phenom(tm) II X6 1090T Processor (3214.31-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x100fa0  Family=0x10  Model=0xa  Stepping=0
Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x802009<SSE3,MON,CX16,POPCNT>
  AMD
Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!>
  AMD
Features2=0x37ff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT>
  SVM: NP,NRIP,NAsids=64
  TSC: P-state invariant, performance statistics


#x86info -a | grep "CPU Model"
CPU Model (x86info's best guess): Phenom/Athlon/Sempron/Turion
(II)/Opteron (PH-E0)

#x86info -a | grep Microcode
Microcode patch level: 0x1bf

#/usr/local/etc/rc.d/microcode_update onestart
Updating CPU Microcode...
Done.

#x86info -a | grep Microcode
Microcode patch level: 0x1bf

#grep microcode_update /var/log/messages
---

So no recent update and no log messages, as expected ;)

Regards,
Rainer Hurling
___
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 /head/sys/amd64/amd64/genassym.c breaks buildkernel amd64 current

[Rainer Hurling]

Am 27.03.2017 um 13:07 schrieb Andriy Gapon:

On 03/27/2017 14:35, Rainer Hurling wrote:

Am 27.03.2017 um 10:31 schrieb Andriy Gapon:

On 03/26/2017 00:21, Manfred Antar wrote:

Recent change to genassym.c breaks building a current kernel:

--

stage 3.1: building everything

--
cd /usr/obj/usr/src/sys/pozo; COMPILER_VERSION=4  COMPILER_TYPE=clang
COMPILER_FREEBSD_VERSION=126 MAKEOBJDIRPREFIX=/usr/obj
MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac
CC="/usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0
--sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin"
CXX="/usr/local/bin/ccache c++  -target x86_64-unknown-freebsd12.0
--sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp
-target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp
-B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" LLVM_LINK=""  NM=nm
OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"  INSTALL="sh
/usr/src/tools/install.sh"
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr


   /sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make  -m
/usr/src/share/mk  KERNEL=kernel all -DNO_MODULES_OBJ

machine -> /usr/src/sys/amd64/include
x86 -> /usr/src/sys/x86/include
/usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0
--sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O2 -pipe
-fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys
-I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include
opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD
-MF.depend.genassym.o -MTgenassym.o -mcmodel=kernel -mno-red-zone -mno-mmx
-mno-sse -msoft-float -fno-asynchronous-unwind-tables -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
-Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9

   899:1999 /usr/src/sys/amd64/amd64/genassym.c

In file included from /usr/src/sys/amd64/amd64/genassym.c:47:
/usr/src/sys/sys/bus.h:730:10: fatal error: 'device_if.h' file not found
#include "device_if.h"
   ^
1 error generated.
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/sys/pozo
*** Error code 1

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

Stop.
make: stopped in /usr/src


cd /usr/obj/usr/src/sys/pozo ; make device_if.h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h

also bus_if.h is missing:
(pozo)5023}make
/usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I.
-I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -MD -MF.depend.genassym.o -MTgenassym.o
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -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
-Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999
/usr/src/sys/amd64/amd64/genassym.c
In file included from /usr/src/sys/amd64/amd64/genassym.c:47:
/usr/src/sys/sys/bus.h:731:10: fatal error: 'bus_if.h' file not found

so:
make bus_if.h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h
then the build works:

MAKE=make sh /usr/src/sys/conf/newvers.sh  pozo
--- vers.o ---
/usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing  -g -nostdinc  -I.
-I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
-fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs

Re: New /head/sys/amd64/amd64/genassym.c breaks buildkernel amd64 current

[Rainer Hurling]

Am 27.03.2017 um 10:31 schrieb Andriy Gapon:

On 03/26/2017 00:21, Manfred Antar wrote:

Recent change to genassym.c breaks building a current kernel:

--

stage 3.1: building everything

--
cd /usr/obj/usr/src/sys/pozo; COMPILER_VERSION=4  COMPILER_TYPE=clang  COMPILER_FREEBSD_VERSION=126 MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE= 
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin  GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font  GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac 
CC="/usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CXX="/usr/local/bin/ccache c++  
-target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -target x86_64-unknown-freebsd12.0 
--sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" LLVM_LINK=""  NM=nm 
OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"  INSTALL="sh /usr/src/tools/install.sh"  
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/us

r

  /sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make  -m 
/usr/src/share/mk  KERNEL=kernel all -DNO_MODULES_OBJ

machine -> /usr/src/sys/amd64/include
x86 -> /usr/src/sys/x86/include
/usr/local/bin/ccache cc -target x86_64-unknown-freebsd12.0 
--sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin -c -O2 -pipe 
-fno-strict-aliasing -g -nostdinc -I. -I/usr/src/sys 
-I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD 
-MF.depend.genassym.o -MTgenassym.o -mcmodel=kernel -mno-red-zone -mno-mmx 
-mno-sse -msoft-float -fno-asynchronous-unwind-tables -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 
-Wno-error-address-of-packed-member -mno-aes -mno-avx -std=iso

9

  899:1999 /usr/src/sys/amd64/amd64/genassym.c

In file included from /usr/src/sys/amd64/amd64/genassym.c:47:
/usr/src/sys/sys/bus.h:730:10: fatal error: 'device_if.h' file not found
#include "device_if.h"
  ^
1 error generated.
*** Error code 1

Stop.
make[2]: stopped in /usr/obj/usr/src/sys/pozo
*** Error code 1

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

Stop.
make: stopped in /usr/src


cd /usr/obj/usr/src/sys/pozo ; make device_if.h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h

also bus_if.h is missing:
(pozo)5023}make
/usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing -g -nostdinc -I. 
-I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer -MD -MF.depend.genassym.o -MTgenassym.o 
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float 
-fno-asynchronous-unwind-tables -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 -Wno-error-address-of-packed-member -mno-aes 
-mno-avx -std=iso9899:1999 /usr/src/sys/amd64/amd64/genassym.c
In file included from /usr/src/sys/amd64/amd64/genassym.c:47:
/usr/src/sys/sys/bus.h:731:10: fatal error: 'bus_if.h' file not found

so:
make bus_if.h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h
then the build works:

MAKE=make sh /usr/src/sys/conf/newvers.sh  pozo
--- vers.o ---
/usr/local/bin/ccache cc -c -O2 -pipe -fno-strict-aliasing  -g -nostdinc  -I. 
-I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h  -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse 
-msoft-float  -fno-asynchronous-unwind-tables -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 

Re: HEAD does not build bwn (after r297405 ?)

[Rainer Hurling]

Am 30.03.16 um 13:08 schrieb Jia-Shiun Li:

On Wed, Mar 30, 2016 at 2:06 PM, Rainer Hurling <rhur...@gwdg.de
<mailto:rhur...@gwdg.de>> wrote:

If I try to build most recent HEAD (r297407), I get the following error:

I suspect r297405 with its migration of time_* macros to be the reason?


Adrian Chadd fixed that in r297409.


Thanks for the info. I already noticed it and rebuild my box. Works fine 
so far.




-Jia-Shiun.



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

HEAD does not build bwn (after r297405 ?)

[Rainer Hurling]

If I try to build most recent HEAD (r297407), I get the following error:


[..snip..]
===> bwn (all)
machine -> /usr/src/sys/amd64/include
x86 -> /usr/src/sys/x86/include
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/device_if.m -h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/kern/bus_if.m -h
awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/pci/pci_if.m -h
/usr/local/bin/ccache cc  -O2 -pipe  -fno-strict-aliasing -Werror 
-D_KERNEL -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include 
/usr/obj/usr/src/sys/RHURLIN/opt_global.h -I. -I/usr/src/sys -fno-common 
 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-I/usr/obj/usr/src/sys/RHURLIN  -MD  -MF.depend.if_bwn.o -MTif_bwn.o 
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float 
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector 
-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__ 
-Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas 
-Wno-error-tautological-compare -Wno-error-empty-body 
-Wno-error-parentheses-equality -Wno-error-unused-function 
-Wno-error-pointer-sign -Wno-error-shift-negative-value 
-Wno-error-sometimes-uninitialized -mno-aes -mno-avx  -std=iso9899:1999 
-c /usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c -o if_bwn.o
/usr/src/sys/modules/bwn/../../dev/bwn/if_bwn.c:2615:7: error: implicit 
declaration of function 'time_before' is invalid in C99 
[-Werror,-Wimplicit-function-declaration]

if (time_before(lo->pwr_vec_read_time, expire)) {
^
1 error generated.
*** Error code 1
Stop.
make[4]: stopped in /usr/src/sys/modules/bwn
*** Error code 1



I suspect r297405 with its migration of time_* macros to be the reason?

Regards,
Rainer Hurling
___
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: mounting CIFS share (tcp/445) with FreeBSD and mount_smbfs(8)

[Rainer Hurling]

Hi Oliver,

Am 02.03.16 um 15:29 schrieb O. Hartmann:

On Tue, 1 Mar 2016 23:39:22 +0200
"Reko Turja"  wrote:


-Original Message-
From: O. Hartmann
Subject: mounting CIFS share (tcp/455) with FreeBSD and mount_smbfs(8)


I need to mount a CIFS share from windows server 2012 r2 via CIFS, tcp/445
as NetBIOS service (tcp/139) has been deprecated due to serious
vulnerability issues. .
.
.
I desperately need CIFS and I need tcp/445 since tcp/139 is from now on
firewalled.


There's actually alternative available that's far more UNIX-friendly and not
depending on the SAMBA foibles.

https://technet.microsoft.com/en-us/library/jj574143.aspx?f=255=-2147217396

Of course, you need to have admin access to the server or get the admins
enable NFS on it.

-Reko

(I've used the Windows NFS the other way around- FreeBSD NFS shares mounted
with on Win7.) ___
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"


Using others than CIFS is impossible, I'm dependend on existing services.
Within the next forseable time port tcp/139 gets firewalled.

So far I have compiled NETSMB, SMBFS, LIBMCHAIN and LIBICONV (I think the
latter two are prerequests for NETSMB/SMBFS, didn't find much in the very
sparse and unfinished docs for that subject!) into the kernel.

I found this following the exact subject I ran into:

http://agreif.blogspot.de/2014/01/blog-post.html

It doesn't work with either SAMBA 4.3 or Windows Server 2012 R2. Consider the
following situation.

Windows/samba server has IP 10.0.0.1, it's WINS name is locus, its domain is
ASUF the user is pimmel. The passowrd is in /etc/nsmb.conf,
hashed:


[default]
charsets=utf-8:utf-8

[LOCUS:PIMMEL]
address=10.0.0.1
password=$$ajdhasuih57

The, following the above instructions, the mount_smbfs(8) command would be

mount_smbfs -I10.0.0.1 -Wasuf -N //pimmel@10.0.0.1:445/share /mnt

If -W is fed with ASUF (all uppercase), I get a strange error:

mount_smbfs: invalid local charset specification (IT4)

Connecting to the SAMBA 4.3 server, and with -Wasuf, I get

mount_smbfs: unable to open connection: syserr = RPC struct is bad

Connectingto the Windows 2012 R2 server results in

mount_smbfs: unable to open connection: syserr = Connection reset by peer

First, the manpage for mount_smbfs(8) is everything else than FreeBSD standard!
There is an unexplained option "-n opt". What is that?

Second, CIFS over tcp/445 seems to be now very(!) common in the Windooze world
- why is that fact not reflected by FreeBSD? I tried to find some
explanations/manpages for "man netsmb" or "smbfs" (the kernel options), but
none found :-(

My interpretation of the above errors are: FreeBSD is incapable to handle CIFS
over tcp/445. The above URL/site claims to have solved the problem, but it
seems not true for CURRENT.


For me, the described scenario works well with base smbfs (on recent 
HEAD amd64). My configuration differs in some way from yours.


GROUPNAME, SERVERNAME, and USERNAME should be written in capital letters 
(?), domainname\\username in small letters (?):



# ---
#cat /etc/nsmb.conf
...
[default]
workgroup=GROUPNAME

[SERVERNAME]
nbns=xxx.xxx.xxx.xxx  (IPv4 address)
charsets=UTF-8:CP866
addr=servername.xxx.de

[SERVERNAME:USERNAME]
username=domainname\\username
password=HASHED_PASSWORD


# ---
My entries in /etc/fstab look like this:
...
### Mountpoints for mount_smbfs (of base system)
//username@servername/dir   /SMB/DIRsmbfs   rw,late 0   0

[and this also works with port 445:]
//username@servername:445/dir   /SMB/DIRsmbfs   rw,late 0   0


# ---
!!! If this was a real hashed password in your mail above, you should 
change it ...


HTH and greetings,
Rainer

___
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

[Rainer Hurling]

Am 25.11.15 um 20:37 schrieb Bryan Drewery:
> On 11/25/2015 11:34 AM, Rainer Hurling wrote:
>> Am 25.11.15 um 19:50 schrieb Bryan Drewery:
>>> On 11/25/2015 10:09 AM, Juan Molina wrote:
>>>>> On 11/24/2015 1:31 AM, M - Krasznai András wrote:
>>>>>> /What can I do to eliminate the ccache error during installworld
>>>>> apart from not using ccache? /
>>>>> I would recommend not setting CC or CCACHE_PATH in make.conf and using
>>>>> the new WITH_CCACHE_BUILD=yes option instead.
>>>>>
>>>>> -- 
>>>>> Regards,
>>>>> Bryan Drewery
>>>>
>>>> Hi.
>>>>
>>>> I’m seeing the same ccache errors and I do not have CC or CCACHE_PATH
>>>> defined anywhere. Only WITH_CCACHE_BUILD and WITH_FAST_DEPEND in src.conf.
>>>>
>>>
>>> WITH_FAST_DEPEND is not related.
>>>
>>> Are you building and installing as a different user? Using a different
>>> MAKEOBJDIRPREFIX in build and install?
>>>
>>> Do you have CCACHE_PATH in your environment?
>>>
>>> Run 'make ccache-print-options|grep path'. It should have no value.
>>>
>>
>> Is there any possibility to redirect the .ccache directory, something
>> like CCACHE_PATH for userland?
>>
>> I am asking, because in my attempts to build base with WITH_CCACHE_BUILD
>> and WITH_FAST_DEPEND enabled, it breaks with error message 'file system
>> full'. My root partition has only 1GB and ccache itself seems to need
>> more than 800MB in /root/.ccache.
>>
> 
> You want to modify CCACHE_DIR. You can do this in make.conf or the
> environment.
> 
> I tend to just symlink /root/.ccache to somewhere else though and let
> the default work via the symlink.
> 
> Also see 'man src.conf' (WITH_CCACHE_BUILD section) and 'man ccache'.
> 

Oops, I should have looked into man src.conf before asking here, sorry.

And many thanks for the quick and helpful answer.
___
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

[Rainer Hurling]

Am 25.11.15 um 19:50 schrieb Bryan Drewery:
> On 11/25/2015 10:09 AM, Juan Molina wrote:
>>> On 11/24/2015 1:31 AM, M - Krasznai András wrote:
>>>> /What can I do to eliminate the ccache error during installworld
>>> apart from not using ccache? /
>>> I would recommend not setting CC or CCACHE_PATH in make.conf and using
>>> the new WITH_CCACHE_BUILD=yes option instead.
>>>
>>> -- 
>>> Regards,
>>> Bryan Drewery
>>
>> Hi.
>>
>> I’m seeing the same ccache errors and I do not have CC or CCACHE_PATH
>> defined anywhere. Only WITH_CCACHE_BUILD and WITH_FAST_DEPEND in src.conf.
>>
> 
> WITH_FAST_DEPEND is not related.
> 
> Are you building and installing as a different user? Using a different
> MAKEOBJDIRPREFIX in build and install?
> 
> Do you have CCACHE_PATH in your environment?
> 
> Run 'make ccache-print-options|grep path'. It should have no value.
> 

Is there any possibility to redirect the .ccache directory, something
like CCACHE_PATH for userland?

I am asking, because in my attempts to build base with WITH_CCACHE_BUILD
and WITH_FAST_DEPEND enabled, it breaks with error message 'file system
full'. My root partition has only 1GB and ccache itself seems to need
more than 800MB in /root/.ccache.

Thanks in advance,
Rainer Hurling

___
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: Error building x11/nvidia-driver kernel module @r284408

[Rainer Hurling]

Am 15.06.2015 um 22:07 schrieb David Wolfskill:
 On Mon, Jun 15, 2015 at 11:33:47AM -0700, Simon J. Gerraty wrote:
 Garrett Cooper yaneurab...@gmail.com wrote:
 Now that vanilla head @284408 builds ( boots):


 I fixed this the other day - just realized I haven't committed it.

 make[6]: don't know how to make 
 /common/S3/obj/usr/src/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-346.47/src/machine.
  Stop

 
 OK; following up: I see Simon committed r284420; after hand-appling that
 (1-line fix); I performed:
 
 make -DNOCLEAN -j16 buildkernel
 make installkernel
 ... [mergemaster c...]
 make installworld
 ...
 make delete-old
 
 for each of head/amd64  head/i386 on my laptop; since /etc/src.conf is:
 
 KERNCONF=CANARY
 PORTS_MODULES=x11/nvidia-driver
 PORTS_MODULES+=multimedia/cuse4bsd-kmod
 PORTS_MODULES+=emulators/virtualbox-ose-kmod
 WITHOUT_DEBUG_FILES=1
 IWN_DEBUG=1
 IEEE80211_DEBUG=1
 
 the above process also built kernel modules for x11/nvidia-driver,
 multimedia/cuse4bsd-kmod, and emulators/virtualbox-ose-kmod.
 
 Each was successful:
 
 FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #95  
 r284408M/284408:1100077: Mon Jun 15 06:09:41 PDT 2015 
 r...@g1-254.catwhisker.org:/common/S3/obj/usr/src/sys/CANARY  amd64
 
 FreeBSD localhost 11.0-CURRENT FreeBSD 11.0-CURRENT #30  
 r284408M/284408:1100077: Mon Jun 15 07:25:43 PDT 2015 
 r...@g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386
 
 Peace,
 david
 

I just tried r284421 and get another error. My '/etc/src.conf' includes
'WITH_LLDB=1':


[..snip..]
--- usr.bin.all__D ---
--- all_subdir_clang ---
--- all_subdir_lldb ---
c++: error: linker command failed with exit code 1 (use -v to see
invocation)
*** [lldb] Error code 1

make[5]: stopped in /usr/src/usr.bin/clang/lldb
.CURDIR='/usr/src/usr.bin/clang/lldb'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/usr.bin/clang/lldb'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/tmp'
LD_LIBRARY_PATH='/usr/local/grass/lib'
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH=''
MAKE_VERSION='20150606'
SRCTOP='/usr/src'
OBJTOP=''
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/bsd.mkopt.mk
/etc/make.conf /usr/src/share/mk/local.sys.mk
/usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/share/mk/bsd.cpu.mk
/usr/src/usr.bin/clang/lldb/Makefile /usr/src/share/mk/bsd.own.mk
/usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.compiler.mk
/usr/src/usr.bin/clang/clang.prog.mk /usr/src/lib/clang/clang.build.mk
/usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.prog.mk
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk
/usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk
/usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.files.mk
/usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk
/usr/src/share/mk/bsd.man.mk /usr/src/share/mk/bsd.dep.mk
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk
/usr/src/share/mk/bsd.sys.mk /usr/obj/usr/src/usr.bin/clang/lldb/.depend'
.PATH='. /usr/src/usr.bin/clang/lldb
/usr/src/usr.bin/clang/lldb/../../../contrib/llvm/tools/lldb/tools/driver'
1 error

make[5]: stopped in /usr/src/usr.bin/clang/lldb
.CURDIR='/usr/src/usr.bin/clang/lldb'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/usr.bin/clang/lldb'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/tmp'
LD_LIBRARY_PATH='/usr/local/grass/lib'
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH=''
MAKE_VERSION='20150606'
SRCTOP='/usr/src'
OBJTOP=''
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/bsd.mkopt.mk
/etc/make.conf /usr/src/share/mk/local.sys.mk
/usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/share/mk/bsd.cpu.mk
/usr/src/usr.bin/clang/lldb/Makefile /usr/src/share/mk/bsd.own.mk
/usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.compiler.mk
/usr/src/usr.bin/clang/clang.prog.mk /usr/src/lib/clang/clang.build.mk
/usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.prog.mk
/usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk
/usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk
/usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.files.mk
/usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk
/usr/src/share/mk/bsd.man.mk /usr/src/share/mk/bsd.dep.mk
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk
/usr/src/share/mk/bsd.sys.mk /usr/obj/usr/src/usr.bin/clang/lldb/.depend'
.PATH='. /usr/src/usr.bin/clang/lldb
/usr/src/usr.bin/clang/lldb/../../../contrib/llvm/tools/lldb/tools/driver'
*** [all_subdir_lldb] Error code 2

make[4]: stopped in /usr/src/usr.bin/clang
.CURDIR='/usr/src/usr.bin/clang'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/usr.bin/clang'
.TARGETS='all'
DESTDIR='/usr/obj/usr/src/tmp'
LD_LIBRARY_PATH='/usr/local/grass/lib'
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH=''
MAKE_VERSION='20150606'
SRCTOP='/usr/src'
OBJTOP=''
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/bsd.mkopt.mk
/etc/make.conf 

Upgrade to Unbound 1.5.1 incomplete?

[Rainer Hurling]

It seems, that r276605 is missing a file 'dnstap/dnstap_config.h'.

At least, I get this output, when I try to build world now:


--- depend_subdir_libunbound ---
In file included from
/usr/src/lib/libunbound/../../contrib/unbound/util/netevent.c:48:
/usr/src/lib/libunbound/../../contrib/unbound/dnstap/dnstap.h:38:10:
fatal error: 'dnstap/dnstap_config.h' file not found
#include dnstap/dnstap_config.h
 ^
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: pkg/ports system terribly messed up?

[Rainer Hurling]

Am 02.10.2014 um 04:40 schrieb Chuck Burns:
 On Wednesday, October 01, 2014 7:48:08 AM Rainer Hurling wrote:
 Am 01.10.2014 um 05:44 schrieb Chuck Burns:
 On Tuesday, September 30, 2014 8:13:01 AM O. Hartmann wrote:
 Hello.

 I just made the last update of the ports yesterday (I use 
 portmaster -da
 performing this task) and obviously or superficially everything 
 went all
 right.

 snip

 It's portmaster actually.  While it -usually- works great, I've noticed
 that occassionally it loops like that.

 kill the script, upgrade the port that is looping.

 Because it seems that I have the same problem as Oliver: What script 
 you
 are talking about?

 That usually fixes it.
 
 portmaster is just a (not-so-)simple shell script.  Kill portmaster (CTRL-C 
 a few times) then build the offending port with make  make 
 deinstall reinstall clean
 
Thanks for your answer. I tried it, but unfortunately, this does not
change my problems with using portmaster for updating ports.

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

Re: pkg/ports system terribly messed up?

[Rainer Hurling]

Am 01.10.2014 um 22:17 schrieb NGie Cooper:
 On Mon, Sep 29, 2014 at 11:13 PM, O. Hartmann
 ohart...@zedat.fu-berlin.de wrote:

 Hello.

 I just made the last update of the ports yesterday (I use portmaster -da 
 performing this
 task) and obviously or superficially everything went all right.

 I'm running on the boxes in question most recent CURRENT.

 On one system, a subsequent start of updating ports starts to freak out when 
 updateing
 lang/gcc: it loops over and over on some ports already updated, especially
 devel/binutils, but the port looping on isn't specific and varies.

 On every CURRENT box I tried this morning to update the ports again, I find 
 this
 frsutrating message (depends on installation, but it seems in principal the 
 same, only
 the affected ports in dependency chain varies):
 
 Are you using portmaster? If so, it might be fallout from r272282.
 Cheers,

Yup, after defining

setenv PORTSDIR /usr/ports

my problems, described on my mail in this thread from 30th September,
completely went away.

Thanks for this hint. It helps a lot!

Regards,
Rainer Hurling

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

Re: pkg/ports system terribly messed up?

[Rainer Hurling]

Am 01.10.2014 um 05:44 schrieb Chuck Burns:

On Tuesday, September 30, 2014 8:13:01 AM O. Hartmann wrote:

Hello.

I just made the last update of the ports yesterday (I use portmaster -da
performing this task) and obviously or superficially everything went all
right.



snip

It's portmaster actually.  While it -usually- works great, I've noticed that
occassionally it loops like that.

kill the script, upgrade the port that is looping.


Because it seems that I have the same problem as Oliver: What script you 
are talking about?




That usually fixes it.



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

Re: pkg/ports system terribly messed up?

[Rainer Hurling]

Am 30.09.2014 um 08:13 schrieb O. Hartmann:
 
 Hello.
 
 I just made the last update of the ports yesterday (I use portmaster -da 
 performing this
 task) and obviously or superficially everything went all right.
 
 I'm running on the boxes in question most recent CURRENT.
 
 On one system, a subsequent start of updating ports starts to freak out when 
 updateing
 lang/gcc: it loops over and over on some ports already updated, especially
 devel/binutils, but the port looping on isn't specific and varies.
 
 On every CURRENT box I tried this morning to update the ports again, I find 
 this
 frsutrating message (depends on installation, but it seems in principal the 
 same, only
 the affected ports in dependency chain varies):
 
  === Gathering distinfo list for installed ports
 
 === Starting check of installed ports for available updates
 === Launching child to update openldap-sasl-client-2.4.39_2 to
 openldap-sasl-client-2.4.40
 
 === All  openldap-sasl-client-2.4.39_2 (1/1)
 
 === Currently installed version: openldap-sasl-client-2.4.39_2
 === Port directory: /usr/ports/net/openldap24-sasl-client
 
 === Launching 'make checksum' for net/openldap24-sasl-client in background
 === Gathering dependency list for net/openldap24-sasl-client from ports
 === Launching child to install 
 net/openldap24-sasl-client/../../ports-mgmt/pkg
 
 === All  openldap-sasl-client-2.4.39_2 
 net/openldap24-sasl-client/../../ports-mgmt/pkg (2/2)
 
 === Port directory: 
 /usr/ports/net/openldap24-sasl-client/../../ports-mgmt/pkg
 
 
 === Update for net/openldap24-sasl-client/../../ports-mgmt/pkg failed
 === Aborting update
 
 === Update for openldap-sasl-client-2.4.39_2 failed
 === Aborting update
 
 You have new mail.
 
 
 This isn't, so far, OpenLDAP specific, on other systems without LDAP the 
 update fails on
 another port.
 
 Oliver
 

I am afraid I am observing something similar to what Oliver reported. On
a CURRENT box (r272295) I get the following for all ports execpt pkg itself:

portmaster indexinfo-0.2

=== Currently installed version: indexinfo-0.2
=== Port directory: /usr/ports/print/indexinfo

=== Gathering distinfo list for installed ports

=== Launching 'make checksum' for print/indexinfo in background
=== Gathering dependency list for print/indexinfo from ports
=== Launching child to install print/indexinfo/../../ports-mgmt/pkg

=== indexinfo-0.2  print/indexinfo/../../ports-mgmt/pkg (1/1)

=== Port directory: /usr/ports/print/indexinfo/../../ports-mgmt/pkg

=== Update for print/indexinfo/../../ports-mgmt/pkg failed
=== Aborting update


When I try to build other ports, it does not complain about
ports-mgmt/pkg, but something else in the dependency list. For example,
for net/mpich2 it complains about devel/binutils ...


This does not happen on my other CURRENT boxes (they build ports as
exected). All systems have pkg-1.3.8_2 installed. The main difference
between these boxes is, that the boxes without problems come from older
installations, which were converted via pkg2ng.

Only the box in question has all ports built and installed from scratch
after installing pkg, without any installations via pkg_* before.

As far as I can say, all went well until r369572. After svn'ing to a
more recent revision, I was not able to build ports any more ...

HTH,
Rainer Hurling

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

Re: freebsd and utf-8 directory names

[Rainer Hurling]

Am 30.06.2014 08:30 (UTC+1) schrieb MS - Krasznai András:
 Hi
 
 I have been using FreeBSD as desktop since 2003, and living in a mixed 
 (windows-linux) environment I installed FreeBSd along with my usual (Windows 
 7) work environment, I have a dualboot configured laptop. I use FreeBSD-10 
 STABLE.
 
 There is a partition formatted for FAT32 where I store documents which I 
 would like to view (and edit) both in  windows and freebsd.
 
 The problem is that if the path name contains certain Hungarian characters 
 (e.g o with double accent), then libreoffice in FreeBSD refuses to open them 
 complaining about illegal characters. The directory was created in windows, 
 the document also, and I can handle them perfectly from windows (what is 
 more, libreoffice under a linux can also open those documents). Some accented 
 characters are shown as a question mark in FreeBSD, and some others are as a 
 black rectangle; these latter are causing problems. If a file-nam contains 
 such characters then the file is shown as 0- length in Midnight Commander.
 
 I tried some steps described in the „Localization” part of the FreeBSD 
 Handbook, but things did not improve.
 
 I installed PC-BSD with Hungarian language support, thinking that it would 
 handle the localized directory names correctly but no, it gives the same 
 error message.
 
 This problem is really annoying. How could I solve it?

In my German environment I also use FAT32 formatted drives, mounted like:

/dev/adaXsX /XXXmsdosfs rw,large,-Lde_DE.UTF-8  0   0

This should also work for Hungarian?

HTH,
Rainer Hurling


 Krasznai András
 rendszermérnök
 MS Informatikai Zrt.
 1136 Budapest, Pannónia u. 17/A.
 Telefon: +36   1 703-2923
 Mobil:+36 30 703-2923
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: mounting ntfs partition from /etc/fstab

[Rainer Hurling]

Am 06.03.2014 08:35, schrieb MS - Krasznai András:
 Hi
 
 I am using freebsd 10 64bit on an IBM T510.
 
 I can not mount ntfs partition from /etc/fstab with the normal method, thatis 
 specifying
 
 /dev/ada0s2  /windows/C  ntfs-3g ro   0   
   0

For me it works with

/dev/ada0s2 /windows/C  ntfsro,mountprog=/usr/local/bin/ntfs-3g 
0   0

HTH,
Rainer

 
 in /etc/fstab
 
 the mount -a command gives me an error message:
 
 /dev/ada0s2:Operation not supported by the device
 
 
 but I can mount the same partition from the command line:
 
 ntfs-3g -o ro /dev/ada0s2  /windows/C
 
 works.
 
 
 What is the cause of this problem?
 
 Krasznai András
 rendszermérnök
 MS Informatikai Zrt.
 1136 Budapest, Pannónia u. 17/A.
 Telefon: +36   1 703-2923
 Mobil:+36 30 703-2923

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

Re: [CURRENT]: claws-mail and firefox fail with Invalid alignment

[Rainer Hurling]

Am 22.02.2014 10:03, schrieb Ranjan1018 .:
 The problem is still present in r262325. Verified with Firefox.

Just for the record. With r262334 the problem seems to be solved,
Firefox, Thunderbird etc. work again :-)

Thanks to davidxu@ for the quick fix.

Greetings,
Rainer Hurling


 2014-02-22 9:12 GMT+01:00 Alexandr shur...@shurik.kiev.ua:
 
 21.02.2014 20:03, O. Hartmann пишет:
 On Fri, 21 Feb 2014 19:00:13 +0100
 O. Hartmann ohart...@zedat.fu-berlin.de wrote:

 On Fri, 21 Feb 2014 18:49:13 +0100
 Dimitry Andric d...@freebsd.org wrote:

 On 21 Feb 2014, at 18:40, O. Hartmann ohart...@zedat.fu-berlin.de
 wrote:
 On every FreeBSD 11.0-CURRENT #0 r262294: Fri Feb 21 14:11:20 CET
 2014 amd64 I run neither claws-mail nor firfox run after the last
 buildworld. They fail both with the error

 Invalid alignment

 Does anyone see this problem too? I tried to recompile claws-mail
 and firefox, but without success (compilation succeeded, but the
 error stays).

 What happened here? How to solve?
 Can you try reverting r262277, rebuilding libexec/rtld-elf and
 reinstalling it, and seeing if that fixes it?

 -Dimitry

 Hello Dimitry,

 in r262277 there is no change in libexec/rtld-elf, I had to go back to
 r262270. I did as requested and reinstalling libexec/rtld-elf fixes
 the reported issue.

 Regards,
 Oliver
 Sorry, it is r262276


 I have the same issue with firefox and thunderbird. Reverting
 libexec/rtld-elf to r262276 solves a problem.
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 

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

Re: mouse pointer has gone.

[Rainer Hurling]

Am 16.01.2014 15:07, schrieb clutton:
 Using X, I have a frozen mouse pointer.
 Mouse works fine from syscons but not from X. Booting from kernel.old
 resolves the problem.
 
 Here is my X log with current kernel.
 
 158:[34.043] (==) NVIDIA(0): Silken mouse enabled
 208:[34.232] (II) config/hal: Adding input device PS/2 Mouse
 209:[34.232] (II) LoadModule: mouse
 210:[34.233] (II)
 Loading /usr/local/lib/xorg/modules/input/mouse_drv.so
 211:[34.236] (II) Module mouse: vendor=X.Org Foundation
 215:[34.237] (II) Using input driver 'mouse' for 'PS/2 Mouse'
 216:[34.237] (**) PS/2 Mouse: always reports core events
 218:[34.237] (==) PS/2 Mouse: Protocol: Auto
 219:[34.237] (**) PS/2 Mouse: always reports core events
 222:[34.238] (EE) PS/2 Mouse: cannot open input device
 223:[34.238] (EE) PreInit returned 2 for PS/2 Mouse
 224:[34.238] (II) UnloadModule: mouse
 
 
 And with kernel.old
 
 158:[30.743] (==) NVIDIA(0): Silken mouse enabled
 208:[30.941] (II) config/hal: Adding input device PS/2 Mouse
 209:[30.941] (II) LoadModule: mouse
 210:[30.942] (II)
 Loading /usr/local/lib/xorg/modules/input/mouse_drv.so
 211:[30.945] (II) Module mouse: vendor=X.Org Foundation
 215:[30.946] (II) Using input driver 'mouse' for 'PS/2 Mouse'
 216:[30.946] (**) PS/2 Mouse: always reports core events
 217:[30.946] (**) Option Device /dev/sysmouse
 218:[30.946] (==) PS/2 Mouse: Protocol: Auto
 219:[30.946] (**) PS/2 Mouse: always reports core events
 220:[30.947] (==) PS/2 Mouse: Emulate3Buttons, Emulate3Timeout: 50
 221:[30.947] (**) PS/2 Mouse: ZAxisMapping: buttons 4 and 5
 222:[30.947] (**) PS/2 Mouse: Buttons: 5
 224:[30.947] (II) XINPUT: Adding extended input device PS/2
 Mouse (type: MOUSE, id 7)
 225:[30.948] (**) PS/2 Mouse: (accel) keeping acceleration scheme 1
 226:[30.948] (**) PS/2 Mouse: (accel) acceleration profile 0
 227:[30.948] (**) PS/2 Mouse: (accel) acceleration factor: 2.000
 228:[30.948] (**) PS/2 Mouse: (accel) acceleration threshold: 4
 229:[30.948] (II) PS/2 Mouse: SetupAuto: hw.iftype is 4, hw.model is
 0
 230:[30.948] (II) PS/2 Mouse: SetupAuto: protocol is SysMouse
 

For me, it helped to rebuild devel/dbus and sysutils/hal and restart
that services again.

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

r259031 breaks build on CURRENT

[Rainer Hurling]

I just tried to build head (r259037) and it stops with the following
messages. This is on amd64 with systems clang. Please let me know, if I
should provide more info, thanks.


[..snip..]
=== usb/run (all)
cc  -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
-nostdinc   -DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/RHURLIN/opt_global.h -I. -I@ -I@/contrib/altq
-fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-I/usr/obj/usr/src/sys/RHURLIN  -mno-aes -mno-avx -mcmodel=kernel
-mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
-std=iso9899:1999 -Qunused-arguments -fstack-protector -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs
-fdiagnostics-show-option  -Wno-error-tautological-compare
-Wno-error-empty-body  -Wno-error-parentheses-equality  -c
/usr/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c
/usr/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:3233:6:
error: invalid application of 'sizeof' to an
  incomplete type 'struct rt2870_txwi'
sizeof(struct rt2870_txwi)), rt2860_rates[ridx].rate, qid);
^ 
@/dev/usb/usb_debug.h:41:21: note: expanded from macro 'DPRINTFN'
   __FUNCTION__ ,##__VA_ARGS__);\
   ^
/usr/src/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:3233:20:
note: forward declaration of
  'struct rt2870_txwi'
sizeof(struct rt2870_txwi)), rt2860_rates[ridx].rate, qid);
  ^
@/dev/usb/usb_debug.h:41:21: note: expanded from macro 'DPRINTFN'
   __FUNCTION__ ,##__VA_ARGS__);\
   ^
1 error generated.
*** Error code 1
Stop.
make[5]: stopped in /usr/src/sys/modules/usb/run
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: libc++ vs. libstdc++ usage in the ports tree

[Rainer Hurling]

Am 14.11.2013 10:54 (UTC+1) schrieb David Chisnall:
 On 13 Nov 2013, at 19:40, Dimitry Andric d...@freebsd.org wrote:
 
 On the other hand, different C++ standard libraries simply cannot be
 mixed.  The internal implementations are usually completely different.
 This is not really news at all, certainly not to the ports people. :-)
 
 That said, it should still be possible to mix them in different libraries.
 The constraint from the wiki still applies: if you don't use STL types at 
 library boundaries, then it should still work.  If you do, then the libc++ 
 and libstdc++ symbols will be mangled differently and so you will get 
 link-time errors.
 
 In theory, if it links it should run...
 
 David

With the in this thread described change of the behaviour in 10.x and
HEAD, I have massive problems with building my port math/saga. Before
the changes, all built and worked fine.

Now, even when I add

  USES=   compiler:openmp
  CXXFLAGS+=  -std=gnu++0x

and commenting out USE_GCC=any

in the Makefile of math/saga, the build breaks with problems between
x11-toolkits/wxgtk29 (build with clang) and math/saga (try to build with
gcc46), see below, please.

I am clueless, what to do here. Building x11-toolkits/wxgtk29 with
gcc46+ is not an option.

Any help is really appreciated,
Rainer Hurling


make -D MAKE_JOBS_UNSAFE=yes
===  Building for saga-2.1.0_2
--- all ---
/usr/bin/make  all-recursive
--- all-recursive ---
Making all in .
Making all in src
--- all-recursive ---
Making all in saga_core
--- all-recursive ---
Making all in saga_api
Making all in saga_odbc
Making all in saga_gdi
Making all in saga_cmd
--- all-recursive ---
Making all in man
Making all in saga_gui
--- all-recursive ---
Making all in man
--- saga_gui ---
/bin/sh ../../../libtool  --tag=CXX--mode=link g++46 -fPIC
-D_SAGA_LINUX -D_TYPEDEF_BYTE -D_TYPEDEF_WORD -D_SAGA_DONOTUSE_HARU
-DMODULE_LIBRARY_PATH=\/usr/local/lib/saga\
-DSHARE_PATH=\/usr/local/share/saga\  -I.. -I.
`/usr/local/bin/wxgtk2u-2.9-config --unicode=yes --cxxflags`
-D_SAGA_UNICODE -fopenmp  -O2 -pipe -I/usr/local/include
-Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -std=gnu++0x
-Wl,-rpath=/usr/local/lib/gcc46 -fPIC `/usr/local/bin/wxgtk2u-2.9-config
--unicode=yes --libs adv,aui,base,core,html,net,propgrid,xml`
-L/usr/local/lib -lopencv_core -pthread -Wl,-rpath=/usr/local/lib/gcc46
-o saga_gui active.o active_attributes.o  active_description.o
active_history.o  active_HTMLExtraInfo.o active_legend.o
active_parameters.o callback.o  data_source.o data_source_files.o
data_source_odbc.o dc_helper.o  dlg_about.o dlg_about_logo.o  dlg_base.o
dlg_colors.o  dlg_colors_control.o dlg_list_base.o  dlg_list_grid.o
dlg_list_pointcloud.o  dlg_list_shapes.o dlg_list_table.o
dlg_list_tin.o dlg_parameters.o  dlg_table.o dlg_text.o helper.o  info.o
info_messages.o  parameters_control.o parameters_properties.o  project.o
res_commands.o  res_controls.o res_dialogs.o  res_images.o saga.o
saga_frame.o  saga_frame_droptarget.o view_base.o  view_histogram.o
view_layout.o  view_layout_control.o view_layout_info.o
view_layout_printout.o view_map.o  view_map_3d.o view_map_3d_image.o
view_map_control.o view_ruler.o  view_scatterplot.o view_table.o
view_table_control.o view_table_diagram.o  wksp.o wksp_base_control.o
wksp_base_item.o wksp_base_manager.o  wksp_data_control.o
wksp_data_item.o  wksp_data_layers.o wksp_data_manager.o
wksp_data_menu_file.o wksp_data_menu_files.o  wksp_grid.o
wksp_grid_manager.o  wksp_grid_system.o wksp_layer.o
wksp_layer_classify.o wksp_layer_legend.o  wksp_map.o wksp_map_buttons.o
 wksp_map_control.o wksp_map_dc.o  wksp_map_layer.o wksp_map_manager.o
wksp_module.o wksp_module_control.o  wksp_module_library.o
wksp_module_manager.o  wksp_module_menu.o wksp_pointcloud.o
wksp_pointcloud_manager.o wksp_shapes.o  wksp_shapes_edit.o
wksp_shapes_line.o  wksp_shapes_manager.o wksp_shapes_point.o
wksp_shapes_points.o wksp_shapes_polygon.o  wksp_shapes_type.o
wksp_table.o  wksp_table_manager.o wksp_tin.o  wksp_tin_manager.o
../saga_api/libsaga_api.la ../saga_odbc/libsaga_odbc.la
libtool: link: g++46 -fPIC -D_SAGA_LINUX -D_TYPEDEF_BYTE -D_TYPEDEF_WORD
-D_SAGA_DONOTUSE_HARU -DMODULE_LIBRARY_PATH=\/usr/local/lib/saga\
-DSHARE_PATH=\/usr/local/share/saga\ -I.. -I.
-I/usr/local/lib/wx/include/gtk2-unicode-2.9 -I/usr/local/include/wx-2.9
-D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -D_THREAD_SAFE
-D_SAGA_UNICODE -fopenmp -O2 -pipe -I/usr/local/include
-Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -std=gnu++0x
-Wl,-rpath=/usr/local/lib/gcc46 -fPIC -pthread -pthread
-Wl,-rpath=/usr/local/lib/gcc46 -o .libs/saga_gui active.o
active_attributes.o active_description.o active_history.o
active_HTMLExtraInfo.o active_legend.o active_parameters.o callback.o
data_source.o data_source_files.o data_source_odbc.o dc_helper.o
dlg_about.o dlg_about_logo.o dlg_base.o dlg_colors.o
dlg_colors_control.o dlg_list_base.o dlg_list_grid.o
dlg_list_pointcloud.o dlg_list_shapes.o

latest sbin/pkg updates seem to break HEAD

[Rainer Hurling]

After svn update my 11.0-CURRENT box to r257152, the build breaks.
Obviously there is something wrong with the newest patches for sbin/pkg
(or libcrypt). Am I the only one observing this?

Any help is appreciated,
Rainer Hurling


[..snip..]
=== usr.sbin/pkg (all)
cc  -O2 -pipe  -I/usr/src/usr.sbin/pkg/../../contrib/libyaml/include
-std=gnu99 -Qunused-arguments -fstack-protector -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 -Wmissing-variable-declarations -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -c /usr/src/usr.sbin/pkg/pkg.c
cc  -O2 -pipe  -I/usr/src/usr.sbin/pkg/../../contrib/libyaml/include
-std=gnu99 -Qunused-arguments -fstack-protector -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 -Wmissing-variable-declarations -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -c /usr/src/usr.sbin/pkg/dns_utils.c
cc  -O2 -pipe  -I/usr/src/usr.sbin/pkg/../../contrib/libyaml/include
-std=gnu99 -Qunused-arguments -fstack-protector -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 -Wmissing-variable-declarations -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -c /usr/src/usr.sbin/pkg/config.c
cc  -O2 -pipe  -I/usr/src/usr.sbin/pkg/../../contrib/libyaml/include
-std=gnu99 -Qunused-arguments -fstack-protector -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 -Wmissing-variable-declarations -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int
-L/usr/obj/usr/src/tmp/usr/lib/private -rpath /usr/lib/private -o pkg
pkg.o dns_utils.o config.o -larchive -lelf -lfetch -lyaml -lsbuf -lssl

/usr/obj/usr/src/tmp/usr/bin/ld: D: invalid DSO for symbol
`EVP_PKEY_free' definition
/usr/obj/usr/src/tmp/lib/libcrypto.so.7: could not read symbols: Bad value
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1
Stop.
make[4]: stopped in /usr/src/usr.sbin/pkg
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: latest sbin/pkg updates seem to break HEAD

[Rainer Hurling]

Am 26.10.2013 13:04, schrieb Matthias Andree:
 Am 26.10.2013 12:56, schrieb Rainer Hurling:
 After svn update my 11.0-CURRENT box to r257152, the build breaks.
 Obviously there is something wrong with the newest patches for sbin/pkg
 (or libcrypt). Am I the only one observing this?

 Any help is appreciated,
 Rainer Hurling


 [..snip..]
 === usr.sbin/pkg (all)
 ...
 cc  -O2 -pipe  -I/usr/src/usr.sbin/pkg/../../contrib/libyaml/include
 -std=gnu99 -Qunused-arguments -fstack-protector -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 -Wmissing-variable-declarations -Wno-pointer-sign
 -Wno-empty-body -Wno-string-plus-int
 -L/usr/obj/usr/src/tmp/usr/lib/private -rpath /usr/lib/private -o pkg
 pkg.o dns_utils.o config.o -larchive -lelf -lfetch -lyaml -lsbuf -lssl

 /usr/obj/usr/src/tmp/usr/bin/ld: D: invalid DSO for symbol
 `EVP_PKEY_free' definition
 /usr/obj/usr/src/tmp/lib/libcrypto.so.7: could not read symbols: Bad value
 cc: error: linker command failed with exit code 1 (use -v to see invocation)
 *** Error code 1
 Stop.
 make[4]: stopped in /usr/src/usr.sbin/pkg
 
 These can happen if a library is missing, for instance, -lcrypto is
 apparently not mentioned on the linker's command line, but AFAIR the
 clang linker accepts no unresolved symbols from .so when linking
 executables, and -lssl likely needs -lcrypto.  This avoids run-time
 surprises due to missing dependencies (on libcrypto, in this case).
 
 Try pasting that command line with -lcrypto added after -lssl, and if
 that helps, try to debug where the -lcrypto has been or gets lost, or
 should get added.
 
 HTH

Yep, adding -lcrypto seems to help. I patched usr.sbin/pkg/Makefile for it.

But I am wondering if nobody else has this problem? I did not change my
systems sources before.

Many thanks for your fast reply and help,
Rainer



--- Makefile.orig   2013-10-26 08:33:50.0 +0200
+++ Makefile2013-10-26 14:26:06.0 +0200
@@ -7,7 +7,7 @@
 CFLAGS+=-I${.CURDIR}/../../contrib/libyaml/include
 .PATH: ${.CURDIR}/../../contrib/libyaml/include
 DPADD= ${LIBARCHIVE} ${LIBELF} ${LIBFETCH} ${LIBYAML} ${LIBSBUF}
-LDADD= -larchive -lelf -lfetch -lyaml -lsbuf -lssl
+LDADD= -larchive -lelf -lfetch -lyaml -lsbuf -lssl -lcrypto
 USEPRIVATELIB= yaml

 .include bsd.prog.mk

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

Re: AFFECTS: 10-CURRENT users with any port depending on converters/libiconv

[Rainer Hurling]

Am 07.09.2013 00:07, schrieb Baptiste Daroussin:
 On Fri, Sep 06, 2013 at 11:51:32PM +0200, O. Hartmann wrote:
 On Fri, 06 Sep 2013 21:11:26 +0400
 Boris Samorodov b...@passap.ru wrote:

 06.09.2013 20:44, O. Hartmann пишет:
 On Fri, 06 Sep 2013 20:08:59 +0400
 Boris Samorodov b...@passap.ru wrote:

 06.09.2013 19:44, O. Hartmann пишет:

 Here we go. It is the config.log from one of the failing machines,
 failing in print/cups-client.

 Please, show the output of following commands (at the host in
 question): # svn info /usr/ports/
 # svn svn st /usr/ports/print/cups*

 svn info /usr/ports/

 Path: /usr/ports
 Working Copy Root Path: /usr/ports
 URL: svn://svn.de.freebsd.org/ports/head
 Relative URL: ^/head
 Repository Root: svn://svn.de.freebsd.org/ports
 Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
 Revision: 326523
 Node Kind: directory
 Schedule: normal
 Last Changed Author: danfe
 Last Changed Rev: 326523
 Last Changed Date: 2013-09-06 18:22:29 +0200 (Fri, 06 Sep 2013)


 svn st /usr/ports/print/cups*
 ?   /usr/ports/print/cups-base/work
 ?   /usr/ports/print/cups-client/work

 That is really stange... Some more info:
 # svn st /usr/ports/Mk

 nothin (NULL output)

 # make -C /usr/ports/print/cups-client -V ICONV_LIB -V CONFIGURE_ARGS

 make -C /usr/ports/print/cups-client -V ICONV_LIB -V CONFIGURE_ARGS

 --localstatedir=/var
 --disable-slp
 --disable-gssapi--with-cups-user=cups
 --with-cups-group=cups   --with-system-groups=wheel
 --with-docdir=/usr/local/share/doc/cups
 --with-icondir=/usr/local/share/icons
 --with-menudir=/usr/local/share/applications
 --with-domainsocket=/var/run/cups.sock  --with-cachedir=/var/db/cups
 --with-pam-module=unix--enable-ssl
 --with-printcap=/usr/local/etc/printcap --disable-gnutls
 --enable-openssl --without-php --disable-dnssd --disable-pam
 --disable-ldap --disable-dbus --disable-libusb LIBS=-lssp_nonshared
 --prefix=/usr/local ${_LATE_CONFIGURE_ARGS}




 I see a lot of those obscure libtool errors not finding libiconv.la.
 Where the hell does the tool take those ecos from the past? I guess I
 have to reboot the box after X11 has been compiled

 
 Can you try to force rebuilding gettext first?

I can confirm that at least on my box after rebuilding gettext there are
no more of these 'not finding libiconv.la' errors.

For some reason gmake should be also rebuilded in an early stage. After
that, rebuilding libxml2 works fine.

 
 and then retry?
 
 regards,
 Bapt
 

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

Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[Rainer Hurling]

 = kmem_alloc_contig(kmem_arena, size, flags, 0,
  sc-dma_mask, PAGE_SIZE, 0, attr);
  if (!address) {
  status = ENOMEM;
 @@ -994,7 +994,7 @@
  os_flush_cpu_cache();
  
  if (at-pte_array[0].virtual_address != NULL) {
 -kmem_free(kernel_map,
 +kmem_free(kmem_arena,
  at-pte_array[0].virtual_address, at-size);
  malloc_type_freed(M_NVIDIA, at-size);
  }
 @@ -1021,7 +1021,7 @@
  if (at-attr != VM_MEMATTR_WRITE_BACK)
  os_flush_cpu_cache();
  
 -kmem_free(kernel_map, at-pte_array[0].virtual_address,
 +kmem_free(kmem_arena, at-pte_array[0].virtual_address,
  at-size);
  malloc_type_freed(M_NVIDIA, at-size);
  
 @@ -1085,7 +1085,7 @@
  }
  
  for (i = 0; i  count; i++) {
 -address = kmem_alloc_contig(kernel_map, PAGE_SIZE, flags, 0,
 +address = kmem_alloc_contig(kmem_arena, PAGE_SIZE, flags, 0,
  sc-dma_mask, PAGE_SIZE, 0, attr);
  if (!address) {
  status = ENOMEM;
 @@ -1139,7 +1139,7 @@
  for (i = 0; i  count; i++) {
  if (at-pte_array[i].virtual_address == 0)
  break;
 -kmem_free(kernel_map,
 +kmem_free(kmem_arena,
  at-pte_array[i].virtual_address, PAGE_SIZE);
  malloc_type_freed(M_NVIDIA, PAGE_SIZE);
  }
 @@ -1169,7 +1169,7 @@
  os_flush_cpu_cache();
  
  for (i = 0; i  count; i++) {
 -kmem_free(kernel_map,
 +kmem_free(kmem_arena,
  at-pte_array[i].virtual_address, PAGE_SIZE);
  malloc_type_freed(M_NVIDIA, PAGE_SIZE);
  }
 
 The primary differences are
 1) use kmem_arena instead of kernel_map everywhere.  The REINPLACE_CMD
uses kernel_arena
 2) DO NOT use kva_free, but kmem_free as previously
 
 To use the patch
 Delete or comment out the 4 lines starting at 160 in Makefile
 Run ``make patch''
 cd work/NVIDIA-FreeBSD-x86_64-319.32/src
 patch  [wherever the patch is]
 cd ../../..
 make deinstall install clean
 kldunload the old nvidia.ko
 kldload the new nvidia.ko
 start X
 

Yes, I can confirm, that it builds, installs and runs fine for me.

The patch should be placed as
x11/nvidia-driver/files/patch-src__nvidia_subr.c, shoudn't it?

Many thanks for this work.

Regards and a nice weekend,
Rainer Hurling

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

Re: Port problems after r253839 on HEAD

[Rainer Hurling]

Am 09.08.2013 19:27 UTC+2, schrieb Steve Kargl:
 On Wed, Aug 07, 2013 at 07:43:33PM +0200, Baptiste Daroussin wrote:
 On Wed, Aug 07, 2013 at 07:28:41PM +0200, Rainer Hurling wrote:
 After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c),
 I recognized some wired behaviour in the ports system on my CURRENT boxes.

 Some of the ports do not build anymore. They print almost similar
 messages about an ld problem (invalid DSO for symbol 'xxx' definition),
 followed by the lib, which symbols are not found.

 With a recent 10.0-CURRENT (at least r253839) you can try this for
 example with the following two ports:

 normally I had tracked down all those ports, except if you are building them
 with nom default options,

 What that means is basically the said ports are missing some -lbla in 
 ldflags,

 The missing ones are those listed in the line following the DSO bla
 in nano for example the first failure means -liconv is missing.

 I afk until 24th so I can't commit any fix to the said ports.
 There were properly building in my exp-run for the said change, meaning 
 either
 you build with non default options im that case the port requires a fix or
 perhaps your ports tree is not uptodate, in particular lots of those failures
 are fixed by the recent glib update.
 
 
 On a freshly rebuilt freebsd-current where I've deleted all ports
 to do a fresh build of everything I use, I see
 
 % portmaster news/pan
 ...
   CXXLD  pan
 /usr/bin/ld: ,: invalid DSO for symbol `libiconv_open' definition
 /usr/local/lib/libiconv.so.3: could not read symbols: Bad value
 c++: error: linker command failed with exit code 1 (use -v to see invocation)
 gmake[5]: *** [pan] Error 1
 gmake[5]: Leaving directory `/usr/ports/news/pan/work/pan-0.139/pan/gui'
 gmake[4]: *** [all-recursive] Error 1
 gmake[4]: Leaving directory `/usr/ports/news/pan/work/pan-0.139/pan'
 
 Please, fix.
 

If I understand bapt@ right, this should be all what is needed:


--- Makefile.orig   2013-06-20 17:48:12.0 +0200
+++ Makefile2013-08-09 20:56:36.0 +0200
@@ -15,7 +15,8 @@
 LICENSE=   GPLv2

 LIB_DEPENDS=   pcre:${PORTSDIR}/devel/pcre \
-   gmime-2.6:${PORTSDIR}/mail/gmime26
+   gmime-2.6:${PORTSDIR}/mail/gmime26 \
+   iconv:${PORTSDIR}/converters/libiconv

 USE_BZIP2= yes
 USE_GMAKE= yes
@@ -23,7 +24,7 @@
 USE_GNOME= intlhack
 GNU_CONFIGURE= yes
 CPPFLAGS+= -I${LOCALBASE}/include
-LDFLAGS+=  -L${LOCALBASE}/lib -lgnuregex
+LDFLAGS+=  -L${LOCALBASE}/lib -lgnuregex -liconv

 OPTIONS_DEFINE=GTKSPELL GTK3
 OPTIONS_DEFAULT=GTKSPELL


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

Re: Port problems after r253839 on HEAD

[Rainer Hurling]

Am 07.08.2013 21:01 (UTC+1) schrieb Rainer Hurling:
 Thanks, Bapt, for answering.
 
 Am 07.08.2013 19:43, schrieb Baptiste Daroussin:
 On Wed, Aug 07, 2013 at 07:28:41PM +0200, Rainer Hurling wrote:
 After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c),
 I recognized some wired behaviour in the ports system on my CURRENT boxes.

 Some of the ports do not build anymore. They print almost similar
 messages about an ld problem (invalid DSO for symbol 'xxx' definition),
 followed by the lib, which symbols are not found.

 With a recent 10.0-CURRENT (at least r253839) you can try this for
 example with the following two ports:

 normally I had tracked down all those ports, except if you are building them
 with nom default options,
 
 #cd /usr/ports/www/evolution-webcal
 #make config
 === No options to configure
 
 #cd /usr/ports/editors/nano
 #make config
 === No options to configure
 
 What that means is basically the said ports are missing some -lbla in 
 ldflags,

 The missing ones are those listed in the line following the DSO bla
 in nano for example the first failure means -liconv is missing.
 
 Yupp, thanks, the following two patches seem to work:
 
 --- Makefile.orig 2013-07-17 16:59:50.0 +0200
 +++ Makefile  2013-08-07 20:42:11.0 +0200
 @@ -15,11 +15,13 @@
 
  CONFLICTS=   nano-devel-2*
 
 +LIB_DEPENDS= tinfow:${PORTSDIR}/devel/ncurses
 +
  GNU_CONFIGURE=   yes
 
  CONFIGURE_ARGS=  --docdir=${DOCSDIR}
  CPPFLAGS+=   -I${LOCALBASE}/include
 -LDFLAGS+=-L${LOCALBASE}/lib
 +LDFLAGS+=-L${LOCALBASE}/lib -ltinfow
 
  .include bsd.port.options.mk
 
 
 
 --- Makefile.orig 2013-06-20 17:40:13.0 +0200
 +++ Makefile  2013-08-07 20:47:21.0 +0200
 @@ -23,7 +23,7 @@
  USE_GNOME=   gnomeprefix gnomehack intlhack evolutiondataserver libgnomeui
  GNU_CONFIGURE=   yes
  CPPFLAGS+=   -I${LOCALBASE}/include
 -LDFLAGS+=-L${LOCALBASE}/lib
 +LDFLAGS+=-L${LOCALBASE}/lib -lgthread-2.0
 
  GCONF_SCHEMAS=   evolution-webcal.schemas
 
 

 I afk until 24th so I can't commit any fix to the said ports.
 
 
 There were properly building in my exp-run for the said change, meaning 
 either
 you build with non default options im that case the port requires a fix or
 perhaps your ports tree is not uptodate, in particular lots of those failures
 are fixed by the recent glib update.
 
 Hmm. As far as I can say my ports tree is uptodate and I did the
 complete glib update (/usr/ports/UPDATING entry 20130731). So I have no
 clue, why editors/nano does complain about devel/ncurses.
 
 In particular I am wondering about the misbehaviour of my port
 math/saga. As I wrote before, the autotools process does not find
 libopencv.so, only and only if HEAD is using /usr/bin/ld r253839.
 Probably there is a hidden problem, not seen before without the ld
 patch? Any hint would be very appreciated.

Ok, after getting your hint about missing LDFLAGS I narrowed it down for
SAGA GIS 2.1.0. As complained in the config.log, conftest for autotools
is also missing one library. The following in math/saga should do the
trick (I will open a PR for it):

--- Makefile.orig   2013-07-31 18:09:58.0 +0200
+++ Makefile2013-08-08 11:11:15.0 +0200
@@ -47,7 +47,7 @@

 .include bsd.port.options.mk

-LDFLAGS+=  -L${LOCALBASE}/lib
+LDFLAGS+=  -L${LOCALBASE}/lib -lopencv_core
 CONFIGURE_ARGS+=   CFLAGS=${CFLAGS} LDFLAGS=${LDFLAGS}

 .if ${PORT_OPTIONS:MPYTHON}


So no problems left for me with new /usr/bin/ld :)
Thanks again for any help.

Greetings,
Rainer

 
 Many thanks for your fast help and greetings from Göttingen in Germany,
 Rainer

 regards,
 Bapt

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

Port problems after r253839 on HEAD

[Rainer Hurling]

After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c),
I recognized some wired behaviour in the ports system on my CURRENT boxes.

Some of the ports do not build anymore. They print almost similar
messages about an ld problem (invalid DSO for symbol 'xxx' definition),
followed by the lib, which symbols are not found.

With a recent 10.0-CURRENT (at least r253839) you can try this for
example with the following two ports:


(1) editors/nano
cc  -O2 -pipe -fno-strict-aliasing  -L/usr/local/lib -o nano browser.o
chars.o color.o  cut.o files.o global.o help.o  move.o nano.o prompt.o
rcfile.o search.o text.o  utils.o winio.o /usr/local/lib/libintl.so
/usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib -lncursesw
/usr/bin/ld: .: invalid DSO for symbol `keypad' definition
/usr/local/lib/libtinfow.so.5.9: could not read symbols: Bad value
cc: error: linker command failed with exit code 1 (use -v to see invocation)

(2) www/evolution-webcal
cc  -O2 -pipe -fno-strict-aliasing  -L/usr/local/lib -o evolution-webcal
evolution-webcal-main.o evolution-webcal-notify.o -lgtk-x11-2.0
-lgdk-x11-2.0 -lpangocairo-1.0 -lXext -lXrender -lXinerama -lXi -lXrandr
-lXcursor -lXcomposite -lXdamage -lXfixes -lX11 -latk-1.0 -lcairo
-lgdk_pixbuf-2.0 -lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig
-lecal-1.2 -lical -licalss -licalvcal -pthread -ledataserver-1.2 -lxml2
-lgconf-2 -lsoup-2.4 -lgio-2.0 -lgobject-2.0 -L/usr/local/lib -lglib-2.0
-lintl
/usr/bin/ld: R: invalid DSO for symbol `g_thread_init' definition
/usr/local/lib/libgthread-2.0.so.0: could not read symbols: Bad value
cc: error: linker command failed with exit code 1 (use -v to see invocation)


This errors disappear when I revert /usr/bin/ld to a revision before 253839.


Furthermore I observed some wired behaviour for SAGA GIS (math/saga; I
am the maintainer of it).
This port should build and install a SAGA GIS module as
/usr/local/lib/saga/libopencv.so (for this it has graphics/opencv as a
dependency).
With /usr/bin/ld rev. 253839 installed, the autotools configure process
from math/saga is not able to find /usr/local/lib/libopencv_legacy.so
and so it does not build the module. Unfortunately it gives no
clarifying hint about the problem).
Reverting the version of /usr/bin/ld before r253839 solves this problem ...


I hope my description is of some use and does not point in the wrong
direction.
Rainer Hurling
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Port problems after r253839 on HEAD

[Rainer Hurling]

Thanks, Bapt, for answering.

Am 07.08.2013 19:43, schrieb Baptiste Daroussin:
 On Wed, Aug 07, 2013 at 07:28:41PM +0200, Rainer Hurling wrote:
 After introducing r253839 on HEAD (/head/contrib/binutils/ld/ldmain.c),
 I recognized some wired behaviour in the ports system on my CURRENT boxes.

 Some of the ports do not build anymore. They print almost similar
 messages about an ld problem (invalid DSO for symbol 'xxx' definition),
 followed by the lib, which symbols are not found.

 With a recent 10.0-CURRENT (at least r253839) you can try this for
 example with the following two ports:

 normally I had tracked down all those ports, except if you are building them
 with nom default options,

#cd /usr/ports/www/evolution-webcal
#make config
=== No options to configure

#cd /usr/ports/editors/nano
#make config
=== No options to configure

 What that means is basically the said ports are missing some -lbla in ldflags,
 
 The missing ones are those listed in the line following the DSO bla
 in nano for example the first failure means -liconv is missing.

Yupp, thanks, the following two patches seem to work:

--- Makefile.orig   2013-07-17 16:59:50.0 +0200
+++ Makefile2013-08-07 20:42:11.0 +0200
@@ -15,11 +15,13 @@

 CONFLICTS= nano-devel-2*

+LIB_DEPENDS=   tinfow:${PORTSDIR}/devel/ncurses
+
 GNU_CONFIGURE= yes

 CONFIGURE_ARGS=--docdir=${DOCSDIR}
 CPPFLAGS+= -I${LOCALBASE}/include
-LDFLAGS+=  -L${LOCALBASE}/lib
+LDFLAGS+=  -L${LOCALBASE}/lib -ltinfow

 .include bsd.port.options.mk



--- Makefile.orig   2013-06-20 17:40:13.0 +0200
+++ Makefile2013-08-07 20:47:21.0 +0200
@@ -23,7 +23,7 @@
 USE_GNOME= gnomeprefix gnomehack intlhack evolutiondataserver libgnomeui
 GNU_CONFIGURE= yes
 CPPFLAGS+= -I${LOCALBASE}/include
-LDFLAGS+=  -L${LOCALBASE}/lib
+LDFLAGS+=  -L${LOCALBASE}/lib -lgthread-2.0

 GCONF_SCHEMAS= evolution-webcal.schemas


 
 I afk until 24th so I can't commit any fix to the said ports.


 There were properly building in my exp-run for the said change, meaning either
 you build with non default options im that case the port requires a fix or
 perhaps your ports tree is not uptodate, in particular lots of those failures
 are fixed by the recent glib update.

Hmm. As far as I can say my ports tree is uptodate and I did the
complete glib update (/usr/ports/UPDATING entry 20130731). So I have no
clue, why editors/nano does complain about devel/ncurses.

In particular I am wondering about the misbehaviour of my port
math/saga. As I wrote before, the autotools process does not find
libopencv.so, only and only if HEAD is using /usr/bin/ld r253839.
Probably there is a hidden problem, not seen before without the ld
patch? Any hint would be very appreciated.

Many thanks for your fast help and greetings from Göttingen in Germany,
Rainer
 
 regards,
 Bapt
 

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

Typo in /usr/src/UPDATING

[Rainer Hurling]

I am not a native speaker, but isn't there a typo in /usr/src/UPDATING
entry from 20130121?

--- UPDATING.orig   2013-05-09 09:46:55.0 +0200
+++ UPDATING2013-05-12 17:58:20.0 +0200
@@ -108,7 +108,7 @@
Due to the use of the new -l option to install(1) during build
and install, you must take care not to directly set the INSTALL
make variable in your /etc/make.conf, /etc/src.conf, or on the
-   command line.  If you with to use the -C flag for all installs
+   command line.  If you wish to use the -C flag for all installs
you may be able to add INSTALL+=-C to /etc/make.conf or
/etc/src.conf.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: kernel panic with _autoload_ nvidia driver

[Rainer Hurling]

On 05.05.2013 08:01 (UTC+2), de...@stasyan.com wrote:
   Hello !
 
   This problems appears about 4-6 months ago after updating of -CURRENT
 host.
 Unable to boot host with nvidia_load=YES in loader.conf because panic.
 But when nvidia driver loads manually via kldload, everything OK.
 Nvidia driver version is 310.44 at this moment, but problem was and on
 earlier version too.

As far as I can tell this is OK again with nvidia version 319.17.

This version is not in the ports yet, but you can try it by overwriting
the Makefiles version number ('make makesum' also adjusts the distfile
than).

HTH,
Rainer

 
 Here is output of debugging (full version at
 http://www.stasyan.com/devel/kern_crash_nvidia_autoload.txt)
 
 
 Loaded symbols for /boot/kernel/udf.ko.symbols
 #0  doadump (textdump=0) at pcpu.h:253
 253 __asm(movl %%fs:%1,%0 : =r (td)
 (kgdb) backtrace
 #0  doadump (textdump=0) at pcpu.h:253
 #1  0xc050a991 in db_dump (dummy=-1062503683, dummy2=0, dummy3=-1,
 dummy4=0xfad2c8b4 ) at /usr/src/sys/ddb/db_command.c:543
 #2  0xc050a487 in db_command (cmd_table=value optimized out) at
 /usr/src/sys/ddb/db_command.c:449
 #3  0xc050a1a0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502
 #4  0xc050c9e0 in db_trap (type=value optimized out, code=-86848816)
 at /usr/src/sys/ddb/db_main.c:231
 #5  0xc0ab8278 in kdb_trap (type=value optimized out, code=value
 optimized out, tf=value optimized out)
 at /usr/src/sys/kern/subr_kdb.c:654
 #6  0xc0e9f1ae in trap (frame=value optimized out) at
 /usr/src/sys/i386/i386/trap.c:720
 #7  0xc0e8835c in calltrap () at /usr/src/sys/i386/i386/exception.s:169
 #8  0xc0ab7afd in kdb_enter (why=0xc10786cb panic, msg=value
 optimized out) at cpufunc.h:71
 #9  0xc0a81503 in vpanic (fmt=value optimized out, ap=value optimized
 out) at /usr/src/sys/kern/kern_shutdown.c:747
 #10 0xc0a813ba in kassert_panic (fmt=value optimized out) at
 /usr/src/sys/kern/kern_shutdown.c:642
 #11 0xc0acfb55 in witness_warn (flags=value optimized out, lock=value
 optimized out) at /usr/src/sys/kern/subr_witness.c:1727
 #12 0xc0ac7d95 in userret (td=0xc866c000, frame=value optimized out)
 at /usr/src/sys/kern/subr_trap.c:151
 #13 0xc0e9fff1 in syscall (frame=value optimized out) at
 subr_syscall.c:178
 #14 0xc0e883f1 in Xint0x80_syscall () at
 /usr/src/sys/i386/i386/exception.s:267
 #15 0x0033 in ?? ()
 Previous frame inner to this frame (corrupt stack?)
 Current language:  auto; currently minimal
 

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

Re: kernel panic with _autoload_ nvidia driver

[Rainer Hurling]

On 05.05.2013 09:24 (UTC+2), de...@stasyan.com wrote:
 Hello !
   This problems appears about 4-6 months ago after updating of -CURRENT
 host.
 Unable to boot host with nvidia_load=YES in loader.conf because panic.
 But when nvidia driver loads manually via kldload, everything OK.
 Nvidia driver version is 310.44 at this moment, but problem was and on
 earlier version too.
 As far as I can tell this is OK again with nvidia version 319.17.
 I've got panic with nvidia-driver 319.17 too.
 

Do you know the workaround to build the port with

  'env USE_GCC=any make' ?

With this it should not panic anymore, but start normal again ...

Perhaps danfe@ as the maintainer has more ideas?

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

Re: Booting an alternative kernel from loader prompt fails the first time only

[Rainer Hurling]

On 21.04.2013 02:36 (UTC+2), Steven Hartland wrote:
 
 - Original Message - From: Joshua Isom jri...@gmail.com
 To: freebsd-current@freebsd.org
 Sent: Sunday, April 21, 2013 12:41 AM
 Subject: Re: Booting an alternative kernel from loader prompt fails the
 first time only
 
 
 On 4/20/2013 12:41 PM, Manfred Antar wrote:
 At 10:24 AM 4/20/2013, Rainer Hurling wrote:
 On 20.04.2013 18:47 (UTC+2), Florian Smeets wrote:
 On 20.04.13 18:05, Steven Hartland wrote:
 When trying to boot an alternative kernel from the loader prompt
 it fails the first time the command is run but succeeds the second
 time.

 Type '?' for a list of commands, 'help' for more detailed help.
 OK boot kernel.generic
 Booting...
 don't know how to load module '/boot/kernel.generic/kernel'
 OK boot kernel.generic
 Booting...
 /boot/kernel.generic/kernel text=0xd21288 data=..


 Yes, I've been seeing the same thing for about 6-12 months maybe more.
 None of the people I asked were able to confirm, so I'm happy that I'm
 not imagining it :)

 I also can confirm this behaviour for month now (on 10.0-CURRENT amd64
 with clang).

 Rainer


 Have you tried:
 OK boot /boot/kernel.generic/kernel

 Use full path name always works for me
 Manfred
 
 I believe this may well have been introduced by:-
 http://svnweb.freebsd.org/base?view=revisionrevision=241069
 
 When booting with a /boot/loader.conf that contains a module load line
 e.g. zfs_load=YES then this is loaded before the kernel.
 
 Loading any module causes last_file_format to get set so when the next
 file that's loaded is in fact a kernel it still try's to load it as a
 kernel module using what was stored with last_file_format.
 
 This fails and trips the Restart from the beginning case which contains:
   last_file_format = i = 0;
   fp = NULL;
   continue;
 
 So i gets set to 0 but the loop then increments it to 1 before running
 the next iteration, so its impossible to use first handler in the retry
 case; which I suspect is the kernel loader.
 
 This also explains why the second call to boot works as last_file_format
 is now 0 due to the previous failure.
 
 If this is the issue the attached patch should fix it. I can't test it
 ATM as my current box is at the office and doesn't have remote KVM, so
 I need to be in front of it.
 
 If anyone can confirm this attached patch fixes the problem then I'll get
 it committed, otherwise I'll test on Monday.

I tried your patch with recent 10.0-CURRENT amd64 (r249715, clang), and
it seems to work. I can set module path, load some modules, and
afterwards load a kernel in one call.

Thank you very much.

Best wishes,
Rainer

 
Regards
Steve

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

Re: Booting an alternative kernel from loader prompt fails the first time only

[Rainer Hurling]

On 20.04.2013 18:47 (UTC+2), Florian Smeets wrote:
 On 20.04.13 18:05, Steven Hartland wrote:
 When trying to boot an alternative kernel from the loader prompt
 it fails the first time the command is run but succeeds the second
 time.

 Type '?' for a list of commands, 'help' for more detailed help.
 OK boot kernel.generic
 Booting...
 don't know how to load module '/boot/kernel.generic/kernel'
 OK boot kernel.generic
 Booting...
 /boot/kernel.generic/kernel text=0xd21288 data=..

 
 Yes, I've been seeing the same thing for about 6-12 months maybe more.
 None of the people I asked were able to confirm, so I'm happy that I'm
 not imagining it :)

I also can confirm this behaviour for month now (on 10.0-CURRENT amd64
with clang).

Rainer

 
 I see this on serial as well as on the normal console in front of a PC.
 
 Florian
 

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

Re: CURRENT ( r249381): can't find boot partition on GPT disk

[Rainer Hurling]

On 13.04.2013 12:07 (UTC+2), Marcus Reid wrote:
 On Sat, Apr 13, 2013 at 09:14:10AM +0200, O. Hartmann wrote:
 Trying to boot a kernel  r249381 fails and I see on the console the
 loader prompt at mountroot. Obviously, the bootloader doesn't find
 the root/boot partition.
 
 Same problem observed here.  r249435, gpt zfs root.  Entering
 zfs:zroot at the mountroot prompt allows system to continue booting.

Same here without gtp and zfs, but with ufs. Seems to be solved for me
with r249436.

Rainer

 Marcus

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

Re: post SVN r238886 no boot?

[Rainer Hurling]

On 29.07.2012 19:40 (UTC+2), Michael Butler wrote:

Is anyone else having troubles getting -current after SVN r238886 to
boot? In my case, I have an unstoppable stream of pager_something
console messages :-(

imb


Yes, it's the same here. I had to revert to old kernel.

Rainer

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

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

Am 26.07.2012 03:52 (UTC+1) schrieb Bruce Evans:

On Wed, 25 Jul 2012, Rainer Hurling wrote:


On 25.07.2012 19:00 (UTC+2), Steve Kargl wrote:

On Wed, Jul 25, 2012 at 06:29:18PM +0200, Rainer Hurling wrote:


Many thanks to you three for implementing expl() with r238722 and
r238724.

I am not a C programmer, but would like to ask if the following example
is correct and suituable as a minimalistic test of this new C99
function?


It's not clear to me what you mean by test.  If expl() is
not available in libm, then linking the code would fail.
So, testing for the existence of expl() (for example,
in a configure script) is as simple as


Sorry for not being clear enough. I didn't mean testing for the
existence, but for some comparable output between exp() and expl(), on
a system with expl() available in libm.


This is basically what I do to test exp() (with a few billion cases
automatically generated and compared).  It is not sufficient for
checking expl(), except for consistency.  (It is assumed that expl()
is reasonably accurate.  If it is in fact less accurate than exp(),
this tends to show up in the comparisons.)


Ahh ok, I think I understand it better now.


#include math.h
long double
func(long double x)
{
   return (expl(x));
}


//---
#include stdio.h
#include math.h

int main(void)
{
   double c = 2.0;
   long double d = 2.0;

   double e = exp(c);
   long double f = expl(d);

   printf(exp(%f)  is %.*f\n,  c, 90, e);
   printf(expl(%Lf) is %.*Lf\n, d, 90, f);


If you mean testing that the output is correct, then
asking for 90 digits is of little use.  The following
is sufficient (and my actually produce a digit or two
more than is available in number)


Ok, I understand. I printed the 90 digits to be able to take a look at
the decimal places, I did not expect to get valid digits in this area.


Use binary format (%a) for manual comparison.  Don't print any more
bits than the format has.  This is DBL_MANT_DIG (53) for doubles and
LDLBL_MANT_DIG (64 on x86) for long doubles.  %a format is in nybbles
and tends to group the bits into nybbles badly.  See below on reducing
problems from this.  Decimal format has to print about 3 more digits
than are really meaningful, to allow recovering the original value
uniquely.  For manual comparison, you need to print these extra digits
and manually round or ignore them as appropriate.  The correct number
of extra digits is hard to determine.  For the any, type, it is
DECIMAL_DIG (21) on x86.  The corresponding number of normally-accurate
decimal digits for long doubles is given by LDBL_DIG (18).  For
floats and doubles, this corresponds to FLT_DIG (6) and DBL_DIG (15).
Unfortunately, float.h doesn't define anything corresponding to
DECIMAL_DIG for the smaller types.  21 is a lot of digits and noise
digits take a long time to determine and ignore (its worse on sparc64
where DECIMAL_DIG is 36).  I usually add 2 extra digits to the number
of normally-accurate digits.  This is sloppy.  3 is needed in some
cases, depending on MANT_DIG and the bits in log(2) and/or log(10).


I printed more bits (digits) than the format provides, because I wanted 
to see if and when what the new function would do in this 'outside' 
area. Of course you are right that this has nothing to do with more 
precision and these digits may not be used in subsequent calculations. 
But this really was not my intention here (only curiosity).



troutmask:fvwm:kargl[203] diff -u a.c.orig a.c
--- a.c.orig2012-07-25 09:38:31.0 -0700
+++ a.c 2012-07-25 09:40:36.0 -0700
@@ -1,5 +1,6 @@
  #include stdio.h
  #include math.h
+#include float.h

  int main(void)
  {
@@ -9,8 +10,8 @@
double e = exp(c);
long double f = expl(d);

-  printf(exp(%f)  is %.*f\n,  c, 90, e);
-  printf(expl(%Lf) is %.*Lf\n, d, 90, f);
+  printf(exp(%f)  is %.*f\n,  c, DBL_DIG+2, e);
+  printf(expl(%Lf) is %.*Lf\n, d, LDBL_DIG+2, f);

return 0;
  }


Thanks, I was not aware of DBL_DIG and LDBL_DIG.


Steve is sloppy and adds 2 also :-).  For long doubles, it is clear that
3 are strictly needed, since DECIMAL_DIG is 3 more.


So I better use +3 here?
printf(expl(%Lf) is %.*Lf\n, d, LDBL_DIG+3, f);
  ^^


For most long double functions on i386, you need to switch the rounding
precision to 64 bits around calls to them, and also to do any operations
on the results except printing them.  expl() is one of the few large
functions that does the switch internally.  So the above should work
(since it only prints), but (expl(d) + 0) should round to the default
53-bit precision and this give the same result as exp(d).


Now that this rounding problem is more understandable to me, I am happy 
that in most cases I can use math/R for my calculations ;-)



If you actually want to test expl() to see if it is producing
a decent result, you need a reference solution that contains
a higher precision.  I use mpfr with 256 bits of precision

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

On 11.07.2012 00:58 (UTC+2), David Schultz wrote:

On Tue, Jul 10, 2012, Rainer Hurling wrote:

On 10.07.2012 17:11 (UTC+2), David Schultz wrote:

On Tue, Jul 10, 2012, Rainer Hurling wrote:

On 10.07.2012 16:02 (UTC+2), Warner Losh wrote:


On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote:

As far as I understand from discussions on R mailing list
(r-de...@r-project.org), they plan to reduce the emulation and/or
workaround of long and complex math functions for FreeBSD and other
systems with their next releases of R devel. So we could really need
some
progress with our C99 conform math functions ;-)


Not having R would be a bit pain in my backside.  That's one of the
practical considerations that I was talking about.  It is very real, and
if I have to, I'll commit the #define junk I railed against to get it
back.  Please, let's get some progress.  I have some time to help.


Yes, thank you Warner, that is also my problem. As I wrote some weeks
ago (05/28/2012) when starting this thread, I am using FreeBSD as a
scientific desktop because of its good scaling properties. For some
years now, FreeBSD fits all our needs with R, SAGA GIS, PostgreSQL and
some more.

If I would not be able to run upcoming versions of R on FreeBSD any
more, that would be really, really hard :-(


Do you have a list of the essential functions here?  There are 17 long
double functions and some complex functions missing, but only a
handful of those are of general interest.  The reason I ask is that if
R is just looking for a few missing functions that are already mostly
implemented, then the best solution is probably to finish that work.
But if it's expecting us to have something arcane like long double
Bessel functions of the first kind, then we need to pursue a workaround
in the short term.



That is, what I found by grepping the sources of a recent R development
version:

expl:   src/nmath/pnchisq.c


Many thanks to you three for implementing expl() with r238722 and r238724.

I am not a C programmer, but would like to ask if the following example 
is correct and suituable as a minimalistic test of this new C99 function?



//---
#include stdio.h
#include math.h

int main(void)
{
  double c = 2.0;
  long double d = 2.0;

  double e = exp(c);
  long double f = expl(d);

  printf(exp(%f)  is %.*f\n,  c, 90, e);
  printf(expl(%Lf) is %.*Lf\n, d, 90, f);

  return 0;
}
//---


Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards 
it gives me:


exp(2.00)  is 
7.38905609893065040694182243896648287773132324218750
expl(2.00) is 
7.38905609893065022739794267536694860609713941812515258789062500



Already the sixteenth position after decimal point differs.

Please forgive me, if this is a really stupid approach for producing 
some expl() output.


uname -a: FreeBSD xxx.xxx.xxx 10.0-CURRENT FreeBSD 10.0-CURRENT #0 
r238740: Tue Jul 24 18:08:13 CEST 2012 
x...@xxx.xxx.xxx:/usr/obj/usr/src/sys/XXX  amd64


Rainer



logl:   src/nmath/dnbeta.c
 src/nmath/pnbeta.c


Bruce has versions of these that could be committed with some cleanup.
It's a matter of sorting through about 1200 emails from him and 3
source trees to find the most up-to-date patches, then cleaning them
up and testing and committing them.  I have no time right now, but I
will do at least the first step as soon as I can, and try to get the
patches to someone willing to do the final few steps.


log10l: src/extra/trio/trio.c

log1pl: src/nmath/pnbeta.c


If Bruce doesn't already have implementations of these, they are easy
wrappers around logl() or some internal k_logl in Bruce's implementation.


powl:   src/extra/trio/triostr.c
 src/extra/trio/trio.c
 src/main/format.c


It's hard to do a good job on powl(), but the simple approach
(exp(log(x)*y)) plus a few special cases may suffice for many uses.


NEWS:l2044
The C99 functions acosh, asinh, atanh, snprintf and vsnprintf are
now required.


We have had them forever.


NEWS:l3032
The C99 double complex type is now required.
The C99 complex trigonometric functions (such as csin) are not
currently required (FreeBSD lacks most of them): substitutes are
used if they are missing.


We have these (but not the inverse trig functions).


NEWS:l3277
Complex arithmetic (notably z^n for complex z and integer n) gave
incorrect results since R 2.10.0 on platforms without C99 complex
support.  This and some lesser issues in trigonometric functions
have been corrected.
Such platforms were rare (we know of Cygwin and FreeBSD).
However, because of new compiler optimizations in the way complex
arguments are handled, the same code was selected on x86_64 Linux
with gcc 4.5.x at the default -O2 optimization (but not at -O).


Not sure if this is relevant.


BTW: There seems to be a discrepancy about missing functions listed in
http://wiki.freebsd.org/MissingMathStuff

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

On 25.07.2012 19:00 (UTC+2), Steve Kargl wrote:

On Wed, Jul 25, 2012 at 06:29:18PM +0200, Rainer Hurling wrote:


Many thanks to you three for implementing expl() with r238722 and r238724.

I am not a C programmer, but would like to ask if the following example
is correct and suituable as a minimalistic test of this new C99 function?



It's not clear to me what you mean by test.  If expl() is
not available in libm, then linking the code would fail.
So, testing for the existence of expl() (for example,
in a configure script) is as simple as


Sorry for not being clear enough. I didn't mean testing for the 
existence, but for some comparable output between exp() and expl(), on a 
system with expl() available in libm.



#include math.h
long double
func(long double x)
{
   return (expl(x));
}


//---
#include stdio.h
#include math.h

int main(void)
{
   double c = 2.0;
   long double d = 2.0;

   double e = exp(c);
   long double f = expl(d);

   printf(exp(%f)  is %.*f\n,  c, 90, e);
   printf(expl(%Lf) is %.*Lf\n, d, 90, f);


If you mean testing that the output is correct, then
asking for 90 digits is of little use.  The following
is sufficient (and my actually produce a digit or two
more than is available in number)


Ok, I understand. I printed the 90 digits to be able to take a look at 
the decimal places, I did not expect to get valid digits in this area.



troutmask:fvwm:kargl[203] diff -u a.c.orig a.c
--- a.c.orig2012-07-25 09:38:31.0 -0700
+++ a.c 2012-07-25 09:40:36.0 -0700
@@ -1,5 +1,6 @@
  #include stdio.h
  #include math.h
+#include float.h

  int main(void)
  {
@@ -9,8 +10,8 @@
double e = exp(c);
long double f = expl(d);

-  printf(exp(%f)  is %.*f\n,  c, 90, e);
-  printf(expl(%Lf) is %.*Lf\n, d, 90, f);
+  printf(exp(%f)  is %.*f\n,  c, DBL_DIG+2, e);
+  printf(expl(%Lf) is %.*Lf\n, d, LDBL_DIG+2, f);

return 0;
  }


Thanks, I was not aware of DBL_DIG and LDBL_DIG.


   return 0;
}
//---

Compiled with 'c99 -o math_expl math_expl.c -lm' and running afterwards
it gives me:

exp(2.00)  is
7.38905609893065040
expl(2.00) is
7.38905609893065022739

Already the sixteenth position after decimal point differs.


DBL_DIG is 15 on x86 hardware and LDBL_DIG is 18.  You can
expect at most 15 correct digits from exp().


Please forgive me, if this is a really stupid approach for producing
some expl() output.


If you actually want to test expl() to see if it is producing
a decent result, you need a reference solution that contains
a higher precision.  I use mpfr with 256 bits of precision.

troutmask:fvwm:kargl[213] ./testl -V 2
ULP = 0.3863
   x = 2.00e+00
libm: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2
mpfr: 7.389056098930650227e+00 0x1.d8e64b8d4ddadcc4p+2
mpfr: 7.3890560989306502272304274605750078131803155705518\
   47324087127822522573796079054e+00
mpfr: 0x7.63992e35376b730ce8ee881ada2aeea11eb9ebd93c887eb59ed77977d109f148p+0

The 1st 'mpfr:' line is produced after converting the results
fof mpfr_exp() to long double.  The 2nd 'mpfr:' line is
produced by mpfr_printf() where the number of printed
digits depends on the 256-bit precision.  The last 'mpfr:'
line is mpfr_printf()'s hex formatting.  Unfortunately, it
does not normalize the hex representation to start with
'0x1.', which makes comparison somewhat difficult.



Many thanks also for this mpfr example. This helps me to understand a 
little bit more what is going here. So on amd64 even the expl() result 
is far from what mpfr provides.

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

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

On 09.07.2012 01:36 (UTC+2), Steve Kargl wrote:

On Sun, Jul 08, 2012 at 11:51:56AM -0600, Warner Losh wrote:


On Jul 8, 2012, at 6:40 AM, David Schultz wrote:


On Tue, May 29, 2012, Peter Jeremy wrote:

On 2012-May-28 15:54:06 -0700, Steve Kargl s...@troutmask.apl.washington.edu 
wrote:

Given that cephes was written years before C99 was even
conceived, I suspect all functions are sub-standard.


Well, most of cephes was written before C99.  The C99 parts of
cephes were written to turn it into a complete C99 implementation.


I'm a bit late to the party, but I thought I'd chime in with some
context.  We did consider using Cephes years ago, and even got
permission from the author to release it under an acceptable license.
We later decided not to use it for technical reasons.

By the way, virtually none of the people who have complained about the
missing functions actually need them.  Mostly they just want to
compile some software that was written by a naive programmer who
thought it would be cool to use the most precise type available.  The
complex functions are even less commonly needed, and the truth is that
they have no business being part of the C standard anyway.

The question remains of what to do about the missing functions.  Bruce
and Steve have been working on expl and logl for years.  If those ever
get in the tree, the remaining long double functions are easy.  Those
functions are basically done, modulo a bunch of cleanup and testing,
and I encourage any mathematically inclined folks who are interested
in pushing things along to get in touch with them.  I'm not going to
have any time myself for a few months at least.


Where can I find these?


I've posted expl() a few times for the ld80 version.
I don't have an ld128 version, which is why I have
yet to submit a formal patch for expl().  I also
have an ld80 expm1l().  I have a copy of bde's ld80
logl().  IIRC, bde wrote an ld128, but I don't have
nor do I know if it has been tested.


Do you think your version from 
http://www.freebsd.org/cgi/query-pr.cgi?pr=152415 for expl() ld80 
version could be the one getting into head? Would you be willing to 
commit it?


As far as I understand from discussions on R mailing list 
(r-de...@r-project.org), they plan to reduce the emulation and/or 
workaround of long and complex math functions for FreeBSD and other 
systems with their next releases of R devel. So we could really need 
some progress with our C99 conform math functions ;-)



Lastly, there's the question of mediocre alternatives, such as
solutions that get the boundary cases wrong or don't handle 128-bit
floating point.  For the exponential and logarithmic functions, Bruce
and Steve have already written good implementations, so there's no
reason to settle for less.  As for the other long double functions,
bringing in some Cephes code in a separate directory as a temporary
fix might be the way to go.  I don't like that solution, and Steve
raises some good technical points about why it isn't ideal; however, a
better solution is more than a decade overdue, and people are
justified in finding that unacceptable.


Don't let the perfect be the enemy of the good.  It is better to
have OK implementations of these functions than none at all.


You'll need to define OK, because some of the implementations
I've read are poor.  I also hope that before anything is
committed to libm that the person doing the committing does
some rather thorough testing of the code.


We originally had so-so double support, but bruce spent many
years optimizing them to make them very good.  If we were
just starting out, and hadn't let 10 years get behind us, I'd
give the substandard argument some weight.  But now that we're
13 years down the line from c99's publication I think we need
to relax our standards a bit.  I'd even argue that these
functions being a little bad could easily spur people to make
them better.  Their absence makes people just
#define llexp(x) lexp(x), etc. :(


Of course, the converse argument is that people have had 10 years
to learn enough about floating point to actually write and submit
code.  I knew very little about FP before I wrote sqrtl().  I had
a need for sqrtl() and so I went looking for a solution.

PS: I also wrote sincos[fl](), which is very handy for the
complex trig functions.





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

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

On 10.07.2012 16:02 (UTC+2), Warner Losh wrote:


On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote:

As far as I understand from discussions on R mailing list 
(r-de...@r-project.org), they plan to reduce the emulation and/or workaround of 
long and complex math functions for FreeBSD and other systems with their next 
releases of R devel. So we could really need some progress with our C99 conform 
math functions ;-)


Not having R would be a bit pain in my backside.  That's one of the practical 
considerations that I was talking about.  It is very real, and if I have to, 
I'll commit the #define junk I railed against to get it back.  Please, let's 
get some progress.  I have some time to help.


Yes, thank you Warner, that is also my problem. As I wrote some weeks 
ago (05/28/2012) when starting this thread, I am using FreeBSD as a 
scientific desktop because of its good scaling properties. For some 
years now, FreeBSD fits all our needs with R, SAGA GIS, PostgreSQL and 
some more.


If I would not be able to run upcoming versions of R on FreeBSD any 
more, that would be really, really hard :-(


Rainer


Warner



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

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

On 10.07.2012 17:11 (UTC+2), David Schultz wrote:

On Tue, Jul 10, 2012, Rainer Hurling wrote:

On 10.07.2012 16:02 (UTC+2), Warner Losh wrote:


On Jul 10, 2012, at 3:10 AM, Rainer Hurling wrote:

As far as I understand from discussions on R mailing list
(r-de...@r-project.org), they plan to reduce the emulation and/or
workaround of long and complex math functions for FreeBSD and other
systems with their next releases of R devel. So we could really need some
progress with our C99 conform math functions ;-)


Not having R would be a bit pain in my backside.  That's one of the
practical considerations that I was talking about.  It is very real, and
if I have to, I'll commit the #define junk I railed against to get it
back.  Please, let's get some progress.  I have some time to help.


Yes, thank you Warner, that is also my problem. As I wrote some weeks
ago (05/28/2012) when starting this thread, I am using FreeBSD as a
scientific desktop because of its good scaling properties. For some
years now, FreeBSD fits all our needs with R, SAGA GIS, PostgreSQL and
some more.

If I would not be able to run upcoming versions of R on FreeBSD any
more, that would be really, really hard :-(


Do you have a list of the essential functions here?  There are 17 long
double functions and some complex functions missing, but only a
handful of those are of general interest.  The reason I ask is that if
R is just looking for a few missing functions that are already mostly
implemented, then the best solution is probably to finish that work.
But if it's expecting us to have something arcane like long double
Bessel functions of the first kind, then we need to pursue a workaround
in the short term.



That is, what I found by grepping the sources of a recent R development 
version:


expl:   src/nmath/pnchisq.c

log10l: src/extra/trio/trio.c

log1pl: src/nmath/pnbeta.c

logl:   src/nmath/dnbeta.c
src/nmath/pnbeta.c

powl:   src/extra/trio/triostr.c
src/extra/trio/trio.c
src/main/format.c


In the R NEWS file I found the following three entries about C99 
(complex) functions:


NEWS:l2044
The C99 functions acosh, asinh, atanh, snprintf and vsnprintf are
now required.

NEWS:l3032
The C99 double complex type is now required.
The C99 complex trigonometric functions (such as csin) are not
currently required (FreeBSD lacks most of them): substitutes are
used if they are missing.

NEWS:l3277
Complex arithmetic (notably z^n for complex z and integer n) gave
incorrect results since R 2.10.0 on platforms without C99 complex
support.  This and some lesser issues in trigonometric functions
have been corrected.
Such platforms were rare (we know of Cygwin and FreeBSD).
However, because of new compiler optimizations in the way complex
arguments are handled, the same code was selected on x86_64 Linux
with gcc 4.5.x at the default -O2 optimization (but not at -O).


From the discussions on the R-devel mailing list we could expect, that 
there will be more complex (long, longlong) functions introduced in the 
near future. (But it is very likely that b.f. does know much more about 
this.)


Rainer


BTW: There seems to be a discrepancy about missing functions listed in
http://wiki.freebsd.org/MissingMathStuff and in
http://svnweb.freebsd.org/base/head/lib/msun/src/math.h?r1=227472r2=236148pathrev=236148. 
So the wiki is a bit outdated now?

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

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

On 29.05.2012 08:10 (UTC+1), Steve Kargl wrote:

On Tue, May 29, 2012 at 02:56:13PM +1000, Peter Jeremy wrote:

On 2012-May-28 15:54:06 -0700, Steve Kargls...@troutmask.apl.washington.edu  
wrote:

There some test code in cephes.  Can you point me to a suitable test
suite for LD80 and LD128?  The reason for calling it libm is to avoid
having to hack every consumer to add an additional library.


I can't point you to test code.  When I work on a function,
I write test code.


  It took
me 3+ years to get sqrtl() into libm, but bde and das (and
myself) wanted to make sure the code worked.


Last time I checked (a couple of years ago), FreeBSD was missing 65
C99 libm functions.  At 3 years per function, we should have C99
support available early in the 23rd century - which may be a bit late.


sqrtl() is a bit special in that IEEE 754 requires that
it have no more than 0.5 ULP for all arguments in all
roundng modes.  As to other functions, I've been trying
for 10+ years to get some of these into FreeBSD.  I can
assure you that there has never been a rush of people
volunteering to help or a rush of people willing to fund
the development of the necessary code.


The almost complete absence of volunteers in this case is first of all 
caused by the need of very special, deep knowlegdes on mathematical and 
informatical issues. I bet there are only a few people out there, who 
are really good in both (three of them are known to us ;) ). The 
problems with quality standards in such libraries spreaded over most 
OS'es and platforms support this view. (I am aware that these arguments 
are kown and discussed before.)


People like me, who wanted to _use_ FreeBSD as scientific desktops, have 
an urgent need on such mathematical libraries. But most of us have no 
chance to contribute conceptual. For some tasks we could use specialized 
libraries or software, which include missing procedures and functions. 
But more often, modern apps expect to get this functionalities from the OS.


This discussion confirms my impression, that it should be possible as an 
interim solution, to use a port for missing math functions (cephes alike 
or whatever). The port itself could warn the user about inaccuracies and 
edge-cases.


The more important question to me is, how can the remaining (huge!) work 
on the systems libm done in a foreseeable time. As one possibility, 
wouldn't it be imaginable to pay some people for doing (some of) this 
work (FreeBSD Foundation, Sponsors from industry and science etc.)? I 
personally, as a private person, would be willing to pay a few hundred 
dollars for it. Paying people for other tasks in FreeBSD is not entirely 
uncommon, if I am not mistaken.




On 2012-May-28 22:03:43 -0500, Stephen Montgomery-Smithstep...@missouri.edu  
wrote:

1.  By being so picky about being so precise, FreeBSD is behind the time
line in rolling out a usable set of C99 functions.


And at the current rate, we'll all be long dead before they are
available.


It seems you've had a couple of years to implement one or
more of the missing functions.  Yes, we'll all be dead before
libm is C99 ready because no one, other than bde@, das@ and
myself, has been willing to actually help write the code.  I
know that at least one of those three people has had no time
in the last year or two work on libm.



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

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

On 28.05.2012 10:41 (UTC+1), David Chisnall wrote:

On 28 May 2012, at 05:35, Rainer Hurling wrote:


First I should note that I am by no means an expert in C / C++ or C99 
standards. So my comments are only on a level of someone who is using 
FreeBSD for scientific purposes like GIS and math applications and who 
is the maintainer of some scientific ports (like math/saga).



Yesterday r236148 (Allow inclusion of libc++cmath  to work after including 
math.h) was comitted to head, many thanks.

Does this mean, that extra long double functions like acoshl, expm1l or log1pl are now 
really implemented? As far as I understand, they had only been declared 
before?


They are still not implemented.  Thecmath  header in libc++ provides wrappers around 
these functions for C++, but if they are not declared then the compiler throws an error.  Now 
there is a linker error if they are used, but if they are not used then it works irrespective of 
whether you just includecmath  or do undefined things like includemath.h  first.


Ok, that's what I had supposed. Because the main difference between 
r236147 and r2136148 seems to be the define of _MATH_EXTRA_H_, the rest 
is more a type of binning?



If this is right, are they usable on a recent CURRENT, built with gcc42 (system 
compiler), by ports which use gcc46 (not clang)? If not, are there any plans to 
implement these functions in the near future?


I think they're one of the last bits of C99 / C11 that anyone actually cares 
about (C11 unicode support being another), so they'll probably get done at some 
point, but doing them correctly is nontrivial, except on platforms where double 
and long double are the same.


Yes, I agree. These outstanding long double math functions (like log1pl) 
and better unicode support are really needed for some important third 
party projects like R or SAGA GIS.


In the past I have read several times discussions about the correctness 
of long double functions on FreeBSD. Some drafts have been dismissed 
because of there inaccuracy in special cases. Also was discussed to get 
missing libm routines from NetBSD [1]. It appears as if we have to wait 
some more time ...



The use of C99 extra long double functions would be of interest for example for 
programs like math/R, especially its upcoming releases.


I would be very wary of anything that depends on long double.  The C spec makes 
no constraints on the range of float, double, or long double, but by convention 
on most platforms float is an IEEE 754 32-bit floating point value and double 
is 64-bit.  No such conventions apply to long doubles and I know of (widely 
deployed) platforms where they are 64 bits, 80 bits and 128 bits, respectively. 
 I believe on PowerPC FreeBSD actually gets it wrong and uses 64 bits even 
though the platform ABI spec recommends using 128 bits.  x86 uses 80-bit x87 
values (although sizeof(long double) may be 16 because they have some padding 
bytes in memory).  If your program is tolerant of a potential variation in 
precision between 64 bits and 128 bits, then it is probably tolerant of just 
using doubles.


Yes, I think in most cases math/R is tolerant enough of just using 
doubles. But in the near future they plan to implement much more of the 
C99 stuff and their tolerance to offer workarounds for FreeBSD shrinks 
from release to release [2]. So these problems will increase :-(


Many thanks for your fast und well explained answer, I really appreciate it.

Rainer


David



[1] 
http://lists.freebsd.org/pipermail/freebsd-standards/2011-February/002119.html


[2] https://stat.ethz.ch/pipermail/r-devel/2012-May/064128.html

And some more places I found interesting about C99 and FreeBSD

[3] http://www.freebsd.org/projects/c99/index.html

[4] http://wiki.freebsd.org/MissingMathStuff

[5] http://marc.info/?l=freebsd-standardsm=123158761305427

[6] 
http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/028030.html


[7] 
http://www.koders.com/c/fid164FD2F50C9AAA63119A641875824455B3AE6B55.aspx?s=log1pl.c


[8] http://www.mail-archive.com/bug-gnulib@gnu.org/msg26571.html

[9] http://leaf.dragonflybsd.org/mailarchive/commits/2011-12/msg00190.html
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Use of C99 extra long double math functions after r236148

[Rainer Hurling]

On 28.05.2012 14:49 (UTC+1), David Chisnall wrote:

On 28 May 2012, at 13:30, Rainer Hurling wrote:


On 28.05.2012 10:41 (UTC+1), David Chisnall wrote:

On 28 May 2012, at 05:35, Rainer Hurling wrote:


Ok, that's what I had supposed. Because the main difference between r236147 and 
r2136148 seems to be the define of _MATH_EXTRA_H_, the rest is more a type of 
binning?


Yes, it's just about making libc++'s cmath header compile, nothing more.


I see, thanks.


Yes, I agree. These outstanding long double math functions (like log1pl) and 
better unicode support are really needed for some important third party 
projects like R or SAGA GIS.


I very much doubt that anything is using the C11 unicode stuff yet, since no 
compiler or libc currently supports it...


Of course you are right with C11 unicode stuff.

I thougt more about my actual problems to get the right charset 
conversions between different apps, i.e. qgis - wxgtk29 - saga gis. 
Or using Gnome apps (utf8) on windowmaker using ISO8859-15. But this is 
OT here, sorry.



In the past I have read several times discussions about the correctness of long 
double functions on FreeBSD. Some drafts have been dismissed because of there 
inaccuracy in special cases. Also was discussed to get missing libm routines 
from NetBSD [1]. It appears as if we have to wait some more time ...


I thought we did pull in some NetBSD libm stuff recently.  Not sure what the 
status of that is, you'd need to check with das@.


I am not aware of it and will have a look. But this did not implement 
the missing long double functions.



Yes, I think in most cases math/R is tolerant enough of just using doubles. But 
in the near future they plan to implement much more of the C99 stuff and their 
tolerance to offer workarounds for FreeBSD shrinks from release to release [2]. 
So these problems will increase :-(


Reading that email, it seems that they would prefer a function that exists and 
returns the wrong result to one that does not exist.  If this is really the 
attitude of the developers of R, then I shall make absolutely certain that I 
avoid using R for anything where I actually care about the results, and would 
strongly encourage everyone else to do the same.


This was a statement of just one (though not unimportant) person from 
the R Core team. I don't think that this is the only view of R Core 
developers. On the other hand he is the person, who actually did most of 
the stuff within R for years now to circumvent the problems running on 
FreeBSD.



In general, (sane) people use the long double versions because they need the 
extra precision and care about the result.  We could easily implement the long 
double versions now as toy versions that just called the double versions, but 
that would upset a lot of people who actually care about accuracy, who are the 
main target audience for these functions.


It seems to be a general trend (outside of FreeBSD) to implement more 
and more stuff at the cost of quality. I am certain that for many 
FreeBSD users accuracy is more important than completeness, especially 
for scientists.


Nevertheless this policy brings some problems in the real world ;-)

Thanks again for your thoughts,
Rainer


David

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

Use of C99 extra long double math functions after r236148

[Rainer Hurling]

Yesterday r236148 (Allow inclusion of libc++ cmath to work after 
including math.h) was comitted to head, many thanks.


Does this mean, that extra long double functions like acoshl, expm1l or 
log1pl are now really implemented? As far as I understand, they had 
only been declared before?


If this is right, are they usable on a recent CURRENT, built with gcc42 
(system compiler), by ports which use gcc46 (not clang)? If not, are 
there any plans to implement these functions in the near future?


The use of C99 extra long double functions would be of interest for 
example for programs like math/R, especially its upcoming releases.


Many thanks for any clarification.

Regards,
Rainer Hurling
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

stat(1) - option doubled in manpage

[Rainer Hurling]

Just a small note.

In stat(1) the description of option -l doubles:

-l  Display output in ls -lT format.


Perhaps someone with a commit bit is interested in correcting this?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Kernel builds, but crashes at boot (amd64, Revision: 234306)

[Rainer Hurling]

Am 17.04.2012 03:53 (UTC+1) schrieb Edward Tomasz Napierała:

Wiadomość napisana przez Rainer Hurling w dniu 16 kwi 2012, o godz. 19:58:

On 16.04.2012 19:31 (UTC+1), Konstantin Belousov wrote:

On Mon, Apr 16, 2012 at 06:15:32PM +0200, Rainer Hurling wrote:


I just updated my system to r234342, only downgraded
/usr/src/sys/cam/scsi/scsi_da.c to r233746, and now the system is
booting again. So obviously there is something wrong with the newest
patch to  scsi_da.c.

It is too broad, try to revert exactly one patch and see whether it works.


Sorry for my bad english. I wanted to say, that I only reverted exactly one 
patch (file scsi_da.c from 234177 back to 233746 manually). The rest is up to 
r234342.


Could you try the patch below?

Index: sys/cam/scsi/scsi_da.c
===
--- sys/cam/scsi/scsi_da.c  (revision 234314)
+++ sys/cam/scsi/scsi_da.c  (working copy)
@@ -938,7 +938,9 @@ daopen(struct disk *dp)
if (error != 0)
xpt_print(periph-path, unable to retrieve capacity data);

-   if (periph-flags  CAM_PERIPH_INVALID)
+   if (periph-flags  CAM_PERIPH_INVALID ||
+   softc-disk-d_sectorsize == 0 ||
+   softc-disk-d_mediasize == 0)
error = ENXIO;

if (error == 0  (softc-flags  DA_FLAG_PACK_REMOVABLE) != 0




Thanks for the patch. I just tried it with 10.0-CURRENT (amd64) r234370 
and it at least boots again.

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

Re: Kernel builds, but crashes at boot (amd64, Revision: 234306)

[Rainer Hurling]

On 16.04.2012 16:55 (UTC+1), Konstantin Belousov wrote:

On Mon, Apr 16, 2012 at 07:35:23AM -0700, matt wrote:

On 04/16/12 01:57, O. Hartmann wrote:

On 04/15/12 12:30, Conrad J. Sabatier wrote:

Today I'm suddenly unable to boot a newly built kernel without crashing
right near the end of the device probes, just before the system is
about to actually come up:

Fatal trap 18: integer divide fault while in kernel mode

Stopped at 0x803b2646 = g_label_ufs_taste_common+0x36
divl 0x50(%rcx),%eax

Backtrace lists this chain of calls:
g_label_ufs_taste_common
g_label_taste
g_new_provider_event
g_run_events
g_event_procbody
fork_exit
fork_trampoline

Whether built with clang or gcc, CUSTOM config or GENERIC, same results
on rebooting.  No idea why this suddenly started happening, haven't
changed anything at all in my setup.

My recent kernel does the same on two FreeBSD 10.0-CURRENT #1 r234309:
Sun Apr 15 14:14:11 CEST 2012 boxes. Both boxes in common is they are
attached to a Dell UltraSharp U2711 screen which does have a built-in
USB/MMC hub. I realized that it was possible to log into my lab's box
from remote when I'm not in the lab and that is usually coincidentally
with a switched off screen.
This morning I loged in from home, loged out and got to the office,
switched on the screen - and reboot! I wasn't able to get the system
running again, it always got stuck in a

Fatal trap 18: integer divide fault while in kernel mode

Unplugging the screen's USB hub makes the system booting again!

Following is one of the last logged messages from the kernel, I don not
know whether this is usefull looking for the problem.

Regards,
Oliver

Apr 12 15:32:33 telesto kernel: hwpmc:
SOFT/16/64/0x67INT,USR,SYS,REA,WRI  TSC/1/64/0x20REA
IAP/4/48/0x3ffINT,USR,SYS,EDG,THR,REA,WRI,INV,QUA,PRC
IAF/3/48/0x61INT,REA,WRI  UCP/8/48/0x3f8EDG,THR,REA,WRI,INV,QUA,PRC
UCF/1/48/0x60REA,WRI
Apr 12 15:32:33 telesto kernel: uhub1: 4 ports with 4 removable, self
powered
Apr 12 15:32:33 telesto kernel: uhub2: 4 ports with 4 removable, self
powered
Apr 12 15:32:33 telesto kernel: uhub3: 2 ports with 2 removable, self
powered
Apr 12 15:32:33 telesto kernel: uhub0: 2 ports with 2 removable, self
powered
Apr 12 15:32:33 telesto kernel: ugen3.2:vendor 0x8087  at usbus3
Apr 12 15:32:33 telesto kernel: uhub4:vendor 0x8087 product 0x0024,
class 9/0, rev 2.00/0.00, addr 2  on usbus3
Apr 12 15:32:33 telesto kernel: ugen0.2:vendor 0x8087  at usbus0
Apr 12 15:32:33 telesto kernel: uhub5:vendor 0x8087 product 0x0024,
class 9/0, rev 2.00/0.00, addr 2  on usbus0
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3 usbus0
Apr 12 15:32:33 telesto kernel: uhub5: 6 ports with 6 removable, self
powered
Apr 12 15:32:33 telesto kernel: uhub4: 8 ports with 8 removable, self
powered
Apr 12 15:32:33 telesto kernel: ugen3.3:Cherry GmbH  at usbus3
Apr 12 15:32:33 telesto kernel: ukbd0:Cherry GmbH wired keyboard,
class 0/0, rev 2.00/1.11, addr 3  on usbus3
Apr 12 15:32:33 telesto kernel: kbd2 at ukbd0
Apr 12 15:32:33 telesto kernel: uhid0:Cherry GmbH wired keyboard,
class 0/0, rev 2.00/1.11, addr 3  on usbus3
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3
Apr 12 15:32:33 telesto kernel: ugen3.4:vendor 0x0424  at usbus3
Apr 12 15:32:33 telesto kernel: uhub6:vendor 0x0424 product 0x2514,
class 9/0, rev 2.00/0.00, addr 4  on usbus3
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3
Apr 12 15:32:33 telesto kernel: uhub6: 3 ports with 2 removable, self
powered
Apr 12 15:32:33 telesto kernel: ugen3.5:vendor 0x0424  at usbus3
Apr 12 15:32:33 telesto kernel: uhub7:vendor 0x0424 product 0x2640,
class 9/0, rev 2.00/0.00, addr 5  on usbus3
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3
Apr 12 15:32:33 telesto kernel: uhub7: 3 ports with 2 removable, self
powered
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3
Apr 12 15:32:33 telesto kernel: ugen3.6:Generic  at usbus3
Apr 12 15:32:33 telesto kernel: umass0:Generic Ultra Fast Media
Reader, class 0/0, rev 2.00/1.91, addr 6  on usbus3
Apr 12 15:32:33 telesto kernel: Root mount waiting for: usbus3
Apr 12 15:32:33 telesto kernel: (probe0:umass-sim0:0:0:0): TEST UNIT
READY. CDB: 0 0 0 0 0 0
Apr 12 15:32:33 telesto kernel: (probe0:umass-sim0:0:0:0): CAM status:
SCSI Status Error
Apr 12 15:32:33 telesto kernel: (probe0:umass-sim0:0:0:0): SCSI status:
Check Condition
Apr 12 15:32:33 telesto kernel: (probe0:umass-sim0:0:0:0): SCSI sense:
NOT READY asc:3a,0 (Medium not present)
Apr 12 15:32:33 telesto kernel: da0 at umass-sim0 bus 0 scbus14 target 0
lun 0
Apr 12 15:32:33 telesto kernel: da0:Generic Ultra HS-SD/MMC 1.91
Removable Direct Access SCSI-0 device
Apr 12 15:32:33 telesto kernel: da0: 40.000MB/s transfers
Apr 12 15:32:33 telesto kernel: da0: Attempt to query device size
failed: NOT READY, Medium not present
Apr 12 15:32:33 telesto kernel: ugen3.7:Logitech  at usbus3
Apr 12 15:32:33 telesto kernel: ums0:Logitech USB Laser Mouse, class
0/0, rev 2.00/56.01,