Re: buildkernel: don't know how to make cleandir in drm-current-kmod

[Niclas Zeising]

On 2021-02-18 09:41, Ruslan Makhmatkhanov wrote:

Niclas Zeising wrote on 2/18/21 9:55 AM:

On 2021-02-18 06:32, Ruslan Makhmatkhanov wrote:

Hello,

trying to build kernel from
commit f61e92ca5a23450bc28169bbdd71d7674df98c19 (HEAD -> main, 
origin/main, origin/HEAD)

Author: Glen Barber 
Date:   Wed Feb 17 23:00:03 2021 -0500

world built ok, but then I have this on make kernel:

===> zlib (cleandir)
rm -f export_syms machine x86 zlib.ko zlib.kld zcalloc.o zlib_mod.o 
adler32.o compress.o crc32.o deflate.o inffast.o inflate.o inftrees.o 
trees.o uncompr.o zutil.o offset.inc genoffset.o

rm -f machine x86 .depend .depend.* GPATH GRTAGS GSYMS GTAGS
===> drm-current-kmod (cleandir)
make[3]: don't know how to make cleandir. Stop

make[3]: stopped in /usr/local/sys/modules/drm-current-kmod
*** Error code 2

Stop.
make[2]: stopped in /usr/obj/mnt/hdd/src/amd64.amd64/sys/Z1
*** Error code 1

Stop.
make[1]: stopped in /mnt/hdd/src
*** Error code 1

Stop.
make: stopped in /mnt/hdd/src

Tried to reinstall drm-current-kmod to not avail.



Can you check that you have the folder 
/usr/local/sys/modules/drm-current-kmod, and that there are sources 
inside?
drm-current-kmod no longer installs sources by default, please check 
if you have enabled that option locally.

Regards




That's what was installed by the package from official repo. Now I built 
it locally with making sure SOURCE option is enabled and kernel now 
builds. Thanks.


So, was it some temporary decision to exclude sources from the package 
by default, or since now I should manually build drm-kmod package at 
every update?




We disabled the source option because it caused too much issues.
It catches people by surprise sometimes when the drm-kmod modules are 
rebuilt automatically with the kernel, even when they are not in /usr/src.
The biggest problem though is that the general workflow often is to 
rebuild the world, then the kernel, then update ports.  This means that 
the drm-kmod srources won't be updated before the kernel is built, 
causing build failures (if you need an updated drm-kmod because of 
changes in the kernel).
Generally, the recommended way is to first buildworld/buildkernel, 
install the new kernel, remove the old drm-current-kmod before booting 
the new kernel, and then rebuild drm-current-kmod from ports with the 
new kernel.

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: buildkernel: don't know how to make cleandir in drm-current-kmod

[Niclas Zeising]

On 2021-02-18 06:32, Ruslan Makhmatkhanov wrote:

Hello,

trying to build kernel from
commit f61e92ca5a23450bc28169bbdd71d7674df98c19 (HEAD -> main, 
origin/main, origin/HEAD)

Author: Glen Barber 
Date:   Wed Feb 17 23:00:03 2021 -0500

world built ok, but then I have this on make kernel:

===> zlib (cleandir)
rm -f export_syms machine x86 zlib.ko zlib.kld zcalloc.o zlib_mod.o 
adler32.o compress.o crc32.o deflate.o inffast.o inflate.o inftrees.o 
trees.o uncompr.o zutil.o offset.inc genoffset.o

rm -f machine x86 .depend .depend.* GPATH GRTAGS GSYMS GTAGS
===> drm-current-kmod (cleandir)
make[3]: don't know how to make cleandir. Stop

make[3]: stopped in /usr/local/sys/modules/drm-current-kmod
*** Error code 2

Stop.
make[2]: stopped in /usr/obj/mnt/hdd/src/amd64.amd64/sys/Z1
*** Error code 1

Stop.
make[1]: stopped in /mnt/hdd/src
*** Error code 1

Stop.
make: stopped in /mnt/hdd/src

Tried to reinstall drm-current-kmod to not avail.



Can you check that you have the folder 
/usr/local/sys/modules/drm-current-kmod, and that there are sources inside?
drm-current-kmod no longer installs sources by default, please check if 
you have enabled that option locally.

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: Problem with X Server when updating to 38bfc6dee33

[Niclas Zeising]

On 2021-02-03 16:46, Thomas Laus wrote:


On 2/3/21 8:07 AM, Michael Gmelin wrote:


There was a problem with xorg-server which made it build without udev
on 14.

Try reinstalling xorg-server from ports (something like: portsnap
fetch extract; cd /usr/ports/x11-servers/xorg-server && make clean
reinstall clean)


That also did not work for me.  I tried with both a PS2 and a USB mouse
and neither worked with the latest port version of xorg-server.  I made
sure that sysctl 'kern.evdev.rcpt_mask=6' was set according to the
package-message.  Should I update my source to the latest?  I try to
only make one change at a time when looking into a problem.  My system
is still at 38bfc6dee33 but I have the time to rebuild everything today
with the latest xorg-server port.

Tom




I think also xf86-input-synaptics was affeced by the same issue.
In any case, kern.evdev.rcpt_mask should not need any changes on FreeBSD 
12.1 or later, the defaults have been updated there.  Unless you are 
using a serial mouse.


Can you provide an Xorg.log from the faulty system?
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: loading drm crashes system

[Niclas Zeising]

On 2021-01-25 00:19, Robert Huff wrote:


Hello:
On a system now running:

14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-d6327ae8c1: Sun Jan 24
14:16:54 EST 2021 amd64

(src+ports updated at midnight US EST)
with PORTS_MODULES="drm-current-kmod gpu-firmware-kmod", starting
the system _without_ loading drm results in a usable system.
Loading drm - whether via kldlist in rc.conf or by kldload at the
console immediately after start-up - instantly crashes the system; the
screen goes blank and the lights on the monitor report no signal
from the system.


[snip error log]



[insert image of open jaw and glassy-eyed stare]
The GPU is a Radeon HD 3300, and at one point this used to work.
Help, please?



When did it stop working?
Which version of drm-current-kmod?
Can you try to remove it and build it directly from an updated ports 
tree, without using PORTS_MODULES=, and see if that helps?

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: geeqie, and neverball build problem on 13-current

[Niclas Zeising]

On 2020-09-24 11:52, Stefan Esser wrote:

Am 24.09.20 um 11:24 schrieb Niclas Zeising:

