Installers for FreeBSD fail to boot HP ProBook 440 G7: discrete graphics

[Graham Perrin]

On 04/12/2020 00:34, Waitman Gobble wrote:

On 2020-12-03 20:25, Graham Perrin wrote:

Where installers for FreeBSD 12.2 and 13.0-CURRENT fail to boot, the
installer for OmniOS community edition succeeds.


Photographs and other details at
; 


"I'm advised that it's symptomatic of the kernel not loading.". …


Something to check out?
That machine has Intel and NVidia gpu, you should check the BIOS 
settings. I have a Lenovo laptop that won't boot if it's set in BIOS 
to 'detect/auto', I think it's called Optimus? But my Dell that also 
has both boots fine although there's no selectable option in BIOS.




Thanks, the BIOS on this machine allows me to set an amount of video 
memory, and so on, but I see nothing relating to the discrete GPU.



(I see HP support articles on how to disable discrete graphics on some 
other models, but not the ProBook 440 G7.)

___
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: Installers for FreeBSD fail to boot HP ProBook 440 G7

[Waitman Gobble]

On 2020-12-03 20:25, Graham Perrin wrote:

Where installers for FreeBSD 12.2 and 13.0-CURRENT fail to boot, the
installer for OmniOS community edition succeeds.


Photographs and other details at
;
"I'm advised that it's symptomatic of the kernel not loading.".

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


Something to check out?
That machine has Intel and NVidia gpu, you should check the BIOS 
settings. I have a Lenovo laptop that won't boot if it's set in BIOS to 
'detect/auto', I think it's called Optimus? But my Dell that also has 
both boots fine although there's no selectable option in BIOS.


--
Waitman Gobble
___
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: port build fails with missing sys/smr_types.h

[Mark Johnston]

On Thu, Dec 03, 2020 at 03:42:40PM -0800, Chuck Tuffli wrote:
> On Thu, Dec 3, 2020 at 3:18 PM Mark Johnston  wrote:
> >
> > On Thu, Dec 03, 2020 at 01:08:52PM -0800, Chuck Tuffli wrote:
> > > Hi
> > >
> > > I'm trying to fix the build of qemu-utils but am seeing failures on
> > > CURRENT (13.0-HEAD-9e082d278b9) like:
> > >
> > > In file included from util/oslib-posix.c:50:
> > > In file included from /usr/include/sys/user.h:51:
> > > In file included from /usr/include/sys/proc.h:50:
> > > /usr/include/sys/filedesc.h:47:10: fatal error: 'sys/smr_types.h' file 
> > > not found
> > > #include 
> > >  ^
> > >
> > > # uname -a
> > > FreeBSD sv0.tuffli.net 13.0-HEAD-9e082d278b9 FreeBSD
> > > 13.0-HEAD-9e082d278b9 #0 9e082d278b91-c254726(HEAD)-dirty: Fri Nov 27
> > > 00:09:50 PST 2020
> > > root@freebsd:/build/9e082d278b9/obj/build/9e082d278b9/src/amd64.amd64/sys/GENERIC-NODEBUG
> > >  amd64
> > > # ls -l /usr/include/sys/*smr*
> > > -r--r--r--  1 root  wheel  1988 Nov 30 14:04 /usr/include/sys/_smr.h
> > > -r--r--r--  1 root  wheel  7822 Nov 30 14:04 /usr/include/sys/smr.h
> > >
> > > So it appears the file is missing. Any ideas?
> >
> > How old is your world?  I have /usr/include/sys/smr_types.h on my
> > systems.  It's present on freefall as well.
> 
> It is the FreeBSD-13.0-CURRENT-amd64-20201126-9e082d278b9 snapshot. If
> this is fixed in recent snapshots, I can move to one of those.

