Re: loader.conf and rootdev option for memory disk
On Fri, Nov 18, 2022 at 12:57 PM Chlasták Miroslav wrote: > Hi all, > > In the /boot/defaults/loader.conf are these options for memory disk > settings: > > #mdroot_load="YES" # The "mdroot" prefix is arbitrary. > #mdroot_type="md_image" # Create md(4) disk at boot. > #mdroot_name="/boot/root.img" # Path to a file containing the image. > #rootdev="ufs:/dev/md0" # Set the root filesystem to md(4) device. > > > But - is this example for rootdev option still right? Because > “ufs:/dev/md0” works fine on freebsd 12.1, but on freebsd 12.3 this does > not work and generates error message: > > Can’t determine root device > > > When I use this option with value “/dev/md0” or “md0” (even with this > option commented out), so the machine boots correctly without any error. > I think you want vfs.root.mountfrom= instead of rootdev= here. Warner > — > Mira >
loader.conf and rootdev option for memory disk
Hi all, In the /boot/defaults/loader.conf are these options for memory disk settings: #mdroot_load="YES" # The "mdroot" prefix is arbitrary. #mdroot_type="md_image" # Create md(4) disk at boot. #mdroot_name="/boot/root.img" # Path to a file containing the image. #rootdev="ufs:/dev/md0" # Set the root filesystem to md(4) device. But - is this example for rootdev option still right? Because “ufs:/dev/md0” works fine on freebsd 12.1, but on freebsd 12.3 this does not work and generates error message: Can’t determine root device When I use this option with value “/dev/md0” or “md0” (even with this option commented out), so the machine boots correctly without any error. — Mira
Re: ULE realtime scheduler advice needed
Quoting Hans Petter Selasky (from Fri, 18 Nov 2022 05:47:58 +0100): Hi, I'm doing some work with audio and have noticed some problems with the ULE scheduler. I have a program that generate audio based on key-presses. When no keys are pressed, the load is near 0%, but as soon as you start pressing keys, the load goes maybe to 80% of a CPU core. This program I run with rtprio 8 xxx. The issue I observe or hear actually, is that it takes too long until the scheduler grasps that this program needs it's own CPU core and stops time-sharing the program. When I however use cpuset -l xxx rtprio 8 yyy everything is good, and the program outputs realtime audio in-time. I have something in my mind about ULE not handling idleprio and/or rtprio correctly, but I have no pointer to a validation of this. Or is this perhaps a CPU frequency stepping issue? You could play with rc.conf (/etc/rc.d/power_profile): performance_cpu_freq="HIGH" performance_cx_lowest="C3" # see sysctl hw.cpu.0 | grep cx economy_cx_lowest="C3" # see sysctl hw.cpu.0 | grep cx Your system may provide other Cx possibilities, and ging to a lower number (e.g. C1) means less power-saving but faster response from the CPU (I do not expect that this is causing the issue you have). Any advice on where to look? Potential sysctl to play with to change "interactivity detection" in ULE: https://www.mail-archive.com/freebsd-stable@freebsd.org/msg112118.html Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpkBXOWiYjFT.pgp Description: Digitale PGP-Signatur