On 2020-09-24 11:17, monochrome wrote:
Not sure how long this has been a problem, I noticed with the new 
version of geeqie (geeqie-devel builds fine) and found the neverball 
problem when rebuilding all packages to investigate. neverball output 
changes with consecutive build attempts, geeqie does not.


This is related to the update of llvm to 11.  With this update, builds 
are by default using -fno-common, which means global variables cannot 
exist in multiple places.  gcc 10 has the same default.  A quick fix 
is to add -fcommon to CFLAGS, but the proper fix is to update the 
application source to only have the variable in one place.


This was very easy to fix (like most of the ports affected by the
-fno-common issue).

The port is updated (r549911) and packages will appear in due time.


Great!
Thanks for doing the work!
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: geeqie, and neverball build problem on 13-current

[Niclas Zeising]

On 2020-09-24 11:17, monochrome wrote:
Not sure how long this has been a problem, I noticed with the new 
version of geeqie (geeqie-devel builds fine) and found the neverball 
problem when rebuilding all packages to investigate. neverball output 
changes with consecutive build attempts, geeqie does not.





This is related to the update of llvm to 11.  With this update, builds 
are by default using -fno-common, which means global variables cannot 
exist in multiple places.  gcc 10 has the same default.  A quick fix is 
to add -fcommon to CFLAGS, but the proper fix is to update the 
application source to only have the variable in one place.

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: vfs.zfs.min_auto_ashift and OpenZFS

[Niclas Zeising]

On 2020-09-09 17:55, Ryan Moeller wrote:


On 9/8/20 4:31 PM, Niclas Zeising wrote:

On 2020-05-02 02:20, Matthew Macy wrote:

OpenZFS doesn't have the same ashift optimization logic that FreeBSD
has. It's something that needs to be resolved before the code can be
integrated downstream.


So currently all pools created with OpenZFS will use 512 bit 
alignment, at least if the underlying storage device uses 512bit 
sectors (which most drives tend to do)?


If this is the case, it feels like a pessimisation.

Regards



The vdev ashift optimizations from FreeBSD were put in OpenZFS before 
the import into base. That sysctl does work now.




Thank you for the clarification!
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: vfs.zfs.min_auto_ashift and OpenZFS

[Niclas Zeising]

On 2020-05-02 02:20, Matthew Macy wrote:

OpenZFS doesn't have the same ashift optimization logic that FreeBSD
has. It's something that needs to be resolved before the code can be
integrated downstream.


So currently all pools created with OpenZFS will use 512 bit alignment, 
at least if the underlying storage device uses 512bit sectors (which 
most drives tend to do)?


If this is the case, it feels like a pessimisation.

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: Is pkg site forbidden by brower?

[Niclas Zeising]

On 2020-09-06 09:00, grarpamp wrote:

On 9/6/20, Kevin Oberman  wrote:

On Sat, Sep 5, 2020 at 8:04 PM Yoshihiro Ota  wrote:

Is "403 Forbidden" an intended response for a brower access to
http://pkg.freebsd.org/FreeBSD:12:i386/ nowdays?

I used to see available packages with a brower and decided which one to
use.


Some more people have noted this change
as breaking tool scripts, etc.

And useful meta files are unfortunately now invisible:
packagesite.txz, meta.txz, pkg.txz, pkg.txz.sig

If someone want to block the '/.../All/' dir full of pkgs,
maybe, but do not block any other part of the hier.


The reason that folder listing was disabled on the package download 
sites is that it used too much resources.  For every hit on those URLs, 
the web server had to dynamically generate the folder listing, and send 
it.  This caused DDoS-like scenarios, where these were hit repeatedly, 
which caused problems for legitimate traffic.  Since the relevant 
information is available in the txz files above, and also on freshports, 
and since pkg have no need for directory listing, it was disabled.


I would suggest using freshports.org, which has information on which 
version of a package is available for the various FreeBSD versions and 
architectures, both in the latest and the quarterly branch.





How can I find distributions like "latest", "release_X", etc?


Yes, there does not appear to be any docs enumerating all
the available live names for use in PACKAGESITE url.
Reopening the above dirs would be self documenting.


I am not sure what you are looking for here.  Can you explain the use 
case, what are you trying to accomplish?




The name for the term in  position of /${ABI}//All/...
might be "REPOSITORY_ROOT" or "repo-path" or simply "repository",
but it does not seem defined for users in pkg or pkg.conf manpages.
"distribution" is unlikely the correct term, "branch" might be
a useful connotation regarding ports source tree.


Once again, I'm not sure what you are looking for.  Have you looked at 
the manual for pkg.conf, which is fairly extensive and have several 
examples.





Does https://pkg-status.freebsd.org/builds?jailname=121amd64 have what you
want?


Those names don't correspond 1:1 to anything on pkg.freebsd.org.


Actually, they do. You can see both the ports tree built (default for 
top of the ports tree, and quarterly for the quarterly branch), as well 
as architecture and FreeBSD version.  You can even see exactly which svn 
revision is used.





I can't believe that there is no way to see a log of failed builds,
but I can only see the new failures and no information on previous builds.


Pkg buildlogs are a separate issue.
They should be available for browsing, same as kernel, base...


Build logs are available, but not all of them are available over IPv4, 
since IPv4 addresses are scarce.  If you open a specific builder, you 
can see a list of new failures, and links to the build logs.  There are 
also links to previous builds, so that you can compare, and find earlier 
failures.


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"

deprecation of drm-legacy-kmod

[Niclas Zeising]

[ cross posted across several mailing lists, please respect reply-to ]

Hi!

It is time to deprecate drm-legacy-kmod, since it is taking too much 
time to maintain and are holding off changes in other areas.


drm-legacy-kmod was created to aid in the transition to the LinuxKPI 
based graphics drivers, at a time when the new drivers only supported 
amd64.  Since then, the new drivers have been updated to support more 
architectures and more GPUs, and the burden of maintaining 
drm-legacy-kmod has increased.  It became apparent with the update of 
xorg-server to 1.20 that drm-legacy-kmod is too old to work with certain 
aspects of the graphics stack, and it is also holding back changes in 
areas of the FreeBSD base system such as VM scaling and optimization. 
The VM locking protocol needs to be changed, and to port those changes 
to these drivers would require extensive reworking of its use of the 
FreeBSD VM subsystem.  This means it is time for it to go.


The driver will remain for a transition period.  For FreeBSD 13-CURRENT, 
this will be fairly short, as there are changes to FreeBSD base that 
breaks the drivers.  For FreeBSD 12, the driver will remain a bit 
longer, to ease in transition.  On FreeBSD 12, there is also the option 
of using the graphics drivers in base, although those are supported on a 
best-effort basis only.


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: KiCad is horrible on CURRENT

