Re: Bug in make setting wrong MAKESYSPATH

2017-05-28 Thread Simon J. Gerraty 
Thomas Mueller  wrote:
> Just because I found a workaround does not mean it is not a bug.

Sorry I don't know what else to tell you.
make is behaving as it should, based on the way it is configured.

That setup was deemed the most useful by those working on src/,
so is not likely to be changed.

I guess we should add a note to the man page...
___
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: firefox/ rust failed to install on FreeBSD 12-CURRENT

2017-05-28 Thread Kevin Oberman 
On Sun, May 28, 2017 at 1:12 PM, blubee blubeeme 
wrote:

> I am using the default tcsh shell and sudo -c isn't a valid sudo command.
>
>
> On Mon, May 29, 2017 at 3:49 AM, Kevin Oberman 
> wrote:
>
>> On Sun, May 28, 2017 at 12:24 PM, Konstantin Belousov <
>> kostik...@gmail.com> wrote:
>> [...]
>> More exactly, don't build rust with 'sudo buildcommand' where
>> 'buildcommand' could be make, portmaster, or any other command that will
>> build rust.
>>
>> You can, however, 'sudo -c' and then run the build with no problem. I do
>> this regularly. 'sudo -c' really makes your environment into root with a
>> new shell and you must 'exit' to get back to being yourself.
>> --
>> Kevin Oberman, Part time kid herder and retired Network Engineer
>> E-mail: rkober...@gmail.com
>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>>
>
>
Brain, meet fingers. Fingers, meet brain.

It's 'sudo -s'. Don't know why I typed 'c'. And did it twice! Sorry!
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: NFS client perf. degradation when SCHED_ULE is used (was when SMP enabled)

2017-05-28 Thread Rick Macklem 
I wrote:
[stuff snipped]
> So, I'd say either reverting the patch or replacing it with the "obvious 
> change" mentioned
> in the commit message will at least mostly fix the problem.
"mostly fix" was probably a bit optimistic. Here's my current #s.
(All cases are the same single threaded kernel build, same hardware, etc. The 
only
 changes are recent vs 1yr old head kernel and what is noted.)

- 1yr old kernel, SMP, SCHED_ULE94minutes
- 1yr old kernel, no SMP, SCHED_ULE 111minutes

- recent kernel, SMP, SCHED_4BSD  104minutes
- recent kernel, no SMP, SCHED_ULE   113minutes
- recent kernel, SMP, SCHED_ULE,
   r312426 reverted  122minutes
- recent kernel, SMP, SCHED_ULE 148minutes

So, reverting r312426 only gets rid of about 1/2 of the degradation.
One more thing I will note is that the system CPU is higher for the cases that 
run
with lower/better elapsed times:
- 1yr old kernel, SMP, SCHED_ULE545s
- 1yr old kernel, no SMP, SCHED_ULE   293s
- recent kernel, no SMP, SCHED_ULE292s
- recent kernel, SMP, SCHED_ULE 466s

cperciva@ is running a highly parallelized buuildworld and he sees better
slightly better elapsed times and much lower system CPU for SCHED_ULE.

As such, I suspect it is the single threaded, processes mostly sleeping waiting
for I/O case that is broken.
I suspect this is how many people use NFS, since a highly parallelized make 
would
not be a typical NFS client task, I think?

There are other changes to sched_ule.c in the last year, but I'm not sure which
would be easy to revert and might make a difference in this case?

rick
ps: I've cc'd cperiva@ and he might wish to report his results. I am hoping he
  does try a make without "-j" at some point.
___
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"

firefox/ rust failed to install on FreeBSD 12-CURRENT

2017-05-28 Thread blubee blubeeme 
I'm trying to install firefox on FreeBSD
FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT
#0 r318998: Sun May 28 04:38:22 CST 2017
/usr/obj/usr/src/sys/GENERIC  amd64

