cd*.iso reboot loop (vultr, Skylake AVX MDS)
My vultr OpenBSD 6.8 instance crashed and when it tried to reboot it failed at: root on sd0a (...) WARNING: / was not properly unmounted kernel: privileged instruction fault trap, code=0 mds_handler_skl_avx+0x33: clflush __ALIGN_SIZE+0x500(%rid,%rax,8) I tried to boot from cd{68,69,70}iso but all of them "fail", i.e., they start to boot, show some messages, and then get to the boot prompt again. Unfortunately the screen is cleared so I'm not sure what the last message was, but it seems to be similar as above. Unfortunately I don't have a previous dmesg from the system but I have a different vultr instance which runs fine (see dmesg below) I noticed at least one difference however: the crashing system shows Using Skylake AVX MDS workaround which might be something related to the function mentioned above? Is this workaround something that could be turned off to see whether it causes the problem? The weird thing is that OpenBSD 6.8 was installed fine (11 months ago), so I don't understand why this problem happens now (could vultr have changed something in the underlying system?) OpenBSD 7.0 (GENERIC) #224: Thu Sep 30 14:13:34 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 1056817152 (1007MB) avail mem = 1008914432 (962MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5950 (9 entries) bios0: vendor Vultr bios0: Vultr VC2 acpi0 at bios0: ACPI 3.0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP APIC HPET MCFG 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: Intel Core Processor (Broadwell, no TSX, IBRS), 2394.77 MHz, 06-3d-02 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 acpimcfg0 at acpi0 acpimcfg0: addr 0xb000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) "ACPI0006" at acpi0 not configured acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 "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 Broadwell MDS workaround pvbus0 at mainbus0: KVM pvclock0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00 vga1 at pci0 dev 1 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) ppb0 at pci0 dev 2 function 0 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci1 at ppb0 bus 1 virtio0 at pci1 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01 vio0 at virtio0: address 56:00:03:98:50:6e virtio0: msix shared ppb1 at pci0 dev 2 function 1 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci2 at ppb1 bus 2 xhci0 at pci2 dev 0 function 0 vendor "Red Hat", unknown product 0x000d rev 0x01: apic 0 int 22, xHCI 0.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Red Hat xHCI root hub" rev 3.00/1.00 addr 1 ppb2 at pci0 dev 2 function 2 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci3 at ppb2 bus 3 virtio1 at pci3 dev 0 function 0 "Qumranet Virtio 1.x Storage" rev 0x01 vioblk0 at virtio1 scsibus1 at vioblk0: 1 targets sd0 at scsibus1 targ 0 lun 0: sd0: 25600MB, 512 bytes/sector, 52428800 sectors virtio1: msix shared ppb3 at pci0 dev 2 function 3 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci4 at ppb3 bus 4 virtio2 at pci4 dev 0 function 0 vendor "Qumranet", unknown product 0x1045 rev 0x01 viomb0 at virtio2 virtio2: apic 0 int 22 ppb4 at pci0 dev 2 function 4 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci5 at ppb4 bus 5 virtio3 at pci5 dev 0 function 0 "Qumranet Virtio 1.x RNG" rev 0x01 viornd0 at virtio3 virtio3: apic 0 int 22 ppb5 at pci0 dev 2 function 5 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci6 at ppb5 bus 6 ppb6 at pci0 dev 2 function 6 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci7 at ppb6 bus 7 ppb7 at pci0 dev 2 function 7 vendor "Red Hat", unknown product 0x000c r
Re: Missing action list in lesskey man page
On Sat, Dec 04, 2021 at 12:19:34PM +0100, Richard Ulmer wrote: > Hi all, > I've been reading up on "advanced" less(1) features and came across the > lesskey(1) man page. In the COMMAND SECTION of the page I read this: > > > The action is the name of the less action, from the list below. > > However I cannot see this list of available actions. The only thing > similar I can find is the list of default commands with their actions. > From this I can deduce some available actions, but I'm not sure if those > are all the available actions. Maybe there are some actions that are not > bound by default. I'm also missing a description of what the actions do > (I don't know all the default less(1) commands off the cuff). > > Is the action list missing from the lesskey(1) man page, or am I > misunderstanding something? > > Greetings, > Richard Ulmer > hi. the actions do indeed match those in the command list. whether there are any undocumented ones, i don;t know. i suppose you'd have to go poking in the source. the actions will roughly match those described in the less(1) COMMANDS section. so for example in less(1): d | ^D Scroll forward n lines ... and in lesskey(1): d forw-scroll ^D forw-scroll so leskey gives you the action names (if you want to change them), and less describes what these actions do. we could maybe make this clearer: #command \r forw-line ... to sth like this: #command action \r forw-line ... however we still import less. i'd want to make sure that's not stepping on anyone's toes to make local changes. jmc
Re: Missing action list in lesskey man page
On 2021-12-04 12:39:41+, Jason McIntyre wrote: > On Sat, Dec 04, 2021 at 12:19:34PM +0100, Richard Ulmer wrote: > > Hi all, > > I've been reading up on "advanced" less(1) features and came across the > > lesskey(1) man page. In the COMMAND SECTION of the page I read this: > > > > > The action is the name of the less action, from the list below. > > > > However I cannot see this list of available actions. The only thing > > similar I can find is the list of default commands with their actions. > > From this I can deduce some available actions, but I'm not sure if those > > are all the available actions. Maybe there are some actions that are not > > bound by default. I'm also missing a description of what the actions do > > (I don't know all the default less(1) commands off the cuff). > > > > Is the action list missing from the lesskey(1) man page, or am I > > misunderstanding something? > hi. > > the actions do indeed match those in the command list. whether there are > any undocumented ones, i don;t know. i suppose you'd have to go poking > in the source. the actions will roughly match those described in the > less(1) COMMANDS section. so for example in less(1): > [] > > however we still import less. i'd want to make sure that's not stepping > on anyone's toes to make local changes. Pls forgive if I'm missing the important points, but in a way, maybe it is implied by man lesskey that the actions are connected with the command list shown. On ~ line 56-57 (under COMMAND SECTION) it says "The string is the command key(s) which invoke the action", which is easy to miss. Then there follows a list of commands, and one can search the man pages (with /) for everything that mentions "command", type "h" within less, etc. I find I have to do kind of thing that often to get a better idea of things, if one idea is mentioned in one part (or man page) then I need to go read other parts (or pages) that discuss the same thing; I even made a couple of scripts or aliases that quicken the process for me.
Re: cd*.iso reboot loop (vultr, Skylake AVX MDS)
On Sat, Dec 4, 2021 at 4:32 AM Claus Assmann wrote: > My vultr OpenBSD 6.8 instance crashed and when it tried to reboot it > failed at: > > root on sd0a (...) > WARNING: / was not properly unmounted > kernel: privileged instruction fault trap, code=0 > mds_handler_skl_avx+0x33: clflush __ALIGN_SIZE+0x500(%rid,%rax,8) > ... > I noticed at least one difference however: > the crashing system shows > Using Skylake AVX MDS workaround > which might be something related to the function mentioned above? They have your virtualization guest configured in a way that doesn't match any real hardware: it has a family-model-stepping combination that matches the Skylake line, real hardware of which all have the cflushopt extension, but the host is making the guest trap when that instruction is used. You could test this theory by changing "clflushopt" to "clflush" in mds.S and building a new ISO, but poking them to provide a more consistent virtualization setup, whether by migration or reconfiguration, is the better solution. We could add more tests of the cpuid data and codepatch out the instructions that should be there but aren't, but for something like the clflushopt instruction where there's no real good reason for not passing through the extension when the CPU presumably has it, it's hard to get much enthusiasm up for working around a pointlessly dumb (or buggy) virtualization config. > Is this workaround something that could be turned off to see whether > it causes the problem? > The weird thing is that OpenBSD 6.8 was installed fine > (11 months ago), so I don't understand why this problem happens now > (could vultr have changed something in the underlying system?) > The machine hosting your guest probably suffered some failure (thus the crash that you experienced) and they migrated your guest to another host to get you back up and running. I periodically see the tickets go by at my $DAYJOB of this sort of replacement. Hardware, especially modern PCs, don't live anywhere near forever... Philip Guenther
Re: cd*.iso reboot loop (vultr, Skylake AVX MDS)
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 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: cd*.iso reboot loop (vultr, Skylake AVX MDS)
Philip Guenther wrote: > They have your virtualization guest configured in a way that doesn't match > any real hardware: it has a family-model-stepping combination that matches > the Skylake line, real hardware of which all have the cflushopt extension, > but the host is making the guest trap when that instruction is used. My personal favorite is AMD cpus with Intel host bridges. Then code has to decide which types of family workarounds apply based upon non-sensical conditions. Oh, I see you have qbus instead of isa, you don't need this specific interrupt controller hack!
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: cd*.iso reboot loop (vultr, Skylake AVX MDS)
Mike Larkin wrote: > 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. No kidding. The Intel-compatible cpu landcape is pretty fucked up, in that feature bits are missing in some generations or otherwise inaccurate. Therefore a kernel has to someones look at the brand to narrow in on the truth and make a logical decision. At the moment the way we do it looks like this: amd64/cpu.c:if (strcmp(cpu_vendor, "GenuineIntel") == 0) { amd64/cpu.c:if (strcmp(cpu_vendor, "GenuineIntel") != 0 || amd64/cpu.c:if (strcmp(cpu_vendor, "GenuineIntel") == 0 && amd64/cpu.c:if (strcmp(cpu_vendor, "GenuineIntel") == 0 && amd64/identcpu.c: if (!strcmp(cpu_vendor, "GenuineIntel")) { amd64/identcpu.c: } else if (!strcmp(cpu_vendor, "CentaurHauls")) { amd64/identcpu.c: } else if (!strcmp(cpu_vendor, "AuthenticAMD")) { amd64/identcpu.c: if (!strcmp(cpu_vendor, "GenuineIntel") && cpuid_level >= 0x06) { amd64/identcpu.c: } else if (!strcmp(cpu_vendor, "AuthenticAMD")) { amd64/identcpu.c: if (!strcmp(cpu_vendor, "AuthenticAMD")) { amd64/identcpu.c: if (!strcmp(cpu_vendor, "AuthenticAMD")) { amd64/identcpu.c: if (!strcmp(cpu_vendor, "GenuineIntel") && amd64/identcpu.c: if (!strcmp(cpu_vendor, "AuthenticAMD") && amd64/identcpu.c: if (!strcmp(cpu_vendor, "AuthenticAMD")) amd64/identcpu.c: if (CPU_IS_PRIMARY(ci) && !strcmp(cpu_vendor, "CentaurHauls")) { amd64/identcpu.c: if (strcmp(cpu_vendor, "AuthenticAMD") == 0) { amd64/identcpu.c: } else if (strcmp(cpu_vendor, "GenuineIntel") == 0) { amd64/identcpu.c: if (!strcmp(cpu_vendor, "GenuineIntel")) { amd64/lapic.c: if (strcmp(cpu_vendor, "AuthenticAMD") == 0) { amd64/mtrr.c: if (((strcmp(cpu_vendor, "GenuineIntel") == 0) || amd64/mtrr.c: (strcmp(cpu_vendor, "CentaurHauls") == 0) || amd64/mtrr.c: (strcmp(cpu_vendor, "AuthenticAMD") == 0)) && amd64/pctr.c: pctr_isamd = (strcmp(cpu_vendor, "AuthenticAMD") == 0); amd64/pctr.c: pctr_isintel = (strcmp(cpu_vendor, "GenuineIntel") == 0); amd64/tsc.c:if (!strcmp(cpu_vendor, "GenuineIntel") && amd64/ucode.c: if (strcmp(cpu_vendor, "GenuineIntel") == 0) Then someone at Vultr, who is probably really proud of themselves, disabled all those tests. If they can so easily make a damaging decision like that without studying real system behaviour, what else will they get wrong?
Re: Missing action list in lesskey man page
On Sat, Dec 04, 2021 at 07:11:01PM +0100, Richard Ulmer wrote: > Hi Jason, > Thanks for you response! > hi! > > the actions do indeed match those in the command list. whether there are > > any undocumented ones, i don;t know. i suppose you'd have to go poking > > in the source. > > IMO users shouldn't have to go to the source code to compensate for > lacking documentation. > right. but someone at some point has to do the work if there is an issue. so by "you'd have to go poking" i really meant with a view to improving the page, rather than "all users should read the source to find this out". > Out of curiosity I did take a peek at the source and found this that > there are indeed undocumented actions: > - 'display-flag' is an undocumented alias for 'display-option' > - 'end' is an undocumented alias for 'goto-end' > - 'first-cmd' is an undocumented alias for 'firstcmd' > - 'flush-repaint' is an undocumented alias for 'repaint-flush' > - 'toggle-flag' is an undocumented alias for 'toggle-option' > - 'debug' is an entirely undocumented action > - 'forw-skip' is an entirely undocumented action > - 'shell' appears in the lesskey(1) man page but does not work > right. so if someone writes it up, future readers will not have to go poking. alternatively, there may a reason they are undocumented. > > the actions will roughly match those described in the > > less(1) COMMANDS section. so for example in less(1): > > > > d | ^D > > Scroll forward n lines ... > > > > and in lesskey(1): > > > > d forw-scroll > > ^D forw-scroll > > Doing this seems unnecessarily tedious to me. I'd much prefer to have > the actions explained in the lesskey(1) man page. Doing this still > doesn't explain everything; e.g. this still confuses me: > > s toggle-option o > > translates to > > s filename > Save the input to a file. This only works if the input is a > pipe, > not an ordinary file. > it confuses me too! i have no idea why they have used "toggle-option". but you can easily correlate "s" in lesskey with the documented "s" command in less. > > we could maybe make this clearer: > > > > #command > > \r forw-line > > ... > > > > to sth like this: > > > > #command action > > \r forw-line > > ... > > I'd prefer a separate list where each action is described with a little > more detail, than just having the example. > > > however we still import less. i'd want to make sure that's not stepping > > on anyone's toes to make local changes. > > I wanted to hear some second opinions first and make sure, that I didn't > miss anything. If I still think the documentation is lacking after that, > I could also suggest changes upstream. well you can file a bug report i suppose. but you could also look at how to improve things, write a diff, and submit it upstream. you will probably have a better chance if you do some of the work. jmc