[SPAM] Re: Official request: Please make GNU grep the default

[Niclas Zeising]

On 2010-08-20 11:10, Dag-Erling Smørgrav wrote:


If you have profiling libraries installed, you can build a profiling
version of grep (or any program) like so:

% cd /usr/src/usr.bin/grep
% make clean
% make DEBUG_FLAGS="-pg -g" -DNO_SHARED

Do *not" make install, because the result will be dog slow and you don't
want to use it in production.  Every time you run it, it will leave a
file named grep.gmon in your current directory, so:



As a side note, this maybe should be posted in the handbook and/or on 
the wiki for reference, so people who want to profile slow applications 
know how to do it.


Regards!
//Niclas
___
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: Call for Documentation Contributors

[Niclas Zeising]

On 2010-09-02 00:46, Gabor PALI wrote:

Hello there,

I am looking for volunteers who are interested in writing
documentation, i.e. working with the FreeBSD Handbook and the
documentation set.  Many of our great documentation writers have
decided to retire from their work over the last years, which means the
FreeBSD Documentation Project is in need of talented, skilled,
determined, and ambitious people who would help to maintain the
tradition of producing high quality documentation for the FreeBSD
operating system.

The documentation set is prepared in DocBook that might seem a bit
complicated at first sight, but I can assure you it can be learned
quickly.  All you need is good writing skills in English, some
knowledge of FreeBSD systems, and willingness to learn even more about
them.  To coordinate and encourage the efforts, I have created a site
[1] called "The FreeBSD Contributor's Documentation Project" that
contains the necessary information.  Note that there are many ways of
contribution: you can comment open Problem Reports or write patches
(by using Mercurial Queues for example), etc. depending on your free
time.  I can help with anything at the regular weekly IRC meetings,
and you can contact me via email directly any time, and hopefully
other documentation developers will also join me.


Thank you for any help in advance.

:g

[1] http://doc.hu.freebsd.org/


Hi!
Just a nitpick, would it be possible to move that site to the wiki, 
where most other stuff related to FreeBSD development is? It's not meant 
as critique towards your work, just a suggestion.
Also, a list of open tasks would probably be valuable. For instance a 
list where people who find errors or discrepancies in the docs can add 
them so other people find them and can work on them. I know this is what 
the PR system is built for, but the PR system might be a bid cumbersome 
for just making annotations and stuff like that.
Just some suggestions on how to make this flow better. Hopefully I will 
have some time to actually do some of the work involved too. :)

Keep up the good work!
Best Regards!
//Niclas
___
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: Error message while updating src for FreeBSD 9 current

[Niclas Zeising]

On 2010-09-23 04:29, Ralph Ellis wrote:

Hi,
I recently upgraded my FreeBSD 8.1 installation to FreeBSD 9 current via
buildworld and buildkernel. I was able to one general ports, src and doc
update by cvsup but now I am getting the following error message when I
do a src update.


cvsup srcsupfile
Connected to cvsup2.FreeBSD.org
Updating collection src-all/cvs
Edit src/bin/ps/extern.h
Illegal instruction


I am new to the mailing list. Is this a known error?
Is this an error to do with the source tree or an issue on my end?

Just for reference, the contents of my supfile are

*default tag=.
*default host=cvsup2.FreeBSD.org
*default prefix=/usr
*default base=/var/db
*default release=cvs delete use-rel-suffix compress
src-all
ports-all
doc-all

Thanks in advance for your assistance,
Ralph Ellis
ralphell...@netscape.ca



Are you using cvsup or csup? Have you recompiled cvsup in case you use 
that? What's in your make.conf file?
Illegal instruction is usually because the program is compiled for 
another CPU than what it's running on. It can also be that syscalls has 
changed, but then it usually complains about that.

When doing a major version upgrade, you usually have to recompile all ports.
Hope this helps!
//Niclas
___
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"

[SPAM] Re: Error message while updating src for FreeBSD 9 current

[Niclas Zeising]

On 2010-09-23 13:21, Ralph Ellis wrote:

Niclas Zeising wrote:

On 2010-09-23 04:29, Ralph Ellis wrote:

Hi,
I recently upgraded my FreeBSD 8.1 installation to FreeBSD 9 current via
buildworld and buildkernel. I was able to one general ports, src and doc
update by cvsup but now I am getting the following error message when I
do a src update.


cvsup srcsupfile
Connected to cvsup2.FreeBSD.org
Updating collection src-all/cvs
Edit src/bin/ps/extern.h
Illegal instruction


I am new to the mailing list. Is this a known error?
Is this an error to do with the source tree or an issue on my end?

Just for reference, the contents of my supfile are

*default tag=.
*default host=cvsup2.FreeBSD.org
*default prefix=/usr
*default base=/var/db
*default release=cvs delete use-rel-suffix compress
src-all
ports-all
doc-all

Thanks in advance for your assistance,
Ralph Ellis
ralphell...@netscape.ca



Are you using cvsup or csup? Have you recompiled cvsup in case you use
that? What's in your make.conf file?
Illegal instruction is usually because the program is compiled for
another CPU than what it's running on. It can also be that syscalls
has changed, but then it usually complains about that.
When doing a major version upgrade, you usually have to recompile all
ports.
Hope this helps!
//Niclas


I am using cvsup. I had recompiled my VirtualBox port but I had not
finished recompiling the other major ports. Thanks for the suggestion.
My make.conf is deliberately very plain jane with no special conditions
or comments.
Thanks
Ralph Ellis
ralphell...@netscape.ca





Try to recompile everything, or at least cvsup, and see if it works.
//Niclas
___
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"

[SPAM] Re: Error message while updating src for FreeBSD 9 current

[Niclas Zeising]

On 2010-09-23 14:02, Bartosz Stec wrote:

On 2010-09-23 13:36, Niclas Zeising wrote:

On 2010-09-23 13:21, Ralph Ellis wrote:

Niclas Zeising wrote:

On 2010-09-23 04:29, Ralph Ellis wrote:

Hi,
I recently upgraded my FreeBSD 8.1 installation to FreeBSD 9
current via
buildworld and buildkernel. I was able to one general ports, src
and doc
update by cvsup but now I am getting the following error message
when I
do a src update.


cvsup srcsupfile
Connected to cvsup2.FreeBSD.org
Updating collection src-all/cvs
Edit src/bin/ps/extern.h
Illegal instruction


I am new to the mailing list. Is this a known error?
Is this an error to do with the source tree or an issue on my end?

Just for reference, the contents of my supfile are

*default tag=.
*default host=cvsup2.FreeBSD.org
*default prefix=/usr
*default base=/var/db
*default release=cvs delete use-rel-suffix compress
src-all
ports-all
doc-all

Thanks in advance for your assistance,
Ralph Ellis
ralphell...@netscape.ca



Are you using cvsup or csup? Have you recompiled cvsup in case you use
that? What's in your make.conf file?
Illegal instruction is usually because the program is compiled for
another CPU than what it's running on. It can also be that syscalls
has changed, but then it usually complains about that.
When doing a major version upgrade, you usually have to recompile all
ports.
Hope this helps!
//Niclas


I am using cvsup. I had recompiled my VirtualBox port but I had not
finished recompiling the other major ports. Thanks for the suggestion.
My make.conf is deliberately very plain jane with no special conditions
or comments.
Thanks
Ralph Ellis
ralphell...@netscape.ca





Try to recompile everything, or at least cvsup, and see if it works.
//Niclas


Niclas, did you perform 'make delete-old && make delete-old-libs' after
upgrade to CURRENT? If you did, many of your ports won't longer work
properly (or at all) because of missing libraries. If you didn't, you
definitely should do something like 'portupgrade -afrRi' and after you
done, you can get rid of these old files with commands above.


You wouldn't get illegal instruction then though. Usually the 
application fails to load if dynamic libraries are missing.




Of course it could take VERY long time depending on installed ports and
machine spec., so if you just need to get your sources updated quickly I
recommend:

1. Try csup instead of cvsup. It's integrated in both 8.x and in
CURRENT, so should work "out of the box"


That's a good idea.


2. If you (for some strange reasons) want to stick to cvsup, you'll
probably make it work again by portupgrade -fR 'cvsup*'
3. another approach is to get cvsup binaries from package instead of
compiling ports - check man pkg_add
4. If you need cvsup to update ports tree, try portsnap instead. It's
faster and smarter, and integrated with system :) - check man portsnap

Good luck!


//Niclas
___
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: Error message while updating src for FreeBSD 9 current

[Niclas Zeising]

Thanks for all the helpful suggestions.
csup worked like a charm and solved the problem. I will be rebuilding my
ports gradually, starting with the development ports like Perl, gcc,
clang etc.

I am also experimenting with a custom kernel where I am eliminating
drivers and modules for isa, wireless devices and hardware only found on
laptops. The early results are encouraging. I run fold...@home in a
VirtualBox with Unbuntu x64 as a guest OS. Since trying a custom kernel,
floating point performance has improved over 20%. This may also be due
to some kernel improvements in FreeBSD 9. So far I am very impressed
with the stability of the OS. I have not had problems with any of the
programs that I run on a regular basis. I had expected to hit more bugs.
I will get started on the rebuilds but with 1700 ports installed, I will
wait for a free weekend to compile the big stuff.
Thanks again
Ralph Ellis
ralphell...@netscape.ca




Glad to hear everything worked out in the end!
Just a side note, clang is already included in the base system in 
FreeBSD 9, so unless you've opted out from that with WITHOUT_CLANG in 
/etc/src.conf then you don't need the port.

Regards!
//Niclas
___
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"

[PATCH] update to NTP in base

[Niclas Zeising]

Hello!
The instructions at
http://www.freebsd.org/cgi/query-pr.cgi?pr=148836
(Pr bin/148836) contains an update to the base system NTP program suite. 
Please test it and report successes and failures.
Known issues: The html doc distribution is not installed, but it can be 
found on the internet if needed. If it is requested by many to include 
it I'll make a new patch for it.


The patch can be found here
http://www.lysator.liu.se/~zeising/FreeBSD/ntp-update/ntpupdate.diff 
(uncompressed, 10M)
http://www.lysator.liu.se/~zeising/FreeBSD/ntp-update/ntpupdate.diff.bz2 
(compressed with bz2, 1.7M)
The reason for the sizes is that the patches include a lot of changes to 
the vendor code. See the PR for details.


Best Regards!
//Niclas
___
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: priority of paths to kernel modules?

[Niclas Zeising]

On 08/24/18 17:20, Warner Losh wrote:

 This would allow the graphics port to have a rc script that sets
this up so when X11 goes to automatically load the module, the right one
gets loaded.



I just want to point out that X11 doesn't load the graphics kernel 
driver by default when using the drm-*-kmod ports, and I'm not sure the 
hack to have the intel ddx (xf86-video-intel) load the drm2 driver is 
still around.