$ fetch 
http://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/13.0-CURRENT/amd64/20201126/FreeBSD-13.0-CURRENT-amd64-20201126-9e082d278b9.raw.xz
$ unxz FreeBSD-13.0-CURRENT-amd64-20201126-9e082d278b9.raw.xz
$ sudo mdconfig -a -f FreeBSD-13.0-CURRENT-amd64-20201126-9e082d278b9.raw
md0
$ sudo mount /dev/md0p4 /mnt
$ stat /mnt/usr/include/sys/smr_types.h
544 241404 -r--r--r-- 1 root wheel 554933 4985 "Nov 26 03:57:51 2020" "Nov 26 
03:51:14 2020" "Nov 26 03:58:26 2020" "Nov 26 03:51:14 2020" 32768 16 0 
/mnt/usr/include/sys/smr_types.h
$

So I'm not sure what's going on in your case.  smr_types.h was added a
number of months ago.
___
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"

Installers for FreeBSD fail to boot HP ProBook 440 G7

[Graham Perrin]

Where installers for FreeBSD 12.2 and 13.0-CURRENT fail to boot, the 
installer for OmniOS community edition succeeds.



Photographs and other details at 
; 
"I'm advised that it's symptomatic of the kernel not loading.".


___
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: port build fails with missing sys/smr_types.h

[Chuck Tuffli]

On Thu, Dec 3, 2020 at 3:18 PM Mark Johnston  wrote:
>
> On Thu, Dec 03, 2020 at 01:08:52PM -0800, Chuck Tuffli wrote:
> > Hi
> >
> > I'm trying to fix the build of qemu-utils but am seeing failures on
> > CURRENT (13.0-HEAD-9e082d278b9) like:
> >
> > In file included from util/oslib-posix.c:50:
> > In file included from /usr/include/sys/user.h:51:
> > In file included from /usr/include/sys/proc.h:50:
> > /usr/include/sys/filedesc.h:47:10: fatal error: 'sys/smr_types.h' file not 
> > found
> > #include 
> >  ^
> >
> > # uname -a
> > FreeBSD sv0.tuffli.net 13.0-HEAD-9e082d278b9 FreeBSD
> > 13.0-HEAD-9e082d278b9 #0 9e082d278b91-c254726(HEAD)-dirty: Fri Nov 27
> > 00:09:50 PST 2020
> > root@freebsd:/build/9e082d278b9/obj/build/9e082d278b9/src/amd64.amd64/sys/GENERIC-NODEBUG
> >  amd64
> > # ls -l /usr/include/sys/*smr*
> > -r--r--r--  1 root  wheel  1988 Nov 30 14:04 /usr/include/sys/_smr.h
> > -r--r--r--  1 root  wheel  7822 Nov 30 14:04 /usr/include/sys/smr.h
> >
> > So it appears the file is missing. Any ideas?
>
> How old is your world?  I have /usr/include/sys/smr_types.h on my
> systems.  It's present on freefall as well.

It is the FreeBSD-13.0-CURRENT-amd64-20201126-9e082d278b9 snapshot. If
this is fixed in recent snapshots, I can move to one of those.

--chuck
___
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: port build fails with missing sys/smr_types.h

[Mark Johnston]

On Thu, Dec 03, 2020 at 01:08:52PM -0800, Chuck Tuffli wrote:
> Hi
> 
> I'm trying to fix the build of qemu-utils but am seeing failures on
> CURRENT (13.0-HEAD-9e082d278b9) like:
> 
> In file included from util/oslib-posix.c:50:
> In file included from /usr/include/sys/user.h:51:
> In file included from /usr/include/sys/proc.h:50:
> /usr/include/sys/filedesc.h:47:10: fatal error: 'sys/smr_types.h' file not 
> found
> #include 
>  ^
> 
> # uname -a
> FreeBSD sv0.tuffli.net 13.0-HEAD-9e082d278b9 FreeBSD
> 13.0-HEAD-9e082d278b9 #0 9e082d278b91-c254726(HEAD)-dirty: Fri Nov 27
> 00:09:50 PST 2020
> root@freebsd:/build/9e082d278b9/obj/build/9e082d278b9/src/amd64.amd64/sys/GENERIC-NODEBUG
>  amd64
> # ls -l /usr/include/sys/*smr*
> -r--r--r--  1 root  wheel  1988 Nov 30 14:04 /usr/include/sys/_smr.h
> -r--r--r--  1 root  wheel  7822 Nov 30 14:04 /usr/include/sys/smr.h
> 
> So it appears the file is missing. Any ideas?