[Niclas Zeising]

On 2020-07-29 21:18, Poul-Henning Kamp wrote:


Michael Gmelin writes:


Which driver are you using?


drm-devel-kmod-5.3.g20200724



Can you try with drm-current-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: FYI: forum web site is .. unreadable

[Niclas Zeising]

On 2020-06-23 08:48, Gary Jennejohn wrote:

On Tue, 23 Jun 2020 01:14:52 +0200
Steffen Nurpmeso  wrote:


Hello.

Normally i do not do forums (web interface etc etc), but i was
interested in ZFS encryption support and so i searched, and found
a page[1].  Now when i open that on a glibc Linux box with

   #?0|kent:src$ prt-get info firefox-bin
   Name: firefox-bin
   Path: /usr/ports/opt
   Version:  77.0.1
   Release:  1
   Description:  Firefox binary
   URL:  http://www.mozilla.com
   Maintainer:   Fredrik Rinnestam, fredrik at crux dot guru
   Dependencies: gtk3,dbus-glib

i.e. Mozilla.com-compiled firefox, then i see a small forum
"frame" on the right side, it is right of the "Foundation" link in
the link bar.  It is just large enought to place "To be honest,"
in a single line, on a, well, pretty wide screen.

   [1] https://forums.freebsd.org/threads/native-encryption-of-zfs.70284/

Ciao, and good night from Germany,



I see exactly the same bad formatting with the standard firefox port.  All the
text is pushed to the right.

seamonkey works, but it's been removed from ports.



It looks fine on my 1080p display, using Firefox from FreeBSD 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"

Re: lock order reversal and poudriere

[Niclas Zeising]

On 2020-05-02 20:36, Kurt Jaeger wrote:

Hi!


I am compiling some packages with poudriere on 13-current kernel. I
noticed some strange messages printed into the terminal and dmesg:

lock order reversal:

[...]

Are those the debug messages that aren't visible on non-current kernel
and should they be reported?

Yes, they should be checked and reported.

For more details see:

http://sources.zabbadoz.net/freebsd/lor.html

There's a webpage with a list of all known LORs and a way to
report new LORs.



Thanks Kurt. I can't find those two specific LORs in the list on that
page. The page also says to report them using a link, which leads to 404
:-), or on this mailing list, which I did. I am not sure what else should
I do.


I don't know, either 8-} bz@ is in Cc:, so he'll probably know what
to do.


How do I know if I have got a backtrace?

Are those errors:

pid 43297 (conftest), jid 5, uid 0: exited on signal 11

related or it's a different issue?


I think that's a different issue.



conftest is when configure scripts do things.  Configure works a lot by 
compiling (and sometimes running) small snippets of code to figure out 
what's going on.  Sometimes those snippets core dump.  It's all normal.

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: Weird mouse behaviour

[Niclas Zeising]

On 2020-04-27 17:06, Malcolm Matalka wrote:



Michael Gmelin  writes:



Could you share your setup by running

   pkg install ca_root_nss
   fetch \
   
https://raw.githubusercontent.com/grembo/xorg-udev-setup-check/master/xorg-udev-setup-check.sh
   ./xorg-udev-setup-check.sh -desk

and mailing the resulting file to the list (or just me directly)?


I ran this and emailed results to Michael.  I fixed the issues it
brought up and, tada, it's working.

One thing I'm not sure about is: how do I persist the changes?  I have
done:

xinput --set-prop "SynPS/2 Synaptics TouchPad" "libinput Tapping
Enabled" 1

xinput --set-prop "SynPS/2 Synaptics TouchPad" "libinput Accel Speed" 0.3


I put these in my .xinitrc, before i start my window manager.  xinitrc 
is read by startx.  If you're using a session manager (gdm, sddm or 
similar) it should be possible to put the same commands in .xsession 
instead.


But these names don't seem to directly correspond to names in man 4
libinput.  Why the difference?

I also noticed in xorg logs:

[34.491] (EE) event6  - SynPS/2 Synaptics TouchPad: kernel bug: Touch jump 
detected and discarded.
See 
https://wayland.freedesktop.org/libinput/doc/1.15.5/touchpad-jumping-cursors.html
 for details
[34.491] (EE) event6  - SynPS/2 Synaptics TouchPad: WARNING: log rate limit 
exceeded (5 msgs per 720ms). Discarding future messages.



Those warnings can be disregarded.  They're not great, but I see them 
too and I haven't found any ill effects.

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: Weird mouse behaviour

[Niclas Zeising]

On 2020-04-27 11:29, Michael Gmelin wrote:



On Mon, 27 Apr 2020 08:28:50 +
"Poul-Henning Kamp"  wrote:



In message <65670198-e725-5b66-646c-5b147c943...@daemonic.se>, Niclas
Zeising writes:


With my touchpad, ctrl left click and ctrl right click opens two
different menus in xterm, main menu and vt font menu, respectively.


ctrl-middle should open "VT Options"



I could reproduce this on my laptop and found the fix.