===>   firefox-i18n-53.0.3 depends on file: /usr/local/lib/firefox/firefox
- not found
===>   firefox-53.0.3_1,1 depends on package: nspr>=4.13.1 - found
===>   firefox-53.0.3_1,1 depends on package: nss>=3.29.5 - found
===>   firefox-53.0.3_1,1 depends on package: libevent>=2.0.21_2 - found
===>   firefox-53.0.3_1,1 depends on package: harfbuzz>=1.4.1 - found
===>   firefox-53.0.3_1,1 depends on package: graphite2>=1.3.8 - found
===>   firefox-53.0.3_1,1 depends on package: png>=1.6.28 - found
===>   firefox-53.0.3_1,1 depends on package: libvorbis>=1.3.5,3 - found
===>   firefox-53.0.3_1,1 depends on package: libvpx>=1.5.0 - found
===>   firefox-53.0.3_1,1 depends on package: sqlite3>=3.17.0 - found
===>   firefox-53.0.3_1,1 depends on package: py27-sqlite3>0 - found
===>   firefox-53.0.3_1,1 depends on package: v4l_compat>0 - found
===>   firefox-53.0.3_1,1 depends on executable: autoconf-2.13 - found
===>   firefox-53.0.3_1,1 depends on executable: yasm - found
===>   firefox-53.0.3_1,1 depends on executable: zip - found
===>   firefox-53.0.3_1,1 depends on package: gtk3>=3.14.6 - found
===>   firefox-53.0.3_1,1 depends on package: libnotify>0 - found
===>   firefox-53.0.3_1,1 depends on executable: rustc - not found
===>  Building for rust-1.17.0
gmake[7]: Entering directory '/usr/ports/lang/rust/work/rustc-1.17.0-src'
"/usr/local/bin/python2.7"
/usr/ports/lang/rust/work/rustc-1.17.0-src/src/bootstrap/bootstrap.py build
-v
info: looks like you are running this command under `sudo`
  and so in order to preserve your $HOME this will now
  use vendored sources by default. Note that if this
  does not work you should run a normal build first
  before running a command like `sudo make install`
extracting
/usr/ports/lang/rust/work/rustc-1.17.0-src/build/cache/2017-03-11/rust-std-1.16.0-x86_64-unknown-freebsd.tar.gz
  extracting
rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd
  extracting
rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib
  extracting
rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/
manifest.in
  extracting
rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib/rustlib
  extracting
rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd
  extracting
rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd/lib
  extracting
rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd/lib/GNUSparseFile.0/librustc_llvm-74a1be1110b5d4d0.so
gmake[7]: Leaving directory '/usr/ports/lang/rust/work/rustc-1.17.0-src'
*** Error code 1

Stop.
make[6]: stopped in /usr/ports/lang/rust
*** Error code 1

Stop.
make[5]: stopped in /usr/ports/lang/rust
*** Error code 1

Stop.
make[4]: stopped in /usr/ports/www/firefox
*** Error code 1

Stop.
make[3]: stopped in /usr/ports/www/firefox
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/www/firefox-i18n
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/www/firefox-i18n
*** Error code 1

Stop.
make: stopped in /usr/ports/www/firefox-i18n


I am getting build failures with or without make_build_unsafe flags.

I am building from source and ports tree is updated to revision 441919.

Best,
Owen
___
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: INO64 Effecting Firefox

