Re: Strange issue after early AP startup

[Hans Petter Selasky]

On 01/23/17 06:27, Jia-Shiun Li wrote:

On Sat, Jan 21, 2017 at 3:51 PM, Hans Petter Selasky 
wrote:


FYI:

https://svnweb.freebsd.org/changeset/base/312551



Hi hps,

sorry I have to correct my test results.
I found that I did not revert changes to kernel config,
which commented out EARLY_AP_STARTUP option,
before testing you patches. So they were tested without
EARLY_AP_STARTUP.

I tested again your patches with kernel config reverted,
and they (and head as of r312620) did not solve the c2d
system time lag issue.

vmstat results attached.
And also my apology for this stupid mistake.



This might be another issue, not related to my patch.

--HPS

___
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: Strange issue after early AP startup

[Jia-Shiun Li]

On Sat, Jan 21, 2017 at 3:51 PM, Hans Petter Selasky 
wrote:

> FYI:
>
> https://svnweb.freebsd.org/changeset/base/312551
>
>
Hi hps,

sorry I have to correct my test results.
I found that I did not revert changes to kernel config,
which commented out EARLY_AP_STARTUP option,
before testing you patches. So they were tested without
EARLY_AP_STARTUP.

I tested again your patches with kernel config reverted,
and they (and head as of r312620) did not solve the c2d
system time lag issue.

vmstat results attached.
And also my apology for this stupid mistake.

-Jia-Shiun.
interrupt  total   rate
???0  0
irq1: atkbd0   2  0
stray irq1 0  0
irq0: attimer0 0  0
stray irq0 0  0
irq3:  0  0
stray irq3 0  0
irq4: uart00  0
stray irq4 0  0
irq5:  0  0
stray irq5 0  0
irq6:  0  0
stray irq6 0  0
irq7:  0  0
stray irq7 0  0
irq8: atrtc0   0  0
stray irq8 0  0
irq9: acpi00  0
stray irq9 0  0
irq10: 0  0
stray irq100  0
irq11: 0  0
stray irq110  0
irq12: 0  0
stray irq120  0
irq13: 0  0
stray irq130  0
irq14: 0  0
stray irq140  0
irq15: 0  0
stray irq150  0
irq16: em0:irq0++ 18  0
stray irq160  0
irq17: 0  0
stray irq170  0
irq18: uhci2 ehci0+   18  0
stray irq180  0
irq19: uhci4   0  0
stray irq190  0
irq20: hpet0   12503277
stray irq200  0
irq21: uhci1   0  0
stray irq210  0
irq22: 0  0
stray irq220  0
irq23: uhci3 ehci1 0  0
stray irq230  0
cpu0:timer 0  0
cpu1:timer 0  0
irq256: hdac0 97  2
stray irq256   0  0
irq257: pcib1  0  0
stray irq257   0  0
irq258: pcib2  0  0
stray irq258   0  0
irq259: pcib3  0  0
stray irq259   0  0
irq260: re0 9049201
stray irq260   0  0
irq261: ahci0:ch0   4186 93
stray irq261   0  0
irq262: ahci0:ch1  0  0
stray irq262   0  0
irq263: ahci0:ch2  0  0
stray irq263   0  0
irq264: ahci0:ch3  0  0
stray irq264   0  0
irq265: ahci0:ch4  0  0
stray irq265   0  0
irq266: ahci0:ch5  0  0
stray irq266   0  0
irq267: ahci0:60  0
stray irq267   0  0
irq268: ahci0:70  0
stray irq268   0  0
irq269: ahci0:80  0
stray irq269   0  0
irq270: ahci0:90  0
stray irq270   0  0
irq271: ahci0:10   0  0
stray irq271   0  0
irq272: ahci0:11   0  0
stray irq272   0  0
irq273: ahci0:12   0 

command line environment and port to equal CURRENT clang?

[Jeffrey Bouquet]

... that may work in /usr/src/sbin for example?
make clang=[/usr/ports/lang/??]clang-foo clang+ depend;   make;   # so that a 
buildworld is not needed?
or that would have to be created as a feature..
___
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: Linker problems with clang /usr/local/lib

