Re: Waking from sleep on X1 Carbon
On Sun, Aug 18, 2024 at 01:20:06PM -0600, Raymond, David wrote: > Good news! I previously reported that various generations of Lenovo X1 > Carbon laptops would occasionally hang on waking up from sleep. > > I am happy to report that the problem has apparently gone away after > upgrading to OpenBSD 7.5. > > Dave > > David J. Raymond > david.raym...@nmt.edu > http://kestrel.nmt.edu/~raymond Upgrading to 7.5 release or -current?
Re: Unable to Mount NFS Share
On Sat, Aug 03, 2024 at 01:35:11PM -0700, Aric Gregson wrote: > Hello, > > I am having a great deal of difficulty mounting a NFS shared folder on my > local network. The share is from a TrueNAS server. I am able to mount the > same share on Armbian without difficulty. > > The error that I receive is: > > mount_nfs: bad MNT RPC: RPC: Timed out > > I have tried many variations of the mount and all fail with the same error. > > doas mount address:/mnt/share /mnt/nfs > doas mount_nfs address:/mnt/share /mnt/nfs > doas mount_nfs -T -i address:/mnt/share /mnt/nfs > doas mount_nfs -2 -T -i address:/mnt/share /mnt/nfs > doas mount_nfs -3 -T -i address:/mnt/share /mnt/nfs > > This is not new for me, it has been going on for years. Just getting around > to trying it again. Any help is greatly appreciated. > > Thanks, Aric > You could try these commands from the openbsd client (replace server_ip with server's IP address or FQDN) rpcinfo -p server_ip showmount -e server_ip These should show you what RPC services are running on the server (and if they are even reachable from the client), and what mounts are exported. My guess is you either have NFSv4 only on the server, or it's not reachable for some reason.
Re: -current #168 cannot suspend with zzz
On Mon, Jul 08, 2024 at 10:01:30PM +0700, hahahahacker2009 wrote: > Vào Th 6, 5 thg 7, 2024 vào lúc 21:27 hahahahacker2009 > đã viết: > > > > Vào Th 6, 5 thg 7, 2024 vào lúc 21:18 Mike Larkin > > đã viết: > > > > > > On Fri, Jul 05, 2024 at 07:17:35PM +0700, hahahahacker2009 wrote: > > > > I'm on -current #168 (Thu Jul 4 18:00:50 MDT 2024) and I > > > > cannot suspend (sleep) my computer using zzz. When I run zzz, > > > > the screen enter power save mode, the machine seems to be > > > > sleeping: the lights on the power button goes blinking for 2s, > > > > and then the machine wake up. > > > > > > > > > > when did it last work? what snapshot? > > > > > > > I have never tried suspending OpenBSD before. > > I've just tested 7.5-stable without applying patches on the same > machine. Can't suspend either. Now I've upgraded to the snapshot. > sorry, don't know what this might be.
Re: -current #168 cannot suspend with zzz
On Fri, Jul 05, 2024 at 07:17:35PM +0700, hahahahacker2009 wrote: > I'm on -current #168 (Thu Jul 4 18:00:50 MDT 2024) and I > cannot suspend (sleep) my computer using zzz. When I run zzz, > the screen enter power save mode, the machine seems to be > sleeping: the lights on the power button goes blinking for 2s, > and then the machine wake up. > when did it last work? what snapshot? > The machine is Dell Optiplex 9020 > CPU: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz > I started apmd without flag. > > OpenBSD 7.5-current (GENERIC.MP) #168: Thu Jul 4 18:00:50 MDT 2024 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8409645056 (8020MB) > avail mem = 8131563520 (7754MB) > random: good seed from bootblocks > mpath0 at root > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe (87 entries) > bios0: vendor Dell Inc. version "A25" date 05/30/2019 > bios0: Dell Inc. OptiPlex 9020 > efi0 at bios0: UEFI 2.3.1 > efi0: American Megatrends rev 0x4028d > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT > MCFG SSDT ASF! SSDT BGRT DMAR TCPA > acpi0: wakeup devices UAR1(S3) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) > PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S4) > HDEF(S4) PEG0(S4) PEGP(S4) PEG1(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 3192.70 MHz, 06-3c-03, > patch 0028 > cpu0: cpuid 1 > edx=bfebfbff > ecx=77fafbff > cpu0: cpuid 6 eax=75 ecx=9 > cpu0: cpuid 7.0 > ebx=27ab > edx=9c000600 > cpu0: cpuid a vers=3, gp=8, gpwidth=48, ff=3, ffwidth=48 > cpu0: cpuid d.1 eax=1 > cpu0: cpuid 8001 edx=2c100800 ecx=21 > cpu0: cpuid 8007 edx=100 > cpu0: MELTDOWN > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 6MB 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 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 3192.76 MHz, 06-3c-03, > patch 0028 > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 3192.79 MHz, 06-3c-03, > patch 0028 > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 3192.86 MHz, 06-3c-03, > patch 0028 > cpu3: smt 0, core 3, package 0 > ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins > acpihpet0 at acpi0: 14318179 Hz > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-63 > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (PEG0) > acpiprt2 at acpi0: bus -1 (PEG1) > acpiprt3 at acpi0: bus -1 (PEG2) > acpiec0 at acpi0: not present > acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 > acpicmos0 at acpi0 > com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo > acpibtn0 at acpi0: PWRB(wakeup) > "PNP0C14" at acpi0 not configured > tpm0 at acpi0 TPM_ 1.2 (TIS) addr 0xfed4/0x5000, device 0x104a rev > 0x4e > acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS > acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS > acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS > acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS > acpitz0 at acpi0: critical temperature is 105 degC > acpitz1 at acpi0: critical temperature is 105 degC > acpivideo0 at acpi0: GFX0 > acpivout0 at acpivideo0: DD1F > cpu0: using VERW MDS workaround (except on vmm entry) > cpu0: Enhanced SpeedStep 3192 MHz: speeds: 3200, 3000, 2900, 2700, > 2600, 2400, 2200, 2100, 1900, 1800, 1600, 1400, 1300, 1100, 1000, 800 > MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x06 > inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 4600" rev 0x06 > drm0 at inteldrm0 > inteldrm0: msi, HASWELL, gen 7 > azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x06: msi > azalia0: No codecs found > xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI" rev 0x04: msi, xHCI 1.0 > usb0 at xhci0: USB revision 3.0 > uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev > 3.00/1.00 addr 1 > "Intel 8 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured > puc0 at pci0 dev 22 function 3 "Intel 8 Series KT" rev 0x04: ports: 16 com > com4 at puc0 port 0 apic 8 int 19: ns16550a, 16 byte fifo > com4: probed fifo depth: 0 bytes > em0 at pci0 dev 25 function 0 "Intel I217-LM" rev 0x04: msi, address > 34:17:eb:a5:03:5f > ehci0 at pci0 dev 26 function 0 "Intel 8 Series USB" rev 0x04: apic 8 int 16 > usb1 at ehci0: USB revision 2.0 > uhub1 at usb1 configuration 1 interf
Re: Debian 12 Under VMM
On Tue, Jun 04, 2024 at 04:06:13PM +0100, 04-psyche.tot...@icloud.com wrote:
> Thank you Dave and Bruce.
>
> This worked for me:
>
> boost install gfxpayload=text console=ttyS0,115200n8
>
> The critical part was that I had to type it and not copy paste it.
>
glad you got it working; this matches what most/all of us do for these
installs.
> For some reasons, I have problems on the terminal of the VM. I can't copy
> paste it correctly, nor use the arrows without glitch.
>
see other email reply.
> Also as an FYI for anyone else trying. I have to kill the VM at the end of
> the install, and not let the installation process reboot the machine.
> Otherwise it hangs indefinitely.
>
> Thanks!
> Jake
>
>
>
>
> Dave Voutila mailto:d...@sisu.io>> writes:
> >
> >> Hi all,
> >>
> >> I am trying to run Debian 12 under VMM.
> >>
> >> I can see on the email from 2024-04-02 that Bruce managed to make it work,
> >> but I don't know how.
> >>
> >> The crux of the issue is that the Debian ISO installer does not seem to
> >> work under serial console.
> >
> > You need to modify the kernel boot args to disable video and rely on
> > serial console. I can't recall whatever the graphics arg is to the linux
> > kernel, but you typically want something like vga=off and then set the
> > console arg. I recommend setting both that and io_delay:
> >
> > console=ttyS0,115200 io_delay=none
> >
> > io_delay will make the kernel skip doing some pointless artificial
> > delays that don't matter with vmd.
> >
> >>
> >> Here's what I did:
> >>
> >> /etc/vm.conf
> >>
> >> vm "vm1" {
> >>memory 1G
> >>disable
> >>cdrom "/isos/debian-12.5.0-amd64-netinst.iso"
> >>disk "/disks/disk_vm1.qcow2" format qcow2
> >>local interface
> >> }
> >>
> >> When I then start the vm, I am greeted with the message:
> >>
> >> "Press a key, otherwise speech synthesis will be started in 27 seconds..."
> >>
> >>
> >> and then after keypress
> >>
> >> "
> >> Undefined video mode number: 314
> >> Press to see video modes available, to continue, or wait
> >> 30 sec
> >> "
> >>
> >> and it then crashes.
> >>
> >> Can anyone (maybe Bruce) point me in the right direction?
> >>
> >> Thanks!
> >> Jake
>
> Try "gfxpayload=text console=ttyS0,115200" (without the quotes)
>
> I think there's a question about scanning for a graphics card after
> setting the boot parameters. Skip it if you can. The timeout was really
> long, maybe indefinate. I think I gave up a tried again.
Re: Using arrows in VMM
On Tue, Jun 04, 2024 at 01:20:22PM +0100, 04-psyche.tot...@icloud.com wrote: > Greetings, > > I am running Debian 12 under VMM, on OpenBSD 7.5. > > Whenever I am using the arrows (to retrieve previous history or simply to > move left or right), there is a long random sleep, of 5 to 10 seconds. > Sometimes more. > > Does anybody know what could be the issue? > > Inside the VM, the term is vt200. > > The host has xterm-256color as term. > > I ssh into the host. > > Thanks, > Jake I have no issues with D12 locally here; can you submit this via sendbug so we get a dmesg from you? Thx.
Re: 7.5 install crashes on "entry point at 0x1001000" HP Elitebook 840 G10
On Sat, May 25, 2024 at 07:51:31AM +0200, Comète wrote: > Hello, > > This is a link to a screenshot, I can't copy/paste at this step: > > https://ibb.co/tpr8zBz > > Thanks a lot ! > > Comete > looks fine. probably our choice of physaddr conflicting with something from efi. > Le 24 mai 2024 20:38:45 GMT+02:00, Mike Larkin a écrit : > >On Fri, May 24, 2024 at 06:59:24AM +, Comète wrote: > >> Thanks Sven, > >> > >> I can't install OpenBDS because I get the error when trying to boot the > >> install image. > >> > >> Comete > >> > > > >At the boot> prompt, can you show what "mach mem" prints? > > > >Thanks > > > >-ml > > > >> 24 mai 2024 07:48 "Sven Wolf" a écrit: > >> > >> > Hi, > >> > > >> > I had a silimar issue on a Lenovo V130. > >> > For this machine I needed to remove the amdgpu driver in the kernel. > >> > > >> > See also: > >> > https://marc.info/?l=openbsd-misc&m=160232897421774&w=2 > >> > https://marc.info/?l=openbsd-tech&m=160383074317608&w=2 > >> > > >> > Do you get the error "entry point at 0x1001000" also with the bsd.rd > >> > kernel or only after you > >> > installed the system with the bsd.mp/bsd.sp kernel? > >> > > >> > Best regards, > >> > Sven > >> > > >> > On 5/23/24 22:40, Comète wrote: > >> > > >> >> Hello, > >> >> I tried to install OpenBSD 7.5 on a new HP Elitebook 840 G10 (UEFI > >> >> capable only) without success. > >> >> It is stuck at boot on "entry point at 0x1001000". > >> >> Even retried after a BIOS upgrade but no luck either. > >> >> I tried with a snapshot install too with the same result. > >> >> I post here what lspci returns from a debian bookworm: > >> >> 00:00.0 Host bridge: Intel Corporation Device a706 > >> >> 00:02.0 VGA compatible controller: Intel Corporation Raptor Lake-P > >> >> [Iris Xe Graphics] (rev 04) > >> >> 00:04.0 Signal processing controller: Intel Corporation Raptor Lake > >> >> Dynamic Platform and Thermal > >> >> Framework Processor Participant > >> >> 00:06.0 PCI bridge: Intel Corporation Raptor Lake PCIe 4.0 Graphics Port > >> >> 00:06.2 PCI bridge: Intel Corporation Device a73d > >> >> 00:07.0 PCI bridge: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI > >> >> Express Root Port > >> >> 00:07.2 PCI bridge: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI > >> >> Express Root Port > >> >> 00:08.0 System peripheral: Intel Corporation GNA Scoring Accelerator > >> >> module > >> >> 00:0a.0 Signal processing controller: Intel Corporation Raptor Lake > >> >> Crashlog and Telemetry (rev 01) > >> >> 00:0d.0 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 > >> >> USB Controller > >> >> 00:0d.2 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 > >> >> NHI > >> >> 00:0d.3 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 > >> >> NHI > >> >> 00:14.0 USB controller: Intel Corporation Alder Lake PCH USB 3.2 xHCI > >> >> Host Controller (rev 01) > >> >> 00:14.2 RAM memory: Intel Corporation Alder Lake PCH Shared SRAM (rev > >> >> 01) > >> >> 00:14.3 Network controller: Intel Corporation Raptor Lake PCH CNVi WiFi > >> >> (rev 01) > >> >> 00:15.0 Serial bus controller: Intel Corporation Alder Lake PCH Serial > >> >> IO I2C Controller #0 (rev > >> >> 01) > >> >> 00:16.0 Communication controller: Intel Corporation Alder Lake PCH HECI > >> >> Controller (rev 01) > >> >> 00:16.3 Serial controller: Intel Corporation Alder Lake AMT SOL > >> >> Redirection (rev 01) > >> >> 00:1c.0 PCI bridge: Intel Corporation Alder Lake PCH-P PCI Express Root > >> >> Port #9 (rev 01) > >> >> 00:1e.0 Communication controller: Intel Corporation Alder Lake PCH UART > >> >> #0 (rev 01) > >> >> 00:1e.2 Serial bus controller: Intel Corporation Alder Lake SPI > >> >> Controller (rev 01) > >> >> 00:1f.0 ISA bridge: Intel Corporation Raptor Lake LPC/eSPI Controller > >> >> (rev 01) > >> >> 00:1f.3 Multimedia audio controller: Intel Corporation Raptor > >> >> Lake-P/U/H cAVS (rev 01) > >> >> 00:1f.4 SMBus: Intel Corporation Alder Lake PCH-P SMBus Host Controller > >> >> (rev 01) > >> >> 00:1f.5 Serial bus controller: Intel Corporation Alder Lake-P PCH SPI > >> >> Controller (rev 01) > >> >> 02:00.0 Non-Volatile memory controller: SK hynix BC901 NVMe Solid State > >> >> Drive (DRAM-less) (rev 03) > >> >> 57:00.0 Wireless controller [0d40]: Intel Corporation XMM7560 LTE > >> >> Advanced Pro Modem (rev 01) > >> >>> Thanks for your help. > >> >> Comete > >> > > -- > Envoyé de mon téléphone. Excusez la brièveté. >
Re: 7.5 install crashes on "entry point at 0x1001000" HP Elitebook 840 G10
On Fri, May 24, 2024 at 06:59:24AM +, Comète wrote: > Thanks Sven, > > I can't install OpenBDS because I get the error when trying to boot the > install image. > > Comete > At the boot> prompt, can you show what "mach mem" prints? Thanks -ml > 24 mai 2024 07:48 "Sven Wolf" a écrit: > > > Hi, > > > > I had a silimar issue on a Lenovo V130. > > For this machine I needed to remove the amdgpu driver in the kernel. > > > > See also: > > https://marc.info/?l=openbsd-misc&m=160232897421774&w=2 > > https://marc.info/?l=openbsd-tech&m=160383074317608&w=2 > > > > Do you get the error "entry point at 0x1001000" also with the bsd.rd kernel > > or only after you > > installed the system with the bsd.mp/bsd.sp kernel? > > > > Best regards, > > Sven > > > > On 5/23/24 22:40, Comète wrote: > > > >> Hello, > >> I tried to install OpenBSD 7.5 on a new HP Elitebook 840 G10 (UEFI capable > >> only) without success. > >> It is stuck at boot on "entry point at 0x1001000". > >> Even retried after a BIOS upgrade but no luck either. > >> I tried with a snapshot install too with the same result. > >> I post here what lspci returns from a debian bookworm: > >> 00:00.0 Host bridge: Intel Corporation Device a706 > >> 00:02.0 VGA compatible controller: Intel Corporation Raptor Lake-P [Iris > >> Xe Graphics] (rev 04) > >> 00:04.0 Signal processing controller: Intel Corporation Raptor Lake > >> Dynamic Platform and Thermal > >> Framework Processor Participant > >> 00:06.0 PCI bridge: Intel Corporation Raptor Lake PCIe 4.0 Graphics Port > >> 00:06.2 PCI bridge: Intel Corporation Device a73d > >> 00:07.0 PCI bridge: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI > >> Express Root Port > >> 00:07.2 PCI bridge: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI > >> Express Root Port > >> 00:08.0 System peripheral: Intel Corporation GNA Scoring Accelerator module > >> 00:0a.0 Signal processing controller: Intel Corporation Raptor Lake > >> Crashlog and Telemetry (rev 01) > >> 00:0d.0 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 USB > >> Controller > >> 00:0d.2 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI > >> 00:0d.3 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI > >> 00:14.0 USB controller: Intel Corporation Alder Lake PCH USB 3.2 xHCI Host > >> Controller (rev 01) > >> 00:14.2 RAM memory: Intel Corporation Alder Lake PCH Shared SRAM (rev 01) > >> 00:14.3 Network controller: Intel Corporation Raptor Lake PCH CNVi WiFi > >> (rev 01) > >> 00:15.0 Serial bus controller: Intel Corporation Alder Lake PCH Serial IO > >> I2C Controller #0 (rev > >> 01) > >> 00:16.0 Communication controller: Intel Corporation Alder Lake PCH HECI > >> Controller (rev 01) > >> 00:16.3 Serial controller: Intel Corporation Alder Lake AMT SOL > >> Redirection (rev 01) > >> 00:1c.0 PCI bridge: Intel Corporation Alder Lake PCH-P PCI Express Root > >> Port #9 (rev 01) > >> 00:1e.0 Communication controller: Intel Corporation Alder Lake PCH UART #0 > >> (rev 01) > >> 00:1e.2 Serial bus controller: Intel Corporation Alder Lake SPI Controller > >> (rev 01) > >> 00:1f.0 ISA bridge: Intel Corporation Raptor Lake LPC/eSPI Controller (rev > >> 01) > >> 00:1f.3 Multimedia audio controller: Intel Corporation Raptor Lake-P/U/H > >> cAVS (rev 01) > >> 00:1f.4 SMBus: Intel Corporation Alder Lake PCH-P SMBus Host Controller > >> (rev 01) > >> 00:1f.5 Serial bus controller: Intel Corporation Alder Lake-P PCH SPI > >> Controller (rev 01) > >> 02:00.0 Non-Volatile memory controller: SK hynix BC901 NVMe Solid State > >> Drive (DRAM-less) (rev 03) > >> 57:00.0 Wireless controller [0d40]: Intel Corporation XMM7560 LTE Advanced > >> Pro Modem (rev 01) > >>> Thanks for your help. > >> Comete >
Re: Debian 12 Under VMM
On Tue, Apr 02, 2024 at 09:11:04AM -0500, Robert B. Carleton wrote: > I thought I'd share a small success with installing Debian 12 under VMM, > in case some might find it useful. The boot parameters are "install > gfxpayload=text console=ttyS0,115200n8". I added these boot parameters > from the Debian installer after selecting the Help menu using "H", then > selecting "Special boot parameters for special machines." using . > > By the way, I found an article that suggested using "vga=off" instead of > "gfxpayload=text". This worked in the installer, but hung up the boot on > the post-install, because "vga=off" has been deprecated. > > This was under OpenBSD 7.4, run from an xterm. Let me know if there are > any comments or questions. > > Cheers, > > --Bruce > Thanks for the note. I find that the "n8" isn't needed since vmd(8)'s serial emulation doesn't really do different parity/byte sizes. I also usually recommend removing "quiet" from Linux kernel command lines with vmm(4), so you can see what's going on or if/where it gets stuck. -ml
Re: Does anyone know whether this hardware runs OpenBSD?
On Mon, Mar 25, 2024 at 04:39:15AM -0400, Steve Litt wrote: > Does anyone know whether this hardware runs OpenBSD? > > https://www.walmart.com/ip/MeLE-Quieter3Q-Fanless-Mini-PC-N5105-Windows-11-8GB-256GB-4K-UHD-Wifi-6-Mini-Desktop-Computer-New/2177929669 > > Thanks, > > SteveT > > Steve Litt > > Autumn 2023 featured book: Rapid Learning for the 21st Century > http://www.troubleshooters.com/rl21 > We've seen some of those cheap "router PCs" with bad broken BIOS. There were a few all using the same common motherboard that had stuck GPEs a few years ago. Since most of these machines don't have a manufacturer website for BIOS updates, tracking down an updated BIOS without risking bricking the machine is sorta a pain. You get what you pay for. -ml
Re: vmd silently exits (after 7.4 upgrade)
On Fri, Feb 02, 2024 at 08:28:42AM +0100, Piotr K. Isajew wrote: > Hello, > > I'm observing this on one of my machines (which I seldom use > nowadays) after upgrading it to 7.4. The machine had existing > vm.conf setup which worked for me in the past. > > Now "rcctl start vmd" reports: > vmd(ok) > > but just after that executing "vmctl status" gives: > vmctl: connect: /var/run/vmd.sock: Connection refused > > and there is no vmd process running. > > When I try to start vmd from command line, it generates some > output, but it is not really helpful in determining what could be > the problem: > > /usr/sbin/vmd -d -v -v -v -v -v -v -v -v -v -v -v > vmd: startup > vmd: vm_register: registering vm 1 > vmd: /etc/vm.conf:18: vm "lindev" registered (disabled) > vmd: vmd_configure: setting staggered start configuration to parallelism: 4 > and delay: 30 > vmd: vmd_configure: starting vms in staggered fashion > vmd: start_vm_batch: starting batch of 4 vms > vmd: start_vm_batch: not starting vm lindev (disabled) > vmd: start_vm_batch: done starting vms > vmd: vmd: getgrnam caused by missing _agentx group. _agentx:*:92: -ml > vmd: exiting > control: config_getconfig: control retrieving config > control: control exiting, pid 33268 > # priv: config_getconfig: priv retrieving config > priv: priv exiting, pid 1161 > vmm: config_getconfig: vmm retrieving config > vmm: vmm exiting, pid 48824 > > > dmesg excerpt > OpenBSD 7.4 (GENERIC.MP) #2: Fri Dec 8 15:39:04 MST 2023 > > r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > cpu0: Intel(R) Xeon(R) CPU E31225 @ 3.10GHz, 3093.12 MHz, 06-2a-07, patch > 002f > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > cpu0: using VERW MDS workaround (except on vmm entry) > vmm0 at mainbus0: VMX/EPT >
Re: Power usage in Dell XPS 17
On Tue, Jan 30, 2024 at 12:02:37PM -0500, Jag Talon wrote: > Ah yes that's exactly my experience it looks like it might be the GPU at > fault. Good to know I wasn't the only one experiencing this. > > Do people know if there's a way to somehow turn off the GPU outside of BIOS? > Perhaps there's no way around that? > > On 1/30/24 11:54, Benjamin Stürz wrote: > > > I had the same issue with my TUXEDO Polaris 17 (AMD) w/ an RTX 2060M. > > It was also not possible to disable the GPU in the BIOS, > > so the battery life was miserable (45 min). > > > > That's why I later bought myself a used Thinkpad T450 and then a T480, > > which both played very nice with OpenBSD. > > -- > Jag Talon > > https://weirder.earth/@jag > https://jagtalon.net/ > https://aangat.lahat.computer/ One thing I did a while ago is made acpipwrres(4) issue an _OFF on the power resoruce attached to the GPU. That worked on one machine, but failed on another machine since that power resource also powered the screen. YMMV, and you'd need to write that diff yourself in acpipwrres_attach(). -ml
Re: Run VM with 16G or more?
On Tue, Jan 02, 2024 at 08:29:03PM +0100, Kirill A. Korinsky wrote: > And one more noticed bug in vmd regarding memory. > > If I changed memory in /etc/vm.conf for running machine, run rcctl reload vmd, > and restart VM... It has no effect. > > The VM should be shutdown before reload. > > -- > wbr, Kirill > yes, vmctl reload does not reload specifications for currently running VMs.
Re: VMs not rebooting
On Sun, Dec 10, 2023 at 03:16:22PM -0600, Robert B. Carleton wrote:
> Mike Larkin writes:
>
> > On Sun, Dec 10, 2023 at 01:03:27PM -0600, Robert B. Carleton wrote:
> >> I have a number virtual machines, and I've noticed that they power off
> >> instead of rebooting when using "shutdown -r now" on the guest. This is
> >> the general form for a configuration in the /etc/vm.conf:
> >>
> >> vm "batch2" {
> >> memory 2G
> >> enable
> >> cdrom /home/ISO/OpenBSD/7.4/install74.iso
> >> disk /home/vm/batch2/disk0.qcow2
> >> boot device disk
> >> interface { switch "int_switch" }
> >> interface { switch "ext_switch" }
> >> }
> >>
> >
> > I've not heard of anyone else having reboot vs shutdown issues recently.
> > I just did a shutdown -r now on my local machine and it works here:
> >
> >
> > -vmmtech- /var/www/logs# shutdown -r now
> > Shutdown NOW!
> > shutdown: [pid 95485]
> >
> > *** FINAL System shutdown message from root ***
> > System going down IMMEDIATELY
> >
> >
> > -vmmtech- /var/www/logs#
> > System shutdown time has arrived
> >
> > -vmmtech- /var/www/logs# syncing disks... done
> > vmmci0: powerdown
> > rebooting...
> >
> >
> >
> > Using drive 0, partition 3.
> > Loading..
> > probing: pc0 com0 mem[638K 3838M 256M a20=on]
> > disk: hd0+
> >>> OpenBSD/amd64 BOOT 3.65
> > \
> > com0: 115200 baud
> > switching console to com0
> >>> OpenBSD/amd64 BOOT 3.65
> > boot>
> > -
> >
> >> I also tried running vmd from the command line with "-d -vv". Here's the
> >> end of the logging when I tried to reboot the guest:
> >>
> >> vm/batch2: vcpu_exit_eptviolation: fault already handled
> >> vm/batch2: vcpu_exit_eptviolation: fault already handled
> >> vm/batch2: vcpu_exit_eptviolation: fault already handled
> >> vm/batch2: vmmci_ack: vm 7 requested shutdown
> >> vm/batch2: virtio_shutdown: waiting on device pid 35337
> >> vm/batch2: virtio_dispatch_dev: pipe dead (EV_READ)
> >> vm/batch2: virtio_shutdown: device for pid 35337 is stopped
> >> vm/batch2: virtio_shutdown: waiting on device pid 64912
> >> vm/batch2: virtio_shutdown: device for pid 64912 is stopped
> >> vm/batch2: virtio_shutdown: waiting on device pid 34607
> >> vm/batch2: virtio_shutdown: device for pid 34607 is stopped
> >> vmm: vmm_sighdlr: handling signal 20
> >> vmm: vmm_sighdlr: terminated vm batch2 (id 1)
> >> vmm: vm_remove: vmm vmm_sighdlr removing vm 1 from running config
> >> vmm: vm_stop: vmm vmm_sighdlr stopping vm 1
> >> vmd: vm_stop: vmd vmd_dispatch_vmm stopping vm 1
> >>
> >> The three "vcpu_exit_eptviolation: fault already handled" lines seemed
> >> to happen continuously during run time for the guest.
> >
> > harmless
> >
> >>
> >> Is there some kind of configuration that I'm missing? I read the vmctl,
> >> and vm.conf man pages. I also looked at the examples in
> >> /etc/examples. Nothing stood out, so far.
> >>
> >> I'm running OpenBSD 7.4 on the hypervisor and guests. Any suggestions?
> >>
> >> PS: Overall, using vmm has been a good experience. I'm pretty happy with
> >> it.
> >>
> >
> > amd64 guest or i386?
>
> The guests are amd64. Here's a transcript, including a pause to allow
> the boot reordering to finish:
>
> === start transcript ===
> athena$ doas vmctl start batch2
> vmctl: started vm 1 successfully, tty /dev/ttyp2
> athena$ doas vmctl console batch2
> Connected to /dev/ttyp2 (speed 115200)
>
>
> OpenBSD/amd64 (batch2.rbcarleton.net) (tty00)
>
> login: root
> Password:
> Last login: Sun Dec 10 14:58:05 on tty00
> OpenBSD 7.4 (GENERIC) #2: Fri Dec 8 15:38:40 MST 2023
>
> Welcome to OpenBSD: The proactively secure Unix-like operating system.
>
> Please use the sendbug(1) utility to report bugs in the system.
> Before reporting a bug, please try to reproduce it with the latest
> version of the code. With bug reports, please try to ensure that
> enough information to reproduce the problem is enclosed, and if a
> known fix for it exists, include that as well.
>
> You have mail.
> batch2# shutdown -r now
> Shutdown NOW!
> shutdown: [pid 47954]
>
> *** FINAL System shutdown message from r...@batch2.rbcarleton.net ***
> System going down IMMEDIATELY
>
>
> batch2#
> System shutdown time has arrived
>
> batch2# syncing disks... done
> vmmci0: powerdown
> rebooting...
>
> [EOT]
> athena$
> === end transcript ===
>
> A note I'll add is that I don't recall getting the EOT at the end of the
> transcript
> until I hit the enter key.
>
I don't think it will matter much but can you send a host dmesg? Either reply
here or use sendbug.
Re: VMs not rebooting
On Sun, Dec 10, 2023 at 01:03:27PM -0600, Robert B. Carleton wrote:
> I have a number virtual machines, and I've noticed that they power off
> instead of rebooting when using "shutdown -r now" on the guest. This is
> the general form for a configuration in the /etc/vm.conf:
>
> vm "batch2" {
> memory 2G
> enable
> cdrom /home/ISO/OpenBSD/7.4/install74.iso
> disk /home/vm/batch2/disk0.qcow2
> boot device disk
> interface { switch "int_switch" }
> interface { switch "ext_switch" }
> }
>
I've not heard of anyone else having reboot vs shutdown issues recently.
I just did a shutdown -r now on my local machine and it works here:
-vmmtech- /var/www/logs# shutdown -r now
Shutdown NOW!
shutdown: [pid 95485]
*** FINAL System shutdown message from root ***
System going down IMMEDIATELY
-vmmtech- /var/www/logs#
System shutdown time has arrived
-vmmtech- /var/www/logs# syncing disks... done
vmmci0: powerdown
rebooting...
Using drive 0, partition 3.
Loading..
probing: pc0 com0 mem[638K 3838M 256M a20=on]
disk: hd0+
>> OpenBSD/amd64 BOOT 3.65
\
com0: 115200 baud
switching console to com0
>> OpenBSD/amd64 BOOT 3.65
boot>
-
> I also tried running vmd from the command line with "-d -vv". Here's the
> end of the logging when I tried to reboot the guest:
>
> vm/batch2: vcpu_exit_eptviolation: fault already handled
> vm/batch2: vcpu_exit_eptviolation: fault already handled
> vm/batch2: vcpu_exit_eptviolation: fault already handled
> vm/batch2: vmmci_ack: vm 7 requested shutdown
> vm/batch2: virtio_shutdown: waiting on device pid 35337
> vm/batch2: virtio_dispatch_dev: pipe dead (EV_READ)
> vm/batch2: virtio_shutdown: device for pid 35337 is stopped
> vm/batch2: virtio_shutdown: waiting on device pid 64912
> vm/batch2: virtio_shutdown: device for pid 64912 is stopped
> vm/batch2: virtio_shutdown: waiting on device pid 34607
> vm/batch2: virtio_shutdown: device for pid 34607 is stopped
> vmm: vmm_sighdlr: handling signal 20
> vmm: vmm_sighdlr: terminated vm batch2 (id 1)
> vmm: vm_remove: vmm vmm_sighdlr removing vm 1 from running config
> vmm: vm_stop: vmm vmm_sighdlr stopping vm 1
> vmd: vm_stop: vmd vmd_dispatch_vmm stopping vm 1
>
> The three "vcpu_exit_eptviolation: fault already handled" lines seemed
> to happen continuously during run time for the guest.
harmless
>
> Is there some kind of configuration that I'm missing? I read the vmctl,
> and vm.conf man pages. I also looked at the examples in
> /etc/examples. Nothing stood out, so far.
>
> I'm running OpenBSD 7.4 on the hypervisor and guests. Any suggestions?
>
> PS: Overall, using vmm has been a good experience. I'm pretty happy with
> it.
>
amd64 guest or i386?
Re: ls in color
On Fri, Dec 08, 2023 at 07:41:23PM +0100, Karel Lucas wrote: > > Hi all, > > In openBSD V7.4 I would like to see the output of ls in color, and therefore > would like to know how to configure that. The output of "man ls" provides no > information about this. Can anyone give me a tip? > pkg_add colorls alias ls='/usr/local/bin/colorls -GF'
Re: CPU0 at 100% on Thinkpad 480 with OpenBSD 7.4
On Mon, Nov 27, 2023 at 11:38:01AM -0700, Theo de Raadt wrote: > Mike Larkin wrote: > > > On Mon, Nov 27, 2023 at 01:05:56PM -0500, Laurent Cimon wrote: > > > Hi, > > > > > > > > > The CPU0 on my Thinkpad 480 is always running at around 100%. It's on > > > OpenBSD 7.4. > > > > > > It seems to be doing this in the kernel. > > > > > > > > > Here is the CPU's line from top(1). > > > > > > CPU0: 0.0% user, 0.0% nice, 79.3% sys, 3.8% spin, 16.3 > > > > > > > > > It's always this specific CPU, and it's been draining my battery. > > > > > > How do I find what causes this? > > > > > > > > > I think that it starts doing it after waking from sleep, as it doesn't do > > > it > > > when the system is freshly started. > > > > > > But I'd need to do some tests before verifying this. > > > > > > > > > Laurent > > > > > > > Please search the list, this has been reported and solved many times, > > specifically for this machine. > > > > It is not solved. > > There is a "workaround" > > We do something wrong by not managing thunderbolt, but it is not clear > what we are supposed to do. My theory is that thunderbolt is initialized > far enough by BIOS or chipset default configuration or our driver, that > interrupts occur which we don't handle, and spin. > fair enough, that's a more accurate description.
Re: CPU0 at 100% on Thinkpad 480 with OpenBSD 7.4
On Mon, Nov 27, 2023 at 01:05:56PM -0500, Laurent Cimon wrote: > Hi, > > > The CPU0 on my Thinkpad 480 is always running at around 100%. It's on > OpenBSD 7.4. > > It seems to be doing this in the kernel. > > > Here is the CPU's line from top(1). > > CPU0: 0.0% user, 0.0% nice, 79.3% sys, 3.8% spin, 16.3 > > > It's always this specific CPU, and it's been draining my battery. > > How do I find what causes this? > > > I think that it starts doing it after waking from sleep, as it doesn't do it > when the system is freshly started. > > But I'd need to do some tests before verifying this. > > > Laurent > Please search the list, this has been reported and solved many times, specifically for this machine.
Re: Sleep induces acpi0 interrupt storm
On Wed, Oct 25, 2023 at 07:19:29PM +0200, Richard Ulmer wrote: > Hi all, > I've just set up a new T480 ThinkPad with OpenBSD 7.4. I have noticed > that after sleeping (by closing and opening the lid of the laptop) > my fan turns up and one of my CPU cores is fully loaded. `top -U -S > root` and `systat vmstat` tell me, that acpi0 is generating a lot of > interrupts, close to 2000/s. > > Once I had this high interrupt count directly after booting, without > even putting the laptop to sleep. > > Can anyone help me debug this or does someone know of a workaround? > From what I've read I could probably disable certain ACPI functions > using bsd.re-config(5), but I'm not sure where to start. Do I have to go > through all 49 devices listed in acpi(4)? > > Greetings, > Richard > check the lists; this was reported lots of times. I think it was some thunderbolt related thing in the BIOS. > > dmesg; the last 22 lines were generated when closing and opening the > lid: > > OpenBSD 7.4 (GENERIC.MP) #1397: Tue Oct 10 09:02:37 MDT 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8200216576 (7820MB) > avail mem = 7931973632 (7564MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x9a628000 (63 entries) > bios0: vendor LENOVO version "N24ET74W (1.49 )" date 08/15/2023 > bios0: LENOVO 20L6SF8C00 > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT > SSDT SSDT SSDT BOOT BATB SLIC SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP > DBG2 MSDM DMAR ASF! FPDT UEFI > acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) > RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) > RP06(S4) PXSX(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 2399 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 1496.52 MHz, 06-8e-0a, patch > 00f4 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,RSBA,MISC_PKG_CT,ENERGY_FILT,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 4-way L2 cache, 6MB 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 24MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 1496.52 MHz, 06-8e-0a, patch > 00f4 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,RSBA,MISC_PKG_CT,ENERGY_FILT,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 4-way L2 cache, 6MB 64b/line 12-way L3 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 1496.52 MHz, 06-8e-0a, patch > 00f4 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,RSBA,MISC_PKG_CT,ENERGY_FILT,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN > cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 4-way L2 cache, 6MB 64b/line 12-way L3 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 1496.52 MHz, 06-8e-0a, patch > 00f4 > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,F
Re: Limiting RAM on boot to emulate low-memory situation
On Sat, Oct 21, 2023 at 10:22:45AM -, Stuart Henderson wrote: > On 2023-10-21, Chris Narkiewicz wrote: > > Is it possible to decrease amount of available RAM at boot time? > > > > I'm about to migrate some VPS system to a significantly cheaper option > > that comes with less RAM and I need to evaluate how existing system > > will behave. > > > > Sadly, I can't reconfigure RAM in VPS config. > > At least for x86, see "machine mem" in boot(8). > > -- > Please keep replies on the mailing list. > While mach mem in boot> will work for BIOS based machines, it does not work in EFI (or at least it didn't, last time I checked). FYI.
Re: Crash on TOSHIBA PORTEGE Z30-A laptop
On Sat, Oct 21, 2023 at 01:27:21PM +0400, wes...@technicien.io wrote: > Hi Philip, > > Thank you very much for your answer. > > I tried to disable all options (+devices) possible. Same issue. > And what's about disable acpi in the kernel using the bsd.re-config? > Not advisable. You'll probably end up causing even more problems. > Do you think If I replace the wireless card by somthing else, It could > resolve this issue? > > > /Wesley > > > > -Message d'origine- > De : owner-b...@openbsd.org De la part de Philip > Guenther > Envoyé : samedi 21 octobre 2023 03:23 > À : wes...@technicien.io > Cc : b...@openbsd.org; misc@openbsd.org > Objet : Re: Crash on TOSHIBA PORTEGE Z30-A laptop > > On Fri, Oct 20, 2023 at 1:23 PM wrote: > > > I've recently installed OpenBSD 7.4 on this laptop. > > > > However, I'm experiencing random crashes. These occur at various > > times, including during kernel loading (before running /etc/rc), > > > > or later while I'm using the system. > > > > > > I've included the contents of /var/run/dmesg.boot below and attached > > the screens with the ddb output command. > > > ... > > > bios0: vendor TOSHIBA version "Version 4.30" date 04/26/2018 > > > > The screenshots show that the fault happens during a wifi interrupt that > catches the ACPI thread processing a very deeply nested AML code. I suspect > it's actually running out of kernel stack space as a result. > Everything below is based on that hypothesis. > > So, the first thing to try is to see if there's a BIOS update newer than the > 2018 rev it currently has. They may have optimized the AML code, or at least > made it less deeply nested. > > Another possibility is to see if there's a device you can disable that would > result in that AML not being called. If there's anything that you aren't > using then disable it in the BIOS and hope. > > The last possibility would be to build a kernel which allocates more pages > per thread for its kernel stack by bumping the UPAGES #define in > /usr/src/sys/arch/amd64/include/param.h and building a new kernel. It's > really only the ACPI thread that needs this, but we don't currently have code > to control that on a per-thread basis. > > > Philip Guenther >
Re: vmd and /dev/sd*
On Thu, Oct 12, 2023 at 09:24:33AM -0600, Theo de Raadt wrote: > Manuel Giraud wrote: > > > > Manuel Giraud writes: > > > > > >> Hi, > > >> > > >> I can't find the information on this list (or elsewhere). Is it > > >> possible to have a vm that access a disk through its device? The > > >> following does not seem to work: > > >> > > >> # vmctl start -cL -m 1G -b /bsd.rd -d /dev/sd1c myvm > > >> vmctl: start vm command failed: Unknown error: -1 > > > > > > No, passing file descriptors to devices over ipc sockets isn't currently > > > allowed by the kernel. You'd need to use the raw character device, too, > > > afaik if passing them were allowed. > > > > Ok, noted. BTW I have the same error passing the raw character device. > > > > I made the decision to not allow passing of weird file descriptor types > very intentionally. I'm still very sure that is the right decision. > > Here's 1 program which wants to do it, but the other 1000 pledge'd programs > are being protected from being passed an incorrect fd and then doing system > calls upon it which behave "different". By that, I mean seek, read, and > write short-operation behaviours are subtly different outside of files and > sockets, and it would also expose some ioctl (which is MOSTLY limited by > pledge, but ioctl "request" values are just numbers, and they can overlap in > surprising ways). > I would like to make clear that vmd does not "want to do it", and that I agree that the current design of not being able to pass these types of fds is correct. It may be slightly inconvient for certain niche use cases, but not worth weakening everything else or putting in hacks. Just dd the device you want to a .raw file and use that. -ml
Re: Failure to start vmd
On Tue, Oct 03, 2023 at 11:30:28AM -0500, B. Atticus Grobe wrote: > The E8400 processor doesn't support extended page tables, which vmm > requires. AFAIK, all modern hypervisors require this. Correct. It was my plan long ago to support shadow paging for CPUs like this but there really is no point now.
Re: Failure to start vmd
On Tue, Oct 03, 2023 at 01:03:02PM -0300, vitmau...@gmail.com wrote: > Hi, > > I'm trying to fiddle with OpenBSD's virtualization capabilities, but I > couldn't manage to start vmd. The console gives me the error "vmd(failed)" > and my /var/log/message says "vmd[31605]: vmd: /dev/vmm: Operation not > supported by device". I enabled the "Virtualization Technology" and "VT-d" > options on my bios and fw_update indicates that vmm is already installed. I > did a grep on my dmesg to look for "VMX/EPT" (as suggested by OpenBSD's > FAQ), but only occurrences of "VMX". > > Anybody has any idea about what might be wrong? cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2826.29 MHz, 06-17-0a That CPU is too old. > > Here's my dmesg. > > OpenBSD 7.2 (GENERIC.MP) #5: Tue Jul 25 16:20:58 CEST 2023 > r...@syspatch-72-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ > GENERIC.MP > real mem = 6254428160 (5964MB) > avail mem = 6047473664 (5767MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (40 entries) > bios0: vendor Itautec ST 4262, LTD 6.00 PG version "FC" date 08/21/2009 > bios0: Itautec S.A. Infoway > acpi0 at bios0: ACPI 1.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP ASF! HPET MCFG APIC SSDT > acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) > PEX5(S5) HUB0(S5) UAR1(S3) UAR2(S3) IGBE(S4) USB0(S3) USB1(S3) USB2(S3) > USB3(S3) USB4(S3) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimcfg0 at acpi0 > acpimcfg0: addr 0xd000, bus 0-255 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2826.29 MHz, 06-17-0a > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB > 64b/line 24-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 332MHz > cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2826.26 MHz, 06-17-0a > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB > 64b/line 24-way L2 cache > cpu1: smt 0, core 1, package 0 > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus 1 (PEX0) > acpiprt2 at acpi0: bus -1 (PEX1) > acpiprt3 at acpi0: bus -1 (PEX2) > acpiprt4 at acpi0: bus -1 (PEX3) > acpiprt5 at acpi0: bus -1 (PEX4) > acpiprt6 at acpi0: bus -1 (PEX5) > acpiprt7 at acpi0: bus 2 (HUB0) > acpibtn0 at acpi0: PWRB > acpipci0 at acpi0 PCI0 > acpicmos0 at acpi0 > com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo > com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo > acpicpu0 at acpi0: C1(@1 halt!), FVS, 2667, 2000 MHz > acpicpu1 at acpi0: C1(@1 halt!), FVS, 2667, 2000 MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel Q45 Host" rev 0x03 > inteldrm0 at pci0 dev 2 function 0 "Intel Q45 Video" rev 0x03 > drm0 at inteldrm0 > intagp0 at inteldrm0 > agp0 at intagp0: aperture at 0xe000, size 0x1000 > inteldrm0: apic 2 int 16, G45, gen 4 > "Intel Q45 Video" rev 0x03 at pci0 dev 2 function 1 not configured > "Intel Q45 HECI" rev 0x03 at pci0 dev 3 function 0 not configured > pciide0 at pci0 dev 3 function 2 "Intel Q45 PT IDER" rev 0x03: DMA > (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI > pciide0: using apic 2 int 18 for native-PCI interrupt > pciide0: channel 0 ignored (not responding; disabled or no drives?) > pciide0: channel 1 ignored (not responding; disabled or no drives?) > puc0 at pci0 dev 3 function 3 "Intel Q45 KT" rev 0x03: ports: 16 com > com4 at puc0 port 0 apic 2 int 17: ns16550a, 16 byte fifo > com4: probed fifo depth: 15 bytes > em0 at pci0 dev 25 function 0 "Intel ICH10 D BM LM" rev 0x02: apic 2 int > 20, address 6c:f0:49:fa:26:2e > uhci0 at pci0 dev 26 function 0 "Intel 82801JD USB" rev 0x02: apic 2 int 16 > uhci1 at pci0 dev 26 function 1 "Intel 82801JD USB" rev 0x02: apic 2 int 21 > uhci2 at pci0 dev 26 function 2 "Intel 82801JD USB" rev 0x02: apic 2 int 18 > ehci0 at pci0 dev 26 function 7 "Intel 82801JD USB" rev 0x02: apic 2 int 18 > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev > 2.00/1.00 addr 1 > azalia0 at
Re: volatility or something like that in the future ?
On Fri, Aug 18, 2023 at 01:31:41PM +, whistlez wrote:
> Il 2023-08-18 09:22 Omar Polo ha scritto:
> > On 2023/08/18 02:06:11 +, whistlez wrote:
> >> Il 2023-08-18 02:20 Scott Cheloha ha scritto:
> >> >> On Aug 17, 2023, at 10:28, whistlez wrote:
> >>
> >> Furthermore, in my opinion - brace yourself, I might trigger an atomic
> >> war with what I'm about to say - we should consider it certain that the
> >> kernel could contain unknown vulnerabilities. Unauthorized code running
> >> in the kernel is impossible to detect, clearly. I'm talking about code
> >> that might not even reside on the disk but is injected remotely. Thus,
> >> the only way is through inspecting the RAM dump, that is, a software
> >> that can analyze the dump and determine its integrity.
> >
> > Assuming that the kernel was compromised, how can you trust a tool to
> > detect that? The compromised kernel could return normal-looking data
> > through /dev/{k,}mem (ignoring for a moment the perils of allowing
> > random software to access these devices.) You'd be asking a liar if
> > they're telling the truth :)
>
> Yes, I understand exactly what you're saying, and I partly agree, but
> I'd like to share some thoughts. However, first and foremost, I want to
> reiterate that I'm not a developer, and for this reason, my statements
> might be based on entirely erroneous assumptions. But let's get to the
> considerations.
>
> 1. Volatility allows the detection of hidden kernel modules in a Linux
> environment, including typical LKM rootkits.
>
> 2. There are multiple methods for RAM dumping, some of which cannot be
> circumvented and do not require specific software or interfaces. For
> example:
> a. Through a 'cold boot attack,' it's possible to dump RAM from an
> uncompromised operating system. (Reference:
> https://en.wikipedia.org/wiki/Cold_boot_attack)
> b. Through a DMA attack, leveraging FireWire or other hardware
> interfaces, it's possible to dump RAM. I believe that, in this case, as
> in the previous one, the kernel would be completely unaware. An example
> of this kind of attack and dump is "inception"
> (https://github.com/carmaa/inception).
> c. In a virtualized environment such as VMM, VirtualBox, VMware,
> etc. (we know OpenBSD can be virtualized), you can acquire RAM without
> the operating system knowing.
Great, sounds like you've stumbled across 3 solutions for your problem.
Looks like no diff is needed after all.
>
> 3. The third consideration relates to what you said – that it doesn't
> make sense to ask a liar if he is lying. I think, similar to how the
> police operate, you can ask a suspect a series of questions, and all
> answers should exhibit a certain logical consistency. If you want to
> make a neighborhood disappear from a city, you can't just dig a hole.
> Because everyone will understand that it can't be true. Roads will
> terminate at the hole and continue on the other side, and that doesn't
> make sense. Moral of the story: the more you have to hide, the more code
> you have to write to make your façade believable. And so, the more
> questions you ask the suspect, the more they have to invent lies that
> are consistent. The more lies there are, the greater the chances of
> creating a discrepancy in the infrastructure. For instance, library,
> memory, pointers must be reorganized coherently. You can't make a
> pointer point to a memory area that is empty.
>
> 4. Another thing we can't ignore is that we all know there are no
> definitive security solutions, only building bricks that add layers of
> difficulty and complicate matters for an attacker. Keeping hidden code
> within a kernel while simultaneously ensuring that code performs actions
> is an additional layer of difficulty.
>
Re: riscv questions
On Fri, Aug 18, 2023 at 06:44:48AM +0200, Peter J. Philipp wrote: > On Thu, Aug 17, 2023 at 06:03:42PM +0000, Mike Larkin wrote: > > On Sun, Aug 13, 2023 at 06:27:20PM +0200, Peter J. Philipp wrote: > > > Hi, > > > > > > I was wondering two things currently, both having to do with QEMU on > > > OpenBSD. > > > > > > I noticed in my QEMU that is running OpenBSD that it is supporting the > > > H-extension. The H is hypervisor. Does this mean that there is support > > > emulated for hypervisor host and guest in QEMU? Also is there any > > > efforts to > > > implement this where I can be an observer? > > > > I believe they have some support for that. > > > > There is no hardware currently available that has it though, from what I > > know. > > There is an FPGA core you can implement on a suitably large dev board > > though, > > but you'd be a 1-off. > > > > When you say "implement this", what do you mean? > > Oh I didn't know there was no hardware support for this yet. What I meant > for implementing this was if there is anyone porting vmm to riscv64. I guess > arm64 needs it too but riscv64 to me is the ultimate :-). > arm64 is first but the separation work was done already. There are about two dozen functions that need to be implemented in the kernel, plus a bunch of work in vmd. > I was wondering Mike, do you offer any more workgroups like the one that > ported riscv64? I know someone on IRC who lives in the Los Angeles region of It wasn't a workgroup. It was a group of four full time students working on their master's degrees as a final project. It took six months, more or less, and at that time we barely could print hello world from userland. It was another 6-12 months after that before it was stable, thanks to many other developers. > California that might be interested in such a workgroup. Though he may > not be available until 2024/2025 for something such as this, but the interest > would be there. I told him an effort to port vmm to riscv64 would be a > worthwhile endeavour, for everyone. Obviously it depends on hardware support > and someone to guide the group. > I'm prioritizing arm64 at this point, there isn't much value in porting vmm to hardware that is way too slow to matter (and I am unsure if such hardware even exists). powerpc64 is another choice, it has virtualization support, as do some octeons. We have real hardware for those, too. That said, if a diff appeared on tech@, I'd certainly take a look at it. > > > > > > > I saw somewhere that newer QEMU support RV128 cpu emulation. While this > > > is something for 20 years from now perhaps, I'm still curious if anyone is > > > considering a port to the RV128, or is at least turned on by the thought > > > of it. > > > > no > > > > > Unfortunately I believe the RV128 isn't intended for an 128 bit address > > > space > > > but has something planned for partitioning it in half so it will be 64 bit > > > space. With the other 64 bit for something security related. > > > > > > Also I'd like to say that I have my first piece of RV64 hardware for a few > > > weeks now and it can run linux ubuntu. It's a Mango Pi which is the same > > > form factor as a RPI zero. I also donated one to a developer so perhaps > > > we'll > > > see OpenBSD running on it one day. In half a dozen weeks or so I'm > > > considering > > > getting my second RV64 computer, which will be somewhat of a visionfive > > > 2-like > > > SBC for a router. Not sure which yet, though, let's see who can deliver > > > in > > > October. > > > > > > Next year I'd like to invest into a larger RV64 computer for workstation. > > > As > > > you can see I'm starting to get a bit serious around Risc-V > > > > get a milk-v pioneer then, it's the biggest you can currently buy. > > Interesting. Thanks! > > Best Regards, > -peter > > -- > Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: riscv questions
On Sun, Aug 13, 2023 at 06:27:20PM +0200, Peter J. Philipp wrote: > Hi, > > I was wondering two things currently, both having to do with QEMU on OpenBSD. > > I noticed in my QEMU that is running OpenBSD that it is supporting the > H-extension. The H is hypervisor. Does this mean that there is support > emulated for hypervisor host and guest in QEMU? Also is there any efforts to > implement this where I can be an observer? I believe they have some support for that. There is no hardware currently available that has it though, from what I know. There is an FPGA core you can implement on a suitably large dev board though, but you'd be a 1-off. When you say "implement this", what do you mean? > > I saw somewhere that newer QEMU support RV128 cpu emulation. While this > is something for 20 years from now perhaps, I'm still curious if anyone is > considering a port to the RV128, or is at least turned on by the thought of > it. no > Unfortunately I believe the RV128 isn't intended for an 128 bit address space > but has something planned for partitioning it in half so it will be 64 bit > space. With the other 64 bit for something security related. > > Also I'd like to say that I have my first piece of RV64 hardware for a few > weeks now and it can run linux ubuntu. It's a Mango Pi which is the same > form factor as a RPI zero. I also donated one to a developer so perhaps we'll > see OpenBSD running on it one day. In half a dozen weeks or so I'm > considering > getting my second RV64 computer, which will be somewhat of a visionfive 2-like > SBC for a router. Not sure which yet, though, let's see who can deliver in > October. > > Next year I'd like to invest into a larger RV64 computer for workstation. As > you can see I'm starting to get a bit serious around Risc-V get a milk-v pioneer then, it's the biggest you can currently buy. > > Best Regards, > -peter > > -- > Over thirty years experience on Unix-like Operating Systems starting with QNX. >
Re: unhibernate failed: original kernel changed
On Tue, Aug 01, 2023 at 07:22:04AM -, Piotr Isajew wrote:
> Dnia 31.07.2023 Mike Larkin napisał/a:
>
> > The message explained exactly what happened. What is unclear?
>
> I understand the message. What I don't undestand is the reason
> for it. The message is due to this comparison not returning 0:
>
> if (bcmp(mine->kern_hash, disk->kern_hash, SHA256_DIGEST_LENGTH) != 0) {
>
> but the same kernel image was used when booting the system before
> hibernation and on unhibernate.
>
Something changed on disk otherwise that bcmp would be the same.
Try reproing with a GENERIC/GENERIC.MP kernel and see if that fixes it.
Re: unhibernate failed: original kernel changed
On Mon, Jul 31, 2023 at 09:39:01PM +0200, Piotr K. Isajew wrote: > that's exactly what I got when I tried to resume after ZZZ on my > Lenovo machine with custom 7.3 kernel. Customization is primarily > to point swap and dump to non-default device: > > root on sd1a swap on sd0b dump on sd0b > > Full dmesg attached. > > Note that I'm not a heavy hibernate/suspend user. I have never > tried it with success on this machine. The message explained exactly what happened. What is unclear? > OpenBSD 7.3-stable (PKI) #27: Tue Jul 25 21:39:08 CEST 2023 > pki@zgred.localnet:/sys/arch/amd64/compile/PKI > real mem = 29892214784 (28507MB) > avail mem = 28966887424 (27624MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.3 @ 0xcb709000 (57 entries) > bios0: vendor LENOVO version "GKCN50WW" date 11/24/2021 > bios0: LENOVO 82JU > acpi0 at bios0: ACPI 5.0Undefined scope: \\_SB_.PCI0.PB2_ > > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP UEFI SSDT SSDT IVRS SSDT SSDT TPM2 POAT ASF! BOOT > HPET APIC MCFG SLIC WDAT WDRT SSDT SSDT VFCT SSDT SSDT SSDT SSDT CRAT CDIT > SSDT SSDT SSDT SSDT SSDT SSDT FPDT WSMT SSDT SSDT BGRT > acpi0: wakeup devices GPP0(S3) GPP1(S3) GPP2(S3) GPP3(S3) GPP4(S3) GPP5(S3) > GP17(S3) XHC0(S3) XHC1(S3) GP19(S3) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpihpet0 at acpi0: 14318180 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Ryzen 7 5800H with Radeon Graphics, 3200.00 MHz, 19-50-00 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,WAITPKG,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB > 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 100MHz > cpu0: mwait min=64, max=64, C-substates=1.1, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD Ryzen 7 5800H with Radeon Graphics, 3200.00 MHz, 19-50-00 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB > 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache > cpu1: smt 1, core 0, package 0 > tsc: cpu0/cpu1: sync test failed > timecounter: active counter changed: tsc -> acpihpet0 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: AMD Ryzen 7 5800H with Radeon Graphics, 3200.00 MHz, 19-50-00 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB > 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache > cpu2: smt 0, core 1, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: AMD Ryzen 7 5800H with Radeon Graphics, 3200.00 MHz, 19-50-00 > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB > 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache > cpu3: smt 1, core 1, package 0 > cpu4 at mainbus0: apid 4 (application processor) > cpu4: AMD Ryzen 7 5800H with Radeon Graphics, 3200.00 MHz, 19-50-00 > cpu4: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,P
Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches
On Tue, Jul 25, 2023 at 10:42:25AM -0700, Kevin wrote: > On Tue, Jul 25, 2023 at 7:42 AM Theo de Raadt wrote: > > > It seems some of the smaller hypervisor companies didn't get the memo, > > and they are blocking the msr write to to set the chicken bit. > > > > They block it by raising an exception. > > They should IGNORE that bit if they allow setting it. > > > > I also have a strong suspicion some of them do not have the firmware > > fixes, and that the chickenbit-off state we read is true. > > > > Anyways, a brand new errata to skip setting the chickenbit on such > > hypervisors is going out the door right now. > > > > > I just fucking love you guys. > > Thank you. > > Just applied the fix to the first affected AMD machine and all is well > again. > > Would this be worth putting a ticket into Vultr to get them to make > appropriate updates on their side? Yes (but I see you already did)
Re: xenodm + Xvfb + x11vnc = virtual display for vmm(4) OpenBSD guests
On Tue, Jul 18, 2023 at 04:09:21PM -0400, Morgan Aldridge wrote: > I'm maintaining an OpenBSD X11 window manager (WM) port, but try to > keep my primary workstation on -stable, so do most of my development > there and test in Xephyr. I test & submit patches from an OpenBSD > -current VM running under vmm(4), but since vmm(4) doesn't emulate > video hardware, I haven't been run-testing there. > > I'm already comfortable with x11vnc under OpenBSD, plus Xephyr, but > they both use an existing X display. After studying xenodm(1), > Xvfb(1), x11vnc(1), and a bunch of other X(1)-related manual pages, > plus tons of experimenting, the solution was actually quite simple. > > TL; DR > > I could find much on the Internet, list archives, etc., regarding this > specific situation, so here's my solution for a [slow] X11 virtual > display on a vmm(4) OpenBSD guest, accessible via VNC over an SSH > tunnel: > > doas rcctl enable xenodm > doas rcctl set xenodm flags \ > "-server ':0 local /usr/X11R6/bin/Xvfb :0 -screen 1024x768x24 -shmem'" > doas rcctl start xenodm > doas pkg_add x11vnc > doas rcctl enable x11vnc > doas rcctl start x11vnc > > Hope someone else finds this useful down the road, > > Morgan > Thanks. Always good to have information like this on the list for later searchers. There are other ways too (like sthen@ replied subsequently).
Re: Ryzen 9 (7x000) users: do you experience hangs?
On Tue, Jul 18, 2023 at 01:19:14PM -0700, Kastus Shchuka wrote: > On Tue, Jul 18, 2023 at 08:09:11PM +0100, cho...@jtan.com wrote: > > Not really. But. > > > > I have an APU2 which runs two VMs that do practically nothing, > > although the box itself is used actively. The VMs consistently, and > > without warning, hang in a way which matches the description "nothing > > new can be execed" although I recall being able to log in on the > > console. I noticed shortly after I installed the VMs in around May > > but I haven't got very far diagnosing it because it's a low priority. > > However there is a common denominator: AMD > > > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: AMD G-T40E Processor, 1000.02 MHz, 14-02-00 > > cpu0: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC > > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache > > cpu0: 512KB 64b/line 16-way L2 cache > > cpu0: smt 0, core 0, package 0 > > > > Times two. > > > > As you say the existing processes seem to work fine right up until > > sshd is nearly (but not quite?) ready to fork: > > > > . > > . > > . > > debug1: SSH2_MSG_EXT_INFO received > > debug1: kex_input_ext_info: > > server-sig-algs= > > debug1: kex_input_ext_info: publickey-hostbo...@openssh.com=<0> > > debug1: SSH2_MSG_SERVICE_ACCEPT received > > > > Ordinarily it would next attempt authentication. Does sshd fork and > > drop privileges to do that? > > > > I don't know if that could help or even if it's related, but it can > > be reproduced with confidence. I can poke the box or its VMs any > > way that could shake some data loose. > > > > Matthew > > > > Is AMD errata referenced from https://inks.tedunangst.com/l/4996 any relevant? > (errata #1474 in https://www.amd.com/system/files/TechDocs/56323-PUB_1.01.pdf) > > -Kastus > no
Re: Allwinner D1 riscv64 mango pi SBC
On Tue, Jul 18, 2023 at 02:02:45PM -0600, deich...@placebonol.com wrote: > Hi Mike > > I've volunteered to coordinate a purchase of Mango Pi to get them into > OpenBSD developers working on riscv64 platform. > > It has been awhile but I used to facilitate getting h/w into OpenBSD > developers hands on a semi-regular basis. > > diana > > Great. I don't know who would be interested, so I'd wait to let them speak up before ordering anything. -ml > > On July 16, 2023 1:13:02 PM MDT, "Peter J. Philipp" > wrote: > >On Sun, Jul 16, 2023 at 06:25:50PM +, Mike Larkin wrote: > >> On Sun, Jul 16, 2023 at 11:56:51AM +0200, Peter J. Philipp wrote: > >> > Hi *, > >> > > >> > I'm back for the moment. I was wondering who has a Allwinner D1 riscv64 > >> > SBC? > >> > This is the Mango Pi SBC. > >> > > >> > I have one which has linux on it currently but I'm trying to boot > >> > OpenBSD on > >> > it. But I'm fairly lazy and haven't done much with this lately. I can > >> > get > >> > to the riscv64 loader but when it loads the kernel, it goes blind. So > >> > there > >> > is more than just getting the GPIO pins configured which I think I have > >> > been > >> > able to adjust. > >> > > >> > I use a QEMU-based riscv64 emulation to compile kernels which is slow > >> > but this > >> > SBC isn't much faster either (1000 Mhz it claims). > >> > > >> > I use this u-boot directive to get into the boot loader: > >> > > >> > setenv bootobsd 'load mmc 0:1 0x4FA0 > >> > /boot/dtbs/5.19.0-1009-allwinner/allwinner/sun20i-d1-nezha-memory.dtb ; > >> > load mmc 0:f 0x4008 /EFI/OpenBSD/BOOTRISCV64.EFI ; bootefi > >> > 0x4008 0x4FA0' > >> > > >> > followed by a: > >> > > >> > run bootobsd > >> > > >> > I am unsure how to save this though in the u-boot itself. Any hints > >> > would be > >> > appreciated. > >> > > >> > I think we need a specific riscv mailing list for this sort of stuff > >> > perhaps > >> > it's too technical for misc. Regarding to the nostradamus stuff of > >> > someone > >> > from chicago (Re: A couple of Questions) , check out "1st wave" and > >> > "cade foster" on youtube (reruns), this will feed you more ideas. my > >> > personal > >> > opinion is that time travel of information is possible, contributing to > >> > major > >> > headaches when events get changed (for the prometheus seers). > >> > > >> > Back to "reality" I'm looking for a group of people to help getting the > >> > mango > >> > pi working. I'm hampered by pride to ask knowledged people and these > >> > people > >> > have their own directions and I don't want to bother their efforts. The > >> > more > >> > we are the more we could possibly get something done. > >> > > >> > >> The best way to get that done is to get hardware in the hands of > >> developer(s). > >> Wishing on misc@ is likely not going to get anyone interested. Check the > >> commit > >> logs for people working in this area, reach out to them, and see if they > >> are > >> interested in helping. > >> > >> -ml > > > >Hi Mike, > > > >Thanks. This will take a bit, I'm in talks to get a new job soon, which will > >put extra money in my pocket. Then I may be able to get a handful of these > >perhaps. Do you still keep tabs on Shivam, Mars, Brian, and Wenyan? Are > >they > >still interested in riscv64 after the initial port with yours and Dales > >guidance? I think I paid something like 30 EUR for a Mango Pi from > >AliExpress > >buying 4 would work but I can only do this when I have secured the job. > > > >Best Regards, > >-peter > > > >-- > >Over thirty years experience on Unix-like Operating Systems starting with > >QNX. > >
Re: Ryzen 9 (7x000) users: do you experience hangs?
On Tue, Jul 18, 2023 at 08:09:11PM +0100, cho...@jtan.com wrote: This is completely unrelated to the question we asked. Please don't hijack the thread. > Not really. But. > > I have an APU2 which runs two VMs that do practically nothing, > although the box itself is used actively. The VMs consistently, and > without warning, hang in a way which matches the description "nothing > new can be execed" although I recall being able to log in on the > console. I noticed shortly after I installed the VMs in around May > but I haven't got very far diagnosing it because it's a low priority. > However there is a common denominator: AMD > > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD G-T40E Processor, 1000.02 MHz, 14-02-00 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache > cpu0: 512KB 64b/line 16-way L2 cache > cpu0: smt 0, core 0, package 0 > > Times two. > > As you say the existing processes seem to work fine right up until > sshd is nearly (but not quite?) ready to fork: > > . > . > . > debug1: SSH2_MSG_EXT_INFO received > debug1: kex_input_ext_info: > server-sig-algs= > debug1: kex_input_ext_info: publickey-hostbo...@openssh.com=<0> > debug1: SSH2_MSG_SERVICE_ACCEPT received > > Ordinarily it would next attempt authentication. Does sshd fork and > drop privileges to do that? > > I don't know if that could help or even if it's related, but it can > be reproduced with confidence. I can poke the box or its VMs any > way that could shake some data loose. > > Matthew >
Re: Ryzen 9 (7x000) users: do you experience hangs?
On Tue, Jul 18, 2023 at 09:43:51AM +0100, Laurence Tratt wrote: > A small number of us with AMD Ryzen 9 (i.e. chips in the 7x000 range) > machines have been experiencing regular (often daily), or semi-regular > hangs, but without any obvious cause. > > What we don't know is if we're the unlucky few, or whether this might be a > wider issue. So, to see if there is some sort of pattern going on (e.g. are > certain motherboards / BIOSes correlated with hangs or not?), I'd like to > poll Ryzen 9 OpenBSD users. At a minimum we'd need to know: > > CPU model (e.g. "7900x") > Motherboard (e.g. "MSI PRO670-X") > Have you experienced crashes? (Yes/No) If "Yes": > what frequency (e.g. "daily/weekly/no obvious pattern")? > are there are obvious causes (e.g. "happens when I run program X")? > have you found any mitigations (e.g. "updated BIOS")? > Ideally a dmesg too > > We're as interested in Ryzen 9 users who aren't experiencing hangs as who > are! Please feel free to reply to the list, or to me individually, and I'll > collate the information and see if there are any patterns or not. > > > Laurie > -- > Personalhttps://tratt.net/laurie/ > Software Development Team https://soft-dev.org/ >https://github.com/ltratt https://twitter.com/laurencetratt > A bit of color commentary here... Laurie and I and a few other folks have been trying to debug the hangs that some people are seeing on these machines. He and I have identical hardware and he sees regular hangs, and I rarely see any (I think in the span of 7 months I've seen maybe 2 or 3 total). I've been using this machine in anger as a daily driver and I can't make it break and other people can't even make it a day without a hang. We've tried to debug the issue and narrow down what device(s) might be causing the problem, or what workload, etc, but nothing is pointing in any specific direction. We've also seen reports of "long slow death" crashes where existing processes continue to work for some time but nothing new can be execed, and eventually even the existing processes freeze. To me that sounds like a lock issue but it never happens on my machine and only infreqently elsewhere, so I can't really debug it. We'd like to know if others have similar machines and if they are stable or not. -ml
Re: Allwinner D1 riscv64 mango pi SBC
On Sun, Jul 16, 2023 at 11:56:51AM +0200, Peter J. Philipp wrote: > Hi *, > > I'm back for the moment. I was wondering who has a Allwinner D1 riscv64 SBC? > This is the Mango Pi SBC. > > I have one which has linux on it currently but I'm trying to boot OpenBSD on > it. But I'm fairly lazy and haven't done much with this lately. I can get > to the riscv64 loader but when it loads the kernel, it goes blind. So there > is more than just getting the GPIO pins configured which I think I have been > able to adjust. > > I use a QEMU-based riscv64 emulation to compile kernels which is slow but this > SBC isn't much faster either (1000 Mhz it claims). > > I use this u-boot directive to get into the boot loader: > > setenv bootobsd 'load mmc 0:1 0x4FA0 > /boot/dtbs/5.19.0-1009-allwinner/allwinner/sun20i-d1-nezha-memory.dtb ; load > mmc 0:f 0x4008 /EFI/OpenBSD/BOOTRISCV64.EFI ; bootefi 0x4008 > 0x4FA0' > > followed by a: > > run bootobsd > > I am unsure how to save this though in the u-boot itself. Any hints would be > appreciated. > > I think we need a specific riscv mailing list for this sort of stuff perhaps > it's too technical for misc. Regarding to the nostradamus stuff of someone > from chicago (Re: A couple of Questions) , check out "1st wave" and > "cade foster" on youtube (reruns), this will feed you more ideas. my personal > opinion is that time travel of information is possible, contributing to major > headaches when events get changed (for the prometheus seers). > > Back to "reality" I'm looking for a group of people to help getting the mango > pi working. I'm hampered by pride to ask knowledged people and these people > have their own directions and I don't want to bother their efforts. The more > we are the more we could possibly get something done. > The best way to get that done is to get hardware in the hands of developer(s). Wishing on misc@ is likely not going to get anyone interested. Check the commit logs for people working in this area, reach out to them, and see if they are interested in helping. -ml
Re: High ACPI CPU load
On Sat, Jul 15, 2023 at 04:34:20PM +0200, Julian Huhn wrote: > Since I got many DMARC rejection mails and therefore don't know how many > people this mail reached at all, once again with less restrictive DMARC > settings. > > On Sat, Jul 15, 2023 at 02:28:56PM +0200, Julian Huhn wrote: > > Moin! > > > > A few weeks ago, I put a new system into operation, where I notice a > > permanently high CPU load. With the help of top it appears that > > permanently the process acpi0 is executed. > > > > Is this a bug? > > > > I'm happy to help with more logs, if you tell me what you need. > > > > --Huhn > > This is a stuck GPE. This board in particular is a known issue; search the lists. mbuhl@ suggested a few months back that I get one of these machines to fix the issue, but when I started looking at it, the simplest fix was to just install a new bios. Since this is likely one of these super cheap 4 port igc(4) aliexpress "firewall PCs", you may need to search a bit to find a compatible bios since most of these don't have a real brand site associated with them. FWIW, the machines with "techvision" bios (like yours) exhibit this issue. Mine had techvision bios (and the same problem) before I flashed it to the image described below. You need to find this bios: bios0: vendor American Megatrends International, LLC. version "JK4LV107" date 04/17/2023 That one works on my machine, with exactly the same config as yours. No more ACPI GPE storm. I don't have the link anymore for where I found the BIOS image, but I think it was on servethehome in one of the long threads about these machines. You need to do some digging. While the root cause may be due to us lacking some driver for the device owning that GPE, or our lack of activating GPEs based on attached hardware, the 5-minute bios update fix was a good enough fix for me and I moved on to other things. The other lesson I learned is that you get what you pay for; buying $100 PCs from aliexpress means you're just going to be paying for it somewhere else. In this case, dealing with shoddy engineering and unsupported boards. -ml > > # top -S > > load averages: 1.01, 0.99, 1.00blech02.trust.dtm.huhn.dev > > 14:08:31 > > 85 processes: 81 idle, 4 on processor up 3 days 16:04:10 > > CPU0 states: 0.1% user, 0.0% nice, 16.3% sys, 0.5% spin, 75.6% intr, > > 7.5% idle > > CPU1 states: 0.1% user, 0.0% nice, 0.9% sys, 3.3% spin, 0.0% intr, > > 95.7% idle > > CPU2 states: 0.1% user, 0.0% nice, 0.9% sys, 3.3% spin, 0.0% intr, > > 95.7% idle > > CPU3 states: 0.1% user, 0.0% nice, 0.7% sys, 2.5% spin, 0.0% intr, > > 96.7% idle > > Memory: Real: 33M/10G act/tot Free: 21G Cache: 9303M Swap: 0K/32G > > > > PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU > > COMMAND > > 57981 root 3400K 1976K onproc/0 - 832:27 15.48% > > acpi0 > > 18343 root 2800K 1976K onproc/3 -85.2H 0.00% > > idle3 > > 71885 root -2200K 1976K sleep/1 -84.3H 0.00% > > idle1 > > 6761 root 2800K 1976K onproc/2 -84.3H 0.00% idle2 > > 7152 root -2200K 1976K sleep/0 -69.4H 0.00% idle0 > > 95844 root 1800K 1976K sleep/2 syncer0:48 0.00% > > update > > 92641 root 1000K 1976K sleep/1 bored 0:40 0.00% > > softnet > > 10729 root 1000K 1976K sleep/3 bored 0:31 0.00% > > sensors > > 31290 root 1000K 1976K sleep/2 bored 0:22 0.00% > > softnet > > 23268 _pflogd40 764K 1588K sleep/2 bpf 0:22 0.00% > > pflogd > > 7279 root 1000K 1976K sleep/1 bored 0:21 0.00% srdis > > 24604 jhuhn 20 1460K 3448K sleep/1 kqread0:14 0.00% sshd > > 9279 root -2200K 1976K sleep/0 bored 0:10 0.00% > > softclock > > 35785 root 105 200K 1976K sleep/2 pgzero0:10 0.00% > > zerothread > > 21023 root 100 476K 972K sleep/2 nanoslp 0:06 0.00% > > sensorsd > > 82628 root 1000K 1976K sleep/1 bored 0:05 0.00% > > systqmp > > 76212 root 1000K 1976K sleep/2 bored 0:05 0.00% > > softnet > > 52512 root 1000K 1976K sleep/1 bored 0:04 0.00% > > systq > > > > # dmesg > > OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 34180132864 (32596MB) > > avail mem = 33124827136 (31590MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x78d77000 (116 entries) > > bios0: vendor Techvision, LLC. version "5.19" date 09/16/2022 > > bios0: Techvision TVI7309X > > efi0 at bios0: UEFI 2.7 > > efi0: American Megatrends rev 0x50013 > > acpi0 at bios0: ACPI 6.2 > > acpi0: sleep states S0 S3 S5 > > acpi0: tables DSDT FACP MCFG FIDT SSDT SSDT SSDT HPET APIC PRAM SSDT > > SSDT NHLT LPIT SSDT SS
Re: load custom acpi table
On Mon, Jun 19, 2023 at 08:55:10AM +0300, S V wrote: > Hello, list! > > Is it possible to load custom acpi table on boot ? > > in FreeBSD it was possible by strings in conf like > > acpi_dsdt_load="YES" acpi_dsdt_name="filename.aml" no
Re: apm doesn't know AC state on APU1C
On Wed, Apr 26, 2023 at 08:48:00PM +0200, Jan Stary wrote: > On Apr 26 11:38:40, dera...@openbsd.org wrote: > > Jan Stary wrote: > > > > > On Apr 26 14:57:22, stu.li...@spacehopper.org wrote: > > > > On 2023-04-26, Jan Stary wrote: > > > > > This is current/amd64 on an APU1C (dmesg below). > > > > > While 'sysctl hw' knows hw.power=1, apm doesn't know: > > > > > > > > > > Battery state: absent, 0% remaining, unknown life estimate > > > > > AC adapter state: not known > > > > > Performance adjustment mode: auto (1000 MHz) > > > > > > > > > > Yes, apmd -A is running. > > > > > > > > > > Not that this matters much, the machine will always be on AC; > > > > > but it still seems strange for apm to not know. > > > > > > > > I don't expect the machine has bothered with a way to pass that > > > > information through to the OS. > > > > > > Does sysctl hw.power know through a different way than apm? > > > > Does your APU1C have acpi? > > Yes (dmesg below). Is that how sysctl hw gets it, as opposed to apm? > > Jan > no acpiac(4). > > OpenBSD 7.3-current (GENERIC.MP) #0: Wed Apr 26 12:48:53 CEST 2023 > h...@stary.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 2098511872 (2001MB) > avail mem = 2015346688 (1921MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (7 entries) > bios0: vendor coreboot version "4.0" date 09/08/2014 > bios0: PC Engines APU > acpi0 at bios0: ACPI 4.0 > acpi0: sleep states S0 S1 S3 S4 S5 > acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT > acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) > PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) > UOH4(S3) UOH5(S3) [...] > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpihpet0 at acpi0: 14318180 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD G-T40E Processor, 1000.02 MHz, 14-02-00 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache > cpu0: 512KB 64b/line 16-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 200MHz > cpu0: mwait min=64, max=64, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD G-T40E Processor, 1000.02 MHz, 14-02-00 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache > cpu1: 512KB 64b/line 16-way L2 cache > cpu1: smt 0, core 1, package 0 > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (AGPB) > acpiprt2 at acpi0: bus -1 (HDMI) > acpiprt3 at acpi0: bus 1 (PBR4) > acpiprt4 at acpi0: bus 2 (PBR5) > acpiprt5 at acpi0: bus 3 (PBR6) > acpiprt6 at acpi0: bus -1 (PBR7) > acpiprt7 at acpi0: bus 5 (PE20) > acpiprt8 at acpi0: bus -1 (PE21) > acpiprt9 at acpi0: bus -1 (PE22) > acpiprt10 at acpi0: bus -1 (PE23) > acpiprt11 at acpi0: bus 4 (PIBR) > acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 > acpicmos0 at acpi0 > acpibtn0 at acpi0: PWRB > acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS > acpicpu1 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS > cpu0: 1000 MHz: speeds: 1000 800 MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "AMD 14h Host" rev 0x00 > ppb0 at pci0 dev 4 function 0 "AMD 14h PCIE" rev 0x00: msi > pci1 at ppb0 bus 1 > re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E > (0x2c00), msi, address 00:0d:b9:3d:bb:fc > rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 > ppb1 at pci0 dev 5 function 0 "AMD 14h PCIE" rev 0x00: msi > pci2 at ppb1 bus 2 > re1 at pci2 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E > (0x2c00), msi, address 00:0d:b9:3d:bb:fd > rgephy1 at re1 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 > ppb2 at pci0 dev 6 function 0 "AMD 14h PCIE" rev 0x00: msi > pci3 at ppb2 bus 3 > re2 at pci3 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E > (0x2c00), msi, address 00:0d:b9:3d:bb:fe > rgephy2 at re2 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 > ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x40: apic 2 int 19, > AHCI 1.2 > scsibus1 at ahci0: 32 targets > ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 2 int 18, > version 1.0, legacy support > ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00: apic 2 int 17 > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 configuration 1 interface 0 "ATI
Re: hardware
On Mon, Apr 17, 2023 at 02:21:14PM -0600, Theo de Raadt wrote: > Gustavo Rios wrote: > > > What is the best supported servers by OpenBSD ? > > The silver ones work a little bit better than the black ones. > disagree. All my long running servers are the black ones.
Re: openbsd get really hot/warm
On Thu, Mar 02, 2023 at 06:43:02PM +0100, l...@netc.fr wrote: > > hello > > > > unfortunately since a week I was wondering about something : > > on two old hp elitebook, it looks like under win7 and linux/LMDE, that at a > general glance everything looks correct > > > > but on openbsd, something happens, even if CPU is not high : it's a huge > overheating, with fans going almost everytime in the high speed, and lower > case of the laptop, almost burning (in a way it's really warm, impossible to > get it a minute on laps) > > I saw the same problem on an asus laptop. > > is there anyway to know where it come from? > > > > openbsd v7.1 > > > > under win7 and linux (lmde5), this problem doesnt happens. It's really > strange. > thak you for ideas man sendbug
Re: Calculating VMs/CPU
On Sun, Feb 05, 2023 at 10:12:39PM +, Mike Larkin wrote: > On Sun, Feb 05, 2023 at 03:53:34PM -0500, Nick Holland wrote: > > On 2/4/23 17:31, latin...@vcn.bc.ca wrote: > > > Hello misc > > > > > > i am building an only VMD server: > > > > > > How could calculate the relation: CPU, Ram, Storage, VMs please? > > > > > > Thanks. > > > PD: > > > I have a Lenovo ThinkPad Edge 4 i3 cores, 500GB disk. 8GB Ram. > > > > > > > This is kinda virtualization 101 stuff, not really specific to OpenBSD. > > > > RAM: assume more than 1:1. The VM will require certain overhead, as will > > the base OS. So, if you want 2G VMs, you won't be getting four of them > > on your 8G machine. You might get three. (some VM systems support > > "thin provisioning" of RAM. This is really a great way to hurt yourself > > unless you really know what you -- and all your guest OSs -- are doing. > > And you are still really likely to hurt yourself). > > All vmm memory is wired, so do not overcommit memory with vmm/vmd. > > > > > Disk: Assume 1:1. Even if your VM system supports thin provisioning > > (OpenBSD doesn't appear to), don't. Assume you will use 100% of the > > Both supported formats (qcow2 and raw) are thin. But your advice is > sound; assume you will eventually use 100% of what you provision. Here's what I meant by that: $ /export/VMs> vmctl create -s 100g big.raw vmctl: raw imagefile created $ /export/VMs> du -h big.raw 192Kbig.raw $ /export/VMs> ls -la big.raw -rw--- 1 mlarkin wheel 107374182400 Feb 5 14:20 big.raw Same holds true for qcow2. -ml > > > disk you provision for a VM. Because you will. Thin provisioning VMs > > is generally a bad idea. > > > > CPU: Test, don't speculate. This is where you can get some benefit from > > resource sharing. You can also end up fooling yourself into thinking > > that 10 VMs that are usually 90% idle can share one CPU, because that > > 10% busy time? They are all working on the same task. > > > > > > In your case of a 4xi3 8g/500g, I suspect your machine will run out of > > RAM, CPU and then disk, in that order, though if you work at it, you > > can run out in any order you wish. :) > > > > But it is all how you define your VMs and what you do with it. Your > > host i3 could be maxed out with a web browser, so the VMs you run are > > going to have to be minimal and your expectations modest. > > > > Nick. > > >
Re: Calculating VMs/CPU
On Sun, Feb 05, 2023 at 03:53:34PM -0500, Nick Holland wrote: > On 2/4/23 17:31, latin...@vcn.bc.ca wrote: > > Hello misc > > > > i am building an only VMD server: > > > > How could calculate the relation: CPU, Ram, Storage, VMs please? > > > > Thanks. > > PD: > > I have a Lenovo ThinkPad Edge 4 i3 cores, 500GB disk. 8GB Ram. > > > > This is kinda virtualization 101 stuff, not really specific to OpenBSD. > > RAM: assume more than 1:1. The VM will require certain overhead, as will > the base OS. So, if you want 2G VMs, you won't be getting four of them > on your 8G machine. You might get three. (some VM systems support > "thin provisioning" of RAM. This is really a great way to hurt yourself > unless you really know what you -- and all your guest OSs -- are doing. > And you are still really likely to hurt yourself). All vmm memory is wired, so do not overcommit memory with vmm/vmd. > > Disk: Assume 1:1. Even if your VM system supports thin provisioning > (OpenBSD doesn't appear to), don't. Assume you will use 100% of the Both supported formats (qcow2 and raw) are thin. But your advice is sound; assume you will eventually use 100% of what you provision. > disk you provision for a VM. Because you will. Thin provisioning VMs > is generally a bad idea. > > CPU: Test, don't speculate. This is where you can get some benefit from > resource sharing. You can also end up fooling yourself into thinking > that 10 VMs that are usually 90% idle can share one CPU, because that > 10% busy time? They are all working on the same task. > > > In your case of a 4xi3 8g/500g, I suspect your machine will run out of > RAM, CPU and then disk, in that order, though if you work at it, you > can run out in any order you wish. :) > > But it is all how you define your VMs and what you do with it. Your > host i3 could be maxed out with a web browser, so the VMs you run are > going to have to be minimal and your expectations modest. > > Nick. >
Re: Calculating VMs/CPU
On Sat, Feb 04, 2023 at 10:02:13PM -0800, latin...@vcn.bc.ca wrote: > > On Sat, Feb 04, 2023 at 02:31:39PM -0800, latin...@vcn.bc.ca wrote: > >> Hello misc > >> > >> i am building an only VMD server: > >> > >> How could calculate the relation: CPU, Ram, Storage, VMs please? > >> > >> Thanks. > >> PD: > >> I have a Lenovo ThinkPad Edge 4 i3 cores, 500GB disk. 8GB Ram. > >> > > > > what are you planning on running? > > > > Thanks for your attention: > > For now, only OpenBSD with connection to the world' the 3rd option i think. > > In the future: > BSD and Linux! > > How can i get the related information please. I have installed OpenBSD 7.2 > and it is a testing laptop. it is going to be reproduced on arented bare > metal Server. > > > > I can't answer your question without knowing what you plan to run in the VMs. Just don't overcommit RAM. -ml
Re: Calculating VMs/CPU
On Sat, Feb 04, 2023 at 02:31:39PM -0800, latin...@vcn.bc.ca wrote: > Hello misc > > i am building an only VMD server: > > How could calculate the relation: CPU, Ram, Storage, VMs please? > > Thanks. > PD: > I have a Lenovo ThinkPad Edge 4 i3 cores, 500GB disk. 8GB Ram. > what are you planning on running?
Re: hw.ncpuonline
On Tue, Jan 31, 2023 at 05:54:23PM -0800, Justin Muir wrote: > Hi all, > > I've got an AMD A10 with 4 cores and only 2 are online. I'm not sure how to > enable the other 2. > > hw.ncpufound=4 btw > > Any ideas out there? > > Tia! likely sysctl hw.smt=1
Re: virtualization in openbsd running on Raspberry pi
On Thu, Dec 22, 2022 at 08:47:00AM +0530, Sandeep Gupta wrote: > Just wanted to double confirm that it's not possible to run virtual > instances of openBSD on openBSD running on Raspberry Pi. > This is because the CPU has no support for SLAT/EPT (but these are only for > intel/amd. doesn't say about arm). > > Also, in my instance, I don't see vmctl installed. In fact, doing `rcctl > start vmd` fails. But don't see error messages in /var/log/messages. > Where are error messages logged for running daemons? > > Thanks > Sandeep vmm/vmd is only supported on amd64.
Re: updated vmm support modules for older Linux guests
On Thu, Nov 24, 2022 at 12:35:20PM -0500, Dave Voutila wrote: > I finally got around to slapping more hacky #ifdef's onto my vmm_clock > [1] and virtio_vmmci [2] Linux kernel modules because I found older > Linux kernel versions (~3.10 era) didn't support compiling them. > > If you host things like CentOS 7 guests under vmm(4)/vmd(8), I recommend > trying them out and opening a GitHub issue in the respective project if > there's something wrong. (PR's welcome.) > > No idea what I'm talking about? > > * virtio_vmmci - Linux port of vmmci(4) that helps signal reboots/rtc > sync with Linux guests via vmctl(8) and vmd(8). > > * vmm_clock - duct-taped version of kvmclock to work with vmm(4)'s > pvclock(4) paravirtualized clock. > > -dv > > [1] https://github.com/voutilad/virtio_vmmci > [2] https://github.com/voutilad/vmm_clock > Awesome, thanks!
Re: Suspend not working Lenovo X1 Nano Gen 2
On Wed, Nov 02, 2022 at 02:31:56PM +, Ottavio Caruso wrote: > Op 01/11/2022 om 22:50 schreef Mike Larkin: > > On Tue, Nov 01, 2022 at 05:05:21PM -0500, Jason Morris wrote: > > > Hi Everyone, > > > > > > I've upgraded from a X1 Nano Gen 1 and noticed that suspend isn't working > > > on the new machine. By running 'zzz' it starts to suspend and then wakes > > > up after ~10 seconds. I've ran apmd in debug mode and got the following: > > > > > > apmd -d > > > battery status: high. external power status: not connected. estimated > > > battery life 65% (225 minutes life time estimate) > > > can't disable driver messages, error: Inappropriate ioctl for device > > > apmevent index 0 > > > apmevent 0006 index 193 > > > system suspending > > > battery status: high. external power status: not connected. estimated > > > battery life 65% (235 minutes life time estimate) > > > /etc/apm/suspend exited with status 0 > > > apmevent 0003 index 194 > > > do_etc_file(): cannot access file /etc/apm/resume > > > system resumed from sleep > > > battery status: high. external power status: not connected. estimated > > > battery life 65% (272 minutes life time estimate) > > > apmevent 0006 index 196 > > > apmevent 0006 index 197 > > > > > > > > > When running 'ZZZ' the system hibernates but when it's waking back up, > > > I'm flooding with the following error: > > > > > > "*ERROR* Fault errors on pipe A" > > > > > > Any recommendations on how I can move forward? > > > > > > -Jason > > > > This is a known issue. No solution at this time. > > > > -ml > > > > > > > Is this a known problem for all Lenovo's? I'm going to try an installation > on a Thinkpad E130. > > -- > Ottavio Caruso > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > Just the nano gen2 afaik.
Re: Suspend not working Lenovo X1 Nano Gen 2
On Tue, Nov 01, 2022 at 05:05:21PM -0500, Jason Morris wrote: > Hi Everyone, > > I've upgraded from a X1 Nano Gen 1 and noticed that suspend isn't working on > the new machine. By running 'zzz' it starts to suspend and then wakes up > after ~10 seconds. I've ran apmd in debug mode and got the following: > > apmd -d > battery status: high. external power status: not connected. estimated battery > life 65% (225 minutes life time estimate) > can't disable driver messages, error: Inappropriate ioctl for device > apmevent index 0 > apmevent 0006 index 193 > system suspending > battery status: high. external power status: not connected. estimated battery > life 65% (235 minutes life time estimate) > /etc/apm/suspend exited with status 0 > apmevent 0003 index 194 > do_etc_file(): cannot access file /etc/apm/resume > system resumed from sleep > battery status: high. external power status: not connected. estimated battery > life 65% (272 minutes life time estimate) > apmevent 0006 index 196 > apmevent 0006 index 197 > > > When running 'ZZZ' the system hibernates but when it's waking back up, I'm > flooding with the following error: > > "*ERROR* Fault errors on pipe A" > > Any recommendations on how I can move forward? > > -Jason This is a known issue. No solution at this time. -ml
Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
On Fri, Oct 28, 2022 at 12:30:11PM -0600, Theo de Raadt wrote: > Kalabic S, wrote: > > > To be more precise, I wanted to say sticking with FreeBSD means > > sticking with whatever behavior VMware will keep consistent and > > support in the future. For "Others" option I don't think they care and > > is more probable to vary. > > I cannot tell the difference. I think you are completely unqualified > to know what "they will not change" fakery vmware is doing with the MSR's > and clock related registers... it is actually possible that when they > *know* it is one particular operating system they do something sophisticated > to fool that one specific operating system, whereas when they don't know > what the operating system is, they reduce the amount of trickery. > > You don't know. I don't know. None of us know. > > But can you please stop making claims you can't back. > I think it's reasonable to try and claim that whatever we are, we are the closest to "that thing". Meaning, the OP said we should claim we are FreeBSD 64 bit or 32 bit or whatever. Fine, but let's spend some time to actually figure out *what* we should say we are before we just pick something randomly because "it fixed my machine". Maybe we should say we're Windows? Maybe we should say we're Linux? My point, and I think Theo's as well, is we don't know and just randomly taking a diff because it fixes one scenario on one version of ESXi is shortsighted. So I would ask the OP to: - try different OS choices - on different versions of ESX - on different versions of VMware fusion - on different versions of VMware workstation - on different versions of OpenBSD VMs - on different archs (i386/amd64) of OpenBSD VMs ... and then report back what the findings are. -ml
Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
On Fri, Oct 28, 2022 at 06:25:11PM +0200, Kalabic S. wrote: > > In my testing, this has no effect on the operation of the clock. Only > > the guest OS selected in the VM configuration does have an effect. > > We should remove any suggestion that 32bit FreeBSD is the right thing > > to select though, so changing the guest OS we report is still a good > > idea. > > Interestingly, it looks like if the guest OS is set to 'Other > > (64-bit)', and vmt reports an unrecognised short guest OS name (such > > as 'OpenBSD'), vcenter will display the full guest OS name, so you get > > something like 'OpenBSD 7.2 GENERIC.MP#31'. > > I'm pretty sure this caused problems in the distant past, but it seems > > fine now with esxi 6.7+, so I think we should change to saying we're > > OpenBSD instead. > > Replacing 'FreeBSD' with something ESXi doesn't support will almost > certainly have drawbacks. We can already see different 'Guest OS' options > have different effects on guest VMs. What drawbacks? Does jmatthew@'s diff to change the name to OpenBSD fix the problem or not? If it does, that's a more factually accurate diff. We are not "FreeBSD 32 bit" or "FreeBSD 64 bit" and it seems that calling ourselves "OpenBSD" doesn't cause problems anymore. So I'd like to know what "certainly have drawbacks" means. Can you shed some light on that please? -ml > > Also, OpenBSD really is part of BSD family. > > I have an OpenBSD VM running without issues as a guest with 'FreeBSD' option > for years and serving as an Internet router for home network. IMO, it's > pretty good chice. > > Only thing I would update is to make it exactly specify to hypervisor is it > 32 or 64 bit OS. So 'FreeBSD-64' for amd64 and 'FreeBSD' for i386. >
Re: VMware Tools driver to advertise OS as 'FreeBSD 64-bit' OS, not 32-bit version
On Wed, Oct 26, 2022 at 07:39:03PM +0200, Kalabic S. wrote:
> Hello @misc,
>
> I do not see a reason not to update OS version that vmt (kernel level
> implementation of VMware Tools) is advertising to VMware hypervisor from 32
> bit FreeBSD to 64 bit version.
>
> If for nothing else, there's clock running forward issue that appeared in
> 7.2 release and that is solved simply by manually specifying "FreeBSD
> 64-bit" instead of "FreeBSD 32-bit" for "Guest OS Version".
> - https://marc.info/?t=16667408377&r=1&w=2
> - https://marc.info/?t=16663046932&r=1&w=2
>
> Attached is a simple patch that I tested and that changes string "FreeBSD"
> to "FreeBSD-64" in a call to "SetGuestInfo" function on hypervisor and that
> accomplishes the task.
>
> What could be a drawback? Is author David Gwynne still active and can he
> give some feedback?
What versions of ESXi did you test this with?
Did you test both i386 OpenBSD VMs and amd64 ones on each version?
-ml
> Index: dev/pv/vmt.c
> ===
> RCS file: /cvs/src/sys/dev/pv/vmt.c,v
> retrieving revision 1.26
> diff -u -p -u -r1.26 vmt.c
> --- dev/pv/vmt.c 8 Sep 2022 10:22:06 - 1.26
> +++ dev/pv/vmt.c 26 Oct 2022 17:01:39 -
> @@ -633,7 +633,7 @@ vmt_update_guest_info(struct vmt_softc *
>*/
>
> if (vm_rpc_send_rpci_tx(sc, "SetGuestInfo %d %s",
> - VM_GUEST_INFO_OS_NAME, "FreeBSD") != 0) {
> + VM_GUEST_INFO_OS_NAME, "FreeBSD-64") != 0) {
> DPRINTF("%s: unable to set guest OS", DEVNAME(sc));
> sc->sc_rpc_error = 1;
> }
Re: VM(D) Interface Question
On Sat, Oct 01, 2022 at 08:32:35AM -0400, Dave Voutila wrote: > > Holger Glaess writes: > > > Hi > > > > > > how many Interfaces can an single VM have ? > > > > > > With 3 Interface in my vm.conf the vm works, with 4 not i get "to many > > interfaces". > > > > The maximum supported per vm is currently 4. Without your config or > invocation triggering the "too many interfaces" when you use 4, I cannot > explain any further. Debug output would also be helpful to make sure > it's the message coming from the config parsing as I suspect. > > -dv > 4 should work (I just did this and it worked here). There is nothing special about "4", it's just a reasonable number we picked early on. You could probably crank that higher. Note that there is a maximum number of devices per vm which I think is 10 (includes all virtio devices and don't forget we use one for the rnd device). Technically we rotate the IRQ back to the start of the list at 10 devices but the level triggered code for interrupt sharing in 8259.c probably hasn't been tested too much and I wouldn't be surprised if something is broken there. -ml
Re: mSATA woes on APU2D0
On Thu, Aug 25, 2022 at 05:51:18PM +0200, Jan Stary wrote: > This is current/amd64 on and APU2D0 (dmesg below) > upgraded to the most recent coreboot and snapshot. > > I am having trouble using an mSATA disk on the machine. > It boots from a 32GB SD card and runs just fine; > but with an mSATA plugged into the mSATA port, > it does not even get to boot the OS. > > I have tried two cards: a cheapo from ebay, > and the good one straight from PC Engines. > Same story in both cases: it worked for a few boots, > running a filesystem on the msata which reads and writes, > but then, after one more reboot, the leds on the card > start blinking, the card makes a clicking sound, > and the cereal emits only garbage AFAICT. Sounds like a power supply issue. IIRC APUs were super sensitive to having enough current. Probably try a beefier power supply? -ml > > Here are two very short videos of what happens: > > http://stare.cz/.tmp/msata1.mp4 > http://stare.cz/.tmp/msata2.mp4 > > These are the cereal outputs (as in script of cu, hexdump -C), > with one card: > > c0 00 00 00 00 fe 00 00 e0 00 e0 00 00 f8 00 00 || > 0010 c0 00 80 00 80 00 00 00 e0 00 e0 00 80 00 00 c0 || > 0020 00 00 00 00 00 e0 00 00 c0 00 00 f8 00 c0 00 80 || > 0030 00 00 c0 00 00 00 c0 00 00 00 00 00 00 e0 00 c0 || > 0040 00 c0 00 80 00 00 e0 00 c0 00 c0 00 00 00 00 00 || > > and the other: > > 80 00 00 00 00 00 00 00 c0 00 00 00 00 00 e0 00 || > 0010 00 00 00 00 00 00 c0 00 00 c0 00 00 80 00 00 00 || > 0020 00 fe 00 00 80 00 00 f0 00 00 00 00 e0 00 00 00 || > 0030 00 00 80 00 00 00 80 00 00 00 fe 00 c0 00 00 80 || > 0040 00 00 c0 00 80 00 00 00 c0 00 00 00 00 e0 00 00 || > > Note that I am not booting _from_ the msata card, > but from the SD card, which in itself works fine, > if the msata card is not plugged in. > > (On an APU2E2, I am booting from msata without problems.) > > Is anyone else seeing this? > Is this a hardware problem? > > Jan > > > OpenBSD 7.2-beta (GENERIC.MP) #707: Wed Aug 24 10:03:37 MDT 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 2112430080 (2014MB) > avail mem = 2031087616 (1936MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7ee92040 (13 entries) > bios0: vendor coreboot version "v4.17.0.2" date 07/28/2022 > bios0: PC Engines apu2 > acpi0 at bios0: ACPI 6.0 > acpi0: sleep states S0 S1 S4 S5 > acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT DRTM HPET > acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) > UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-63 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD GX-412TC SOC, 998.28 MHz, 16-30-01 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 64b/line > 16-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD GX-412TC SOC, 998.11 MHz, 16-30-01 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 64b/line > 16-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: AMD GX-412TC SOC, 998.11 MHz, 16-30-01 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT > cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 2MB 64b/line > 16-way L2 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 3 (application processor) > cpu3: AMD GX-412TC SOC, 998.16 MHz, 16-30-01 > cpu3:
Re: Excessive fan - Thinkpad X1 (4th Gen)
On Fri, Jul 22, 2022 at 01:53:25PM +0100, openbsdli...@speedymail.org wrote: > Hi all, > > I have a recurring problem with OpenBSD on my Thinkpad X1 Carbon (4th Gen). > > When the machine wakes from suspend, there is (approximately) a 75% > chance that the fan start and pretty much max out. Doesn't matter about > CPU usage or temperature. Suspending (zzz) or closing the lid tends not > to fix it - the fan will eventually stop but will start again on wake. > Rebooting or hibernating is required. > > This has occured on this particular machine with various stable/release > versions of OpenBSD and I'm currently running the latest snapshot > (7.2-beta). > > I have used various Linux distros (Debian and Arch, mostly) on this > machine in the past and this has never happened. > > I also have a Thinkpad X220 running the same versions historically > without issue. > > I can't find much in the archives so I'm hoping someone might be able to > offer something. Many thanks in advance. > > I include sysctl hw, sysctl hw.sensors and dmesg below: > -- > Best regards, > Matthew systat vm 0.5 tell you anything perhaps an interrupt storm? Check the columns on the right when it happens. If not, build a kernel with acpi debug and see if you can find if its a stuck GPE. We've seen that happen before. Also check the lists, IIRC around this generation of X1 there was some bios setting about thunderbolt assist that needed to be tweaked or this would happen. -ml > > syctl hw: > > hw.machine=amd64 > hw.model=Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz > hw.ncpu=4 > hw.byteorder=1234 > hw.pagesize=4096 > hw.disknames=sd0:74bfeea5a5883a85,sd1:7da04eb499cd98e3 > hw.diskcount=2 > hw.sensors.cpu0.temp0=36.00 degC > hw.sensors.cpu0.frequency0=32.00 Hz > hw.sensors.cpu1.frequency0=33.00 Hz > hw.sensors.acpibtn0.indicator0=On (lid open) > hw.sensors.acpibat0.volt0=15.20 VDC (voltage) > hw.sensors.acpibat0.volt1=16.26 VDC (current voltage) > hw.sensors.acpibat0.power0=0.00 W (rate) > hw.sensors.acpibat0.watthour0=38.50 Wh (last full capacity) > hw.sensors.acpibat0.watthour1=1.93 Wh (warning capacity) > hw.sensors.acpibat0.watthour2=0.20 Wh (low capacity) > hw.sensors.acpibat0.watthour3=36.78 Wh (remaining capacity), OK > hw.sensors.acpibat0.watthour4=52.06 Wh (design capacity) > hw.sensors.acpibat0.raw0=0 (battery idle), OK > hw.sensors.acpiac0.indicator0=On (power supply) > hw.sensors.acpithinkpad0.fan0=6940 RPM > hw.sensors.acpithinkpad0.indicator0=Off (port replicator), UNKNOWN > hw.sensors.acpitz0.temp0=48.00 degC (zone temperature) > hw.sensors.pchtemp0.temp0=35.50 degC > hw.sensors.softraid0.drive0=online (sd1), OK > hw.cpuspeed=2701 > hw.setperf=100 > hw.vendor=LENOVO > hw.product=20FB002LUS > hw.version=ThinkPad X1 Carbon 4th > hw.physmem=17011974144 > hw.usermem=15295393792 > hw.ncpufound=4 > hw.allowpowerdown=1 > hw.perfpolicy=auto > hw.smt=0 > hw.ncpuonline=2 > hw.power=1 > > sysctl hw.sensors: > > hw.sensors.cpu0.temp0=34.00 degC > hw.sensors.cpu0.frequency0=325000.00 Hz > hw.sensors.cpu1.frequency0=32.00 Hz > hw.sensors.acpibtn0.indicator0=On (lid open) > hw.sensors.acpibat0.volt0=15.20 VDC (voltage) > hw.sensors.acpibat0.volt1=16.26 VDC (current voltage) > hw.sensors.acpibat0.power0=0.00 W (rate) > hw.sensors.acpibat0.watthour0=38.50 Wh (last full capacity) > hw.sensors.acpibat0.watthour1=1.93 Wh (warning capacity) > hw.sensors.acpibat0.watthour2=0.20 Wh (low capacity) > hw.sensors.acpibat0.watthour3=36.78 Wh (remaining capacity), OK > hw.sensors.acpibat0.watthour4=52.06 Wh (design capacity) > hw.sensors.acpibat0.raw0=0 (battery idle), OK > hw.sensors.acpiac0.indicator0=On (power supply) > hw.sensors.acpithinkpad0.fan0=6932 RPM > hw.sensors.acpithinkpad0.indicator0=Off (port replicator), UNKNOWN > hw.sensors.acpitz0.temp0=48.00 degC (zone temperature) > hw.sensors.pchtemp0.temp0=35.00 degC > hw.sensors.softraid0.drive0=online (sd1), OK > > dmesg: > > OpenBSD 7.2-beta (GENERIC.MP) #640: Thu Jul 21 21:03:56 MDT 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 17011974144 (16223MB) > avail mem = 16479031296 (15715MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xd7057000 (65 entries) > bios0: vendor LENOVO version "N1FET75W (1.49 )" date 05/25/2021 > bios0: LENOVO 20FB002LUS > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP TCPA SSDT UEFI SSDT SSDT ECDT HPET APIC MCFG SSDT > SSDT DBGP DBG2 BOOT BATB SLIC SSDT SSDT MSDM DMAR ASF! FPDT UEFI > acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP9(S4) XHCI(S3) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpiec0 at acpi0 > acpihpet0 at acpi0: 2399 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz, 2494.19 MHz, 06-4e-03 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SE
Re: [RISC V] OpenBSD/riscv64 vs devterm R1 kit
On Fri, Jun 24, 2022 at 06:34:14PM +0200, Alexander Shendi wrote: > Hello @misc world, > > I couldn't find any mailing list for the OpenBSD RISC V port, so I'm posting > here. If there is a better place, please give directions. Also feel free to > forward to anyone who may be interested or of help. > > Does anyone have experience with the RISC-V devterm kit? Apparently it's > quite easy to assemble. I have one of these. Yes, it's easy to assemble. > > Drawbacks: > * Slowish CPU > * CPU design not really open > * Apparently a bit awkward to use > > Could it run OpenBSD/riscv64, or is only the HiFive board supported? It currently does not work with OpenBSD. It uses the Allwinner D1, which has DMA issues. Another thing that would need to be worked out is the panel output support. I was going to try and take a whack at these issues but I probably won't have time. > > https://www.clockworkpi.com/product-page/devterm-kit-r01 > > I would volunteer to buy one or two for OpenBSD devs, but I don't know if > they could be used for serious development work. > > Many Thanks in advance, > > Alexander > -- > Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet. >
Re: M2 disk slowing down on sequential reads
On Mon, Jun 13, 2022 at 06:01:39PM +0200, Jan Stary wrote: > This is current/amd64 on a PC (dmesg below). > It is using this M2 SSD as a system disk: > > sd0 at scsibus1 targ 0 lun 0: > naa.5001b448b8532530 > sd0: 238475MB, 512 bytes/sector, 488397168 sectors, thin > > I do a weekly dd read of all disks as a precaution > to see if any of the report any errors, as in > dd bs=1m conv=noerror if=/dev/rsd0c of=/dev/null > > This particular disk seems to be very fast when reading > up to something between 3GB and 4GB; then the speed drops: > > dd bs=1m count=1k conv=noerror if=/dev/rsd0c of=/dev/null > 1073741824 bytes transferred in 5.404 secs (198679263 bytes/sec) > 1073741824 bytes transferred in 5.271 secs (203672530 bytes/sec) > 1073741824 bytes transferred in 5.072 secs (211697503 bytes/sec) > > dd bs=1m count=2k conv=noerror if=/dev/rsd0c of=/dev/null > 2147483648 bytes transferred in 8.392 secs (255879364 bytes/sec) > 2147483648 bytes transferred in 8.413 secs (255242225 bytes/sec) > 2147483648 bytes transferred in 9.139 secs (234968292 bytes/sec) > > dd bs=1m count=3k conv=noerror if=/dev/rsd0c of=/dev/null > 3221225472 bytes transferred in 11.823 secs (272447923 bytes/sec) > 3221225472 bytes transferred in 12.124 secs (265674803 bytes/sec) > > dd bs=1m count=4k conv=noerror if=/dev/rsd0c of=/dev/null > 4294967296 bytes transferred in 53.442 secs (80365818 bytes/sec) > 4294967296 bytes transferred in 52.680 secs (81528574 bytes/sec) > 4294967296 bytes transferred in 52.082 secs (82465212 bytes/sec) > > dd bs=1m count=5k conv=noerror if=/dev/rsd0c of=/dev/null > 5368709120 bytes transferred in 179.967 secs (29831567 bytes/sec) > 5368709120 bytes transferred in 221.400 secs (24248900 bytes/sec) > 5368709120 bytes transferred in 215.760 secs (24882667 bytes/sec) > > That's a drop from 200MB/s to 20MB/s. > I get a similar rate of slowdown with different dd bs. > > Is this expected when doing a long sequential read of this kind of disks? > could be thermals. Try a better heat sink/fan on the drive then try again? > (The rotating disks also slow down when doing a long read, > but only marginaly: a dd read of the whole disk is not > that much slower than a read of the first 10GB.) > > Jan > > > > OpenBSD 7.1-current (GENERIC.MP) #0: Thu Apr 14 13:26:20 CEST 2022 > h...@box.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 17009606656 (16221MB) > avail mem = 16476803072 (15713MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries) > bios0: vendor Award Software International, Inc. version "F3" date 03/31/2011 > bios0: Gigabyte Technology Co., Ltd. H67MA-USB3-B3 > acpi0 at bios0: ACPI 1.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT > acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) > PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf400, bus 0-63 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.60 MHz, 06-2a-07 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.10 MHz, 06-2a-07 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.09 MHz, 06-2a-07 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 0, core 2, package
Re: hw.perfpolicy behavior on desktop/server
On Thu, May 12, 2022 at 01:16:01AM +0200, f.holop wrote: > Stuart Henderson - Mon, 09 May 2022 at 17:17:57 > > Currently, you can either set it manually to low speed > > (hw.perfpolicy=manual, hw.setperf=0), modify the kernel (e.g. with the > > diff below), or use obsdfreqd from packages. The latter is only in > > -current packages not 7.1, but it could be built from ports. > > I think the elephant in the room is: > will this change be reverted? > > What is the rationale of not letting wall powered servers > throttle down? > > -f > -- > If you want to revert it, revert it. You have the code. -ml
Re: HP T430 "Thin Client": Won't sysupgrade without HDMI monitor attached.
On Fri, May 06, 2022 at 11:39:51PM -0400, Nick Holland wrote: > On 5/6/22 2:30 PM, Nick Holland wrote: > > On 5/6/22 12:48 PM, Theo de Raadt wrote: > > > Florian Obser wrote: > > > > > > > So, if you end up with a /bsd.upgrade on the running system that is > > > > still mode 0700, your bootloader is on the fritz. > > > > > > > > If you have a /bsd.upgrade that's 0600 your bootloader found the kernel > > > > and tried to boot it, but the installer didn't get very far. > > > > > > > > If there is no /bsd.upgrade after a reboot and no email to root the > > > > installer got rebooted by a watchdog process, otherwise you got an email > > > > to root detailing the upgrade process. > > > > > > A very nice 3-way split. > > > > Brilliant, even. > > > Then once you figure out which one of those 3 is happening, it is easy > > > to reason about how to create further differentiations and see which is > > > happening. > > > > I was very much guessing it was /boot, but no. > > -rw--- 1 root wheel 4609699 May 6 13:13 bsd.upgrade > > > > So ... it's booting bsd.upgrade and failing, which explains why copying > > bsd.upgrade (aka bsd.rd) to /bsd tossed it into a lala-loop. > > > > Unfortunately, this machine doesn't retain dmesg buffer between boots. > > > > so ... booted bsd.rd with a monitor attached, and grabbed the dmesg below. > > > > I'm looking at this: > > > > efifb0 at mainbus0: 1920x1080, 32bpp > > > > If the system is booted (bsd) without a monitor attached, that says: > > > > efifb at mainbus0 not configured > > > > Getting to the boot> prompt, typing "boot bsd.rd", unplugging the monitor > > and hitting "ENTER" resulted in a successful boot of the bsd.rd kernel (and > > efifb is showing the monitor as connected). > > > > I tried bsd.rd renamed "bsd" so it would only boot bsd.rd, and then firing > > the machine up and plugged the monitor in AFTER the boot process (probably) > > started hoping to see some indication on the screen of the crash. Result: > > no display until the kernel crashes and the system reboots. > > > > Nick. > > Got contacted by someone off-list who told me they "fixed" this problem > on their machine by switching to a serial console, which is cool, but my > machine doesn't have a serial console. (set tty com0 resulted in a hang, > as it was probably waiting for the UART to say, "Sent that first character" > and it never does). > > Is it possible that bsd.rd *must* have some kind of output device? > efifb fails to configure without a monitor attached, so no console output? > > For giggles, I did a "gop" and a "video" at the boot> prompt, and both came > back with no response, just another boot> prompt. > just 'gop' amd 'video'? These should be "machine gop" and "machine video". > Nick. >
Re: clang 13 space issues with KARL
On Thu, Apr 28, 2022 at 07:57:20PM +0200, Peter J. Philipp wrote: > On Thu, Apr 28, 2022 at 11:47:14AM -0600, Theo de Raadt wrote: > > >On Thu, Apr 28, 2022 at 10:44:09AM -0600, Theo de Raadt wrote: > > >> If people built properly sized machines there would be no problem. > > > > > >That's a little condescending don't you think? > > > > Not at all. > > > > If you don't use a tool as it was intended, you bear the consequences. > > > > *WE* built the tool. *WE* decided how it works. We even documented > > how much resources it typically needs. When people use it > > incorrectly, it is their own damn fault. *THEY* can make adjustments. > > > > But they cannot complain, because they did not pay and even if they > > had there is no warrantee. > > > > There is nothing condescending about telling someone their complaints > > about how something works are falling on deaf ears. I don't give a > > flying damn if KARL is hurting people who don't provide their machines > > with reasonable defaults. It is their own damn fault, and they can > > make manual accomodations for their own (completely stupid, IMHO) > > decisions. > > > > In this modern world is has become *impossible* to complain about > > any technology which doesn't work like you want, companies who take > > money don't give a damn. Here's the shocker: I will not be held > > to a higher standard than that. So Peter, your attitude stinks > > and your suggestion that anything I've said is "rude" rather than "real", > > thgat suggestion of yours is an insult. > > OK, I get it you're having a bad day. I'm sorry if I was rude. > > BTW do you know any operating systems that aren't BSD, Linux that I can > continue on? Surely you'd be in the know for this. > > -peter > This is the second time in a week someone has posted on tech or misc asking why we don't run well on ancient or ridiculously low resource machines. Your question about why KARL doesn't work well on such machines is effectively the same as "why doesn't LLVM work well on my ridiculously small machine?" I'd suggest that question should go to the llvm developer mailing list. We don't control how much RAM LLVM requires. I can totally see where theo is coming from. -ml
Re: Unusable resolution on a widescreen monitor during install
On Wed, Apr 27, 2022 at 05:07:14PM -0400, Nick Holland wrote: > On 4/27/22 9:15 AM, David Demelier wrote: > > Hello, > > > > I have a lenovo thinkcentre machine connected to 24” LG screen (with > > 4k resolution), the installer boots fine using UEFI but it looks like > > efifb takes a strange “squared” resolution where bottom part of the > > console is below the screen so I’m unable to see what I type. I’ve > > taken a picture of what’s seen: > > > > http://markand.fr/static/openbsd-resolution.jpeg > > > > I have tried disabling inteldrm using UKC as I’ve seen on some > > websites with somewhat similar problem but with no effect. I’ve also > > noticed there is no wscons(cfg|ctl) utilities in the installer so I > > was unable to blindly type commands to alter the resolution either. > > Unfortunately, changing boot video mode using `machine video …` does > > not change kernel resolution either. > > > > My only solution for now would be to boot not using UEFI but that’s > > something I’d like to avoid if possible. > > > > Do you have any idea why an incorrect resolution is picked up by the > > kernel? I’m using install71.img on USB stick FYI. > Does: boot> machine gop (then machine gop followed by some mode number) work? -ml > The installer kernel is very limited in its abilities, and if I understand > UEFI (which I don't), the install kernel is more-or-less locked into using > what the firmware sets up. "man efifb" kinda hints that I might be right > on this. > > In short: probably not a lot you can do with the install kernel to fix > the problem. And hopefully, once installed, the "real" kernel will be fine > with your monitor. > > HOWEVER, 4k monitors and their support are interesting. I have an old HP > netbook with an AMD competitor to the Intel Atom chips which just took off > and ran with an HDMI 4k monitor, and a much more capable and newer Thinkpad > which didn't work properly at all with 4k (in both OpenBSD and Windows). > > You might want to start with a firmware upgrade for your machine in question, > see if that helps. If not, a few ideas: > > * Boot the installer, drop to shell, hit "clear" to put the cursor back at > the top of the screen and do your install, taking defaults as much as > possible to minimize dialog, and defaults for everything after the text rolls > off the bottom of the screen, and clean it up later. > > * Do a serial install (aren't I funny? As if there is a serial port on a > machine with an HDMI port! But maybe there is...Maybe I should go buy > a lottery ticket, too). > > * Try the install with a 1920x1080 or lesser resolution monitor. > > * Move the hard disk to another UEFI machine and do the install on it, then > move the disk back, hoping the other machine works better for the installer. > > Nick. >
Re: OpenBSD and multitasking
On Tue, Apr 26, 2022 at 02:13:16AM +0300, Mihai Popescu wrote: > Hello, > > I use OpenBSD amd64 snapshots on the following dmesg hardware. > The download rate on a browser was slow and I figured out with some > memory mapped partition that disk transfer rate was slow. > I can bear this since I'm not into large file transfer business. But > here is another interesting fact: each time my disk is used by some > file transfer, all the running applications, mostly GUI based are > stalling - that includes mostly chromium ( even if it is not chromium > that it does the disk data transfer). > > My questions are: is something incorrectly set up on my computer, > regarding the multitasking? > I understand disk operations are slow, but may I say that kernel is > dragged in that slow transfer too (no DMA, no cache, etc.)? > Does this happens to all users, but since there are more powerful > configuration involved the delay is not so noticeable? > > I know it is hard to project this, but can someone give me a hint > about a minimum hardware to allow using chromium with no delays, > please? See comments below. The hardware is ancient. I'd say try running chrome on windows on this hardware and you'll probably see it's also horrible. "minimum hardware to allow using chromium with no delays" is probably a machine with a fast nvme drive, 8+ cores, and 16+ gb ram. > I know, it should be advisable to get the maximum performance > hardware, but i'm not in that case. > > OpenBSD 7.1-current (GENERIC.MP) #483: Sat Apr 23 05:33:19 MDT 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 7711170560 (7353MB) > avail mem = 7460139008 (7114MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe86ed (64 entries) > bios0: vendor Hewlett-Packard version "K06 v02.77" date 03/22/2018 > bios0: Hewlett-Packard HP Compaq Pro 6305 SFF This is an almost 9 year old machine. Release date September 2013. Also, see below. > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT MSDM TCPA IVRS VFCT > SSDT SSDT CRAT > acpi0: wakeup devices SBAZ(S4) PS2K(S3) PS2M(S3) P0PC(S4) PE20(S4) > PE21(S4) PE22(S4) BNIC(S4) PE23(S4) BR12(S4) BR14(S4) OHC1(S3) > EHC1(S3) OHC2(S3) EHC2(S3) OHC3(S3) [...] > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 16 (boot processor) > cpu0: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.45 MHz, 15-10-01 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB > cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB > 64b/line 16-way L2 cache > cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative > cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, IBE > cpu1 at mainbus0: apid 17 (application processor) > cpu1: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.05 MHz, 15-10-01 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB > cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB > 64b/line 16-way L2 cache > cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative > cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu1: disabling user TSC (skew=129) > cpu1: smt 1, core 0, package 0 > cpu2 at mainbus0: apid 18 (application processor) > cpu2: AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.05 MHz, 15-10-01 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1,IBPB > cpu2: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB > 64b/line 16-way L2 cache > cpu2: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative > cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu2: disabling user TSC (skew=186) > cpu2: smt 0, core 1, package 0 > cpu3 at mainbus0: apid 19
Re: login.conf daemon datasize limit effects on VMs with 4GB+ RAM
On Fri, Feb 25, 2022 at 06:36:35PM -, Stuart Henderson wrote: > On 2022-02-25, Robert Nagy wrote: > > Maybe we need a default vmd class? What do you guys think? > > I definitely think it makes sense. Not sure whether it should just go in > etc.amd64 or the others too (vmd only exists on amd64 so far, but if it's > ever added e.g. to arm64 then adding it in the other files would avoid > having to remember to add it later..) > > Maybe the same 16G limit as bgpd by default.. > > I am in support of this change as well. Thanks everyone.
Re: login.conf daemon datasize limit effects on VMs with 4GB+ RAM
On Fri, Feb 25, 2022 at 01:46:00PM -0500, Ted Unangst wrote:
> On 2022-02-25, Robert Nagy wrote:
> > Maybe we need a default vmd class? What do you guys think?
>
> Regardless of what the limit is, this seems like a daemon where people
> will bump into the limit. Perhaps a reminder is in order too?
>
ok mlarkin on this one. thanks
>
> Index: vm.c
> ===
> RCS file: /cvs/src/usr.sbin/vmd/vm.c,v
> retrieving revision 1.67
> diff -u -p -r1.67 vm.c
> --- vm.c 30 Dec 2021 08:12:23 - 1.67
> +++ vm.c 25 Feb 2022 18:42:39 -
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -292,8 +293,12 @@ start_vm(struct vmd_vm *vm, int fd)
> ret = alloc_guest_mem(vcp);
>
> if (ret) {
> + struct rlimit lim;
> + const char *msg = "could not allocate guest memory - exiting";
> + if (getrlimit(RLIMIT_DATA, &lim) == 0)
> + msg = "could not allocate guest memory (data limit is
> %llu) - exiting";
> errno = ret;
> - fatal("could not allocate guest memory - exiting");
> + fatal(msg, lim.rlim_cur);
> }
>
> ret = vmm_create_vm(vcp);
>
Re: cd*.iso reboot loop (vultr, Skylake AVX MDS)
On Sat, Dec 04, 2021 at 06:18:55PM +, Claus Assmann wrote: > Just in case someone is wondering: vultr moved the VM to a different > server, the system is up and running again. > BTW: I guess I can ignore this: > fd0 at fdc0 drive 1: density unknown > > > OpenBSD 6.9 (GENERIC) #464: Mon Apr 19 10:28:56 MDT 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > real mem = 1056813056 (1007MB) > avail mem = 1009561600 (962MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5940 (9 entries) > bios0: vendor Vultr > bios0: Vultr VC2 > acpi0 at bios0: ACPI 1.0 > acpi0: sleep states S3 S4 S5 > acpi0: tables DSDT FACP APIC HPET WAET > acpi0: wakeup devices > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Virtual CPU 6db7dc0e7704, 2993.33 MHz, 06-5e-03 It was at this point I stopped caring about this configuration. > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,SSBD,ARAT,XSAVEOPT,MELTDOWN > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB > 64b/line 16-way L2 cache > cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 1000MHz > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins > acpihpet0 at acpi0: 1 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > "ACPI0006" at acpi0 not configured > acpipci0 at acpi0 PCI0 > acpicmos0 at acpi0 > "PNP0A06" at acpi0 not configured > "PNP0A06" at acpi0 not configured > "PNP0A06" at acpi0 not configured > "QEMU0002" at acpi0 not configured > "ACPI0010" at acpi0 not configured > acpicpu0 at acpi0: C1(@1 halt!) > cpu0: using Skylake AVX MDS workaround > pvbus0 at mainbus0: KVM > pvclock0 at pvbus0 > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 > pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 > pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 > wired to compatibility, channel 1 wired to compatibility > pciide0: channel 0 disabled (no drives) > atapiscsi0 at pciide0 channel 1 drive 0 > scsibus1 at atapiscsi0: 2 targets > cd0 at scsibus1 targ 0 lun 0: removable > cd0(pciide0:1:0): using PIO mode 4, DMA mode 2 > uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11 > piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int 9 > iic0 at piixpm0 > vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00 > wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) > wsdisplay0: screen 1-5 added (80x25, vt100 emulation) > virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00 > vio0 at virtio0: address 56:00:03:1a:c3:11 > virtio0: msix shared > virtio1 at pci0 dev 4 function 0 "Qumranet Virtio Storage" rev 0x00 > vioblk0 at virtio1 > scsibus2 at vioblk0: 1 targets > sd0 at scsibus2 targ 0 lun 0: > sd0: 25600MB, 512 bytes/sector, 52428800 sectors > virtio1: msix shared > virtio2 at pci0 dev 5 function 0 "Qumranet Virtio Memory Balloon" rev 0x00 > viomb0 at virtio2 > virtio2: apic 0 int 10 > virtio3 at pci0 dev 6 function 0 "Qumranet Virtio RNG" rev 0x00 > viornd0 at virtio3 > virtio3: apic 0 int 10 > isa0 at pcib0 > isadma0 at isa0 > fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 > pckbc0 at isa0 port 0x60/5 irq 1 irq 12 > pckbd0 at pckbc0 (kbd slot) > wskbd0 at pckbd0: console keyboard, using wsdisplay0 > pms0 at pckbc0 (aux slot) > wsmouse0 at pms0 mux 0 > pcppi0 at isa0 port 0x61 > spkr0 at pcppi0 > usb0 at uhci0: USB revision 1.0 > uhub0 at usb0 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 > addr 1 > uhidev0 at uhub0 port 1 configuration 1 interface 0 "QEMU QEMU USB Tablet" > rev 2.00/0.00 addr 2 > uhidev0: iclass 3/0 > ums0 at uhidev0: 3 buttons, Z dir > wsmouse1 at ums0 mux 0 > vscsi0 at root > scsibus3 at vscsi0: 256 targets > softraid0 at root > scsibus4 at softraid0: 256 targets > root on sd0a (6bd47bbc8137acde.a) swap on sd0b dump on sd0b > fd0 at fdc0 drive 1: density unknown > > -- > Address is valid for this mailing list only, please do not reply > to it direcly, but to the list. >
Re: nested virtualization with vmm on hyper-v
On Sat, Oct 30, 2021 at 02:25:44PM +0200, Peter J. Philipp wrote: > Hi, > > I'm a little confused by this. I have an old Xeon e3-1275v3 computer that > runs windows server 2019 essentials natively. It shares half it's RAM and > 2 cores with OpenBSD as a hyper-v guest. > > So after a long time of not looking into this I asked someone how they did > virtualization nesting and I got this link: > > https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/nested-virtualization > > So this is good, I thought, I followed the instructions, turned off the > hyper-v, > did the powershell command, restarted hyper-v guest and got some indication by > OpenBSD that vmm is enabled: > > arda$ dmesg | grep vmm > cpu0: using VERW MDS workaround (except on vmm entry) > vmm0 at mainbus0: VMX/EPT > > Only when I start the vmm guest with vmctl and vmctl console, it boots me out > of console mode back into arda and the vmm guest is stopped. > > So then I rebooted the entire machine to make sure that all BIOS settings are > correct. And they are. There is no CPU option that I can set here that would > disallow this nesting. > > Here is the CPU options of arda (short of a dmesg): > > cpu0: using VERW MDS workaround (except on vmm entry) > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3498.01 MHz, 06-3c-03 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > cpu0: apic clock running at 200MHz > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3497.99 MHz, 06-3c-03 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > cpu0: using VERW MDS workaround (except on vmm entry) > > Does anyone know how I can get vmm with nesting to function? Is it a OpenBSD > problem or should I seek elsewhere? > > Best Regards, > -peter > I told Microsoft years ago that their implementation of legacy event injection was broken. This is how we inject interrupts in vmm(4). They either didn't understand, or didn't care. Since hyper-v doesn't deliver our injected event, no interrupts are delivered to the VM and as soon as interrupts are enabled in autoconf, you hang. Note: KVM and VMware do it correctly. -ml
Re: boot error: 'entry point at 0xffffffff81001000'
On Thu, Oct 28, 2021 at 09:26:33PM -0500, J Dragu wrote: > Trying with a snapshot returned the same error. > > Here's what it tells me when I check machine memory: > > > Low ram: 634KB High ram: 3065328KB > > Total free memory: 8179378KB > > On Thu, Oct 28, 2021 at 20:04 Mike Larkin wrote: > > > On Thu, Oct 28, 2021 at 06:57:46PM -0500, J Dragu wrote: > > > Hello, > > > > > > I know there was a previous thread here about a perhaps similar issue > > > with 6.8 (?), but since from what I can tell it was fixed with 6.9 > > > I figured I'd ask about my problem. If there's something obvious I'm > > > missing I do apologize! > > > > > > I'm trying to install OpenBSD 7.0 on a Thinkpad T410 from a USB stick. > > > Whenever I try to boot in to the installer I get the following messages: > > > > > > > cannot open hd0a:/etc/random.seed: No such file or directory > > > > booting hd0a:/7.0/amd64/bsd.rd: 38030471+1598464+3907256+0+704512 > > > [109+288+28]=0x995530 > > > > entry point at 0x81001000 > > > > > > ... at which point it becomes unresponsive. I've checked to make sure > > > the BIOS are up to date (1.45, going by Lenovo's website), and also > > > fiddled with some settings like disabling hyperthreading, to no avail. > > > I'm writing this email from my X61s (which is running 7.0 just fine) > > > and I tried putting this SSD in the T410 and got the exact same results, > > > so I suppose the issue isn't with the installer itself (?). Has anyone > > > else encountered this? > > > > > > Thank you for reading. > > > J > > > > > > > 2 things to try: > > > > 1. get a latest snap if you didn't already. > > > > 2. boot> machine memory > > ... and show the result here. > > You'll probably need to bisect builds and find where it started failing. -ml
Re: boot error: 'entry point at 0xffffffff81001000'
On Thu, Oct 28, 2021 at 06:57:46PM -0500, J Dragu wrote: > Hello, > > I know there was a previous thread here about a perhaps similar issue > with 6.8 (?), but since from what I can tell it was fixed with 6.9 > I figured I'd ask about my problem. If there's something obvious I'm > missing I do apologize! > > I'm trying to install OpenBSD 7.0 on a Thinkpad T410 from a USB stick. > Whenever I try to boot in to the installer I get the following messages: > > > cannot open hd0a:/etc/random.seed: No such file or directory > > booting hd0a:/7.0/amd64/bsd.rd: 38030471+1598464+3907256+0+704512 > [109+288+28]=0x995530 > > entry point at 0x81001000 > > ... at which point it becomes unresponsive. I've checked to make sure > the BIOS are up to date (1.45, going by Lenovo's website), and also > fiddled with some settings like disabling hyperthreading, to no avail. > I'm writing this email from my X61s (which is running 7.0 just fine) > and I tried putting this SSD in the T410 and got the exact same results, > so I suppose the issue isn't with the installer itself (?). Has anyone > else encountered this? > > Thank you for reading. > J > 2 things to try: 1. get a latest snap if you didn't already. 2. boot> machine memory ... and show the result here.
Re: 6.9/amd64 runaway acpi process on Thinkpad T580
On Wed, Sep 29, 2021 at 08:44:54PM -0400, David Anthony wrote: > After enabling "BIOS Thunderbolt Assist", I experience consistent machine > slowdown on my T480. Previously, I experienced slowdown after power cycling > my machine occasionally. Currently, with this BIOS setting enabled, I > experience slowdown consistently. > > I am sorry but I don't know enough technically as to discern why. I am > simply reporting my user experience. I will re-disable the Thunderbolt > assist for now. > If someone would build an ACPI_DEBUG kernel and show us what GPE is stuck then we can make forward progress (we need an acpidump of that machine also). Otherwise, its like throwing darts in the dark. -ml > On 9/29/21 2:58 PM, David Anthony wrote: > > Another T480 user who has noticed the same problem. Per advice given, > > I've just enabled "BIOS Thunderbolt Assist". I will report back if I > > notice the problem persists. > > > > On 9/19/21 4:50 AM, Daniel Wilkins wrote: > > > I've ran into this on my T480, it seems most consistently triggered > > > by power > > > cycles caused by running out of battery. The bug's existed for quite > > > a few > > > years (I think I first noticed it in 2019.) If I recall correctly I've > > > posted it to the list a couple of times but I don't think any > > > concrete answers > > > ever emerged; your report is more thorough than mine were though. > > > I do remember that it never happened on my T430, but that's quite the > > > hardware gap. > > > > > >
Re: 6.9/amd64 runaway acpi process on Thinkpad T580
On Tue, Sep 28, 2021 at 10:08:47PM -0600, Theo de Raadt wrote: > the term "runaway ACPI" is not the best. What is probably happening > is a stuck interrupt. > > We continue to fight these. Some of them are BIOS bugs, some are > undocumented behaviours, sometimes AML parse errors in setting things > up, and potentially a few are due to incorrect resume sequencing. > The suspend/resume specification is weak, and getting even weaker as > time goes by and newer machines come out which are poorly tested by > even the mainstream OS vendors. > > Jonathan Thornburg wrote: > > > After more experimentation, I find that the runaway ACPI process occurs > > every time I suspend/resume (Fn-backspace). (The system resumes fine > > apart from the runaway ACPI process.) > > > > Is there any to kill or reset the kernel ACPI process short of rebooting? > > /ps/ doen't see it, and /pkill/ (even /pkill -9/) has no effect. > > No you cannot kill kernel threads... > > > I will try compiling a custom kernel with ACPITHINKPAD_DEBUG defined > > in /usr/src/sys/dev/acpi/acpithinkpad.c and see if that prints anything > > interesting. Are there any other particularly useful debugging things > > I should explore to help track down the problem? > > There are a few people who have experience with this. Maybe one of > them will mail you privately. > If you build an ACPI_DEBUG kernel and zzz/un-zzz from the text console (not X), you might see what GPE is stuck. it will probably be spewing tons of debug output but maybe you can see which GPE it is. -ml
Re: Does anyone have experience with OpenBSD on SiFive Unmatched?
On Mon, Aug 30, 2021 at 03:25:42AM +, Joseph wrote: > > > In this moment on -current, how well does the SiFive Unmatched RISCV64 > > > board work? > > > > > > E.g. multiple core support, PCIe. > > > > Works fine. > > > > > E.g. multiple core support, PCIe. > > > > Works, and works. > > > > The "serial cable" can in fact be just a USB-A to Micro-USB cable > > with the A end plugged into a USB port on a laptop or PC. > > > > The micro-SD card must be present to boot OpenBSD (so maybe make > > a backup copy of it?). IDK exactly what files it needs. Maybe > > somebody will figure out how the boot stuff can be flashed into > > flash mem on the motherboard without bricking their board. > > > > And bear in mind the Unmatched is meant to be a developr machine not > > > powerhouse; it lopes along nicely at 1.2GHz with 4 cores. If the RISC-V > > people are right, there will be faster, bigger machines "real soon > > now", in case you need breath-holding practice. > > Hi Mike and Ian, > > Wow. Thank you for letting me know. > > > If the ISA even has it, two questions on the topic of virtualization: > > Is the riscv64 architecture designed in such a way that riscv64 > OpenBSD should work out of the box as guest under a virtualizer, > if-when one exists? > I know of no hardware capable of this. > And off-topic here, does any VM host exist for riscv64? Without or > with passthrough of PCI/cad/etc. > For OpenBSD, no. > I see this KVM fork but not sure exactly in what environment/ > distribution/setup it works e.g. does it support Unmatched, not even > clear if virtualization is really in the riscv64 ISA spec: > > https://github.com/kvm-riscv/howto/wiki/KVM-RISCV64-on-QEMU > https://lwn.net/Articles/856685/ > https://lists.riscv.org/g/tech-privileged/topic/risc_v_h_extension_freeze/80346318?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,80346318 > https://lwn.net/ml/linux-kernel/CAAhSdy0F7gisk=fzxn7jmqflvb3456wunwvxhkrnvnuwtrh...@mail.gmail.com/ > > Perhaps this q is too early for riscv64 and to be revisited later. > Yes > Best regards, > Joseph > > (Related: https://news.ycombinator.com/item?id=27592187 > 38bit vmem upped to 48 https://www.sifive.com/cores/performance-p550 > https://www.anandtech.com/show/16780/intel-to-create-riscv-development-platform-with-sifive-p550-cores-on-7nm-in-2022)
Re: Does anyone have experience with OpenBSD on SiFive Unmatched?
On Sun, Aug 29, 2021 at 05:28:45AM +, Joseph wrote: > (In absence of an openbsd-riscv emailing list sending this to misc:) > > Hi all, > > In this moment on -current, how well does the SiFive Unmatched RISCV64 > board work? > Works fine. > E.g. multiple core support, PCIe. > Works, and works. > The current installation instructions are the oneliner at > http://www.openbsd.org/riscv64.html . > > Should one boot with serial cable or would PCIe graphics activate > early. With the Xenocara support, should X supposedly work out of the > box e.g. AMDGPU or commodity PCIe or USB graphics adapter? > People have reported amdgpu on unmatched works. Boot with serial cable and use the microsd card that came with the machine. Install from USB stick to nvme. The cad(4) onboard adapter should work fine as well. -ml > Best regards, > Joseph > > Commits: > > Arch 23 April > https://marc.info/?l=openbsd-cvs&m=161914575319702&w=2 > > Xenocara 15 June > https://undeadly.org/cgi?action=article;sid=20210619161607 > > SMP 29 June > https://marc.info/?l=openbsd-cvs&m=162500209229957&w=2 >
Re: Crash when unplugging a UPS USB connection
On Sun, Jul 11, 2021 at 04:11:39PM -0400, Mike wrote: > I run NUT on OpenBSD to monitor a Cyperpower UPS. The UPS plugs into > the OpenBSD box via a USB connection. > > OpenBSD 6.8, I had no problems, everything ran fine. When the power > went out, NUT saw that and reacted according to configuration. > > After I upgraded to OpenBSD 6.9 (a fresh install, not an in-place > upgrade), when the power dropped, I'd be greeted with a blue crash screen. > > It seems that when the power drops, the UPS temporarily drops the USB > connection, seemingly the equivalent of unplugging the USB connector. > > I am able to reproduce that 100% by booting up OpenBSD 6.9 with the UPS > communications cable plugged into the USB port. When I unplugged that > USB connector, the crash occurs. > > This first occurred on my production box which is a Supermicro > motherboard. I can provide that dmesg if needed. > > > Both OpenBSD 6.8 and current below are fresh installs on a test Lenovo > laptop. > > On OpenBSD 6.8, when I plug in the UPS and unplug it, here is what I see > on the console (dmesg is included): > This crash happens to me as well when I unplug my upd(4). I'll try to find what diff caused this. -ml > vvv= OpenBSD 6.8 == > > OpenBSD 6.8 (GENERIC.MP) #3: Sat Jun 5 10:34:16 MDT 2021 > > t...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4129800192 (3938MB) > avail mem = 3989590016 (3804MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries) > bios0: vendor LENOVO version "6IET75WW (1.35 )" date 02/01/2011 > bios0: LENOVO 2522DU5 > acpi0 at bios0: ACPI 4.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT > TCPA SSDT SSDT SSDT > acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) > EXP3(S4) EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpiec0 at acpi0 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 2926.44 MHz, 06-25-05 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 133MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 2926.01 MHz, 06-25-05 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 1, core 0, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 2926.02 MHz, 06-25-05 > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 5 (application processor) > cpu3: Intel(R) Core(TM) i5 CPU M 560 @ 2.67GHz, 2926.01 MHz, 06-25-05 > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN > cpu3: 256KB 64b/line 8-way L2 cache > cpu3: smt 1, core 2, package 0 > ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped > acpimcfg0 at acpi0 > acpimcfg0: addr 0xe000, bus 0-255 > acpihpet0 at acpi0: 14318179 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus 1 (PEG_) > acpiprt2 at acpi0: bus 2 (EXP1) > acpiprt3 at acpi0: bus 3 (EXP2) > acpiprt4 at acpi0: bus -1 (EXP3) > acpiprt5 at acpi0: bus 5 (EXP4) > acpiprt6 at acpi0: bus 13 (EXP5) > acpibtn0 at acpi0: LID_ > acpibtn1 at acpi0: SLPB > acpipci0 at acpi0 UNCR > acpipci1 at acpi0 PCI0: 0x 0x0011 0x0001 > acpicmos0 at acpi0 > acpibat0 at acpi0: BAT0 model "42T4911" serial 21260 type LION oem "LGC" > acpiac0 at acpi0: AC unit online > acpithinkpad0 at acpi0: version 1.0 > "*pnp0c14" at a
Re: unhibernate failed: original kernel changed
On Fri, Jun 11, 2021 at 05:11:50PM -0400, Allan Streib wrote: > Mike Larkin writes: > > > This is happening because you changed the kernel on your machine after > > you booted, then did a hibernate. The new kernel no longer matches the > > kernel loaded in memory. The kernels have to be identical. We do a few > > checks to ensure this is the case, and that's the check you're seeing. > > So then is it correct to say that if I run syspatch(8), and get the > advisory message to reboot, I should be sure to do that before > hibernating? > > And if I don't, my recovery would be a cold boot and abandoning my > hibernated state? > > Allan > yes
Re: unhibernate failed: original kernel changed
On Fri, Jun 11, 2021 at 02:46:42PM +0300, Artem Mazurov wrote: > Hi. > > The lights went out when my system was in the process of hibernation > and now I can't resume from hibernation. the error in dmesg is in > the subject. > > How can this be fixed? > This has nothing to do with "lights out during hibernate". This is happening because you changed the kernel on your machine after you booted, then did a hibernate. The new kernel no longer matches the kernel loaded in memory. The kernels have to be identical. We do a few checks to ensure this is the case, and that's the check you're seeing. If you're seeing that message all the time, just do another ZZZ and un-ZZZ to clear any old hibernate signatures from swap. Obviously this needs to be done without changing the kernel after boot. -ml
Re: An OpenBSD Consumer Gateway Launch
On Fri, Jun 11, 2021 at 04:15:50PM +, fern.tje...@aiyja.com wrote: > Hi, > > I am Nan Mel, the marketing director of Aiyja and Etheria group of companies, > nice to meet you all. All of us in the company would like to say a big thank > you! > > We have launched Ayos HCS, a consumer gateway & Server, based on OpenBSD!, > and we could not have done it without you. So a huge thank you to you, the > OpenBSD developers, and those that support this group, you are all amazing, > keeping Unix alive in such a form, so we could build on top of it. > > It is the first of its kind of this type of products we believe. So we use a > lot of native capabilities such as the firewall that feels nostalgic (many of > us are ex-sun). We have added lots of unique features like Home Anywhere, > allowing a consumer to VPN back into their home, without open ports or port > forwards. Secure IoT, finally in a consumer product, securing not only in > VTEP & IP layers but other areas. And Home cloud using our own flavours with > some NextCloud Hub etc …. It has over 670 features now and we are still, and > will forever, build more. > > We even have a fully fledged middleware, with an API bridge, integrated ….. > if only the consumers knew what that was, and how lucky they are. But again > we think this is a first for a consumer gateway. Plus a lot of privacy > features like a web proxy, malware and ransomware filters, the things the > consumer could not really do for themselves, but are easy for us, and this > group. > > We know how under appreciated, and under paid, companies tend to be towards > your group. We would like to officially state if we do well we will be > donating regularly into OpenBSD. We would like to support you as much as we > can. We will also be out-sourcing some coding to those that wish it towards > the end fo the year. As we need specific improvements like VMD enhancements > to over 2 threads. > Diffs improving vmd are always welcome. If you are indeed going to be "outsourcing" this effort, I'd recommend reaching out on tech@ before starting. > We know most of you could probably build much of this yourselves, so we are > not expecting sales from this group, we are just saying thank you and > announcing what seems to us a unique OpenBSD consumer product, that you might > enjoy hearing about. We originally made it for ourselves and friends as it > was a huge gap in our racks, but then we thought, some consumers might > understand enough to buy it. > > Note; we are a small European company (ies), so only sell in the EU, for now. > Sorry for those outside but maybe you have a friend. > > Here is the website link if you wish it. > https://www.ayoshcs.eu/index.html > > Have a wonderful summer! Xxxx > Cheers, > > Nan Mel > Marketing Director > Etheria EU > nan@etheria.eu (mailto:nan@etheria.eu) > etheriaconsulting.com (http://etheriaconsulting.com) > > Disclaimer: This e-mail communication and any attachments to it, are > confidential and privileged to Etheria Services and Etheria Group, within the > European Union, and this includes its sister companies, and to the correct > recipients of this email, which are directly applicable to GDPR regulations, > and only confidential use of that designated recipient(s) named above in this > email may receive the contents herein. If you are not the intended recipient > of this message, you are hereby notified that any review, dissemination, > distribution or copying of this message is strictly prohibited and may be > unlawful and can result in heavy fines relative to your company's income. > Please notify the sender immediately and destroy all copies of this message > along with all attachments. We give no rights to any reader of this email, to > sell or forward our employee or company details on, to any third party, > without specific written request
Re: Resuming from suspend takes 12-14 seconds
On Fri, May 28, 2021 at 12:59:09PM +0530, Subhaditya Nath wrote: > On 5/28/21, Theo de Raadt wrote: > > amdgpu startup is slow. > > > > not our fault. > > > > Oh. > You mean amdgpu(4), right? > > But resuming from suspend is instantaneous in Linux... > Why is it so slow on OpenBSD? > different code. > > I am sorry, but I am new to OpenBSD, and I am genuinely curious about > what might cause amdgpu startup to be so slow on OpenBSD compared to > Linux. > > > - Subhaditya >
Re: VMM 6.9amd64 host video acceleration
On Wed, May 12, 2021 at 06:06:14PM +, Martin wrote: > Hi Dave, > > Can you recommend any way to see online videos without shuttering? Modern > CPUs can't smoothly play it in software emulation, unfortunately. > pkg_add youtube-dl pkg_add firefox (or chrome, etc) What's the problem here? Are you trying to watch 8k 240Hz videos or something? > Martin > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, May 12, 2021 1:43 PM, Dave Voutila wrote: > > > Martin writes: > > > > > Hi list, > > > Just wonder how to enable video acceleration on VMM guest's side (Debian) > > > if it was possible. Maybe PCIe passthru should be present for that > > > purpose? > > > > There is nothing to accelerate: vmd(8) doesn't emulate a display or > > video device. vmm(4) doesn't support pass-through to host hardware > > either. > > > > -dv > >
Re: I can’t get veb/vport to work with vmd.
On Wed, May 05, 2021 at 09:04:04PM -0500, Luke Small wrote: > There seems to be ZERO examples of using veb/vport vs bridge/vether. I am > running 6.9 now and I substituted the bridge0 usage in vm.conf and I copied > the hostname.vether0 into hostname.vport0 and hostname.bridge0 uses vether0 > so I used vport0 in hostname.veb0 . I used ifconfig … down for bridge0 and > vether0 and ifconfig … up for vport0 and veb0 and ran “sh /etc/netstart > veb0 then ran the vm of choice and it gets no internet. I reverted > everything back and I get internet. > > What am I missing? > -- > -Luke a tcpdump and what's in your pf.conf
Re: accessing user memory from kernel
On Mon, Apr 19, 2021 at 11:27:29PM +0200, Alessandro Pistocchi wrote: > Hi all, > > I am playing around with openbsd kernel source code. > Is there any clean way of accessing a process' memory from inside the > kernel? > > Thanks, > Alessandro man copyin
Re: Suspend/resume does not work on Lenovo X1 Carbon 3rd gen laptop
On Sun, Apr 04, 2021 at 09:15:14AM +0100, Mark Hesselink wrote: > Hi Theo, > > Thanks for reaching out and explaining the issue in more detail. It prompted > me to check the disklabel for the drive. If I recall correctly, the disk was > formatted using the autoformatting option supplied by the OpenBSD 6.8 > installer and has the following disklabel: > > # /dev/rsd0c: > type: SCSI > disk: SCSI disk > label: SAMSUNG MZHPV512 > duid: e4819536ae37a0af > flags: > bytes/sector: 512 > sectors/track: 63 > tracks/cylinder: 255 > sectors/cylinder: 16065 > cylinders: 62260 > total sectors: 1000215216 # total bytes: 476.9G > boundstart: 64 > boundend: 1000206900 > drivedata: 0 > > 16 partitions: > # size offset fstype [fsize bsize cpg] > a: 1.0G 64 4.2BSD 2048 16384 12960 # / > b: 8.1G 2097216 swap # none > c: 476.9G 0 unused > d: 4.0G 19164928 4.2BSD 2048 16384 12960 # /tmp > e: 19.8G 27553536 4.2BSD 2048 16384 12956 # /var > f: 6.0G 69028992 4.2BSD 2048 16384 12960 # /usr > g: 1.0G 81611904 4.2BSD 2048 16384 12960 # > /usr/X11R6 > h: 20.0G 83709056 4.2BSD 2048 16384 12960 # > /usr/local > i: 2.0G 125652096 4.2BSD 2048 16384 12960 # /usr/src > j: 6.0G 129846400 4.2BSD 2048 16384 12960 # /usr/obj > k: 300.0G 142429312 4.2BSD 4096 32768 26062 # /home > > By the looks of it, the swap partition should be sufficiently large to > support hibernate. > > I went through the following steps to highlight the issue: > > 1. Reboot machine using "doas reboot" to start the test with a clean slate. > 2. Switch to console; The machine starts xenodm at boot as the machine is > meant to be used as a workstation by my children. > 3. Login, execute "ZZZ" and wait for the machine to finish hibernating. > 4. Resume machine. > 5. OpenBSD boot(8) bootstrap program shows the standard boot prompt, i.e. it > does not detect that the machine is being resumed after it has been > hibernated. Does it say "unhibernate detected; switching to bsd.booted" at the boot> prompt here? -ml > 6. Machine boots as if the hibernate request was never executed. During boot > OpenBSD detects a number of uncleanly unmounted filesystems as well. > > The above test sequence was executed on a fresh OpenBSD 6.9 snapshot which > was successfully installed using "sysupgrade -s": > > OpenBSD 6.9-beta (GENERIC.MP) #446: Sat Apr 3 01:48:42 MDT 2021 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8261603328 (7878MB) > avail mem = 7995830272 (7625MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries) > bios0: vendor LENOVO version "N14ET54W (1.32 )" date 03/19/2020 > bios0: LENOVO 20BTS0MX00 > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT > SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI > acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpiec0 at acpi0 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.31 MHz, 06-3d-04 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.16 MHz, 06-3d-04 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > ioapic0 at
Re: vmm/vmd disk issue
On Tue, Mar 09, 2021 at 11:20:30PM +0100, Jan Johansson wrote: > Mike Larkin wrote: > > On Tue, Mar 09, 2021 at 09:38:57AM -0500, Ian Darwin wrote: > > > On Tue, Mar 09, 2021 at 09:52:03AM +0100, Jan Johansson wrote: > > > > If I try to cp or dd the disk image on the host it fails > > > > > > > > dd if=disk.raw.old of=disk.raw.bak bs=1m > > > > dd: disk.raw.old: Input/output error > > > > 8858+0 records in > > > > 8858+0 records out > > > > 9288286208 bytes transferred in 102.048 secs (91018010 bytes/sec) > > > > > > > > The host show no other signs of failing hardware. > > > > > > > > Is this a software or a hardware error? > > > > > > Given that it gives an error outside the VM, it's likely hardware. > > > > > > > Agreed. Sorta hard to fault vmd(8) if it's not even running. > > Since these are sparse files, could the vioblk(4) somehow write > incorrect data that later will make it unreadable such as a > pointer pointing into nothingness? > no > The messages > > vmd[39543]: vioblk write error: Input/output error > vmd[39543]: wr vioblk: disk write error > > was produced and 01:30 when all the 4 guests and the host all run > the daily script (which makes backup and other maintenance tasks) > if that could have any impact. > > Should there not be anything on the host logging errors to > dmesg/syslog such as sd(4) or ahci(4)? > > (If it is not obvious my understanding of how the virtio/vioblk > stuff hooks in to the disk stack is very limited) > > This drive was installed in august 2020 and if I recall correctly > it was because of this issue. So I am thinkig cable or > motherboard. > > If I decide to replace would it make sense to make this a > softraid mirror (RAID1) to avoid or get better indication of this > kind of problems in the future or would only add more parts that > can break? > > I'am currently trying to provoke the drive from the host with > > dd if=/dev/random of=test.raw bs=1m count=17000 > > then cp/dd and cmp to see if I can make it break for real. >
Re: vmm/vmd disk issue
On Tue, Mar 09, 2021 at 09:38:57AM -0500, Ian Darwin wrote: > On Tue, Mar 09, 2021 at 09:52:03AM +0100, Jan Johansson wrote: > > If I try to cp or dd the disk image on the host it fails > > > > dd if=disk.raw.old of=disk.raw.bak bs=1m > > dd: disk.raw.old: Input/output error > > 8858+0 records in > > 8858+0 records out > > 9288286208 bytes transferred in 102.048 secs (91018010 bytes/sec) > > > > The host show no other signs of failing hardware. > > > > Is this a software or a hardware error? > > Given that it gives an error outside the VM, it's likely hardware. > Agreed. Sorta hard to fault vmd(8) if it's not even running. > > Is there some way to recover the guest disk image without a > > complete reinstall? > > Depending on where the error is, you might get away with > dd'ing with conv=noerror,sync, changing vm.conf to point > to the new copy, and run fsck in the vm. > > And buy a new hard disk or SDD. Probably cheaper than your time > to further diagnose it? >
Re: -current amd64 packages not updated? Impatient or broken?
On Thu, Jan 07, 2021 at 05:44:05PM -0700, Theo de Raadt wrote: > Chris Cappuccio wrote: > > > Mihai Popescu [mih...@gmail.com] wrote: > > > I was in the same situation, impatient to have a 2021 snapshot. > > > > > > Warning: I am not sure you will not finish with a Frankenstein system. I > > > am > > > not so good with compiler-linker stuff. > > > > For those trying to use the latest snap and the latest ports, try link > > libc++.so.4.0 to libc++.so.5.0 and libc++abi.so.2.1 to libc++abi.so.3.0 > > for now. Frankenstein, indeed. You'll feel dirty just doing it. > > DO NOT DO THAT. > > We do not want reports from people about weird troubles, after they do > such things. > ... and this is the sort of thing that may work now and then bite you weeks later. -ml
Re: 9Front on VMM on Ryzen Hardware
On Tue, Dec 15, 2020 at 12:10:42PM +, e...@disroot.org wrote: > Hello, I hope that this is the right mailing list to send this query to. > > First some background. It is possible to run 9front on OpenBSD using > vmm, this is well documented and I have gotten it working before on a > ThinkPad X220. > Where I run into trouble is trying to install it on a T14 AMD, which > uses an AMD processor. Essentially when you begin to run the live cd, > the 9front kernel loads, and then immediately vmd restarts the virtual > machine, presumably because it crashed somewhere in the boot process. > > Now to the question, how would I go about debugging this? I know that > this install works on Intel, this is on OpenBSD -current. > > The 9front IRC told me that it was a vmm issue, as there are different > implementations on AMD and Intel, is this true? > If so, what debugging should I run to help the OpenBSD developers fix > this issue? > > If it's a 9front issue, is there any way for me to be able to take some > kind of memory dump so that the 9front developers can handle this? > > Hopefully this wasn't too off topic, I have read the relevant manual > pages for vmm, but I couldn't work out what debugger to use, I'm not > here to get others to debug it for me, only to work out where to start. > > Thank you > If you know how, build a kernel with VMM_DEBUG enabled and send me the output from dmesg (it will be a lot) when the VM crashes. VMM_DEBUG is settable at the top of vmm.c, fwiw. -ml
Re: 6.8 release crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)
On Mon, Oct 26, 2020 at 07:48:32PM -0700, Alfred Morgan wrote: > I just wanted to report 6.8 release is having the same issue as > https://marc.info/?l=openbsd-misc&m=160224393101534&w=2 > except I have a CHUWI HeroBox Windows 10 Mini PC,Intel Gemini-Lake N4100 > Quad-Core Processor,8GB DDR4 256GB SSD,Expandable 2TB 2.5 Inch HDD,1TB SSD > with 2.4GHz/5GHz Dual WiFi 1000Mbps/BT4.2 > https://www.amazon.com/gp/product/B082VZP76P > > On a 6.7 release I did syspatch and then a sysupgrade and got the entry > point at: 0x1001000 error trying to boot after the upgrade was successful. > > -alfred A mach mem output from this machine might reveal something useful. boot> mach mem ... then send the output
Re: crosscompiling binutils
On Thu, Oct 22, 2020 at 06:34:27PM +0200, Peter J. Philipp wrote: > On Thu, Oct 22, 2020 at 08:52:48AM -0700, Mike Larkin wrote: > > On Thu, Oct 22, 2020 at 04:26:37PM +0200, Peter J. Philipp wrote: > > > Hi, > > > > > > I was wondering if binutils-2.17 will be that version for the next > > > foreseeable > > > future? Reason being is that there is backports to RISCV's binutils but > > > they > > > don't go that low to 2.17. Since I'm lazy, I don't really want to port > > > binutils to 2.17 for any architecture if it's not already done so. > > > Unfortunately I only invested a handful of days looking into the problem > > > and > > > just as many procrastinating around this. > > > > > > I lost contact to the riscv group, but if I rejoin them I'd like to give > > > them > > > something and not just look happy. :-) > > > > > > Peace. > > > -peter > > > > Any idea why you feel this is needed? After all, the tree in that repo > > already > > builds cleanly without needing to do this. > > > > Ps that workspace is still open, just a bit idle the last few months. > > > > -ml > > Hi Mike, > > How do you build the userland tree? Do you hash out the binutils part? I > know there is the binutils that I think Mars put together, but it's not 2.17, > (working off memory here). > > I'll have to look for my credentials for the riscv groups chat. I must have > lost the cookie and url completion from my browser. When I find that I'll be > back. > > Best Regards, > -peter I believe they were using the llvm ld and such. I'll ask. -ml
Re: crosscompiling binutils
On Thu, Oct 22, 2020 at 04:26:37PM +0200, Peter J. Philipp wrote: > Hi, > > I was wondering if binutils-2.17 will be that version for the next foreseeable > future? Reason being is that there is backports to RISCV's binutils but they > don't go that low to 2.17. Since I'm lazy, I don't really want to port > binutils to 2.17 for any architecture if it's not already done so. > Unfortunately I only invested a handful of days looking into the problem and > just as many procrastinating around this. > > I lost contact to the riscv group, but if I rejoin them I'd like to give them > something and not just look happy. :-) > > Peace. > -peter Any idea why you feel this is needed? After all, the tree in that repo already builds cleanly without needing to do this. Ps that workspace is still open, just a bit idle the last few months. -ml
Re: Switching layout in vmm linux guest on OpenBSD host with english layout only
On Tue, Oct 06, 2020 at 02:28:54PM +, Martin wrote: > Hi, > > Linux Guest has virtual dummy video card to emulate video hardware. Linux > Guest has TightVNC server running also. It automatically starts on boot. > Guest has two layouts. > > The _same_ Guest *.qcow2 image is running on both Linux host and OpenBSD vmm > host. > > 1. When I connected from Linux host by TightVNC with EN layout only to Guest, > I can switch layout and I see symbols when input. > 2. When I connected from OpenBSD host by ssvnc with only EN layout present, I > can switch layout in Guest but no symbols input. Any pressed key shows > nothing, like keyboard is absent at all. > > Any fresh idea can help. > > Martin > Whatever your issue is, it's not with vmm(4)/vmd(8) as we don't emulate a keyboard at all. So it would sorta be hard to mess up the layout on a device we don't even say we have. Go talk to the TightVNC or ssvnc people, the issue is in one of those two products. -ml > ‐‐‐ Original Message ‐‐‐ > On Friday, October 2, 2020 7:34 AM, Stuart Henderson > wrote: > > > On 2020-09-30, Martin martin...@protonmail.com wrote: > > > > > Graphical mode of vmm > > > > vmm has no graphical mode .. > > > > > and qemu > > > > and has no interaction with qemu. > > > > If you're using qemu on OpenBSD then it's emulating a cpu in software, > > not managing a VM on your real cpu. > > > > > Layout switching works fine in qemu on Debian host even the host has > > > single english layout. > > > But layout switching doesn't work in vmm and can't be changed in any way. > > > OpenBSD host uses single english layout as Debian host. > > > Looking any solution on how to fix it. Please suggest. > > > > Which vnc client are you using? AFAIK you want one which supports the > > extension to use raw keycodes rather than keysyms for things to work > > properly, I believe tigervnc's version of vncviewer does this. > >
Re: VMM vulns?
On Wed, Sep 02, 2020 at 09:36:14PM -0400, Bryan Steele wrote: > On Wed, Sep 02, 2020 at 02:03:35AM -0700, Mike Larkin wrote: > > On Wed, Sep 02, 2020 at 03:35:54AM +0200, f...@disciples.com wrote: > > > https://twitter.com/m00nbsd/status/1291257985734410244 > > > > > > I don't want to bump that old thread or start any arguments about this. > > > I'm just curious if this tweet is accurate or have these issues been > > > addressed? Were any of Maxime's suggestions implemented? > > > > > > > I am not sure if anyone picked up the remaining issues after I left active > > vmm development. At that time, I sent out my WIP diff for the TLB flush > > issue > > Maxime reported; it was not 100% complete. I am not sure if anyone is > > working > > on that or not, or any other issues he reported. > > > > -ml > > As far as I'm aware all the pvclock(4) issues were addressed by pd@ and > mortimer@. > > https://marc.info/?l=openbsd-cvs&m=158180761313544&w=2 > https://marc.info/?l=openbsd-cvs&m=158269876318391&w=2 > > The "assorted bugs and vulns" like the RDMSR passthrough and the XSETBV > CPL check issues were handled by pd@, me and kettenis@ and they have all > been committed. > > https://marc.info/?l=openbsd-cvs&m=158196338821895&w=2 > > The direct map issue on Intel CPUs hinted at by Maxime was also fixed > by kettenis@, deraadt@ and millert@. > > https://marc.info/?l=openbsd-cvs&m=158269724517998&w=2 > > -Bryan. > The TLB flush issues are still outstanding. -ml
Re: VMM vulns?
On Wed, Sep 02, 2020 at 03:35:54AM +0200, f...@disciples.com wrote: > https://twitter.com/m00nbsd/status/1291257985734410244 > > I don't want to bump that old thread or start any arguments about this. I'm > just curious if this tweet is accurate or have these issues been addressed? > Were any of Maxime's suggestions implemented? > > > I am not sure if anyone picked up the remaining issues after I left active vmm development. At that time, I sent out my WIP diff for the TLB flush issue Maxime reported; it was not 100% complete. I am not sure if anyone is working on that or not, or any other issues he reported. -ml
Re: Alpine-virt vmd guest tsc directive
On Mon, Jun 29, 2020 at 08:25:19PM +, Martin wrote:
> Setting up Debian as vmm guest is not a trivial procedure and require Debian
> Linux host with KVM installed first to install your guest with screen
> connected.
>
Why do you believe this? Setting up debian in vmm is not any harder than setting
up any other distribution. You just need to make sure to use their install iso
that includes virtio. I think I used the minimal install iso (can't recall the
name, might have even been the netinst one).
> Once you have your host ready with KVM run a command to set iso up:
>
> qemu-img create -f qcow2 linux.qcow2 128G
>
> kvm -enable-kvm -vnc 127.0.0.1:0 -k en-us -monitor pty -m 2048 -net nic -net
> user -soundhw all -cdrom debian-linux.iso -boot -d -name linux -hda
> linux.qcow2
>
> Install it and run the machine with VNC connection
>
> kvm -enable-kvm -vnc 127.0.0.1:0 -k en-us -nographic -monitor pty -m 2048
> -net nic -net user -soundhw all -boot -d -name linux -hda linux.qcow
>
You don't need to do any of this.
-ml
> Onece you do it please mail me back, I'll share next steps somewhere.
>
> Martin
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, June 29, 2020 7:53 PM, George wrote:
>
> > On 2020-06-29 12:54 p.m., Martin wrote:
> >
> > > George, thanks for your feedback!
> > > I'd prefer OpenBSD in 99% of situations, but now I need to roll out
> > > Docker. Docker = linux. So I have to solve all the major issues,
> > > especially with clock, and run it for a project using OpenBSD host of
> > > course.
> >
> > Work is an imposed 'choice' ;) and yes that is where virtualization
> > shines a little light in the tunnel.
> >
> > > I set vmd Debian desktop guest a year ago with 5.2.x kernel which boots
> > > headless on vmd. Virtual framebuffer used for VNC connection from the
> > > same OpenBSD host by vnc viewer. Works perfectly, except clock...
> >
> > I would be interested in any instructions you might have on setting that up.
> >
> > > Currently, rebuilt kernel and vmd from -current. Going to make 5.4.x
> > > related vmm_clock module for minimalist Alpine-virt Linux guest. I'll
> > > report about results once done.
> >
> > That would be great.
> >
> > Thanks.
> >
> > > Martin
> > > ‐‐‐ Original Message ‐‐‐
> > > On Monday, June 29, 2020 4:21 PM, George g.lis...@nodeunit.com wrote:
> > >
> > > > On 2020-06-29 8:51 a.m., Martin Sukany wrote:
> > > >
> > > > > Hi George,
> > > > > did you solved the issue? I remember that I faces similar thing when
> > > > > I installed headless ubuntu as a guest … My issue was related to the
> > > > > fact that I used ‚boot cdrom‘ directive inside my configuration
> > > > > (seems that there is a bit inconsistency between the man page and the
> > > > > real configuration).
> > > > > This is is a relevant piece of my config:
> > > > > vm "ubuntu" {
> > > > > memory 2G
> > > > > cdrom /data/vms/_iso/mini-serial.iso
> > > > > disk /data/vms/ubuntu.raw
> > > > > interface tap { switch "uplink" }
> > > > > disable
> > > > > }
> > > > > I had bad experience with usage of qcow2 disk format for Linux based
> > > > > guests — especially when you’re trying to do dozens of I/O operations
> > > > > — several disk containers crashed before I migrated them to raw
> > > > > format.
> > > > > if you have more than 4 vms, don’t forget to create another
> > > > > /dev/tap device, otherwise you could expect the unexpectable
> > > > > behaviour :)
> > > > > M>
> > > > > Hello Martin,
> > > >
> > > > Thanks for the pointers. I abandoned my Linux efforts, too many issue
> > > > and things to learn no time now. My goals could be satisfied by an
> > > > OpenBSD VM and it is much better than most Linuxes ;). I have been
> > > > swimming against the current (read using things/software/apis/os/tools
> > > > etc. when people said it is not what is supposed to be done) but as of
> > > > late I find it more relaxing going with it ;).
> > > > Virtualization is such a ... mess which like everything else in our
> > > > lives nowadays is designed to cover another mess ... I want to run Linux
> > > > software on OpenBSD because I don't want to dedicate a machine to Linux
> > > > and want to upgrade or run the version I want until I want ... I should
> > > > be free to make that choice because of "I", sarcastic here, problem is
> > > > CPU vendors and OS developers have to jump some hoops and add some
> > > > features to make it happen ... and then things happen that the I does
> > > > not like.
> > > > Thanks for adding this info albeit to the wrong thread, I read it
> > > > because I like Alpine and was thinking of it myself, but they don't have
> > > > a ready console install version do they?
> > > > Cheers,
> > > > George
> > > >
> > > > > > > Hi guys,
> > > > > > > I apologize if this maybe out of topic even though it is truly
> > > > > > > related
> > > > > > > to VMM than Debian.
> > > > > > > I am trying to setup a VMM Debian based guest but I'm not able to
> > > > >
Re: Error messages with VMM on 6.6 and 6.7
On Tue, Jun 02, 2020 at 10:18:32AM +0800, jrmu wrote: > OpenBSD VMM suffers from error messages and possibly spontaneous crashing > > System : OpenBSD 6.7 > Details : OpenBSD 6.7 (GENERIC.MP) #182: Thu May 7 11:11:58 MDT > 2020 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > > >Description: > I ran VMM on OpenBSD 6.6 with ~30 VMs, a mixture of OpenBSD 6.6, 6.7, > and Debian, and kept seeing the following error messages in logs: > > May 28 00:54:37 srv1 vmd[97924]: rtc_update_rega: set non-32KHz timebase not > supported > May 28 00:59:05 srv1 vmd[24983]: rtc_update_rega: set non-32KHz timebase not > supported > May 28 01:12:35 srv1 vmd[31276]: rtc_update_rega: set non-32KHz timebase not > supported > May 28 01:14:40 srv1 vmd[31276]: vioblk queue notify - nothing to do? > May 28 01:15:12 srv1 last message repeated 806 times > May 28 01:17:03 srv1 last message repeated 78 times > May 28 01:30:03 srv1 vmd[31276]: vioblk queue notify - nothing to do? > May 28 01:40:19 srv1 last message repeated 67 times > May 28 01:44:17 srv1 last message repeated 47 times Those messages are a bit odd, basically it means the in-guest driver notified vioblk (the VM's disk device) that there were descriptors in the ring but when the device-side implementation (in vmd(8)) went to process them, the ring was empty. There shouldn't be any side effect, although it does indicate something unexpected is happening. > May 28 01:44:19 srv1 vmd[9684]: rtc_update_rega: set non-32KHz timebase not > supported > Those messages aren't serious, Linux kernels program the RTC this way. TBH, that message has probably outlived its usefulness. Someone can remove it at this point. > Every 2-3 weeks, the system appeared to crash, but I could not find any other > error message that would narrow down the cause. I am not sure if the crash is > related to either of those two above error messages. Likely unrelated; those messages are from vmd(8), a user-mode process. I think it's difficult for vmd(8) to crash the system. > > Today I upgraded to OpenBSD 6.7 stable with hopes that the problem may have > been fixed. However, I still notice the same two error messages: > > May 31 19:06:32 srv1 vmd[72705]: vcpu_process_com_data: guest reading com1 > when not ready > May 31 19:06:33 srv1 last message repeated 2 times > May 31 19:06:40 srv1 reorder_kernel: kernel relinking done > May 31 19:09:03 srv1 vmd[72705]: rtc_update_rega: set non-32KHz timebase not > supported > > Any workaround or suggestions? What is the question here? If you are tiring of the log messages, you can remove those particular ones. As I said higher up, these messages have likely exceeded their usefulness (these were put in during early development to detect weird corner cases like this). -ml > > dmesg: > OpenBSD 6.7 (GENERIC.MP) #182: Thu May 7 11:11:58 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 34306437120 (32717MB) > avail mem = 33254100992 (31713MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec830 (156 entries) > bios0: vendor American Megatrends Inc. version "3.3" date 05/23/2018 > bios0: Supermicro X9DRi-LN4+/X9DR3-LN4+ > acpi0 at bios0: ACPI 4.0 > acpi0: sleep states S0 S1 S4 S5 > acpi0: tables DSDT FACP APIC FPDT SRAT SLIT HPET PRAD SPMI SSDT EINJ ERST > HEST BERT DMAR MCFG > acpi0: wakeup devices P0P9(S1) EUSB(S4) USBE(S4) PEX0(S4) PWVE(S4) NPE1(S4) > NPE4(S4) NPE5(S4) NPE6(S4) NPE8(S4) NPEA(S4) NPE2(S4) NPE3(S4) NPE7(S4) > NPE9(S4) NPE2(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 2000.27 MHz, 06-2d-07 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz, 2000.02 MHz, 06-2d-07 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,A
Re: riscv
On Sat, Mar 14, 2020 at 11:18:11PM -0700, Mike Larkin wrote: > On Fri, Mar 13, 2020 at 02:12:19PM -0700, Jordan Geoghegan wrote: > > > > > > On 2020-03-13 09:50, Christian Weisgerber wrote: > > > On 2020-03-13, "Peter J. Philipp" wrote: > > > > > > > Any developer working on a riscv port and willing to share their > > > > unofficial > > > > work for possible future collaboration? > > > I think I'd have heard by now if somebody was, so I'll go out on a > > > limb and say no, nobody's working on a RISC-V port. > > > > > > > I stumbled across this a while back, this guy at least claims to be > > attempting a port to RISC-V... > > > > https://github.com/MengshiLi/openbsd-riscv-notes > > > > We have a riscv64 kernel booting up to the rootdev prompt, and are working on PS, "We" here is my student team. This is not being done as part of the main OpenBSD development effort. We hope to be able to get this committed when it is ready but we are nowhere near that yet. > getting plic working so that we can use virtio disks. > > The link above is from one of my students that is working on this. This is not > in the main tree, and I'm not sure what it will take to get it there (we are > using a newer version of clang than is in base). > > -ml >
Re: riscv
On Fri, Mar 13, 2020 at 02:12:19PM -0700, Jordan Geoghegan wrote: > > > On 2020-03-13 09:50, Christian Weisgerber wrote: > > On 2020-03-13, "Peter J. Philipp" wrote: > > > > > Any developer working on a riscv port and willing to share their > > > unofficial > > > work for possible future collaboration? > > I think I'd have heard by now if somebody was, so I'll go out on a > > limb and say no, nobody's working on a RISC-V port. > > > > I stumbled across this a while back, this guy at least claims to be > attempting a port to RISC-V... > > https://github.com/MengshiLi/openbsd-riscv-notes > We have a riscv64 kernel booting up to the rootdev prompt, and are working on getting plic working so that we can use virtio disks. The link above is from one of my students that is working on this. This is not in the main tree, and I'm not sure what it will take to get it there (we are using a newer version of clang than is in base). -ml
Re: Userland PCI drivers possible in OpenBSD?
On Fri, Jan 10, 2020 at 03:58:16AM +, Joseph Mayer wrote: > Maybe this topic is better suited for tech@, you tell: > > Is there some way I can implement PCI drivers in userland in OpenBSD? > no > On a quick Internet search, see some discussion for Linux and NetBSD > e.g. [1] however nothing in OpenBSD. > > I may be interested in operating some PCI device manually from my own > program (run as root or user) in OpenBSD, and I can see this being of > interest to others also, asking therefore. > > (I could understand if this would require IOMMU support to be safe.) > > OpenBSD overall is totally great so I'd prefer running an userland > driver in OpenBSD over another OS. > > Thanks, > Joseph > > [1] https://wiki.netbsd.org/projects/project/userland_pci/ , > https://news.ycombinator.com/item?id=16671852 >
Re: Suspend on Dell Inspiron 6000
On Thu, Oct 31, 2019 at 09:10:51PM +0100, Andreas Kusalananda Kähäri wrote: > On Thu, Oct 31, 2019 at 10:56:38AM -0700, Mike Larkin wrote: > > On Thu, Oct 31, 2019 at 01:41:55PM -0400, Patrick Coppock wrote: > > > Hi, All: > > > > > > I am new to OpenBSD; I recently installed 6.5 on a Dell Inspiron 6000 > > > and upgraded to 6.6 yesterday. Suspend did not work in 6.5 and still > > > doesn't in 6.6. > > > > > > What is the best way for me to go about debugging this issue? So far, > > > I have checked: > > > - dmesg for ACPI wake devices > > > - syslog for suspend messages > > > > > > Specifically, the suspend works; however, when I attempt to wake the > > > device, the laptop seems to respond and attempt to wake, but the > > > display never turns on, and I cannot SSH into the machine. Below are > > > the dmesg and relevant syslog entries. > > > > > > > About a year or so ago I posted a message to either misc@ or tech@ about > > how to diagnose suspend/resume failures, by bisecting the resume path and > > placing resets or spins at various places to see how far the resume gets > > before dying. I would recommend finding that post (I just looked and I > > couldn't find it though) and walking through those steps. > > Possibly this one? > > https://marc.info/?l=openbsd-bugs&m=152536221312302&w=2 > > > > > > I doubt any of us still have machines that old to try debugging this > > ourselves, the machine is nearly 15 years old. > > > > -ml > > > > > dmesg > > > = > > > > > > OpenBSD 6.6 (GENERIC) #0: Sat Oct 26 05:57:51 MDT 2019 > > > > > > r...@syspatch-66-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC > [cut] > Yep, that's the one. Thanks for digging that up. -ml
Re: Suspend on Dell Inspiron 6000
On Thu, Oct 31, 2019 at 01:41:55PM -0400, Patrick Coppock wrote:
> Hi, All:
>
> I am new to OpenBSD; I recently installed 6.5 on a Dell Inspiron 6000
> and upgraded to 6.6 yesterday. Suspend did not work in 6.5 and still
> doesn't in 6.6.
>
> What is the best way for me to go about debugging this issue? So far,
> I have checked:
> - dmesg for ACPI wake devices
> - syslog for suspend messages
>
> Specifically, the suspend works; however, when I attempt to wake the
> device, the laptop seems to respond and attempt to wake, but the
> display never turns on, and I cannot SSH into the machine. Below are
> the dmesg and relevant syslog entries.
>
About a year or so ago I posted a message to either misc@ or tech@ about
how to diagnose suspend/resume failures, by bisecting the resume path and
placing resets or spins at various places to see how far the resume gets
before dying. I would recommend finding that post (I just looked and I
couldn't find it though) and walking through those steps.
I doubt any of us still have machines that old to try debugging this
ourselves, the machine is nearly 15 years old.
-ml
> dmesg
> =
>
> OpenBSD 6.6 (GENERIC) #0: Sat Oct 26 05:57:51 MDT 2019
> r...@syspatch-66-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem = 527790080 (503MB)
> avail mem = 502480896 (479MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 09/28/05, BIOS32 rev. 0 @ 0xffe90, SMBIOS rev. 2.3 @
> 0xf80e0 (44 entries)
> bios0: vendor Dell Inc. version "A09" date 09/28/2005
> bios0: Dell Inc. Inspiron 6000
> acpi0 at bios0: ACPI 1.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC MCFG BOOT SSDT SSDT
> acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S3) USB0(S0) USB1(S0) USB2(S0)
> USB4(S0) USB3(S0) MODM(S3) PCIE(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Celeron(R) M processor 1.30GHz ("GenuineIntel" 686-class) 1.30
> GHz, 06-0d-06
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE,PERF,MELTDOWN
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xe000, bus 0-255
> acpimcfg0: addr 0x0, bus 0-0
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (AGP_)
> acpiprt2 at acpi0: bus 3 (PCIE)
> acpicpu0 at acpi0: !C3(250@85 io@0x1015), !C2(500@1 io@0x1014), C1(1000@1
> halt)
> acpitz0 at acpi0: critical temperature is 99 degC
> acpiac0 at acpi0: AC unit online
> acpibat0 at acpi0: BAT0 model "DELL F51336" serial 1988 type LION oem "Sanyo"
> acpibtn0 at acpi0: LID_
> acpibtn1 at acpi0: PBTN
> acpibtn2 at acpi0: SBTN
> "PNP0A03" at acpi0 not configured
> acpicmos0 at acpi0
> acpivideo0 at acpi0: VID_
> acpivideo1 at acpi0: VID_
> acpivideo2 at acpi0: VID2
> bios0: ROM list: 0xc/0xf800! 0xcf800/0x800
> pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82915GM Host" rev 0x03
> inteldrm0 at pci0 dev 2 function 0 "Intel 82915GM Video" rev 0x03
> drm0 at inteldrm0
> intagp0 at inteldrm0
> agp0 at intagp0: aperture at 0xc000, size 0x1000
> inteldrm0: apic 1 int 16
> "Intel 82915GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
> uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x03: apic 1 int 16
> uhci1 at pci0 dev 29 function 1 "Intel 82801FB USB" rev 0x03: apic 1 int 17
> uhci2 at pci0 dev 29 function 2 "Intel 82801FB USB" rev 0x03: apic 1 int 18
> uhci3 at pci0 dev 29 function 3 "Intel 82801FB USB" rev 0x03: apic 1 int 19
> ehci0 at pci0 dev 29 function 7 "Intel 82801FB USB" rev 0x03: apic 1 int 16
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00
> addr 1
> ppb0 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xd3
> pci1 at ppb0 bus 3
> bce0 at pci1 dev 0 function 0 "Broadcom BCM4401B1" rev 0x02: apic 1 int 18,
> address 00:11:43:70:7f:12
> bmtphy0 at bce0 phy 1: BCM4401 10/100baseTX PHY, rev. 0
> cbb0 at pci1 dev 1 function 0 "Ricoh 5C476 CardBus" rev 0xb3: apic 1 int 19
> "Ricoh 5C552 Firewire" rev 0x08 at pci1 dev 1 function 1 not configured
> sdhc0 at pci1 dev 1 function 2 "Ricoh 5C822 SD/MMC" rev 0x17: apic 1 int 17
> sdhc0: SDHC 1.0, 33 MHz base clock
> sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed
> bwi0 at pci1 dev 3 function 0 "Broadcom BCM4306" rev 0x03: apic 1 int 17,
> address 00:0b:7d:15:3a:24
> cardslot0 at cbb0 slot 0 flags 0
> cardbus0 at cardslot0: bus 4 device 0 cacheline 0x0, lattimer 0x20
> pcmcia0 at cardslot0
> auich0 at pci0 dev 30 function 2 "Intel 82801FB AC97" rev 0x03: apic 1 int
> 16, ICH6
> ac97: codec id 0x83847652 (SigmaTel STAC9752/53)
> ac97: codec features headphone, 20 bit DAC, 20 bit ADC,
Re: [6.6] PostgreSQL server: fail to auth
On Wed, Oct 30, 2019 at 05:45:15PM +0100, Stéphane HUC "PengouinBSD" wrote: > Hi, > > On my OpenBSD server, run with 6.6, I installed Postgresql server. > > I have a problem with auth. solene@ is informed of this problem; but > I'll tell you about it. Perhaps you have a solution? > > FYI: I start completely with Postgresql. Usually I use MySQL* > Postgresql has just been installed. > > > > The error message: > > psql: FATAL: password authentication failed for user "***" > > > > Demo: > > # su - _postgresql > arrakiss$ psql -U postgres > Password for user postgres: > psql (11.5) > Type "help" for help. > > postgres=# CREATE USER ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2 WITH PASSWORD > '6TsrKeqq93KyVtc5yVjU9dfZsJkPPtKKdSyEnjypZDkVdgtW4aVN3YNQd5vKoFNx'; > CREATE ROLE > postgres=# \connect template1 > You are now connected to database "template1" as user "postgres". > template1=# CREATE DATABASE "A5mSHO4SamFa2OJmJC81GbDtUhj4wkyU2" WITH > ENCODING 'UTF-8';" > CREATE DATABASE > template1"# GRANT ALL PRIVILEGES ON DATABASE > "A5mSHO4SamFa2OJmJC81GbDtUhj4wkyU2" TO ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2; > template1"# ALTER DATABASE "A5mSHO4SamFa2OJmJC81GbDtUhj4wkyU2" OWNER TO > ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2; > template1"# \q > Use control-D to quit. > template1"# \q > arrakiss$ exit > > In fact, I have one created user, named ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2 > His password: > 6TsrKeqq93KyVtc5yVjU9dfZsJkPPtKKdSyEnjypZDkVdgtW4aVN3YNQd5vKoFNx > One created DB, named: > A5mSHO4SamFa2OJmJC81GbDtUhj4wkyU2 > > And the user ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2 has all rights on DB > A5mSHO4SamFa2OJmJC81GbDtUhj4wkyU2 > > Right?! > > But, when I attempt to connect to DB with user, I have the above the > error message: > # psql -U ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2 > Password for user ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2: > psql: FATAL: password authentication failed for user > "ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2" > > # psql -U ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2 -d > A5mSHO4SamFa2OJmJC81GbDtUhj4wkyU2 > Password for user ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2: > psql: FATAL: password authentication failed for user > "ghiMDQawgogUfFRTikPoWsUFN1xX8bgz2" > > Ok I found it's necessary to change informations into file > 'pg_hba.conf'. I set as: > # grep A5mSHO4SamFa2OJmJC81GbDtUhj4wkyU2 > /var/postgresql/data/pg_hba.conf > > > local A5mSHO4SamFa2OJmJC81GbDtUhj4wkyU2 alltrust > > And restart the service/daemon postgresql. > > Despite, I cant connect on! > > --- > > Any idea, please?! > > -- > ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<< > > Stephane HUC as PengouinBSD or CIOTBSD > b...@stephane-huc.net > I think the problem might be that the user tC1xQOo7KSLdnc5J1VmGFChhodnH doesn't have the proper password of 47znNtnBlhViIzSm9GZFSQirlb8HIQcSl, which according to your PG installation, is required for accessing the database 'dqXijG7C1GGkuu98ZirPFwu2XTMo3V0QlF4'. Of course, it also might be because the user ZYo43MnD5aW5P4wqqeSE9aInA5SL9HURvpmpOZ doesn't have access to database NfyhoNhUQWZiZKOTtl0K7mR4yPEsMy8sJC to begin with. Seriously, did you expect someone to take the time to decipher what you wrote there? -ml
