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, freebsd-current-request_at_freebsd.org wrote: > Send freebsd-current mailing list submissions to > freebsd-current_at_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-request_at_freebsd.org > > You can reach the person managing the list at > freebsd-current-owner_at_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." <lizbethmutterhunt_at_gmail.com> > To: freebsd-current_at_freebsd.org > Subject: Re: freebsd-current Digest, Vol 877, Issue 6 > Message-ID: <2624761.GQDcWxOStt_at_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-request_at_freebsd.org > wrote: > >> Message: 1 >> Date: Thu, 20 Aug 2020 08:15:56 +0200 >> From: "Vanbreukelingen Ltd." <lizbethmutterhunt_at_gmail.com> >> To: Current FreeBSD <freebsd-current_at_freebsd.org> >> Subject: Re: funny thing with the drm0 >> Message-ID: <8073347.hK6j7OjjKr_at_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 < >>>> >>>> lizbethmutterhunt_at_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_at_current:/usr/obj/usr/src/i386.i386/sys/MIRANDA >>>>> >>>>> Panic String: vm_page_assert_xbusied: page 0x72bd024 not exclusive >>>>> >>>>> busy _at_ /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 _at_ >>>>> /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) _at_ >>>>> /usr/src/sys/kern/vfs_mount.c:1008 >>>>> Aug 19 02:51:10 current kernel: 2nd 0x3121e744 devfs (devfs, lockmgr) >>>>> _at_ /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 <andrnils_at_gmail.com> >> To: "Vanbreukelingen Ltd." <lizbethmutterhunt_at_gmail.com>, Current >> FreeBSD <freebsd-current_at_freebsd.org> >> Subject: Re: funny thing with the drm0 >> Message-ID: >> <CAPS9+SshknntXpCxnNB=Pm+BNJh_+pvJc_z5X5eN6t- > VkKAsBQ_at_mail.gmail.com> >> Content-Type: text/plain; charset="UTF-8" >> >> On Thu, Aug 20, 2020 at 2:48 PM Vanbreukelingen Ltd. < >> >> lizbethmutterhunt_at_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 < >>>> >>>> lizbethmutterhunt_at_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_at_current:/usr/obj/usr/src/i386.i386/sys/MIRANDA >>>>> >>>>> Panic String: vm_page_assert_xbusied: page 0x72bd024 not exclusive >>>>> >>>>> busy _at_ /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 _at_ >>>>> /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) _at_ >>>>> /usr/src/sys/kern/vfs_mount.c:1008 >>>>> Aug 19 02:51:10 current kernel: 2nd 0x3121e744 devfs (devfs, lockmgr) >>>>> _at_ /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." <lizbethmutterhunt_at_gmail.com> >> To: Andreas Nilsson <andrnils_at_gmail.com>, freebsd-current_at_freebsd.org >> Subject: Re: funny thing with the drm0 >> Message-ID: <d9e752b0-fae1-1975-7eac-adb7b43c0db8_at_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. >>> >>> <lizbethmutterhunt_at_gmail.com <mailto:lizbethmutterhunt_at_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 < >>> > >>> > lizbethmutterhunt_at_gmail.com >>> >>> <mailto:lizbethmutterhunt_at_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_at_current:/usr/obj/usr/src/i386.i386/sys/MIRANDA >> *Panic String: vm_page_assert_xbusied: page 0x6f47814 not exclusive busy >> _at_ /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_at_current:/usr/obj/usr/src/i386.i386/sys/MIRANDA >>> > > >>> > >? ?Panic String: vm_page_assert_xbusied: page 0x72bd024 not >>> >>> exclusive >>> >>> > > busy _at_ /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 _at_ >>> > > /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) _at_ >>> >>> > > /usr/src/sys/kern/vfs_mount.c:1008 >>> > > Aug 19 02:51:10 current kernel:? 2nd 0x3121e744 devfs (devfs, >>> >>> lockmgr) >>> >>> > > _at_ /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 <eric_at_vangyzen.net> >> To: current_at_freebsd.org, kevans_at_freebsd.org >> Subject: LOR: tun_ioctl after tun_mtx >> Message-ID: <41921dc3-b1e9-b823-12f4-d108319c08d4_at_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) _at_ >> /usr/src/sys/net/if_tuntap.c:1628 >> 2nd 0xffffffff81d99d28 tun_ioctl (tun_ioctl, sx) _at_ >> /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.jr_at_gmail.com> >> To: "freebsd-current_at_freebsd.org" <freebsd-current_at_freebsd.org> >> Subject: Weekly Current 13.0 Snapshot? >> Message-ID: >> <CAGLDxTWTrku-BAcaaEgeA_hi- > zQ3fz80=CRZGyYqb03hvmt2Sw_at_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 <gjb_at_freebsd.org> >> To: Clay Daniels <clay.daniels.jr_at_gmail.com> >> Cc: "freebsd-current_at_freebsd.org" <freebsd-current_at_freebsd.org> >> Subject: Re: Weekly Current 13.0 Snapshot? >> Message-ID: <20200820214706.GK61041_at_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 <imp_at_bsdimp.com> >> To: Glen Barber <gjb_at_freebsd.org> >> Cc: Clay Daniels <clay.daniels.jr_at_gmail.com>, >> "freebsd-current_at_freebsd.org" <freebsd-current_at_freebsd.org> >> Subject: Re: Weekly Current 13.0 Snapshot? >> Message-ID: >> > <CANCZdfq=-1sd85uHh0Na-8a5kX5T+JauD5gQ+PWXDiZMO9ejzw_at_mail.gmail.com> >> Content-Type: text/plain; charset="UTF-8" >> >> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber <gjb_at_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 <gjb_at_FreeBSD.org> >> To: Warner Losh <imp_at_bsdimp.com> >> Cc: Clay Daniels <clay.daniels.jr_at_gmail.com>, >> "freebsd-current_at_freebsd.org" <freebsd-current_at_freebsd.org> >> Subject: Re: Weekly Current 13.0 Snapshot? >> Message-ID: <A3173D69-A692-4DE1-8037-F5751B4343E6_at_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 <imp_at_bsdimp.com> wrote: >>> >>> ? >>> >>>> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber <gjb_at_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.jr_at_gmail.com> >> To: Glen Barber <gjb_at_freebsd.org> >> Cc: Warner Losh <imp_at_bsdimp.com>, "freebsd-current_at_freebsd.org" >> <freebsd-current_at_freebsd.org> >> Subject: Re: Weekly Current 13.0 Snapshot? >> Message-ID: >> <CAGLDxTUo8XMh-ZfjBLs_E- > WN251hqAb9JEwUwicSPR=1K6GyOw_at_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 <gjb_at_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 <imp_at_bsdimp.com> wrote: >>> >>> ? >>> >>> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber <gjb_at_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 <gjb_at_FreeBSD.org> >> To: Clay Daniels <clay.daniels.jr_at_gmail.com> >> Cc: Warner Losh <imp_at_bsdimp.com>, "freebsd-current_at_freebsd.org" >> <freebsd-current_at_freebsd.org> >> Subject: Re: Weekly Current 13.0 Snapshot? >> Message-ID: <A4B6B6E7-0435-4FE3-A815-E36C14788F46_at_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.jr_at_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 <gjb_at_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 <imp_at_bsdimp.com> wrote: >>>>> ? >>>>> >>>>>> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber <gjb_at_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_at_freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_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 <marklmi_at_yahoo.com> > To: FreeBSD Current <freebsd-current_at_freebsd.org>, FreeBSD Toolchain > <freebsd-toolchain_at_freebsd.org> > Cc: freebsd-arm <freebsd-arm_at_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-F249D85D10FF_at_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 <lwhsu_at_freebsd.org> > To: freebsd-testing_at_freebsd.org > Cc: freebsd-current_at_freebsd.org, freebsd-stable_at_freebsd.org > Subject: FreeBSD CI Weekly Report 2020-08-16 > Message-ID: <20200821211904.GA21926_at_freefall.freebsd.org> > Content-Type: text/plain; charset=us-ascii > > (Please send the followup to freebsd-testing_at_ 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/_at_FreeBSD-CI/report-20200816 and archive is available at > https://hackmd.io/_at_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_at_](https://preview.tinyurl.com/y9maauwg) > > > ------------------------------ > > Message: 4 > Date: Fri, 21 Aug 2020 23:23:19 +0200 > From: Hans Petter Selasky <hps_at_selasky.org> > To: Alexandre Levy <a13xlevy_at_gmail.com> > Cc: freebsd-current_at_freebsd.org > Subject: Re: Kernel crash during video transcoding > Message-ID: <0ccb28fe-569d-2abb-f94b-f33d6155a9e8_at_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_at_unrelenting.technology> > To: Mark Millard <marklmi_at_yahoo.com>, FreeBSD Current > <freebsd-current_at_freebsd.org>, FreeBSD Toolchain > <freebsd-toolchain_at_freebsd.org> > Cc: freebsd-arm <freebsd-arm_at_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_at_unrelenting.technology> > Content-Type: text/plain; charset=utf-8 > > > > On August 21, 2020 6:52:23 PM UTC, Mark Millard via freebsd-arm <freebsd-arm_at_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-current_at_lordsith.net> > To: freebsd-current <freebsd-current_at_freebsd.org> > Subject: 13-CURRENT won't boot after switch to sysutils/openzfs > Message-ID: <20200822114934.GB40844_at_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_at_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 >Received on Sat Aug 22 2020 - 21:20:55 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:24 UTC