How old is your world?  I have /usr/include/sys/smr_types.h on my
systems.  It's present on freefall as well.
___
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: port build fails with missing sys/smr_types.h

[Yuri Pankov]

Alan Somers wrote:

On Thu, Dec 3, 2020 at 2:09 PM Chuck Tuffli  wrote:


Hi

I'm trying to fix the build of qemu-utils but am seeing failures on
CURRENT (13.0-HEAD-9e082d278b9) like:

In file included from util/oslib-posix.c:50:
In file included from /usr/include/sys/user.h:51:
In file included from /usr/include/sys/proc.h:50:
/usr/include/sys/filedesc.h:47:10: fatal error: 'sys/smr_types.h' file not
found
#include 
  ^

# uname -a
FreeBSD sv0.tuffli.net 13.0-HEAD-9e082d278b9 FreeBSD
13.0-HEAD-9e082d278b9 #0 9e082d278b91-c254726(HEAD)-dirty: Fri Nov 27
00:09:50 PST 2020
root@freebsd
:/build/9e082d278b9/obj/build/9e082d278b9/src/amd64.amd64/sys/GENERIC-NODEBUG
  amd64
# ls -l /usr/include/sys/*smr*
-r--r--r--  1 root  wheel  1988 Nov 30 14:04 /usr/include/sys/_smr.h
-r--r--r--  1 root  wheel  7822 Nov 30 14:04 /usr/include/sys/smr.h

So it appears the file is missing. Any ideas?

--chuck



That file doesn't get installed into /usr/include, but it exists in
/usr/src.  A few ports need /usr/src.  See  devel/py-libzfs/Makefile for an
example of how to find it.


But it's included from the header that *is* in /usr/include/, not 
directly by external code.  Should not such dependencies all be in 
/usr/include/?

___
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: port build fails with missing sys/smr_types.h

[Alan Somers]

On Thu, Dec 3, 2020 at 2:09 PM Chuck Tuffli  wrote:

> Hi
>
> I'm trying to fix the build of qemu-utils but am seeing failures on
> CURRENT (13.0-HEAD-9e082d278b9) like:
>
> In file included from util/oslib-posix.c:50:
> In file included from /usr/include/sys/user.h:51:
> In file included from /usr/include/sys/proc.h:50:
> /usr/include/sys/filedesc.h:47:10: fatal error: 'sys/smr_types.h' file not
> found
> #include 
>  ^
>
> # uname -a
> FreeBSD sv0.tuffli.net 13.0-HEAD-9e082d278b9 FreeBSD
> 13.0-HEAD-9e082d278b9 #0 9e082d278b91-c254726(HEAD)-dirty: Fri Nov 27
> 00:09:50 PST 2020
> root@freebsd
> :/build/9e082d278b9/obj/build/9e082d278b9/src/amd64.amd64/sys/GENERIC-NODEBUG
>  amd64
> # ls -l /usr/include/sys/*smr*
> -r--r--r--  1 root  wheel  1988 Nov 30 14:04 /usr/include/sys/_smr.h
> -r--r--r--  1 root  wheel  7822 Nov 30 14:04 /usr/include/sys/smr.h
>
> So it appears the file is missing. Any ideas?
>
> --chuck
>

That file doesn't get installed into /usr/include, but it exists in
/usr/src.  A few ports need /usr/src.  See  devel/py-libzfs/Makefile for an
example of how to find it.
-Alan
___
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"

port build fails with missing sys/smr_types.h

