Re: funny thing with the drm0

[Vanbreukelingen Ltd.]

On 2020-08-20 16:43, Andreas Nilsson wrote:



On Thu, Aug 20, 2020 at 2:48 PM Vanbreukelingen Ltd. 
mailto:lizbethmutterh...@gmail.com>> wrote:


On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote:
> On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D <
>
> lizbethmutterh...@gmail.com
> 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: 
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:  on
> > iicbb_nostop0 addr 0x1
> > Aug 19 02:51:10 current kernel: iic0:  on iicbus0
> > Aug 19 02:51:10 current kernel: iicbus1:  on
intel_gmbus0
> > Aug 19 02:51:10 current kernel: iic1:  on iicbus1
> > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0
> > Aug 19 02:51:10 current kernel: iicbus2:  on
> > iicbb_nostop1 addr 0x12
> > Aug 19 02:51:10 current kernel: iic2:  on iicbus2
> > Aug 19 02:51:10 current kernel: iicbus3:  on
intel_gmbus1
> > Aug 19 02:51:10 current kernel: iic3:  on iicbus3
> > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0
> > Aug 19 02:51:10 current kernel: iicbus4:  on
> > iicbb_nostop2 addr 0x12
> > Aug 19 02:51:10 current kernel: iic4:  on iicbus4
> > Aug 19 02:51:10 current kernel: iicbus5:  on
intel_gmbus2
> > Aug 19 02:51:10 current kernel: iic5:  on iicbus5
> > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0
> > Aug 19 02:51:10 current kernel: iicbus6:  on
> > iicbb_nostop3 addr 0x12
> > Aug 19 02:51:10 current kernel: iic6:  on iicbus6
> > Aug 19 02:51:10 current kernel: iicbus7:  on
intel_gmbus3
> > Aug 19 02:51:10 current kernel: iic7:  on iicbus7
> > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0
> > Aug 19 02:51:10 current kernel: iicbus8:  on
> > iicbb_nostop4 addr 0x12
> > Aug 19 02:51:10 current kernel: iic8:  on iicbus8
> > Aug 19 02:51:10 current kernel: iicbus9:  on
intel_gmbus4
> > Aug 19 02:51:10 current kernel: iic9:  on iicbus9
> > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0
> > Aug 

Re: funny thing with the drm0

[Andreas Nilsson]

On Thu, Aug 20, 2020 at 2:48 PM Vanbreukelingen Ltd. <
lizbethmutterh...@gmail.com> wrote:

> On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote:
> > On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D <
> >
> > lizbethmutterh...@gmail.com> wrote:
> > > After having had some near-death-experiences in Greece I'm back to my
> > > screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-)
> > >
> > >
> > > But this is the experience with my Dell Vostro on 13 current:
> > >
> > >
> > > After finally recompiling the kernel with the drm-module inside and
> > > the trick of injecting the
> >
> > This is not the way to do it. Modern hardware require drm-kmod from
> ports,
> > or if you want the latest drm-devel-kmod. Then add  /boot/modules/drm.ko
> > and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf
> wasn't yet finished (c [see] beyond), but I guess I have to disable the
> whole
> output with something like hw.*=1 or so. is it possible to make a bootlogo
> while VEBOSE output = 2 just for the reason some kids try to play with it.
>
>
> > > device IWNFW
> doesn't install the 6000, btw --- probably can't find FW on device HAL.


> > Again, this is not needed, firmware is autoloaded on module load. Just
> add
> > if_iwn to kld_list in /etc/rc.conf
>

Here I admit I was wrong, iwn handles it differently than iwm. The man page
lists 3 different firmware versions for the 6000 series, which can be
loaded from loader.conf


> built 15 hours of NanoBSD while finishing the nightly built someone was on
> Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at all but
> some
> reason tells me behind this system in system is something to beat beastie
> in
> killing KFC forks.
>
>
> > > I get a *nice* message a bootup:
> > >
> > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0
> 20060810
> > > Aug 19 02:51:10 current kernel: drmn0:  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:  on
> > > iicbb_nostop0 addr 0x1
> > > Aug 19 02:51:10 current kernel: iic0:  on iicbus0
> > > Aug 19 02:51:10 current kernel: iicbus1:  on
> intel_gmbus0
> > > Aug 19 02:51:10 current kernel: iic1:  on iicbus1
> > > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0
> > > Aug 19 02:51:10 current kernel: iicbus2:  on
> > > iicbb_nostop1 addr 0x12
> > > Aug 19 02:51:10 current kernel: iic2:  on iicbus2
> > > Aug 19 02:51:10 current kernel: iicbus3:  on
> intel_gmbus1
> > > Aug 19 02:51:10 current kernel: iic3:  on iicbus3
> > > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0
> > > Aug 19 02:51:10 current kernel: iicbus4:  on
> > > iicbb_nostop2 addr 0x12
> > > Aug 19 02:51:10 current kernel: iic4:  on iicbus4
> > > Aug 19 02:51:10 current kernel: iicbus5:  on
> intel_gmbus2
> > > Aug 19 02:51:10 current kernel: iic5:  on iicbus5
> > > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0
> > > Aug 19 02:51:10 current kernel: iicbus6:  on
> > > iicbb_nostop3 addr 0x12
> > > Aug 19 02:51:10 current kernel: iic6:  on iicbus6
> > > Aug 19 02:51:10 current kernel: iicbus7:  on
> intel_gmbus3
> > > Aug 19 02:51:10 current kernel: iic7:  on iicbus7
> > > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0
> > > Aug 19 02:51:10 current kernel: iicbus8:  on
> > > iicbb_nostop4 addr 0x12
> > > Aug 19 02:51:10 current kernel: iic8:  on iicbus8
> > > Aug 19 02:51:10 current kernel: iicbus9:  on
> intel_gmbus4
> > > Aug 19 02:51:10 current kernel: iic9:  on iicbus9
> > > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0
> > > Aug 19 02:51:10 current kernel: iicbus10:  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 0xe000-0xf000
> > > 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]   - 