It doesn't really matter though, since upstream is moving away from 
having X load the driver, and I'd like us to follow suit by using 
devmatch (this is one of the reasons we wanted to get rid of the base 
drivers, as I've stated before).  X can't always know which driver to 
load (when using modesetting for instance), and in my opinion, it should 
be the kernel/loader that decides which drivers to load.


Regards
--
Niclas Zeising
___
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: Problem starting Xorg

[Niclas Zeising]

On 10/2/18 7:02 PM, Filippo Moretti wrote:

I get the following error while attemptong to start xorg,that did work until 
today,amd64 alpha3drmn0:error:no GEM object associated to handle 0x0400 
can't  create framebufferany help appreciatedFilippo


Hi!
Can you provde your Xorg log, as well as information about the hardware 
you are using, and which ports you have installed, and the output of 
kldstat -v | grep drm.  Thank you!

Regards
--
Niclas
___
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: Dependencies – drm-kmod, drm-stable-kmod and drm-next-kmod

[Niclas Zeising]

On 10/7/18 7:17 AM, Graham Perrin wrote:

According to <https://www.freshports.org/graphics/drm-kmod/#requiredtorun>:

- for drm-kmod, drm-stable-kmod is the sole runtime dependency.

Below, I see -next- (not -stable-):

$ pkg rquery %dn graphics/drm-kmod
drm-next-kmod
drm-next-kmod
$

– is that contrary to what's at FreshPorts? (Do I misunderstand something?)



More:

$ pkg rquery %rn graphics/drm-kmod
$

$ pkg rquery %dn graphics/drm-stable-kmod
gpu-firmware-kmod
gpu-firmware-kmod
$ pkg rquery %rn graphics/drm-stable-kmod
$

$ pkg rquery %dn graphics/drm-next-kmod
gpu-firmware-kmod
gpu-firmware-kmod
$ pkg rquery %rn graphics/drm-next-kmod
drm-kmod
drm-kmod
$

– is there _truly_ intended to be some dependency between drm-next-kmod and 
drm-kmod?



Hi!
The version of drm-*-kmod that's pulled in is dependent on your FreeBSD 
version.  The dependenvy shown on FreshPorts is probably based on the 
version of FreeBSD FreshPorts is using to parse the ports tree.


gpu-firmware-kmod is a dependency of all drm-*-kmod ports, but it's not 
a direct dependency of drm-kmod.


Regards
--
Niclas Zeising
___
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 x11-servers/xorg-server and CVE-2018-14665

[Niclas Zeising]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

[ cross posted to several FreeBSD lists.
Please keep replies to x...@freebsd.org ]

Hi!
As some of you are aware, the X.org project posted a security advisory
on October 25 regarding a vulnerability in xorg-server [1].
This has been given the identifier CVE-2018-14665 [2].

The version of xorg-server in the FreeBSD ports tree is not vulnerable.

In short, there is a vulnerability in versions 1.19 through 1.20.2 of
xorg-server, when installed setuid root, which allows an attacker to
overwrite or create any file on the system.  By using this
vulnerability, a local user can gain root privileges.  There are several
articles about this [3] [4].

The code in question was introduced on xorg-server 1.19, and as FreeBSD
is still using xorg-server 1.18.4 we are not vulnerable to this issue.

If you have questions or comments regarding this, don't hesitate to
contact me or to send a message to the x...@freebsd.org mailing list.

Regards
- -- 
Niclas Zeising

FreeBSD X11/Graphics Team

[1] https://lists.x.org/archives/xorg-announce/2018-October/002927.html
[2] https://nvd.nist.gov/vuln/detail/CVE-2018-14665
[3] 
https://arstechnica.com/information-technology/2018/10/x-org-bug-that-gives-attackers-root-bites-openbsd-and-other-big-name-oses/

[4] https://www.securepatterns.com/2018/10/cve-2018-14665-xorg-x-server.html

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE+Ll/478KgNjo+JKEu41LV7uLVVEFAlvU0WMACgkQu41LV7uL
VVGgBw/+O7pIgdU5IvommsSetDAHPmdq3wy2j5mnWTjZXxz4qRe6pVJ6a0hJdkLw
8eSZGvPSo05Tnzk3Vx0cFdZ0hPIxm6Yp7dDpO6sXKDlxQrqDoxjPkjGMPj0897F+
4hw7RWW9O5EEDlBHjL8+Uektkk2N7MjrlbNc2IZ+eHnH8XjQ5yDOFHT9NKLeAZeP
ReJR/kN/+tW9VtzJtolk7vnksc8OF8ortsPX7dEXzoc1uHwppEoDlwQZrVRVuyCk
j6JzrOthEVEnxvdvVmcQueijhzKE/2g1Ix82gYEfcHA1172kMWJka1m9Og2mKGqW
8aqKilpCv6koPXtWACeG5P8nG9+SpDH6HMhjpjQqdKG80x+0I9dbAu5mL9fTVKjp
iFcY+8EQzsUYHEkvS9qk4dgiMR7MMXPM3JtOQOQ94hjoFcIp9toqeDr9U2DuRxAS
LC4EQ1heaiqEtlCOMfkX5BExpBQ3fs+JrTqcDtIHujp7Cv8p19fhmehoXc3hzL0z
xco1ubCOmLmR6Yed+BUxBcguMn37vE6KXDMoW0yQ/jmYt9a4EtECh/bTun81DZwN
gEaFqutcnxzX1AWrYv92VT65OnA9pFXjmb4oU9OQRAiwnP7a8Is0nc7fnSrdtO/Y
CoHWnZKI3hoMMWSXsfEc67RNtJyUnnGLHVvIt1VWrkL1+/WCm6k=
=xBK6
-END PGP SIGNATURE-

___
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 x11-servers/xorg-server and CVE-2018-14665

[Niclas Zeising]

On 10/27/18 11:00 PM, Niclas Zeising wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

[ cross posted to several FreeBSD lists.
Please keep replies to x...@freebsd.org ]



Yes, I know the signature is BAD.  GPG is as user friendly as always. 
I'm about to re-send this with a (hopefully) good signature.

Apologies for the spam.
--
Niclas Zeising
___
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 x11-servers/xorg-server and CVE-2018-14665

[Niclas Zeising]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

[ cross posted to several FreeBSD lists.
Please keep replies to x...@freebsd.org ]

Hi!
As some of you are aware, the X.org project posted a security advisory
on October 25 regarding a vulnerability in xorg-server [1].
This has been given the identifier CVE-2018-14665 [2].

The version of xorg-server in the FreeBSD ports tree is not vulnerable.

In short, there is a vulnerability in versions 1.19 through 1.20.2 of
xorg-server, when installed setuid root, which allows an attacker to
overwrite or create any file on the system.  By using this
vulnerability, a local user can gain root privileges.  There are several
articles about this [3] [4].

The code in question was introduced on xorg-server 1.19, and as FreeBSD
is still using xorg-server 1.18.4 we are not vulnerable to this issue.

If you have questions or comments regarding this, don't hesitate to
contact me or to send a message to the x...@freebsd.org mailing list.

Regards
Niclas Zeising
FreeBSD X11/Graphics Team

[1] https://lists.x.org/archives/xorg-announce/2018-October/002927.html
[2] https://nvd.nist.gov/vuln/detail/CVE-2018-14665
[3] 
https://arstechnica.com/information-technology/2018/10/x-org-bug-that-gives-attackers-root-bites-openbsd-and-other-big-name-oses/

[4] https://www.securepatterns.com/2018/10/cve-2018-14665-xorg-x-server.html

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE+Ll/478KgNjo+JKEu41LV7uLVVEFAlvU1AgACgkQu41LV7uL
VVEbJA//X6jZBPlBgv86w0zD2kxvBEu9wdx4Ib2MwRHAFmnhkv4vkOK37cmkNl35
PJII8TE+9+AoOdm+jybZqJJDqyl54uLh1M46BTuE4LQkvhCyHlMKUaBaQmcBMGyE
9j/hKKr4aaHXwFKZS+Cy/KhKytAOR6le1r07KlmWBTw6SPq4Bm8+KWXjceiFdlkF
GvCF35PeiJ+aIBIT/5ufVJHaUqNZZF8jtuCpNEgSotLogX/HfWYvMhf/ExC6JijA
OuYLjw/xZmGNKg68QM0AN1dFB83JYx/eIZMVCRWj9Rt/ypeF7ISM/qkypW1OOHMr
a9uwEhO6qTr7drfb/pX4/Y+Z9/pumIWQIZgAI9aYzBY9T+op2qifKTFEqpxfXTCj
wuFDKP270la3prhs2hp+q+LgsGxTv9BelodQh5NsNHuKWb6Fzro7Vsy189wg6ulK
E+tQ8qNbWQLfUHVCkCthe1nfLAX2KrOEgDMxWjlgPM5BPIU8JancCjuz02wQ6AiU
lBMfMCW4b5fDZZMqSNNpDW0kiAvXt+aewA23tAmhNSSmSRFXUXlV6UKw3anU3R0G
xVkN8dXnkhWSVfMWXUy92aYHUr1eTZDclSEZlrgJGfLI+DY2OXWDnvsUwm2wPhIR
YSYvrI2iJa31qoF05t6bpJY3USRORHg+OlrGlVnOPXK4rar/Z6M=
=0NLO
-END PGP SIGNATURE-

___
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: drm changes and updating to 12.0

[Niclas Zeising]

On 11/4/18 8:29 PM, Robert Huff wrote:


I have a set of older machines (e.g. AMD Phenom II, Radeon HD3300
gpu) which will be updated from 11. to 12.0 once 12 is out
and the initial round of bugs are squashed.
One system is being done now, to allow time to catch any major
problems and then plan the update process.
Looking at src/UPDATING, the only thing I don't understand is the
whole drm-kmod change.  Is there an authoritative write-up on what's
going on, how to choose the right drivers for my hardware, and how to
do this from source without forcing a fresh install?



We are working on better documentation for this, but the main highlights 
are:  In most cases graphics/drm-kmod should suffice, especially on 
somewhat modern hardware.  You can also install any of the drm-*-kmod 
ports directly, if you want a specific version.  In general graphics 
hardware older than from 2013 requires drm-legacy-kmod instead. 
drm-kmod will also install drm-legacy-kmod on i386.


The same drivers in drm-legacy-kmod is also available in base on 12, so 
you can use the base drivers.  This is deprecated however, and not the 
case for 13-CURRENT.


You can install the drivers either from pkg, if you are using the 
GENERIC kernel, or build from ports if you have a customized kernel or 
if you are tracking for instance 12-STABLE or 13-CURRENT.


If you are using drm-legacy-kmod or the base driver with AMD graphics 
cards you might also need to install xf86-video-ati-legacy rather than 
xf86-video-ati.


Regards
--
Niclas Zeising
___
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: "Oddness" in head since around r343678 or so

[Niclas Zeising]

On 2019-02-08 10:27, Alexander Leidinger wrote:

Hi,

I recently noticed some generic slowness myself. I experienced this 
during replacing disks in a raidz by bigger ones. Long story short, 
check top -s if you have vnlru running for a long period at high CPU... 
If yes increase kern.maxvnodes (I increased to 10 times). Note, we 
should improve the admin page in the FAQ, the vnlru entry could need a 
little bit more hints and explanations.


If you encounter the same issue we have probably introduced a change 
somewhere with an unintended side effect.


Bye,
Alexander.



Hi!
I'm seeing this as well, on 13-CURRENT.  I updated a computer from the 
last January snapshot (30 or 31 of January, I can't remember) and it 
seems disk IO is very slow.  I remember having a svn checkout taking a 
very long time, with the SVN process pegged at 100% according to top.  I 
can't see the vnlru process running though, but I haven't looked 
closely, and I haven't tried the maxvnodes workaround.  Something has 
changed though.
This is systems using ZFS, both mirror and single disk.  Gstat shows 
disks are mostly idle.


I know this is a lousy bug report, but this, and the feeling that things 
are slower than usual, is what I have for now.

Regards
--
___
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: "Oddness" in head since around r343678 or so

[Niclas Zeising]

On 2019-02-10 16:35, Niclas Zeising wrote:

On 2019-02-08 10:27, Alexander Leidinger wrote:

Hi,

I recently noticed some generic slowness myself. I experienced this 
during replacing disks in a raidz by bigger ones. Long story short, 
check top -s if you have vnlru running for a long period at high 
CPU... If yes increase kern.maxvnodes (I increased to 10 times). Note, 
we should improve the admin page in the FAQ, the vnlru entry could 
need a little bit more hints and explanations.


If you encounter the same issue we have probably introduced a change 
somewhere with an unintended side effect.


Bye,
Alexander.



Hi!
I'm seeing this as well, on 13-CURRENT.  I updated a computer from the 
last January snapshot (30 or 31 of January, I can't remember) and it 
seems disk IO is very slow.  I remember having a svn checkout taking a 
very long time, with the SVN process pegged at 100% according to top.  I 
can't see the vnlru process running though, but I haven't looked 
closely, and I haven't tried the maxvnodes workaround.  Something has 
changed though.
This is systems using ZFS, both mirror and single disk.  Gstat shows 
disks are mostly idle.


I know this is a lousy bug report, but this, and the feeling that things 
are slower than usual, is what I have for now.

Regards


Hi!
I did some more digging.  In short, disabling options COVERAGE and 
options KCOV made my test case much faster.


My test:
boot system
create a new zfs dataset (zroot/home/test in my case)
time a checkout of https://svn.freebsd.org/base/head, putting the files 
in the new zfs dataset.


This is in no way scientific, since I only ran the test once on each 
kernel, and using something on the network means I'm susceptible to 
varying network speeds and so on, but.
In this specific scenario, using a kernel without those options, it's 
about 3 times faster than with, at least on the computer where I ran the 
tests.


I noticed in the commit log that the coverage and kcov options has been 
disabled again, albeit for a different reason.  Perhaps they should 
remain off, unless the extra runtime overhead can be disabled in 
runtime, similar to witness.

Regards
--
Niclas
___
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: drm2 removed?

[Niclas Zeising]

On 2/11/19 5:20 PM, Steve Kargl wrote:

On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote:

Anyone have any idea which recent change broke the
drm-legacy-kmod port.  This is why I raised an issue
with removal of drm2 from src/sys.  How is suppose
to be fixed?



It was r343567.  The merging of PAE and NO PAE pmap.h
by kib removed all of the missing macros. :(



The code is still in base, but disabled by default.  I have to have a 
look at this, but it might take a couple of days before we have a fix.

Regards
--
Niclas
___
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: drm2 removed?

[Niclas Zeising]

On 2/11/19 5:20 PM, Steve Kargl wrote:

On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote:

Anyone have any idea which recent change broke the
drm-legacy-kmod port.  This is why I raised an issue
with removal of drm2 from src/sys.  How is suppose
to be fixed?



It was r343567.  The merging of PAE and NO PAE pmap.h
by kib removed all of the missing macros. :(



Can you give attached patch a spin?
Thanks!
Regards
--
Niclas
Index: graphics/drm-legacy-kmod/Makefile
===
--- graphics/drm-legacy-kmod/Makefile	(revision 492695)
+++ graphics/drm-legacy-kmod/Makefile	(working copy)
@@ -22,7 +22,7 @@
 USE_GITHUB=	yes
 GH_ACCOUNT=	FreeBSDDesktop
 GH_PROJECT=	drm-legacy
-GH_TAGNAME=	50ea058
+GH_TAGNAME=	1550ba3
 
 .include 
 
Index: graphics/drm-legacy-kmod/distinfo
===
--- graphics/drm-legacy-kmod/distinfo	(revision 492695)
+++ graphics/drm-legacy-kmod/distinfo	(working copy)
@@ -1,3 +1,3 @@
-TIMESTAMP = 1548274203
-SHA256 (FreeBSDDesktop-drm-legacy-g20190109-50ea058_GH0.tar.gz) = aec43a977d644c65cd1a59297d6d6fd0a8df085932ebc7e2feb1af0823d4fbfe
-SIZE (FreeBSDDesktop-drm-legacy-g20190109-50ea058_GH0.tar.gz) = 1676264
+TIMESTAMP = 1549903495
+SHA256 (FreeBSDDesktop-drm-legacy-g20190109-1550ba3_GH0.tar.gz) = 2922cd4a12594a3e431dd2eaac2780957ee6285fc0fc7eb6484d32e051c199a4
+SIZE (FreeBSDDesktop-drm-legacy-g20190109-1550ba3_GH0.tar.gz) = 1675960
___
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: drm2 removed?

[Niclas Zeising]

On 2/11/19 6:36 PM, Steve Kargl wrote:

On Mon, Feb 11, 2019 at 06:05:03PM +0100, Niclas Zeising wrote:

On 2/11/19 5:20 PM, Steve Kargl wrote:

On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote:

Anyone have any idea which recent change broke the
drm-legacy-kmod port.  This is why I raised an issue
with removal of drm2 from src/sys.  How is suppose
to be fixed?



It was r343567.  The merging of PAE and NO PAE pmap.h
by kib removed all of the missing macros. :(



Can you give attached patch a spin?
Thanks!
Regards
--
Niclas


The patch allows the port to be built.

kldloading the i915kms module causes a 'black screen
of death'

I'll note that there seems to be a race condition in
booting a kernel (with or without the drm2 stuff).
During boot the kernel hangs (see below) :

---<>---
Copyright (c) 1992-2019 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-CURRENT r343477 MOBILE i386
FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 
7.0.1)
VT(vga): resolution 640x480
CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1995.05-MHz 686-class CPU)
   Origin="GenuineIntel"  Id=0x6fd  Family=0x6  Model=0xf  Stepping=13
   
Features=0xbfebfbff
   Features2=0xe3bd
   AMD Features=0x2010
   AMD Features2=0x1
   VT-x: (disabled in BIOS) HLT,PAUSE
   TSC: P-state invariant, performance statistics
real memory  = 4294967296 (4096 MB)
avail memory = 3659202560 (3489 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
Firmware Warning (ACPI): Incorrect checksum in table [TCPA] - 0x80, should be 
0x24 (20190108/tbprint-337)
ioapic0: Changing APIC ID to 2
ioapic0  irqs 0-23 on motherboard
Launching APs: 1

*** kernel hangs here sometimes ***

Timecounter "TSC" frequency 1995048460 Hz quality 1000
random: entropy device external interface
kbd1 at kbdmux0




Hi!
I assume you load the kernel module either manually with kldload or 
using kld_list in rc.conf, not by loading it from the loader?
So there is two bugs?  One bug is that the kernel hangs while booting, 
and the other is that you get a black screen when loading the drm module 
after the kernel is mostly done booting?


Regards
--
Niclas
___
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: "Oddness" in head since around r343678 or so

[Niclas Zeising]

On 2/12/19 1:38 PM, David Wolfskill wrote:

On Thu, Feb 07, 2019 at 05:09:40AM -0800, David Wolfskill wrote:

...
The laptop is configured to run xdm; while running stable/11 or
stable/12, there's a period of about 5 seconds after xdm's login banner
shows up before either the mouse or keyboard responds.

Up to a few days ago, head was the same, but as of about last weekend (I
think), that period is about 40 seconds while running head.



I no longer observe the above-described delay in head, as of r343998.



Most likely because the coverage stuff were removed from GENERIC.
Regards
--
Nicals
___
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: What is evdev and autoloading?

[Niclas Zeising]

On 2/18/19 12:06 PM, Stefan Blachmann wrote:

On 2/18/19, Vladimir Kondratyev  wrote:

On 2019-02-17 21:03, Steve Kargl wrote:

Anyone have insight into what evdev is?

evdev.ko is a small in-kernel library that makes all your input events
like keyboard presses libinput-compatible.


And libinput was created by the Freedesktop Wayland team to create
pressure on OS people to make their systems Wayland-compatible.


I do not need nor what these modules loaded.

I think removing "option EVDEV_SUPPORT" from your kernel config should
disable most of evdev.ko dependencies


Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well
as libinput not be part of the standard packages?

The Freedesktop Wayland team consists of people with the Kay Sievers
mentality, which made Linus Torvalds ban his contributions. They do
not care about the bugs they introduce, forcing others to clean up the
mess they create.

I'd be glad if FreeBSD would keep clean of following that Wayland fad...


EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve 
input device handling in X and Wayland.  Not having it means that a lot 
of input devices stop working, or work much worse.


We in the FreeBSD Graphics Team are working very hard to improve the 
FreeBSD Desktop experience, since it is an avenue to recruit new users, 
and make current users use FreeBSD more.


Evdev and libinput is used by both Wayland and xorg.  You are free to 
use either one.


Regards
--
Niclas Zeising
FreeBSD Graphics Team
___
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: SVN r345102 breaks drm-current-kmod

[Niclas Zeising]

On March 14, 2019 7:37:50 AM UTC, Hans Petter Selasky  wrote:
>CC'ing Johannes and Niclas.
>
>--HPS
>
>On 3/14/19 1:20 AM, Michael Butler wrote:
>> As below ..
>> 
>> --- drm_atomic_helper.o ---
>> In file included from
>>
>/usr/ports/graphics/drm-current-kmod/work/kms-drm-78e51d0/drivers/gpu/drm/drm_atomic_helper.c:28:
>> In file included from
>>
>/usr/ports/graphics/drm-current-kmod/work/kms-drm-78e51d0/include/drm/drmP.h:139:
>>
>/usr/ports/graphics/drm-current-kmod/work/kms-drm-78e51d0/drivers/gpu/drm/drm_os_freebsd.h:124:9:
>> error: 'IS_ALIGNED' macro redefined [-Werror,-Wmacro-redefined]
>> #define IS_ALIGNED(x, y)(((x) & ((y) - 1)) == 0)
>>  ^
>> /usr/src/sys/compat/linuxkpi/common/include/linux/kernel.h:133:9:
>note:
>> previous definition is here
>> #define IS_ALIGNED(x, a)(((x) & ((__typeof(x))(a) - 1)) == 0)
>>  ^
>> --- drm_atomic.o ---
>> In file included from
>>
>/usr/ports/graphics/drm-current-kmod/work/kms-drm-78e51d0/drivers/gpu/drm/drm_atomic.c:29:
>> In file included from
>>
>/usr/ports/graphics/drm-current-kmod/work/kms-drm-78e51d0/include/drm/drmP.h:139:
>>
>/usr/ports/graphics/drm-current-kmod/work/kms-drm-78e51d0/drivers/gpu/drm/drm_os_freebsd.h:124:9:
>> error: 'IS_ALIGNED' macro redefined [-Werror,-Wmacro-redefined]
>> #define IS_ALIGNED(x, y)(((x) & ((y) - 1)) == 0)
>>  ^
>> /usr/src/sys/compat/linuxkpi/common/include/linux/kernel.h:133:9:
>note:
>> previous definition is here
>> #define IS_ALIGNED(x, a)(((x) & ((__typeof(x))(a) - 1)) == 0)
>>  ^
>> --- drm_atomic_helper.o ---
>> 1 error generated.
>> *** [drm_atomic_helper.o] Error code 1
>> 
>> make[3]: stopped in
>> /usr/ports/graphics/drm-current-kmod/work/kms-drm-78e51d0/drm
>> 
>___
>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'll look asap.
-- 
Niclas Zeising
___
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: Inability to build FreeBSD-current amd64

[Niclas Zeising]

On 2019-05-16 03:46, Thomas Mueller wrote:

In general, WITH_CLANG_EXTRAS controls the building of extra tools such
as a disassembler, and tools for working on clang itself such as bug
reporting tools.  I don't have a really detailed answer because I've
never enabled the option.  I've always perceived it as being something
most people don't need.  WITHOUT_CLANG_EXTRAS may cut some time from
your build, but it probably won't cut it in half or anything.



- Ian


I am not concerned about the time to build CLANG_EXTRAS so much as the 
possibility of CLANG_EXTRAS stopping the build.

WITH_CLANG_EXTRAS worked back in July-August 2017, but it may have ballooned 
since then beyond FreeBSD buildability.



I run a build WITH_CLANG_EXTRAS, and that worked, on current, last 
weekend, if that's what you're asking about.


This won't take away the need for llvm ports in certain ports builds, 
however, such as firefox and mesa.


Regards
--
Niclas
___
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: Inability to build FreeBSD-current amd64

[Niclas Zeising]

On 2019-05-16 09:36, Thomas Mueller wrote:

from Niclas Zeising:


I run a build WITH_CLANG_EXTRAS, and that worked, on current, last weekend, if
that's what you're asking about.
  

This won't take away the need for llvm ports in certain ports builds, however,
such as firefox and mesa.


So now I wonder why I failed four times straight building current.  One 
definition of insanity is doing the same thing repeatedly and expecting a 
different result.

Maybe the build host, 11.1-STABLE from July 30, 2017, was too old?  I wouldn't 
have thought it was too old.

I could also try an old current host from August 2, 2017, or try to build 
12-STABLE from my 11.1-STABLE host.  Would I do better to build amd64 or i386 
from amd64 host?  I presently have no FreeBSD i386 installation, only amd64.



That could be that the toolchain on 11.1 stable is too old to build 
current.  If you've posted the error you're getting, I've missed it, 
however.

Regards
--
Niclas
___
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: Heads up for breaking drm update.

[Niclas Zeising]

On 2019-05-20 17:21, Michael Butler wrote:

On 2019-05-19 23:21, Johannes Lundberg wrote:


On 5/19/19 7:36 PM, Steve Kargl wrote:

On Sun, May 19, 2019 at 02:50:54PM -0700, Johannes Lundberg wrote:

LinuxKPI in base have received a lot of updates recently for Linux 5.0,
a couple of them will break drm-current-kmod. So, as of r347973 you will
need drm-current-kmod 4.16.g20190519. Ports have been updated and new
packages should be available shortly.


If drm-current-kmod is broken, should I venture to ask
about drm-stable-kmod and drm-legacy-kmod?


That's a very good question. Maybe I should have included more
information regarding what's not affected. The last series of commits
have been to LinuxKPI in -CURRENT. As such:

drm-kmod: Meta port, not relevant
drm-current-kmod: See original message
drm-fbsd11.2-kmod: Not affected by changes in -CURRENT
drm-fbsd12.0-kmod: Not affected by changes in -CURRENT
drm-legacy-kmod: Not affected by changes in LinuxKPI

drm-stable-kmod does not exist anymore. Stable drm kmod ports for other
than -CURRENT are more or less frozen in separate branches where they
only receive bug fixes (drm-fbsdxxx-kmod).

Hope that answers your questions.


It should also be noted that drm-current now has a new dependency on
lindebugfs. It won't load without it :-(



Previously, lindebugfs was part of the port, and loaded from the port. 
With this update, we simply switched to using the debugfs version that 
was imported into base.

Regards
--
Niclas Zeising
FreeBSD Graphics Team
___
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"

Enabling synaptics and elantech touchpads by default

[Niclas Zeising]

Hi!
I've created a reveiew, https://reviews.freebsd.org/D20507, to enable 
synaptics and elantech touchpads by default.


Today, these tunables needs to be set on boot for users to get full use 
of their touchpads, even when using X.  By enabling this, things like 
two finger scroll will work in X by default, meaning we get a more user 
friendly appearance.


Is there any reason not to do this?
Regards
--
Niclas Zeising
___
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: signal 11 for 'conftest' && poudriere jails

[Niclas Zeising]

On 2019-06-17 07:32, Matthias Apitz wrote:


While running poudriere jails on a very recent CURRENT:

FreeBSD jet 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r349041: Sat Jun 15 07:45:13 
CEST 2019 guru@jet:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

I see messages about signal 11 for 'conftest'. The uid 65534 (nobody)
let me think in poudriere, because there is nothing else running on this
box:

Jun 16 19:31:46 jet kernel: pid 55572 (conftest), jid 23, uid 65534: exited on 
signal 11 (core dumped)
Jun 16 19:37:25 jet su[98388]: guru to root on /dev/pts/2
Jun 16 20:01:32 jet kernel: pid 26452 (conftest), jid 25, uid 65534: exited on 
signal 11 (core dumped)
Jun 16 20:02:26 jet kernel: pid 54189 (conftest), jid 25, uid 65534: exited on 
signal 11 (core dumped)
Jun 16 20:14:09 jet kernel: pid 86215 (conftest), jid 23, uid 65534: exited on 
signal 11 (core dumped)
Jun 16 20:31:06 jet ntpdate[79734]: step time server 130.149.17.21 offset 
0.309740 sec
Jun 16 20:38:39 jet kernel: pid 61044 (conftest), jid 25, uid 65534: exited on 
signal 11 (core dumped)
Jun 16 20:45:29 jet kernel: pid 24274 (conftest), jid 31, uid 65534: exited on 
signal 11 (core dumped)
Jun 16 21:31:06 jet ntpdate[99262]: step time server 130.149.17.21 offset 
0.309141 sec
Jun 16 22:31:06 jet ntpdate[27064]: step time server 130.149.17.21 offset 
0.309090 sec
Jun 16 23:31:06 jet ntpdate[1088]: step time server 130.149.17.21 offset 
0.309793 sec
Jun 16 23:51:38 jet kernel: pid 10847 (java), jid 29, uid 65534, was killed: 
out of swap space
Jun 17 00:31:06 jet ntpdate[6936]: step time server 130.149.17.21 offset 
0.308939 sec
Jun 17 00:32:58 jet su[10397]: guru to root on /dev/pts/4
Jun 17 00:38:22 jet su[28548]: guru to root on /dev/pts/2
Jun 17 01:31:06 jet ntpdate[39553]: step time server 130.149.17.21 offset 
0.309018 sec
Jun 17 01:41:23 jet kernel: pid 81104 (conftest), jid 26, uid 65534: exited on 
signal 11 (core dumped)
Jun 17 02:17:29 jet kernel: pid 9625 (conftest), jid 29, uid 65534: exited on 
signal 11 (core dumped)
Jun 17 02:21:56 jet kernel: pid 36351 (conftest), jid 29, uid 65534: exited on 
signal 11 (core dumped)



I am not 100% sure, but I believe conftest is something from the build 
system, most likely autotools.  Autotools (and possibly others) work by 
compiling, and I guess sometimes running, small code snippets to figure 
out things about the host system.
This is just a guess, but looking at 
https://ftp.gnu.org/old-gnu/Manuals/autoconf-2.57/html_chapter/autoconf_6.html 
and 
https://lists.freebsd.org/pipermail/freebsd-questions/2007-July/154070.html 
seem to agree with me.

Regards
--
Niclas
___
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: UEFI firmware and getting FreeBSD recognized by default: who to talk to?

[Niclas Zeising]

On 2019-06-23 04:56, Karl Denninger wrote:

On 6/22/2019 20:16, Thomas Mueller wrote:

I am trying to set up UEFI to boot my FreeBSD and NetBSD installations, and 
later, Linux.


Easy.  Refind should do that and allow selection from a menu.



I wrote this as an instruction on how to get FreeBSD and Windows 
dual-booting using rEFInd.  You can probably adapt that to get going 
with other OSes as well.

https://gist.github.com/zeising/5d2402d92b4cf421c7402d663b2d9e41

I hope it is of some value.
Regards
--
Niclas
___
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: Someone broke USB

[Niclas Zeising]

On 2019-07-09 06:33, Steve Kargl wrote:

On Mon, Jul 08, 2019 at 10:54:24PM +0200, Hans Petter Selasky wrote:

On 2019-07-08 22:08, Steve Kargl wrote:

On Mon, Jul 08, 2019 at 09:08:17PM +0200, Hans Petter Selasky wrote:

Hi Steve,

Can you revert all prior patches and try this one instead.



With the new patch, none of the USB devices are found.
I'll be away from the laptop for a few hours.



I've put the USB ACPI code into an own module, which is not enabled by
default. So USB should be back to normal for now.

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



Thanks!  Unfortunately, things have gone left.  To update
/usr/src to get your change, I pulled in some vm changes,
which break the graphics/drm-legacy-kmod port.



Can you report this, including the failure you're seeing, to 
x...@freebsd.org or as an issue on the FreeBSDDesktop github?

Thanks!
Regards
--
Niclas Zeising
___
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: Can't buildworld at r350321

[Niclas Zeising]

On 2019-07-25 12:33, Masachika ISHIZUKA wrote:

   Hi.
   I want to update 13-current from r349989 to r350321 as follows.
   
% cd /usr/src

% pwd
/usr/altlocal/freebsd-current/src
% df -h .
Filesystem   SizeUsed   Avail Capacity  Mounted on
192.168.1.2:/usr/altlocal2.5T930G1.6T37%/usr/altlocal
% svn up -r 350321
% time make -j4 buildworld
(snip)
--- all_subdir_lib/libsysdecode ---
===> lib/libsysdecode (all)
make[5]: make[5]: don't know how to make 
/usr/altlocal/freebsd-current/obj/usr/altlocal/freebsd-current/src/amd64.amd64/obj-lib32/tmp/sys/netinet/in.h.
 Stop

make[5]: stopped in /usr/altlocal/freebsd-current/src/lib/libsysdecode
(snip)
make: stopped in /usr/altlocal/freebsd-current/src
20974.852u 3569.891s 2:17:32.86 297.4%  60110+3554k 183950+308232io 225686pf+0w

   I can buildworld at r349989 without errors.



This should have been fixed, or at least worked around, in r350322, as I 
understand it.

Regards
--
Niclas
___
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: drm-legacy is broken, again

[Niclas Zeising]

On 2019-08-01 21:42, Steve Kargl wrote:

On Thu, Aug 01, 2019 at 03:31:15PM -0400, Mark Johnston wrote:

On Thu, Aug 01, 2019 at 12:30:24PM -0700, Steve Kargl wrote:

On Thu, Aug 01, 2019 at 03:22:27PM -0400, Mark Johnston wrote:

On Thu, Aug 01, 2019 at 12:10:09PM -0700, Steve Kargl wrote:

Just updated /usr/src to top of tree.

Trying to update drm-legacy port.  After
a failed 'make' in /usr/ports/drm-legacy


The patch below should fix it.  drm was relying on refcount.h including
limits.h.

diff --git a/src/dev/drm2/drmP.h b/src/dev/drm2/drmP.h
index 3af7ad1..7cbd8db 100644
--- a/src/dev/drm2/drmP.h
+++ b/src/dev/drm2/drmP.h
@@ -42,6 +42,7 @@ __FBSDID("$FreeBSD$");
  
  #include 

  #include 
+#include 
  #include 
  #include 
  #include 


Thanks for the quick response.  I had recalled someone
has/had been undoing some header pollution changes,
but the individual names escaped me.


I reproduced the issue and submitted a PR:
https://github.com/FreeBSDDesktop/drm-legacy/pull/13



Thanks for that, too.  I'm not in a position to
submit a PR as my mouse has gone missing under
Xorg.



Port has been updated:
https://svnweb.freebsd.org/changeset/ports/507828
Regards
--
Niclas Zeising
___
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: HEADSUP: drm-current-kmod now installs sources

[Niclas Zeising]

On 2019-08-14 00:35, Conrad Meyer wrote:

This is super cool, thank you!  Is it feasible to integrate other
out-of-tree kmods in a similar way, e.g., nvidia-driver?



It should be possible to expand this to work with other ports that 
install kmods.  I think the plan is to have drm-current-kmod work like 
this for a while, to shake out any bugs or other unexpected issues, and 
then look into converting more kmod ports.

Regards
--
Niclas Zeising
___
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: HEADSUP: drm-current-kmod now installs sources

[Niclas Zeising]

On 2019-08-14 19:23, Emmanuel Vadot wrote:

On Wed, 14 Aug 2019 10:13:48 -0700
John Baldwin  wrote:


On 8/14/19 9:22 AM, Ian Lepore wrote:

This all sounds vaguely wrong, backwards, to me.  A developer who is
using a given module on their build system might want that module to be
rebuilt automatically, but only if the build parameters match those of
the running build host system.

If my build host is running freebsd 12 amd64 and I'm doing a build for
freebsd 13 armv7, I have no interest in automatic rebuilds of an amd64
driver module for a different OS arch and version just because that
module happens to be installed on the system I use to do crossbuilds.

My objections are theoretical... this automation just seems improperly
designed to me.  But it won't actually affect me in any way, because I
don't build video driver modules from ports, and I don't run freebsd
current on my build host machine.  Probably the number of people doing
crossbuilding is small enough that nobody else is going to object to
this "the whole world is amd64" automation.


You assume DRM is amd64-only when it is definitely not.  It also has
suitable guards in its Makefile to only build the relevant kernel
modules on supported architectures.


  I clearly don't want to spend time to build the drm and radeon modules
when I'm hacking on arm64.
  Shouldn't LOCAL_MODULE have ${TARGET}.${TARGET_ARCH} as a
subdirectory ? So when you install drm-kmod-* it will only install the
source in /usr/local/modules/${TARGET}.${TARGET_ARCH}/ ? (or whatever
the correct dir is).



I'm not sure what you're trying to accomplish.  I might be 
misunderstanding completely, but, at least the drm ports have safeguards 
in their makefiles so they'll only be built for those arches where there 
is support, and only the modules needed, as an example, i915kms.ko will 
only be built on amd64 and i386, if that's what you're worried about.

Regards
--
Niclas Zeising
___
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: Installing drm-current-kmod from ports

[Niclas Zeising]

On 2019-08-18 04:08, Clay Daniels Jr. wrote:

I've been reading the HEADSUP: drm-current-kmod thread, actually several
times, and since my pkg install of plain vanilla drm-kmod was a dud after
working for several weekly installs of 13.0-Current, it's clear I probably
need to make install from the ports, which I have installed, as well as the
sources. I must confess I have done pkg install xorg, but this can be
corrected if it needs to be make install xorg from ports.

Is simply navigating to /usr/ports/graphics/drm-current-kmod and running
"make install clean" the best next step, or am I missing something else?

I want to confess my relative ignorance, and thank Graham Perrin & Pete
Wright for their help on a previous post, 13.0 Current - r350702 exposed an
Xorg failure. I've moved on to this weeks r351067 and no longer think my
problem is with Xorg, but with my install of drm-*-kmod.

I'm willing to wipe my install & start fresh if need be. I sure like
gParted. It erases a lot of sins.



Hi!
drm-kmod should pull in drm-current-kmod if you install it on FreeBSD 
CURRENT.  The feature to have sources installed with the port is fairly 
recent, it could be that the port hasn't caught up yet.  You can check 
in /usr/local/sys/modules/drm-current-kmod if they are installed.  If 
they are, it should be enough to run a buildkernel and installkernel to 
get the updated modules.


Otherwise, it's completely safe to install drm-current-kmod (and 
gpu-firmware-kmod, which is a dependency) from ports, even if the rest 
of the system is installed using packages.


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

ses no longer attaches

[Niclas Zeising]

Hi!
I have an issue where the ses driver no longer attaches.  Last known 
good version was r351188, r351544 is broken.  In that interval, 
something happened.  I haven't had time to bisect yet.

Thanks!
Regards
--
Niclas Zeising
___
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: ses no longer attaches

[Niclas Zeising]

On 2019-08-28 00:38, Alexander Motin wrote:

Hi.

On 27.08.2019 18:03, Niclas Zeising wrote:

I have an issue where the ses driver no longer attaches.  Last known
good version was r351188, r351544 is broken.  In that interval,
something happened.  I haven't had time to bisect yet.


I would appreciate some details, like dmesg, error messages, etc.  On my
test systems I see no problems.



Hi!
I did some more digging. r351355 is ok, while r351356 is bad.  This is 
Warner's (CC:d) commit to add RST support to nvme, however, I'm using a 
ssd drive connected to ahci.


What happens is that the ses driver doesn't attach to the AHCI SGPIO 
enclosure.  This is on a laptop with an ssd (not an nvme) drive.  I have 
the same issue on another computer as well.  On the broken kernel, 
sesutil status complains about "No SES devices found", on the working 
kernel it reports "ok".


Regards
--
Niclas Zeising
___
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: ses no longer attaches

[Niclas Zeising]

On 2019-08-28 01:45, Michael Butler wrote:

On 2019-08-27 19:41, Michael Butler wrote:

On 2019-08-27 19:15, Niclas Zeising wrote:

On 2019-08-28 00:38, Alexander Motin wrote:

Hi.

On 27.08.2019 18:03, Niclas Zeising wrote:

I have an issue where the ses driver no longer attaches.  Last known
good version was r351188, r351544 is broken.  In that interval,
something happened.  I haven't had time to bisect yet.


I would appreciate some details, like dmesg, error messages, etc.  On my
test systems I see no problems.



Hi!
I did some more digging. r351355 is ok, while r351356 is bad.  This is
Warner's (CC:d) commit to add RST support to nvme, however, I'm using a
ssd drive connected to ahci.

What happens is that the ses driver doesn't attach to the AHCI SGPIO
enclosure.  This is on a laptop with an ssd (not an nvme) drive.  I have
the same issue on another computer as well.  On the broken kernel,
sesutil status complains about "No SES devices found", on the working
kernel it reports "ok".


I can confirm this behaviour (haven't checked versioning) .. working
kernel yields ..

Aug 20 17:40:06 toshi kernel: ses0 at ahciem0 bus 0 scbus4 target 0 lun 0
Aug 20 17:40:06 toshi kernel: ses0: 
SEMB S-E-S 2.00 device
Aug 20 17:40:06 toshi kernel: ses0: SEMB SES Device
Aug 20 17:40:06 toshi kernel: ses0: ada0,pass0 in 'Slot 00', SATA Slot:
scbus0 target 0
Aug 20 17:40:06 toshi kernel: ses0: ada1,pass1 in 'Slot 01', SATA Slot:
scbus1 target 0


Should have been ..

Aug 20 17:40:06 toshi kernel: ahci0: AHCI v1.30 with 6 6Gbps ports, Port
Multiplier not supported
Aug 20 17:40:06 toshi kernel: ahcich0:  at channel 0 on ahci0
Aug 20 17:40:06 toshi kernel: ahcich1:  at channel 1 on ahci0
Aug 20 17:40:06 toshi kernel: ahcich4:  at channel 4 on ahci0
Aug 20 17:40:06 toshi kernel: ahcich5:  at channel 5 on ahci0
Aug 20 17:40:06 toshi kernel: ahciem0:  on ahci0



  [ .. other stuff .. ]

Aug 20 17:40:06 toshi kernel: ses0 at ahciem0 bus 0 scbus4 target 0 lun 0
Aug 20 17:40:06 toshi kernel: ses0: 
SEMB S-E-S 2.00 device
Aug 20 17:40:06 toshi kernel: ses0: SEMB SES Device
Aug 20 17:40:06 toshi kernel: ses0: ada0,pass0 in 'Slot 00', SATA Slot:
scbus0 target 0
Aug 20 17:40:06 toshi kernel: ses0: ada1,pass1 in 'Slot 01', SATA Slot:
scbus1 target 0

  .. non working reports ..

Aug 27 11:06:28 toshi kernel: ahciem0:  at channel 2147483647 on ahci0
Aug 27 11:06:28 toshi kernel: device_attach: ahciem0 attach returned 6



Yeah, I'm seeing this also.
Regards
--
Niclas Zeising
___
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: ses no longer attaches

[Niclas Zeising]

On 2019-08-29 00:07, Alexander Motin wrote:

On 27.08.2019 19:15, Niclas Zeising wrote:

I did some more digging. r351355 is ok, while r351356 is bad.  This is
Warner's (CC:d) commit to add RST support to nvme, however, I'm using a
ssd drive connected to ahci.

What happens is that the ses driver doesn't attach to the AHCI SGPIO
enclosure.  This is on a laptop with an ssd (not an nvme) drive.  I have
the same issue on another computer as well.  On the broken kernel,
sesutil status complains about "No SES devices found", on the working
kernel it reports "ok".


Thank you for the report.  r351589 should fix it.



I can confirm that it works.  Thanks for fixing it!
Regards
--
Niclas Zeising
___
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: hang up with r352239 and r352386 with i5-7500

[Niclas Zeising]

On 2019-09-16 13:09, Masachika ISHIZUKA wrote:

   Hi.

   My machine (with core i5-7500) is hangup when loading i915kms.ko
on r352239 and r352386 (1300047).
   This machine was working good with r351728 (1300044).

   /etc/rc.conf has the following line.
kld_list="i915kms.ko"

   It is good wowking with core i7-4500U on r352239 (1300047).



Hi!
Which version of drm-current are you using?  Have you recompiled it 
after updating the kernel?  What happens if you change to 
kld_list="/boot/modules/i915kms.ko"?


There is a patch here: 
https://github.com/FreeBSDDesktop/kms-drm/pull/175/commits/7b8fab2461262b22f64425146b60608bb0e0240d 
that might solve the issue, can you apply that and recompile 
drm-current-kmod and see if it works?


Thanks!
Regards
--
Niclas Zeising
___
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: hang up with r352239 and r352386 with i5-7500

[Niclas Zeising]

On 2019-09-16 15:13, Masachika ISHIZUKA wrote:

   My machine (with core i5-7500) is hangup when loading i915kms.ko
on r352239 and r352386 (1300047).
   This machine was working good with r351728 (1300044).

   /etc/rc.conf has the following line.
kld_list="i915kms.ko"


Pardon the intrusion.
What happens if you add drm2.ko and/or switch to absolute paths?

This is what I had to put in my /etc/rc.conf for a Dell Latitude
E5530 to get rid of the message of drm2 being deprecated:

kld_list="/boot/modules/drm2.ko /boot/modules/i915kms.ko"


   Hi.

   Thank you for mail.
   I'm using 13-current and it has no longer drm2.ko.
   This machine was working good on r351728 as follows.
   
r351728% kldstat

Id Refs AddressSize Name
  1   90 0x8020  2336bb0 kernel
  21 0x82537000 7278 ums.ko
  31 0x82ef9000 aa70 tmpfs.ko
  41 0x82f04000 4fb8 linprocfs.ko
  54 0x82f09000 3d70 linux_common.ko
  61 0x82f0d000 24fe linsysfs.ko
  71 0x82f1   12eb90 i915kms.ko
  81 0x8303f00077e90 drm.ko
  94 0x830b7000125f0 linuxkpi.ko
102 0x830ca00013f30 linuxkpi_gplv2.ko
112 0x830de000  8e0 lindebugfs.ko
121 0x830df000 240d i915_kbl_dmc_ver1_04_bin.ko
131 0x830e2000 a218 if_lagg.ko
141 0x830ed000 3f00 ng_ubt.ko
156 0x830f1000 a998 netgraph.ko
162 0x830fc000 9378 ng_hci.ko
173 0x83106000  9c0 ng_bluetooth.ko
181 0x83107000 c890 snd_uaudio.ko
191 0x83114000 1840 uhid.ko
201 0x83116000 1b00 wmt.ko
211 0x83118000 d560 ng_l2cap.ko
221 0x8312600019900 ng_btsocket.ko
231 0x8314 2100 ng_socket.ko
241 0x83143000263b0 ipfw.ko
251 0x8316a0003c960 linux.ko
261 0x831a700034b70 linux64.ko
271 0x831dc000 45a0 autofs.ko
281 0x831e1000  acf mac_ntpd.ko




Hi!
Can you please use absolute paths to i915kms.ko anyway, just to test?
Thanks!
Regards
--
Niclas Zeising
___
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: hang up with r352239 and r352386 with i5-7500

[Niclas Zeising]

On 2019-09-16 16:06, Masachika ISHIZUKA wrote:

Can you please use absolute paths to i915kms.ko anyway, just to test?


   The same hang up occure with kld_list="/boot/modules/i915kms.ko"
in /etc/rc.conf.



Even after applying the patch I suggested?
Regards
--
Niclas Zeising
___
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: hang up with r352239 and r352386 with i5-7500

[Niclas Zeising]

On 2019-09-18 10:15, Masachika ISHIZUKA wrote:

Can you please use absolute paths to i915kms.ko anyway, just to test?

The same hang up occure with kld_list="/boot/modules/i915kms.ko"
in /etc/rc.conf.



Even after applying the patch I suggested?


   Yes.

   kld_list="/boot/modules/drm.ko /boot/modules/i915kms.ko"
will hang as well.

/boot/modules/{drm,i915kms}.ko is patched modules.

# /boot/kernel.r352239/{drm,i915kms}.ko is not patched.


Are you able to collect a kernel dump?  If so, remove the kld_list
setting and set debug.debugger_on_panic=0 and dev.drm.skip_ddb=1.  Then
manually kldload /boot/modules/i915kms.ko.  If you are running an
INVARIANTS kernel you might be hitting an assertion failure; having the
vmcore would help us debug.


   Thank you for mail.

   As I'm busy now, I'll try to get kernel dump about 1 day after.


   I'm very sorry.

   The patch you suggested is work fine.
   The reason why it didn't work was because the patch was applied
to the wrong file.

   Now, drm-current-kmod is working fine on r352467 by your patch.



Hi!
I just updated the port with the fix I suggested earlier, hopefully it 
works.  It will take some time before it shows up as packages, but there 
is no problems building drm-current-kmod from ports even if packages are 
used for the rest of the system.

Regards
--
Niclas Zeising
___
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: DRM-current-kmod is still a problem at r353339

[Niclas Zeising]

On 2019-10-16 18:57, Neel Chauhan wrote:

While drm-current-kmod worked for a little while, it broke with r353645.

https://i.imgur.com/Q5nYZf2.jpg

I'm using the same HP Spectre that I used earlier (where it worked and 
where it panicked).




That commit looks unrelated, it touches the wbwd and superio drivers, 
nothing else.  Any chance you can bisect exactly which revision that 
caused the new issues?


Regards
--
Niclas
___
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: DRM-current-kmod is still a problem at r353339

[Niclas Zeising]

On 2019-10-17 21:53, ma...@freebsd.org wrote:

On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote:

On 2019-10-16 18:57, Neel Chauhan wrote:

While drm-current-kmod worked for a little while, it broke with r353645.

https://i.imgur.com/Q5nYZf2.jpg

I'm using the same HP Spectre that I used earlier (where it worked and
where it panicked).



That commit looks unrelated, it touches the wbwd and superio drivers,
nothing else.  Any chance you can bisect exactly which revision that
caused the new issues?


I believe it was the recent work on the vm page busy state, r353539
specifically.  This patch should fix it; we don't yet have a
__FreeBSD_version number bump on which to gate the patch.

diff --git a/linuxkpi/gplv2/src/linux_page.c b/linuxkpi/gplv2/src/linux_page.c
index e2b85c45c..060ae85ed 100644
--- a/linuxkpi/gplv2/src/linux_page.c
+++ b/linuxkpi/gplv2/src/linux_page.c
@@ -239,7 +239,7 @@ retry:
page = vm_page_lookup(devobj, i);
if (page == NULL)
continue;
-   if (vm_page_sleep_if_busy(page, "linuxkpi"))
+   if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL))
goto retry;
cdev_pager_free_page(devobj, page);
}