[Dimitry Andric]

It only does so on Linux.  This has always been the case, but apparently
it was never noted clearly in the man page.

-Dimitry

> On 22 Jan 2017, at 21:57, Johannes Lundberg  wrote:
> 
> I found a way to pass various linker flags to Rust through the .cargo/config 
> file which is doable for now.
> 
> However, in man pages it says that ld looks in /etc/ld.so.conf for paths.. 
> This seem broken. While a solution, having to write wrappers sounds like a 
> workaround that shouldn't be needed...
> 
> 
> On Sun, Jan 22, 2017 at 12:42 PM, Dimitry Andric  wrote:
> On 22 Jan 2017, at 21:29, Johannes Lundberg  wrote:
> >
> > How can I make 'cc' (/usr/bin/ld) look for libraries in /usr/local/lib
> > without having to specify environment or command line variables?
> >
> > I got "/usr/local/lib" in /etc/ld.so.conf and /var/run/ld-elf.so.hints.
> >
> > /sbin/ldconfig -l xxx can find library xxx in /usr/local/lib
> >
> > /usr/bin/ld can not.
> >
> > This is a problem when building Rust crates with Cargo which does not care
> > about env variables like LDFLAGS. I can however override the linker and use
> > 'gcc' which solves the problem but I assume it should be possible to get
> > clang (cc) to look in /usr/local/lib as well.
> >
> > Anyone got any ideas?
> 
> Create a wrapper script that adds -L/usr/local/lib to the link command
> line, and invokes the 'real' cc or ld.  Then either let Rust call the
> wrappers, or put them in a directory that is in front of your PATH.
> 
> -Dimitry
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Linker problems with clang /usr/local/lib

[Johannes Lundberg]

I found a way to pass various linker flags to Rust through the
.cargo/config file which is doable for now.

However, in man pages it says that ld looks in /etc/ld.so.conf for paths..
This seem broken. While a solution, having to write wrappers sounds like a
workaround that shouldn't be needed...


On Sun, Jan 22, 2017 at 12:42 PM, Dimitry Andric  wrote:

> On 22 Jan 2017, at 21:29, Johannes Lundberg  wrote:
> >
> > How can I make 'cc' (/usr/bin/ld) look for libraries in /usr/local/lib
> > without having to specify environment or command line variables?
> >
> > I got "/usr/local/lib" in /etc/ld.so.conf and /var/run/ld-elf.so.hints.
> >
> > /sbin/ldconfig -l xxx can find library xxx in /usr/local/lib
> >
> > /usr/bin/ld can not.
> >
> > This is a problem when building Rust crates with Cargo which does not
> care
> > about env variables like LDFLAGS. I can however override the linker and
> use
> > 'gcc' which solves the problem but I assume it should be possible to get
> > clang (cc) to look in /usr/local/lib as well.
> >
> > Anyone got any ideas?
>
> Create a wrapper script that adds -L/usr/local/lib to the link command
> line, and invokes the 'real' cc or ld.  Then either let Rust call the
> wrappers, or put them in a directory that is in front of your PATH.
>
> -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: Linker problems with clang /usr/local/lib

[Dimitry Andric]

On 22 Jan 2017, at 21:29, Johannes Lundberg  wrote:
> 
> How can I make 'cc' (/usr/bin/ld) look for libraries in /usr/local/lib
> without having to specify environment or command line variables?
> 
> I got "/usr/local/lib" in /etc/ld.so.conf and /var/run/ld-elf.so.hints.
> 
> /sbin/ldconfig -l xxx can find library xxx in /usr/local/lib
> 
> /usr/bin/ld can not.
> 
> This is a problem when building Rust crates with Cargo which does not care
> about env variables like LDFLAGS. I can however override the linker and use
> 'gcc' which solves the problem but I assume it should be possible to get
> clang (cc) to look in /usr/local/lib as well.
> 
> Anyone got any ideas?

