FreeBSD 11.0-RC1 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The first RC build of the 11.0-RELEASE release cycle is now available.

Installation images are available for:

o 11.0-RC1 amd64 GENERIC
o 11.0-RC1 i386 GENERIC
o 11.0-RC1 powerpc GENERIC
o 11.0-RC1 powerpc64 GENERIC64
o 11.0-RC1 sparc64 GENERIC
o 11.0-RC1 armv6 BANANAPI
o 11.0-RC1 armv6 BEAGLEBONE
o 11.0-RC1 armv6 CUBIEBOARD
o 11.0-RC1 armv6 CUBIEBOARD2
o 11.0-RC1 armv6 CUBOX-HUMMINGBOARD
o 11.0-RC1 armv6 GUMSTIX
o 11.0-RC1 armv6 RPI-B
o 11.0-RC1 armv6 RPI2
o 11.0-RC1 armv6 PANDABOARD
o 11.0-RC1 armv6 WANDBOARD
o 11.0-RC1 aarch64 GENERIC

Note regarding arm/armv6 images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access.  Additionally,
the root user password is set to root, which it is strongly
recommended to change the password for both users after gaining
access to the system.

Installer images and memory stick images are available here:

ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/11.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use SVN to do a source based update of an existing
system, use the "releng/11.0" branch.

A summary of changes since BETA4 includes:

o A NULL pointer dereference in IPSEC has been fixed.

o Support for SSH Protocol 1 has been removed.

o OpenSSH DSA keys have been disabled by default.  Users upgrading from
  prior FreeBSD versions are urged to update their SSH keys to DSA or
  ECDSA keys before upgrading to 11.0-RC1.

o PCI-e hotplug on bridges with power controllers has been disabled.

o A loader tunable (hw.pci.enable_pcie_hp) to disable PCI-e HotPlug has
  been added.

o A VESA panic on suspend has been fixed.

o Google Compute Engine image publication has been fixed.

o An AES-ICM heap corruption typo bug has been fixed.

o A regression in pf.conf while parsing the 'interval' keyword has been
  fixed.

o A ZFS/VFS deadlock has been fixed.

A list of changes since 10.0-RELEASE are available on the releng/11.0
release notes:

https://www.freebsd.org/releases/11.0R/relnotes.html

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 11.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64 and i386 architectures.
Disk images may be downloaded from the following URL (or any of the
FreeBSD FTP mirrors):

ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/11.0-RC1/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

 us-east-1 region: ami-1f128b08
 us-west-1 region: ami-73baf913
 us-west-2 region: ami-9062a9f0
 sa-east-1 region: ami-daaf39b6
 eu-west-1 region: ami-424d2731
 eu-central-1 region: ami-ca7284a5
 ap-northeast-1 region: ami-3ae6255b
 ap-northeast-2 region: ami-dc5c96b2
 ap-southeast-1 region: ami-0f875e6c
 ap-southeast-2 region: ami-c3d6e2a0

=== Vagrant Images ===

FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can
be installed by running:

% vagrant init freebsd/FreeBSD-11.0-RC1
% vagrant up

=== Upgrading ===

The freebsd-update(8) utility supports binary upgrades of amd64 and i386
systems running earlier FreeBSD releases.  Systems running earlier
FreeBSD releases can upgrade as follows:

# freebsd-update upgrade -r 11.0-RC1

During this process, freebsd-update(8) may ask the user to help by
merging some configuration files or by confirming that the automatically
performed merging was done correctly.

# freebsd-update install

The system must be rebooted with the newly installed kernel before
continuing.

# shutdown -r now

After rebooting, freebsd-update needs to be run again to install the new
userland 

Re: Wayland work status

[Lundberg, Johannes]

Hi

I followed the instructions for evdev enabled kernel here
https://github.com/wulf7/libudev-devd and it works fine!
I needed to update libinput to latest version since it was required by
xf86-input-libinput so I'm using latest version from
https://github.com/jiixyj/libinput.