Hi!
Hopefully someone can confirm that this patch to drm-current-kmod or 
drm-devel-kmod fixes the issue.  I won't be able to work on this before 
the weekend at the earliest, I'm afraid.
Mark, is it possible to get a belated version bump for this fix, and 
what changed to require it?

Thanks!
Regards
--
Niclas
___
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: DRM-current-kmod is still a problem at r353339

[Niclas Zeising]

On 2019-10-20 08:45, Yuri Pankov wrote:

On 10/18/2019 8:01 AM, Xin Li wrote:

Another (semi-fixed!) data point -- I can confirm that with if
(vm_page_sleep_if_busy(page, "linuxkpi"))
  -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and
mjg@'s earlier patch at
https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) ,
the latest drm-v5.0 branch of drm-current-kmod worked just fine with
Intel HD Graphics P630 on Lenovo P51.


Confirmed that it worked for me too on P51.

Sorry for offtopic, but do you see the console getting "stuck" after 
loading i915kms, i.e. for input to show you need to switch to another 
console and back?


This is a known regression with drm-devel-kmod, and one of the reasons 
it hasn't made it past devel yet.

Regards
--
Niclas
___
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: DRM-current-kmod is still a problem at r353339

[Niclas Zeising]

On 2019-10-21 09:01, Thomas Mueller wrote:

