On 2020-08-20 16:43, Andreas Nilsson wrote:
On Thu, Aug 20, 2020 at 2:48 PM Vanbreukelingen Ltd.
<lizbethmutterh...@gmail.com <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
<mailto: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: <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
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
