Re: Lock order reversal [ newbie ] report [2nd one]

[Benjamin Kaduk]

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"

Re: Lock order reversal [ newbie ] report [2nd one]

[Jeffrey Bouquet]

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"

Lock order reversal [ newbie ] report

[Jeffrey Bouquet]

#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: int128_t and uint128_t typeinfo

[Dimitry Andric]

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

Re: TSC as timecounter makes system lag

[Jia-Shiun Li]

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: r313938 breaks portsnap

[Allan Jude]

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: int128_t and uint128_t typeinfo

[Hartmut.Brandt]

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"