As for the wsp driver I've simply added REL_HWHEEL to get x/y scrolling and
changed the back/forward events to x axis scrolling. See the attached
patch.  It's still really simple but adds a bit more functionality compared
to what is allowed by the old mouse protocol. Of course, if you want
advanced multi-touch gestures, it's need to be rewritten a lot. Although, I
don't know how many X apps actually support this so maybe it's a lot of
work for nothing...

I also needed to change the order of horizontal scroll wheel and buttons
with
xinput set-button-map 6  3 2 1 4 5 7 6 ​

​I think wsp already puts out vertical scroll in opposite direction by
default. ​

​I'm using xfce4 as desktop environment.​


On Fri, Aug 12, 2016 at 1:12 PM, Jan Kokemüller 
wrote:

> Hi,
>
> On 12.08.16 19:22, Lundberg, Johannes wrote:
>
>> ​Where can I find xf86-input-libinput for FreeBSD? Will the original
>> source build?
>>
>
> Yes, the original source (https://cgit.freedesktop.org/
> xorg/driver/xf86-input-libinput/) will build unmodified.
>
> I've copied libinput_drv.so to 
> /usr/local/lib/xorg/modules/input/libinput_drv.so
> and installed "99-libinput.conf" into /usr/local/etc/X11/xorg.conf.d so
> that X will use libinput for the /dev/input/event* devices by default and
> not xf86-input-evdev or -synaptics.
>
> Libinput has pretty advanced multitouch scrolling and gesture support that
> relies on evdev multitouch packets (https://www.kernel.org/doc/Do
> cumentation/input/multi-touch-protocol.txt). Are you already sending
> these packets, or are you sending relative (EV_REL) packets? Looking at the
> wmt driver in the wulf7/evdev branch sending EV_ABS packets does not seem
> too hard for USB based touchpads.
>
> It is probably easiest to boot Linux, dump all evdev packets from the
> touchpad with the libevdev-events tool from libevdev, and then try to
> emulate that output with the wsp driver.
>
> For testing smooth scrolling, gtk3-demo is pretty good; or recent versions
> of Firefox with the MOZ_USE_XINPUT2 environment variable set to 1.
>
> -Jan
>

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
diff --git a/sys/dev/usb/input/wsp.c b/sys/dev/usb/input/wsp.c
index 694e0d9..21cc518 100644
--- a/sys/dev/usb/input/wsp.c
+++ b/sys/dev/usb/input/wsp.c
@@ -27,6 +27,8 @@
 #include 
 __FBSDID("$FreeBSD$");
 
+#include "opt_evdev.h"
+
 #include 
 #include 
 #include 
@@ -54,6 +56,11 @@ __FBSDID("$FreeBSD$");
 
 #include 
 
+#ifdef EVDEV
+#include 
+#include 
+#endif
+
 #defineWSP_DRIVER_NAME "wsp"
 #defineWSP_BUFFER_MAX  1024
 
