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

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

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 x86_64-u

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: Delay in 14.0-RELEASE cycle and blocking items

[Rainer Duffner]

> Am 03.05.2023 um 18:27 schrieb Glen Barber :
> 
> On Wed, May 03, 2023 at 07:53:09AM +, Alexey Dokuchaev wrote:
>> On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote:
>>> ...
>>> There is no feasible way we are going to make the branch point of
>>> stable/14 in time, with that scheduled for May 12, 2023 with the above
>>> points.  That said, this is not an all-inclusive list, but the more
>>> major items on our radar at the moment.
>> 
>> Does this delay mean we might get Clang 16 in the base?
>> 
> 
> Well, the delay really means we do not currently have OpenSSL 3 in base.
> 
> Glen
> 

I cannot help with this, of course.

But out of interest: what are the problems?

There was a post on the haproxy mailing-list a while back, linking to some 
github issue and from what I understood, there are huge performance-problems in 
there.


Rainer

Re: Why was Sendmail replaced with DMA?

[rainer]

Am 2022-12-05 18:37, schrieb Chris:

I just noticed that FreeBSD will now install dma(8) instead of
sendmail(8) as the default mailer. Why is this so?

Thank you

--chris



I think the problem was that the original developers of sendmail have 
mostly disappeared.

More or less.

It looked like abandonware.

I'm sorry for the people who still use and love it - but the first thing 
we do is install postfix and set a relayhost...



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: smartpqi: panic: malloc(M_WAITOK) with sleeping prohibited

[Rainer Duffner]

> Am 31.01.2022 um 21:13 schrieb Yuri :
> 
> Got this panic after booting GENERIC kernel:
> 



Probably best to open a PR.

It usually gets assigned to the microchip-people - I’m not sure if they are 
following the mailing-lists.

Re: storcli: howto crossflash Fujitsu PRAID400i to LSI3008 HBA?

[Rainer Duffner]

> Am 23.06.2021 um 13:04 schrieb O. Hartmann :
> 
> Does anyone have had success on flashing this type of SAS controller from IR
> firmware to IT firmware?



Hi,

I once tried to cross-flash a HP H220 (IIRC) to LSI 2008 (or whatever), because 
HP would not update the firmware (anymore) and obviously does not bother about 
FreeBSD (never did…).

It actually worked, but only with a very old version of LSI’s flash tools 
(newer versions refused to do it).

Of course, the HBA did not work better afterwards and the only „fix“ was to buy 
actual LSI hardware.

IIRC, for our Supermicro Servers, the firmware is/was really identical, except 
for a vendor-string (which a co-worker changed using a hex-editor).

But you can never be too sure about that and the best (and only IMO) way is to 
avoid OEM HBAs like the plague and buy them directly from the people who 
designed the hardware in the first place.

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: Update to the 13.0-RELEASE schedule

[Rainer Duffner]

> Am 31.03.2021 um 17:58 schrieb Glen Barber :
> 
> A small set of updates that we consider blocking the 13.0 release have
> been brought to our attention.  As such, the 13.0-RELEASE schedule has
> been updated to include a fifth release candidate (RC5).
> 
> The updated schedule is available on the FreeBSD Project website:
> 
> https://www.freebsd.org/releases/13.0R/schedule/
> 
> As usual, we will continue to consider critical bug fixes only for the
> duration of this release cycle.
> 
> Thank you for your cooperation, and for your patience.
> 
> Glen
> On behalf of: re@
> 



The truth is that a lot people don’t really start testing until the later 
release candidates.

So, having more of these release candidates with just refinements is a good 
thing, IMHO.



___
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

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]