Re: funny thing with the drm0

[Vanbreukelingen Ltd.]

On Thursday, August 20, 2020 8:12:58 AM CEST Vanbreukelingen Ltd. wrote:
> On Wednesday, August 19, 2020 9:43:21 AM CEST you wrote:
> > On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D <
> > 
> > lizbethmutterh...@gmail.com> wrote:
> > > After having had some near-death-experiences in Greece I'm back to my
> > > screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-)
> > > 
> > > 
> > > But this is the experience with my Dell Vostro on 13 current:
> > > 
> > > 
> > > After finally recompiling the kernel with the drm-module inside and
> > > the trick of injecting the
> > 
> > This is not the way to do it. Modern hardware require drm-kmod from ports,
> > or if you want the latest drm-devel-kmod. Then add  /boot/modules/drm.ko
> > and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf

wasn't yet finished (c [see] beyond), but I guess I have to disable the whole 
output with something like hw.*=1 or so. is it possible to make a
bootlogo while VEBOSE output = 2 just for the reason some kids try to play
with it.
> > > device IWNFW
> 
 doesn't install the 6000, btw --- probably can't find FW on device HAL.
> 
> > Again, this is not needed, firmware is autoloaded on module load. Just add
> > if_iwn to kld_list in /etc/rc.conf
> 
 built of 15 hours of NanoBSD while finishing the nightly built someone was on
Ctrl-C. So _i.w (installworld) is 5MB "thick" and doesn't boot at all but
some reason tells me behind this system in system is something to beat
beastie in killing KFC forks. ;-)
> 
> > > I get a *nice* message a bootup:
> > > 
> > > Aug 19 02:51:10 current kernel: info: [drm] Initialized drm 1.1.0
> > > 20060810
> > > Aug 19 02:51:10 current kernel: drmn0:  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:  on
> > > iicbb_nostop0 addr 0x1
> > > Aug 19 02:51:10 current kernel: iic0:  on iicbus0
> > > Aug 19 02:51:10 current kernel: iicbus1:  on
> > > intel_gmbus0
> > > Aug 19 02:51:10 current kernel: iic1:  on iicbus1
> > > Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0
> > > Aug 19 02:51:10 current kernel: iicbus2:  on
> > > iicbb_nostop1 addr 0x12
> > > Aug 19 02:51:10 current kernel: iic2:  on iicbus2
> > > Aug 19 02:51:10 current kernel: iicbus3:  on
> > > intel_gmbus1
> > > Aug 19 02:51:10 current kernel: iic3:  on iicbus3
> > > Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0
> > > Aug 19 02:51:10 current kernel: iicbus4:  on
> > > iicbb_nostop2 addr 0x12
> > > Aug 19 02:51:10 current kernel: iic4:  on iicbus4
> > > Aug 19 02:51:10 current kernel: iicbus5:  on
> > > intel_gmbus2
> > > Aug 19 02:51:10 current kernel: iic5:  on iicbus5
> > > Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0
> > > Aug 19 02:51:10 current kernel: iicbus6:  on
> > > iicbb_nostop3 addr 0x12
> > > Aug 19 02:51:10 current kernel: iic6:  on iicbus6
> > > Aug 19 02:51:10 current kernel: iicbus7:  on
> > > intel_gmbus3
> > > Aug 19 02:51:10 current kernel: iic7:  on iicbus7
> > > Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0
> > > Aug 19 02:51:10 current kernel: iicbus8:  on
> > > iicbb_nostop4 addr 0x12
> > > Aug 19 02:51:10 current kernel: iic8:  on iicbus8
> > > Aug 19 02:51:10 current kernel: iicbus9:  on
> > > intel_gmbus4
> > > Aug 19 02:51:10 current kernel: iic9:  on iicbus9
> > > Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0
> > > Aug 19 02:51:10 current kernel: iicbus10:  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 0xe000-0xf000
> > > 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]   -
> > > 

Re: funny thing with the drm0

[Andreas Nilsson]

On Wed, Aug 19, 2020 at 3:22 AM Lizbeth Mutterhunt, Ph.D <
lizbethmutterh...@gmail.com> wrote:

> After having had some near-death-experiences in Greece I'm back to my
> screens. As horizon arises, BSD gets up --- and if it is 3 a.m.! :-)
>
>
> But this is the experience with my Dell Vostro on 13 current:
>
>
> After finally recompiling the kernel with the drm-module inside and
> the trick of injecting the
>

This is not the way to do it. Modern hardware require drm-kmod from ports,
or if you want the latest drm-devel-kmod. Then add  /boot/modules/drm.ko
and /boot/modules/i915kms.ko to kld_list in /etc/rc.conf


>
> device IWNFW
>

Again, this is not needed, firmware is autoloaded on module load. Just add
if_iwn to kld_list in /etc/rc.conf

>
> 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:  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:  on
> iicbb_nostop0 addr 0x1
> Aug 19 02:51:10 current kernel: iic0:  on iicbus0
> Aug 19 02:51:10 current kernel: iicbus1:  on intel_gmbus0
> Aug 19 02:51:10 current kernel: iic1:  on iicbus1
> Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0
> Aug 19 02:51:10 current kernel: iicbus2:  on
> iicbb_nostop1 addr 0x12
> Aug 19 02:51:10 current kernel: iic2:  on iicbus2
> Aug 19 02:51:10 current kernel: iicbus3:  on intel_gmbus1
> Aug 19 02:51:10 current kernel: iic3:  on iicbus3
> Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0
> Aug 19 02:51:10 current kernel: iicbus4:  on
> iicbb_nostop2 addr 0x12
> Aug 19 02:51:10 current kernel: iic4:  on iicbus4
> Aug 19 02:51:10 current kernel: iicbus5:  on intel_gmbus2
> Aug 19 02:51:10 current kernel: iic5:  on iicbus5
> Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0
> Aug 19 02:51:10 current kernel: iicbus6:  on
> iicbb_nostop3 addr 0x12
> Aug 19 02:51:10 current kernel: iic6:  on iicbus6
> Aug 19 02:51:10 current kernel: iicbus7:  on intel_gmbus3
> Aug 19 02:51:10 current kernel: iic7:  on iicbus7
> Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0
> Aug 19 02:51:10 current kernel: iicbus8:  on
> iicbb_nostop4 addr 0x12
> Aug 19 02:51:10 current kernel: iic8:  on iicbus8
> Aug 19 02:51:10 current kernel: iicbus9:  on intel_gmbus4
> Aug 19 02:51:10 current kernel: iic9:  on iicbus9
> Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0
> Aug 19 02:51:10 current kernel: iicbus10:  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 0xe000-0xf000
> 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 

funny thing with the drm0

[Lizbeth Mutterhunt, Ph.D]

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

device IWNFW

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:  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:  on
iicbb_nostop0 addr 0x1
Aug 19 02:51:10 current kernel: iic0:  on iicbus0
Aug 19 02:51:10 current kernel: iicbus1:  on intel_gmbus0
Aug 19 02:51:10 current kernel: iic1:  on iicbus1
Aug 19 02:51:10 current kernel: intel_iicbb1 on drmn0
Aug 19 02:51:10 current kernel: iicbus2:  on
iicbb_nostop1 addr 0x12
Aug 19 02:51:10 current kernel: iic2:  on iicbus2
Aug 19 02:51:10 current kernel: iicbus3:  on intel_gmbus1
Aug 19 02:51:10 current kernel: iic3:  on iicbus3
Aug 19 02:51:10 current kernel: intel_iicbb2 on drmn0
Aug 19 02:51:10 current kernel: iicbus4:  on
iicbb_nostop2 addr 0x12
Aug 19 02:51:10 current kernel: iic4:  on iicbus4
Aug 19 02:51:10 current kernel: iicbus5:  on intel_gmbus2
Aug 19 02:51:10 current kernel: iic5:  on iicbus5
Aug 19 02:51:10 current kernel: intel_iicbb3 on drmn0
Aug 19 02:51:10 current kernel: iicbus6:  on
iicbb_nostop3 addr 0x12
Aug 19 02:51:10 current kernel: iic6:  on iicbus6
Aug 19 02:51:10 current kernel: iicbus7:  on intel_gmbus3
Aug 19 02:51:10 current kernel: iic7:  on iicbus7
Aug 19 02:51:10 current kernel: intel_iicbb4 on drmn0
Aug 19 02:51:10 current kernel: iicbus8:  on
iicbb_nostop4 addr 0x12
Aug 19 02:51:10 current kernel: iic8:  on iicbus8
Aug 19 02:51:10 current kernel: iicbus9:  on intel_gmbus4
Aug 19 02:51:10 current kernel: iic9:  on iicbus9
Aug 19 02:51:10 current kernel: intel_iicbb5 on drmn0
Aug 19 02:51:10 current kernel: iicbus10:  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 0xe000-0xf000
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

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.

To disable WITNESS would be one way I think but this can't be the
yellw of the egg, isn't it?

Another thing but I guess having