[Chuck Tuffli]

Hi

I'm trying to fix the build of qemu-utils but am seeing failures on
CURRENT (13.0-HEAD-9e082d278b9) like:

In file included from util/oslib-posix.c:50:
In file included from /usr/include/sys/user.h:51:
In file included from /usr/include/sys/proc.h:50:
/usr/include/sys/filedesc.h:47:10: fatal error: 'sys/smr_types.h' file not found
#include 
 ^

# uname -a
FreeBSD sv0.tuffli.net 13.0-HEAD-9e082d278b9 FreeBSD
13.0-HEAD-9e082d278b9 #0 9e082d278b91-c254726(HEAD)-dirty: Fri Nov 27
00:09:50 PST 2020
root@freebsd:/build/9e082d278b9/obj/build/9e082d278b9/src/amd64.amd64/sys/GENERIC-NODEBUG
 amd64
# ls -l /usr/include/sys/*smr*
-r--r--r--  1 root  wheel  1988 Nov 30 14:04 /usr/include/sys/_smr.h
-r--r--r--  1 root  wheel  7822 Nov 30 14:04 /usr/include/sys/smr.h

So it appears the file is missing. Any ideas?

--chuck
___
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: Issues with USB-C external monitors

[Ali Abdallah]

Sorry for the noise, you can the patches at the following link:

https://github.com/Alix82/FreeBSD-xorg-drm-hotplug

On 03.12.2020 08:05, Ali Abdallah wrote:
> On 02.12.2020 11:28, Ali Abdallah wrote:
> > Actually Xorg on FreeBSD with UDEV is compiled with
> > --disable-config-udev-kms, thus the server never calls:
> > 
> > udev_monitor_filter_add_match_subsystem_devtype
> > 
> > for GPU devices, and thus libudev-devd doesn't forward kms events to the
> > server. Actually Xorg doesn't even process them, even if the filter check
> > is bypassed in libudev-devd (udev-monitor.c:261).
> > 
> > Basically Xorg is missing bsd platform code for drm devices, on Linux
> > the code that implements that can be found in:
> > hw/xfree86/os-support/linux/lnx_platform.c
> 
> I'm attaching two patches that make hotpluggable drm connectors work on
> FreeBSD with xorg-server compiled with UDEV.
> 
> If you want to give them a try, for libudev-devd it is enough to apply
> patch-libudev-devd-drm-hotplug.c, but for xorg-server you need to change
> its Makefile to enable udev-kms, and apply 
> patch-xorg-server-drm-bsd-platform.c
> 
> UDEV_CONFIGURE_ON=  --disable-config-udev-kms
> 
> to
> 
> UDEV_CONFIGURE_ON=  --enabled-config-udev-kms
> 
> The bsd-platform code for the xorg-server is basically the same as Linux,
> expect for the systemd bit obviously. For now, I appended the code to
> hw/xfree86/os-support/bsd/bsd_VTsw.c just because I didn't want to patch
> the Makefile.in or Makefile.am and fight with autotools. But that code
> should finish in the future in bsd_platform.c.
> 
> It is working perfectly fine for me, also got positive feedback from a
> friend using it on a Thinkpad X280 with a USB-C dock.
> 
> The patches even for onboard connectors deliver for "complete" desktop
> plugging/unplugging external monitors events (such as Xfce, gnome, KDE),
> and then the external monitors are configured automatically.
> 
> I will also later on work on DEVD support as well.
> 
> Regards.
> 
> -- 
> Ali Abdallah | SUSE Linux L3 Engineer
> GPG fingerprint: 51A0 F4A0 C8CF C98F 842E  A9A8 B945 56F8 1C85 D0D5
> 






-- 
Ali Abdallah | SUSE Linux L3 Engineer
GPG fingerprint: 51A0 F4A0 C8CF C98F 842E  A9A8 B945 56F8 1C85 D0D5

___
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: Issues with USB-C external monitors

[Ali Abdallah]