from Neel Chauhan:


For me, the following code is still necessary for me (HP Spectre x360
2018), which is the remaining parts of the patches not committed if you
are using a recent kernel. I don't know about you all ThinkPad users, it
should still apply as it's Intel in general not just HP or Lenovo.
Without these patches, I get a kernel panic.
  

Keep in mind that the patch may render as spaces, but it should be tabs.


What happens if the patch is applied with spaces as opposed to tabs?

I believe, in C, there is no difference as far as compiling is concerned.

Or is it just a standard for formatting?



If the whitespace isn't correct, the patch won't apply cleanly.  It has 
no effect on compiling the code though.


Regards
--
Niclas
___
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: DRM-current-kmod is still a problem at r353339

[Niclas Zeising]

On 2019-10-17 23:05, Mark Johnston wrote:

On Thu, Oct 17, 2019 at 10:31:12PM +0200, Niclas Zeising wrote:

On 2019-10-17 21:53, ma...@freebsd.org wrote:

On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote:

On 2019-10-16 18:57, Neel Chauhan wrote:

While drm-current-kmod worked for a little while, it broke with r353645.

https://i.imgur.com/Q5nYZf2.jpg

I'm using the same HP Spectre that I used earlier (where it worked and
where it panicked).



That commit looks unrelated, it touches the wbwd and superio drivers,
nothing else.  Any chance you can bisect exactly which revision that
caused the new issues?


I believe it was the recent work on the vm page busy state, r353539
specifically.  This patch should fix it; we don't yet have a
__FreeBSD_version number bump on which to gate the patch.

diff --git a/linuxkpi/gplv2/src/linux_page.c b/linuxkpi/gplv2/src/linux_page.c
index e2b85c45c..060ae85ed 100644
--- a/linuxkpi/gplv2/src/linux_page.c
+++ b/linuxkpi/gplv2/src/linux_page.c
@@ -239,7 +239,7 @@ retry:
page = vm_page_lookup(devobj, i);
if (page == NULL)
continue;
-   if (vm_page_sleep_if_busy(page, "linuxkpi"))
+   if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL))
goto retry;
cdev_pager_free_page(devobj, page);
}


Hi!
Hopefully someone can confirm that this patch to drm-current-kmod or
drm-devel-kmod fixes the issue.  I won't be able to work on this before
the weekend at the earliest, I'm afraid.
Mark, is it possible to get a belated version bump for this fix, and
what changed to require it?


I committed the bump and verified the patch on amdgpu.  Here are some
PRs for the drivers:

https://github.com/FreeBSDDesktop/kms-drm/pull/180
https://github.com/FreeBSDDesktop/kms-drm/pull/181


Hi!
I'm working on getting this into the versions that are in ports.  For 
drm-current-kmod it's fairly simple, but for drm-devel-kmod there are 
unrelated changes which I need to check if they are ready to go in or 
not, so it will take some more time.


Looking at the mail list thread, there seems to be a patch needed for 
base as well, has this been committed?


Regards
--
Niclas
___
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: DRM-current-kmod is still a problem at r353339

[Niclas Zeising]

On 2019-10-21 11:08, Yuri Pankov wrote:

Niclas Zeising wrote:

On 2019-10-20 08:45, Yuri Pankov wrote:

On 10/18/2019 8:01 AM, Xin Li wrote:

Another (semi-fixed!) data point -- I can confirm that with if
(vm_page_sleep_if_busy(page, "linuxkpi"))
  -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and
mjg@'s earlier patch at
https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit 
it) ,

the latest drm-v5.0 branch of drm-current-kmod worked just fine with
Intel HD Graphics P630 on Lenovo P51.


Confirmed that it worked for me too on P51.

Sorry for offtopic, but do you see the console getting "stuck" after 
loading i915kms, i.e. for input to show you need to switch to another 
console and back?


This is a known regression with drm-devel-kmod, and one of the reasons 
it hasn't made it past devel yet.


Got it, thanks.  I'm only seeing it on the lenovo laptop with hd630 and 
not on the intel nuc with iris plus 650 graphics, so I thought it's that 
laptop specific.


It is a strange error.  I'm seeing it on my laptop (an x270) but only on 
the internal screen.  If I connect an external screen using HDMI that 
screen works, but still not the internal screen.  Others aren't having 
this issue at all.


https://github.com/FreeBSDDesktop/kms-drm/issues/151 has some more (not 
very much more) info.


Regards
--
Niclas
___
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: DRM-current-kmod is still a problem at r353339

[Niclas Zeising]

On 2019-10-21 10:13, Niclas Zeising wrote:

On 2019-10-17 23:05, Mark Johnston wrote:

On Thu, Oct 17, 2019 at 10:31:12PM +0200, Niclas Zeising wrote:

On 2019-10-17 21:53, ma...@freebsd.org wrote:

On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote:

On 2019-10-16 18:57, Neel Chauhan wrote:
While drm-current-kmod worked for a little while, it broke with 
r353645.


https://i.imgur.com/Q5nYZf2.jpg

I'm using the same HP Spectre that I used earlier (where it worked 
and

where it panicked).



That commit looks unrelated, it touches the wbwd and superio drivers,
nothing else.  Any chance you can bisect exactly which revision that
caused the new issues?


I believe it was the recent work on the vm page busy state, r353539
specifically.  This patch should fix it; we don't yet have a
__FreeBSD_version number bump on which to gate the patch.

diff --git a/linuxkpi/gplv2/src/linux_page.c 
b/linuxkpi/gplv2/src/linux_page.c

index e2b85c45c..060ae85ed 100644
--- a/linuxkpi/gplv2/src/linux_page.c
+++ b/linuxkpi/gplv2/src/linux_page.c
@@ -239,7 +239,7 @@ retry:
   page = vm_page_lookup(devobj, i);
   if (page == NULL)
   continue;
-    if (vm_page_sleep_if_busy(page, "linuxkpi"))
+    if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL))
   goto retry;
   cdev_pager_free_page(devobj, page);
   }


Hi!
Hopefully someone can confirm that this patch to drm-current-kmod or
drm-devel-kmod fixes the issue.  I won't be able to work on this before
the weekend at the earliest, I'm afraid.
Mark, is it possible to get a belated version bump for this fix, and
what changed to require it?


I committed the bump and verified the patch on amdgpu.  Here are some
PRs for the drivers:

https://github.com/FreeBSDDesktop/kms-drm/pull/180
https://github.com/FreeBSDDesktop/kms-drm/pull/181


Hi!
I'm working on getting this into the versions that are in ports.  For 
drm-current-kmod it's fairly simple, but for drm-devel-kmod there are 
unrelated changes which I need to check if they are ready to go in or 
not, so it will take some more time.


Looking at the mail list thread, there seems to be a patch needed for 
base as well, has this been committed?


drm-devel-kmod and drm-current-kmod has been updated with the above fix.
If there are further issues, please let us know.
Regards
--
Niclas
___
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: DRM-current-kmod is still a problem at r353339

[Niclas Zeising]

On 2019-10-23 21:50, Clay Daniels Jr. wrote:

r353709
Looked promising, but failed:

Loaded r353709
make install drm-kmod, all 3 installed
(drm-devel-kmod, drm-current-kmod, & gpu-firmware-kmod)
set /etc/rc.conf & /boot/loader.conf configs as usual
rebooted and looked good, video tingling
pkg install xorg
rebooted and ran startx

panic: vm_page_assert_xbusied: page 0xfe0005057500 not exclusive busy @
/usr/src/sys/vm/vm_page.c

System: Ryzen 7 3700X, MSI 570 series motherboard & video card


Hi!
Did this used to work before the recent changes to current?  Can you 
please update past current r353906, which contains some fixes that was 
posted earlier in this thread.


Can you also provide the full backtrace from the panic, as well as the 
output from kldstat -v.


Thank you!
Regards
--
Niclas
___
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: DRM-current-kmod is still a problem at r353339

[Niclas Zeising]

Hi!

On 2019-10-24 01:32, Clay Daniels Jr. wrote:

Niclas, my last working install of 13.0 Current was r353072 of Oct 4th. The
next week's r353427  of Oct 11th did not work and I reverted to r353072 for
a week. Then r353709 of Oct 18th did not work, and when I tried to revert
back to r353072 it does not work either. These were install from ports, not
pkg install.

I'm looking at the available Current amd64 snapshots and all I see are:
r352778 (which worked), r353072 (worked), r353427 (did not work for me), &
r353709 (did not work for me). I don't see a r353906?


That is a specific revision of the source tree, not a snapshot.  A 
snapshot that is later than r353906 is enough.  It is also possible to 
update FreeBSD to arbitrary revisions by building the system from source.





I would like to provide the full backtrace from the panic, as well as the
output from kldstat -v, but the boot hangs at this point, and the first
line of the panic I quoted above was a pen & paper transcription. Not sure
how to get what you would like...


Sometimes, it is enough to have a photo of the information.  It is not 
as convenient as having it in text form, but in a pinch, it will do.
However, I'd syggest that you either update your system by building it 
from source (you can find details here: 
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html) 
or wait for a more recent snapshot, before trying again.


As a side note, please try to leave your reply below the message you are 
replying to, it makes the flow of the text more natural, as this way, 
you will read the e-mail in the order it was written.


Regards!
--
Niclas
___
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"

Panic using QLogic NetXtreme II BCM57810 with latest CURRENT snapshot

[Niclas Zeising]

Hi!
I got the following panic with a QLogic NetXtreme II BCM57810 when
trying to assign an IP address using dhclient.  The network card uses
the bxe driver.  The machine in question is a HP DL380 Gen9.

Kernel page fault with the following non-sleepable locks held:
shared rw if_addr_lock (if_addr_lock) locked @ /usr/src/sys/net/if.c:1539
exclusive sleep mutex bxe0_mcast_lock lockeed @
/usr/src/sys/dev/bxe/bxe.c:12548

See screenshots at the links below for details and a stack trace.
I can provoke this panic at will, let me know if you need more details.
 Unfortunately I don't have access to a console where I can copy things
out currently, so screenshots have to do.

Screenshot 1: https://people.freebsd.org/~zeising/panic1.png
Screenshot 2: https://people.freebsd.org/~zeising/panic2.png

Regards!
-- 
Niclas

___
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: Bad GPTZFSBOOT?

[Niclas Zeising]

On 2016-01-27 04:07, Larry Rosenman wrote:
> Can someone(tm) look at
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206659 for me?

Just to get the same information here as in the PR.
This seems to have broken between r294750 and r294770.  There were a
series of commits to the boot loaders in that interval.  Hopefully this
will be resolved soon.
Regards!
-- 
Niclas
___
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: iwn panic with 9.0-BETA3-amd64

[Niclas Zeising]

On 10/07/11 12:26, Rene Ladan wrote:

Hi,

just experienced a panic with if_iwn on 9.0-BETA3-amd64 (base and
kernel compiled with clang, CPUTYPE?=core2, GENERIC with CAPABILITIES).

My network card: iwn0:  mem
0xf520-0xf5201fff irq 17 at device 0.0 on pci3

iwn0: flags=8803  metric 0 mtu 2290
 ether 00:26:c6:xx:xx:xx
 nd6 options=29
 media: IEEE 802.11 Wireless Ethernet autoselect mode 11b
 status: associated

Some snippets from /var/crash/core.txt.24 :

Unread portion of the kernel message buffer:
Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex iwn0 (network driver) r = 0 (0xff8000882018)
locked @ /usr/src/9/sys/dev/iwn/if_iwn.c:3135
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b
kdb_backtrace() at kdb_backtrace+0x39
witness_warn() at witness_warn+0x438
trap() at trap+0x14c
calltrap() at calltrap+0x8
--- trap 0xc, rip = 0x804fd1c7, rsp = 0xff811850a9d0, rbp =
0xff811850aa30 ---
iwn_ampdu_tx_done() at iwn_ampdu_tx_done+0xa7
iwn_notif_intr() at iwn_notif_intr+0x523
iwn_intr() at iwn_intr+0x60c
intr_event_execute_handlers() at intr_event_execute_handlers+0x7e
ithread_loop() at ithread_loop+0xf0
fork_exit() at fork_exit+0x80
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff811850ad00, rbp = 0 ---

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xa
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x804fd1c7
stack pointer   = 0x28:0xff811850a9d0
frame pointer   = 0x28:0xff811850aa30
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 = 12 (irq259: iwn0)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 1h23m24s
Dumping 692 out of 4055 MB:..3%..12%..21%..31%..42%..51%..61%..72%..81%..91%

No symbol "dumptid" in current context.
[...]

#0  sched_switch (td=dwarf2_read_address: Corrupted DWARF expression.
) at /usr/src/9/sys/kern/sched_ule.c:1854
1854/usr/src/9/sys/kern/sched_ule.c: No such file or directory.
 in /usr/src/9/sys/kern/sched_ule.c
(kgdb) #0  sched_switch (td=dwarf2_read_address: Corrupted DWARF expression.
) at /usr/src/9/sys/kern/sched_ule.c:1854
#1  0x807f23c9 in mi_switch (flags=dwarf2_read_address:
Corrupted DWARF expression.
)
 at /usr/src/9/sys/kern/kern_synch.c:448
#2  0x in ?? ()
#3  0xff811c0367d0 in ?? ()
#4  0x0046 in ?? ()
#5  0xff811c036810 in ?? ()
#6  0x807c2075 in intr_event_handle (ie=dwarf2_read_address:
Corrupted DWARF expression.
)
 at /usr/src/9/sys/kern/kern_intr.c:1476
Previous frame inner to this frame (corrupt stack?)

[...]

More information upon request.

Regards,
René


This might or might not be related, but, I'm having trouble with the iwn 
firmware crashing. I also have a clang built kernel (and userland) 
buildwith CPUTYPE=core2. My iwn device is
iwn0:  mem 0xe400-0xe4001fff irq 
17 at device 0.0 on pci16

and the firmware gives the following output when it dies.
iwn0: iwn_intr: fatal firmware error
firmware error log:
  error type  = "NMI_INTERRUPT_WDG" (0x0004)
  program counter = 0x046C
  source line = 0x00D0
  error data  = 0x00020743
  branch link = 0x837004C2
  interrupt link  = 0x06DA18B8
  time= 1052095
driver status:
  tx ring  0: qid=0  cur=246 queued=0
  tx ring  1: qid=1  cur=0   queued=0
  tx ring  2: qid=2  cur=0   queued=0
  tx ring  3: qid=3  cur=13  queued=0
  tx ring  4: qid=4  cur=183 queued=0
  tx ring  5: qid=5  cur=0   queued=0
  tx ring  6: qid=6  cur=0   queued=0
  tx ring  7: qid=7  cur=0   queued=0
  tx ring  8: qid=8  cur=0   queued=0
  tx ring  9: qid=9  cur=0   queued=0
  tx ring 10: qid=10 cur=0   queued=0
  tx ring 11: qid=11 cur=0   queued=0
  tx ring 12: qid=12 cur=0   queued=0
  tx ring 13: qid=13 cur=0   queued=0
  tx ring 14: qid=14 cur=0   queued=0
  tx ring 15: qid=15 cur=0   queued=0
  rx ring: cur=38

