How to build with VMM_DEBUG
I'm trying to hunt down a recent breakage with my VMM virtual machines refusing to start, and I'm getting errors like this: vcpu_run_loop: vm 5 / vcpu 0 run ioctl failed: Invalid argument It looks like previous requests for help with this error have resulted in being asked to build with the VMM_DEBUG macro, but I don't know how to do that. I do not see VMM_DEBUG in the GENERIC config, and just a few ifdefs in the code. I'd like to gather more info to provide a more complete bug report. Ideas? --ax0n
Re: hyper-threading...
On Fri, 22 Jun 2018 13:18:31 -0700 > The current release (not distro) already has a fix for it: > https://ftp.openbsd.org/pub/OpenBSD/patches/6.3/common/010_intelfpu.patch.sig That is the FPU fix. The hyper threading has landed in current/snapshots but not in stable yet. Also, I expect the code is disabling at the OS level and so will not help other OS, like a bios switch could. The hyper threading performance change may not affect other OS atleast in the same way either.
Re: hyper-threading...
On 22 June 2018 at 13:14, Dan Campbell wrote: > Just saw the news about you disabling hyper-threading by default on Intel > CPUs for security reasons, which I agree with. It would be nice to be able > to do this on systems that don't have a toggle for it in the BIOS, as it > increases single-threaded performance. So just wondering when your latest > distro will be coming out with this change, as I see your current version > came out in April? I would like to create a Linux live DVD/flash drive that > I could boot to toggle hyper-threading off on Intel systems running Windows, > or to create a dual-boot situation for those who want to use Linux part-time. > It could also be useful for updating processor microcode, which can't be > done under Windows. Thanks, > The current release (not distro) already has a fix for it: https://ftp.openbsd.org/pub/OpenBSD/patches/6.3/common/010_intelfpu.patch.sig Download 6.3 run syspatch, which will fetch all available patches for 6.3: https://www.openbsd.org/errata63.html > Dan -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info
hyper-threading...
Just saw the news about you disabling hyper-threading by default on Intel CPUs for security reasons, which I agree with. It would be nice to be able to do this on systems that don't have a toggle for it in the BIOS, as it increases single-threaded performance. So just wondering when your latest distro will be coming out with this change, as I see your current version came out in April? I would like to create a Linux live DVD/flash drive that I could boot to toggle hyper-threading off on Intel systems running Windows, or to create a dual-boot situation for those who want to use Linux part-time. It could also be useful for updating processor microcode, which can't be done under Windows. Thanks, Dan
Restoring MIPS32 support as a private project
So, I have a mipsel-none-elf32 bare-metal Clang/LLVM cross-compiler (and the
corresponding bare-metal GNU cross-binutils), and the platform-specific code
('sys/mips/mips' and 'sys/mips/broadcom') from the FreeBSD source tree as a
starting point.
Are there any other specific considerations to bootstrapping OpenBSD using
the cross-compiler? The target is a router (128MB flash, 128MB RAM), so a
native build is probably impractical, I plan to attach urndis(4) devices to
its lone USB port primarily.
(Yes, I plan to do the porting myself, just wanted to ask about any build
system specifics. There isn't much in the way of documentation re: porting
OpenBSD to a "new" architecture.)
Thanks
R
Re: New laptop recommendations
X200 is a bad idea, Core 2 Duos will never get microcode updates for Spectre bugs. -- Patrick Harper paia...@fastmail.com On Thu, 21 Jun 2018, at 08:30, flipchan wrote: > I got the x200 with libreboot and openbsd > > On June 19, 2018 10:47:24 AM UTC, Kaya Saman wrote: > >I couldn't say for the compatibility with OpenBSD though I have read > >other people running on them, but how about Lenovo?? > > > > > >I've got an X220 which I run a Linux distro on which I'm really happy > >with though the i7 CPU does seem to overheat for some reason, though I > >seem to have this issue with all laptops I've gone through?? Must be me > >:-S > > > >- only system that never overheated was my old PowerBook G3 Firewire > >running Mac OS 9 > > > > > >I might be remembering wrong but I'm sure I've seen people on the list > >running OBSD on X-series Lenovo's so it might be worth a shot unless > >anyone else has better suggestions :-) > > > > > >Regards, > > > > > >Kaya > > > > > >On 06/19/18 11:37, Rupert Gallagher wrote: > >> I'm done with my 10 years old 1200EUR MacBookPro. It served me well, > >every day, but is now falling apart, finally. > >> > >> I would buy a new one if only Steve Jobs would be alive and keeping > >Apple inspired. The new models are meticulously designed to make you > >suffer: expensive, slow cpu, soldered ram, soldered disk, small disk, > >bad keyboard keys, wifi only, must pay extra for standard connectors. > >> > >> I have 1500EUR for a new laptop. What would you buy with it? > > -- > Take Care Sincerely flipchan layerprox dev
Re: sndiod internals
On Wed, Jun 20, 2018 at 11:31:37PM +0200, Denis Buga wrote: > sorry for bad english no problem > if simplify, seems like we have three pairs of concepts, while in audio path > from file to card > file (Hz/bit), sndiod (Hz/bit), card (Hz/bit) > first and third is more or less i understand > by second i mean sndiod's "dsp" > i understand, that, when i set up "sndiod_flags" with frequency "N" and > "aucat" file with same "N" > - i can think about it as, simplifying, "passthrough by frequency" yes, true > seems like, the same thing i can think about "bits" in "sndiod_flags" > my question is about "ADATA_BITS" in "dsp.h": sndiod always uses ADATA_BITS internally, no matter the file format, the sound-card format or the sndiod_flags. By default, ADATA_BITS=16, so it uses 16-bit, signed, native byte order (aka "s16"). > to get "bit-perfect" audio, do i need to set this value in all the way with > file, sndiod_flags > if we say that we need "perfect line", is it nessesary to have > ADATA_BITS same as "-e ...N... " in sndiod_flags > ? With ADATA_BITS=16, the only way to get bit-perfect data is to use files with the "s16" format on a sound-card supporting "s16". The volume must be set to the maximum (-v 127 -w off), so that sndiod wont modify the samples, and only one program must be playing. Note that if the file is 8-bit or 16-bit non-native byte order, the resulting data won't have the same binary representation, but I'd qualify the resulting sound as bit-perfect. This is because the original bits representation can be recovered back from the sndiod output. As long as sndiod and the sound-card have better precision than the file, the sound restitution will be perfect (assuming there's no sample frequency conversion, volume changes, etc).
sndiod internals
sorry for bad english if simplify, seems like we have three pairs of concepts, while in audio path from file to card file (Hz/bit), sndiod (Hz/bit), card (Hz/bit) first and third is more or less i understand by second i mean sndiod's "dsp" i understand, that, when i set up "sndiod_flags" with frequency "N" and "aucat" file with same "N" - i can think about it as, simplifying, "passthrough by frequency" seems like, the same thing i can think about "bits" in "sndiod_flags" my question is about "ADATA_BITS" in "dsp.h": to get "bit-perfect" audio, do i need to set this value in all the way with file, sndiod_flags if we say that we need "perfect line", is it nessesary to have ADATA_BITS same as "-e ...N... " in sndiod_flags ? thank you
