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

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

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

Lizbeth Mutterhunt, Ph.D
here we go - when nothing works anymore (kernel panic after a simple 'xinit'
and kwin_x11. recomiled to WITNESS="YES" and HYPERV off, but still same panics.

https://pasteboard.co/Jnqgbeq.png



On Friday, August 21, 2020 2:00:00 PM CEST [hidden email]
wrote:

> Message: 1
> Date: Thu, 20 Aug 2020 08:15:56 +0200
> From: "Vanbreukelingen Ltd." <[hidden email]>
> To: Current FreeBSD <[hidden email]>
> Subject: Re: funny thing with the drm0
> Message-ID: <8073347.hK6j7OjjKr@alice>
> Content-Type: text/plain; charset="us-ascii"
>
> On Thursday, August 20, 2020 8:12:58 AM CEST Vanbreukelingen Ltd. wrote:
> > On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote:
> > > On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D <
> > >
> > > [hidden email]> wrote:
> > > > After having had some near-death-experiences in Greece I'm back to my
> > > > screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-)
> > > >
> > > >
> > > > But this is the experience with my Dell Vostro on 13 current:
> > > >
> > > >
> > > > After finally recompiling the kernel with the drm-module inside and
> > > > the trick of injecting the
> > >
> > > This is not the way to do it. Modern hardware require drm-kmod from
> > > ports,
> > > or if you want the latest drm-devel-kmod. Then add  /boot/modules/drm.ko
> > > and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf
>
> wasn't yet finished (c [see] beyond), but I guess I have to disable the
> whole output with something like hw.*=1 or so. is it possible to make a
> bootlogo while VEBOSE output = 2 just for the reason some kids try to play
> with it.
>
> > > > device IWNFW
>
>  doesn't install the 6000, btw --- probably can't find FW on device HAL.
>
> > > Again, this is not needed, firmware is autoloaded on module load. Just
> > > add
> > > if_iwn to kld_list in /etc/rc.conf
>
>  built of 15 hours of NanoBSD while finishing the nightly built someone was
> on Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at all
> but some reason tells me behind this system in system is something to beat
> beastie in killing KFC forks. ;-)
>
> > > > I get a *nice* message a bootup:
> > > >
> > > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0
> > > > 20060810
> > > > Aug 19 02:51:10 current kernel: drmn0: <Intel SandyBridge (M)> on
> > > > vgapci0
> > > > Aug 19 02:51:10 current kernel: info: [drm] Memory usable by graphics
> > > > device = 2048M
> > > > Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation failed.
> > > > Graphics performance may suffer.
> > > > Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus0: <Philips I2C bus> on
> > > > iicbb_nostop0 addr 0x1
> > > > Aug 19 02:51:10 current kernel: iic0: <I2C generic I/O> on iicbus0
> > > > Aug 19 02:51:10 current kernel: iicbus1: <Philips I2C bus> on
> > > > intel_gmbus0
> > > > Aug 19 02:51:10 current kernel: iic1: <I2C generic I/O> on iicbus1
> > > > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus2: <Philips I2C bus> on
> > > > iicbb_nostop1 addr 0x12
> > > > Aug 19 02:51:10 current kernel: iic2: <I2C generic I/O> on iicbus2
> > > > Aug 19 02:51:10 current kernel: iicbus3: <Philips I2C bus> on
> > > > intel_gmbus1
> > > > Aug 19 02:51:10 current kernel: iic3: <I2C generic I/O> on iicbus3
> > > > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus4: <Philips I2C bus> on
> > > > iicbb_nostop2 addr 0x12
> > > > Aug 19 02:51:10 current kernel: iic4: <I2C generic I/O> on iicbus4
> > > > Aug 19 02:51:10 current kernel: iicbus5: <Philips I2C bus> on
> > > > intel_gmbus2
> > > > Aug 19 02:51:10 current kernel: iic5: <I2C generic I/O> on iicbus5
> > > > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus6: <Philips I2C bus> on
> > > > iicbb_nostop3 addr 0x12
> > > > Aug 19 02:51:10 current kernel: iic6: <I2C generic I/O> on iicbus6
> > > > Aug 19 02:51:10 current kernel: iicbus7: <Philips I2C bus> on
> > > > intel_gmbus3
> > > > Aug 19 02:51:10 current kernel: iic7: <I2C generic I/O> on iicbus7
> > > > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus8: <Philips I2C bus> on
> > > > iicbb_nostop4 addr 0x12
> > > > Aug 19 02:51:10 current kernel: iic8: <I2C generic I/O> on iicbus8
> > > > Aug 19 02:51:10 current kernel: iicbus9: <Philips I2C bus> on
> > > > intel_gmbus4
> > > > Aug 19 02:51:10 current kernel: iic9: <I2C generic I/O> on iicbus9
> > > > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus10: <Philips I2C bus> on
> > > > iicbb_nostop5 addr 0x12
> > > >
> > > > And furthermore:
> > > >
> > > > Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 message(s)
> > > > Aug 19 02:51:10 current kernel: info: [drm] Supports vblank timestamp
> > > > caching Rev 1 (10.10.201>
> > > > Aug 19 02:51:10 current kernel: info: [drm] Driver supports precise
> > > > vblank timestamp query.
> > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on drmn0
> > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: detached
> > > > Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0
> > > > Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious
> > > > range 0xe0000000-0xf0000000
> > > > Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: get mode
> > > > from tunables:
> > > > Aug 19 02:51:10 current kernel: info: [drm]   -
> > > > kern.vt.fb.modes.LVDS-1
> > > > Aug 19 02:51:10 current kernel: info: [drm]   -
> > > > kern.vt.fb.default_mode
> > > > Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: get mode
> > > > from tunables:
> > > > Aug 19 02:51:10 current kernel: info: [drm]   - kern.vt.fb.modes.VGA-1
> > > > Aug 19 02:51:10 current kernel: info: [drm]   -
> > > > kern.vt.fb.default_mode
> > > > Aug 19 02:51:10 current kernel: info: [drm] Connector HDMI-A-1: get
> > > > mode from tunables:
> > > > Aug 19 02:51:10 current kernel: info: [drm]   -
> > > > kern.vt.fb.modes.HDMI-A-1
> > > > Aug 19 02:51:10 current kernel: info: [drm]   -
> > > > kern.vt.fb.default_mode
> > > > Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: get mode
> > > > from tunables:
> > > > Aug 19 02:51:10 current kernel: info: [drm]   - kern.vt.fb.modes.DP-1
> > > > Aug 19 02:51:10 current kernel: info: [drm]   -
> > > > kern.vt.fb.default_mode
> > > > Aug 19 02:51:10 current kernel: fbd0 on drmn0
> > > > Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant locked
> > > > and may be deleted before>
> > > > Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" with new
> > > > "fb".
> > > > ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0
> > > > 20080730 for drmn0 on minor 0
> > > >
> > > > so far so good, quality of text in grafics 1368x1024 is perfectly
> > > > initialized. but now, when starting xinit or lightdm or sddm or
> > > > whatever I get a kernel panic:
> > > >
> > > > Dump header from device: /dev/ada0p4
> > > >
> > > >   Architecture: i386
> > > >   Architecture Version: 4
> > > >   Dump Length: 97792
> > > >   Blocksize: 512
> > > >   Compression: none
> > > >   Dumptime: 2020-08-19 02:49:00 +0200
> > > >   Hostname: current
> > > >   Magic: FreeBSD Text Dump
> > > >   Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18 20:18:40
> > > >
> > > > CEST 2020
> > > >
> > > >     root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA
> > > >  
> > > >   Panic String: vm_page_assert_xbusied: page 0x72bd024 not exclusive
> > > >
> > > > busy @ /usr/src/sys/vm/vm>
> > > >
> > > >   Dump Parity: 2773167169
> > > >   Bounds: 1
> > > >   Dump Status: good
> > > >  
> > > >   /var/crash/vmcore.0 not found
> > >
> > > Do you have  dumpdev="AUTO" in /etc/rc.conf ?
>
> yes and the directory is /var/crash, but this is all I get as lack of
> insufficent memory of dump, it says.
>
> > > > First thing I think is kern options:
> > > >
> > > > options WITNESS_SKIPSPIN
> > > > options WITNESS
> > > >
> > > > I disabled device HYPERV but this can't be the reason, kern is being
> > > > compiled with clang.
> > >
> > > Clang is the default since a long time.
>
> depends on gcc++ development in 4D AIs.
>
> > > > To disable WITNESS would be one way I think but this can't be the
> > > > yellw of the egg, isn't it?
> > >
> > > I use the GENERIC-NODEBUG kernel config which disables WITNESS for some
> > > performance improvements.
>
> yup. we don't need another debugger. killing insects is murder but when
> getting better stuff I never resist to lance them. like housecats with flys.
> > > > Another thing but I guess having nothing to do with bug above is on
> > > > rather the end of  startup:
> > > >
> > > > Aug 19 02:51:10 current savecore[1209]: reboot after panic:
> > > > vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @
> > > > /usr/src/sys/vm/vm_page.c:1609
> > > > Aug 19 02:51:10 current savecore[1209]: writing core to
> > > > /var/crash/textdump.tar.1
> > > > Aug 19 02:51:10 current kernel: linsysfs:
> > > > Aug 19 02:51:10 current kernel: Device busy
> > > > Aug 19 02:51:10 current kernel: lock order reversal:
> > > > Aug 19 02:51:10 current kernel:  1st 0x3121e870 ufs (ufs, lockmgr) @
> > > > /usr/src/sys/kern/vfs_mount.c:1008
> > > > Aug 19 02:51:10 current kernel:  2nd 0x3121e744 devfs (devfs, lockmgr)
> > > > @ /usr/src/sys/kern/vfs_mount.c:1019
> > > > Aug 19 02:51:10 current kernel: lock order devfs -> ufs established
> > > > at:
> > > > Aug 19 02:51:10 current kernel: #0 0x1027cd5 at
> > > > witness_checkorder+0x3c5
> > > > Aug 19 02:51:10 current kernel: #1 0xf9cca0 at
> > > > lockmgr_lock_flags+0x140
> > > > Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57
> > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f
> > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f
> > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99
> > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b
> > > > Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57
> > > > Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452
> > > > Aug 19 02:51:10 current kernel: #9 0x10859be at vfs_mountroot+0x4ce
> > > > Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22
> > > > Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68
> > > > Aug 19 02:51:10 current kernel: #12 0xffc0340e at
> > > > __stop_set_sysinit_set+0xd0a4199e
> > > > Aug 19 02:51:10 current kernel: lock order ufs -> devfs attempted at:
> > > > Aug 19 02:51:10 current kernel: #0 0x1028360 at
> > > > witness_checkorder+0xa50
> > > > Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46
> > > > Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a
> > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f
> > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f
> > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99
> > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b
> > > > Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d
> > > > Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195
> > > > Aug 19 02:51:10 current kernel: #9 0xffc033f9 at
> > > > __stop_set_sysinit_set+0xd0a41989
> > > >
> > > > any ideas?
> > > > Miranda
> > > >
> > > >
> > > >
> > > > does someone know how to fix it?
> > > >
> > > > Miranda
> > >
> > > Hope this helps.
>
> It does!
>
> > > Best regards
> > > Andreas Nilsson
>
> Yours,
> Miranda van Breukelingen
>
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 20 Aug 2020 16:43:56 +0200
> From: Andreas Nilsson <[hidden email]>
> To: "Vanbreukelingen Ltd." <[hidden email]>,  Current
> FreeBSD <[hidden email]>
> Subject: Re: funny thing with the drm0
> Message-ID:
> <CAPS9+SshknntXpCxnNB=Pm+BNJh_+pvJc_z5X5eN6t-
[hidden email]>

> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, Aug 20, 2020 at 2:48 PM Vanbreukelingen Ltd. <
>
> [hidden email]> wrote:
> > On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote:
> > > On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D <
> > >
> > > [hidden email]> wrote:
> > > > After having had some near-death-experiences in Greece I'm back to my
> > > > screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-)
> > > >
> > > >
> > > > But this is the experience with my Dell Vostro on 13 current:
> > > >
> > > >
> > > > After finally recompiling the kernel with the drm-module inside and
> > > > the trick of injecting the
> > >
> > > This is not the way to do it. Modern hardware require drm-kmod from
> >
> > ports,
> >
> > > or if you want the latest drm-devel-kmod. Then add  /boot/modules/drm.ko
> > > and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf
> >
> > wasn't yet finished (c [see] beyond), but I guess I have to disable the
> > whole
> > output with something like hw.*=1 or so. is it possible to make a bootlogo
> > while VEBOSE output = 2 just for the reason some kids try to play with it.
> >
> > > > device IWNFW
> >
> > doesn't install the 6000, btw --- probably can't find FW on device HAL.
> >
> > > Again, this is not needed, firmware is autoloaded on module load. Just
> >
> > add
> >
> > > if_iwn to kld_list in /etc/rc.conf
>
> Here I admit I was wrong, iwn handles it differently than iwm. The man page
> lists 3 different firmware versions for the 6000 series, which can be
> loaded from loader.conf
>
> > built 15 hours of NanoBSD while finishing the nightly built someone was on
> > Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at all but
> > some
> > reason tells me behind this system in system is something to beat beastie
> > in
> > killing KFC forks.
> >
> > > > I get a *nice* message a bootup:
> > > >
> > > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0
> >
> > 20060810
> >
> > > > Aug 19 02:51:10 current kernel: drmn0: <Intel SandyBridge (M)> on
> >
> > vgapci0
> >
> > > > Aug 19 02:51:10 current kernel: info: [drm] Memory usable by graphics
> > > > device = 2048M
> > > > Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation failed.
> > > > Graphics performance may suffer.
> > > > Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus0: <Philips I2C bus> on
> > > > iicbb_nostop0 addr 0x1
> > > > Aug 19 02:51:10 current kernel: iic0: <I2C generic I/O> on iicbus0
> > > > Aug 19 02:51:10 current kernel: iicbus1: <Philips I2C bus> on
> >
> > intel_gmbus0
> >
> > > > Aug 19 02:51:10 current kernel: iic1: <I2C generic I/O> on iicbus1
> > > > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus2: <Philips I2C bus> on
> > > > iicbb_nostop1 addr 0x12
> > > > Aug 19 02:51:10 current kernel: iic2: <I2C generic I/O> on iicbus2
> > > > Aug 19 02:51:10 current kernel: iicbus3: <Philips I2C bus> on
> >
> > intel_gmbus1
> >
> > > > Aug 19 02:51:10 current kernel: iic3: <I2C generic I/O> on iicbus3
> > > > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus4: <Philips I2C bus> on
> > > > iicbb_nostop2 addr 0x12
> > > > Aug 19 02:51:10 current kernel: iic4: <I2C generic I/O> on iicbus4
> > > > Aug 19 02:51:10 current kernel: iicbus5: <Philips I2C bus> on
> >
> > intel_gmbus2
> >
> > > > Aug 19 02:51:10 current kernel: iic5: <I2C generic I/O> on iicbus5
> > > > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus6: <Philips I2C bus> on
> > > > iicbb_nostop3 addr 0x12
> > > > Aug 19 02:51:10 current kernel: iic6: <I2C generic I/O> on iicbus6
> > > > Aug 19 02:51:10 current kernel: iicbus7: <Philips I2C bus> on
> >
> > intel_gmbus3
> >
> > > > Aug 19 02:51:10 current kernel: iic7: <I2C generic I/O> on iicbus7
> > > > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus8: <Philips I2C bus> on
> > > > iicbb_nostop4 addr 0x12
> > > > Aug 19 02:51:10 current kernel: iic8: <I2C generic I/O> on iicbus8
> > > > Aug 19 02:51:10 current kernel: iicbus9: <Philips I2C bus> on
> >
> > intel_gmbus4
> >
> > > > Aug 19 02:51:10 current kernel: iic9: <I2C generic I/O> on iicbus9
> > > > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0
> > > > Aug 19 02:51:10 current kernel: iicbus10: <Philips I2C bus> on
> > > > iicbb_nostop5 addr 0x12
> > > >
> > > > And furthermore:
> > > >
> > > > Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1 message(s)
> > > > Aug 19 02:51:10 current kernel: info: [drm] Supports vblank timestamp
> > > > caching Rev 1 (10.10.201>
> > > > Aug 19 02:51:10 current kernel: info: [drm] Driver supports precise
> > > > vblank timestamp query.
> > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on drmn0
> > > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920: detached
> > > > Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0
> > > > Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious
> > > > range 0xe0000000-0xf0000000
> > > > Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1: get mode
> > > > from tunables:
> > > > Aug 19 02:51:10 current kernel: info: [drm]   -
> > > > kern.vt.fb.modes.LVDS-1
> > > > Aug 19 02:51:10 current kernel: info: [drm]   -
> > > > kern.vt.fb.default_mode
> > > > Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1: get mode
> > > > from tunables:
> > > > Aug 19 02:51:10 current kernel: info: [drm]   - kern.vt.fb.modes.VGA-1
> > > > Aug 19 02:51:10 current kernel: info: [drm]   -
> > > > kern.vt.fb.default_mode
> > > > Aug 19 02:51:10 current kernel: info: [drm] Connector HDMI-A-1: get
> > > > mode from tunables:
> > > > Aug 19 02:51:10 current kernel: info: [drm]   -
> >
> > kern.vt.fb.modes.HDMI-A-1
> >
> > > > Aug 19 02:51:10 current kernel: info: [drm]   -
> > > > kern.vt.fb.default_mode
> > > > Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1: get mode
> > > > from tunables:
> > > > Aug 19 02:51:10 current kernel: info: [drm]   - kern.vt.fb.modes.DP-1
> > > > Aug 19 02:51:10 current kernel: info: [drm]   -
> > > > kern.vt.fb.default_mode
> > > > Aug 19 02:51:10 current kernel: fbd0 on drmn0
> > > > Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant locked
> > > > and may be deleted before>
> > > > Aug 19 02:51:10 current kernel: VT: Replacing driver "vga" with new
> >
> > "fb".
> >
> > > > ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0
> > > > 20080730 for drmn0 on minor 0
> > > >
> > > > so far so good, quality of text in grafics 1368x1024 is perfectly
> > > > initialized. but now, when starting xinit or lightdm or sddm or
> > > > whatever I get a kernel panic:
> > > >
> > > > Dump header from device: /dev/ada0p4
> > > >
> > > >   Architecture: i386
> > > >   Architecture Version: 4
> > > >   Dump Length: 97792
> > > >   Blocksize: 512
> > > >   Compression: none
> > > >   Dumptime: 2020-08-19 02:49:00 +0200
> > > >   Hostname: current
> > > >   Magic: FreeBSD Text Dump
> > > >   Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18 20:18:40
> > > >
> > > > CEST 2020
> > > >
> > > >     root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA
> > > >  
> > > >   Panic String: vm_page_assert_xbusied: page 0x72bd024 not exclusive
> > > >
> > > > busy @ /usr/src/sys/vm/vm>
> > > >
> > > >   Dump Parity: 2773167169
> > > >   Bounds: 1
> > > >   Dump Status: good
> > > >  
> > > >   /var/crash/vmcore.0 not found
> > >
> > > Do you have  dumpdev="AUTO" in /etc/rc.conf ?
> >
> > yes and the directory is /var/crash, but this is all I get as lack of
> > insufficent memory of dump, it says.
>
> Sounds like your swap device is to small. How big is it, and how much
> memory do you have?
>
> > > > First thing I think is kern options:
> > > >
> > > > options WITNESS_SKIPSPIN
> > > > options WITNESS
> > > >
> > > > I disabled device HYPERV but this can't be the reason, kern is being
> > > > compiled with clang.
> > >
> > > Clang is the default since a long time.
> >
> > depends on gcc++ development in 4D AIs.
> >
> > Nothing stops you from using gcc for compiling your programs. Clang is
>
> just the default for the OS.
>
> > > > To disable WITNESS would be one way I think but this can't be the
> > > > yellw of the egg, isn't it?
> > >
> > > I use the GENERIC-NODEBUG kernel config which disables WITNESS for some
> > > performance improvements.
> >
> > yup. we don't need another debugger. killing insects is murder but when
> > getting better stuff I never resist to lance them. like housecats with
> > flys.
> >
> > > > Another thing but I guess having nothing to do with bug above is on
> > > > rather the end of  startup:
> > > >
> > > > Aug 19 02:51:10 current savecore[1209]: reboot after panic:
> > > > vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @
> > > > /usr/src/sys/vm/vm_page.c:1609
> > > > Aug 19 02:51:10 current savecore[1209]: writing core to
> > > > /var/crash/textdump.tar.1
> > > > Aug 19 02:51:10 current kernel: linsysfs:
> > > > Aug 19 02:51:10 current kernel: Device busy
> > > > Aug 19 02:51:10 current kernel: lock order reversal:
> > > > Aug 19 02:51:10 current kernel:  1st 0x3121e870 ufs (ufs, lockmgr) @
> > > > /usr/src/sys/kern/vfs_mount.c:1008
> > > > Aug 19 02:51:10 current kernel:  2nd 0x3121e744 devfs (devfs, lockmgr)
> > > > @ /usr/src/sys/kern/vfs_mount.c:1019
> > > > Aug 19 02:51:10 current kernel: lock order devfs -> ufs established
> > > > at:
> > > > Aug 19 02:51:10 current kernel: #0 0x1027cd5 at
> >
> > witness_checkorder+0x3c5
> >
> > > > Aug 19 02:51:10 current kernel: #1 0xf9cca0 at
> > > > lockmgr_lock_flags+0x140
> > > > Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57
> > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f
> > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f
> > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99
> > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b
> > > > Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57
> > > > Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452
> > > > Aug 19 02:51:10 current kernel: #9 0x10859be at vfs_mountroot+0x4ce
> > > > Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22
> > > > Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68
> > > > Aug 19 02:51:10 current kernel: #12 0xffc0340e at
> > > > __stop_set_sysinit_set+0xd0a4199e
> > > > Aug 19 02:51:10 current kernel: lock order ufs -> devfs attempted at:
> > > > Aug 19 02:51:10 current kernel: #0 0x1028360 at
> >
> > witness_checkorder+0xa50
> >
> > > > Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46
> > > > Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a
> > > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f
> > > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f
> > > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99
> > > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b
> > > > Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d
> > > > Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195
> > > > Aug 19 02:51:10 current kernel: #9 0xffc033f9 at
> > > > __stop_set_sysinit_set+0xd0a41989
> > > >
> > > > any ideas?
> > > > Miranda
> > > >
> > > >
> > > >
> > > > does someone know how to fix it?
> > > >
> > > > Miranda
> > >
> > > Hope this helps.
> >
> > It does!
> >
> > > Best regards
> > > Andreas Nilsson
> >
> > Yours,
> > Miranda van Breukelingen
> >
> >
> > Best regards
>
> Andreas Nilsson
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 20 Aug 2020 16:58:25 +0200
> From: "Vanbreukelingen Ltd." <[hidden email]>
> To: Andreas Nilsson <[hidden email]>, [hidden email]
> Subject: Re: funny thing with the drm0
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 2020-08-20 16:43, Andreas Nilsson wrote:
> > On Thu, Aug 20, 2020 at 2:48 PM Vanbreukelingen Ltd.
> >
> > <[hidden email] <mailto:[hidden email]>> wrote:
> >     On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote:
> >     > On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D <
> >     >
> >     > [hidden email]
> >    
> >     <mailto:[hidden email]>> wrote:
> >     > > After having had some near-death-experiences in Greece I'm
> >    
> >     back to my
> >    
> >     > > screens. As horizon arises, BSD gets up --- and if it is 3
> >    
> >     a.m.! :-)
> >    
> >     > > But this is the experience with my Dell Vostro on 13 current:
> >     > >
> >     > >
> >     > > After finally recompiling the kernel with the drm-module
> >    
> >     inside and
> >    
> >     > > the trick of injecting the
> >     >
> >     > This is not the way to do it. Modern hardware require drm-kmod
> >    
> >     from ports,
> >    
> >     > or if you want the latest drm-devel-kmod. Then add
> >    
> >     /boot/modules/drm.ko
> >    
> >     > and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf
> >    
> >     wasn't yet finished (c [see] beyond), but I guess I have to
> >     disable the whole
> >     output with something like hw.*=1 or so. is it possible to make a
> >     bootlogo
> >     while VEBOSE output = 2 just for the reason some kids try to play
> >     with it.
>
> tried it now: next kernel panic on lightdm and sddm makes a mouse in
> mouse pointer over a blank screen. the driver is initialised but hungs
> up like this:
>
> Dump header from device: /dev/ada0p4
>  ? Architecture: i386
>  ? Architecture Version: 4
>  ? Dump Length: 97792
>  ? Blocksize: 512
>  ? Compression: none
>  ? Dumptime: 2020-08-20 16:41:45 +0200
>  ? Hostname: current
>  ? Magic: FreeBSD Text Dump
>  ? Version String: FreeBSD 13.0-CURRENT #3 r364372: Wed Aug 19 07:54:57
> CEST 2020
>  ??? root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA
> *Panic String: vm_page_assert_xbusied: page 0x6f47814 not exclusive busy
> @ /usr/src/sys/vm/vm_page.c:1609**
> **? Dump Parity: 4227235352*
>  ? Bounds: 2
>  ? Dump Status: good
>
> >     > > device IWNFW
> >    
> >     doesn't install the 6000, btw --- probably can't find FW on device
> >     HAL.
> >    
> >     > Again, this is not needed, firmware is autoloaded on module
> >    
> >     load. Just add
> >    
> >     > if_iwn to kld_list in /etc/rc.conf
> >
> > Here I admit I was wrong, iwn handles it differently than iwm. The man
> > page lists 3 different firmware versions for the 6000 series, which
> > can be loaded from loader.conf
>
> When compiling DEVICE iwnfb into kern: mine (iwn6000g2bfw) doesn't load
> probably at bootup but with wpa_supplicant -d BSD -i wlan0 -c
> /etc/wpa_supplicant.conf it loads correctly and automatically assigns an
> IP.
>
> >     built 15 hours of NanoBSD while finishing the nightly built
> >     someone was on
> >     Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at
> >     all but some
> >     reason tells me behind this system in system is something to beat
> >     beastie in
> >     killing KFC forks.
> >    
> >     > > I get a *nice* message a bootup:
> >     > >
> >     > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm
> >    
> >     1.1.0 20060810
> >    
> >     > > Aug 19 02:51:10 current kernel: drmn0: <Intel SandyBridge (M)>
> >    
> >     on vgapci0
> >    
> >     > > Aug 19 02:51:10 current kernel: info: [drm] Memory usable by
> >    
> >     graphics
> >    
> >     > > device = 2048M
> >     > > Aug 19 02:51:10 current kernel: info: [drm] MTRR allocation
> >    
> >     failed.
> >    
> >     > > Graphics performance may suffer.
> >     > > Aug 19 02:51:10 current kernel: intel_iicbb0 on drmn0
> >     > > Aug 19 02:51:10 current kernel: iicbus0: <Philips I2C bus> on
> >     > > iicbb_nostop0 addr 0x1
> >     > > Aug 19 02:51:10 current kernel: iic0: <I2C generic I/O> on iicbus0
> >     > > Aug 19 02:51:10 current kernel: iicbus1: <Philips I2C bus> on
> >    
> >     intel_gmbus0
> >    
> >     > > Aug 19 02:51:10 current kernel: iic1: <I2C generic I/O> on iicbus1
> >     > > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0
> >     > > Aug 19 02:51:10 current kernel: iicbus2: <Philips I2C bus> on
> >     > > iicbb_nostop1 addr 0x12
> >     > > Aug 19 02:51:10 current kernel: iic2: <I2C generic I/O> on iicbus2
> >     > > Aug 19 02:51:10 current kernel: iicbus3: <Philips I2C bus> on
> >    
> >     intel_gmbus1
> >    
> >     > > Aug 19 02:51:10 current kernel: iic3: <I2C generic I/O> on iicbus3
> >     > > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0
> >     > > Aug 19 02:51:10 current kernel: iicbus4: <Philips I2C bus> on
> >     > > iicbb_nostop2 addr 0x12
> >     > > Aug 19 02:51:10 current kernel: iic4: <I2C generic I/O> on iicbus4
> >     > > Aug 19 02:51:10 current kernel: iicbus5: <Philips I2C bus> on
> >    
> >     intel_gmbus2
> >    
> >     > > Aug 19 02:51:10 current kernel: iic5: <I2C generic I/O> on iicbus5
> >     > > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0
> >     > > Aug 19 02:51:10 current kernel: iicbus6: <Philips I2C bus> on
> >     > > iicbb_nostop3 addr 0x12
> >     > > Aug 19 02:51:10 current kernel: iic6: <I2C generic I/O> on iicbus6
> >     > > Aug 19 02:51:10 current kernel: iicbus7: <Philips I2C bus> on
> >    
> >     intel_gmbus3
> >    
> >     > > Aug 19 02:51:10 current kernel: iic7: <I2C generic I/O> on iicbus7
> >     > > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0
> >     > > Aug 19 02:51:10 current kernel: iicbus8: <Philips I2C bus> on
> >     > > iicbb_nostop4 addr 0x12
> >     > > Aug 19 02:51:10 current kernel: iic8: <I2C generic I/O> on iicbus8
> >     > > Aug 19 02:51:10 current kernel: iicbus9: <Philips I2C bus> on
> >    
> >     intel_gmbus4
> >    
> >     > > Aug 19 02:51:10 current kernel: iic9: <I2C generic I/O> on iicbus9
> >     > > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0
> >     > > Aug 19 02:51:10 current kernel: iicbus10: <Philips I2C bus> on
> >     > > iicbb_nostop5 addr 0x12
> >     > >
> >     > > And furthermore:
> >     > >
> >     > > Aug 19 02:51:10 current kernel: info: [drm] MSI enabled 1
> >    
> >     message(s)
> >    
> >     > > Aug 19 02:51:10 current kernel: info: [drm] Supports vblank
> >    
> >     timestamp
> >    
> >     > > caching Rev 1 (10.10.201>
> >     > > Aug 19 02:51:10 current kernel: info: [drm] Driver supports
> >    
> >     precise
> >    
> >     > > vblank timestamp query.
> >     > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920 on
> >    
> >     drmn0
> >    
> >     > > Aug 19 02:51:10 current kernel: intel_sdvo_ddc_proxy921920:
> >     detached
> >    
> >     > > Aug 19 02:51:10 current kernel: drm_iic_dp_aux0 on drmn0
> >     > > Aug 19 02:51:10 current kernel: drmn0: taking over the fictitious
> >     > > range 0xe0000000-0xf0000000
> >    
> >     > > Aug 19 02:51:10 current kernel: info: [drm] Connector LVDS-1:
> >     get mode
> >    
> >     > > from tunables:
> >     > > Aug 19 02:51:10 current kernel: info: [drm]? ?-
> >    
> >     kern.vt.fb.modes.LVDS-1
> >    
> >     > > Aug 19 02:51:10 current kernel: info: [drm]? ?-
> >    
> >     kern.vt.fb.default_mode
> >    
> >     > > Aug 19 02:51:10 current kernel: info: [drm] Connector VGA-1:
> >     get mode
> >    
> >     > > from tunables:
> >     > > Aug 19 02:51:10 current kernel: info: [drm]? ?-
> >    
> >     kern.vt.fb.modes.VGA-1
> >    
> >     > > Aug 19 02:51:10 current kernel: info: [drm]? ?-
> >    
> >     kern.vt.fb.default_mode
> >    
> >     > > Aug 19 02:51:10 current kernel: info: [drm] Connector
> >    
> >     HDMI-A-1: get
> >    
> >     > > mode from tunables:
> >     > > Aug 19 02:51:10 current kernel: info: [drm]? ?-
> >    
> >     kern.vt.fb.modes.HDMI-A-1
> >    
> >     > > Aug 19 02:51:10 current kernel: info: [drm]? ?-
> >    
> >     kern.vt.fb.default_mode
> >    
> >     > > Aug 19 02:51:10 current kernel: info: [drm] Connector DP-1:
> >     get mode
> >    
> >     > > from tunables:
> >     > > Aug 19 02:51:10 current kernel: info: [drm]? ?-
> >    
> >     kern.vt.fb.modes.DP-1
> >    
> >     > > Aug 19 02:51:10 current kernel: info: [drm]? ?-
> >    
> >     kern.vt.fb.default_mode
> >    
> >     > > Aug 19 02:51:10 current kernel: fbd0 on drmn0
> >     > > Aug 19 02:51:10 current kernel: WARNING: Device "fb" is Giant
> >    
> >     locked
> >    
> >     > > and may be deleted before>
> >     > > Aug 19 02:51:10 current kernel: VT: Replacing driver "vga"
> >    
> >     with new "fb".
> >    
> >     > > ug 19 02:51:10 current kernel: info: [drm] Initialized i915 1.6.0
> >     > > 20080730 for drmn0 on minor 0
> >     > >
> >     > > so far so good, quality of text in grafics 1368x1024 is perfectly
> >     > > initialized. but now, when starting xinit or lightdm or sddm or
> >     > > whatever I get a kernel panic:
> >     > >
> >     > > Dump header from device: /dev/ada0p4
> >     > >
> >     > >? ?Architecture: i386
> >     > >? ?Architecture Version: 4
> >     > >? ?Dump Length: 97792
> >     > >? ?Blocksize: 512
> >     > >? ?Compression: none
> >     > >? ?Dumptime: 2020-08-19 02:49:00 +0200
> >     > >? ?Hostname: current
> >     > >? ?Magic: FreeBSD Text Dump
> >     > >? ?Version String: FreeBSD 13.0-CURRENT #2 r364350: Tue Aug 18
> >    
> >     20:18:40
> >    
> >     > > CEST 2020
> >     > >
> >     > > ?root@current:/usr/obj/usr/src/i386.i386/sys/MIRANDA
> >     > >
> >     > >? ?Panic String: vm_page_assert_xbusied: page 0x72bd024 not
> >    
> >     exclusive
> >    
> >     > > busy @ /usr/src/sys/vm/vm>
> >     > >
> >     > >? ?Dump Parity: 2773167169
> >     > >? ?Bounds: 1
> >     > >? ?Dump Status: good
> >     > >
> >     > >? ?/var/crash/vmcore.0 not found
> >     >
> >     > Do you have? dumpdev="AUTO" in /etc/rc.conf ?
> >    
> >     yes and the directory is /var/crash, but this is all I get as lack of
> >     insufficent memory of dump, it says.
> >
> > Sounds like your swap device is to small. How big is it, and how much
> > memory do you have?
> >
> >     > > First thing I think is kern options:
> >     > >
> >     > > options WITNESS_SKIPSPIN
> >     > > options WITNESS
> >     > >
> >     > > I disabled device HYPERV but this can't be the reason, kern is
> >    
> >     being
> >    
> >     > > compiled with clang.
> >     >
> >     > Clang is the default since a long time.
> >    
> >     depends on gcc++ development in 4D AIs.
> >
> > Nothing stops you from using gcc for compiling your programs. Clang is
> > just the default for the OS.
> >
> >     > > To disable WITNESS would be one way I think but this can't be the
> >     > > yellw of the egg, isn't it?
> >     >
> >     > I use the GENERIC-NODEBUG kernel config which disables WITNESS
> >    
> >     for some
> >    
> >     > performance improvements.
> >    
> >     yup. we don't need another debugger. killing insects is murder but
> >     when
> >     getting better stuff I never resist to lance them. like housecats
> >     with flys.
> >    
> >     > > Another thing but I guess having nothing to do with bug above
> >    
> >     is on
> >    
> >     > > rather the end of? startup:
> >     > >
> >     > > Aug 19 02:51:10 current savecore[1209]: reboot after panic:
> >     > > vm_page_assert_xbusied: page 0x72bd024 not exclusive busy @
> >     > > /usr/src/sys/vm/vm_page.c:1609
> >     > > Aug 19 02:51:10 current savecore[1209]: writing core to
> >     > > /var/crash/textdump.tar.1
> >     > > Aug 19 02:51:10 current kernel: linsysfs:
> >     > > Aug 19 02:51:10 current kernel: Device busy
> >     > > Aug 19 02:51:10 current kernel: lock order reversal:
> >     > > Aug 19 02:51:10 current kernel:? 1st 0x3121e870 ufs (ufs,
> >    
> >     lockmgr) @
> >    
> >     > > /usr/src/sys/kern/vfs_mount.c:1008
> >     > > Aug 19 02:51:10 current kernel:? 2nd 0x3121e744 devfs (devfs,
> >    
> >     lockmgr)
> >    
> >     > > @ /usr/src/sys/kern/vfs_mount.c:1019
> >     > > Aug 19 02:51:10 current kernel: lock order devfs -> ufs
> >    
> >     established at:
> >     > > Aug 19 02:51:10 current kernel: #0 0x1027cd5 at
> >    
> >     witness_checkorder+0x3c5
> >    
> >     > > Aug 19 02:51:10 current kernel: #1 0xf9cca0 at
> >    
> >     lockmgr_lock_flags+0x140
> >    
> >     > > Aug 19 02:51:10 current kernel: #2 0x123f697 at ffs_lock+0x57
> >     > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f
> >     > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f
> >     > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99
> >     > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b
> >     > > Aug 19 02:51:10 current kernel: #7 0x1085017 at kernel_mount+0x57
> >     > > Aug 19 02:51:10 current kernel: #8 0x10871c2 at parse_mount+0x452
> >     > > Aug 19 02:51:10 current kernel: #9 0x10859be at
> >    
> >     vfs_mountroot+0x4ce
> >    
> >     > > Aug 19 02:51:10 current kernel: #10 0xf65912 at start_init+0x22
> >     > > Aug 19 02:51:10 current kernel: #11 0xf8aa18 at fork_exit+0x68
> >     > > Aug 19 02:51:10 current kernel: #12 0xffc0340e at
> >     > > __stop_set_sysinit_set+0xd0a4199e
> >     > > Aug 19 02:51:10 current kernel: lock order ufs -> devfs
> >    
> >     attempted at:
> >     > > Aug 19 02:51:10 current kernel: #0 0x1028360 at
> >    
> >     witness_checkorder+0xa50
> >    
> >     > > Aug 19 02:51:10 current kernel: #1 0xf9e486 at lockmgr_xlock+0x46
> >     > > Aug 19 02:51:10 current kernel: #2 0x107b21a at vop_lock+0x6a
> >     > > Aug 19 02:51:10 current kernel: #3 0x13a1daf at VOP_LOCK1_APV+0x2f
> >     > > Aug 19 02:51:10 current kernel: #4 0x10a03df at _vn_lock+0x4f
> >     > > Aug 19 02:51:10 current kernel: #5 0x1082d89 at vfs_domount+0xc99
> >     > > Aug 19 02:51:10 current kernel: #6 0x108178b at vfs_donmount+0x75b
> >     > > Aug 19 02:51:10 current kernel: #7 0x1080ffd at sys_nmount+0x5d
> >     > > Aug 19 02:51:10 current kernel: #8 0x138c895 at syscall+0x195
> >     > > Aug 19 02:51:10 current kernel: #9 0xffc033f9 at
> >     > > __stop_set_sysinit_set+0xd0a41989
> >     > >
> >     > > any ideas?
> >     > > Miranda
> >     > >
> >     > >
> >     > >
> >     > > does someone know how to fix it?
> >     > >
> >     > > Miranda
> >     >
> >     > Hope this helps.
> >    
> >     It does!
> >    
> >     > Best regards
> >     > Andreas Nilsson
> >    
> >     Yours,
> >     Miranda van Breukelingen
> >
> > Best regards
> > Andreas Nilsson
>
> ------------------------------
>
> Message: 4
> Date: Thu, 20 Aug 2020 12:05:45 -0500
> From: Eric van Gyzen <[hidden email]>
> To: [hidden email], [hidden email]
> Subject: LOR: tun_ioctl after tun_mtx
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> I see this LOR on head r364364 while running the tcptestsuite
> (ports/net/tcptestsuite).  In fact, I interrupted a test with Ctrl-C,
> and got a panic.  I assume it's the same, since the test was twiddling
> the MTU, but I haven't looked closely.
>
> Eric
>
> lock order reversal: (sleepable after non-sleepable)
>   1st 0xfffff802238ea690 tun_mtx (tun_mtx, sleep mutex) @
> /usr/src/sys/net/if_tuntap.c:1628
>   2nd 0xffffffff81d99d28 tun_ioctl (tun_ioctl, sx) @
> /usr/src/sys/net/if_tuntap.c:1326
> lock order tun_ioctl -> tun_mtx established at:
> #0 0xffffffff80c432dd at witness_checkorder+0x46d
> #1 0xffffffff80bb38e4 at __mtx_lock_flags+0x94
> #2 0xffffffff80cfad2b at tuninit+0x4b
> #3 0xffffffff80cfa44f at tunifioctl+0x6f
> #4 0xffffffff80dc398f at in6_update_ifa+0xa8f
> #5 0xffffffff80dc96f0 at in6_ifattach+0x5b0
> #6 0xffffffff80dc577e at in6_if_up+0x7e
> #7 0xffffffff80ceb289 at if_up+0x69
> #8 0xffffffff80cec2f7 at ifhwioctl+0xd07
> #9 0xffffffff80ced475 at ifioctl+0x395
> #10 0xffffffff80c490ae at kern_ioctl+0x28e
> #11 0xffffffff80c48d77 at sys_ioctl+0x127
> #12 0xffffffff81015820 at amd64_syscall+0x140
> #13 0xffffffff80febb3e at fast_syscall_common+0xf8
> lock order tun_mtx -> tun_ioctl attempted at:
> #0 0xffffffff80c43c3c at witness_checkorder+0xdcc
> #1 0xffffffff80be0247 at _sx_xlock+0x67
> #2 0xffffffff80cfa411 at tunifioctl+0x31
> #3 0xffffffff80ceba5b at ifhwioctl+0x46b
> #4 0xffffffff80cf9101 at tunioctl+0x5b1
> #5 0xffffffff80a7b0fc at devfs_ioctl+0xcc
> #6 0xffffffff80cc9bf2 at vn_ioctl+0x132
> #7 0xffffffff80a7b76e at devfs_ioctl_f+0x1e
> #8 0xffffffff80c490ae at kern_ioctl+0x28e
> #9 0xffffffff80c48d77 at sys_ioctl+0x127
> #10 0xffffffff81015820 at amd64_syscall+0x140
> #11 0xffffffff80febb3e at fast_syscall_common+0xf8
>
> local/tcptestsuite/tcptestsuite_atf_test:snd_syn_mss_inherited_from_mtu_72_i
> pv4 ->  ^C[-- Signal caught; please wait for cleanup --]
>
> Sleeping thread (tid 100505, pid 61414) owns a non-sleepable lock
> KDB: stack backtrace of thread 100505:
> sched_switch() at sched_switch+0x5b2/frame 0xfffffe00627165a0
> mi_switch() at mi_switch+0x155/frame 0xfffffe00627165c0
> sleepq_switch() at sleepq_switch+0x109/frame 0xfffffe0062716600
> _sx_xlock_hard() at _sx_xlock_hard+0x42e/frame 0xfffffe00627166a0
> _sx_xlock() at _sx_xlock+0xba/frame 0xfffffe00627166e0
> tunifioctl() at tunifioctl+0x31/frame 0xfffffe0062716720
> ifhwioctl() at ifhwioctl+0x46b/frame 0xfffffe00627167a0
> tunioctl() at tunioctl+0x5b1/frame 0xfffffe0062716810
> devfs_ioctl() at devfs_ioctl+0xcc/frame 0xfffffe0062716860
> vn_ioctl() at vn_ioctl+0x132/frame 0xfffffe0062716970
> devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfffffe0062716990
> kern_ioctl() at kern_ioctl+0x28e/frame 0xfffffe0062716a00
> sys_ioctl() at sys_ioctl+0x127/frame 0xfffffe0062716ad0
> amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe0062716bf0
> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0062716bf0
> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8005818fa, rsp =
> 0x7fffffffd408, rbp = 0x7fffffffd540 ---
> panic: sleeping thread
> cpuid = 4
> time = 1597942792
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfffffe00652545e0
> vpanic() at vpanic+0x182/frame 0xfffffe0065254630
> panic() at panic+0x43/frame 0xfffffe0065254690
> propagate_priority() at propagate_priority+0x219/frame 0xfffffe00652546d0
> turnstile_wait() at turnstile_wait+0x380/frame 0xfffffe0065254720
> __mtx_lock_sleep() at __mtx_lock_sleep+0x1cc/frame 0xfffffe00652547b0
> __mtx_lock_flags() at __mtx_lock_flags+0xe5/frame 0xfffffe0065254800
> tunifioctl() at tunifioctl+0xdc/frame 0xfffffe0065254840
> ifhwioctl() at ifhwioctl+0x2b1/frame 0xfffffe00652548c0
> ifioctl() at ifioctl+0x395/frame 0xfffffe0065254990
> kern_ioctl() at kern_ioctl+0x28e/frame 0xfffffe0065254a00
> sys_ioctl() at sys_ioctl+0x127/frame 0xfffffe0065254ad0
> amd64_syscall() at amd64_syscall+0x140/frame 0xfffffe0065254bf0
> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0065254bf0
> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004b48fa, rsp =
> 0x7fffffffd428, rbp = 0x7fffffffdc50 ---
> KDB: enter: panic
> [ thread pid 61418 tid 100573 ]
> Stopped at      kdb_enter+0x37: movq    $0,0x10b70b6(%rip)
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 20 Aug 2020 16:41:59 -0500
> From: Clay Daniels <[hidden email]>
> To: "[hidden email]" <[hidden email]>
> Subject: Weekly Current 13.0 Snapshot?
> Message-ID:
> <CAGLDxTWTrku-BAcaaEgeA_hi-
zQ3fz80=[hidden email]>

> Content-Type: text/plain; charset="UTF-8"
>
> I hope nobody is ill & just busy filling the weekly snapshot of 13.0
> Current with new goodies. I don't see it at it's usual location:
>
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/
>
> Clay
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 20 Aug 2020 21:47:06 +0000
> From: Glen Barber <[hidden email]>
> To: Clay Daniels <[hidden email]>
> Cc: "[hidden email]" <[hidden email]>
> Subject: Re: Weekly Current 13.0 Snapshot?
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset="us-ascii"
>
> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote:
> > I hope nobody is ill & just busy filling the weekly snapshot of 13.0
> > Current with new goodies. I don't see it at it's usual location:
> >
> > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/
>
> Not ill, but indeed sick of the build being broken so much.
>
> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.htm
> l
>
> Glen
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: not available
> URL:
> <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20200820/db
> dfc32d/attachment-0001.sig>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 20 Aug 2020 15:54:37 -0600
> From: Warner Losh <[hidden email]>
> To: Glen Barber <[hidden email]>
> Cc: Clay Daniels <[hidden email]>,
> "[hidden email]" <[hidden email]>
> Subject: Re: Weekly Current 13.0 Snapshot?
> Message-ID:
>
<CANCZdfq=-[hidden email]>

> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber <[hidden email]> wrote:
> > On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote:
> > > I hope nobody is ill & just busy filling the weekly snapshot of 13.0
> > > Current with new goodies. I don't see it at it's usual location:
> > >
> > > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/
> >
> > Not ill, but indeed sick of the build being broken so much.
> >
> >
> > https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.h
> > tml
> Build isn't broken now, can't you just run it again?
>
> Warner
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 20 Aug 2020 18:38:58 -0400
> From: Glen Barber <[hidden email]>
> To: Warner Losh <[hidden email]>
> Cc: Clay Daniels <[hidden email]>,
> "[hidden email]" <[hidden email]>
> Subject: Re: Weekly Current 13.0 Snapshot?
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=utf-8
>
> Not without putting a wedge in place with updating scripts for the git
> conversion, which as you know, I am already past the deadline.
>
> Glen
> Sent from my phone.
> Please excuse my brevity and/or typos.
>
> > On Aug 20, 2020, at 5:54 PM, Warner Losh <[hidden email]> wrote:
> >
> > ?
> >
> >> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber <[hidden email]> wrote:
> >>
> >> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote:
> >> > I hope nobody is ill & just busy filling the weekly snapshot of 13.0
> >> > Current with new goodies. I don't see it at it's usual location:
> >> >
> >> > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/
> >>
> >> Not ill, but indeed sick of the build being broken so much.
> >>
> >> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.
> >> html>
> > Build isn't broken now, can't you just run it again?
> >
> > Warner
>
> ------------------------------
>
> Message: 9
> Date: Thu, 20 Aug 2020 18:43:19 -0500
> From: Clay Daniels <[hidden email]>
> To: Glen Barber <[hidden email]>
> Cc: Warner Losh <[hidden email]>,  "[hidden email]"
> <[hidden email]>
> Subject: Re: Weekly Current 13.0 Snapshot?
> Message-ID:
> <CAGLDxTUo8XMh-ZfjBLs_E-
WN251hqAb9JEwUwicSPR=[hidden email]>

> Content-Type: text/plain; charset="UTF-8"
>
> Sorry to bug you. I didn't even know about the snapshot email list, but I
> have just subscribed and will know next time. Do what you need to and don't
> worry about the snapshot this week. I too am busy this week and have plenty
> to do.
>
> Clay
>
> On Thu, Aug 20, 2020 at 5:39 PM Glen Barber <[hidden email]> wrote:
> > Not without putting a wedge in place with updating scripts for the git
> > conversion, which as you know, I am already past the deadline.
> >
> > Glen
> > Sent from my phone.
> > Please excuse my brevity and/or typos.
> >
> > On Aug 20, 2020, at 5:54 PM, Warner Losh <[hidden email]> wrote:
> >
> > ?
> >
> > On Thu, Aug 20, 2020 at 3:47 PM Glen Barber <[hidden email]> wrote:
> >> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote:
> >> > I hope nobody is ill & just busy filling the weekly snapshot of 13.0
> >> > Current with new goodies. I don't see it at it's usual location:
> >> >
> >> > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/
> >>
> >> Not ill, but indeed sick of the build being broken so much.
> >>
> >>
> >> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.
> >> html>
> > Build isn't broken now, can't you just run it again?
> >
> > Warner
>
> ------------------------------
>
> Message: 10
> Date: Thu, 20 Aug 2020 19:48:23 -0400
> From: Glen Barber <[hidden email]>
> To: Clay Daniels <[hidden email]>
> Cc: Warner Losh <[hidden email]>, "[hidden email]"
> <[hidden email]>
> Subject: Re: Weekly Current 13.0 Snapshot?
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=utf-8
>
> Not bugging at all.
>
> I?m hoping that the state that machine is in now, with some sanding off some
> newly-discovered rough edges of some code changes, to have snapshots from
> git before Wednesday.
>
> Fingers crossed....
>
> Glen
> Sent from my phone.
> Please excuse my brevity and/or typos.
>
> > On Aug 20, 2020, at 7:43 PM, Clay Daniels <[hidden email]>
> > wrote:
> >
> > ?
> > Sorry to bug you. I didn't even know about the snapshot email list, but I
> > have just subscribed and will know next time. Do what you need to and
> > don't worry about the snapshot this week. I too am busy this week and
> > have plenty to do.
> >
> > Clay
> >
> >> On Thu, Aug 20, 2020 at 5:39 PM Glen Barber <[hidden email]> wrote:
> >> Not without putting a wedge in place with updating scripts for the git
> >> conversion, which as you know, I am already past the deadline.
> >>
> >> Glen
> >> Sent from my phone.
> >> Please excuse my brevity and/or typos.
> >>
> >>>> On Aug 20, 2020, at 5:54 PM, Warner Losh <[hidden email]> wrote:
> >>> ?
> >>>
> >>>> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber <[hidden email]> wrote:
> >>>>
> >>>> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote:
> >>>> > I hope nobody is ill & just busy filling the weekly snapshot of 13.0
> >>>> > Current with new goodies. I don't see it at it's usual location:
> >>>> >
> >>>> > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.
> >>>> > 0/
> >>>>
> >>>> Not ill, but indeed sick of the build being broken so much.
> >>>>
> >>>> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/00073
> >>>> 9.html>>>
> >>> Build isn't broken now, can't you just run it again?
> >>>
> >>> Warner
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[hidden email]"
>
>
> ------------------------------
>
> End of freebsd-current Digest, Vol 877, Issue 6
> ***********************************************




_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"