The problem is, that the middle mouse button only generates a key
press/key release event pair once its released (can be seen using xev
and `libinput debug-events').

This is caused by the trackpoint driver using one-button scrolling by
default (that is, you can hold the middle mouse button and move the
trackpoint - even though this didn't work for me).

You can disable on-button scrolling using xinput, e.g.

xinput set-prop 'TPPS/2 IBM TrackPoint' \
   'libinput Scroll Method Enabled' 0 0 0

After this, Ctrl+middle works as expected in xterm.

Note: Check `xinput' output to get the correct device name for your
trackpoint (you can also use its numeric identifier, but the name is
supposed to be more stable).


Nice catch!
I tried looking at xev myself, but apparently, I didn't look closely 
enough.  Now when I know what to look for, I see it clearly.

Thanks for your help!
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: Weird mouse behaviour

[Niclas Zeising]

On 2020-04-27 10:28, Poul-Henning Kamp wrote:


In message <65670198-e725-5b66-646c-5b147c943...@daemonic.se>, Niclas Zeising 
writes:


With my touchpad, ctrl left click and ctrl right click opens two
different menus in xterm, main menu and vt font menu, respectively.


ctrl-middle should open "VT Options"



This could be an upstream issue.  I did a quick test on a linux system I 
had close by, and ctrl+middle click doesn't open a menu there either.

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: Weird mouse behaviour

[Niclas Zeising]

On 2020-04-27 10:14, Malcolm Matalka wrote:



Niclas Zeising  writes:


On 2020-04-27 08:03, Malcolm Matalka wrote:

I saw that there was another thread on this and I wanted to throw my
experience in: my mouse was sluggish and tap-to-click did not work.  I
set the evdev mask back to 3 and it worked.

I am on a Dell XPS 13.


Hi!
Is this on CURRENT?  When using X?
Can you verify that you have xf86-input-libinput installed?
You can change sensitivity and enable tap to click using xinput.
Regards


Yes this is current, and I'm on commit 360355.  Yes I do have it
installed.  And yes I am on X.

The situation I was in this morning after installing the new kernel was
things that previously worked no longer worked so I did the shortest
path I could find to get them working, which was modifying this evdev.

Is there a document on how one is supposed to configure their system in
X?  I have never used xinput, instead I have configured my trackpad
through sysctl.  I'm happy to do it the way that is considered correct
but I've sort of pieced together how to get my system setup.



First off, do you have any local xorg conf?  That's generally not needed 
any more.

For xinput, I suggest start with the manual.
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: Weird mouse behaviour

[Niclas Zeising]

On 2020-04-27 09:26, Poul-Henning Kamp wrote:


In message <7549a5dd-3edc-4efd-bc0b-4d67232b4...@grem.de>, Michael Gmelin 
writes:


In my case, with the default

sysctl kern.evdev.rcpt_mask=12

CTRL + middle button would not activate the menu in xterm.



Are you using the trackpoint?


No, the touchpad.


Did you set the trackpoint sysctl?
(hw.psm.trackpoint_support=1)


That seems to default to one ?



It's the default on current and stable, but not any release (yet).

With my touchpad, ctrl left click and ctrl right click opens two 
different menus in xterm, main menu and vt font menu, respectively.


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: Weird mouse behaviour

[Niclas Zeising]

On 2020-04-27 08:03, Malcolm Matalka wrote:

I saw that there was another thread on this and I wanted to throw my
experience in: my mouse was sluggish and tap-to-click did not work.  I
set the evdev mask back to 3 and it worked.

I am on a Dell XPS 13.


Hi!
Is this on CURRENT?  When using X?
Can you verify that you have xf86-input-libinput installed?
You can change sensitivity and enable tap to click using xinput.
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: FreeBSD-13.0-CURRENT-amd64-20200409-r359731: drm-kmod failure?

[Niclas Zeising]

On 2020-04-11 08:09, Clay Daniels wrote:

I removed what I thought was FreeBSD-13.0-CURRENT-amd64-20200402-r359556
snapshot yesterday. It was working fine. I loaded the 20200409-r359731
snapshot, rebooted, installed drm-kmod, and it booted into the first
"flash" screen where there is a great light show as normal, but stalled out
there.

Today I cleaned up the partition and re-installed. I put the appropriate
line in /etc/rc.conf: kld_list='amdgpu" but DID_NOT use the line I have
been adding to /boot/loader.conf: hw.syscons.disable=1 . This time there
was more no nice graphics light show, but it stalled with db> debug prompt.
The section was where it tries to load drm-kmod & amdgpu.

Just now I reloaded r359556 from Apr 2. It works just fine. I will use this
until next weeks Thursday Current snapshot,, and see what happens.



How did you install the driver?
When using the drm drivers on current, you usually have to build them 
from ports rather than use the packages, this way the driver matches the 
kernel you are using.

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: Undefined symbol "xf86DisableRandR"

[Niclas Zeising]

On 2020-04-04 01:44, Chris wrote:

I'm struggling with a build of 13/current on a box.
Everything went pretty much as I might expect. But I'm stuck
on Xorg; big changes. I read updating, and understood that
building xorg-server with default options would DTRT. I
I added the sysctl(8) line for the keyboard, installed
my video driver (nvidia), and also followed advise in
pkg-message.

Starting Xorg resulted in:
...
ld-elf.so.1: /usr/local/lib/xorg/modules/drivers/nvidia_drv.so: 
Undefined symbol

"xf86DisableRandR"

So I searched the interweb for solution(s), and found a
shell script in pr(1) 196678. Ran it, and was informed that the
xf86-input-evdev driver was not installed. I installed it. But
the results were the same.

Thoughts? Solutions?

Thank you for all your time, and consideration.



Hi!
Are you using the nVidia driver version 304 by any chance?  That version 
of the nVidia driver does not support xorg-server 1.20, and since it's a 
binary driver there is not much we can do about it.  I suggest you talk 
to nVidia about getting the driver to support xserver 1.20.

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: users of xorg, in particular on FreeBSD 11.3

[Niclas Zeising]

On 2020-03-23 22:00, Niclas Zeising wrote:
In ports r528813 I switched FreeBSD 11 (including FreeBSD 11.3 and the 

   
This should be r529003, sorry about that.


upcoming 11.4) back to use the legacy rule set.  This means that once 
you have installed libxkbcommon 0.10.0_2 on FreeBSD 11, things should 
work as normal, and the environment variable XKB_DEFAULT_RULES does not 
need to be changed.


If you are on FreeBSD 12 or later, and are using xf96-input-keyboard, 
you might still need to set this env variable.  Please see the 
instructions below.


Regards

On 2020-03-21 00:41, Niclas Zeising wrote:
[ This is cross-posted across several mailing lists for maximum 
visibility.  Please respect reply-to and keep replies to 
x...@freebsd.org . Thank you! ]


In order to improve support when using evdev to manage input devices, 
in particular keyboards, we have switched the default in 
x11/libxkbcommon to the evdev instead of the legacy ruleset.  This was 
done in ports r528813 .


On FreeBSD 11.3, the default configuration still requires the legacy 
ruleset.


If you are using FreeBSD 11.3, or if you are using xf86-input-keyboard 
on FreeBSD 12 or later, you need to change the ruleset used by 
x11/libxkbcommon.


If you have issues with your keyboard, most notably arrow keys, and if 
/var/log/Xorg.*.log shows that the "kbd" or "keyboard" driver is being 
used, you need to switch to legacy rules by setting the environment 
variable XKB_DEFAULT_RULES to xorg.


The easiest way to accomplish this is by adding it to your shell 
startup file.


As an example, for users of [t]csh, put
   setenv XKB_DEFAULT_RULES xorg
in ~/.login

For users of bourne type shells (sh, bash, ksh, zsh, ...) instead put
export XKB_DEFAULT_RULES=xorg
in ~/.profile

Regards





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: users of xorg, in particular on FreeBSD 11.3

[Niclas Zeising]

In ports r528813 I switched FreeBSD 11 (including FreeBSD 11.3 and the 
upcoming 11.4) back to use the legacy rule set.  This means that once 
you have installed libxkbcommon 0.10.0_2 on FreeBSD 11, things should 
work as normal, and the environment variable XKB_DEFAULT_RULES does not 
need to be changed.


If you are on FreeBSD 12 or later, and are using xf96-input-keyboard, 
you might still need to set this env variable.  Please see the 
instructions below.


Regards

On 2020-03-21 00:41, Niclas Zeising wrote:
[ This is cross-posted across several mailing lists for maximum 
visibility.  Please respect reply-to and keep replies to x...@freebsd.org 
. Thank you! ]


In order to improve support when using evdev to manage input devices, in 
particular keyboards, we have switched the default in x11/libxkbcommon 
to the evdev instead of the legacy ruleset.  This was done in ports 
r528813 .


On FreeBSD 11.3, the default configuration still requires the legacy 
ruleset.


If you are using FreeBSD 11.3, or if you are using xf86-input-keyboard 
on FreeBSD 12 or later, you need to change the ruleset used by 
x11/libxkbcommon.


If you have issues with your keyboard, most notably arrow keys, and if 
/var/log/Xorg.*.log shows that the "kbd" or "keyboard" driver is being 
used, you need to switch to legacy rules by setting the environment 
variable XKB_DEFAULT_RULES to xorg.


The easiest way to accomplish this is by adding it to your shell startup 
file.


As an example, for users of [t]csh, put
   setenv XKB_DEFAULT_RULES xorg
in ~/.login

For users of bourne type shells (sh, bash, ksh, zsh, ...) instead put
export XKB_DEFAULT_RULES=xorg
in ~/.profile

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"

users of xorg, in particular on FreeBSD 11.3

[Niclas Zeising]

[ This is cross-posted across several mailing lists for maximum 
visibility.  Please respect reply-to and keep replies to x...@freebsd.org 
. Thank you! ]


In order to improve support when using evdev to manage input devices, in 
particular keyboards, we have switched the default in x11/libxkbcommon 
to the evdev instead of the legacy ruleset.  This was done in ports 
r528813 .


On FreeBSD 11.3, the default configuration still requires the legacy 
ruleset.


If you are using FreeBSD 11.3, or if you are using xf86-input-keyboard 
on FreeBSD 12 or later, you need to change the ruleset used by 
x11/libxkbcommon.


If you have issues with your keyboard, most notably arrow keys, and if 
/var/log/Xorg.*.log shows that the "kbd" or "keyboard" driver is being 
used, you need to switch to legacy rules by setting the environment 
variable XKB_DEFAULT_RULES to xorg.


The easiest way to accomplish this is by adding it to your shell startup 
file.


As an example, for users of [t]csh, put
  setenv XKB_DEFAULT_RULES xorg
in ~/.login

For users of bourne type shells (sh, bash, ksh, zsh, ...) instead put
export XKB_DEFAULT_RULES=xorg
in ~/.profile

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: New Xorg - different key-codes

[Niclas Zeising]

On 2020-03-11 10:29, Niclas Zeising wrote:

On 2020-03-11 01:46, Greg 'groggy' Lehey wrote:

Sorry.  I should have thought of reporting it.  For me, with a number
of other issues, it was a frustrating week,some of which are still not
resolved.


As a side note, if it's not reported, it's very hard for us to be aware 
of issues, and to help out in resolving them.


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: New Xorg - different key-codes

[Niclas Zeising]

On 2020-03-11 10:27, Mark Martinec wrote:

I just updated my laptop from source, and somewhere along the way
the key-codes Xorg sees changed.


Indeed.  This doesn't just affect -CURRENT: it happened to me on
-STABLE last week, so I'm copying that list too.


And a "Down" key now opens and closes a KDE "Application Launcher",
alternatively with its original function (which makes editing a 
frustration).


   https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244354



And that PR has a suggested solution for at least KDE users.
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: New Xorg - different key-codes

[Niclas Zeising]

On 2020-03-11 01:46, Greg 'groggy' Lehey wrote:


On Wednesday, 11 March 2020 at  0:20:03 +, Poul-Henning Kamp wrote:
[originally sent to current@]

I just updated my laptop from source, and somewhere along the way
the key-codes Xorg sees changed.


Indeed.  This doesn't just affect -CURRENT: it happened to me on
-STABLE last week, so I'm copying that list too.  See
http://www.lemis.com/grog/diary-mar2020.php?topics=c=Daily%20teevee%20update=D-20200306-002910#D-20200306-002910
, not the first entry on the subject.


I have the right Alt key mapped to "Multi_key", which is now
keycode 108 instead of 113, which is now arrow left instead.


Interesting.  Mine wandered from 117 to 147, with PageDown ("Next") as
collateral damage.  It seems that there are a lot of strange new key
bindings (partial output of xmodmap -pk):

 117 0xff56 (Next)   0x (NoSymbol)   0xff56 (Next)
 130 0xff31 (Hangul) 0x (NoSymbol)   0xff31 (Hangul)
 131 0xff34 (Hangul_Hanja)   0x (NoSymbol)   0xff34 
(Hangul_Hanja)
 135 0xff67 (Menu)   0x (NoSymbol)   0xff67 (Menu)
 147 0x1008ff65 (XF86MenuKB) 0x (NoSymbol)   0x1008ff65 
(XF86MenuKB)

Some of these may reflect other remappings that I have done.


I hope this email saves somebody else from the frustrating
morning I had...


Sorry.  I should have thought of reporting it.  For me, with a number
of other issues, it was a frustrating week,some of which are still not
resolved.



This has to do with switching to using evdev to handle input devices on 
FreeBSD 12 and CURRENT.  There's been several reports, and suggested 
solutions to this, as well as an UPDATING entry detailing the change.


I'm sorry that it has caused fallout, but it is something that needs to 
be done in order to keep up with upstream graphics stack, and to improve 
FreeBSD desktop support in general.


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678 has some 
discussions regarding input devices, as does the x11@ mailing list archives.


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"

users of drm-legacy-kmod or drm drivers from base

[Niclas Zeising]

[ This is cross-posted across several mailing lists for maximum 
visibility.  Please respect reply-to and keep replies to x...@freebsd.org 
. Thank you! ]


In order to improve support for the new lkpi based graphics drivers 
(drm-kmod) and to improve the graphics stack we have switched mesa to 
prefer DRI3 over DRI2.  This was done in r528071.  For those using 
drm-kmod, this should improve performance somewhat, and more importantly 
alleviate the use of the FIXDRM option (now removed) in xorg-server.


However, for those of you using graphics/drm-legacy-kmod or the drm 
drivers in base, this change can cause issues.  If you are experiencing 
problems when running OpenGL applications, you can force the use of the 
DRI2 backend.


To force mesa to use DRI2, set the environment variable 
LIBGL_DRI3_DISABLE to 1 before starting any OpenGL application.  The 
easiest way to accomplish this is by adding it to either your shell 
startup file or ~/.xinitrc.


As an example, for users of [t]csh, put
setenv LIBGL_DRI3_DISABLE 1
in ~/.cshrc.

For users of bourne type shells (sh, bash, ksh, zsh, ...) instead put
export LIBGL_DRI3_DISABLE=1
in ~/.profile

If you are using these legacy drivers, I'm also very interested in 
hearing what issues you are facing that prevents you from using the new 
lkpi based drivers.


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: 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"

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]

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-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-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 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-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-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-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: 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: 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-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 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: 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: 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-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"

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: 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"

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: 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: 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: 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: 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: 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: 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"

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: 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"

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: 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: 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: 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: "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: 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: 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 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: "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: "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: 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"

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: 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+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: 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"

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: 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: ntpd as ntpd user question