t;>>>>>
>>>>>>>>
>>>>>>>> ___
>>>>>>>> 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&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 before to successfully apply and
> run this patch?
> 
> [...]
> --- beforedepend ---
> mkdir -p xlocale arpa;  for i in a.out.h assert.h elf.h limits.h
> nlist.h setjmp.h stddef.h stdbool.h string.h strings.h time.h unistd.h
> uuid.h; do  ln -sf /usr/src/include/$i $i;  done;  ln -sf
> /usr/src/sys/amd64/include/stdarg.h stdarg.h;  ln -sf
> /usr/src/sys/sys/errno.h errno.h;  ln -sf /usr/src/sys/sys/stdint.h
> stdint.h;  ln -sf /usr/src/include/arpa/inet.h arpa/inet.h;  ln -sf
> /usr/src/include/arpa/tftp.h arpa/tftp.h;  for i in _time.h _strings.h
> _string.h; do  [ -f xlocale/$i ] || cp /dev/null xlocale/$i;  done;
> for i in ctype.h fcntl.h signal.h stdio.h stdlib.h; do  ln -sf
> /usr/src/stand/libsa/stand.h $i;  done cp: /dev/null: Invalid argument
> *** [beforedepend] Error code 1
> 
> make[4]: stopped in /usr/src/stand/libsa32
> --- all_subdir_rescue ---
> *** [iscsictl_make] Error code 2
> 

For me the build proceeds, after I did a 'make install' in
/usr/src/bin/cp (with updated utils.c!).

HTH,
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: New FreeBSD snapshots available: main (20200903 c122cf32f2a)

[rainer]

Am 2020-09-03 17:02, schrieb Glen Barber:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

New FreeBSD development branch installation ISOs and virtual machine
disk images have been uploaded to the FreeBSD Project mirrors.



=== Virtual Machine Disk Images ===

VM disk images are available for the following architectures:

o 13.0-CURRENT amd64
o 13.0-CURRENT i386
o 13.0-CURRENT aarch64

Disk images may be downloaded from the following URL (or any of the
FreeBSD Project mirrors):

https://download.freebsd.org/ftp/snapshots/VM-IMAGES/

Images are available in the following disk image formats:

~ RAW
~ QCOW2 (qemu)
~ VMDK (qemu, VirtualBox, VMWare)
~ VHD (qemu, xen)

The partition layout is:

~ 512k - freebsd-boot GPT partition type (bootfs GPT label)
~ 1GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label)

Note regarding arm64/aarch64 virtual machine images: a modified QEMU 
EFI

loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0






Hi,

what about adding net/cloud-init to the images so that they can be used 
out-of-the-box on OpenStack?


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238068



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: Plans for git (was: Please check the current beta git conversions)

[Rainer Duffner]

> Am 02.09.2020 um 18:22 schrieb Warner Losh :
> 
> 
> 
>> On Sep 2, 2020, at 10:14 AM, Ed Maste  wrote:
>> 
>> On Wed, 2 Sep 2020 at 02:31, Steve Kargl
>>  wrote:
>>> 
 A short intro on git for svn users:
 https://hackmd.io/ML5TSl8mQ5-27B5eqDf7YA?view
 
>>> 
>>> ROTFL.  From the "short intro", 2nd sentence.
>>> 
>>> New committers are assumed to already be familiar with the basic
>>> operation of Git.  If not, start by reading the Git Book.
>> 
>> This doc started as a direct translation of the Subversion primer,
>> which has as its first sentence:
>>> New committers are assumed to already be familiar with the basic operation 
>>> of Subversion. If not, start by reading the Subversion Book.
>> 
>> As with the Subversion primer the doc is intended to provide a quick
>> reference for day-to-day commands, but not act as a reference or
>> introduction to the entire theory of operation of the associated VCS.
> 
> The rest of the guide walks people through how to do the job, but without all 
> the theory for the basics.
> 
> Again it needs some work for the advanced topic it currently just omits…
> 



Sorry, but I had to think of this:


https://xkcd.com/1597/


The project was announced a while back in the quarterly status report (that’s 
the first time I read about it at least).

It’s obviously a huge undertaking, the people taking part in it should be 
commended, not ridiculed (IMO).

For people who don’t have much exposure to git, it can be very obnoxious. 

Though these days, a lot of people assume git=github and the GUI there 
certainly makes things easier.

If it wasn’t completely riddled with security-holes, I would recommend the 
project to run its own gitlab instance - but for a project this size, you’d be 
looking at a FTE just herding that bag of cats and constantly upgrading it…



 



___
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: 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 initi

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: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

[rainer]

Am 2019-05-27 17:05, schrieb Conrad Meyer:

Hi Rainier,