On 02.12.2020 11:28, Ali Abdallah wrote:
> Actually Xorg on FreeBSD with UDEV is compiled with
> --disable-config-udev-kms, thus the server never calls:
> 
> udev_monitor_filter_add_match_subsystem_devtype
> 
> for GPU devices, and thus libudev-devd doesn't forward kms events to the
> server. Actually Xorg doesn't even process them, even if the filter check
> is bypassed in libudev-devd (udev-monitor.c:261).
> 
> Basically Xorg is missing bsd platform code for drm devices, on Linux
> the code that implements that can be found in:
> hw/xfree86/os-support/linux/lnx_platform.c

I'm attaching two patches that make hotpluggable drm connectors work on
FreeBSD with xorg-server compiled with UDEV.

If you want to give them a try, for libudev-devd it is enough to apply
patch-libudev-devd-drm-hotplug.c, but for xorg-server you need to change
its Makefile to enable udev-kms, and apply patch-xorg-server-drm-bsd-platform.c

UDEV_CONFIGURE_ON=  --disable-config-udev-kms

to

UDEV_CONFIGURE_ON=  --enabled-config-udev-kms

The bsd-platform code for the xorg-server is basically the same as Linux,
expect for the systemd bit obviously. For now, I appended the code to
hw/xfree86/os-support/bsd/bsd_VTsw.c just because I didn't want to patch
the Makefile.in or Makefile.am and fight with autotools. But that code
should finish in the future in bsd_platform.c.

It is working perfectly fine for me, also got positive feedback from a
friend using it on a Thinkpad X280 with a USB-C dock.

The patches even for onboard connectors deliver for "complete" desktop
plugging/unplugging external monitors events (such as Xfce, gnome, KDE),
and then the external monitors are configured automatically.

I will also later on work on DEVD support as well.

Regards.

-- 
Ali Abdallah | SUSE Linux L3 Engineer
GPG fingerprint: 51A0 F4A0 C8CF C98F 842E  A9A8 B945 56F8 1C85 D0D5



signature.asc
Description: PGP signature

Re: page fault due to close(2), possibly drm and i915kms related

[Trond Endrestøl]

On Thu, 3 Dec 2020 11:45+0100, Mateusz Guzik wrote:

> This should be fixed by r368271

Thank you, guys. I'll upgrade my laptop when I get home.

--
Trond.
___
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: page fault due to close(2), possibly drm and i915kms related

[Hans Petter Selasky]

On 12/3/20 11:43 AM, Trond Endrestøl wrote:

[160176] --- trap 0xc, rip = 0x808cbd2c, rsp = 0xfe018500e700, rbp 
= 0xfe018500e780 ---
[160176] __mtx_lock_sleep() at 0x808cbd2c = __mtx_lock_sleep+0xfc/frame 
0xfe018500e780
[160176] doselwakeup() at 0x8095fbee = doselwakeup+0xde/frame 
0xfe018500e7c0
[160176] sowakeup() at 0x80988c7e = sowakeup+0x1e/frame 
0xfe018500e7f0
[160176] soisdisconnected() at 0x8099235a = soisdisconnected+0x8a/frame 
0xfe018500e810
[160176] unp_disconnect() at 0x8099a9fe = unp_disconnect+0x12e/frame 
0xfe018500e850
[160176] uipc_disconnect() at 0x809982a2 = uipc_disconnect+0x42/frame 
0xfe018500e870
[160176] soclose() at 0x8098cc96 = soclose+0x76/frame 0xfe018500e8d0
[160176] _fdrop() at 0x80891eb1 = _fdrop+0x11/frame 0xfe018500e8f0
[160176] closef() at 0x80895098 = closef+0x278/frame 0xfe018500e980
[160176] closefp() at 0x808921d9 = closefp+0x89/frame 0xfe018500e9c0
[160176] amd64_syscall() at 0x80cf8a45 = amd64_syscall+0x755/frame 
0xfe018500eaf0
[160176] fast_syscall_common() at 0x80ccfd0e = 
fast_syscall_common+0xf8/frame 0xfe018500eaf0
[160176] --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x8003b0d7a, rsp = 
0x7fffe998, rbp = 0x7fffe9b0 ---
[160176] Uptime: 1d20h29m36s
[160176] Dumping 6415 out of 32449 
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%