[Niclas Zeising]

On 07/21/18 19:56, RW wrote:

On Sat, 21 Jul 2018 11:14:45 -0600
Ian Lepore wrote:



There's a "pre-world" stage of mergemaster (-Fp option I think) which
isn't needed often, but one of the times it is needed is apparently
when new user ids are added.


I wish mergemaster had an option to just add new users and groups,
rather than merging the files.


etcupdate is usually pretty good at automatically merge updates to files 
without user interaction, even when the files are locally edited as 
well.  For instance, I had no problem merging /etc/master.passwd and 
/etc/group for the ntp change.

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: atomic changes break drm-next-kmod?

[Niclas Zeising]

On 07/06/18 00:02, Warner Losh wrote:



On Thu, Jul 5, 2018 at 1:44 PM, John Baldwin > wrote:


On 7/5/18 12:36 PM, Konstantin Belousov wrote:
 > On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky wrote:
 >> On 07/05/18 20:59, Hans Petter Selasky wrote:
 >>> On 07/05/18 19:48, Pete Wright wrote:
 
 
  On 07/05/2018 10:10, John Baldwin wrote:
 > On 7/3/18 5:10 PM, Pete Wright wrote:
 >>
 >> On 07/03/2018 15:56, John Baldwin wrote:
 >>> On 7/3/18 3:34 PM, Pete Wright wrote:
  On 07/03/2018 15:29, John Baldwin wrote:
 > That seems like kgdb is looking at the wrong CPU.  Can