On Mon, May 27, 2019 at 7:47 AM  wrote:

I have a 32bit FreeBSD 6 binary that I'll need for a bit until the
department who is technically responsible for the service gets around
redoing that service.


Even if this proposal is approved, it would only affect 13+.  You
could still run your FreeBSD 6 binary in a 32-bit 12 VM in a 13+
Bhyve.  But do consider lighting a fire under whatever department
thinks it's ok to deploy like that :-).

Take care,
Conrad



I thought so, too.

I don't really want to run the abandonware of a RADIUS-server any longer 
than necessary (as absurd as that sounds).


It's also running a recursive nameserver (previously also authoritative) 
that is still hard-coded in CPE and computers behind firewalls.


I first wanted to virtualize it (it's not a big problem) - but this way 
the problem is just dragged out: "But it still works, does it and we 
have no time".


Everybody now knows that the clock is ticking, literally.

Oh, I also remember George Neville-Neil talking about a - what - FreeBSD 
4 binary that a certain search-engine had lost the sources for and was 
running on FreeBSD 7 with compat4.
(We also have a client who literally begged us to leave a decade-old 
Solaris box running through 2019 and half of 2020 so they could continue 
to do their bookkeeping on a home-grown java-app that I suspect they, 
too have lost the sources to...). It's running jdk15 and getting that 
thing to run under anything semi-decent doesn't seem to have worked-out 
too well.

So, people pray for the best and don't prepare for the worst.


Other stuff I can think of:
 - very old Netbackup-Clients (like 5-series), though I doubt they still 
work on recent releases, because 7.71 (last official version and 
intended for FreeBSD 11) stopped working on FreeBSD12, sadly)
 - certain pre-compiled VMWare Tools Modules? Pre open-source-tools (I 
can never make up my mind if it's VMWare-open-Tools or Open-VMWare-Tools 
or something different)



What ever people do with COMPAT4-9 - it's bordering the pathological.




___
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: Disabling COMPAT_FREEBSD4/5/6/7/9 as a default kernel option

[rainer]

Am 2019-05-27 15:55, schrieb voida...@420blaze.it:

Hello,
I wanted to discuss about bug 231768 a bit: it is about keeping
COMPAT_FREEBSD4/5/6/7/9 on by default in the kernel configs.

The patch attached for the bug is for disabling these options by
default, following a few reasons which I'm going to list here:
- Keeping support for deprecated libraries isn't exactly the best
we could do to avoid security issues (if there are any) as I'm sure
nobody wants to spend that much time maintaining such stuff (it's
enough to think about misc/compat4x in the ports tree: that version of
FreeBSD was released on March 2000 and keeping 19 years old libraries
around isn't ideal)
- Devs should get track of time and realize that developing
software using unsupported libraries is NOT something that you should
do
- Only a tiny fraction of the ports need COMPAT_FREEBSD9 or older:
if the software won't compile without the legacy components (and has a
replacement of some kind), considering removal wouldn't be a bad idea
- This is on by default: most users don't care or don't use
binaries that old

I don't see any practical reason to keep these options on by default,
but I do appreciate any sort of input regarding this issue.



I have a 32bit FreeBSD 6 binary that I'll need for a bit until the 
department who is technically responsible for the service gets around 
redoing that service.



___
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 Core Team Response to Controversial Social Media Posts

[rainer]

Am 2019-05-20 11:33, schrieb Igor Mozolevsky:

So you think a discussion on whether it is appropriate that CoC Ctte
restricts freedom of expression is bikeshedding?

Thank you for your valuable contribution!



IMO, the CoC was not meant to solve, decide or even regulate discussion 
about decades-old, very controversial geo-political problems.


As such, I don't think it even applies here and the complaint should be 
dismissed on these grounds.


Of course, the FreeBSD project is free to boot developers from its ranks 
more or less at will (not sure if you can sue your way back in) - but 
for that a new CoC wouldn't have been needed to begin with ;-)







___
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: failing to install 11.1R on VMWare

[Rainer Duffner]

Can you export the empty VM and make it available for download somewhere?

If you zero the disks with dd before exporting, it should compress very nicely.


I only have Fusion to test, though.