2017-05-28 Thread Oleg V. Nauman 
On Sunday 28 May 2017 18:09:19 O. Hartmann wrote:
> Am Sun, 28 May 2017 08:54:35 -0700
> 
> Pete Wright  schrieb:
> > Hi all,
> > 
> > I can't imagine that this is related to INO64, but since upgrading my
> > world and kernel on drm-next (which merged upstream CURRENT as of May 27
> > which should include the ino64 work) I am having segfaults running
> > firefox.  Previous to this firefox was very stable for work/personal
> > daily use.
> > 
> > The error I'm seeing is:
> > Full message: TypeError: malformed UTF-8 character sequence at offset 0
> > 
> > Firefox does start and I can load a page or two before it sefaults.
> > 
> > The full console output is here:
> > 
> > https://gist.github.com/anonymous/555202b1452503ad9e26750168f87d5f
> > 
> > 
> > Posting this here in the off chance that it's either related to ino64,
> > or some other recent change has caused this problem.
> > 
> > Cheers!
> > 
> > -pete
> 
> I see similar problems. Out of the blue, firefox crashes.
> But in my case, firefox is "old", since it doesn't compile with
> WITH_LLD_IS_LD due to a very strange error (Bug 218808).
> 
> The binary I run und CURRENT (FreeBSD 12.0-CURRENT #8 r319001: Sun May 28
> 00:21:16 CEST 2017 amd64, WITH_LLD_IS_LD=yes) if as of
> 
> firefox-53.0_2,1
> Name   : firefox
> Version: 53.0_2,1
> Installed on   : Sun Apr 16 10:17:14 2017 CEST
> Origin : www/firefox
> Architecture   : FreeBSD:12:amd64
> 
> I got a kind of relief (means: the frequence of crashes is reduced) when
> starting to rebuild all ports again (I'm staying with make and portmaster)
> to meet ABI requirements after ino64 has been introduced.
> 
> Another strange behaviour is: firefox crashes very likely very often when
> started. Once it has run a while, I can consider it "stable". It doen not
> crash then.

 Please try to rebuild firefox. It helps me today with firefox-esr segfaulting 
on my desktop running 12.0-CURRENT r318856
 From my limited understanding of stacktraces it was related to libthr 
changes.

___
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: INO64 Effecting Firefox

2017-05-28 Thread O. Hartmann 
Am Sun, 28 May 2017 08:54:35 -0700
Pete Wright  schrieb:

> Hi all,
> 
> I can't imagine that this is related to INO64, but since upgrading my 
> world and kernel on drm-next (which merged upstream CURRENT as of May 27 
> which should include the ino64 work) I am having segfaults running 
> firefox.  Previous to this firefox was very stable for work/personal 
> daily use.
> 
> The error I'm seeing is:
> Full message: TypeError: malformed UTF-8 character sequence at offset 0
> 
> Firefox does start and I can load a page or two before it sefaults.
> 
> The full console output is here:
> 
> https://gist.github.com/anonymous/555202b1452503ad9e26750168f87d5f
> 
> 
> Posting this here in the off chance that it's either related to ino64, 
> or some other recent change has caused this problem.
> 
> Cheers!
> 
> -pete
> 
> 

I see similar problems. Out of the blue, firefox crashes.
But in my case, firefox is "old", since it doesn't compile with WITH_LLD_IS_LD 
due to a
very strange error (Bug 218808).

The binary I run und CURRENT (FreeBSD 12.0-CURRENT #8 r319001: Sun May 28 
00:21:16 CEST
2017 amd64, WITH_LLD_IS_LD=yes) if as of

firefox-53.0_2,1
Name   : firefox
Version: 53.0_2,1
Installed on   : Sun Apr 16 10:17:14 2017 CEST
Origin : www/firefox
Architecture   : FreeBSD:12:amd64

I got a kind of relief (means: the frequence of crashes is reduced) when 
starting to
rebuild all ports again (I'm staying with make and portmaster) to meet ABI 
requirements
after ino64 has been introduced.

Another strange behaviour is: firefox crashes very likely very often when 
started. Once
it has run a while, I can consider it "stable". It doen not crash then. 

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgp6nZ0WnC2lb.pgp
Description: OpenPGP digital signature

INO64 Effecting Firefox

2017-05-28 Thread Pete Wright 

Hi all,

I can't imagine that this is related to INO64, but since upgrading my 
world and kernel on drm-next (which merged upstream CURRENT as of May 27 
which should include the ino64 work) I am having segfaults running 
firefox.  Previous to this firefox was very stable for work/personal 
daily use.


The error I'm seeing is:
Full message: TypeError: malformed UTF-8 character sequence at offset 0

Firefox does start and I can load a page or two before it sefaults.

The full console output is here:

https://gist.github.com/anonymous/555202b1452503ad9e26750168f87d5f


Posting this here in the off chance that it's either related to ino64, 
or some other recent change has caused this problem.


Cheers!

-pete


--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
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: NFS client perf. degradation when SCHED_ULE is used (was when SMP enabled)

2017-05-28 Thread Andriy Gapon 
On 28/05/2017 01:20, Rick Macklem wrote:
> After poking at this some more, it appears that r312426 is the main cause of
> this degradation.

Rick,

thank you for the investigation!
A quick question before a longer reply: what network driver do you use in your
test setup?  Is it ixl by a chance?

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