you use
 > 'info threads' and look for threads not stopped in
'sched_switch'
 > and get their backtraces?  You could also just do 'thread
apply
 > all bt' and put that file at a URL if that is easiest.
 >
  sure thing John - here's a gist of "thread apply all bt"
 
 
https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed

 >>> That doesn't look right at all.  Are you sure the kernel
matches the
 >>> vmcore?  Also, which kgdb version are you using?
 >>>
 >> yea i agree that doesn't look right at all.  here is my setup:
 >>
 >> $ which kgdb
 >> /usr/bin/kgdb
 >> $ kgdb
 >> GNU gdb 6.1.1 [FreeBSD]
 >> $ ls -lh /var/crash/vmcore.1
 >> -rw---  1 root  wheel   1.6G Jul  3 15:03
/var/crash/vmcore.1
 >> $ ls -l /usr/lib/debug/boot/kernel/kernel.debug
 >> -r-xr-xr-x  1 root  wheel  87840496 Jul  3 13:54
 >> /usr/lib/debug/boot/kernel/kernel.debug
 >>
 >> and i invoke kgdb like so:
 >> $ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug
/var/crash/vmcore.1
 >>
 >> here's a gist of my full gdb session:
 >> http://termbin.com/krsn
 >>
 >> dunno - maybe i have a bad core dump?  regardless, more than
happy to
 >> help so let me know if i should try anything else or patches
etc..
 > Can you try installing gdb from ports and using