___
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-update: to a specific patch level - help please?

[Rainer Duffner]

> Am 21.03.2018 um 22:12 schrieb Derek (freebsd lists) 
> <48225...@razorfever.net>:
> 
> Hi!
> 
> I was surprised when using freebsd-update, that there was no way to specify a 
> patch level.



AFAIK, the usual answer to these kinds of requests is: „Run your own 
freebsd-update server“.

Mirroring one of the existing ones is AFAIK neither guaranteed to work nor 
desired by the current „administration“.

I’ve contemplated doing both, but never had enough heart-ache to do it and 
never thought the pay-off would be greater than the potential problems.

It’s also a somewhat transient problem now because - AFAIK - FreeBSD will see 
packaged base and you can probably mirror those packages and snapshot the 
directory at any point in time.
And/Or it’s just easier to create these base-packages yourselves vs. running 
your own freebsd-update server.






___
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  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: How to find CPU microcode version ?

[Rainer Duffner]

> Am 18.02.2018 um 11:41 schrieb Kurt Jaeger :
> 
> Hi!
> 
> How do I find the microcode version a Intel CPU is currently using ? 
> 



AFAIK:
All Linux-vendors have retracted their microcode-updates, for the time being.

If your BIOS-vendor didn’t provide you an updated BIOS, just forget about 
„fixing" the various Spectre-variants.



___
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 <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
  Features2=0x802009
  AMD
Features=0xee500800
  AMD
Features2=0x37ff
  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: extending the maximum filename length (pointer to patch)[request for input]

[Rainer Duffner]

> Am 12.09.2017 um 23:11 schrieb Ben RUBSON :
> 
> On 12/9/17 2:17 pm, Conrad Meyer wrote:
>> On Sat, Sep 9, 2017 at 9:09 AM, Julian Elischer  wrote:
>>> maybe we could get it into -current.
>>> It'd be silly to have to have people re-inventing hte wheel all the time.
>>> How about you put those changes into the reviews.freebsd.org and we can get
>>> some general consensus on them.
>>> We'll have to do similar for the Asian customers and anyone who uses UTF-8.
>>> So it
>>> would be silly to have to develop it all again (but subtly different of
>>> course).
>>> 
>>> The key issue is how many system calls and other APIs would be broken,
>>> and how many would be broken in a non backwards compatible way?
>>> 
>>> We would need it in a stable/10 and 11 branch but if the patch is isolated
>>> enough we could carry it forward until we get to 12.
>>> 
>>> One has to allow people to do whatever they are used to with Windows.
>>> And in this case the issue is serving files over samba to windows machines.
>> Hey Julian,
>> 
>> I've thrown the patch up at https://reviews.freebsd.org/D12330 .  I
>> haven't actually tested it on FreeBSD, but it does compile.  We also
>> have some patches against contrib/pjdfstest to fix those tests against
>> long file names, but I think we can hold off on those changes until
>> we've nailed down what the architectural change will be (if any).
> 
> Hi Conrad,
> 
> This patch makes me think about another related bug #184340 :
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184340 
> 
> It is about PATH_MAX which in some cases can be too small.
> 
> Not sure if it's the case / and how to do it,
> but perhaps it is time to raise some other limits /
> think about a global solution regarding these length limits ?
> 
> Many thanks !
> 
> Ben



And there’s also this bug:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215067 


"g_dev_taste: make_dev_p() failed on importing pool with snapshots with long 
names“



But maybe that has nothing to do with it.






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

HP Gen10 servers

[rainer]

Hi,


HP Gen10 servers will bring in a lot of new stuff.
Most importantly is the new RAID controllers.

   028f  Smart Storage PQI 12G SAS/PCIe 3
103c 0600  Smart Array P408i-p SR Gen10
103c 0601  Smart Array P408e-p SR Gen10
103c 0602  Smart Array P408i-a SR Gen10
103c 0603  Smart Array P408i-c SR Gen10
103c 0650  Smart Array E208i-p SR Gen10
103c 0651  Smart Array E208e-p SR Gen10
103c 0652  Smart Array E208i-c SR Gen10
103c 0654  Smart Array E208i-a SR Gen10
103c 0655  Smart Array P408e-m SR Gen10
103c 0700  Smart Array P204i-c SR Gen10
103c 0701  Smart Array P204i-b SR Gen10
103c 1100  Smart Array P816i-a SR Gen10
103c 1101  Smart Array P416ie-m SR G10