The only way to restore the firmware is to reboot the computer.
Regards!
--
Niclas Zeising
___
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: /sys/amd64/conf/DEFAULTS

[Niclas Zeising]

On 11/08/11 12:36, O. Hartmann wrote:

Sorry for the boring question, but is the default configuration file
/sys/amd64/conf/DEFAULTS anywhere include in a regular configuration
file for the kernel while building the kernel?

I looked for include statements in GENERIC, but didn't find one. I use
custom kernel config files and adapt most changes from the NOTES files
in the sources tree.

With the today's update of README in /sys/amd64/conf I realised some
important changes, so this triggered my question.

I simply made an additional "include" in the custom config file, but if
this isn't necessary, I'll delete it again. And I'm interested in how
the kernel is built from. It is a very convenient way to type simply
"make kerne" in /usr/src/, but it vanishes to much of the complexity and
understanding how the system builds and could cause problems.

Thanks for your patience and tahnks in advance,

Regards,
Oliver


From my understanding of things, the DEFAULTS kernel configuration file 
is automatically included into the build by config(8). There is no need 
to include it into the generic using the "include" statement. It was 
first added 6 years ago, on October 27 2005.

Regards!
--
Niclas Zeising
___
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: Heads up: New C++ stack

[Niclas Zeising]

On 2011-11-26 21:59, David Chisnall wrote:
> Hi,
> 
> I've just imported libc++[1] and libcxxrt[2] to head.  libc++ is UUIC 
> licensed, libcxxrt is 2-clause BSDL.  The former implements the C++ standard 
> template library, and provides all of the programmer-visible parts.  The 
> latter provides an implementation of the ARM and Itanium ABI specifications 
> providing the dynamic parts of the language (RTTI, exceptions, and so on).
> 