I wonder if this issue was fixed by:

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

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: page fault due to close(2), possibly drm and i915kms related

[Mateusz Guzik]

This should be fixed by r368271

On 12/3/20, Trond Endrestøl  wrote:
> Fam,
>
> After close(2) got fixed in r368006 last week, my laptop at home has
> been acting up.
>
> It currently runs:
>
> FreeBSD E590T.ufp 13.0-CURRENT FreeBSD 13.0-CURRENT #870 r368192: Mon Nov 30
> 20:29:15 CET 2020 r...@e590t.ufp:/usr/obj/usr/src/amd64.amd64/sys/E590T
> amd64 1300130 1300130 a5c28607a47e84c68f4c8063d23189c475e61ac8
>
> The DRM and KMS drivers (i915kms) are compiled from the source code of
> graphics/drm-kmod and are automatically installed along with the
> kernel.
>
> From time to time whenever I'm logged in using X.org, I sometimes get
> crashes like this one:
>
> Script started on Thu Dec  3 07:13:33 2020
> Command: kkgdb /boot/kernel/kernel /var/crash/vmcore.2
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
>
> Unread portion of the kernel message buffer:
> [160176]
> [160176]
> [160176] Fatal trap 12: page fault while in kernel mode
> [160176] cpuid = 0; apic id = 00
> [160176] fault virtual address= 0x440
> [160176] fault code   = supervisor read data, page not present
> [160176] instruction pointer  = 0x20:0x808cbd2c
> [160176] stack pointer= 0x28:0xfe018500e700
> [160176] frame pointer= 0x28:0xfe018500e780
> [160176] code segment = base 0x0, limit 0xf, type 0x1b
> [160176]  = DPL 0, pres 1, long 1, def32 0, gran 1
> [160176] processor eflags = interrupt enabled, resume, IOPL = 0
> [160176] current process  = 3874 (wc)
> [160176] trap number  = 12
> [160176] WARNING !drm_modeset_is_locked(>mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:621
> [160176] #0 0x82766583 at linux_dump_stack+0x23
> [160176] #1 0x830fb3c3 at drm_atomic_helper_check_modeset+0xb3
> [160176] #2 0x831dfd9d at intel_atomic_check+0x8d
> [160176] #3 0x830fa360 at drm_atomic_check_only+0x400
> [160176] #4 0x830fa793 at drm_atomic_commit+0x13
> [160176] #5 0x83107948 at drm_client_modeset_commit_atomic+0x148
> [160176] #6 0x83107671 at drm_client_modeset_commit_force+0x71
> [160176] #7 0x8314a7d7 at
> drm_fb_helper_restore_fbdev_mode_unlocked+0x77
> [160176] #8 0x831445d1 at vt_kms_postswitch+0x191
> [160176] #9 0x8076202b at vt_window_switch+0x12b
> [160176] #10 0x8075f12f at vtterm_cngrab+0x1f
> [160176] #11 0x80887c36 at cngrab+0x16
> [160176] #12 0x808ee35c at vpanic+0xec
> [160176] #13 0x808ee263 at panic+0x43
> [160176] #14 0x80cf7af7 at trap_fatal+0x387
> [160176] #15 0x80cf7b4f at trap_pfault+0x4f
> [160176] #16 0x80cf71ad at trap+0x27d
> [160176] #17 0x80ccf3e8 at calltrap+0x8
> [160176] WARNING !drm_modeset_is_locked(>mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:621
> [160176] #0 0x82766583 at linux_dump_stack+0x23
> [160176] #1 0x830fb3c3 at drm_atomic_helper_check_modeset+0xb3
> [160176] #2 0x831dfd9d at intel_atomic_check+0x8d
> [160176] #3 0x830fa360 at drm_atomic_check_only+0x400
> [160176] #4 0x830fa793 at drm_atomic_commit+0x13
> [160176] #5 0x83107948 at drm_client_modeset_commit_atomic+0x148
> [160176] #6 0x83107671 at drm_client_modeset_commit_force+0x71
> [160176] #7 0x8314a7d7 at
> drm_fb_helper_restore_fbdev_mode_unlocked+0x77
> [160176] #8 0x831445d1 at vt_kms_postswitch+0x191
> [160176] #9 0x8076202b at vt_window_switch+0x12b
> [160176] #10 0x8075f12f at vtterm_cngrab+0x1f
> [160176] #11 0x80887c36 at cngrab+0x16
> [160176] #12 0x808ee35c at vpanic+0xec
> [160176] #13 0x808ee263 at panic+0x43
> [160176] #14 0x80cf7af7 at trap_fatal+0x387
> [160176] #15 0x80cf7b4f at trap_pfault+0x4f
> [160176] #16 0x80cf71ad at trap+0x27d
> [160176] #17 0x80ccf3e8 at calltrap+0x8
> [160176] WARNING !drm_modeset_is_locked(>mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:621
> [160176] #0 0x82766583 at linux_dump_stack+0x23
> [160176] #1 0x830fb3c3 at drm_atomic_helper_check_modeset+0xb3
> [160176] #2 0x831dfd9d at intel_atomic_check+0x8d
> [160176] #3 0x830fa360 at drm_atomic_check_only+0x400
> [160176] #4 0x830fa793 at drm_atomic_commit+0x13
> [160176] #5 0x83107948 at drm_client_modeset_commit_atomic+0x148
> [160176] #6 0x83107671 at drm_client_modeset_commit_force+0x71
> 

page fault due to close(2), possibly drm and i915kms related

[Trond Endrestøl]

Fam,

After close(2) got fixed in r368006 last week, my laptop at home has 
been acting up.

It currently runs:

FreeBSD E590T.ufp 13.0-CURRENT FreeBSD 13.0-CURRENT #870 r368192: Mon Nov 30 
20:29:15 CET 2020 r...@e590t.ufp:/usr/obj/usr/src/amd64.amd64/sys/E590T  
amd64 1300130 1300130 a5c28607a47e84c68f4c8063d23189c475e61ac8

The DRM and KMS drivers (i915kms) are compiled from the source code of 
graphics/drm-kmod and are automatically installed along with the 
kernel.

>From time to time whenever I'm logged in using X.org, I sometimes get 
crashes like this one:

Script started on Thu Dec  3 07:13:33 2020
Command: kkgdb /boot/kernel/kernel /var/crash/vmcore.2
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
[160176] 
[160176] 
[160176] Fatal trap 12: page fault while in kernel mode
[160176] cpuid = 0; apic id = 00
[160176] fault virtual address  = 0x440
[160176] fault code = supervisor read data, page not present
[160176] instruction pointer= 0x20:0x808cbd2c
[160176] stack pointer  = 0x28:0xfe018500e700
[160176] frame pointer  = 0x28:0xfe018500e780
[160176] code segment   = base 0x0, limit 0xf, type 0x1b
[160176]= DPL 0, pres 1, long 1, def32 0, gran 1
[160176] processor eflags   = interrupt enabled, resume, IOPL = 0
[160176] current process= 3874 (wc)
[160176] trap number= 12
[160176] WARNING !drm_modeset_is_locked(>mutex) failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:621
[160176] #0 0x82766583 at linux_dump_stack+0x23
[160176] #1 0x830fb3c3 at drm_atomic_helper_check_modeset+0xb3
[160176] #2 0x831dfd9d at intel_atomic_check+0x8d
[160176] #3 0x830fa360 at drm_atomic_check_only+0x400
[160176] #4 0x830fa793 at drm_atomic_commit+0x13
[160176] #5 0x83107948 at drm_client_modeset_commit_atomic+0x148
[160176] #6 0x83107671 at drm_client_modeset_commit_force+0x71
[160176] #7 0x8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77
[160176] #8 0x831445d1 at vt_kms_postswitch+0x191
[160176] #9 0x8076202b at vt_window_switch+0x12b
[160176] #10 0x8075f12f at vtterm_cngrab+0x1f
[160176] #11 0x80887c36 at cngrab+0x16
[160176] #12 0x808ee35c at vpanic+0xec
[160176] #13 0x808ee263 at panic+0x43
[160176] #14 0x80cf7af7 at trap_fatal+0x387
[160176] #15 0x80cf7b4f at trap_pfault+0x4f
[160176] #16 0x80cf71ad at trap+0x27d
[160176] #17 0x80ccf3e8 at calltrap+0x8
[160176] WARNING !drm_modeset_is_locked(>mutex) failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:621
[160176] #0 0x82766583 at linux_dump_stack+0x23
[160176] #1 0x830fb3c3 at drm_atomic_helper_check_modeset+0xb3
[160176] #2 0x831dfd9d at intel_atomic_check+0x8d
[160176] #3 0x830fa360 at drm_atomic_check_only+0x400
[160176] #4 0x830fa793 at drm_atomic_commit+0x13
[160176] #5 0x83107948 at drm_client_modeset_commit_atomic+0x148
[160176] #6 0x83107671 at drm_client_modeset_commit_force+0x71
[160176] #7 0x8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77
[160176] #8 0x831445d1 at vt_kms_postswitch+0x191
[160176] #9 0x8076202b at vt_window_switch+0x12b
[160176] #10 0x8075f12f at vtterm_cngrab+0x1f
[160176] #11 0x80887c36 at cngrab+0x16
[160176] #12 0x808ee35c at vpanic+0xec
[160176] #13 0x808ee263 at panic+0x43
[160176] #14 0x80cf7af7 at trap_fatal+0x387
[160176] #15 0x80cf7b4f at trap_pfault+0x4f
[160176] #16 0x80cf71ad at trap+0x27d
[160176] #17 0x80ccf3e8 at calltrap+0x8
[160176] WARNING !drm_modeset_is_locked(>mutex) failed at 
/usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:621
[160176] #0 0x82766583 at linux_dump_stack+0x23
[160176] #1 0x830fb3c3 at drm_atomic_helper_check_modeset+0xb3
[160176] #2 0x831dfd9d at intel_atomic_check+0x8d
[160176] #3 0x830fa360 at drm_atomic_check_only+0x400
[160176] #4 0x830fa793 at drm_atomic_commit+0x13
[160176] #5 0x83107948 at drm_client_modeset_commit_atomic+0x148
[160176] #6 0x83107671 at drm_client_modeset_commit_force+0x71
[160176] #7 0x8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77
[160176] #8 0x831445d1 at vt_kms_postswitch+0x191
[160176] #9 0x8076202b at vt_window_switch+0x12b
[160176] #10 0x8075f12f at 

Re: Issues with USB-C external monitors

[Poul-Henning Kamp]

Ali Abdallah writes:
> Sorry for the noise, you can the patches at the following link:
>
> https://github.com/Alix82/FreeBSD-xorg-drm-hotplug

Thanks a lot Ali!

With these patches my T480+TB3 dock works, with the following footnotes:

I have disabled "TB3 Bios assist" in the BIOS and use a USB-C cable
instead of the TB-3 cable, to keep TB3 out of this.

At some point, probably years ago, I ran "make config" in
x11-servers/xorg-server, and the state-file left in /var/db/ports
kept UDEV disabled, despite the patch to Makefile in the bundle above.

You can either remove the state-file or run "make config" again and
select UDEV.

Poul-Henning


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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"