@@ -83,6 +90,7 @@ SYSCTL_INT(_hw_usb_wsp, OID_AUTO, debug, CTLFLAG_RWTUN,
 static struct wsp_tuning {
int scale_factor;
int z_factor;
+   int t_factor;
int pressure_touch_threshold;
int pressure_untouch_threshold;
int pressure_tap_threshold;
@@ -92,6 +100,7 @@ static struct wsp_tuning {
 {
.scale_factor = 12,
.z_factor = 5,
+   .t_factor = 5,
.pressure_touch_threshold = 50,
.pressure_untouch_threshold = 10,
.pressure_tap_threshold = 120,
@@ -113,6 +122,8 @@ SYSCTL_INT(_hw_usb_wsp, OID_AUTO, scale_factor, 
CTLFLAG_RWTUN,
 _tuning.scale_factor, 0, "movement scale factor");
 SYSCTL_INT(_hw_usb_wsp, OID_AUTO, z_factor, CTLFLAG_RWTUN,
 _tuning.z_factor, 0, "Z-axis scale factor");
+SYSCTL_INT(_hw_usb_wsp, OID_AUTO, t_factor, CTLFLAG_RWTUN,
+_tuning.t_factor, 0, "T-axis scale factor");
 SYSCTL_INT(_hw_usb_wsp, OID_AUTO, pressure_touch_threshold, CTLFLAG_RWTUN,
 _tuning.pressure_touch_threshold, 0, "touch pressure threshold");
 SYSCTL_INT(_hw_usb_wsp, OID_AUTO, pressure_untouch_threshold, CTLFLAG_RWTUN,
@@ -541,7 +552,12 @@ struct wsp_softc {
u_int   sc_pollrate;
mousestatus_t sc_status;
u_int   sc_state;
+   u_int   sc_fflags;
 #defineWSP_ENABLED0x01
+#ifdef EVDEV
+   int sc_evflags;
+#defineWSP_EVDEV_OPENED1
+#endif
 
struct tp_finger *index[MAX_FINGERS];   /* finger index data */
int16_t pos_x[MAX_FINGERS]; /* position array */
@@ -559,9 +575,12 @@ struct wsp_softc {
int 

Re: Wayland work status

[Jan Kokemüller]

Hi,

On 12.08.16 19:22, Lundberg, Johannes wrote:

​Where can I find xf86-input-libinput for FreeBSD? Will the original
source build?


Yes, the original source 
(https://cgit.freedesktop.org/xorg/driver/xf86-input-libinput/) will 
build unmodified.


I've copied libinput_drv.so to 
/usr/local/lib/xorg/modules/input/libinput_drv.so and installed 
"99-libinput.conf" into /usr/local/etc/X11/xorg.conf.d so that X will 
use libinput for the /dev/input/event* devices by default and not 
xf86-input-evdev or -synaptics.


Libinput has pretty advanced multitouch scrolling and gesture support 
that relies on evdev multitouch packets 
(https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt). 
Are you already sending these packets, or are you sending relative 
(EV_REL) packets? Looking at the wmt driver in the wulf7/evdev branch 
sending EV_ABS packets does not seem too hard for USB based touchpads.


It is probably easiest to boot Linux, dump all evdev packets from the 
touchpad with the libevdev-events tool from libevdev, and then try to 
emulate that output with the wsp driver.


For testing smooth scrolling, gtk3-demo is pretty good; or recent 
versions of Firefox with the MOZ_USE_XINPUT2 environment variable set to 1.


-Jan
___
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: Wayland work status

[Lundberg, Johannes]

>
> If you feel adventurous, you can try out the current state of the libinput
> port here (1.4.0):
> https://github.com/jiixyj/libinput
>
>
​Great! Will check it out.
​


> I haven't yet tested the port with the evdev kernel work, though. I've
> been using my evdev implementation in userspace which uses cuse to create
> /dev/input/event* devices (https://github.com/jiixyj/evdevfbsd). I needed
> to adjust a few ioctl defines from the linux/input.h header to make some
> features work. The way Linux defines EVIOCGMTSLOTS and EVIOCGRAB didn't
> work with cuse. The kernel evdev implementation may work slightly
> differently, so that's something to look out for.
>
>
​Kernel evdev implementation seems to work great. It is fairly easy to add
evdev functionality to existing drivers. I just patched the wsp (for
Macbook's touchpad) driver to add it to evdev. I modified it a bit to add
two finger x-y scroll like on macOS. I can't wait to try it on X so I'm
gonna try get libinput working with X today.
​


> I've moved the udev-stubs.{c,h} out of the port into a separate library,
> but libudev-devd (https://github.com/wulf7/libudev-devd) certainly looks
> more mature!
>
>
​I couldn't get it working with your udev-stubs and I found libudev-devd
which seemed to be more mature. It works great so far!​


> All this can be used with the xf86-input-libinput driver to get smooth and
> horizontal scrolling in X, which is awesome!
>

​Where can I find xf86-input-libinput for FreeBSD? Will the original source
build?

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
___
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: Wayland work status

[Lundberg, Johannes]

> There is a similar problem for the drm devices (by default, users can’t
> use 3D acceleration).  A devfs.conf policy can change the permissions.  I’d
> suggest that we create a default group called something like console or
> local, put new users there by default, and make drm and evdev devices
> accessible by this group.
>
> David
>
>

​Actually in Linux wlc and I think also Weston recommend using setuid for
the compositor. It then forks and drops permission. All devices are opened
as superuser and then sent to the child process. This works fine for me
with tty and drm, however, libinput complains about devices not being
tagged as input device but they are opened successfully. I haven't looked
deeper into why...

As for X11, maybe this approach does not work and we need group permissions.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
---
CONFIDENTIALITY NOTE: The information in this email is confidential
and intended solely for the addressee.
Disclosure, copying, distribution or any other action of use of this
email by person other than intended recipient, is prohibited.
If you are not the intended recipient and have received this email in
error, please destroy the original message.
___
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: PORTS_MODULES breakage on HEAD

[Don Lewis]

On 12 Aug, Bryan Drewery wrote:
> On 8/10/2016 4:20 PM, Bryan Drewery wrote:
>> On 8/7/16 5:44 PM, Don Lewis wrote:
>>> Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on
>>> HEAD.  When I do that I get this failure:
>>>
>>> ===> Ports module emulators/virtualbox-ose-kmod (all)
>>> cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; 
>>> PATH=/usr/obj/usr/src/
>>> tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/leg
>>> acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/u
>>> sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin  SRC_BASE=/usr/src  
>>> OSVERSION=12
>>> 0  WRKDIRPREFIX=/usr/obj/usr/src/sys/ make -B clean all
>>> ===>  Cleaning for virtualbox-ose-kmod-5.0.26_1
>>> ===>  License GPLv2 accepted by the user
>>> ===>  Found saved configuration for virtualbox-ose-kmod-4.3.34
>>> ===>   virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/sbin/pkg - 
>>> found
>>> ===> Fetching all distfiles required by virtualbox-ose-kmod-5.0.26_1 for 
>>> buildin
>>> g
>>> ===>  Extracting for virtualbox-ose-kmod-5.0.26_1
>>> => SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2.
>>> ===>  Patching for virtualbox-ose-kmod-5.0.26_1
>>> ===>  Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1
>>> ===>   virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - found
>>> ===>  Configuring for virtualbox-ose-kmod-5.0.26_1
>>> Checking for environment: Determined build machine: freebsd.amd64, target 
>>> machin
>>> e: freebsd.amd64, OK.
>>> Checking for kBuild: found, OK.
>>> Checking for gcc:
>>>   ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not 
>>> found!
>>> Check 
>>> /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualB
>>> ox-5.0.26/configure.log for details
>>> ===>  Script "configure" failed unexpectedly.
>>> Please report the problem to v...@freebsd.org [maintainer] and attach the
>>> "/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5
>>> .0.26/config.log"
>>>
>>>
>>> It appears that the problem is due to CC being set to:
>>> cc -target x86_64-unknown-freebsd12.0 --sysroot
>>> and the Makefile for the port passes this:
>>> --with-gcc="${CC}"
>>> to configure.  The configure script passes $CC to check_avail, which
>>> does a -z test on it.
>>>
>>> I think that CC should just be set to "cc" and the rest should get added
>>> to CFLAGS.  I suspect this got broken by the recent crossbuild changes.
>>>
>> 
>> 
>> It's a SYSTEM_COMPILER bug.  I'll look into fixing it.
>> 
>> For now you can try passing WITHOUT_SYSTEM_COMPILER=yes as a workaround.
>> 
>> 
> 
> I've committed a fix to head in r304005. I will MFC it to stable/11 in
> about a week.

Thanks!

___
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: Wayland work status

[Jan Kokemüller]

Hi,

On 12.08.16 01:18, Lundberg, Johannes wrote:

x11/libinput (removed udev-stubs and linked to libudev-devd)


If you feel adventurous, you can try out the current state of the 
libinput port here (1.4.0):

https://github.com/jiixyj/libinput

I haven't yet tested the port with the evdev kernel work, though. I've 
been using my evdev implementation in userspace which uses cuse to 
create /dev/input/event* devices (https://github.com/jiixyj/evdevfbsd). 
I needed to adjust a few ioctl defines from the linux/input.h header to 
make some features work. The way Linux defines EVIOCGMTSLOTS and 
EVIOCGRAB didn't work with cuse. The kernel evdev implementation may 
work slightly differently, so that's something to look out for.


I've moved the udev-stubs.{c,h} out of the port into a separate library, 
but libudev-devd (https://github.com/wulf7/libudev-devd) certainly looks 
more mature!


The libinput code itself isn't that different from upstream anymore. 
I've removed the epoll->kqueue porting work and written a small epoll 
wrapper instead that implements everything libinput/libevdev and 
possibly wayland needs (https://github.com/jiixyj/epoll-shim). This 
isn't integrated yet into the build system of the libinput port, though. 
So you have to do something like 'CFLAGS="-I ~/git/epoll-shim/include -L 
~/git/epoll-shim -lepoll-shim -pthread" LDFLAGS="-pthread -lrt"' when 
configuring libinput.


All this can be used with the xf86-input-libinput driver to get smooth 
and horizontal scrolling in X, which is awesome!


--
Jan
___
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: PORTS_MODULES breakage on HEAD

[Bryan Drewery]

On 8/10/2016 4:20 PM, Bryan Drewery wrote:
> On 8/7/16 5:44 PM, Don Lewis wrote:
>> Adding PORTS_MODULES=emulators/virtualbox-ose-kmod recently broke on
>> HEAD.  When I do that I get this failure:
>>
>> ===> Ports module emulators/virtualbox-ose-kmod (all)
>> cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; 
>> PATH=/usr/obj/usr/src/
>> tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/leg
>> acy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/u
>> sr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin  SRC_BASE=/usr/src  
>> OSVERSION=12
>> 0  WRKDIRPREFIX=/usr/obj/usr/src/sys/ make -B clean all
>> ===>  Cleaning for virtualbox-ose-kmod-5.0.26_1
>> ===>  License GPLv2 accepted by the user
>> ===>  Found saved configuration for virtualbox-ose-kmod-4.3.34
>> ===>   virtualbox-ose-kmod-5.0.26_1 depends on file: /usr/local/sbin/pkg - 
>> found
>> ===> Fetching all distfiles required by virtualbox-ose-kmod-5.0.26_1 for 
>> buildin
>> g
>> ===>  Extracting for virtualbox-ose-kmod-5.0.26_1
>> => SHA256 Checksum OK for VirtualBox-5.0.26.tar.bz2.
>> ===>  Patching for virtualbox-ose-kmod-5.0.26_1
>> ===>  Applying FreeBSD patches for virtualbox-ose-kmod-5.0.26_1
>> ===>   virtualbox-ose-kmod-5.0.26_1 depends on executable: kmk - found
>> ===>  Configuring for virtualbox-ose-kmod-5.0.26_1
>> Checking for environment: Determined build machine: freebsd.amd64, target 
>> machin
>> e: freebsd.amd64, OK.
>> Checking for kBuild: found, OK.
>> Checking for gcc:
>>   ** cc -target x86_64-unknown-freebsd12.0 --sysroot (variable CC) not found!
>> Check 
>> /usr/obj/usr/src/sys/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualB
>> ox-5.0.26/configure.log for details
>> ===>  Script "configure" failed unexpectedly.
>> Please report the problem to v...@freebsd.org [maintainer] and attach the
>> "/usr/obj/usr/src/sys//usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5
>> .0.26/config.log"
>>
>>
>> It appears that the problem is due to CC being set to:
>>  cc -target x86_64-unknown-freebsd12.0 --sysroot
>> and the Makefile for the port passes this:
>>  --with-gcc="${CC}"
>> to configure.  The configure script passes $CC to check_avail, which
>> does a -z test on it.
>>
>> I think that CC should just be set to "cc" and the rest should get added
>> to CFLAGS.  I suspect this got broken by the recent crossbuild changes.
>>
> 
> 
> It's a SYSTEM_COMPILER bug.  I'll look into fixing it.
> 
> For now you can try passing WITHOUT_SYSTEM_COMPILER=yes as a workaround.
> 
> 

I've committed a fix to head in r304005. I will MFC it to stable/11 in
about a week.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Wayland work status

[David Chisnall]

On 12 Aug 2016, at 00:18, Lundberg, Johannes  
wrote:
> 
> Currently by default evdev create /dev/input/eventX devices with 600
> permission. These need to be accessible for non-root users. What is the
> best solution? Should we create a "input" group similar to "video" group is
> being used for rights to access /dev/drm devices?

There is a similar problem for the drm devices (by default, users can’t use 3D 
acceleration).  A devfs.conf policy can change the permissions.  I’d suggest 
that we create a default group called something like console or local, put new 
users there by default, and make drm and evdev devices accessible by this group.

David



smime.p7s
Description: S/MIME cryptographic signature

drm-4.7-rc1 tagged

[Matthew Macy]

A few days ago I branched drm-next-4.6 in to drm-next and synced it with 
Torvalds' tree as of the v4.6 tag. I then integrated the ~800 commits to drm / 
i915 / radeon / amdgpu , testing periodically along the way and updating the 
linuxkpi as needed. I've just tagged the drm-next branch with drm-4.7-rc1 to 
indicate that it is in sync with 4.7-rc1 upstream. 

If any of you are feeling adventurous I would appreciate it if you would try it 
and report any regressions with respect to drm-next-4.6. I'm aware that there 
are a number of issues with drm-next-4.6 so I'm only really interested in _new_ 
issues. 

If you're feeling really adventurous - run the piglit test suite from the 
ports' xserver-next branch and do a root cause analysis on test failures.  

As always the repo is at:
https://github.com/FreeBSDDesktop/freebsd-base-graphics

Look through the existing open issues before filing a report and check the wiki 
first to address any problems.

Cheers.

-M

___
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: kernel panic caused by virtualbox(?)

[Konstantin Belousov]

On Thu, Aug 11, 2016 at 03:22:44PM -0700, Don Lewis wrote:
> On 11 Aug, Konstantin Belousov wrote:
> > On Wed, Aug 10, 2016 at 04:47:15PM -0700, Don Lewis wrote:
> >> On 10 Aug, Jung-uk Kim wrote:
> >> > On 08/09/16 05:12 AM, Konstantin Belousov wrote:
> >> >> On Mon, Aug 08, 2016 at 04:44:20PM -0700, Don Lewis wrote:
> >> >>> On  8 Aug, Konstantin Belousov wrote:
> >>  On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote:
> >> > On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote:
> >> >> Reposted to -current to get some more eyes on this ...
> >> >>
> >> >> I just got a kernel panic when I started up a CentOS 7 VM in 
> >> >> virtualbox.
> >> >> The host is:
> >> >> FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64
> >> >> The virtualbox version is:
> >> >> virtualbox-ose-5.0.26
> >> >> virtualbox-ose-kmod-5.0.26_1
> >> >>
> >> >> The panic message is:
> >> >>
> >> >> panic: Unregistered use of FPU in kernel
> >> >> cpuid = 1
> >> >> KDB: stack backtrace:
> >> >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
> >> >> 0xfe085a55d030
> >> >> vpanic() at vpanic+0x182/frame 0xfe085a55d0b0
> >> >> kassert_panic() at kassert_panic+0x126/frame 0xfe085a55d120
> >> >> trap() at trap+0x7ae/frame 0xfe085a55d330
> >> >> calltrap() at calltrap+0x8/frame 0xfe085a55d330
> >> >> --- trap 0x16, rip = 0x827dd3a9, rsp = 0xfe085a55d408, 
> >> >> rbp = 0xfe085a55d430 ---
> >> >> g_pLogger() at 0x827dd3a9/frame 0xfe085a55d430
> >> >> g_pLogger() at 0x8274e5c7/frame 0x3
> >> >> KDB: enter: panic
> >> >>
> >> >> Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox 
> >> >> is
> >> >> the trigger.
> >> >>
> >> >> There are no symbols for the virtualbox kmods, possibly because I
> >> >> installed them as an upgrade using packages (built with the same 
> >> >> source
> >> >> tree version) instead of by using PORTS_MODULES in make.conf, so 
> >> >> ports
> >> >> kgdb didn't have anything useful to say about what happened before 
> >> >> the
> >> >> trap.
> >> >>
> >> >> This panic is very repeatable.  I just got another one when 
> >> >> starting the
> >> >> same VM., but this time the two calls before the trap were
> >> >> null_bug_bypass().  Hmn, that symbol is in nullfs ...
> >> >>
> >> >> I don't see this with a Windows 7 VM.
> >> >>
> >> >> All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse
> >> >> -msoft-float -mno-aes -mno-avx
> >>  Your disassemble listed fxrstor instruction that failing, or did I
> >>  mis-remembered ? This is most likely some context switch code, either
> >>  by virtual machine or erronously executed guest code. It is not a
> >>  spontaneous use of FPU, but more likely something different. Can you
> >>  confirm ?
> >> 
> >>  In either case, I do not remember any KBI changes around PCB layout or
> >>  fpu_enter() KPI recently.
> >> 
> >> >
> >> > I suspect head packages are quite likely built against the a "wrong" 
> >> > KBI
> >> > and are too fragile to use for kmods vs compiling from ports. :-/  I 
> >> > would
> >> > try a built-from-ports kmod to see if the panics go away.
> >> 
> >>  FWIW, I will commit the following change shortly. Since third-party
> >>  modules break the invariant, either due to bugs (ndis wrappers) or
> >>  possibly due to KBI breakage, it is worth to have the detection 
> >>  enabled
> >>  for production kernels.
> >> >>>
> >> >>> Interesting ... I tried running virtualbox on recent 10.3-STABLE with a
> >> >>> GENERIC kernel and the guest seemed to operate properly.  Then I 
> >> >>> enabled
> >> >>> INVARIANTS and got the panic.  I suspect that is why nobody has 
> >> >>> stumbled
> >> >>> across this before.
> >> >>>
> >> >> This is yet another reason to promote KASSERT to the full panic.
> >> >> I expect that the vbox source lacks fpu_kern_enter() calls around the
> >> >> FPU state restoration.
> >> > 
> >> > Unfortunately, the code is in MI source as it is unnecessary for
> >> > supported OSes (read: FreeBSD is not supported) and it's not easy to
> >> > inject fpu_kern_enter()/fpu_kern_leave() calls there. :-(
> >> 
> >> It's a headache, but our ports can use patch files for that sort of
> >> thing ...
> > 
> > Note that it is, most likely, completely useless to wrap single
> > FXRSTOR instruction into the fpu_kern_enter() braces.  The purpose of
> > the instruction is to load ('legacy', as they call it, no AVX+) FPU state
> > into the machine context.  If you put fpu_kern_leave() right after
> > the instruction, the context is flushed.
> 
> Since it looks like the code is preparing to re-enter the guest, then
> calling fpu_kern_leave() doesn't make sense.
> 
> > There