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 > ***********************************************Received on Fri Aug 21 2020 - 15:38:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:24 UTC
