Re: freebsd-current Digest, Vol 877, Issue 7

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: freebsd-current Digest, Vol 877, Issue 7

Lizbeth Mutterhunt, Ph.D
replying to myself at 1am:

1. completely new-install

2. kmod-legacy and kmd-stable built

3. svn up; make kernel

4. linux-c7 from /ports installed

5. kld_load x 2

6. fine drm initialized but when trying to sddm or xinit or startx or
whatever I get a loooooong debug output message with self reset running
over my screen.

any help?

miranda


On 22.08.20 14:00, [hidden email] wrote:

> Send freebsd-current mailing list submissions to
> [hidden email]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> or, via email, send a message with subject or body 'help' to
> [hidden email]
>
> You can reach the person managing the list at
> [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of freebsd-current digest..."
>
>
> Today's Topics:
>
>     1. Re: freebsd-current Digest, Vol 877, Issue 6
>        (Vanbreukelingen Ltd.)
>     2. /usr/lib/libomp.so : is there a reason that aarch64 does not
>        have such by default? (Mark Millard)
>     3. FreeBSD CI Weekly Report 2020-08-16 (Li-Wen Hsu)
>     4. Re: Kernel crash during video transcoding (Hans Petter Selasky)
>     5. Re: /usr/lib/libomp.so : is there a reason that aarch64 does
>        not have such by default? (myfreeweb)
>     6. 13-CURRENT won't boot after switch to sysutils/openzfs (marco)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 21 Aug 2020 19:37:54 +0200
> From: "Vanbreukelingen Ltd." <[hidden email]>
> To: [hidden email]
> Subject: Re: freebsd-current Digest, Vol 877, Issue 6
> Message-ID: <2624761.GQDcWxOStt@alice>
> Content-Type: text/plain; charset="us-ascii"
>
> here we go - when nothing works anymore (kernel panic after a simple 'xinit'
> and kwin_x11. recomiled to WITNESS="YES" and HYPERV off, but still same panics.
>
> https://pasteboard.co/Jnqgbeq.png
>
>
>
> On Friday, August 21, 2020 2:00:00 PM CEST [hidden email]
> wrote:
>
>> Message: 1
>> Date: Thu, 20 Aug 2020 08:15:56 +0200
>> From: "Vanbreukelingen Ltd." <[hidden email]>
>> To: Current FreeBSD <[hidden email]>
>> Subject: Re: funny thing with the drm0
>> Message-ID: <8073347.hK6j7OjjKr@alice>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> On Thursday, August 20, 2020 8:12:58 AM CEST Vanbreukelingen Ltd. wrote:
>>> On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote:
>>>> On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D <
>>>>
>>>> [hidden email]> wrote:
>>>>> After having had some near-death-experiences in Greece I'm back to my
>>>>> screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-)
>>>>>
>>>>>
>>>>> But this is the experience with my Dell Vostro on 13 current:
>>>>>
>>>>>
>>>>> After finally recompiling the kernel with the drm-module inside and
>>>>> the trick of injecting the
>>>> This is not the way to do it. Modern hardware require drm-kmod from
>>>> ports,
>>>> or if you want the latest drm-devel-kmod. Then add  /boot/modules/drm.ko
>>>> and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf
>> wasn't yet finished (c [see] beyond), but I guess I have to disable the
>> whole output with something like hw.*=1 or so. is it possible to make a
>> bootlogo while VEBOSE output = 2 just for the reason some kids try to play
>> with it.
>>
>>>>> device IWNFW
>>   doesn't install the 6000, btw --- probably can't find FW on device HAL.
>>
>>>> Again, this is not needed, firmware is autoloaded on module load. Just
>>>> add
>>>> if_iwn to kld_list in /etc/rc.conf
>>   built of 15 hours of NanoBSD while finishing the nightly built someone was
>> on Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at all
>> but some reason tells me behind this system in system is something to beat
>> beastie in killing KFC forks. ;-)
>>
>>>>> I get a *nice* message a bootup:
>>>>>
>>>>> Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0
>>>>> 20060810
>>>>> Aug 19 02:51:10 current kernel: drmn0: <Intel SandyBridge (M)> on
>>>>> vgapci0
>>>>> Aug 19 02:51:10 current kernel: info: [drm] Memory usable by graphics
>>>>> device = 2048M
>>>>> Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation failed.
>>>>> Graphics performance may suffer.
>>>>> Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0
>>>>> Aug 19 02:51:10 current kernel: iicbus0: <Philips I2C bus> on
>>>>> iicbb_nostop0 addr 0x1
>>>>> Aug 19 02:51:10 current kernel: iic0: <I2C generic I/O> on iicbus0
>>>>> Aug 19 02:51:10 current kernel: iicbus1: <Philips I2C bus> on
>>>>> intel_gmbus0
>>>>> Aug 19 02:51:10 current kernel: iic1: <I2C generic I/O> on iicbus1
>>>>> Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0
>>>>> Aug 19 02:51:10 current kernel: iicbus2: <Philips I2C bus> on
>>>>> iicbb_nostop1 addr 0x12
>>>>> Aug 19 02:51:10 current kernel: iic2: <I2C generic I/O> on iicbus2
>>>>> Aug 19 02:51:10 current kernel: iicbus3: <Philips I2C bus> on
>>>>> intel_gmbus1
>>>>> Aug 19 02:51:10 current kernel: iic3: <I2C generic I/O> on iicbus3
>>>>> Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0
>>>>> Aug 19 02:51:10 current kernel: iicbus4: <Philips I2C bus> on
>>>>> iicbb_nostop2 addr 0x12
>>>>> Aug 19 02:51:10 current kernel: iic4: <I2C generic I/O> on iicbus4
>>>>> Aug 19 02:51:10 current kernel: iicbus5: <Philips I2C bus> on
>>>>> intel_gmbus2
>>>>> Aug 19 02:51:10 current kernel: iic5: <I2C generic I/O> on iicbus5
>>>>> Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0
>>>>> Aug 19 02:51:10 current kernel: iicbus6: <Philips I2C bus> on
>>>>> iicbb_nostop3 addr 0x12
>>>>> Aug 19 02:51:10 current kernel: iic6: <I2C generic I/O> on iicbus6
>>>>> Aug 19 02:51:10 current kernel: iicbus7: <Philips I2C bus> on
>>>>> intel_gmbus3
>>>>> Aug 19 02:51:10 current kernel: iic7: <I2C generic I/O> on iicbus7
>>>>> Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0
>>>>> Aug 19 02:51:10 current kernel: iicbus8: <Philips I2C bus> on
>>>>> iicbb_nostop4 addr 0x12
>>>>> Aug 19 02:51:10 current kernel: iic8: <I2C generic I/O> on iicbus8
>>>>> Aug 19 02:51:10 current kernel: iicbus9: <Philips I2C bus> on
>>>>> intel_gmbus4
>>>>> Aug 19 02:51:10 current kernel: iic9: <I2C generic I/O> on iicbus9
>>>>> Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0
>>>>> Aug 19 02:51:10 current kernel: iicbus10: <Philips I2C bus> on
>>>>> iicbb_nostop5 addr 0x12
>>>>>
>>>>> And furthermore:
>>>>>
>>>>> Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 message(s)
>>>>> Aug 19 02:51:10 current kernel: info: [drm] Supports vblank timestamp
>>>>> caching Rev 1 (10.10.201>
>>>>> Aug 19 02:51:10 current kernel: info: [drm] Driver supports precise
>>>>> vblank timestamp query.
>>>>> Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on drmn0
>>>>> Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: detached
>>>>> Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0
>>>>> Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious
>>>>> range 0xe0000000-0xf0000000
>>>>> Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: get mode
>>>>> from tunables:
>>>>> Aug 19 02:51:10 current kernel: info: [drm]   -
>>>>> kern.vt.fb.modes.LVDS-1
>>>>> Aug 19 02:51:10 current kernel: info: [drm]   -
>>>>> kern.vt.fb.default_mode
>>>>> Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: get mode
>>>>> from tunables:
>>>>> Aug 19 02:51:10 current kernel: info: [drm]   - kern.vt.fb.modes.VGA-1
>>>>> Aug 19 02:51:10 current kernel: info: [drm]   -
>>>>> kern.vt.fb.default_mode
>>>>> Aug 19 02:51:10 current kernel: info: [drm] Connector HDMI-A-1: get
>>>>> mode from tunables:
>>>>> Aug 19 02:51:10 current kernel: info: [drm]   -
>>>>> kern.vt.fb.modes.HDMI-A-1
>>>>> Aug 19 02:51:10 current kernel: info: [drm]   -
>>>>> kern.vt.fb.default_mode
>>>>> Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: get mode
>>>>> from tunables:
>>>>> Aug 19 02:51:10 current kernel: info: [drm]   - kern.vt.fb.modes.DP-1
>>>>> Aug 19 02:51:10 current kernel: info: [drm]   -
>>>>> kern.vt.fb.default_mode
>>>>> Aug 19 02:51:10 current kernel: fbd0 on drmn0
>>>>> Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant locked
>>>>> and may be deleted before>
>>>>> Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" with new
>>>>> "fb".
>>>>> ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0
>>>>> 20080730 for drmn0 on minor 0
>>>>>
>>>>> so far so good, quality of text in grafics 1368x1024 is perfectly
>>>>> initialized. but now, when starting xinit or lightdm or sddm or
>>>>> whatever I get a kernel panic:
>>>>>
>>>>> Dump header from device: /dev/ada0p4
>>>>>
>>>>>    Architecture: i386
>>>>>    Architecture Version: 4
>>>>>    Dump Length: 97792
>>>>>    Blocksize: 512
>>>>>    Compression: none
>>>>>    Dumptime: 2020-08-19 02:49:00 +0200
>>>>>    Hostname: current
>>>>>    Magic: FreeBSD Text Dump
>>>>>    Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18 20:18:40
>>>>>
>>>>> CEST 2020
>>>>>
>>>>>      root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA
>>>>>    
>>>>>    Panic String: vm_page_assert_xbusied: page 0x72bd024 not exclusive
>>>>>
>>>>> busy @ /usr/src/sys/vm/vm>
>>>>>
>>>>>    Dump Parity: 2773167169
>>>>>    Bounds: 1
>>>>>    Dump Status: good
>>>>>    
>>>>>    /var/crash/vmcore.0 not found
>>>> Do you have  dumpdev="AUTO" in /etc/rc.conf ?
>> yes and the directory is /var/crash, but this is all I get as lack of
>> insufficent memory of dump, it says.
>>
>>>>> First thing I think is kern options:
>>>>>
>>>>> options WITNESS_SKIPSPIN
>>>>> options WITNESS
>>>>>
>>>>> I disabled device HYPERV but this can't be the reason, kern is being
>>>>> compiled with clang.
>>>> Clang is the default since a long time.
>> depends on gcc++ development in 4D AIs.
>>
>>>>> To disable WITNESS would be one way I think but this can't be the
>>>>> yellw of the egg, isn't it?
>>>> I use the GENERIC-NODEBUG kernel config which disables WITNESS for some
>>>> performance improvements.
>> yup. we don't need another debugger. killing insects is murder but when
>> getting better stuff I never resist to lance them. like housecats with flys.
>>>>> Another thing but I guess having nothing to do with bug above is on
>>>>> rather the end of  startup:
>>>>>
>>>>> Aug 19 02:51:10 current savecore[1209]: reboot after panic:
>>>>> vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @
>>>>> /usr/src/sys/vm/vm_page.c:1609
>>>>> Aug 19 02:51:10 current savecore[1209]: writing core to
>>>>> /var/crash/textdump.tar.1
>>>>> Aug 19 02:51:10 current kernel: linsysfs:
>>>>> Aug 19 02:51:10 current kernel: Device busy
>>>>> Aug 19 02:51:10 current kernel: lock order reversal:
>>>>> Aug 19 02:51:10 current kernel:  1st 0x3121e870 ufs (ufs, lockmgr) @
>>>>> /usr/src/sys/kern/vfs_mount.c:1008
>>>>> Aug 19 02:51:10 current kernel:  2nd 0x3121e744 devfs (devfs, lockmgr)
>>>>> @ /usr/src/sys/kern/vfs_mount.c:1019
>>>>> Aug 19 02:51:10 current kernel: lock order devfs -> ufs established
>>>>> at:
>>>>> Aug 19 02:51:10 current kernel: #0 0x1027cd5 at
>>>>> witness_checkorder+0x3c5
>>>>> Aug 19 02:51:10 current kernel: #1 0xf9cca0 at
>>>>> lockmgr_lock_flags+0x140
>>>>> Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57
>>>>> Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f
>>>>> Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f
>>>>> Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99
>>>>> Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b
>>>>> Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57
>>>>> Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452
>>>>> Aug 19 02:51:10 current kernel: #9 0x10859be at vfs_mountroot+0x4ce
>>>>> Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22
>>>>> Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68
>>>>> Aug 19 02:51:10 current kernel: #12 0xffc0340e at
>>>>> __stop_set_sysinit_set+0xd0a4199e
>>>>> Aug 19 02:51:10 current kernel: lock order ufs -> devfs attempted at:
>>>>> Aug 19 02:51:10 current kernel: #0 0x1028360 at
>>>>> witness_checkorder+0xa50
>>>>> Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46
>>>>> Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a
>>>>> Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f
>>>>> Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f
>>>>> Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99
>>>>> Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b
>>>>> Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d
>>>>> Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195
>>>>> Aug 19 02:51:10 current kernel: #9 0xffc033f9 at
>>>>> __stop_set_sysinit_set+0xd0a41989
>>>>>
>>>>> any ideas?
>>>>> Miranda
>>>>>
>>>>>
>>>>>
>>>>> does someone know how to fix it?
>>>>>
>>>>> Miranda
>>>> Hope this helps.
>> It does!
>>
>>>> Best regards
>>>> Andreas Nilsson
>> Yours,
>> Miranda van Breukelingen
>>
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 20 Aug 2020 16:43:56 +0200
>> From: Andreas Nilsson <[hidden email]>
>> To: "Vanbreukelingen Ltd." <[hidden email]>,  Current
>> FreeBSD <[hidden email]>
>> Subject: Re: funny thing with the drm0
>> Message-ID:
>> <CAPS9+SshknntXpCxnNB=Pm+BNJh_+pvJc_z5X5eN6t-
> [hidden email]>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> On Thu, Aug 20, 2020 at 2:48 PM Vanbreukelingen Ltd. <
>>
>> [hidden email]> wrote:
>>> On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote:
>>>> On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D <
>>>>
>>>> [hidden email]> wrote:
>>>>> After having had some near-death-experiences in Greece I'm back to my
>>>>> screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-)
>>>>>
>>>>>
>>>>> But this is the experience with my Dell Vostro on 13 current:
>>>>>
>>>>>
>>>>> After finally recompiling the kernel with the drm-module inside and
>>>>> the trick of injecting the
>>>> This is not the way to do it. Modern hardware require drm-kmod from
>>> ports,
>>>
>>>> or if you want the latest drm-devel-kmod. Then add  /boot/modules/drm.ko
>>>> and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf
>>> wasn't yet finished (c [see] beyond), but I guess I have to disable the
>>> whole
>>> output with something like hw.*=1 or so. is it possible to make a bootlogo
>>> while VEBOSE output = 2 just for the reason some kids try to play with it.
>>>
>>>>> device IWNFW
>>> doesn't install the 6000, btw --- probably can't find FW on device HAL.
>>>
>>>> Again, this is not needed, firmware is autoloaded on module load. Just
>>> add
>>>
>>>> if_iwn to kld_list in /etc/rc.conf
>> Here I admit I was wrong, iwn handles it differently than iwm. The man page
>> lists 3 different firmware versions for the 6000 series, which can be
>> loaded from loader.conf
>>
>>> built 15 hours of NanoBSD while finishing the nightly built someone was on
>>> Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at all but
>>> some
>>> reason tells me behind this system in system is something to beat beastie
>>> in
>>> killing KFC forks.
>>>
>>>>> I get a *nice* message a bootup:
>>>>>
>>>>> Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0
>>> 20060810
>>>
>>>>> Aug 19 02:51:10 current kernel: drmn0: <Intel SandyBridge (M)> on
>>> vgapci0
>>>
>>>>> Aug 19 02:51:10 current kernel: info: [drm] Memory usable by graphics
>>>>> device = 2048M
>>>>> Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation failed.
>>>>> Graphics performance may suffer.
>>>>> Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0
>>>>> Aug 19 02:51:10 current kernel: iicbus0: <Philips I2C bus> on
>>>>> iicbb_nostop0 addr 0x1
>>>>> Aug 19 02:51:10 current kernel: iic0: <I2C generic I/O> on iicbus0
>>>>> Aug 19 02:51:10 current kernel: iicbus1: <Philips I2C bus> on
>>> intel_gmbus0
>>>
>>>>> Aug 19 02:51:10 current kernel: iic1: <I2C generic I/O> on iicbus1
>>>>> Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0
>>>>> Aug 19 02:51:10 current kernel: iicbus2: <Philips I2C bus> on
>>>>> iicbb_nostop1 addr 0x12
>>>>> Aug 19 02:51:10 current kernel: iic2: <I2C generic I/O> on iicbus2
>>>>> Aug 19 02:51:10 current kernel: iicbus3: <Philips I2C bus> on
>>> intel_gmbus1
>>>
>>>>> Aug 19 02:51:10 current kernel: iic3: <I2C generic I/O> on iicbus3
>>>>> Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0
>>>>> Aug 19 02:51:10 current kernel: iicbus4: <Philips I2C bus> on
>>>>> iicbb_nostop2 addr 0x12
>>>>> Aug 19 02:51:10 current kernel: iic4: <I2C generic I/O> on iicbus4
>>>>> Aug 19 02:51:10 current kernel: iicbus5: <Philips I2C bus> on
>>> intel_gmbus2
>>>
>>>>> Aug 19 02:51:10 current kernel: iic5: <I2C generic I/O> on iicbus5
>>>>> Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0
>>>>> Aug 19 02:51:10 current kernel: iicbus6: <Philips I2C bus> on
>>>>> iicbb_nostop3 addr 0x12
>>>>> Aug 19 02:51:10 current kernel: iic6: <I2C generic I/O> on iicbus6
>>>>> Aug 19 02:51:10 current kernel: iicbus7: <Philips I2C bus> on
>>> intel_gmbus3
>>>
>>>>> Aug 19 02:51:10 current kernel: iic7: <I2C generic I/O> on iicbus7
>>>>> Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0
>>>>> Aug 19 02:51:10 current kernel: iicbus8: <Philips I2C bus> on
>>>>> iicbb_nostop4 addr 0x12
>>>>> Aug 19 02:51:10 current kernel: iic8: <I2C generic I/O> on iicbus8
>>>>> Aug 19 02:51:10 current kernel: iicbus9: <Philips I2C bus> on
>>> intel_gmbus4
>>>
>>>>> Aug 19 02:51:10 current kernel: iic9: <I2C generic I/O> on iicbus9
>>>>> Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0
>>>>> Aug 19 02:51:10 current kernel: iicbus10: <Philips I2C bus> on
>>>>> iicbb_nostop5 addr 0x12
>>>>>
>>>>> And furthermore:
>>>>>
>>>>> Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 message(s)
>>>>> Aug 19 02:51:10 current kernel: info: [drm] Supports vblank timestamp
>>>>> caching Rev 1 (10.10.201>
>>>>> Aug 19 02:51:10 current kernel: info: [drm] Driver supports precise
>>>>> vblank timestamp query.
>>>>> Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on drmn0
>>>>> Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: detached
>>>>> Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0
>>>>> Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious
>>>>> range 0xe0000000-0xf0000000
>>>>> Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: get mode
>>>>> from tunables:
>>>>> Aug 19 02:51:10 current kernel: info: [drm]   -
>>>>> kern.vt.fb.modes.LVDS-1
>>>>> Aug 19 02:51:10 current kernel: info: [drm]   -
>>>>> kern.vt.fb.default_mode
>>>>> Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: get mode
>>>>> from tunables:
>>>>> Aug 19 02:51:10 current kernel: info: [drm]   - kern.vt.fb.modes.VGA-1
>>>>> Aug 19 02:51:10 current kernel: info: [drm]   -
>>>>> kern.vt.fb.default_mode
>>>>> Aug 19 02:51:10 current kernel: info: [drm] Connector HDMI-A-1: get
>>>>> mode from tunables:
>>>>> Aug 19 02:51:10 current kernel: info: [drm]   -
>>> kern.vt.fb.modes.HDMI-A-1
>>>
>>>>> Aug 19 02:51:10 current kernel: info: [drm]   -
>>>>> kern.vt.fb.default_mode
>>>>> Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: get mode
>>>>> from tunables:
>>>>> Aug 19 02:51:10 current kernel: info: [drm]   - kern.vt.fb.modes.DP-1
>>>>> Aug 19 02:51:10 current kernel: info: [drm]   -
>>>>> kern.vt.fb.default_mode
>>>>> Aug 19 02:51:10 current kernel: fbd0 on drmn0
>>>>> Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant locked
>>>>> and may be deleted before>
>>>>> Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" with new
>>> "fb".
>>>
>>>>> ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0
>>>>> 20080730 for drmn0 on minor 0
>>>>>
>>>>> so far so good, quality of text in grafics 1368x1024 is perfectly
>>>>> initialized. but now, when starting xinit or lightdm or sddm or
>>>>> whatever I get a kernel panic:
>>>>>
>>>>> Dump header from device: /dev/ada0p4
>>>>>
>>>>>    Architecture: i386
>>>>>    Architecture Version: 4
>>>>>    Dump Length: 97792
>>>>>    Blocksize: 512
>>>>>    Compression: none
>>>>>    Dumptime: 2020-08-19 02:49:00 +0200
>>>>>    Hostname: current
>>>>>    Magic: FreeBSD Text Dump
>>>>>    Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18 20:18:40
>>>>>
>>>>> CEST 2020
>>>>>
>>>>>      root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA
>>>>>    
>>>>>    Panic String: vm_page_assert_xbusied: page 0x72bd024 not exclusive
>>>>>
>>>>> busy @ /usr/src/sys/vm/vm>
>>>>>
>>>>>    Dump Parity: 2773167169
>>>>>    Bounds: 1
>>>>>    Dump Status: good
>>>>>    
>>>>>    /var/crash/vmcore.0 not found
>>>> Do you have  dumpdev="AUTO" in /etc/rc.conf ?
>>> yes and the directory is /var/crash, but this is all I get as lack of
>>> insufficent memory of dump, it says.
>> Sounds like your swap device is to small. How big is it, and how much
>> memory do you have?
>>
>>>>> First thing I think is kern options:
>>>>>
>>>>> options WITNESS_SKIPSPIN
>>>>> options WITNESS
>>>>>
>>>>> I disabled device HYPERV but this can't be the reason, kern is being
>>>>> compiled with clang.
>>>> Clang is the default since a long time.
>>> depends on gcc++ development in 4D AIs.
>>>
>>> Nothing stops you from using gcc for compiling your programs. Clang is
>> just the default for the OS.
>>
>>>>> To disable WITNESS would be one way I think but this can't be the
>>>>> yellw of the egg, isn't it?
>>>> I use the GENERIC-NODEBUG kernel config which disables WITNESS for some
>>>> performance improvements.
>>> yup. we don't need another debugger. killing insects is murder but when
>>> getting better stuff I never resist to lance them. like housecats with
>>> flys.
>>>
>>>>> Another thing but I guess having nothing to do with bug above is on
>>>>> rather the end of  startup:
>>>>>
>>>>> Aug 19 02:51:10 current savecore[1209]: reboot after panic:
>>>>> vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @
>>>>> /usr/src/sys/vm/vm_page.c:1609
>>>>> Aug 19 02:51:10 current savecore[1209]: writing core to
>>>>> /var/crash/textdump.tar.1
>>>>> Aug 19 02:51:10 current kernel: linsysfs:
>>>>> Aug 19 02:51:10 current kernel: Device busy
>>>>> Aug 19 02:51:10 current kernel: lock order reversal:
>>>>> Aug 19 02:51:10 current kernel:  1st 0x3121e870 ufs (ufs, lockmgr) @
>>>>> /usr/src/sys/kern/vfs_mount.c:1008
>>>>> Aug 19 02:51:10 current kernel:  2nd 0x3121e744 devfs (devfs, lockmgr)
>>>>> @ /usr/src/sys/kern/vfs_mount.c:1019
>>>>> Aug 19 02:51:10 current kernel: lock order devfs -> ufs established
>>>>> at:
>>>>> Aug 19 02:51:10 current kernel: #0 0x1027cd5 at
>>> witness_checkorder+0x3c5
>>>
>>>>> Aug 19 02:51:10 current kernel: #1 0xf9cca0 at
>>>>> lockmgr_lock_flags+0x140
>>>>> Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57
>>>>> Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f
>>>>> Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f
>>>>> Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99
>>>>> Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b
>>>>> Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57
>>>>> Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452
>>>>> Aug 19 02:51:10 current kernel: #9 0x10859be at vfs_mountroot+0x4ce
>>>>> Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22
>>>>> Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68
>>>>> Aug 19 02:51:10 current kernel: #12 0xffc0340e at
>>>>> __stop_set_sysinit_set+0xd0a4199e
>>>>> Aug 19 02:51:10 current kernel: lock order ufs -> devfs attempted at:
>>>>> Aug 19 02:51:10 current kernel: #0 0x1028360 at
>>> witness_checkorder+0xa50
>>>
>>>>> Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46
>>>>> Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a
>>>>> Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f
>>>>> Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f
>>>>> Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99
>>>>> Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b
>>>>> Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d
>>>>> Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195
>>>>> Aug 19 02:51:10 current kernel: #9 0xffc033f9 at
>>>>> __stop_set_sysinit_set+0xd0a41989
>>>>>
>>>>> any ideas?
>>>>> Miranda
>>>>>
>>>>>
>>>>>
>>>>> does someone know how to fix it?
>>>>>
>>>>> Miranda
>>>> Hope this helps.
>>> It does!
>>>
>>>> Best regards
>>>> Andreas Nilsson
>>> Yours,
>>> Miranda van Breukelingen
>>>
>>>
>>> Best regards
>> Andreas Nilsson
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 20 Aug 2020 16:58:25 +0200
>> From: "Vanbreukelingen Ltd." <[hidden email]>
>> To: Andreas Nilsson <[hidden email]>, [hidden email]
>> Subject: Re: funny thing with the drm0
>> Message-ID: <[hidden email]>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> On 2020-08-20 16:43, Andreas Nilsson wrote:
>>> On Thu, Aug 20, 2020 at 2:48 PM Vanbreukelingen Ltd.
>>>
>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>      On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote:
>>>      > On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D <
>>>      >
>>>      > [hidden email]
>>>      
>>>      <mailto:[hidden email]>> wrote:
>>>      > > After having had some near-death-experiences in Greece I'm
>>>      
>>>      back to my
>>>      
>>>      > > screens. As horizon arises, BSD gets up --- and if it is 3
>>>      
>>>      a.m.! :-)
>>>      
>>>      > > But this is the experience with my Dell Vostro on 13 current:
>>>      > >
>>>      > >
>>>      > > After finally recompiling the kernel with the drm-module
>>>      
>>>      inside and
>>>      
>>>      > > the trick of injecting the
>>>      >
>>>      > This is not the way to do it. Modern hardware require drm-kmod
>>>      
>>>      from ports,
>>>      
>>>      > or if you want the latest drm-devel-kmod. Then add
>>>      
>>>      /boot/modules/drm.ko
>>>      
>>>      > and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf
>>>      
>>>      wasn't yet finished (c [see] beyond), but I guess I have to
>>>      disable the whole
>>>      output with something like hw.*=1 or so. is it possible to make a
>>>      bootlogo
>>>      while VEBOSE output = 2 just for the reason some kids try to play
>>>      with it.
>> tried it now: next kernel panic on lightdm and sddm makes a mouse in
>> mouse pointer over a blank screen. the driver is initialised but hungs
>> up like this:
>>
>> Dump header from device: /dev/ada0p4
>>   ? Architecture: i386
>>   ? Architecture Version: 4
>>   ? Dump Length: 97792
>>   ? Blocksize: 512
>>   ? Compression: none
>>   ? Dumptime: 2020-08-20 16:41:45 +0200
>>   ? Hostname: current
>>   ? Magic: FreeBSD Text Dump
>>   ? Version String: FreeBSD 13.0-CURRENT #3 r364372: Wed Aug 19 07:54:57
>> CEST 2020
>>   ??? root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA
>> *Panic String: vm_page_assert_xbusied: page 0x6f47814 not exclusive busy
>> @ /usr/src/sys/vm/vm_page.c:1609**
>> **? Dump Parity: 4227235352*
>>   ? Bounds: 2
>>   ? Dump Status: good
>>
>>>      > > device IWNFW
>>>      
>>>      doesn't install the 6000, btw --- probably can't find FW on device
>>>      HAL.
>>>      
>>>      > Again, this is not needed, firmware is autoloaded on module
>>>      
>>>      load. Just add
>>>      
>>>      > if_iwn to kld_list in /etc/rc.conf
>>>
>>> Here I admit I was wrong, iwn handles it differently than iwm. The man
>>> page lists 3 different firmware versions for the 6000 series, which
>>> can be loaded from loader.conf
>> When compiling DEVICE iwnfb into kern: mine (iwn6000g2bfw) doesn't load
>> probably at bootup but with wpa_supplicant -d BSD -i wlan0 -c
>> /etc/wpa_supplicant.conf it loads correctly and automatically assigns an
>> IP.
>>
>>>      built 15 hours of NanoBSD while finishing the nightly built
>>>      someone was on
>>>      Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at
>>>      all but some
>>>      reason tells me behind this system in system is something to beat
>>>      beastie in
>>>      killing KFC forks.
>>>      
>>>      > > I get a *nice* message a bootup:
>>>      > >
>>>      > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm
>>>      
>>>      1.1.0 20060810
>>>      
>>>      > > Aug 19 02:51:10 current kernel: drmn0: <Intel SandyBridge (M)>
>>>      
>>>      on vgapci0
>>>      
>>>      > > Aug 19 02:51:10 current kernel: info: [drm] Memory usable by
>>>      
>>>      graphics
>>>      
>>>      > > device = 2048M
>>>      > > Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation
>>>      
>>>      failed.
>>>      
>>>      > > Graphics performance may suffer.
>>>      > > Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0
>>>      > > Aug 19 02:51:10 current kernel: iicbus0: <Philips I2C bus> on
>>>      > > iicbb_nostop0 addr 0x1
>>>      > > Aug 19 02:51:10 current kernel: iic0: <I2C generic I/O> on iicbus0
>>>      > > Aug 19 02:51:10 current kernel: iicbus1: <Philips I2C bus> on
>>>      
>>>      intel_gmbus0
>>>      
>>>      > > Aug 19 02:51:10 current kernel: iic1: <I2C generic I/O> on iicbus1
>>>      > > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0
>>>      > > Aug 19 02:51:10 current kernel: iicbus2: <Philips I2C bus> on
>>>      > > iicbb_nostop1 addr 0x12
>>>      > > Aug 19 02:51:10 current kernel: iic2: <I2C generic I/O> on iicbus2
>>>      > > Aug 19 02:51:10 current kernel: iicbus3: <Philips I2C bus> on
>>>      
>>>      intel_gmbus1
>>>      
>>>      > > Aug 19 02:51:10 current kernel: iic3: <I2C generic I/O> on iicbus3
>>>      > > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0
>>>      > > Aug 19 02:51:10 current kernel: iicbus4: <Philips I2C bus> on
>>>      > > iicbb_nostop2 addr 0x12
>>>      > > Aug 19 02:51:10 current kernel: iic4: <I2C generic I/O> on iicbus4
>>>      > > Aug 19 02:51:10 current kernel: iicbus5: <Philips I2C bus> on
>>>      
>>>      intel_gmbus2
>>>      
>>>      > > Aug 19 02:51:10 current kernel: iic5: <I2C generic I/O> on iicbus5
>>>      > > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0
>>>      > > Aug 19 02:51:10 current kernel: iicbus6: <Philips I2C bus> on
>>>      > > iicbb_nostop3 addr 0x12
>>>      > > Aug 19 02:51:10 current kernel: iic6: <I2C generic I/O> on iicbus6
>>>      > > Aug 19 02:51:10 current kernel: iicbus7: <Philips I2C bus> on
>>>      
>>>      intel_gmbus3
>>>      
>>>      > > Aug 19 02:51:10 current kernel: iic7: <I2C generic I/O> on iicbus7
>>>      > > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0
>>>      > > Aug 19 02:51:10 current kernel: iicbus8: <Philips I2C bus> on
>>>      > > iicbb_nostop4 addr 0x12
>>>      > > Aug 19 02:51:10 current kernel: iic8: <I2C generic I/O> on iicbus8
>>>      > > Aug 19 02:51:10 current kernel: iicbus9: <Philips I2C bus> on
>>>      
>>>      intel_gmbus4
>>>      
>>>      > > Aug 19 02:51:10 current kernel: iic9: <I2C generic I/O> on iicbus9
>>>      > > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0
>>>      > > Aug 19 02:51:10 current kernel: iicbus10: <Philips I2C bus> on
>>>      > > iicbb_nostop5 addr 0x12
>>>      > >
>>>      > > And furthermore:
>>>      > >
>>>      > > Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1
>>>      
>>>      message(s)
>>>      
>>>      > > Aug 19 02:51:10 current kernel: info: [drm] Supports vblank
>>>      
>>>      timestamp
>>>      
>>>      > > caching Rev 1 (10.10.201>
>>>      > > Aug 19 02:51:10 current kernel: info: [drm] Driver supports
>>>      
>>>      precise
>>>      
>>>      > > vblank timestamp query.
>>>      > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on
>>>      
>>>      drmn0
>>>      
>>>      > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920:
>>>      detached
>>>      
>>>      > > Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0
>>>      > > Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious
>>>      > > range 0xe0000000-0xf0000000
>>>      
>>>      > > Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1:
>>>      get mode
>>>      
>>>      > > from tunables:
>>>      > > Aug 19 02:51:10 current kernel: info: [drm]? ?-
>>>      
>>>      kern.vt.fb.modes.LVDS-1
>>>      
>>>      > > Aug 19 02:51:10 current kernel: info: [drm]? ?-
>>>      
>>>      kern.vt.fb.default_mode
>>>      
>>>      > > Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1:
>>>      get mode
>>>      
>>>      > > from tunables:
>>>      > > Aug 19 02:51:10 current kernel: info: [drm]? ?-
>>>      
>>>      kern.vt.fb.modes.VGA-1
>>>      
>>>      > > Aug 19 02:51:10 current kernel: info: [drm]? ?-
>>>      
>>>      kern.vt.fb.default_mode
>>>      
>>>      > > Aug 19 02:51:10 current kernel: info: [drm] Connector
>>>      
>>>      HDMI-A-1: get
>>>      
>>>      > > mode from tunables:
>>>      > > Aug 19 02:51:10 current kernel: info: [drm]? ?-
>>>      
>>>      kern.vt.fb.modes.HDMI-A-1
>>>      
>>>      > > Aug 19 02:51:10 current kernel: info: [drm]? ?-
>>>      
>>>      kern.vt.fb.default_mode
>>>      
>>>      > > Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1:
>>>      get mode
>>>      
>>>      > > from tunables:
>>>      > > Aug 19 02:51:10 current kernel: info: [drm]? ?-
>>>      
>>>      kern.vt.fb.modes.DP-1
>>>      
>>>      > > Aug 19 02:51:10 current kernel: info: [drm]? ?-
>>>      
>>>      kern.vt.fb.default_mode
>>>      
>>>      > > Aug 19 02:51:10 current kernel: fbd0 on drmn0
>>>      > > Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant
>>>      
>>>      locked
>>>      
>>>      > > and may be deleted before>
>>>      > > Aug 19 02:51:10 current kernel: VT: Replacing driver "vga"
>>>      
>>>      with new "fb".
>>>      
>>>      > > ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0
>>>      > > 20080730 for drmn0 on minor 0
>>>      > >
>>>      > > so far so good, quality of text in grafics 1368x1024 is perfectly
>>>      > > initialized. but now, when starting xinit or lightdm or sddm or
>>>      > > whatever I get a kernel panic:
>>>      > >
>>>      > > Dump header from device: /dev/ada0p4
>>>      > >
>>>      > >? ?Architecture: i386
>>>      > >? ?Architecture Version: 4
>>>      > >? ?Dump Length: 97792
>>>      > >? ?Blocksize: 512
>>>      > >? ?Compression: none
>>>      > >? ?Dumptime: 2020-08-19 02:49:00 +0200
>>>      > >? ?Hostname: current
>>>      > >? ?Magic: FreeBSD Text Dump
>>>      > >? ?Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18
>>>      
>>>      20:18:40
>>>      
>>>      > > CEST 2020
>>>      > >
>>>      > > ?root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA
>>>      > >
>>>      > >? ?Panic String: vm_page_assert_xbusied: page 0x72bd024 not
>>>      
>>>      exclusive
>>>      
>>>      > > busy @ /usr/src/sys/vm/vm>
>>>      > >
>>>      > >? ?Dump Parity: 2773167169
>>>      > >? ?Bounds: 1
>>>      > >? ?Dump Status: good
>>>      > >
>>>      > >? ?/var/crash/vmcore.0 not found
>>>      >
>>>      > Do you have? dumpdev="AUTO" in /etc/rc.conf ?
>>>      
>>>      yes and the directory is /var/crash, but this is all I get as lack of
>>>      insufficent memory of dump, it says.
>>>
>>> Sounds like your swap device is to small. How big is it, and how much
>>> memory do you have?
>>>
>>>      > > First thing I think is kern options:
>>>      > >
>>>      > > options WITNESS_SKIPSPIN
>>>      > > options WITNESS
>>>      > >
>>>      > > I disabled device HYPERV but this can't be the reason, kern is
>>>      
>>>      being
>>>      
>>>      > > compiled with clang.
>>>      >
>>>      > Clang is the default since a long time.
>>>      
>>>      depends on gcc++ development in 4D AIs.
>>>
>>> Nothing stops you from using gcc for compiling your programs. Clang is
>>> just the default for the OS.
>>>
>>>      > > To disable WITNESS would be one way I think but this can't be the
>>>      > > yellw of the egg, isn't it?
>>>      >
>>>      > I use the GENERIC-NODEBUG kernel config which disables WITNESS
>>>      
>>>      for some
>>>      
>>>      > performance improvements.
>>>      
>>>      yup. we don't need another debugger. killing insects is murder but
>>>      when
>>>      getting better stuff I never resist to lance them. like housecats
>>>      with flys.
>>>      
>>>      > > Another thing but I guess having nothing to do with bug above
>>>      
>>>      is on
>>>      
>>>      > > rather the end of? startup:
>>>      > >
>>>      > > Aug 19 02:51:10 current savecore[1209]: reboot after panic:
>>>      > > vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @
>>>      > > /usr/src/sys/vm/vm_page.c:1609
>>>      > > Aug 19 02:51:10 current savecore[1209]: writing core to
>>>      > > /var/crash/textdump.tar.1
>>>      > > Aug 19 02:51:10 current kernel: linsysfs:
>>>      > > Aug 19 02:51:10 current kernel: Device busy
>>>      > > Aug 19 02:51:10 current kernel: lock order reversal:
>>>      > > Aug 19 02:51:10 current kernel:? 1st 0x3121e870 ufs (ufs,
>>>      
>>>      lockmgr) @
>>>      
>>>      > > /usr/src/sys/kern/vfs_mount.c:1008
>>>      > > Aug 19 02:51:10 current kernel:? 2nd 0x3121e744 devfs (devfs,
>>>      
>>>      lockmgr)
>>>      
>>>      > > @ /usr/src/sys/kern/vfs_mount.c:1019
>>>      > > Aug 19 02:51:10 current kernel: lock order devfs -> ufs
>>>      
>>>      established at:
>>>      > > Aug 19 02:51:10 current kernel: #0 0x1027cd5 at
>>>      
>>>      witness_checkorder+0x3c5
>>>      
>>>      > > Aug 19 02:51:10 current kernel: #1 0xf9cca0 at
>>>      
>>>      lockmgr_lock_flags+0x140
>>>      
>>>      > > Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57
>>>      > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f
>>>      > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f
>>>      > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99
>>>      > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b
>>>      > > Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57
>>>      > > Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452
>>>      > > Aug 19 02:51:10 current kernel: #9 0x10859be at
>>>      
>>>      vfs_mountroot+0x4ce
>>>      
>>>      > > Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22
>>>      > > Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68
>>>      > > Aug 19 02:51:10 current kernel: #12 0xffc0340e at
>>>      > > __stop_set_sysinit_set+0xd0a4199e
>>>      > > Aug 19 02:51:10 current kernel: lock order ufs -> devfs
>>>      
>>>      attempted at:
>>>      > > Aug 19 02:51:10 current kernel: #0 0x1028360 at
>>>      
>>>      witness_checkorder+0xa50
>>>      
>>>      > > Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46
>>>      > > Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a
>>>      > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f
>>>      > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f
>>>      > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99
>>>      > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b
>>>      > > Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d
>>>      > > Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195
>>>      > > Aug 19 02:51:10 current kernel: #9 0xffc033f9 at
>>>      > > __stop_set_sysinit_set+0xd0a41989
>>>      > >
>>>      > > any ideas?
>>>      > > Miranda
>>>      > >
>>>      > >
>>>      > >
>>>      > > does someone know how to fix it?
>>>      > >
>>>      > > Miranda
>>>      >
>>>      > Hope this helps.
>>>      
>>>      It does!
>>>      
>>>      > Best regards
>>>      > Andreas Nilsson
>>>      
>>>      Yours,
>>>      Miranda van Breukelingen
>>>
>>> Best regards
>>> Andreas Nilsson
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 20 Aug 2020 12:05:45 -0500
>> From: Eric van Gyzen <[hidden email]>
>> To: [hidden email], [hidden email]
>> Subject: LOR: tun_ioctl after tun_mtx
>> Message-ID: <[hidden email]>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> I see this LOR on head r364364 while running the tcptestsuite
>> (ports/net/tcptestsuite).  In fact, I interrupted a test with Ctrl-C,
>> and got a panic.  I assume it's the same, since the test was twiddling
>> the MTU, but I haven't looked closely.
>>
>> Eric
>>
>> lock order reversal: (sleepable after non-sleepable)
>>    1st 0xfffff802238ea690 tun_mtx (tun_mtx, sleep mutex) @
>> /usr/src/sys/net/if_tuntap.c:1628
>>    2nd 0xffffffff81d99d28 tun_ioctl (tun_ioctl, sx) @
>> /usr/src/sys/net/if_tuntap.c:1326
>> lock order tun_ioctl -> tun_mtx established at:
>> #0 0xffffffff80c432dd at witness_checkorder+0x46d
>> #1 0xffffffff80bb38e4 at __mtx_lock_flags+0x94
>> #2 0xffffffff80cfad2b at tuninit+0x4b
>> #3 0xffffffff80cfa44f at tunifioctl+0x6f
>> #4 0xffffffff80dc398f at in6_update_ifa+0xa8f
>> #5 0xffffffff80dc96f0 at in6_ifattach+0x5b0
>> #6 0xffffffff80dc577e at in6_if_up+0x7e
>> #7 0xffffffff80ceb289 at if_up+0x69
>> #8 0xffffffff80cec2f7 at ifhwioctl+0xd07
>> #9 0xffffffff80ced475 at ifioctl+0x395
>> #10 0xffffffff80c490ae at kern_ioctl+0x28e
>> #11 0xffffffff80c48d77 at sys_ioctl+0x127
>> #12 0xffffffff81015820 at amd64_syscall+0x140
>> #13 0xffffffff80febb3e at fast_syscall_common+0xf8
>> lock order tun_mtx -> tun_ioctl attempted at:
>> #0 0xffffffff80c43c3c at witness_checkorder+0xdcc
>> #1 0xffffffff80be0247 at _sx_xlock+0x67
>> #2 0xffffffff80cfa411 at tunifioctl+0x31
>> #3 0xffffffff80ceba5b at ifhwioctl+0x46b
>> #4 0xffffffff80cf9101 at tunioctl+0x5b1
>> #5 0xffffffff80a7b0fc at devfs_ioctl+0xcc
>> #6 0xffffffff80cc9bf2 at vn_ioctl+0x132
>> #7 0xffffffff80a7b76e at devfs_ioctl_f+0x1e
>> #8 0xffffffff80c490ae at kern_ioctl+0x28e
>> #9 0xffffffff80c48d77 at sys_ioctl+0x127
>> #10 0xffffffff81015820 at amd64_syscall+0x140
>> #11 0xffffffff80febb3e at fast_syscall_common+0xf8
>>
>> local/tcptestsuite/tcptestsuite_atf_test:snd_syn_mss_inherited_from_mtu_72_i
>> pv4 ->  ^C[-- Signal caught; please wait for cleanup --]
>>
>> Sleeping thread (tid 100505, pid 61414) owns a non-sleepable lock
>> KDB: stack backtrace of thread 100505:
>> sched_switch() at sched_switch+0x5b2/frame 0xfffffe00627165a0
>> mi_switch() at mi_switch+0x155/frame 0xfffffe00627165c0
>> sleepq_switch() at sleepq_switch+0x109/frame 0xfffffe0062716600
>> _sx_xlock_hard() at _sx_xlock_hard+0x42e/frame 0xfffffe00627166a0
>> _sx_xlock() at _sx_xlock+0xba/frame 0xfffffe00627166e0
>> tunifioctl() at tunifioctl+0x31/frame 0xfffffe0062716720
>> ifhwioctl() at ifhwioctl+0x46b/frame 0xfffffe00627167a0
>> tunioctl() at tunioctl+0x5b1/frame 0xfffffe0062716810
>> devfs_ioctl() at devfs_ioctl+0xcc/frame 0xfffffe0062716860
>> vn_ioctl() at vn_ioctl+0x132/frame 0xfffffe0062716970
>> devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfffffe0062716990
>> kern_ioctl() at kern_ioctl+0x28e/frame 0xfffffe0062716a00
>> sys_ioctl() at sys_ioctl+0x127/frame 0xfffffe0062716ad0
>> amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe0062716bf0
>> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0062716bf0
>> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8005818fa, rsp =
>> 0x7fffffffd408, rbp = 0x7fffffffd540 ---
>> panic: sleeping thread
>> cpuid = 4
>> time = 1597942792
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> 0xfffffe00652545e0
>> vpanic() at vpanic+0x182/frame 0xfffffe0065254630
>> panic() at panic+0x43/frame 0xfffffe0065254690
>> propagate_priority() at propagate_priority+0x219/frame 0xfffffe00652546d0
>> turnstile_wait() at turnstile_wait+0x380/frame 0xfffffe0065254720
>> __mtx_lock_sleep() at __mtx_lock_sleep+0x1cc/frame 0xfffffe00652547b0
>> __mtx_lock_flags() at __mtx_lock_flags+0xe5/frame 0xfffffe0065254800
>> tunifioctl() at tunifioctl+0xdc/frame 0xfffffe0065254840
>> ifhwioctl() at ifhwioctl+0x2b1/frame 0xfffffe00652548c0
>> ifioctl() at ifioctl+0x395/frame 0xfffffe0065254990
>> kern_ioctl() at kern_ioctl+0x28e/frame 0xfffffe0065254a00
>> sys_ioctl() at sys_ioctl+0x127/frame 0xfffffe0065254ad0
>> amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe0065254bf0
>> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0065254bf0
>> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004b48fa, rsp =
>> 0x7fffffffd428, rbp = 0x7fffffffdc50 ---
>> KDB: enter: panic
>> [ thread pid 61418 tid 100573 ]
>> Stopped at      kdb_enter+0x37: movq    $0,0x10b70b6(%rip)
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Thu, 20 Aug 2020 16:41:59 -0500
>> From: Clay Daniels <[hidden email]>
>> To: "[hidden email]" <[hidden email]>
>> Subject: Weekly Current 13.0 Snapshot?
>> Message-ID:
>> <CAGLDxTWTrku-BAcaaEgeA_hi-
> zQ3fz80=[hidden email]>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> I hope nobody is ill & just busy filling the weekly snapshot of 13.0
>> Current with new goodies. I don't see it at it's usual location:
>>
>> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/
>>
>> Clay
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Thu, 20 Aug 2020 21:47:06 +0000
>> From: Glen Barber <[hidden email]>
>> To: Clay Daniels <[hidden email]>
>> Cc: "[hidden email]" <[hidden email]>
>> Subject: Re: Weekly Current 13.0 Snapshot?
>> Message-ID: <[hidden email]>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote:
>>> I hope nobody is ill & just busy filling the weekly snapshot of 13.0
>>> Current with new goodies. I don't see it at it's usual location:
>>>
>>> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/
>> Not ill, but indeed sick of the build being broken so much.
>>
>> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.htm
>> l
>>
>> Glen
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: signature.asc
>> Type: application/pgp-signature
>> Size: 833 bytes
>> Desc: not available
>> URL:
>> <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20200820/db
>> dfc32d/attachment-0001.sig>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Thu, 20 Aug 2020 15:54:37 -0600
>> From: Warner Losh <[hidden email]>
>> To: Glen Barber <[hidden email]>
>> Cc: Clay Daniels <[hidden email]>,
>> "[hidden email]" <[hidden email]>
>> Subject: Re: Weekly Current 13.0 Snapshot?
>> Message-ID:
>>
> <CANCZdfq=-[hidden email]>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber <[hidden email]> wrote:
>>> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote:
>>>> I hope nobody is ill & just busy filling the weekly snapshot of 13.0
>>>> Current with new goodies. I don't see it at it's usual location:
>>>>
>>>> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/
>>> Not ill, but indeed sick of the build being broken so much.
>>>
>>>
>>> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.h
>>> tml
>> Build isn't broken now, can't you just run it again?
>>
>> Warner
>>
>>
>> ------------------------------
>>
>> Message: 8
>> Date: Thu, 20 Aug 2020 18:38:58 -0400
>> From: Glen Barber <[hidden email]>
>> To: Warner Losh <[hidden email]>
>> Cc: Clay Daniels <[hidden email]>,
>> "[hidden email]" <[hidden email]>
>> Subject: Re: Weekly Current 13.0 Snapshot?
>> Message-ID: <[hidden email]>
>> Content-Type: text/plain; charset=utf-8
>>
>> Not without putting a wedge in place with updating scripts for the git
>> conversion, which as you know, I am already past the deadline.
>>
>> Glen
>> Sent from my phone.
>> Please excuse my brevity and/or typos.
>>
>>> On Aug 20, 2020, at 5:54 PM, Warner Losh <[hidden email]> wrote:
>>>
>>> ?
>>>
>>>> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber <[hidden email]> wrote:
>>>>
>>>> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote:
>>>>> I hope nobody is ill & just busy filling the weekly snapshot of 13.0
>>>>> Current with new goodies. I don't see it at it's usual location:
>>>>>
>>>>> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/
>>>> Not ill, but indeed sick of the build being broken so much.
>>>>
>>>> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.
>>>> html>
>>> Build isn't broken now, can't you just run it again?
>>>
>>> Warner
>> ------------------------------
>>
>> Message: 9
>> Date: Thu, 20 Aug 2020 18:43:19 -0500
>> From: Clay Daniels <[hidden email]>
>> To: Glen Barber <[hidden email]>
>> Cc: Warner Losh <[hidden email]>,  "[hidden email]"
>> <[hidden email]>
>> Subject: Re: Weekly Current 13.0 Snapshot?
>> Message-ID:
>> <CAGLDxTUo8XMh-ZfjBLs_E-
> WN251hqAb9JEwUwicSPR=[hidden email]>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> Sorry to bug you. I didn't even know about the snapshot email list, but I
>> have just subscribed and will know next time. Do what you need to and don't
>> worry about the snapshot this week. I too am busy this week and have plenty
>> to do.
>>
>> Clay
>>
>> On Thu, Aug 20, 2020 at 5:39 PM Glen Barber <[hidden email]> wrote:
>>> Not without putting a wedge in place with updating scripts for the git
>>> conversion, which as you know, I am already past the deadline.
>>>
>>> Glen
>>> Sent from my phone.
>>> Please excuse my brevity and/or typos.
>>>
>>> On Aug 20, 2020, at 5:54 PM, Warner Losh <[hidden email]> wrote:
>>>
>>> ?
>>>
>>> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber <[hidden email]> wrote:
>>>> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote:
>>>>> I hope nobody is ill & just busy filling the weekly snapshot of 13.0
>>>>> Current with new goodies. I don't see it at it's usual location:
>>>>>
>>>>> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/
>>>> Not ill, but indeed sick of the build being broken so much.
>>>>
>>>>
>>>> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.
>>>> html>
>>> Build isn't broken now, can't you just run it again?
>>>
>>> Warner
>> ------------------------------
>>
>> Message: 10
>> Date: Thu, 20 Aug 2020 19:48:23 -0400
>> From: Glen Barber <[hidden email]>
>> To: Clay Daniels <[hidden email]>
>> Cc: Warner Losh <[hidden email]>, "[hidden email]"
>> <[hidden email]>
>> Subject: Re: Weekly Current 13.0 Snapshot?
>> Message-ID: <[hidden email]>
>> Content-Type: text/plain; charset=utf-8
>>
>> Not bugging at all.
>>
>> I?m hoping that the state that machine is in now, with some sanding off some
>> newly-discovered rough edges of some code changes, to have snapshots from
>> git before Wednesday.
>>
>> Fingers crossed....
>>
>> Glen
>> Sent from my phone.
>> Please excuse my brevity and/or typos.
>>
>>> On Aug 20, 2020, at 7:43 PM, Clay Daniels <[hidden email]>
>>> wrote:
>>>
>>> ?
>>> Sorry to bug you. I didn't even know about the snapshot email list, but I
>>> have just subscribed and will know next time. Do what you need to and
>>> don't worry about the snapshot this week. I too am busy this week and
>>> have plenty to do.
>>>
>>> Clay
>>>
>>>> On Thu, Aug 20, 2020 at 5:39 PM Glen Barber <[hidden email]> wrote:
>>>> Not without putting a wedge in place with updating scripts for the git
>>>> conversion, which as you know, I am already past the deadline.
>>>>
>>>> Glen
>>>> Sent from my phone.
>>>> Please excuse my brevity and/or typos.
>>>>
>>>>>> On Aug 20, 2020, at 5:54 PM, Warner Losh <[hidden email]> wrote:
>>>>> ?
>>>>>
>>>>>> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber <[hidden email]> wrote:
>>>>>>
>>>>>> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote:
>>>>>>> I hope nobody is ill & just busy filling the weekly snapshot of 13.0
>>>>>>> Current with new goodies. I don't see it at it's usual location:
>>>>>>>
>>>>>>> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.
>>>>>>> 0/
>>>>>> Not ill, but indeed sick of the build being broken so much.
>>>>>>
>>>>>> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/00073
>>>>>> 9.html>>>
>>>>> Build isn't broken now, can't you just run it again?
>>>>>
>>>>> Warner
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> [hidden email] mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "[hidden email]"
>>
>>
>> ------------------------------
>>
>> End of freebsd-current Digest, Vol 877, Issue 6
>> ***********************************************
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 21 Aug 2020 11:52:23 -0700
> From: Mark Millard <[hidden email]>
> To: FreeBSD Current <[hidden email]>, FreeBSD Toolchain
> <[hidden email]>
> Cc: freebsd-arm <[hidden email]>
> Subject: /usr/lib/libomp.so : is there a reason that aarch64 does not
> have such by default?
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=us-ascii
>
> My context: head ( currently at -r363590 )
>
> man src.conf is explicit that WITHOUT_OPENMP is the default for
> aarch64 (for example).
>
> But I note that https://openmp.llvm.org/README.txt says:
> (it has the more detailed breakdown of OS/compiler combinations
> for architectures where it matters)
>
> QUOTE
> Architectures Supported
> =======================
> * IA-32 architecture
> * Intel(R) 64 architecture
> * Intel(R) Many Integrated Core Architecture
> * ARM* architecture
> * Aarch64 (64-bit ARM) architecture
> * IBM(R) Power architecture (big endian)
> * IBM(R) Power architecture (little endian)
> * MIPS and MIPS64 architectures
> * RISC-V 64 bit architecture
>
> Supported RTL Build Configurations
> ==================================
>
> Supported Architectures: IA-32 architecture, Intel(R) 64, and
> Intel(R) Many Integrated Core Architecture
>
>                ----------------------------------------------
>                |   icc/icl     |    gcc      |   clang      |
> --------------|---------------|----------------------------|
> | Linux* OS   |   Yes(1,5)    |  Yes(2,4)   | Yes(4,6,7)   |
> | FreeBSD*    |   No          |  No         | Yes(4,6,7,8) |
> | OS X*       |   Yes(1,3,4)  |  No         | Yes(4,6,7)   |
> | Windows* OS |   Yes(1,4)    |  No         | No           |
> ------------------------------------------------------------
> . . .
> (7) Clang* currently does not offer a software-implemented 128 bit extended
>      precision type.  Thus, all entry points reliant on this type are removed
>      from the library and cannot be called in the user program.  The following
>      functions are not available:
>      __kmpc_atomic_cmplx16_*
>      __kmpc_atomic_float16_*
>      __kmpc_atomic_*_fp
> . . .
> Supported Architectures: IBM(R) Power 7 and Power 8
>
>                -----------------------------
>                |   gcc      |   clang      |
> --------------|------------|--------------|
> | Linux* OS   |  Yes(1,2)  | Yes(3,4)     |
> -------------------------------------------
> . . .
> ENDQUOTE
>
> Nothing stands out for why WITH_OPENMP is in use by default only
> for amd64, i386, and powerpc64.
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 21 Aug 2020 21:19:04 +0000
> From: Li-Wen Hsu <[hidden email]>
> To: [hidden email]
> Cc: [hidden email], [hidden email]
> Subject: FreeBSD CI Weekly Report 2020-08-16
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=us-ascii
>
> (Please send the followup to freebsd-testing@ and note Reply-To is set.)
>
> FreeBSD CI Weekly Report 2020-08-16
> ===================================
>
> Here is a summary of the FreeBSD Continuous Integration results for the period
> from 2020-08-10 to 2020-08-16.
>
> During this period, we have:
>
> * 2008 builds (93.7% (-0.3) passed, 6.3% (+0.3) failed) of buildworld and
>    buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6,
>    armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64,
>    sparc64 architectures for head, stable/12, stable/11 branches.
> * 229 test runs (87.8% (-8.6) passed, 11.8% (+8.7) unstable, 0.4% (-0.1)
>    exception) were executed on amd64, i386, riscv64 architectures for head,
>    stable/12, stable/11 branches.
> * 100 doc and www builds (100% (+0) passed)
>
> Test case status (on 2020-08-16 23:59):
> | Branch/Architecture | Total      | Pass      | Fail     | Skipped |
> | ------------------- | ---------- | --------- | -------- | ------- |
> | head/amd64          | 7894 (+20) | 7786 (+2) | 18 (+18) | 90 (0)  |
> | head/i386           | 7892 (+20) | 7777 (+5) | 18 (+18) | 97 (-3) |
> | 12-STABLE/amd64     | 7620 (0)   | 7563 (+3) | 0 (0)    | 57 (-3) |
> | 12-STABLE/i386      | 7618 (0)   | 7550 (0)  | 0 (0)    | 68 (0)  |
> | 11-STABLE/amd64     | 6912 (0)   | 6858 (-3) | 0 (0)    | 54 (+3) |
> | 11-STABLE/i386      | 6910 (0)   | 6854 (0)  | 0 (0)    | 56 (0)  |
>
> (The statistics from experimental jobs are omitted)
>
> If any of the issues found by CI are in your area of interest or expertise
> please investigate the PRs listed below.
>
> The latest web version of this report is available at
> https://hackmd.io/@FreeBSD-CI/report-20200816 and archive is available at
> https://hackmd.io/@FreeBSD-CI/ , any help is welcomed.
>
> ## Failing jobs
>
> * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/
>    There are still mutiple errors when building with gcc6, error log available at
>    https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/lastCompletedBuild/console
>    
> ## Regressions
>
> * lib.libexecinfo.backtrace_test.backtrace_fmt_basic starts failing on amd64 after r360915
>    https://bugs.freebsd.org/246537
>
> * lib.msun.ctrig_test.test_inf_inputs starts failing after llvm10 import
>    https://bugs.freebsd.org/244732
>    Needs to check if llvm11 import fixes this.
>
> * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386
>    https://bugs.freebsd.org/244163
>    Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857))
>    
> * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel
>    https://bugs.freebsd.org/244168
>    Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857))
>    Fix committed as https://svnweb.freebsd.org/changeset/base/364220 , needs more verification.
>    
> ## Failing and Flaky tests (from experimental jobs)
>
> * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/
>      * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d
>          * https://bugs.freebsd.org/237641
>
> * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/
>      * There are ~13 failing and ~109 skipped cases, including flakey ones, see
>        https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details
>      * Work for cleaning these failing cass are in progress
>      * Work on running these tests over OpenZFS is in progress
>
> * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/
>      * Total 3749 tests, 2277 success, 647 failures, 825 skipped
>
> ## Disabled Tests
>
> * sys.fs.tmpfs.mount_test.large
>    https://bugs.freebsd.org/212862
> * sys.fs.tmpfs.link_test.kqueue
>    https://bugs.freebsd.org/213662
> * sys.kqueue.libkqueue.kqueue_test.main
>    https://bugs.freebsd.org/233586
> * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop
>    https://bugs.freebsd.org/220841
> * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only)
>    https://bugs.freebsd.org/237450
> * sys.netinet.socket_afinet.socket_afinet_bind_zero
>    https://bugs.freebsd.org/238781
> * sys.netpfil.pf.names.names
> * sys.netpfil.pf.synproxy.synproxy
>    https://bugs.freebsd.org/238870
> * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger
>    https://bugs.freebsd.org/239292
> * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger
>    https://bugs.freebsd.org/239397
> * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger
>    https://bugs.freebsd.org/239399
> * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger
>    https://bugs.freebsd.org/239425
> * sys.sys.qmath_test.qdivq_s64q
>    https://bugs.freebsd.org/240219
> * sys.kern.ptrace_test.ptrace__getppid
>    https://bugs.freebsd.org/240510
> * lib.libc.sys.stat_test.stat_socket
>    https://bugs.freebsd.org/240621
> * lib.libarchive.functional_test.test_write_filter_zstd
>    https://bugs.freebsd.org/240683
> * lib.libcasper.services.cap_dns.dns_test.main
>    lib.libcasper.services.cap_net.net_test.*
>    https://bugs.freebsd.org/241435
> * local.kyua.* (31 cases) & local.lutok.* (3 cases) on 11-i386
>    https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2278/testReport/
> * sys.kern.ptrace_test.ptrace__procdesc_reparent_wait_child
>    https://bugs.freebsd.org/243605
> * sys.kern.ptrace_test.ptrace__parent_wait_after_attach
>    https://bugs.freebsd.org/244055
> * sys.kern.ptrace_test.ptrace__parent_exits_before_child
>    https://bugs.freebsd.org/244056
> * sys.net.if_lagg_test.witness (i386)
>    https://bugs.freebsd.org/244163
> * PipePdfork.WildcardWait in sys.capsicum.capsicum-test.main
>    https://bugs.freebsd.org/244165
> * sys.net.if_lagg_test.lacp_linkstate_destroy_stress (i386)
>    https://bugs.freebsd.org/244168
> * sys.netinet6.frag6.frag6_07.frag6_07
>    https://bugs.freebsd.org/244170
> * sys.netinet.fibs_test.udp_dontroute6
>    https://bugs.freebsd.org/244172
> * sys.netpfil.pf.nat.exhaust
>    https://bugs.freebsd.org/244703
> * sys.geom.class.gate.ggate_test.ggated (i386)
>    https://bugs.freebsd.org/244737
> * sys.kern.sysv_test.msg
>    https://bugs.freebsd.org/233649
>
> ## Issues
>
> ### Cause build fails
> * https://bugs.freebsd.org/233769
>    Possible build race: ld: error: unable to find library -lgcc_s
>
> ### Cause kernel panics
> * https://bugs.freebsd.org/238870
>    sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic
>
> ### Open
> * https://bugs.freebsd.org/237641
>    Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d
> * https://bugs.freebsd.org/237656
>    "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests
> * https://bugs.freebsd.org/238781
>    sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded
> * https://bugs.freebsd.org/239292
>    Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger
> * https://bugs.freebsd.org/239397
>    Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger
> * https://bugs.freebsd.org/239399
>    Flakey test case: sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger
> * https://bugs.freebsd.org/239425
>    Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger
> * https://bugs.freebsd.org/241662
>    Flakey test case: lib.libarchive.functional_test.test_fuzz_iso9660
> * https://bugs.freebsd.org/246443
>    sys.net.if_clone_test.epair_stress sometimes exceeds timeout limit but not caught by kyua
> * https://bugs.freebsd.org/247510
>    sys.net.if_lagg_test.status_stress panics kernel on i386
>
> ### Others
>
> * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg)
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 21 Aug 2020 23:23:19 +0200
> From: Hans Petter Selasky <[hidden email]>
> To: Alexandre Levy <[hidden email]>
> Cc: [hidden email]
> Subject: Re: Kernel crash during video transcoding
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 2020-08-16 22:23, Alexandre Levy wrote:
>> Any suggestions ?
> Are there any simple steps to reproduce this?
>
> --HPS
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 22 Aug 2020 09:07:55 +0000
> From: myfreeweb <[hidden email]>
> To: Mark Millard <[hidden email]>, FreeBSD Current
> <[hidden email]>, FreeBSD Toolchain
> <[hidden email]>
> Cc: freebsd-arm <[hidden email]>
> Subject: Re: /usr/lib/libomp.so : is there a reason that aarch64 does
> not have such by default?
> Message-ID:
> <[hidden email]>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On August 21, 2020 6:52:23 PM UTC, Mark Millard via freebsd-arm <[hidden email]> wrote:
>> My context: head ( currently at -r363590 )
>>
>> man src.conf is explicit that WITHOUT_OPENMP is the default for
>> aarch64 (for example).
> [...]
>> Nothing stands out for why WITH_OPENMP is in use by default only
>> for amd64, i386, and powerpc64.
> Because nobody has bothered to merge https://reviews.freebsd.org/D21167
>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 22 Aug 2020 11:49:34 +0000
> From: marco <[hidden email]>
> To: freebsd-current <[hidden email]>
> Subject: 13-CURRENT won't boot after switch to sysutils/openzfs
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset="us-ascii"
>
> I'm running r364030.
>
>   [~] uname -apKU
>   FreeBSD harbinger 13.0-CURRENT FreeBSD 13.0-CURRENT #5 r364030: Tue Aug
>   11 07:15:59 UTC 2020
>   root@harbinger:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG  amd64
>   amd64 1300105 1300105
>
> When switching from base ZFS to sysutils/openzfs 2020080800 the boot process fails.
>
> These are the steps I took:
>
> - bectl create r364030-OpenZFS
> - bectl mount r364030-OpenZFS /mnt
> - edit /mnt/boot/loader.conf to use openzfs_load="YES" instead of zfs_load.
> - bectl activate r364030-OpenZFS
> - bectl umount r364030-OpenZFS
> - shutdown -r now
>
> The boot process shows:
> Loader variables:
> vfs.root.mountfrom=zfs:zroot/ROOT/r364030-OpenZFS
>
> But in the end never boots and drops me to the mountroot prompt
> I've tried several options to make it boot but when I just enter (empty
> line) I get the following:
>
> panic: mountroot: unable to (re-)mount root
>
> pls see https://bsd.to/C4yL
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"