I've checked and it seems there isn't even support in CURRENT for these 
controllers.


At least, I didn't see it:

https://svnweb.freebsd.org/base/head/sys/dev/ciss/ciss.c?revision=311351&view=markup


Or is it in a different driver?


We've yet to receive a test-model, which I assume is going to take a 
couple of weeks.



Is anybody working on this?

We can still order Gen9 for a while, I'm told. But I'd like to be able 
to use the Gen10 servers.




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: 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-dec

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 -fdiagnostics-show

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

[Rainer Duffner]

> Am 18.04.2016 um 22:07 schrieb Lev Serebryakov :
> 
> On 18.04.2016 22:40, Glen Barber wrote:
> 
>> This granularity allows easy removal of things that may not be wanted
>> (such as *-debug*, *-profile*, etc.) on systems with little storage.  On
>> one of my testing systems, I removed the tests packages and all debug
>> and profiling, and the number of base system packages is 383.
> IMHO, granularity like "all base debug", "all base profile" is enough
> for this. Really, I hardly could imagine why I will need only 1 debug or
> profile package, say, for csh. On resource-constrained systems NanoBSD
> is much better anyway (for example, my typical NanoBSD installation is
> 37MB base system, 12MB /boot and 10 packages), and on developer system
> where you need profiled libraries it is Ok to install all of them and
> don't think about 100 packages for them.
> 
> Idea of "Roles" from old FreeBSD installers looks much better. Again,
> here are some "contrib" software which have one-to-one replacements in
> ports, like sendmail, ssh/sshd, ntpd, but split all other
> FreeBSD-specific code? Yes, debug. Yes, profile. Yes, static libraries.
> Yes, lib32 on 64 bit system.
> 
>  It seems that it is ideological ("holy war") discussion more than
> technical one...



From the discussion, I believe it’s primarily driven by the need/desire to have 
small packages to make updates easier on the mirror-servers.

I’m really not sure (yet), which is worse: the current system that pulls down 
some 14k small files for a system-upgrade - or a system where the base-system 
is split into almost 800 packages.

freebsd-update is „only" unreliable if
 - you go through a proxy with authentication
 - that proxy doesn’t do http-pipelining (or does it bad/is broken is this 
respect) (certain version of Sophos UTM for example…)

AFAIK.

As for the packages: I wouldn’t mind „fatter“ packages. I’d mirror them locally 
anyway (I hope this is possible - AFAIK, the freebsd-update files are not 
supposed to be mirrored), and I don’t have a thousand servers to pull them down 
all at once anyway (working on that ;-)).

I’m pretty sure the impact on the current FreeBSD delivery infrastructure would 
be quite substantial, if updates came in 60MB chunks - esp. if there was some 
sort of auto-update mechanism in place.
Fast-forward to the future where a lot (millions?) more embedded devices are 
based on FreeBSD and pull updates from the FreeBSD infrastructure.
Or if the container hype-train reached FreeBSD and people started to 
containerize everything, resulting in even more base-package update downloads.

So, I can see both sides. Neither I’m really satisfied with.

I hope a way is found to manage these number of packages without losing sanity 
and that a normal pkg info doesn’t list them.
And that pkg upgrade doesn’t upgrade base-packages.


___
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: OCZ ssdpx-1rvd0120 REVODRIVE support

[Rainer Duffner]

> Am 17.04.2016 um 11:05 schrieb Pavel Timofeev :
> 
> HI! I've recently got a SSD device. Yes, not a disk, but a device.
> It's called, i. e. one of the first REVODRIVEs.
> It's a PCI-express card with two embedded ssd disks about ~ 55GB size.
> And it's a raid card. Fake software raid. You can set it up as a
> RAID0, RAID1, etc and a CONCATENATION. No way to leave it unconfigured
> or set it as JBOD or something else.
> You just won't be able to boot from this device in that case.
> 