Create a wrapper script that adds -L/usr/local/lib to the link command
line, and invokes the 'real' cc or ld.  Then either let Rust call the
wrappers, or put them in a directory that is in front of your PATH.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Linker problems with clang /usr/local/lib

[Johannes Lundberg]

Hi

How can I make 'cc' (/usr/bin/ld) look for libraries in /usr/local/lib
without having to specify environment or command line variables?

I got "/usr/local/lib" in /etc/ld.so.conf and /var/run/ld-elf.so.hints.

/sbin/ldconfig -l xxx can find library xxx in /usr/local/lib

/usr/bin/ld can not.

This is a problem when building Rust crates with Cargo which does not care
about env variables like LDFLAGS. I can however override the linker and use
'gcc' which solves the problem but I assume it should be possible to get
clang (cc) to look in /usr/local/lib as well.

Anyone got any ideas?
___
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: Fix /etc/rc.d/random umask handling (/entropy permissions)

[Jilles Tjoelker]

On Sun, Jan 22, 2017 at 01:22:07AM +, Lu Tung-Pin wrote:
> On 2017-01-21 22:01, Jilles Tjoelker wrote:
> > [Adding Cc: Dag-Erling Smørgrav who committed r273957 which seems to
> > have introduced this]
> > On Sat, Jan 21, 2017 at 01:21:42AM +, Lu Tung-Pin wrote:
> >> A 2014 change broke the umask handling in /etc/rc.d/random,
> >> leaving /entropy with ug+r permissions. Quick fix attached,

> Edit: go+r permissions.

> > Switching the umask here will avoid incorrect permissions on
> > /entropy on new installations, but will not fix existing systems. A
> > chmod command may be useful here.

> Note that random_start() first removes /entropy via feed_dev_random().
> There's also a removal in random_stop(). Provided that a removal occurs,
> the chmod won't be necessary on machines with an existing go+r /entropy.

Right, /entropy is deleted after being read so the chmod is not needed.

> I'm wondering, though: Would it be better to replace all the umask
> fiddling with simple chmods? Every other rc.d script uses chmod if it
> needs to set tighter permissions. When umask is used (dmesg, mountd,
> syslogd), it's with a relaxed 022 setting.

The umask ensures the file is created with the correct permissions so
there is no race window where an unprivileged process can open the file.
A permissions change has no existing opens.

-- 
Jilles Tjoelker
___
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: ISO image: where is the CLANG compiler?

[A. Wilcox]

On 19/01/17 03:16, O. Hartmann wrote:
> I created images on CURRENT of my own - they all lack in the ability of having
> the necessary tools aboard. So I consider every image useless for rescue
> operations except, maybe, the DVD image - but this one is not provided 
> anymore.
> For what reason? Time? Accepted. Space/disk usage? Well, welcome back in the
> stoneage of computer technology ... 
> 
> I remember faintly that there was a small discussion on the @CURRENT list, but
> I didn't realize that the result would be the extraction of the compiler.
> 
> Just for the record: most servers delivered to us do not have CD/DVD drives
> anymore - they are outdated and considered an extra these days. Purchasing 1 
> GB
> USB thumbdrives is getting even harder, smallest size my employer provides now
> is 2 GB. And most optical drives are DVD. From my point of view - and this is 
> a
> personal view - the "standard" is > 1GB so there is no need to break down by
> force the FreeBSD image (if size is the reason) down to < 800 MB or < 1 GB. 
> I'd
> consider having < 2GB the line of standards (2 GB USB mem drive).
> And for those, with need of very small images, smaller images could be 
> provided
> as the extra.


Installation media is not rescue media.  Perhaps there should be a
dedicated rescue disc that does not contain bsdinstall and the sets (we
used to have "fixit" media until at least 8.x days).

Everything else I have to say, I have said before:

 Forwarded Message 