/usr/local/bin/kgdb?
 >
 
  that seems to have done the trick, at least the output looks more
  encouraging.
 
    --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
  KDB: enter: panic
 
  __curthread () at ./machine/pcpu.h:231
  231        __asm("movq %%gs:%1,%0" : "=r" (td)
 
 
  here's my full kgdb session:
  http://termbin.com/qa4f
 
  i don't see any threads not in "sched_switch" though :(
 >>>
 >>> Hi,
 >>>
 >>> The problem may be that the patch to enable atomic inlining of all
 >>> macros forgot to set the SMP keyword which means SMP is not
defined at
 >>> all for KLD's so all non-kernel atomic usage is with MPLOCKED
empty!
 > Problem is that out-of-tree modules build does not have opt*.h files
 > from the kernel.  UP config is a valid one, flipping some option's
 > default value does not solve the problem.

Yes, but using the lock prefix in a generic module is ok (it will still
work, just not quite as fast) whereas the lack of lock is fatal on
SMP.  I would amend Hans' patch slightly to honor the opt_* setting
for KLD_TIED (but that is only true if KLD_TIED means "built as part of
a kernel build, so has valid opt_foo.h headers" and not
'a standalone module where someone put MODULES_TIED=1 on the command
line
to make').


I agree with this default. It's sensible to default to (a) the most 
popular thing and (b) thing that always works, especially when (a) and 
(b) are identical.


Don't make me start the "Do we really need an SMP option, why not make 
it always on" thread :) The number of relevant uniprocessor x86 boxes 
that benefit from omitting SMP is so small as to be irrelevant, IMHO. A 
MP kernel runs just fine on them...


Warner


Where are we on this?
It is important to get it fixed, it's already been 4 days, which means 4 
days of all modern FreeBSD desktop systems being broken, and possibly 
other systems with kernel modules from ports as well.



Another question, how hard would it be to expose how the kernel was 
built to modules built from ports, so that they can figure out stuff 
like SMP and others, that might affect the module build?


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: atomic changes break drm-next-kmod?

[Niclas Zeising]

On 07/03/18 17:02, O. Hartmann wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Tue, 3 Jul 2018 10:19:57 -0400
Michael Butler  schrieb:


It seems recent changes (SVN r335873?) may have broken drm-next-kmod ..

--- i915_drv.o ---
In file included from i915_drv.c:30:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/acpi.h:26:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/device.h:4:
In file included from
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35:
In file included from
/usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37:
In file included from /usr/src/sys/sys/systm.h:44:
./machine/atomic.h:450:29: error: invalid operand for instruction
ATOMIC_ASM(clear,long,  "andq %1,%0",  "ir", ~v);
 ^
:1:7: note: instantiated into assembly here
 andq $9223372036854775807,40672(%r14)
  ^
1 error generated.
*** [i915_drv.o] Error code 1

make[3]: stopped in
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915
--- i915_gem.o ---
In file included from i915_gem.c:28:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:38:
In file included from /usr/src/sys/sys/malloc.h:42:
In file included from /usr/src/sys/sys/systm.h:44:
./machine/atomic.h:449:29: error: invalid operand for instruction
ATOMIC_ASM(set,  long,  "orq %1,%0",   "ir",  v);
 ^
:1:6: note: instantiated into assembly here
 orq $-9223372036854775808,40672(%r14)
 ^~
1 error generated.
*** [i915_gem.o] Error code 1

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



It breaks also graphics/drm-stable-kmod (see PR 229484,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, same error as you 
described
above) and also emulators/virtualbox-ose-kmod. As long as CURRENT revision is < 
r335873,
those kmod compile well.


We are looking into why both the drm ports fail.
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: How to run drm-next-kmod on r334511

[Niclas Zeising]

On 06/02/18 09:56, Masachika ISHIZUKA wrote:

   When I updated to r334511, drm-next-kmod is not working with
the message '[drm:fw_domain_wait_ack] render: timed out waiting
for forcewake ack request.'.
   drm-next-kmod was working fine on r333704.
   My CPU is pentium G4560(kaby lake).


We are working on a fix now.
Sorry for any trouble caused.


   Thank you for reply, Johannes

   Since it works well in 11.2-RC1, it is not in a hurry, but I am
looking forward to being fixed.



This should be fixed as of ports r471368.
https://svnweb.freebsd.org/ports?view=revision=471368
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: [RFC] Deprecation and removal of the drm2 driver

[Niclas Zeising]

On 05/31/18 16:21, Rodney W. Grimes wrote:


I do remeber for a long time this
was a -current only modules, is that still true, or can I
load it on 11.0, 11.1 and 11.2Beta3 now?


drm-stable-kmod works on 11.2 (including the betas) and later.  We can't 
backport the needed changes to the lkpi to the releases, for obvious 
reasons, but they were backported some time between 11.1 and now.

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: [RFC] Deprecation and removal of the drm2 driver

[Niclas Zeising]

On 05/18/18 19:58, Niclas Zeising wrote:
[ Cross posted to freebsd-current@ and freebsd-x11@.  Please respect 
reply-to and send all replies to freebsd-x11@.  Thanks! ]



Hi!
I propose that we remove the old drm2 driver (sys/dev/drm2) from 
FreeBSD.  I suggest the driver is marked as deprecated in 11.x and 
removed from 12.0, as was done for other drivers recently.  Some 
background and rationale:


The drm2 driver was the original port of a KMS driver to FreeBSD.  It 
was done by Konstantin Belousov to support Intel graphics cards, and 
later extended by Jean-Sébastien Pédron as well as Konstantin to match 
what's in Linux 3.8.  This included unstable support from Haswell, but 
nothing newer than that.


For quite some time now we have had the graphics/drm-stable-kmod and 
graphics/drm-next-kmods which provides support for modern AMD and Intel 
graphics cards.  These ports, together with the linuxkpi, or lkpi, has 
made it significantly easier to port and update our graphics drivers. 
Further, these new drivers cover the same drivers as the old drm2 driver.


What does the community think?  Is there anyone still using the drm2 
driver on 12-CURRENT?  If so, what is preventing you from switching to 
the port?





Wow, this blew up quite a lot bigger than I anticipated.  I'll try to 
summarize the discussion a bit below and then suggest a way forward.


The primary reasons we want to do this is because there are conflicts 
between the new drm drivers in ports, and the drm drivers in base, since 
they control the same hardware.  It is hard to make conflicting drivers 
to auto load in a consistent way.  In order to improve the desktop 
experience I'd like to see that graphics drivers are loaded on system 
boot.  There is also a push from upstream to have the xf86-video* 
drivers stop loading driver kernel modules.  It is also easier to keep a 
port updated than keeping the base system updated, and updates can 
propagate to multiple FreeBSD versions at once.  This will also ensure 
that all ports use the same firmware blobs.


So, to the summary.  A lot of people are using i386, and as such still 
need the old drm drivers.  There were also some reports about issues 
with the drm-next/stable drivers, which needs investigating. Power is 
another architecture that also is not supported by drm-next/stable, 
although we hope to extend support to powerpc in the future. There was a 
lot of discussion regarding making it into a port, or only excluding the 
driver on amd64, and similar suggestions.


To move forward, we'll do the following:  Note that this is for current 
only.
We take the drm and drm2 drivers and make a port for it, maintained by 
the graphics team (x11@).  After a transition period, then the drivers 
are removed from base.  At the same time, pkg-messages are added to 
relevant places to point people to the various available drm drivers.


Regards
--
Niclas Zeising
FreeBSD graphics/x11 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: [RFC] Deprecation and removal of the drm2 driver

[Niclas Zeising]

On 05/22/18 13:47, dpolyg wrote:

I have one comment regarding usage of the drm2 on a "legacy" hardware.
Excuse me in advance if I misunderstand something.
For the last 2-3 years I'm playing with devices such as small form 
factor PCs from Shuttle:

http://global.shuttle.com/products/productsList?categoryId=69
or from Gigabyte:
https://www.gigabyte.com/us/Mini-PcBarebone
or Intel "NUC"s.
To my experience drm-next doesn't work on lower price (Celeron/Atom) 
models. Do I missing something?

Here is concrete example:
I have a Shuttle DS47: 
http://global.shuttle.com/main/productsDetail?productId=1718

running FreeBSD 11.1-RELEASE and drm2.ko loaded + Xorg + compton.
Having that I made a box with a voice control and ability to make a SIP 
video call to it from a smartphone (WebRTC) (imagine "Amazon Show" 
powered by stock FeeBSD) but I never install any drm-next on it. Stock 
amd64 kernel used. No ports compiled. Only "pkg install ..." + custom 
code as the most front end.

After reading this thread I tried to compile drm-next on my DS47 box:

root@ShuttleD47:/usr/ports/graphics/drm-next-kmod # uname -a
FreeBSD ShuttleD47 11.1-RELEASE-p10 FreeBSD 11.1-RELEASE-p10 #0: Tue May 
  8 05:21:56 UTC 2018 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

root@ShuttleD47:/usr/ports/graphics/drm-next-kmod # make
===>  drm-next-kmod-4.11.g20180505_1 not supported on 10.x or older, no 
kernel

support.
*** Error code 1

Stop.
make: stopped in /usr/ports/graphics/drm-next-kmod

Why drm-next thinks it lives on a 10.x kernel or older?
Is such usage case already considered as legacy?
Is this hardware supported by drm-next?
https://www.amazon.com/Best-Sellers-Electronics-Mini-Computers/zgbs/electronics/13896591011 




That is most likely a typo, or at least not as good as it should be. 
drm-stable-kmod and drm-next-kmod are supported on CURRENT and will be 
supported on FreeBSD 11.2 (it's supported in stable right now).  Older 
releases will, however, not be supported.  But they still have drm2, I 
will not remove any drivers from releases or from STABLE.

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: [RFC] Deprecation and removal of the drm2 driver

[Niclas Zeising]

On 05/20/18 18:40, Steve Kargl wrote:

On Fri, May 18, 2018 at 02:03:32PM -0600, Warner Losh wrote:

On Fri, May 18, 2018 at 1:30 PM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:


On Fri, May 18, 2018 at 09:14:24PM +0200, Andreas Nilsson wrote:

On Fri, May 18, 2018, 20:00 Niclas Zeising <zeis...@freebsd.org> wrote:


I propose that we remove the old drm2 driver (sys/dev/drm2) from
FreeBSD.  I suggest the driver is marked as deprecated in 11.x and
removed from 12.0, as was done for other drivers recently.  Some
background and rationale:



Sounds good ( deprecate resp remove ). It causes more confusion and
problems and it solves nothing.



Check the Makefiles

% more /usr/ports/graphics/drm-next-kmod/Makefile

ONLY_FOR_ARCHS= amd64
ONLY_FOR_ARCHS_REASON=  the new KMS components are only supported on amd64

Not to ia32 friendly.



So do people use i386 for desktop? And need the latest KMS stuff?



Just a data point.  I had to replace the dead disk in my laptop,
and after 2 days of doing a re-install and update of -current
on a shiny new SSD.

Before loading Xorg.

% kldstat
Id Refs AddressSize Name
  17 0x80 1ac31d4  kernel
  21 0x1e9ae000 5000 ums.ko
  31 0x1e9b9000 4000 uhid.ko

After starting Xorg without an xorg.conf in /etc/X11.

Id Refs AddressSize Name
  1   27 0x80 1ac31d4  kernel
  21 0x1e9ae000 5000 ums.ko
  31 0x1e9b9000 4000 uhid.ko
  41 0x1eaa9000 96000i915kms.ko
  51 0x1eb4 4a000drm2.ko
  64 0x1eb8b000 5000 iicbus.ko
  71 0x1ebc9000 3000 iic.ko
  81 0x1ebcf000 4000 iicbb.ko

So, drm2.ko and i915kms.ko are loaded automatically.  It is
unclear why functionality that works should be removed.

xwininfo shows

   Width: 1400
   Height: 1050
   Depth: 24
   Visual: 0x21



One of the reasons for the deprecation and removal of the drm2 bits is 
that they prevent us from automatically loading the drm-next/stable-kmod 
kernel modules, since the two collide.

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"

[RFC] Deprecation and removal of the drm2 driver

[Niclas Zeising]

[ Cross posted to freebsd-current@ and freebsd-x11@.  Please respect 
reply-to and send all replies to freebsd-x11@.  Thanks! ]



Hi!
I propose that we remove the old drm2 driver (sys/dev/drm2) from 
FreeBSD.  I suggest the driver is marked as deprecated in 11.x and 
removed from 12.0, as was done for other drivers recently.  Some 
background and rationale:


The drm2 driver was the original port of a KMS driver to FreeBSD.  It 
was done by Konstantin Belousov to support Intel graphics cards, and 
later extended by Jean-Sébastien Pédron as well as Konstantin to match 
what's in Linux 3.8.  This included unstable support from Haswell, but 
nothing newer than that.


For quite some time now we have had the graphics/drm-stable-kmod and 
graphics/drm-next-kmods which provides support for modern AMD and Intel 
graphics cards.  These ports, together with the linuxkpi, or lkpi, has 
made it significantly easier to port and update our graphics drivers. 
Further, these new drivers cover the same drivers as the old drm2 driver.


What does the community think?  Is there anyone still using the drm2 
driver on 12-CURRENT?  If so, what is preventing you from switching to 
the port?


Thank you
Regards
--
Niclas Zeising
FreeBSD x11/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: suspend/resume regression

[Niclas Zeising]

On 05/15/18 16:48, Pete Wright wrote:



On 05/14/2018 20:35, Theron wrote:

On 05/13/18 15:44, Pete Wright wrote:
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?


-pete

Returning to the original issue: complete failure to resume, rather 
than slowness: I am affected as well.  CURRENT r333093 worked, but 
r333582 fails in a manner consistent with what Pete has described, 
with or without drm loaded.  There have been a few commit messages 
mentioning ACPI in that window of history, which I will use to help me 
bisect when I have time.




do you think it may be due to r333150

"Merge ACPICA 20180427."

not sure if that's been merged into 11-STABLE, but it seems to touch a 
lot of bits that could effect suspend/resume.




I tried to revert that, but if I remember correctly, it didn't matter. 
I have to do a new test though, when I have more time.

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/14/18 10:06, Edward Tomasz Napierała wrote:

On 0513T1244, 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?


FWIW, I'm seeing the same - sluggishness after resume - with stock
12-CURRENT, without drm-next, just vanilla i915kms.ko, on T420.

TBH I'm not entirely sure it's X11 problem - as I'm writing it now,
under vt(4), it seems somewhat slow too.



It's not impossible that there are two different regressions, one 
causing sluggishness and one causing graphics corruption, or that they 
are intertwined. I have a Kaby Lake system which I run these tests on. 
I also have a window where the regression seem to have happened. 
r333269 to r40, so once I have time I'll start bisecting.


Hopefully I can test on older systems as well.
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"

Re: suspend/resume regression

[Niclas Zeising]

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




On 13. May 2018, at 11:54, Niclas Zeising <zeising+free...@daemonic.se> 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 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 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: 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: 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: 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: 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"

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

[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: 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: 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: 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: 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