RE: int128_t and uint128_t typeinfo
Looks like they are still not there. I've rebuilt world. nm -D -C /usr/lib/libcxxrt.so | grep 128 should show me the symbols, right? It does not. harti -Original Message- From: Dimitry Andric [mailto:d...@freebsd.org] Sent: Tuesday, February 21, 2017 10:52 PM To: Brandt, Hartmut Cc: curr...@freebsd.org Subject: Re: int128_t and uint128_t typeinfo On 21 Feb 2017, at 18:26, Dimitry Andric wrote: > > On 21 Feb 2017, at 13:48, Hartmut Brandt wrote: >> >> it looks like the typeinfo for __int128_t and __uint128_t is missing from >> our dynamically linked libcxxrt. ... > * We also need to add the typeinfo for __u?int128_t * and __u?int128_t > const * > * Maybe these should be under the CXXABI_2.0 version, since that is > where newer libstdc++ places them > * Maybe these should be dependent on whether the architecture supports > 128 bit integers at all > > I need to think a bit on the above, then I'll commit a fix. Okay, can you please try r314061? -Dimitry ___ 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: r313938 breaks portsnap
On 2017-02-21 09:43, Vladimir Zakharov wrote: > Hello > > After recent upgrade portsnap doesn't work anymore: > > # portsnap fetch update > Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found. > Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done. > Fetching snapshot metadata... done. > Updating from Tue Feb 21 16:05:39 MSK 2017 to Tue Feb 21 16:59:30 MSK 2017. > Fetching 5 metadata patches.lam: unable to limit stdio: Capabilities > insufficient > done. > Applying metadata patches... done. > Fetching 5 metadata files... lam: unable to limit stdio: Capabilities > insufficient > /usr/sbin/portsnap: cannot open > 8c94d2c3f8fcea20eb1fd82021566c99c63a010e6b3702ee11e7a491795bcfb8.gz: No such > file or directory > metadata is corrupt. > > Reverting r313938 fixes the problem. > Fixed in r314098. Thank you for the report, sorry for the breakage. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: TSC as timecounter makes system lag
I got the impression that TSC was not preferred timecounter if it is not C-state invariant. But this apparenly is not the case now. Dig a bit and found r277900 chose to prefer TSC over saving power by disabling C2 state when TSC is selected as timecounter. But with EARLY_AP_STARTUP, and TSC as timecounter, CPU still enters C2 state. (Observed by sysctl dev.cpu.0.cx_usage_counters) With nooptions EARLY_AP_STARTUP, CPU correctly stays 100% in C1 and no lower. I added a printf in tc_windup() to check. With EARLY_AP_STARTUP, cpu_disable_c2_sleep is never increased, so it can not prevent CPU from entering C2. Guess there's some kind of race or init order issue, but it is beyond my understanding for now. -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"
Re: int128_t and uint128_t typeinfo
I had to commit a follow-up fix in r314104: when C++ names are used in the version script, they have to be surrounded by an extern "C++" {} block, otherwise the symbols end up as locals in the final library, and thus get stripped out of the installed version. -Dimitry On 22 Feb 2017, at 16:19, hartmut.bra...@dlr.de wrote: > > Looks like they are still not there. I've rebuilt world. > > nm -D -C /usr/lib/libcxxrt.so | grep 128 > > should show me the symbols, right? It does not. > > harti > > -Original Message- > From: Dimitry Andric [mailto:d...@freebsd.org] > Sent: Tuesday, February 21, 2017 10:52 PM > To: Brandt, Hartmut > Cc: curr...@freebsd.org > Subject: Re: int128_t and uint128_t typeinfo > > On 21 Feb 2017, at 18:26, Dimitry Andric wrote: >> >> On 21 Feb 2017, at 13:48, Hartmut Brandt wrote: >>> >>> it looks like the typeinfo for __int128_t and __uint128_t is missing from >>> our dynamically linked libcxxrt. > ... >> * We also need to add the typeinfo for __u?int128_t * and __u?int128_t >> const * >> * Maybe these should be under the CXXABI_2.0 version, since that is >> where newer libstdc++ places them >> * Maybe these should be dependent on whether the architecture supports >> 128 bit integers at all >> >> I need to think a bit on the above, then I'll commit a fix. > > Okay, can you please try r314061? > > -Dimitry > signature.asc Description: Message signed with OpenPGP
Lock order reversal [ newbie ] report
#0 #16 follow: jotted down : 1. ufs /usr/src/sys/kern/vfs_syscalls.c:3364 2. bufwait /usr/src/sys/ufs/ffs/ffs_vnops.c:280 3. ufs /usr/src/sys/kern/vfs_subr.c:2600 [ took roxterm out of the xinitrc, system stable seems more than yesterday... too early to tell, which is/was a 2nd issue... put in urxvt and st... based on TOP memory... ] ___ 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: Lock order reversal [ newbie ] report [2nd one]
This one at boot: #0 to #10 bufwait /usr/src/sys/kern/vfs_bio.c:3500 dirhash /usr/src/sys/ufs/ufs/ufs_dirhash.c:201 r313487 12.0-CURRENT Feb 13 2017 1200020 FWIW both the above and the below reports... On Wed, 22 Feb 2017 15:37:21 -0800 (PST), "Jeffrey Bouquet" wrote: > #0 #16 follow: > jotted down : > > 1. ufs /usr/src/sys/kern/vfs_syscalls.c:3364 > 2. bufwait /usr/src/sys/ufs/ffs/ffs_vnops.c:280 > 3. ufs /usr/src/sys/kern/vfs_subr.c:2600 > > [ took roxterm out of the xinitrc, system stable seems more than yesterday... > too > early to tell, which is/was a 2nd issue... put in urxvt and st... based on > TOP memory... ] > ___ > 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: Lock order reversal [ newbie ] report [2nd one]
Hi Jeffrey, Thank you for your enthusiasm in reporting these. Unfortunately, it is very likely that these two are "well-known" and believed to be harmless, so you have not discovered something terribly exciting. An old and no-longer particularly maintained listing of these and other LORs is at: http://sources.zabbadoz.net/freebsd/lor.html -Ben On Wed, Feb 22, 2017 at 06:20:08PM -0800, Jeffrey Bouquet wrote: > This one at boot: > #0 to #10 > bufwait > /usr/src/sys/kern/vfs_bio.c:3500 > dirhash > /usr/src/sys/ufs/ufs/ufs_dirhash.c:201 > > r313487 12.0-CURRENT Feb 13 2017 > 1200020 FWIW > both the above and the below reports... > > > > > On Wed, 22 Feb 2017 15:37:21 -0800 (PST), "Jeffrey Bouquet" > wrote: > > > #0 #16 follow: > > jotted down : > > > > 1. ufs /usr/src/sys/kern/vfs_syscalls.c:3364 > > 2. bufwait /usr/src/sys/ufs/ffs/ffs_vnops.c:280 > > 3. ufs /usr/src/sys/kern/vfs_subr.c:2600 > > > > [ took roxterm out of the xinitrc, system stable seems more than > > yesterday... too > > early to tell, which is/was a 2nd issue... put in urxvt and st... based on > > TOP memory... ] > > ___ > > 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"