vmm computer freeze
Hi all, Occasionally when I start a VM (Alpine v3.19) the host computer freezes solid and requires a hard power off. It is not consistent but it does seem more stable when I have fewer things running on the computer. If I have a desktop running, web browser, video player, editor, etc. then starting a VM seems to cause the freeze more often... I can't say that with certainty though but maybe I am running into some kernel limit? The computer is running -current but the issue has been there since I first installed OpenBSD on the computer with the 7.5 release. Any input on how to debug this? Or other pointers? dmesg, vm.conf, and sysctl.conf attached. Thanks in advance, Justin OpenBSD 7.5-current (GENERIC.MP) #139: Tue Jun 18 00:36:27 MDT 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16876576768 (16094MB) avail mem = 16341819392 (15584MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x5fcd1000 (81 entries) bios0: vendor Dell Inc. version "1.9.6" date 09/13/2021 bios0: Dell Inc. Latitude 7520 efi0 at bios0: UEFI 2.7 efi0: Dell rev 0x1 acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP SSDT SSDT HPET APIC MCFG SSDT NHLT SSDT SSDT SSDT SSDT LPIT WSMT SSDT SSDT DBGP DBG2 BOOT SSDT TPM2 MSDM DMAR SSDT SSDT ASF! PTDT BGRT FPDT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) XHCI(S0) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz, 4788.96 MHz, 06-8c-01, patch 00b6 cpu0: cpuid 1 edx=bfebfbff ecx=77fafbff cpu0: cpuid 6 eax=17eff7 ecx=9 cpu0: cpuid 7.0 ebx=f3bfa7eb ecx=18c07fce edx=fc100710 cpu0: cpuid a vers=5, gp=8, gpwidth=48, ff=4, ffwidth=48 cpu0: cpuid d.1 eax=f cpu0: cpuid 8001 edx=2c100800 ecx=121 cpu0: cpuid 8007 edx=100 cpu0: msr 10a=a005c6b cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 12MB 64b/line 12-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 38MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz, 4788.97 MHz, 06-8c-01, patch 00b6 cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz, 4290.12 MHz, 06-8c-01, patch 00b6 cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz, 3989.05 MHz, 06-8c-01, patch 00b6 cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz, 3922.99 MHz, 06-8c-01, patch 00b6 cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz, 3881.63 MHz, 06-8c-01, patch 00b6 cpu5: smt 1, core 1, package 0 cpu6 at mainbus0: apid 5 (application processor) cpu6: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz, 3830.44 MHz, 06-8c-01, patch 00b6 cpu6: smt 1, core 2, package 0 cpu7 at mainbus0: apid 7 (application processor) cpu7: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz, 3803.06 MHz, 06-8c-01, patch 00b6 cpu7: smt 1, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xc000, bus 0-255 acpiprt0 at acpi0: bus 0 (PC00) acpiprt1 at acpi0: bus 1 (PEG0) acpiprt2 at acpi0: bus -1 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus -1 (RP04) acpiprt6 at acpi0: bus -1 (RP05) acpiprt7 at acpi0: bus -1 (RP06) acpiprt8 at acpi0: bus 114 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (RP09) acpiprt11 at acpi0: bus -1 (RP10) acpiprt12 at acpi0: bus -1 (RP11) acpiprt13 at acpi0: bus -1 (RP12) acpiprt14 at acpi0: bus -1 (RP13) acpiprt15 at acpi0: bus -1 (RP14) acpiprt16 at acpi0: bus -1 (RP15) acpiprt17 at acpi0: bus -1 (RP16) acpiprt18 at acpi0: bus -1 (RP17) acpiprt19 at acpi0: bus -1 (RP18) acpiprt20 at acpi0: bus -1 (RP19) acpiprt21 at acpi0: bus -1 (RP20) acpiprt22 at acpi0: bus -1 (RP21) acpiprt23 at acpi0: bus -1 (RP22) acpiprt24 at acpi0: bus -1 (RP23) acpiprt25 at acpi0: bus -1 (RP24) acpiprt26 at acpi0: bus 2 (TRP0) acpiprt27 at acpi0: bus 58 (TRP1) acpiec0 at acpi0 acpipci0 at acpi0 PC00: 0x 0x0011 0x0001 acpicmos0 at acpi0 "INT33D2" at acpi0 not configured "INT33D3" at acpi0 not configured "INTC1043" at acpi0 not configured "INTC1043" at acpi0 not configured "INTC1043" at acpi0 not
Re: Open Source / BSD License Copyright infringements
On Thu, 2024-06-06 at 12:10 +0100, Kirill A.Korinsky wrote: > > This door has already been opened, and the most notable case I > suppose is > that Linux developers took some code from BSD and put GPL on it: > https://marc.info/?l=linux-wireless=117572345902445=2 > Just to clarify this point, it was the other way around. Someone working on a driver for OpenBSD was using GPL'd code privately to inspire their development and accidentally committed GPL'd code to the public OpenBSD repo. There was a simple fix, but there was weeping and gnashing of teeth so the developer deleted it all. Tempest in a teapot, in my opinion, and understandable response from the developer. Justin
Re: cwm on wayland
On Sat, 2023-12-16 at 00:22 +0100, Anders Andersson wrote: > On Fri, Dec 15, 2023 at 7:01 PM David Coppa wrote: > > > > On Fri, Dec 15, 2023 at 6:29 PM wrote: > > > > > > So they're putting a Wayland in our BSD. > > > > > > I've never used that before. > > > > > > Is a port of cwm planned? > > > > I really don't think so. > > > > But there's hikari, a stacking Wayland compositor heavily inspired > > by > > cwm: https://hikari.acmelabs.space/ > > > > We might probably have a port of it in our ports tree in the > > future. > > > > Ciao, > > David > > > > I'm not sure their "Geekfeminism Code of Conduct" > (https://hikari.acmelabs.space/coc.html) works well with OpenBSD. > You put "Geekfeminism" in the same quotes as "Code of Conduct".. I suspect you did so for a reason. "Geekfeminism" does not exist on the Hikari page at all. It is the reason that I don't understand. To be fair, I find it unfortuante that any projet needs to have a Code of Conduct, but for whatever reason that is the way the world is going. People are rude against others because of their identity or other reasons not related to the goals of the project. I don't thnk I have ever seen anyone from OpenBSD be rude against anyone because of their idenity. They will be rude with people who expect things and don't contribute, but that is unrelated. There is a non-subtle and significant difference. The license of the Hikari project looks (at a quick glance) seems to to be a 2-clause BSD license. So why would OpenBSD have issues with this? You are not a dev, but considering you posted this publicly I am interested in your response. What was the reason? Justin
Re: What could cause high CPU load averages (no actual CPU usage)?
On Fri, 2023-10-27 at 10:49 +0200, Claudio Jeker wrote: > On Fri, Oct 27, 2023 at 01:54:28AM +0200, Justin Yates Fletcher > wrote: > > On Wed, 2023-10-25 at 20:25 -0400, Raul Miller wrote: > > > On Wed, Oct 25, 2023 at 8:16 PM Justin Yates Fletcher > > > wrote: > > > > On Wed, 2023-10-25 at 21:12 +0200, Mike Fischer wrote: > > > > > > > > > > > Am 25.10.2023 um 17:57 schrieb Theo de Raadt > > > > > > : > > > > > > Mike Fischer wrote: > > > > > > > > Am 25.10.2023 um 17:29 schrieb Theo de Raadt > > > > > > We changed a lot of kernel scheduling code *without giving > > > > > > a > > > > > > damn > > > > > > about the stability of this number* > > > > > > > > > > Fine, but you are not changing my running Kernel, are you? > > > > > > > > I don't understand your point with this. Are you making an > > > > accusation? > > > > If not, then why even write this? > > > > > > I think Mike Fischer's point was that the change did not > > > correspond > > > to > > > a kernel upgrade. > > > > > > > It is hyperbole or accusational... or somewhere on that spectrum. > > Either way, it serves no valuable purpose, so why even write that? > > > > Also, there was a kernel change: 7.4. Pretty sure that was > > mentioned. > > > > > > > (And I think Theo de Raadt's point was that there's not enough > > > rigor > > > on load average to diagnose this issue.) > > > > > > > Theo's point, as I read it, was just that the load average is > > calculated in the same way as before, even though there have been > > changes in other parts of the system that could affect it. > > Just to be clear. There was a change in how the load avarage is > calculated. So it may cause differences in numbers. Do we care about > that? > No because it was done to be able to work on more important projects. > Thanks for the clarification. Maybe I misread. > > > It has nothing to do with rigor. The OS could just always report > > 0.0. > > If you start artifically changing a metric, for the sake of rigor, > > then > > that metric is no longer valuable: > > > > https://en.wikipedia.org/wiki/Goodhart%27s_law > > > > Changing how a mertic is calculated to meet a target certainly > > reduces > > the value of the metric, right? > > I do not agree. The load avarage has some value but most people do > not > understand how it is calculated and what a significant change is. > Also systems change, so metrics change all the time. They still offer > a > good value. > I'm not wanting to get too pedantic, but I'm not quite understanding what you disagree with? My point with this part is just to address the usage of the word "rigor" in regards to calculating the load average. The OP was stating that he would remove load average from his metric collection. I don't think that is a good idea and tried to convey that to him. It is a valuable metric and, like many others, context matters (as you wrote). In response, it was said that Theo implied not enough rigor was applied on load average to diagnose the perceived issue. What I wrote above is in response to specifically that. Goodhart's law popped into my head because it sounded like turning a metric into a target, and the problems of doing so... but maybe I shouldn't have posted that. It might have just confused the point. Anyway, Theo posted a diff on misc@ many years ago (close to 20 maybe?) where the load average would just return 0, in reply to someone complaining about it. So, saying that not enough "rigor" is applied to load average calculation kinda triggered that memory and the response. Justin
Re: What could cause high CPU load averages (no actual CPU usage)?
On Wed, 2023-10-25 at 20:25 -0400, Raul Miller wrote: > On Wed, Oct 25, 2023 at 8:16 PM Justin Yates Fletcher > wrote: > > On Wed, 2023-10-25 at 21:12 +0200, Mike Fischer wrote: > > > > > > > Am 25.10.2023 um 17:57 schrieb Theo de Raadt > > > > : > > > > Mike Fischer wrote: > > > > > > Am 25.10.2023 um 17:29 schrieb Theo de Raadt > > > > We changed a lot of kernel scheduling code *without giving a > > > > damn > > > > about the stability of this number* > > > > > > Fine, but you are not changing my running Kernel, are you? > > > > I don't understand your point with this. Are you making an > > accusation? > > If not, then why even write this? > > I think Mike Fischer's point was that the change did not correspond > to > a kernel upgrade. > It is hyperbole or accusational... or somewhere on that spectrum. Either way, it serves no valuable purpose, so why even write that? Also, there was a kernel change: 7.4. Pretty sure that was mentioned. > (And I think Theo de Raadt's point was that there's not enough rigor > on load average to diagnose this issue.) > Theo's point, as I read it, was just that the load average is calculated in the same way as before, even though there have been changes in other parts of the system that could affect it. It has nothing to do with rigor. The OS could just always report 0.0. If you start artifically changing a metric, for the sake of rigor, then that metric is no longer valuable: https://en.wikipedia.org/wiki/Goodhart%27s_law Changing how a mertic is calculated to meet a target certainly reduces the value of the metric, right? Justin
Re: What could cause high CPU load averages (no actual CPU usage)?
On Wed, 2023-10-25 at 21:12 +0200, Mike Fischer wrote: > > > Am 25.10.2023 um 17:57 schrieb Theo de Raadt : > > > > Mike Fischer wrote: > > > > > > Am 25.10.2023 um 17:29 schrieb Theo de Raadt > > > > : > > > > > > > > Mike Fischer wrote: > > > > > > > > > True. But like I said, this was noticed because of the sudden > > > > > increase on the same (OpenBSD) machine without any obvious > > > > > reason. > > > > > > > > The reason is obvious. > > > > > > > > You installed a completely different system. > > > > > > No, there is a misunderstanding here. I have not been comparing > > > OpenBSD load averages to those on any other OS. > > > > No, it is *your misunderstanding* > > > > We put no effort into maintaining stability of this damn number. > > Ok, I realise that load average may too irrelevant a measurement to > take seriously. I admit that I thought this value was somewhat > consistent in the context of a single running machine, but maybe I > was wrong. > Load average is fine to measure, but I think the point you are misunderstanding is that you went from 0.0 to 0.7 (iirc). > > > We changed a lot of kernel scheduling code *without giving a damn > > about the > > stability of this number* > > Fine, but you are not changing my running Kernel, are you? > I don't understand your point with this. Are you making an accusation? If not, then why even write this? > Or are you saying that the load average does not carry *any* inherent > information and is utterly useless? That would almost imply that this > is a (poor) sort of random number generator. > Nope. That is not the case and nobody has said that. You saw a load average change from 0.0 to some other number greater than 0.0 but less than 1. You are trying to imply that this delta means something. You have been told that it does not, many times. It *can* mean something but that is only within the context of understanding other things. > OTOH years of monitoring this value (amongst many other measurements) > on OpenBSD seems to indicate some correlation to what the machine is > doing. But I get what you are saying: no guarantees. > Nope. You still have misunderstood what is being said. Especially highlighted by your saying this is a 7.4 machine and having monitored it for years... the best you could say for 7.4 is you have monitored it for almost 2 weeks. And you have said it is a VM on VMware. You have a *huge* variable you have only lightly taken into consideration. Monitoring system performance on a VM is an exercise in futility without the underlying host information. And in my experience, still an exercise in futility even given the underlying host information... It is many opaque layers of abstraction. > > > It is a different system. > > To reiterate: I am measuring load averages on OpenBSD 7.4. On a > running system I notice a sudden jump in the value which persists for > several hours. That gets my attention because I can see no reason for > this jump. So I’m trying to figure out the cause. > Your jump was less than 1. On a graph with a scale of 0 and 1, that is "huge"! Ignore that and pay attention to the value. And understand that in context. > Please note that I am not going on the assumption that there is a bug > or that something needs to be changed/fixed in OpenBSD. The jump may > have had perfectly valid reasons. Or it may have been random with a > low probability. The "jump" you mention doesn't mean anything. Without context it means less than nothing. As has already been metioned. It *might* mean that your rrd graph metric gathering is affecting your graphs in a way that you have not seen before... Monitoring uses resources! The goal is if the system is performing what it needs to be at a rate that meets the needs, then the problem is solved. Simple as that. > But given all of the feedback from this thread I’ll deprecate this > part of my monitoring and switch to monitoring actual CPU activity > (as reported by e.g. vmstat) in the hopes that these values are more > accurate/consistent and that they better reflect the workload of the > machine. > > > No! That would be a bad option, IMHO. It is a metric that can be valuable, but good system admin. is taking all the values and understanding them in context. > Thanks everyone! > Mike > Hope that helps, Justin
Re: OpenBSD Hackathons
On Fri, 2023-05-12 at 20:18 +, Katherine Mcmillan wrote: > Hi all, > > Thank you for the helpful responses, this definitely explains some > things! > > I'm looking at organizing an OpenBSD Hackathon in the National > Capital Region in Canada (could potentially be on the Gatineau, > Quebec side) but having never been to an OpenBSD Hackathon, my > interpretation might be quite different from the other Hackathons! > That's fine, and I'm going to seek inspiration from attending a > FreeBSD Hackathon, as that project makes their upcoming Hackathons > public: https://wiki.freebsd.org/Hackathon/202305 > > Thank you very much for the help and please feel free to contact me > privately if you're interested in attending (either as a volunteer or > developer) or otherwise supporting an OpenBSD Hackathon in the > National Capital Region in Canada. > > Sincerely, > Katie Hi Katie, I'll make an assumption based upon what you have written and reply to that. I have no experience with hackathons except when working for a globally recognized company that had no idea what a hackathon meant but tried to do a few. When I learned that leadership set up a process to accept what could be hacked on, and a process to determine the winning team of the hackathons, I decided to skip the events. :-( Anyway, the official OpenBSD hackathons are limited to a select group. There is no minimum size, I assume, because if these people want to meet up then they do. If you want to set up your own community OpenBSD hackathon then you will need to do the advertising, signup process, and management of the location/capacity vs signups, etc. yourself. I do hope it goes well! Justin
Re: 0.0.0.0/32 in pf's tables
God abhors a naked singularity. On Tue, 2022-11-08 at 22:47 +0300, 3 wrote: > what religion forbids using 0.0.0.0/32 in tables? 0_0 but 0/0 can be > used.. what's going on?! is the world going mad? >