It says „Linux support planned“…

on the product page.

Tried loading the  nvme(4) driver at the countdown?

https://www.freebsd.org/cgi/man.cgi?query=nvme&sektion=4


I’d suspect the Intel SSD 750 series would be a better choice…



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: 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 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&MSPPError=-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&S - 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&S - 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  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/m

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: Voxer using FreeBSD, BSDNow.tv interview

[Rainer Duffner]

>> 
> Yes that is the job of the maintainer, so bugging the chef maintainer is the
> right thing to do.
> 
> Maintaining a port meaning making sure it workds properly the FreeBSD way.


The omnibus installer is not a port.
AFAIK.
It’s the installer provided by Chef (the company, formerly known as „Opscode“).

It’s basically a shell-script with an archive attached that dumps stuff into 
/opt/chef and creates a couple of symlinks.



___
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: Voxer using FreeBSD, BSDNow.tv interview

[Rainer Duffner]

> Am 20.10.2014 um 10:19 schrieb David Chisnall :
> 
> 
> I presume that most of the relevant differences are for users / developers 
> and not sysadmins?  It's worth noting that GNU coreutils, tar, bash, and a 
> load of other things are in the ports repository.  I wonder if it's worth 
> having a gnu-userland metaport, perhaps with something like the Solaris 
> approach of sticking them all in a different tree so that you can just add 
> that to the start of your PATH and have all of the GNU tools work by default. 
>  
> 


They use chef.
The chef omnibus installer assumes there is a /bin/bash. Even the FreeBSD 
version of it. Well, it least it did the last time I looked. Maybe this got 
fixed in the meantime.
Which means that to „bootstrap“ a node, you’ve first got to install pkg on it, 
install bash, symlink it to /bin/bash and then bootstrap the node.
Which kind of runs against the concept of doing everything via chef.






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





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 M&S - 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
> M&S 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: gptzfsboot problem on HP P410i Smart Array

[Rainer Duffner]

Am Thu, 10 Apr 2014 06:59:25 +0200
schrieb Andreas Nilsson :


> > You never specified exactly how it fails. But I'll take a guess:
> 
> *Attempting Boot From Hard Drive (C:)*
> 
> *gptzfsboot: error 1 lba 32*
> 
> *gptzfsboot: error 1 lba 1*
> 
> *g**ptzfsboot: No ZFS pools located, can't boot*


True.

But as that was the failure-symptom of the original thread, I kind of
neglected to mention it
 
> A workaround is
> http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026624.html



Yes, but that requires rebuilding FreeBSD.

Why has this never been patched "properly"?
___
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: gptzfsboot problem on HP P410i Smart Array

[Rainer Duffner]

Am 10.04.2014 um 00:02 schrieb Matthew Seaman :

> On 09/04/2014 22:52, Rainer Duffner wrote:
>> And no, as the server is in a remote datacenter, an USB-stick is not an 
>> option.
>> 
>> It’s slow enough booting via a virtual USB-image over iLO...
> 
> Uh... it only has to read the kernel+modules from the USB stick one time
> while booting.  Otherwise, there really shouldn't be any IO inside /boot
> unless you login and do stuff in that directory manually.  Your root
> filesystem would be on the normal hard drives.
> 
> Anyhow the question is moot, since you don't have the same problem I did.
> 
>> No, it’s actually just a single RAID6-0 disk created by the P410i…
> 
> If you're going to use the RAID controller to generate a virtual drive,
> do you really need to use ZFS on top of that?   Couldn't you partition
> your virtual drive and put / onto a small UFS partition and then make a
> zpool on the rest?


I don’t want to sacrifice two disks for a RAID1 boot-disk.
Normally, I would actually do that, but in this case, the server is a 
MySQL-slave to a master that has 12 disks -  and should the master die, this 
system has to take over its work.


___
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: gptzfsboot problem on HP P410i Smart Array

[Rainer Duffner]

Am 09.04.2014 um 23:48 schrieb Matthew Seaman :