[SNIP description of libc++, libcxxrt and instructions on how it's used]

This is great news! Thank you very much for undertaking this work.  Just
a question, is there a wiki page with these instructions, or a wiki page
related to this work where these instructions can be added?  If they're
not on the wiki, I can do the work of getting them there, just point to
where they're best suited.
Thank you once more!
Regards!
-- 
Niclas Zeising
___
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"

[PATCH] make it possible for yp_mkdb to send YPPROC_CLEAR to arbitrary host

[Niclas Zeising]

I have a patch that makes it possible to send an YPPROC_CLEAR to any 
host, not just localhost.  YPPROC_CLEAR is basically used to flush NIS 
connections, so that clients pick up changes done in the NIS maps right 
away.  Currently yp_mkdb can send this to localhost, but if the 
NIS-server is in a jail, there is no localhost.  This way YPPROC_CLEAR 
can be sent to the NIS server in jails as well.

The patch is attached and also in bin/169911 [1]
Regards
--
Niclas Zeising

[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/169911
Index: head/usr.sbin/yp_mkdb/yp_mkdb.c
===
--- head/usr.sbin/yp_mkdb/yp_mkdb.c	(revision 238532)
+++ head/usr.sbin/yp_mkdb/yp_mkdb.c	(working copy)
@@ -57,11 +57,12 @@
 static void
 usage(void)
 {
-	fprintf(stderr, "%s\n%s\n%s\n%s\n",
-	"usage: yp_mkdb -c",
+	fprintf(stderr, "%s\n%s\n%s\n%s\n%s\n",
+	"usage: yp_mkdb [-c | -C hostname]",
 	"   yp_mkdb -u dbname",
-	"   yp_mkdb [-c] [-b] [-s] [-f] [-i inputfile] [-o outputfile]",
-	"   [-d domainname ] [-m mastername] inputfile dbname");
+	"   yp_mkdb [-c | -C hostname] [-b] [-s] [-f] [-i inputfile]",
+	"   [-o outputfile] [-d domainname ] [-m mastername]",
+	"   inputfile dbname");
 	exit(1);
 }
 
@@ -105,6 +106,7 @@
 	char *infile = NULL;
 	char *map = NULL;
 	char *domain = NULL;
+	char *clearhost = "localhost";
 	char *infilename = NULL;
 	char *outfilename = NULL;
 	char *mastername = NULL;
@@ -117,7 +119,7 @@
 	FILE *ifp;
 	char hname[MAXHOSTNAMELEN + 2];
 
-	while ((ch = getopt(argc, argv, "uhcbsfd:i:o:m:")) != -1) {
+	while ((ch = getopt(argc, argv, "uhcC:bsfd:i:o:m:")) != -1) {
 		switch (ch) {
 		case 'f':
 			filter_plusminus++;
@@ -128,6 +130,10 @@
 		case 'c':
 			clear++;
 			break;
+		case 'C':
+			clear++;
+			clearhost = optarg;
+			break;
 		case 'b':
 			interdom++;
 			break;
@@ -156,6 +162,9 @@
 	argc -= optind;
 	argv += optind;
 
+	if (clear > 1)
+		usage();
+
 	if (un) {
 		map = argv[0];
 		if (map == NULL)
@@ -332,7 +341,7 @@
 		char in = 0;
 		char *out = NULL;
 		int stat;
-		if ((stat = callrpc("localhost", YPPROG,YPVERS, YPPROC_CLEAR,
+		if ((stat = callrpc(clearhost, YPPROG,YPVERS, YPPROC_CLEAR,
 			(xdrproc_t)xdr_void, &in,
 			(xdrproc_t)xdr_void, out)) != RPC_SUCCESS) {
 			warnx("failed to send 'clear' to local ypserv: %s",
Index: head/usr.sbin/yp_mkdb/yp_mkdb.8
===
--- head/usr.sbin/yp_mkdb/yp_mkdb.8	(revision 238532)
+++ head/usr.sbin/yp_mkdb/yp_mkdb.8	(working copy)
@@ -42,7 +42,7 @@
 .Nm
 .Fl u Ar dbname
 .Nm
-.Op Fl c
+.Op Fl c | Fl C Ar hostname
 .Op Fl b
 .Op Fl s
 .Op Fl f
@@ -111,6 +111,12 @@
 .Nm
 will send the signal only after the new database has been successfully
 created.
+.It Fl C
+As
+.Fl c
+but send the YPPROC_CLEAR to the specified
+.Ar hostname
+instead.
 .It Fl b
 Cause
 .Nm
___
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: Firefox-15/Thunderbird-15: won't compile on FreeBSD 10.0-CUR: /jsproxy.h:17:7: error: visibility does not match previous declaration

[Niclas Zeising]

On 2012-09-05 11:11, Dimitry Andric wrote:
> On 2012-09-05 10:11, O. Hartmann wrote:
>> Udating/reinstalling of both ports www/firefox (15.0) and
>> mail/thunderbird (15) fail with an error like showed below.
> 
>> ./jsproxy.h:17:7: error: visibility does not match previous declaration
>> class JS_FRIEND_API(BaseProxyHandler) {
> 
> Please see: http://llvm.org/bugs/show_bug.cgi?id=13688
> 
> This is either a bug in clang 3.2, or alternatively, a problem with
> inconsistent declarations in libc++.

Except that libc++ is not used here, or at least I can't see a
-stdlib=libc++ in the command line string, so it is probably not related
to libc++.
Regards!
-- 
Niclas
___
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: ZFS on HEAD

[Niclas Zeising]

On 2012-09-28 21:49, Matthew D. Fuller wrote:
> On Fri, Sep 28, 2012 at 09:44:08PM +0200 I heard the voice of
> Sami Halabi, and lo! it spake thus:
>>
>> what count for little, and what count for huge.
> 
> Off the top of my head, I'd say less than 1 gig (maybe 2) or more than
> 256.  With very little, you may need to start looking at some of the
> i386 tuning to things to scale back.  But anywhere in the middle the
> defaults should work fine (I'm sure there are gains to be had from
> working at tuning, but probably not huge and probably very dependent
> on your particular hardware and workloads).
> 
> 

Just as a measuring point, I managed to run ZFS on an moderately busy
FTP server with 2GB while waiting for replacement RAM.  It worked, but
is perhaps not the best approach.  Less than 4 or even 8GB ram is
probably not recommended these days, especially since RAM is resonably
cheap.
Regards!
-- 
Niclas
P.S.
The handbook should perhaps be slightly updated wrt ZFS, at least to
clarify that tuning is only needed on i386 in the general case, and that
you're usually better off running ZFS on an amd64 machine if you can
choose.  I'll look into it tomorrow...
___
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: HEADS UP: Clang now the default on x86

[Niclas Zeising]

On 11/06/12 14:26, Fabien Thomas wrote:


Le 5 nov. 2012 à 20:52, Brooks Davis a écrit :


I've made clang the default on x86 systems.  There will probably be a
few bumps as we work out the last kinks including a ABI issue for i386
system libraries, but the transition is expected to be fairly smooth for
most users.

Please report problems on freebsd-current or freebsd-toolchain.


Great to see that happening!

I've started rebuilding in a VM with 1Gb memory and buildworld failed because
no memory was available for the compiler (c++). It seems that Clang use a lot 
more memory?
Do you have a minimum required memory size to finish a buildworld (amd64).

Fabien


I have no trouble doing a -j8 build with 2GB memory, so 1GB should work 
fine, unless you spawn a lot of parallel builds or do a lot of other 
stuff at the same time.

Regards!
--
Niclas Zeising
___
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: lsof vs. clang

[Niclas Zeising]

On 11/06/12 14:42, Larry Rosenman wrote:

It appears that we've (mostly) cleaned up the clang/system interface
such that sysutils/lsof works with cc as clang.

Can someone tell me what we need to do to shut these up?


# LSOFCC=cc CC=cc make LSOFCC=cc CC=cc
===> lsof-4.87.a,7 depends on file: /usr/local/sbin/pkg - found
===> Extracting for lsof-4.87.a,7
=> SHA256 Checksum OK for lsof_4.87A.freebsd.tar.bz2.
===> Patching for lsof-4.87.a,7
===> Configuring for lsof-4.87.a,7
Creating ./lockf_owner.h from /usr/src/sys/kern/kern_lockf.c
./lockf_owner.h creation succeeded.
rm -f ddev.c dfile.c dlsof.h dmnt.c dnode*.c dproc.c dproto.h dsock.c
dstore.c dzfs.h kernelbase.h machine.h machine.h.old new_machine.h
__lseek.s Makefile Makefile.zfs ./tests/config.cflags
rm -f ./tests/config.cc ./tests/config.xobj ./tests/config.ldflags
Testing C library for localtime() and strftime(), using cc ... present
ln -s dialects/freebsd/dlsof.h dlsof.h
ln -s dialects/freebsd/dmnt.c dmnt.c
ln -s dialects/freebsd/dnode.c dnode.c
ln -s dialects/freebsd/dnode1.c dnode1.c
ln -s dialects/freebsd/dnode2.c dnode2.c
ln -s dialects/freebsd/dproc.c dproc.c
ln -s dialects/freebsd/dproto.h dproto.h
ln -s dialects/freebsd/dsock.c dsock.c
ln -s dialects/freebsd/dstore.c dstore.c
ln -s dialects/freebsd/dzfs.h dzfs.h
ln -s dialects/freebsd/machine.h machine.h
Makefile and lib/Makefile created.
Makefile.zfs created.
./tests/config.cc created
./tests/config.cflags created
./tests/config.ldflags created
./tests/config.xobj created
===> Building for lsof-4.87.a,7
(cd lib; make DEBUG="-O2" CFGF="-pipe -fno-omit-frame-pointer
-fno-strict-aliasing -fno-omit-frame-pointer -DHASEFFNLINK=i_effnlink
-DHASF_VNODE -DHASSBSTATE -DHAS_KVM_VNODE -DHAS_UFS1_2
-DHAS_VM_MEMATTR_T -DHAS_CDEV2PRIV -DHAS_NO_SI_UDEV -DHAS_SYS_SX_H
-DHAS_ZFS -DHAS_V_LOCKF -DHAS_LOCKF_ENTRY -DHAS_NO_6PORT -DHAS_NO_6PPCB
-DNEEDS_BOOLEAN_T -DFREEBSDV=1 -DHASFDESCFS=2 -DHASPSEUDOFS
-DHASNULLFS -DHASIPv6 -DHASUTMPX -DHAS_STRFTIME
-DLSOF_VSTR=\"10.0-CURRENT\"")
cc -pipe -fno-omit-frame-pointer -fno-strict-aliasing
-fno-omit-frame-pointer -DHASEFFNLINK=i_effnlink -DHASF_VNODE
-DHASSBSTATE -DHAS_KVM_VNODE -DHAS_UFS1_2 -DHAS_VM_MEMATTR_T
-DHAS_CDEV2PRIV -DHAS_NO_SI_UDEV -DHAS_SYS_SX_H -DHAS_ZFS -DHAS_V_LOCKF
-DHAS_LOCKF_ENTRY -DHAS_NO_6PORT -DHAS_NO_6PPCB -DNEEDS_BOOLEAN_T
-DFREEBSDV=1 -DHASFDESCFS=2 -DHASPSEUDOFS -DHASNULLFS -DHASIPv6
-DHASUTMPX -DHAS_STRFTIME -DLSOF_VSTR="10.0-CURRENT" -I/usr/src/sys -O2
-c ckkv.c
In file included from ckkv.c:43:
In file included from ./../lsof.h:195:
In file included from ./../dlsof.h:190:
In file included from /usr/src/sys/ufs/ufs/ufsmount.h:36:
/usr/src/sys/sys/buf.h:392:2: warning: implicit declaration of function
'KASSERT' is invalid in C99 [-Wimplicit-function-declaration]
KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p", bp));
^
As this hints on, KASSERT is undeclared.  You should either declare 
KASSERT manually or include the proper header file.
With that said, KASSERT look very much like kernel code, and should 
probably not be used in userland utilities at all, but I am no expert on 
this.

/usr/src/sys/sys/buf.h:392:33: warning: expression result unused
[-Wunused-value]
KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p", bp));
^
/usr/src/sys/sys/buf.h:393:41: warning: expression result unused
[-Wunused-value]
KASSERT(bp->b_bufobj->bo_ops != NULL, ("bwrite: no bo_ops bp=%p", bp));
^
/usr/src/sys/sys/buf.h:395:7: warning: expression result unused
[-Wunused-value]
("bwrite: no bop_write bp=%p", bp));
^~~~
/usr/src/sys/sys/buf.h:403:33: warning: expression result unused
[-Wunused-value]
KASSERT(bp->b_bufobj != NULL, ("bstrategy: no bufobj bp=%p", bp));
^~~~
/usr/src/sys/sys/buf.h:405:7: warning: expression result unused
[-Wunused-value]
("bstrategy: no bo_ops bp=%p", bp));
^~~~
/usr/src/sys/sys/buf.h:407:7: warning: expression result unused
[-Wunused-value]
("bstrategy: no bop_strategy bp=%p", bp));
^~
7 warnings generated.


The rest of the warnings are probably follow-up warnings since clang 
doesn't know the function prototype for KASSERT.

Regards!
--
Niclas Zeising
___
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: Traditional cpp

[Niclas Zeising]

On 2012-11-10 12:49, Dimitry Andric wrote:
> On 2012-11-10 07:46, Greg 'groggy' Lehey wrote:
>> On Friday,  9 November 2012 at 13:52:24 +0100, Dimitry Andric wrote:
> ...
>>> Looks like yet another cpp -traditional abuse.
>> Use or abuse?
> 
> Abuse, definitely. :-)  A "C Preprocessor" is clearly meant to
> preprocess C, not arbitrary text files.

Hear, hear! :)

> 
> You can see the problem of this approach, when you try to use another
> traditional preprocessor, like ports/devel/ucpp, for tools like Imake.
> Niclas Zeising can probably tell some interesting stories about this.
> 
> Any subtly different spacing, token parsing behaviour, etc. tend to
> break those tools.  They are basically relying on the specifics of the
> GNU cpp implementation.

I have not tried imake, but when using ucpp for other parts of the xorg
bundle, most notably libX11, things broke.  ucpp passed the configure
check, but when used to format text files it does not seem to work the
same as gnu cpp (unless you have to add some sort of command line flag
that I'm unaware of).  This had the unfortunate effect that locales in
xorg, amongst other things, stopped working.  What I ended up doing to
get the xorg ports to build (at least the ports pulled in by the xorg
meta port) was to simply remove the configure check for cpp
-traditional, and proceed anyway.  The only ill effects I've seen so far
is that whitespace in cpp generated files get mangled.  I have not
noticed any functional problems though.  For details, see ports r301687:
http://svnweb.freebsd.org/ports?view=revision&revision=301687

As a side note, it seems that xorg upstream is moving away from using
cpp to generate manuals, at least.

For the case of imake the issue might be harder to resolve.  I don't
know any imake internals, and I have never used it, but it seem to me
that imake uses cpp to generate and pre-process makefiles.  This might
be harder to fix by replacing cpp with sed/awk wizardry.  It might be
more worthwhile to try to fix the port that use imake to use something
else, but I have no clue about how big an undertaking this would be.
> 
> 
>> In any case, it's not the only one.  In the Good Old
>> Days people did things like that.  So, it seems, does imake, and I'm
>> sure others will come out of the woodwork.
>>
>>> Clang will most likely never support traditional preprocessing.
>>
>> OK.
>>
>>> It is probably better to just use sed or awk for this kind of
>>> trickery.
>>
>> I'm not sure that's the way to go.  It's more work than it's worth.
>>
>> What we really need is a traditional cpp.  That's not difficult:
>> there's one in 4.3BSD (all 32 kB of source).  OpenBSD also had one,
>> though it's gone now, so presumably that one has a clean license.
>> Both appear to be from pcc.  Should we import it into the tree as,
>> say, tradcpp?
> 
> Please check with Niclas and the other ports guys who have been
> wrestling with exactly this issue for some time.  They may have lots of
> good suggestions.

I have not tested anything but gnu cpp, clang cpp and ucpp.  I'm not
against the import of a traditional cpp, but to me it seems it might be
better to just fix the cpp abuse altogether.  In any case, the cpp
-traditional replacement *must* be bug-for-bug compatible with gcc cpp,
which I've been told is quite undocumented.
Regards!
-- 
Niclas
___
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: problem booting to multi-vdev root pool [Was: kern/150503: [zfs] ZFS disks are UNAVAIL and corrupted after reboot]

[Niclas Zeising]

On 11/16/12 16:45, Andriy Gapon wrote:

on 13/11/2012 18:16 Guido Falsi said the following:

My idea, but is just a speculation, i could be very wrong, is that the geom
tasting code has some problem with multiple vdev root pools.


Guido,

you are absolutely correct.  The code for reconstructing/tasting a root pool
configuration is a modified upstream code, so it inherited a limitation from it:
the support for only a single top-level vdev in a root pool.
I have an idea how to add the missing support, but it turned out not to be
something that I can hack together in couple of hours.

So, instead I wrote the following patch that should fall back to using a root 
pool
configuration from zpool.cache (if it's present there) for a multi-vdev root 
pool:
http://people.freebsd.org/~avg/zfs-spa-multi_vdev_root_fallback.diff

The patch also fixes a minor (single-time) memory leak.

Guido, Bartosz,
could you please test the patch?

Apologies for the breakage.



Just to confirm, since I am holding back an update pending on this.
If I have a raidz root pool, with three disks, like this:
NAME   STATE READ WRITE CKSUM
zroot  ONLINE   0 0 0
  raidz1-0 ONLINE   0 0 0
gpt/disk0  ONLINE   0 0 0
gpt/disk1  ONLINE   0 0 0
gpt/disk2  ONLINE   0 0 0

Then I'm fine to update without issues. the problem is only if, as an 
example, you have a mirror with striped disks, or a stripe with mirrored 
disks, which it seems to me the original poster had.

Am I correct, and therefore ok to update?
Regards!
--
Niclas Zeising
___
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"

panic: sbuf_trim makes no sense on sbuf 0xffffff82434d8898 with drain

[Niclas Zeising]

Hi!
I consistently get this panic while trying to boot a kernel build from 
r243530.  It happens when the entropy harvesting rc.d script starts. 
r243380 worked fine, I haven't tested any revisions in between. 
Attached is the backtrace from the kernel, as gotten by kgdb.  The 
machine uses zfs as a root pool, and there have been churn in this area. 
 To my untrained eyes, however, the issue seem related to hdaa.c. 
Please let me know if I can provide any more information.

Regards!
--
Niclas


panic.out
Description: Binary data
___
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: panic: sbuf_trim makes no sense on sbuf 0xffffff82434d8898 with drain

[Niclas Zeising]

On 11/25/12 23:48, m...@freebsd.org wrote:

On Sun, Nov 25, 2012 at 2:26 PM, Niclas Zeising
  wrote:

Hi!
I consistently get this panic while trying to boot a kernel build from
r243530.  It happens when the entropy harvesting rc.d script starts. r243380
worked fine, I haven't tested any revisions in between. Attached is the
backtrace from the kernel, as gotten by kgdb.  The machine uses zfs as a
root pool, and there have been churn in this area.  To my untrained eyes,
however, the issue seem related to hdaa.c. Please let me know if I can
provide any more information.


r243530 added the new sysctl that is causing panic.  I'm not sure why
there's an sbuf_trim() call; there shouldn't be more than a few \n at
the end.  IMO the sbuf_trim() can be eliminated.

Alternately, the panic check can be removed and we could allow
sbuf_trim() to remove any un-emitted whitespace for an sbuf with
drain.

CC'ing mav@ who introduced the code.  (I introduced sbuf drains).



Thank you for the quick reply!
Just to confirm, manually reverting r243530 makes the system boot 
without panicing.

Regards!
--
Niclas
___
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: new xorg segfault 11 with KMS

[Niclas Zeising]

On 12/13/12 22:48, Johannes Dieterich wrote:
> On 12/13/12 16:36, Dimitry Andric wrote:
>> On 2012-12-13 21:49, Johannes Dieterich wrote:
>>> I lately see xorg segfault 11s with CURRENT, WITH_NEW_XORG=yes and
>>> WITH_KMS=yes. Interestingly, gdm loads fine but xfce4 at login directly
>>> causes the segfault (log attached), gnome survives a bit longer but
>>> starting any bigger application (e.g. firefox) causes it to crash with
>>> the
>>> same log.
>>>
>>> I have a Xorg.core file, but since it is without debug symbols the
>>> backtrace makes little sense to me.
>>
>> Please post the backtrace anyway. :-)  Or recompile xorg-server with
>> WITH_DEBUG=yes in your environment, and reproduce the crash.
> Here we go:
> 
> I also rebuild xorg with debug enabled. Interestingly, I cannot
> reproduce the crash anymore. Either I forgot to rebuild something (seems
> unlikely) or the crash has to do with optimizations or flags not present
> in a debug build.

This is not unlikely.  There are probably places in the X codebase which
depends on gcc specific behavior, or undefined behavior, by accident or
by chance.
Regards
-- 
Niclas Zeising
___
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: new xorg segfault 11 with KMS

[Niclas Zeising]

On 12/13/12 23:03, Johannes Dieterich wrote:
> On 12/13/12 16:53, David Chisnall wrote:
>> On 13 Dec 2012, at 21:48, Johannes Dieterich wrote:
>>
>>> GNU gdb 6.1.1 [FreeBSD]
>>
>> You might try with gdb 7.x from ports.  gdb 6.1.1 from the base system
>> doesn't do a good job of understanding the newer version of DWARF that
>> clang emits.
> Did that but it doesn't change much:
> 
> I guess marking xorg-server to require USE_GCC=4.2+ would be a
> reasonable workaround for the time being?
> 

I have a shot in the dark before we try that, I just need to finish the
patch.  I'll let you all know when it's ready.
Regards
-- 
Niclas

-- 
Niclas Zeising
___
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: new xorg segfault 11 with KMS

[Niclas Zeising]

Can you please try the attached patch, against x11-servers/xorg-server.
 Apply it and recompile xorg-server with normal flags (that is, no
debugging) and let me and the list know the result when starting X.
Regards!
-- 
Niclas Zeising
Index: x11-servers/xorg-server/Makefile
===
--- x11-servers/xorg-server/Makefile	(revision 308805)
+++ x11-servers/xorg-server/Makefile	(working copy)
@@ -29,7 +29,8 @@
 XORG_REVISION=	1
 PLIST_SUB+=	OLD="@comment " NEW=""
 EXTRA_PATCHES+=	${FILESDIR}/extra-hw_dmx_glxProxy_compsize.h \
-		${FILESDIR}/extra-hw_dmx_glxProxy_glxcmds.h
+		${FILESDIR}/extra-hw_dmx_glxProxy_glxcmds.h \
+		${FILESDIR}/extra-clang
 .else
 XORG_VERSION=	1.7.7
 XORG_REVISION=	6
Index: x11-servers/xorg-server/files/extra-clang
===
--- x11-servers/xorg-server/files/extra-clang	(revision 0)
+++ x11-servers/xorg-server/files/extra-clang	(working copy)
@@ -0,0 +1,53 @@
+--- hw/xfree86/common/xf86Xinput.c.orig	2012-12-13 23:58:55.673738569 +0100
 hw/xfree86/common/xf86Xinput.c	2012-12-13 23:59:52.528738525 +0100
+@@ -479,7 +479,7 @@
+ MatchAttrToken(const char *attr, struct list *patterns,
+int (*compare)(const char *attr, const char *pattern))
+ {
+-const xf86MatchGroup *group;
++const xf86MatchGroup *group = NULL;
+ 
+ /* If there are no patterns, accept the match */
+ if (list_is_empty(patterns))
+--- hw/xfree86/parser/InputClass.c.orig	2012-12-14 00:03:07.149734651 +0100
 hw/xfree86/parser/InputClass.c	2012-12-14 00:04:09.522735172 +0100
+@@ -338,7 +338,8 @@
+ XF86ConfInputClassPtr prev;
+ 
+ while (ptr) {
+-xf86MatchGroup *group, *next;
++xf86MatchGroup *group = NULL;
++xf86MatchGroup *next;
+ char **list;
+ 
+ TestFree(ptr->identifier);
+--- hw/xfree86/dri2/dri2.c.orig	2012-12-14 00:06:39.680738243 +0100
 hw/xfree86/dri2/dri2.c	2012-12-14 00:08:14.310729622 +0100
+@@ -201,7 +201,7 @@
+ static DRI2DrawableRefPtr
+ DRI2LookupDrawableRef(DRI2DrawablePtr pPriv, XID id)
+ {
+-DRI2DrawableRefPtr ref;
++DRI2DrawableRefPtr ref = NULL;
+ 
+ list_for_each_entry(ref, &pPriv->reference_list, link) {
+ 	if (ref->id == id)
+@@ -267,7 +267,8 @@
+ {
+ DRI2DrawablePtr pPriv = p;
+ DRI2ScreenPtr   ds = pPriv->dri2_screen;
+-DRI2DrawableRefPtr ref, next;
++DRI2DrawableRefPtr ref = NULL;
++DRI2DrawableRefPtr  next;
+ WindowPtr pWin;
+ PixmapPtr pPixmap;
+ DrawablePtr pDraw;
+@@ -534,7 +535,7 @@
+ DRI2InvalidateDrawable(DrawablePtr pDraw)
+ {
+ DRI2DrawablePtr pPriv = DRI2GetDrawable(pDraw);
+-DRI2DrawableRefPtr ref;
++DRI2DrawableRefPtr ref = NULL;
+ 
+ if (!pPriv)
+ return;
___
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: new xorg segfault 11 with KMS

[Niclas Zeising]

On 12/14/12 01:24, Johannes Dieterich wrote:
> On Thu, Dec 13, 2012 at 6:51 PM, Artyom Mirgorodskiy
>  wrote:
>> This patch work for me. Thanks.
> I can confirm that it also works for me. Thanks a lot!
> 
>> On Friday 14 December 2012 00:30:52 Niclas Zeising wrote:
>>
>>> Can you please try the attached patch, against x11-servers/xorg-server.
>>
>>> Apply it and recompile xorg-server with normal flags (that is, no
>>
>>> debugging) and let me and the list know the result when starting X.
>>
>>> Regards!
Patch is applied to the ports tree now.  Thanks for help testing!
Regards!
-- 
Niclas Zeising
___
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: new xorg segfault 11 with KMS

[Niclas Zeising]

On 12/14/12 00:51, Artyom Mirgorodskiy wrote:
> This patch work for me. Thanks.
> 
> On Friday 14 December 2012 00:30:52 Niclas Zeising wrote:
>> Can you please try the attached patch, against x11-servers/xorg-server.
>>  Apply it and recompile xorg-server with normal flags (that is, no
>> debugging) and let me and the list know the result when starting X.
>> Regards!
>>

Patch is in the ports tree now.  Thanks for testing!
Regards!
-- 
Niclas Zeising
___
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: 7+ days of dogfood

[Niclas Zeising]

On 02/10/13 01:07, Steve Kargl wrote:
> In a long thread started by Peter Wemm on developers@, he described
> the move/upgrade of the FreeBSD.org cluster to using FreeBSD-10.  A
> part of his description included the need to test top-of-tree under
> actual real-world conditions.  In his words, FreeBSD should "eat its
> own dogfood."  The new installation on FreeBSD.org, of course, would
> test FreeBSD-10 under (heavy) server load. 

Just another data point, I haven't read the whole discussion yet.
On my 5 year old laptop (Intel Core2Duo) amd64 system everything works
fine, including intel graphics using WITH_NEW_XORG=, everything built
with clang.  There is no sound issues or anything, except in libmpg123
when built with clang.  The only problem is that the laptop only have
2GB ram, which is a little on the low side these days.
I also have a desktop set up in a similar way, but with a ATI graphics
card (HD4850) and a core2quad processor.  That one works splendid,
everything build with clang and linked with libc++ (as opposed to
libstdc++) and using ZFS as a boot file system
In summary, it is definitely possible to run a FreeBSD desktop off of
current, and I've never experienced any big hiccoughs that were not very
much self-inflicted.
Regards!
-- 
Niclas

___
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: 7+ days of dogfood

[Niclas Zeising]

On 02/10/13 07:33, Ian FREISLICH wrote:
> 1. WITHOUT_CLANG_IS_CC=yes
>I don't think clang is ready for prime time in FreeBSD, or FreeBSD
>isn't ready to use clang in prime time.  I got a new laptop (ASUS
>UX31A) and found that a lot of the ports I needed to install
>didn't compile or core dumped.  (Sorry I didn't report these to
>the project).
>This option sorted that problem out.  However you will need to
>rebuild everything including world and kernel with gcc before
>you start building ports with gcc or you will still have problems.

Please please please report ports that fail with clang to ports@ or the
ports maintainer or both.  If this is not done, then the problems will
never get fixed (regardless whether it is bad/broken code in the port or
a bug in clang).
Regards!
-- 
Niclas
___
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: 7+ days of dogfood

[Niclas Zeising]

On 02/13/13 00:23, Jakub Lach wrote:
> This is good moment to bring that around, 
> 
> https://wiki.freebsd.org/PortsAndClang
> 
> "Help we don't want:
> Submitting ports PR without fixes. We're not yet at the point 
> where it can help."

That should probably be removed...
Regards!
-- 
Niclas
___
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: Response of *.freebsd.org websites are very slow

[Niclas Zeising]

On 2013-02-27 20:25, Mehmet Erol Sanliturk wrote:
> I have installed snapshot
> 
> FreeBSD-9.1-STABLE-amd64-20130223-r247167-release.iso
> 
> # traceroute ftp.freebsd.org
> 
> 3 failures : traceroute : unknown host ftp.freebsd.org
> 2 successes :
> 
> Route is Izmir ( Turkey ) -> Frankfurt -> New York -> San Jose ->
> freebsd.isc.org ( 204.152.184.73 )
> 
> and pkg_add is not able to find package site .
> 
> Perhaps for many tries it may find in some of the tries , but this will not
> be a feasible way .

Does Turkey (or your ISP) have any sort of great firewall or other
restrictions on network traffic?  Do you have a firewall somewhere?
I have no trouble reaching www.freebsd.org and ftp.freebsd.org from 3
different ASes using both IPv4 and IPv6.
Regards!
-- 
Niclas
___
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: Does anyone regularly build HEAD with clang?

[Niclas Zeising]

On 2012-02-13 17:56, Jordan K. Hubbard wrote:
> 
> On Feb 13, 2012, at 5:59 AM, Dimitry Andric wrote:
> 
>> I build it very regularly, and there are several buildbots that also
>> build it continously (though they currently don't spam the mailing
>> lists).  For me, and the buildbots, head builds just fine with clang,
>> though.  What was the exact error you got during buildworld?
> 
> For that one, the error was:
> 
> clang  -O2 -pipe  -I/usr/src/lib/libc/include 
> -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS  
> -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 
> -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE 
> -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime 
> -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP 
> -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING 
> -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k 
> -Wno-uninitialized -Wno-pointer-sign -Wno-tautological-compare 
> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
> -Wno-conversion -Wno-switch-enum -Wno-empty-body -c 
> /usr/src/lib/libc/rpc/clnt_bcast.c -o clnt_bcast.o
> In file included from /usr/src/lib/libc/rpc/clnt_bcast.c:61:
> In file included from /usr/src/lib/libc/../../include/rpc/rpc.h:76:
> /usr/src/lib/libc/../../include/rpc/rpcb_clnt.h:69:8: error: unknown type name
>   'rpcblist'
> extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *);
>^
> 
> Though having made my small patch, I've now moved on to:
> 
> ./contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc 
> -I/usr/src/lib/libc/resolv -
> D_ACL_PRIVATE -DPOSIX_MISTAKE 
> -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -
> I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP 
> -DD
> ES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING 
> -std=gn
> u99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k 
> -Wno-uninitialized
> -Wno-pointer-sign -Wno-tautological-compare -Wno-unused-value 
> -Wno-parentheses-e
> quality -Wno-unused-function -Wno-conversion -Wno-switch-enum -Wno-empty-body 
> -c
>  /usr/src/lib/libc/rpc/clnt_bcast.c -o clnt_bcast.o
> /usr/src/lib/libc/rpc/clnt_bcast.c:273:28: error: variable has incomplete 
> type '
> struct r_rpcb_rmtcallargs'
> struct r_rpcb_rmtcallargs barg; /* Remote arguments */
>   ^
> 
> During stage 4.2: building libraries.
> 
>> What are your CC, CXX and CPP settings in make.conf?  And can you please
>> post the file:
> 
> My make.conf is pretty bleeding edge, tailored to seeing how far along 
> FreeBSD is to making the full transition away from gcc and other GPL'd bits.  
> I'll attach it.
> 
>>  /usr/obj/usr/src/tmp/usr/include/rpc/rpcb_prot.h
> 
> Also attached.
> 
> 
> Thanks for the prompt reply!
> 
> - Jordan

The ML ate the attachments. Either attach them as text/plain or post
them online somewhere.
Regards!
-- 
Niclas
___
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: Mesa 8.0 Info

[Niclas Zeising]

On 2012-02-13 19:32, Kevin Oberman wrote:
> On Mon, Feb 13, 2012 at 10:02 AM, O. Hartmann
>  wrote:
>> On 02/13/12 09:34, vehemens wrote:
>>
>>> 
>>
>>
>> Interesting to read that FreeBSD has now explicitly been extracted from
>> the description file :-(
> 
> Well, the section listing FreeBSD was totally removed, so all OSes
> were explicitly removed and replaced with text describing APIs. Since
> those are mostly orthogonal, I'd say that they simply removed
> references to any specific OS with DRI support.

For those of you interested in trying out MESA 8.0 it is in the
experimental xorg repository:
http://trillian.chruetertee.ch/ports/browser
It is however not part of the CFT miwi sent a week or so ago, since i
was released after that.
Feel free to try it out though, and report success/failiure.
Regards!
-- 
Niclas
___
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: Mesa 8.0 Info

[Niclas Zeising]

On 2012-02-13 20:29, Ivan Klymenko wrote:
> В Mon, 13 Feb 2012 19:57:42 +0100
> Niclas Zeising  пишет:
> 
>> On 2012-02-13 19:32, Kevin Oberman wrote:
>>> On Mon, Feb 13, 2012 at 10:02 AM, O. Hartmann
>>>  wrote:
>>>> On 02/13/12 09:34, vehemens wrote:
>>>>
>>>>> <http://cgit.freedesktop.org/mesa/mesa/commit/?id=d01de08c4c84f0406a23ce38e1c9c163ed2b91bc>
>>>>
>>>>
>>>> Interesting to read that FreeBSD has now explicitly been extracted
>>>> from the description file :-(
>>>
>>> Well, the section listing FreeBSD was totally removed, so all OSes
>>> were explicitly removed and replaced with text describing APIs.
>>> Since those are mostly orthogonal, I'd say that they simply removed
>>> references to any specific OS with DRI support.
>>
>> For those of you interested in trying out MESA 8.0 it is in the
>> experimental xorg repository:
>> http://trillian.chruetertee.ch/ports/browser
>> It is however not part of the CFT miwi sent a week or so ago, since i
>> was released after that.
>> Feel free to try it out though, and report success/failiure.
>> Regards!
> 
> Where did you see there is Mesa 8.0? Can you give my a direct link?

Here for instance:
https://trillian.chruetertee.ch/ports/browser/trunk/graphics/libGL
The whole repo is found here:
https://trillian.chruetertee.ch/ports/browser/trunk?order=name
Have a look at the wiki here http://wiki.freebsd.org/Xorg before playing
with it though.  To get the new MESA you need the KMS patch,
instructions here http://wiki.freebsd.org/Intel_GPU as well as a
resonably recent intel graphics card (Radeon might work, but that is
unlikely.)
Regards!
-- 
Niclas

P.S. For more questions regarding the experimental xorg repo, feel free
to ask on x...@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 as virtualbox guest not working

[Niclas Zeising]

Hi!
Sometime quite recent a change to FreeBSD CURRENT makes it almost 
impossible to run it as a virtualbox guest, at least under Windows.  If 
I roll back the vbox machine to a (unfortunately quite old, from 
January) CURRENT everything seems to be working.
The issue is that the virtual machine runs very very slow, and makes the 
host almost impossible to work with, especially during compiles and 
other activities involving the CPU and the disk.  I have also 
experienced that the host machine crashes, but that might be unrelated.

Is anyone else experiencing this, or am I doing something very wrong?
Let me know if I need to provide more information or if I can help in 
some other way.

Best Regards!
___
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"

[HEADS UP] xorg version switch in CURRENT

[Niclas Zeising]

[ This message is cross-posted between x11@, current@ and ports@ for
maximum coverage.  Please please PLEASE respect reply-to: ]

The xorg stack has been switched to use what has been dubbed new xorg in
CURRENT.  This means new xserver, new MESA (dri/libGL) stack and in some
cases new versions.
If you want to remain with the old stack, add WITHOUT_NEW_XORG= to
/etc/make.conf.
UPDATING contains instructions for updating.
To get VT switching when using KMS drivers (ATI, Intel) please use
newcons: https://wiki.freebsd.org/Newcons or if that is not possible,
force the use of the vesa driver for xorg.

Please send reports of successes, failures and/or comments to
x...@freebsd.org.  Remember to include any relevant information, such as
xorg logs (Xorg.log.0), dmesg, graphics card model and ports versions
with your report.

Please test this as much as possible!
Regards!
-- 
Niclas Zeising



signature.asc
Description: OpenPGP digital signature

Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found

[Niclas Zeising]

On 2013-03-11 11:58, Hartmann, O. wrote:
> Am 03/11/13 11:17, schrieb Dimitry Andric:
>> On 2013-03-10 00:39, Steve Kargl wrote:
>> ...
>>> If you have a clang built FreeBSD-current, then it is no
>>> longer possible to *bootstrap* gcc-4.6.x, gcc-4.7.x, nor
>>> the upcoming gcc-4.8.0.  AFAICT, the problem is related
>>> to /usr/bin/cpp.  I haven't tried earlier versions of
>>> gcc.
>>
>> I have built the lang/gcc47 and lang/gcc48 ports just now, and they
>> compiled without any issues.  What is the exact error you have been
>> getting?
>>
>> I think there must be a common problem you and Oliver have in your build
>> environment, most likely non-default CFLAGS.  What happens if you remove
>> make.conf and src.conf, do the gcc ports then build successfully?
> 
> 
> 
> I have build port lang/gcc and lang/gcc46 recently on another box
> running the same configuration files like the boxes which fail
> (/etc/make.conf and /etc/src.conf).
> 
> When removing /etc/make.conf and /etc/src.conf as requested, first thing
> I realize is that perl 5.14 wants to be installed - while I use
> throughout all systems perl 5.16.
> 
> Having the default /etc/make.conf with only the PERL specific adaption
> 
> PER_VERSION=5.16.2
> 
> gives a quite short journey into compiling lang/gcc with the following
> error:
> 
> cc -c -DHAVE_CONFIG_H -O2 -pipe -I/usr/local/include
> -fno-strict-aliasing  -I. -I.././../gcc-4.6.3/libiberty/../include  -W
> -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic
> .././../gcc-4.6.3/libiberty/strverscmp.c -o strverscmp.o
> rm -f ./libiberty.a pic/./libiberty.a
> /usr/local/bin/ar rc ./libiberty.a \
>   ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o
> ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o
> ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o
> ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o
> ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o
> ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o
> ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o
> ./pex-unix.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o
> ./simple-object-elf.o ./simple-object-mach-o.o ./sort.o ./spaces.o
> ./splay-tree.o ./strerror.o ./strsignal.o ./unlink-if-ordinary.o
> ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o
> ./xstrndup.o  ./mempcpy.o ./strverscmp.o
> /usr/local/bin/ranlib ./libiberty.a
> if [ x"-fpic" != x ]; then \
>   cd pic; \
>   /usr/local/bin/ar rc ./libiberty.a \
> ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o
> ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o
> ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o
> ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o
> ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o
> ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o
> ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o
> ./pex-unix.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o
> ./simple-object-elf.o ./simple-object-mach-o.o ./sort.o ./spaces.o
> ./splay-tree.o ./strerror.o ./strsignal.o ./unlink-if-ordinary.o
> ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o
> ./xstrndup.o  ./mempcpy.o ./strverscmp.o; \
>   /usr/local/bin/ranlib ./libiberty.a; \
>   cd ..; \
> else true; fi
> gmake[2]: Leaving directory `/usr/ports/lang/gcc/work/build/libiberty'
> gmake[1]: Leaving directory `/usr/ports/lang/gcc/work/build'
> gmake: *** [all] Error 2
> *** [do-build] Error code 1
> 
> Stop in /usr/ports/lang/gcc.
> *** [build] Error code 1

Do you, by any chance, use BSD grep?
Regards!
-- 
___
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: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found

[Niclas Zeising]

On 03/11/13 14:13, Steve Kargl wrote:
> On Mon, Mar 11, 2013 at 11:17:51AM +0100, Dimitry Andric wrote:
>> On 2013-03-10 00:39, Steve Kargl wrote:
>> ...
>>> If you have a clang built FreeBSD-current, then it is no
>>> longer possible to *bootstrap* gcc-4.6.x, gcc-4.7.x, nor
>>> the upcoming gcc-4.8.0.  AFAICT, the problem is related
>>> to /usr/bin/cpp.  I haven't tried earlier versions of
>>> gcc.
>>
>> I have built the lang/gcc47 and lang/gcc48 ports just now, and they
>> compiled without any issues.  What is the exact error you have been
>> getting?
> 
> Note, I said explicitly said *bootstrap*. I can build 4.6, 4.7, 
> and 4.8.  I cannot *bootstrap* these compilers.  The entire
> build log from 'gmake bootstrap |& tee gcc-4.8.0.log' is
> here
> 
> http://troutmask.apl.washington.edu/gcc-4.8.0.log
> 
> The last few lines are
> 
> checking whether  /home/sgk/gcc/obj4x/./prev-gcc/xgcc 
> -B/home/sgk/gcc/obj4x/./prev-gcc/ 
> -B/home/sgk/work/4x/x86_64-unknown-freebsd10.0/bin/ 
> -B/home/sgk/work/4x/x86_64-unknown-freebsd10.0/bin/ 
> -B/home/sgk/work/4x/x86_64-unknown-freebsd10.0/lib/ -isystem 
> /home/sgk/work/4x/x86_64-unknown-freebsd10.0/include -isystem 
> /home/sgk/work/4x/x86_64-unknown-freebsd10.0/sys-includesupports 
> -fno-rtti... yes
> checking dependency style of  /home/sgk/gcc/obj4x/./prev-gcc/xg++ 
> -B/home/sgk/gcc/obj4x/./prev-gcc/ 
> -B/home/sgk/work/4x/x86_64-unknown-freebsd10.0/bin/ -nostdinc++ 
> -B/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/src/.libs 
> -B/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/libsupc++/.libs
>  
> -I/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/include/x86_64-unknown-freebsd10.0
>  -I/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/include 
> -I/home/sgk/gcc/gcc4x/libstdc++-v3/libsupc++ 
> -L/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/src/.libs 
> -L/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/libsupc++/.libs...
>  none
> configure: error: no usable dependency style found
> gmake[2]: *** [configure-stage2-libcpp] Error 1
> gmake[2]: Leaving directory `/usr/home/sgk/gcc/obj4x'
> gmake[1]: *** [stage2-bubble] Error 2
> gmake[1]: Leaving directory `/usr/home/sgk/gcc/obj4x'
> gmake: *** [bootstrap] Error 2
> 
>> I think there must be a common problem you and Oliver have in your build
>> environment, most likely non-default CFLAGS.
> 
> No.  Here's my make.conf.
> 
> KERNCONF=SPEW
> CPUTYPE?=opteron
> FFLAGS+= -O2 -pipe -march=native -mtune=native -funroll-loops -ftree-vectorize
> MALLOC_PRODUCTION="YES"
> WITHOUT_LIB32="YES"
> WITHOUT_MODULES="YES"
> WITHOUT_NLS="YES"
> WITH_BSD_GREP="YES"
> WITH_PROFILE="YES"
> WITH_PKGNG=yes
> PRINTERDEVICE=ps
> #
> # Crap for ports.
> #
> DISABLE_MAKE_JOBS="YES"
> WITH_GHOSTSCRIPT_VER=8
> #
> # added by use.perl 2013-02-19 12:45:06
> PERL_VERSION=5.12.4
> 

This is most likely due to a incompatibility between bsd grep and gnu
grep.  Try to switch to gnu grep, and the problem will most likely go away.
Regards!
-- 
Niclas
___
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: error: unknown warning group '-Wcpp', ignored (#pragma GCC)

[Niclas Zeising]

On 05/25/13 12:09, O. Hartmann wrote:
> With CLANG on FreeBSD 10.0-CURRENT r250968, I get this error message in
> a source I try to port.
> 
> I did not find any suitable "official" workaround and I'd like to avoid
> patching all files containing those #pragma statements. Is there a
> geenral solution on FreeBSD to overcome this?
> 
> error: unknown warning group '-Wcpp', ignored
> [-Werror,-Wunknown-pragmas]
> #  pragma GCC diagnostic ignored "-Wcpp"
> 

You could always remove -Werror or -Wunknown-pragmas from CFLAGS.  Or
add -Wno-unknown-pragmas if -Wunknown-pragmas is turned on by -Wall or
something like that.
Regards!
-- 
Niclas
___
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: -Qunused-parameter and clang (was Re: GHC Port on 9-CURRENT)

[Niclas Zeising]

On 2011-06-28 21:19, Pan Tsu wrote:
> Niclas Zeising  writes:
> 
>> Sorry for hijacking this thread, and cross posting.
>>
>> On 2011-06-26 03:07, Gabor PALI wrote:
>>>
>>>
>>>> With Clang, an error occurs in one of the configure scripts, because
>>>> Clang warns about unused command-line arguments, and the configure
>>>> script assumes that to be a compiler error.  You can deal with this by
>>>> adding -Qunused-parameter to CFLAGS.
>>>
>>> Thanks for investigating this.
>>>
>>
>> This should probably be made the default, at least for ports when clang
>> is compiled, since the output generated when not using
>> -Qunused-parameter confuses configure scripts, and stops at least
>> FireFox 5 from compiling, that I know of.
> 
> Do you use ccache? Try without.
> 
> For example, the combo confuses libtool
> 

It has nothing to do with cccache. The issue is that clang by default
warns when passed flags (-std= -f -W etc.) that's not used during the
compilation/linking. This can be silenced with -Qunused-arguments, and
if not, it confuses configure scripts that believe this is an error in
the code it uses to test for features.

Regards!
-- 
Niclas Zeising
___
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 9

[Niclas Zeising]

On 2011-06-30 17:26, Tim Gustafson wrote:
> Hi,
> 
> I've installed FreeBSD 9 on a new server because 8.2 doesn't have support for 
> the LSI SAS2008 controller.  I've also built the system as a ZFS-root box, 
> and I have to say that I'm quite happy with the disk performance: we're 
> getting about 500MB/s write and 675MB/s read.  All in all, I'm very happy 
> with FreeBSD 9.
> 
> I have noticed two snafus that I thought I'd send to the group just as 
> feedback:
> 
> 
> 2. secondary IP addresses on network interfaces don't seem to be working
> 
> 
> In my rc.conf, I have:
> 
> ifconfig_bce0="1.2.3.4 netmask 255.255.252.0"
> ifconfig_bce0_alias0="1.2.3.5 netmask 255.255.255.255"
> 
> but when the machine reboots, it only gets its primary IP address.
> 

I think you need something along the line of ifconfig_bce0_alias0="inet
1.2.3.5 netmask ...", notice the 'inet', since aliasN can be used for
both inet and inet6.
HTH!
-- 
Niclas
___
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 9

[Niclas Zeising]

On 2011-06-30 19:40, Tim Gustafson wrote:
>> I think you need something along the line of
>> ifconfig_bce0_alias0="inet 1.2.3.5 netmask ...", notice the
>> 'inet', since aliasN can be used for both inet and inet6.
> 
> Got it, thanks!
> 
> I assume that's also recommended for the primary interface as well?  I've 
> added the "inet" prefix to both lines and it is working.  Thanks!
> 

I don't know if it's recommended or not, there's a ifconfig_ifN_ipv6, at
least in current, as well. But it definitely does not hurt. :)

Glad to be able to help!
-- 
Niclas
___
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: HEADS UP: BIND 9.8 imported to HEAD

[Niclas Zeising]

On 2011-07-16 13:55, Doug Barton wrote:
> Howdy,
> 
> I wanted to let everyone know that BIND 9.8.0-P4 has just been imported
> to 9-current, and will be part of the 9.0-RELEASE. The 9.8 branch has
> many nice new features vs. 9.6.x, especially in the area of DNSSEC. You
> can read more about the new features in the README file included in
> /usr/share/doc/bind9. I also encourage you to browse through the ARM,
> either in HTML or PDF format as there are other interesting features for
> both authoritative and resolving name servers.
> 
> The good news is that zone files and server configurations that work
> with BIND 9.6.x should work without modification in 9.8.x so migration
> should be painless.
> 
> If you have any problems or questions feel free to follow up here on
> -current.
> 
> 
> Doug
> 

Awesome!

-- 
Niclas Z
___
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: em problem in virtualbox since the weekend

[Niclas Zeising]

On 2011-07-20 14:33, Bernhard Froehlich wrote:
> On Wed, 20 Jul 2011 07:41:26 -0400, John Baldwin wrote:
>> On Tuesday, July 19, 2011 10:35:42 pm Steve Wills wrote:
>>> Hi,
>>>
>>> While testing some other things, I found -CURRENT from yesterday doesn't
>>> work with the em0 in my VirtualBox 4.0.8 (a little out of date
>>> admittedly). It worked Friday or Saturday I think. Anyone else seen this
>>> or should I open a PR? Has the code changed or am I perhaps
>>> misremembering dates? The error reported is:
>>>
>>> em0: Unable to allocate bus resource: memory
>>> em0: Allocation of PCI resources failed
>>
>> This is due to a bug in VirtualBox's BIOS implementation.  Someone
>> should file
>> a bug report with VirtualBox to ask them to fix their BIOS.  The problem is 
>> that they claim that the Host-PCI bridge in their system only decodes 
>> addresses 0xa-0xb (i.e. the VGA window) via the "Producer" resources 
>> in the _CRS method of the Host-PCI bridge device.  This tells the OS
>> that all
>> the existing PCI devices are using invalid memory address ranges but that 
>> there is also no available address space to allocate for PCI devices such as 
>> em0.
>>
>> You can workaround this by setting "debug.acpi.disabled=hostres" until 
>> VirtualBox fixes their code.  I'm happy to provide further
>> clarification to an
>> existing VirtaulBox bug report if needed.
> 
> Thanks a lot for the analysis! I've talked to one of the virtualbox
> developers about that but they are not aware of such problems with Linux
> or Windows guests yet. So they are currently unsure if it's a VirtualBox
> or FreeBSD fault and if it's their fault why it works fine with other
> guests. I'm also unsure because I haven't heard of that problem before
> and now multiple people complain. That looks more like a FreeBSD related
> problem on current or stable.
> 
> I think it would be good if someone could try to reproduce that with
> emulators/virtualbox-ose-legacy which is 3.2.12 to get some vbox dev
> look into the problem again.
> 

This may or may not be related, apologies if it is not.
My FreeBSD VirtualBox guest, running inside vbox under Windows, is
having trouble mounting it's root partition, mountroot dies with error
19 (which is ENODEV, I've come to understand). I can also see in the
dmesg prior to this ahci, ehci and ohci not being able to allocate
resources properly, or something similar. Rebuilding the kernel with
nooptions NEW_PCIB solves the immediate issue (i.e. the machine boots
and can find filesystems, etc.).
It is probably so, that if there is a bug in vbox bios, the old pci code
masks that bug, but the new version is more stringent and therefore dies
on it. This can be the reason no one has seen this issue up until now.
Why it works for Linux and Windows guests, I have no idea.
I hope this helps someone, or at least can shed some light on the issue
at hand.

Regards!
-- 
Niclas Zeising
___
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: files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz not found -- snapshot corrupt.

[Niclas Zeising]

On 2011-08-13 12:08, Roland Smith wrote:
> On Sat, Aug 13, 2011 at 09:51:41AM +0200, Hartmann, O. wrote:
>> On 08/13/11 09:26, Roland Smith wrote:
>>> On Sat, Aug 13, 2011 at 12:43:52AM +0200, Hartmann, O. wrote:
 On 08/12/11 22:54, Roland Smith wrote:
> On Fri, Aug 12, 2011 at 08:44:07PM +0200, Hartmann, O. wrote:
 files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
>>> Does this file actually exist if you extract the snapshot? And are the
>>> permissions et cetera OK?
>>>
>>> Roland
>>
>> No, it does not.
>>
>> What I did so far over night:
>>
>> I deleted /var/db/portsnap as well as /usr/ports/. Then I tried again. 
>> Again failure.
>> After that it got the ports tree via CVS (make update in /usr/ports). 
>> Everything seems
>> all right. I tried portsnap again. portsnap compalins about a 
>> non-portsnap-created /usr/ports
>> and please me to use 'extract'. I do ... but then I run into the very 
>> same failure:
>>
>> (portsnap fetch extract:)
>> /usr/ports/devel//
>> /usr/ports/devel/ccdoc/
>> /usr/ports/devel/ccrtp/
>> /usr/ports/devel/cdash/
>> files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz 
>> not 
>> found -- snapshot corrupt.
> 
> I've been looking at the portsnap shellscript. This error message is generated
> by the shell's built-in test command, specifically '[ -r'. It is looking for a
> file that was extracted with tar. So the place to look for the bug is IMO
> 
> 1) the portsnap script itself (differences between 8.2 and 9?)
> 2) the sh(1)'s built-in test command (ditto)
> 3) tar (ditto)
> 
> When you run 'portsnap fetch' it downloads a tgz archive and unpacks it with
> tar(1). What you could try is to comment out the line 'rm ${SNAPSHOTHASH}.tgz'
> in portsnap, and test if the tgz file extracts differently using an
> 8.2-RELEASE tar and the 9-CURRENT tar.  If so, that would be a bug!
> 
> Roland

Just a "me too!". It happens for me on a recently updated 9-current
virtual machine, built with clang.
Regards!
-- 
Niclas
___
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: Recent HEAD: buildworld is broken with clang

[Niclas Zeising]

On 2011-08-14 20:58, Oleg V. Nauman wrote:
> ===> libexec (all)
> ===> libexec/atrun (all)
> clang -O -pipe -march=i686 -mtune=i686  -DATJOB_DIR=\"/var/at/jobs/\" 
> -DLFILE=\"/var/at/jobs/.lockfile\"  -DLOADAVG_MX=1.5
> -DATSPOOL_DIR=\"/var/at/spool\"  -DVERSION=\"2.9\" -DDAEMON_UID=1
> -DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'
> -DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at
> -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
> -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized
> -Wno-pointer-sign -c /usr/src/libexec/atrun/atrun.c
> clang -O -pipe -march=i686 -mtune=i686  -DATJOB_DIR=\"/var/at/jobs/\" 
> -DLFILE=\"/var/at/jobs/.lockfile\"  -DLOADAVG_MX=1.5
> -DATSPOOL_DIR=\"/var/at/spool\"  -DVERSION=\"2.9\" -DDAEMON_UID=1
> -DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'
> -DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at
> -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
> -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized
> -Wno-pointer-sign -c /usr/src/libexec/atrun/gloadavg.c
> clang -O -pipe -march=i686 -mtune=i686  -DATJOB_DIR=\"/var/at/jobs/\" 
> -DLFILE=\"/var/at/jobs/.lockfile\"  -DLOADAVG_MX=1.5
> -DATSPOOL_DIR=\"/var/at/spool\"  -DVERSION=\"2.9\" -DDAEMON_UID=1
> -DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'
> -DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at
> -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
> -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized
> -Wno-pointer-sign  -o atrun atrun.o gloadavg.o -lpam -lutil
> clang: warning: argument unused during compilation: '-std=gnu99'
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyylex'
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyyin'
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyytext'
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyyerror'
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyylineno'
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> *** Error code 1
> 
> Stop in /usr/src/libexec/atrun.
> *** Error code 1
> 
> Stop in /usr/src/libexec.
> *** Error code 1
> 
> Stop in /usr/src.
> *** Error code 1
> 
> Stop in /usr/src.
> *** Error code 1
> 
> Stop in /usr/src.
> 

This is fixed. I had no trouble building r224865 some hours ago. This
issue might be related to the fix in r224842, Try to rebuild just the
kernel, and boot to the new kernel before doing another buildworld.
HTH!
-- 
Niclas Zeising
___
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: Buildworld failure after update r224806 to r224886

[Niclas Zeising]

-Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/rpc/svc_simple.c -o 
> svc_simple.po
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyylex'
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyyin'
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyytext'
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyyerror'
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyylineno'
> distcc[37994] ERROR: compile (null) on localhost failed
> *** Error code 1
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> 1 error
> *** Error code 2
> /usr/local/libexec/ccache/world/cc -pg -O2 -mmmx -msse -msse2 -msse3 -mssse3 
> -pipe -march=core2 -I/usr/src/lib/libc/include 
> -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -DNLS  
> -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 
> -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE 
> -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime 
> -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP 
> -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING 
> -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k 
> -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/rpc/svc_vc.c -o 
> svc_vc.po
> ...
> 
> ...
> ===> lib/clang/libllvmx86instprinter (all)
> ===> lib/clang/libllvmx86utils (all)
> ===> lib/clang/include (all)
> 6 errors
> *** Error code 2
> *** Error code 2
> 
> Stop in /usr/src.
> ...
> 
> 
> Someone have any idea what is that?
> 
> Thanks!
>

There was a period when there was a bug in dev/std{in,err,out}, which
amongst other things made it impossible to complete a buildworld.
Compile a new kernel (past r224842), boot to that kernel and rebuild
world, that should work. For details see UPDATING r224875.
HTH!

-- 
Niclas Zeising
___
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: buildworld has been broken for me since Sunday 20110815 at atrun

[Niclas Zeising]

On 2011-08-16 15:47, eculp wrote:
> Is anyone else seeing this?  This is current AMD64.  I'm running the
> compile from Saturday 20110814 that I have been hammering and it has
> been rock solid.
> 
> # uname -a
> FreeBSD home.encontacto.net 9.0-BETA1 FreeBSD 9.0-BETA1 #16: Sat Aug 13
> 05:09:17 CDT 2011
> r...@home.encontacto.net:/usr/obj/usr/src/sys/ENCONTACTO  amd64
> 
> This morning I started with a make clean to be sure and recompile all
> just in case and the same.
> 
> ===> lib/clang/include (all)
> ===> libexec (all)
> ===> libexec/atrun (all)
> cc -O2 -pipe  -DATJOB_DIR=\"/var/at/jobs/\" 
> -DLFILE=\"/var/at/jobs/.lockfile\"  -DLOADAVG_MX=1.5
> -DATSPOOL_DIR=\"/var/at/spool\"  -DVERSION=\"2.9\" -DDAEMON_UID=1
> -DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'
> -DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at
> -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
> -Wno-pointer-sign -c /usr/src/libexec/atrun/atrun.c
> cc -O2 -pipe  -DATJOB_DIR=\"/var/at/jobs/\" 
> -DLFILE=\"/var/at/jobs/.lockfile\"  -DLOADAVG_MX=1.5
> -DATSPOOL_DIR=\"/var/at/spool\"  -DVERSION=\"2.9\" -DDAEMON_UID=1
> -DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'
> -DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at
> -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
> -Wno-pointer-sign -c /usr/src/libexec/atrun/gloadavg.c
> cc -O2 -pipe  -DATJOB_DIR=\"/var/at/jobs/\" 
> -DLFILE=\"/var/at/jobs/.lockfile\"  -DLOADAVG_MX=1.5
> -DATSPOOL_DIR=\"/var/at/spool\"  -DVERSION=\"2.9\" -DDAEMON_UID=1
> -DDAEMON_GID=1  -DDEFAULT_BATCH_QUEUE=\'E\'  -DDEFAULT_AT_QUEUE=\'c\'
> -DPERM_PATH=\"/var/at/\" -I/usr/src/libexec/atrun/../../usr.bin/at
> -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
> -Wno-pointer-sign  -o atrun atrun.o gloadavg.o -lpam -lutil
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyylex'
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyyin'
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyytext'
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyyerror'
> /usr/obj/usr/src/tmp/usr/lib/libc.so: undefined reference to `_nsyylineno'
> *** Error code 1
> 
> Stop in /usr/src/libexec/atrun.
> *** Error code 1
> 
> Stop in /usr/src/libexec.
> *** Error code 1
> 
> Stop in /usr/src.
> *** Error code 1
> 
> Stop in /usr/src.
> *** Error code 1
> 
> Stop in /usr/src.
> (END)
> 
> Thanks,
> 
> ed
>

As per a recent entry in UPDATING, there was a window when a bug in
/dev/std{in,out,err} caused the kernel to be unable to buildworld. The
fix is to update to latest sources, rebuild kernel, and then do the
complete buildworld cycle.
HTH!

-- 
Niclas Z
___
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: howto: enabling journaling on softupdates

[Niclas Zeising]

On 2011-08-31 20:02, Hartmann, O. wrote:
> On 08/31/11 19:56, Garrett Cooper wrote:
>> On Wed, Aug 31, 2011 at 10:34 AM, Hartmann, O.
>>   wrote:
>>>I try to find a suitable reading/howto for how to enable softupdates
>>>on
>>>UFS2 filesystems.
>> Agreed. Added to http://wiki.freebsd.org/DocsFor9x .
> Many thanks.
> 
>>> As I could see, SU+J is enlisted to be enabled by default in
>>> 9.0-RELEASE.
>> Yes, it is on by default in bsdinstall (and I think in newfs? I could
>> be wrong).
> Great!
> 
>>>What is the status quo of that? I've several active systems running
>>>UFS2 on their system disks while data/home/mass storage is ZFS.
>>>Are their any issue with SU+J?
>> I haven't been tracking what's been going on, but several bugfixes
>> have gone in in the last couple of months post-SUJ. There might be
>> some bugs in the work, but most standard operations work out of the
>> box for me at least.
>>
>> ...
>>
>>>I hit was "-J", the option for enabling softupdate via GEOM gjournal.
>> Yeah, it's confusing..
>>
>>>Is there any special preparation to bring up an existing filesystem
>>>securely into
>>>journaling? As I read the blogs and emails in the list, it should be
>>>as simple
>>>as booting into single user mode, enabling on all partitions in
>>>question (even / ?)
>> Yes.
>>
>>>via -j softupdate-journaling, runing a foreground fsck, reboot ...
>>>that's it?
>> If all goes well, that was the entire process IIRC.
> 
> To late ... ;-) I couldn't resist the temptation, shut down the box,
> reboot single user mode,
> enabled "-j" (the lower letter `j' !!!), did a full fsck -y ... rebooted
> ...
>>>Or is there any other additional preparation like mentioned in
>>> gjournal
>>>(async mount)?
>> ENOCLUE (because I'm not aware of that with gjournal -- the last time
>> I tried setting it up things didn't work too well for me) :).
>>
>>>Thanks for patience and repsonding,
>> Sure :)!
>> -Garrett
>> _
> 
> ... and here I am again with SU+J on my box ;-)
> 
> Tomorrow, I will perform this step on all servers. I guess it's a "worth
> having".
> 
> 
> Oliver

Can you please detail a little more the steps you took to enable SU+J
and your experience with it? It sounds like a good start for a howto or
an inclusion in the handbook.
Thanks!

-- 
Niclas Zeising
___
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: 8-stable -> 9-current upgrade

[Niclas Zeising]

On 2011-09-08 02:12, Kevin Oberman wrote:
> I've been looking for any information on any special steps required to
> update from 8-stable to
> 9-current. /usr/src/UPDATING is a bit out of date as it has
> instructions for going from 5-stable
> to "current", although the instruction may well be the same.
> 
> I am particularly concerned with things like header files
> (/usr/include) that might bite me if not
> deleted.
> 
> Thanks!

I did this upgrade not too long ago (a week or maybe two) and as far as
I can tell there aren't that many special steps needed. Firstly I did
compare my custom kernel config to the 9-CURRENT generic one. Be careful
around the NFS options since they've changed names, as well as
COMPAT_TTY which isn't in generic anymore and P1003_1B_SEMAPHORES which
also is gone. There might be some more options, but this is what I can
remember on top of my head. You also might want to check src.conf if you
use that, since there are some new options added there.
After that there's just to build world and kernel, and install them, as
per usual. I had some trouble building clang, so I disabled that, and
then rebuild world and clang when 9-current was installed. Be careful
also of make delete-old-libs, since some libs have had their version
number bumped, which will make ports fail, unless you recompile those as
well.
During the mergemaster "phase" there's plenty of stuff to be merged.
Some is just version numbers, other is content as well. For instance, in
newsyslog.conf the entry for utmp is gone, replaced with utx.log and a
lot of other stuff. There has also been some changes to how network
interfaces are handled in rc.conf. There might be backwards compability
shims for now, but I don't know since I changed them to the new default
instead.
I hope this helps, and good luck with your upgrade! Let me know if I
missed out on any details.
Regards!
-- 
Niclas
___
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: Call for Testing: UEFI Changes

[Niclas Zeising]

On 03/22/18 01:45, Kyle Evans wrote:

Hello!

A number of changes have gone in recently pertaining to UEFI booting
and UEFI runtime services. The changes with the most damaging
potential are:

We now put UEFI runtime services into virtual address mode, fixing
runtime services with U-Boot/UEFI as well as the firmware
implementation in many Lenovos. The previously observed behavior was a
kernel panic upon invocation of efibootmgr/efivar, or a kernel panic
just loading efirt.ko or compiling EFIRT into the kernel.

Graphics mode selection is now done differently to avoid regression
caused by r327058 while still achieving the same effect. The observed
regression was that the kernel would usually end up drawing
incorrectly at the old resolution on a subset of the screen, due to
incorrect framebuffer information.

Explicit testing of these changes, the latest of which happened in
r331326, and any feedback from this testing would be greatly
appreciated. Testing should be done with either `options EFIRT` in
your kernel config or efirt.ko loaded along with updated bootloader
bits.

I otherwise plan to MFC commits involved with the above-mentioned
changes by sometime in the first week of April, likely no earlier than
two (2) weeks from now on April 4th.



Hi!
I've tested on two different computers, my ThinkPad x230 and my desktop 
with a Intel DQ77MK motherboard.  I've only done light testing such as 
loading efirt.ko and running efibootmgr to check the boot settings, but 
it has worked fine.

I also haven't seen any issues with console graphics on either machine.
Both computers are running CURRENT from yesterday, the desktop is on 
r331481 and the laptop probably somewhere around that as well.


Please let me know if you want me to test anything else!
Regards
--
Niclas

___
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: Call for Testing: UEFI Changes

[Niclas Zeising]

On 2018-03-25 14:52, Sheda wrote:
>>
>> I've tested on two different computers, my ThinkPad x230 and my desktop
>> with a Intel DQ77MK motherboard.  I've only done light testing such as
>> loading efirt.ko and running efibootmgr to check the boot settings, but it
>> has worked fine.
>> I also haven't seen any issues with console graphics on either machine.
>> Both computers are running CURRENT from yesterday, the desktop is on
>> r331481 and the laptop probably somewhere around that as well.
>>
> 
> ​Hi,
> 
> I also would like to test the changes on my X230 but looking at ​
> https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/12.0/, the most
> recent snapshot seems to be r331345. How did you get r331481?
> 

Hi!
I updated my FreeBSD system from source.  There are instructions here
https://www.freebsd.org/doc/handbook/current-stable.html and here
https://www.freebsd.org/doc/handbook/makeworld.html on how to do it.
Regards
-- 
Niclas
___
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: Regression Resume Lenovo T450

[Niclas Zeising]

On 05/08/18 22:09, Manuel Stühn wrote:



P.S.
I'm useing drm-stable-kmod, drm-next-kmod did not work for me.


What issues are you seeing with drm-next-kmod?
Regards
--
Niclas

___
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: suspend/resume regression

[Niclas Zeising]

On 05/13/18 09:48, Andriy Gapon wrote:

On 13/05/2018 05:25, Pete Wright wrote:

hi there - i have an amd64 laptop that's been running CURRENT for a while using
both drm-next and drm-stable for graphics. during the past week or so i've run
into issues with suspend resume...well technically resume has stopped working.
i've tested a couple configurations and none have allowed my system to resume
successfully:

- drm-next installed with DMC firmware loaded
- drm-next installed without DMC firmware loaded (worked previously)
- drm-stable with DMC
- drm-stable without DMC
- no drm modules loaded.

I've also tested these configs with the following sysctl set to 0 and 1:
hw.acpi.reset_video

at this point i'd like to help find what the regression i'm running into is, so
any pointers on how i can help? the system seems to boot and i'm pretty sure i
can ssh into it most times, just not sure what info i should grab to help.
nothing of interest in messages or dmesg buffer either.


Did you do any OS upgrades what was last working version and what is the current
version (svn revision number)?
Or any other notable changes before resume stopped working...



Hi!
I'm also seeing issues, not as severe as Pete, but after I resume (which 
works, with drm-next and DMC firmware), the system becomes sluggish.  It 
feels like I/O takes more time, and graphics are sluggish (very 
sientific, I know, but for instance git operations are much slower after 
a resume).  I know there's been an update to acpica between my system 
updates, when this started to happen, but I haven't had time to revert 
that update and test again.  I will try to do that and report back.

Regards
--
Niclas
___
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: suspend/resume regression

[Niclas Zeising]

On 05/13/18 21:44, Pete Wright wrote:



On 05/13/2018 10:27, Pete Wright wrote:



On 05/13/2018 08:58, Theron wrote:

Hi!
I'm also seeing issues, not as severe as Pete, but after I resume 
(which works, with drm-next and DMC firmware), the system becomes 
sluggish.  It feels like I/O takes more time, and graphics are 
sluggish (very sientific, I know, but for instance git operations 
are much slower after a resume).  I know there's been an update to 
acpica between my system updates, when this started to happen, but I 
haven't had time to revert that update and test again.  I will try 
to do that and report back.

Regards

Hi Niclas,
I used drm-next on Skylake with issues which sound similar. Resuming 
from suspend, or simply switching the laptop display output off and 
on from xrandr, resulted in graphics sluggishness (drop to 30fps in 
glxgears) and graphical corruption in Xorg apps, which persisted even 
after restarting these apps. Switching to drm-stable made the 
problems go away; I haven't had time to figure out what -next is 
doing differently to cause them.


Pete's issue sounds more severe, and unrelated as it happens without 
drm loaded.  My kernel is two weeks out of date (r333093), so I need 
to check whether the more recent changes affect my system as well.


so i've done a bit more debugging on my end.  i've even installed the 
11.2-BETA branch last night since 11-STABLE worked without issues 
about a month or so ago.


i've set "debug.acpi.resume_beep=1" and when resuming after entering 
an S3 sleep state the bell rings and does not stop until i do a hard 
reset (both with i915kms loaded and unloaded).


kinda at a loss as to how this could break both CURRENT and basically 
11-STABLE.  i'm going to make a ubuntu live image and test that, my 
laptop is a System76 laptop that shipped with ubuntu originally.  if 
that is broken as well then i guess this could be a hardware issue.


ubuntu live image suspends/resumes without issue so this certainly seems 
to be a freebsd issue unfortunately.  i guess next step is to attempt to 
find a working CURRENT snapshot that does suspend/resume without issue 
then start looking at commits?




Hi!
It's a bit worrisome that your regression occurs both on CURRENT and 
STABLE.  There was an update to both drm-next-kmod and drm-stable-kmod 
last week, but both are very minor.  One question, did you install from 
pkg or compile from ports?


Wrt. my own issues, I'm not entirely sure what's going on.  I tried a 
kernel from r333269 and that worked fine, however, r40 did not. 
I'll need to bisect exactly which revision causes my regression, with 
slowness and lag after resume from sleep.


Regards
--
Niclas
___
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: suspend/resume regression

[Niclas Zeising]

On 05/13/18 18:16, Michael Gmelin wrote:




On 13. May 2018, at 11:54, Niclas Zeising  wrote:


On 05/13/18 09:48, Andriy Gapon wrote:

On 13/05/2018 05:25, Pete Wright wrote:
hi there - i have an amd64 laptop that's been running CURRENT for a while using
both drm-next and drm-stable for graphics. during the past week or so i've run
into issues with suspend resume...well technically resume has stopped working.
i've tested a couple configurations and none have allowed my system to resume
successfully:

- drm-next installed with DMC firmware loaded
- drm-next installed without DMC firmware loaded (worked previously)
- drm-stable with DMC
- drm-stable without DMC
- no drm modules loaded.

I've also tested these configs with the following sysctl set to 0 and 1:
hw.acpi.reset_video

at this point i'd like to help find what the regression i'm running into is, so
any pointers on how i can help? the system seems to boot and i'm pretty sure i
can ssh into it most times, just not sure what info i should grab to help.
nothing of interest in messages or dmesg buffer either.

Did you do any OS upgrades what was last working version and what is the current
version (svn revision number)?
Or any other notable changes before resume stopped working...


Hi!
I'm also seeing issues, not as severe as Pete, but after I resume (which works, 
with drm-next and DMC firmware), the system becomes sluggish.  It feels like 
I/O takes more time, and graphics are sluggish (very sientific, I know, but for 
instance git operations are much slower after a resume).  I know there's been 
an update to acpica between my system updates, when this started to happen, but 
I haven't had time to revert that update and test again.  I will try to do that 
and report back.


Maybe a stupid question, but did you check the cpu frequency before and after 
suspend/resume? (sysctl dev.cpu)


As far as I can tell, the frequency remains the same.  I looked at 
dev.cpu.0.freq, if there's any other sysctl to look at as well, please 
let me know.

Regards
--
Niclas
___
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: suspend/resume regression

[Niclas Zeising]

On 05/13/18 17:58, Theron wrote:

Hi!
I'm also seeing issues, not as severe as Pete, but after I resume 
(which works, with drm-next and DMC firmware), the system becomes 
sluggish.  It feels like I/O takes more time, and graphics are 
sluggish (very sientific, I know, but for instance git operations are 
much slower after a resume).  I know there's been an update to acpica 
between my system updates, when this started to happen, but I haven't 
had time to revert that update and test again.  I will try to do that 
and report back.

Regards

Hi Niclas,
I used drm-next on Skylake with issues which sound similar. Resuming 
from suspend, or simply switching the laptop display output off and on 
from xrandr, resulted in graphics sluggishness (drop to 30fps in 
glxgears) and graphical corruption in Xorg apps, which persisted even 
after restarting these apps.  Switching to drm-stable made the problems 
go away; I haven't had time to figure out what -next is doing 
differently to cause them.


Pete's issue sounds more severe, and unrelated as it happens without drm 
loaded.  My kernel is two weeks out of date (r333093), so I need to 
check whether the more recent changes affect my system as well.




I have a Kaby Lake system.  I haven't tried switching outputs with 
xrandr, I have to do that as well.  What versions of drm-next and 
drm-stable have you tested?

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