Send freebsd-current mailing list submissions to
freebsd-current@freebsd.org
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
freebsd-current-requ...@freebsd.org
You can reach the person managing the list at
freebsd-current-ow...@freebsd.org
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." <lizbethmutterh...@gmail.com>
To: freebsd-current@freebsd.org
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 freebsd-current-requ...@freebsd.org
wrote:
Message: 1
Date: Thu, 20 Aug 2020 08:15:56 +0200
From: "Vanbreukelingen Ltd." <lizbethmutterh...@gmail.com>
To: Current FreeBSD <freebsd-current@freebsd.org>
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 <
lizbethmutterh...@gmail.com> 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 <andrn...@gmail.com>
To: "Vanbreukelingen Ltd." <lizbethmutterh...@gmail.com>, Current
FreeBSD <freebsd-current@freebsd.org>
Subject: Re: funny thing with the drm0
Message-ID:
<CAPS9+SshknntXpCxnNB=Pm+BNJh_+pvJc_z5X5eN6t-
vkka...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Thu, Aug 20, 2020 at 2:48 PM Vanbreukelingen Ltd. <
lizbethmutterh...@gmail.com> 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 <
lizbethmutterh...@gmail.com> 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." <lizbethmutterh...@gmail.com>
To: Andreas Nilsson <andrn...@gmail.com>, freebsd-current@freebsd.org
Subject: Re: funny thing with the drm0
Message-ID: <d9e752b0-fae1-1975-7eac-adb7b43c0...@gmail.com>
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.
<lizbethmutterh...@gmail.com <mailto:lizbethmutterh...@gmail.com>> 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 <
>
> lizbethmutterh...@gmail.com
<mailto:lizbethmutterh...@gmail.com>> 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 <e...@vangyzen.net>
To: curr...@freebsd.org, kev...@freebsd.org
Subject: LOR: tun_ioctl after tun_mtx
Message-ID: <41921dc3-b1e9-b823-12f4-d108319c0...@vangyzen.net>
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 <clay.daniels...@gmail.com>
To: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
Subject: Weekly Current 13.0 Snapshot?
Message-ID:
<CAGLDxTWTrku-BAcaaEgeA_hi-
zQ3fz80=crzgyyqb03hvmt...@mail.gmail.com>
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 <g...@freebsd.org>
To: Clay Daniels <clay.daniels...@gmail.com>
Cc: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
Subject: Re: Weekly Current 13.0 Snapshot?
Message-ID: <20200820214706.gk61...@freebsd.org>
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 <i...@bsdimp.com>
To: Glen Barber <g...@freebsd.org>
Cc: Clay Daniels <clay.daniels...@gmail.com>,
"freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
Subject: Re: Weekly Current 13.0 Snapshot?
Message-ID:
<CANCZdfq=-1sd85uhh0na-8a5kx5t+jaud5gq+pwxdizmo9e...@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Thu, Aug 20, 2020 at 3:47 PM Glen Barber <g...@freebsd.org> 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 <g...@freebsd.org>
To: Warner Losh <i...@bsdimp.com>
Cc: Clay Daniels <clay.daniels...@gmail.com>,
"freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
Subject: Re: Weekly Current 13.0 Snapshot?
Message-ID: <a3173d69-a692-4de1-8037-f5751b434...@freebsd.org>
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 <i...@bsdimp.com> wrote:
?
On Thu, Aug 20, 2020 at 3:47 PM Glen Barber <g...@freebsd.org> 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 <clay.daniels...@gmail.com>
To: Glen Barber <g...@freebsd.org>
Cc: Warner Losh <i...@bsdimp.com>, "freebsd-current@freebsd.org"
<freebsd-current@freebsd.org>
Subject: Re: Weekly Current 13.0 Snapshot?
Message-ID:
<CAGLDxTUo8XMh-ZfjBLs_E-
WN251hqAb9JEwUwicSPR=1k6g...@mail.gmail.com>
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 <g...@freebsd.org> 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 <i...@bsdimp.com> wrote:
?
On Thu, Aug 20, 2020 at 3:47 PM Glen Barber <g...@freebsd.org> 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 <g...@freebsd.org>
To: Clay Daniels <clay.daniels...@gmail.com>
Cc: Warner Losh <i...@bsdimp.com>, "freebsd-current@freebsd.org"
<freebsd-current@freebsd.org>
Subject: Re: Weekly Current 13.0 Snapshot?
Message-ID: <a4b6b6e7-0435-4fe3-a815-e36c14788...@freebsd.org>
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 <clay.daniels...@gmail.com>
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 <g...@freebsd.org> 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 <i...@bsdimp.com> wrote:
?
On Thu, Aug 20, 2020 at 3:47 PM Glen Barber <g...@freebsd.org> 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
_______________________________________________
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"
------------------------------
End of freebsd-current Digest, Vol 877, Issue 6
***********************************************
------------------------------
Message: 2
Date: Fri, 21 Aug 2020 11:52:23 -0700
From: Mark Millard <mark...@yahoo.com>
To: FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Toolchain
<freebsd-toolch...@freebsd.org>
Cc: freebsd-arm <freebsd-...@freebsd.org>
Subject: /usr/lib/libomp.so : is there a reason that aarch64 does not
have such by default?
Message-ID: <2e4e8340-e4c1-4ed4-9e3d-f249d85d1...@yahoo.com>
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 <lw...@freebsd.org>
To: freebsd-test...@freebsd.org
Cc: freebsd-current@freebsd.org, freebsd-sta...@freebsd.org
Subject: FreeBSD CI Weekly Report 2020-08-16
Message-ID: <20200821211904.ga21...@freefall.freebsd.org>
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 <h...@selasky.org>
To: Alexandre Levy <a13xl...@gmail.com>
Cc: freebsd-current@freebsd.org
Subject: Re: Kernel crash during video transcoding
Message-ID: <0ccb28fe-569d-2abb-f94b-f33d6155a...@selasky.org>
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 <greg@unrelenting.technology>
To: Mark Millard <mark...@yahoo.com>, FreeBSD Current
<freebsd-current@freebsd.org>, FreeBSD Toolchain
<freebsd-toolch...@freebsd.org>
Cc: freebsd-arm <freebsd-...@freebsd.org>
Subject: Re: /usr/lib/libomp.so : is there a reason that aarch64 does
not have such by default?
Message-ID:
<90091F80-717F-4405-952B-B6B955AE6E1F@unrelenting.technology>
Content-Type: text/plain; charset=utf-8
On August 21, 2020 6:52:23 PM UTC, Mark Millard via freebsd-arm
<freebsd-...@freebsd.org> 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 <freebsd-curr...@lordsith.net>
To: freebsd-current <freebsd-current@freebsd.org>
Subject: 13-CURRENT won't boot after switch to sysutils/openzfs
Message-ID: <20200822114934.gb40...@lordsith.net>
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