> On 09/04/2014 22:17, Rainer Duffner wrote:
>> Hi,
>> 
>> I found this old thread….
>> 
>> I can’t boot FreeBSD 10 installed with zfsroot on a DL380G7 (P410i 
>> controller).
>> I tried the installer and I tried installing with mfsbsd10se.
>> System has 48GB RAM.
>> 
>> Is there a PR for this?
>> 
>> 
>> Now, I’ve got to waste 2’600 GB disks (and 300-odd I/Os) for a boot-disk…..
> 
> You've got more than 8 drives in your spool?  



No, it’s actually just a single RAID6-0 disk created by the P410i…

And no, as the server is in a remote datacenter, an USB-stick is not an option.

It’s slow enough booting via a virtual USB-image over iLO...

___
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: gptzfsboot problem on HP P410i Smart Array

[Rainer Duffner]

Hi,

I found this old thread….

I can’t boot FreeBSD 10 installed with zfsroot on a DL380G7 (P410i controller).
I tried the installer and I tried installing with mfsbsd10se.
System has 48GB RAM.

Is there a PR for this?


Now, I’ve got to waste 2’600 GB disks (and 300-odd I/Os) for a boot-disk…..


___
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: Scripts for booting FreeBSD images from the install ISO for use in Jenkins?

[Rainer Duffner]

Am Mon, 17 Mar 2014 19:30:01 -0700
schrieb Craig Rodrigues :

> Hi,
> 
> For the BSD DevSummit in May, one of the items
> on our agenda:
> 
> https://wiki.freebsd.org/201405DevSummit/Jenkins
> 
> is to talk about writing scripts which can take a FreeBSD ISO image,
> and then boot it and run it on a remote system or in a VM
> to install the OS.  After the OS is up, we would like to run tests.
> All of this would be triggered from Jenkins.
> 
> Does anyone have scripts which can do this?
> Can they be contributed to the Jenkins effort on FreeBSD?
> 
> If you have scripts in Python, Ruby, Bourne shell, etc. are all fine,
> or even recipes in automation frameworks like Puppet, Ansible, Chef,
> SaltStack, etc.,
> please let us know! :)



I would have loved to attend this talk:


http://2014.asiabsdcon.org/timetable.html.en#P7A


Hopefully, more documentation and/or the slides/the video for this talk
will become available.


___
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 M&S - 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
> M&S 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 :
> 
>> 21.02.2014 20:03, O. Hartmann пишет:
>>> On Fri, 21 Feb 2014 19:00:13 +0100
>>> "O. Hartmann"  wrote:
>>>
>>>> On Fri, 21 Feb 2014 18:49:13 +0100
>>>> Dimitry Andric  wrote:
>>>>
>>>>> On 21 Feb 2014, at 18:40, O. Hartmann 
>>>>> 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: freebsd-update

[Rainer Duffner]

Am 25.01.2014 um 16:11 schrieb Mark Felder :

> 
> 
> On Sat, Jan 25, 2014, at 5:32, Lars Engels wrote:
>> 
>> 
>> Also using freebsd-update behind a proxy is really slow. Even with a
>> very fast internet connection (normally download rates ca. 3 MBytes / s)
>> downloading all the tiny binary diff files took more than 8 hours.
>> Maybe freebsd-update's backend could create a tarball of all those diffs
>> and provide this? 
> 
> Even streaming the tar instead of waiting for the freebsd-update server
> to produce the tarball would be an improvement. I have no experience
> doing that over a WAN but I don't see why it would be unreliable.


Apropos proxy:
freebsd-update does not work behind a proxy that requires authentication.
At least not with our proxy (which is a Sophos/Astaro „threat management 
appliance").
That’s OK for me, because I can talk the proxy-guys here into making an 
exception for my FreeBSD-servers - but It’s really a nuisance because 
everything else (that uses libfetch) can use proxy-authentication.




___
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  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
-D"MODULE_LIBRARY_PATH=\"/usr/local/lib/saga\""
-D"SHARE_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_a

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 

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

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: rcs

[Rainer Duffner]

Am 08.10.2013 um 22:29 schrieb Cy Schubert :

> 
> A Red Hat-like kickstart or Solaris jumpstart possibly? 
> 



http://blog.hostileadmin.com/2013/04/11/installing-freebsd-via-cobbler/


I wish it was using bsdinstall, though.



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