Received: (qmail 20810 invoked from network); 12 Jul 2016 21:08:51 -
Subject: Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
To: freebsd-current@freebsd.org
From: A. Wilcox 
Message-ID: <5785692e.8090...@wilcox-tech.com>
Date: Tue, 12 Jul 2016 17:03:26 -0500
In-Reply-To: <51734d0a-60da-6439-b5c1-1af14e740...@multiplay.co.uk>

On 12/07/16 15:58, Steven Hartland wrote:
> On 12/07/2016 21:50, Slawa Olhovchenkov wrote:
>> On Tue, Jul 12, 2016 at 01:39:34PM -0700, Conrad Meyer wrote:
>>
>>> Maybe Tier 2 can deal with just bootonly.iso.  Or your machines should
>>> be dropped from Tier 2 if they don't support USB and we aren't okay
>>> with dropping disc1 support for all of Tier 2.

That is pretty much all SPARC hardware and a lot of POWER hardware.  Not
to mention newer rack-mount servers that have no USB on front (IBM).

And what of the servers that already have functional CD drives?  Do we
really now have to recommending buying SCSI/SATA slimline or USB DVD
drives just to boot installation media?  That's a heavy cost when you
can fit nearly all other BSDs on a single regular 650 (84 MB for NetBSD
7.0.1 + 223 MB for OpenBSD 5.9 + 385 MB for "TrueOS"/PC-BSD Server 10.3
= 692 MB, all sizes amd64 install iso including sets).

>> Not all BIOS can be boot from USB.
>> I am have Fujitsu notebook not support USB boot.
> From a USB Pen drive I can understand but from a USB DVD Drive that
> would be some seriously antiquated hardware!

I have a Core 2-era Xeon board (Wolfdale-DP, Intel 5000 based) that
cannot under any circumstances boot from a connected USB device.  It
won't boot from a USB DVD, USB CD, USB pen, or USB hard disk (USBMSC).
I hardly consider a server that is 7 years old "antiquated" though I
concede it is not the newest.

Beyond that, there are security issues with allowing servers to boot off
of any random USB device that an admin has lying around.  Most will be
configured by good admins to not do such a thing.

In summary: NAK NAK NAK.  USB is not a solution.  Bringing down the
bloat on disc1 or returning to miniinst is the proper solution.

~arw


-- 
A. Wilcox (awilfox)
Open-source programmer (C, C++, Python)
https://code.foxkit.us/u/awilfox/



signature.asc
Description: OpenPGP digital signature

Re: r312602: panic: Panic String: __lockmgr_args: unknown lockmgr request 0x0

[Julian Elischer]

On 22/01/2017 4:51 AM, O. Hartmann wrote:

Am Sat, 21 Jan 2017 21:13:49 +0100
Mateusz Guzik  schrieb:


On Sat, Jan 21, 2017 at 08:45:55PM +0100, O. Hartmann wrote:

The most recent CURRENT panics spontanously and crashes with the error message:

  
Panic String: __lockmgr_args: unknown lockmgr request 0x0
   

That's a braino in r312600, will be fixed shortly.


??? What is a "braino"?


it's like a typo but more in the head than in the fingers.

The sort of error you make when your wife/girlfriend/boss/kids 
distract you right in the middle of some bit of code and you forget 
that you just decided to reverse the sense of the conditional, and 
complete the rest of the code backwards.


Some of us older folks don't need an external source of confusion.

___
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: r312602: panic: Panic String: __lockmgr_args: unknown lockmgr request 0x0

[Dimitry Andric]

On 21 Jan 2017, at 21:51, O. Hartmann  wrote:
> 
> Am Sat, 21 Jan 2017 21:13:49 +0100
> Mateusz Guzik  schrieb:
> 
>> On Sat, Jan 21, 2017 at 08:45:55PM +0100, O. Hartmann wrote:
>>> The most recent CURRENT panics spontanously and crashes with the error 
>>> message:
>>> 
>>> 
>>> Panic String: __lockmgr_args: unknown lockmgr request 0x0
>>> 
>> 
>> That's a braino in r312600, will be fixed shortly.
>> 
> 
> ??? What is a "braino"?

typo = typing mistake
pasto = pasting mistake
braino = ... :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail