funny thing with the drm0

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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: <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

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 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: funny thing with the drm0

Andreas Nilsson-8
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


>
> 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: <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 ?

>
> 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.

>
> 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.


>
> 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.

Best regards
Andreas Nilsson
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: funny thing with the drm0

Lizbeth Mutterhunt, Ph.D
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




_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: funny thing with the drm0

Andreas Nilsson-8
In reply to this post by Andreas Nilsson-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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: funny thing with the drm0

Lizbeth Mutterhunt, Ph.D

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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"