Re: Webcam support on Lenovo Thinkpad T14 Gen3 (Intel)

[Bryan Steele]

Morgan wrote:
> Hello,
>
> $ video -q -f /dev/video1
> video: /dev/video1 has no usable YUV encodings
>
> $ video -s 1920x1080 -f /dev/video1
> video: /dev/video1 has no usable YUV encodings
>
>
> thanks for your suggestion
>
> Morgan

Are there any non-YUV formats supported?

$ ffmpeg -f v4l2 -list_formats all -i /dev/video1

-Bryan.

Re: Problems with HD

[Bryan Steele]

On Thu, Oct 05, 2023 at 05:41:28AM +, Maria Morisot wrote:
> > On Thu, Oct 05, 2023 at 04:08:34AM +, Maria Morisot wrote:
> > 
> > > I have an Asus Vivobook (1400EA),
> > > and the hard drive is not recognized
> > > by OpenBSD. I have the same problem
> > > on some distros of Linux, but on others
> > > it shows up fine.
> > 
> > 
> > My Asus ZenBook had a similar issue, which was resolved
> > by diving into the BIOS "Advanced" section and setting the
> > storage controller to something other than the pseudo-RAID
> > mode. It may we worth checking whether there is such an option
> > available.
> 
> I went into the BIOS and can't see anything about disabling RAID; and the 
> disk itself says there is no RAID on the drive. But I did get into the BIOS 
> info for the drive itself so I'll post that in case someone finds it useful.
> 
> Port: 1.0
> Model Number: Micron_2450_MTFDKBA256
> Serial Number: 214532CBCA77
> Size 238.4GB
> Controller Type: NVMe
> Controller Interface: PCIe

The option may be called "Intel Volume Management Device" (VMD), if you
don't see anything about RAID or Intel Rapid Storage RST.

It would be helpful to see a dmesg to confirm that this is the problem
you're having though.

-Bryan.
(VMD)

Re: Safely remove USB drive

[Bryan Steele]

On Wed, Feb 08, 2023 at 10:34:07AM -0300, vitmau...@gmail.com wrote:
> Hi,
> 
> I'm not using my drives for anything more than copying files, dd etc.
> I just got curious because you mentioned the act of detaching a device
> after umounting it and I don't know how to do that on OpenBSD. On
> Fedora I would issue "udisks --detach /dev/sdX" (older versions) or
> "udisksctl poweroff -b /dev/sdX" (newer versions).
> 
> Best,
> Vitor

Umounting should be good enough, but you can also use eject(1), which
should have the desired effect, e.g:

# disklabel sd1
# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: Flash Disk
...
# eject /dev/rsd1c
# disklabel sd1
disklabel: DIOCGDINFO: Input/output error
#

You'll need to physically reconnect the drive if you want to use it again.

-Bryan.

Re: WhatsApp Web in Chromium under OpenBSD 7.1

[Bryan Steele]

On Mon, May 09, 2022 at 06:50:16PM +0200, Federico Giannici wrote:
> On 5/9/22 18:40, Caspar Schutijser wrote:
> > On Mon, May 09, 2022 at 01:16:15PM +0200, Federico Giannici wrote:
> > > I'm not able to use WhatsApp Web in Chromium under OpenBSD 7.1 (amd64), no
> > > login page appears.
> > > Is there something bad in my configuration or is this a known problem?
> > > Thanks.
> > 
> > That's because by default WebAssembly is not enabled in Chromium (I
> > found out this was the culprit using the Developer Console, there was
> > some error message).
> > 
> > Starting Chromium with ENABLE_WASM=1 in your environment will
> > make it work.
> > 
> > Caspar
> > 
> 
> OK, it worked!
> 
> Now the question is: why WebAssembly is disabled by default under OpenBSD?
> Is there any contraindication to activate it?
> 
> Thanks.

WASM is unusable unless you have user limits set to near infinity,
and having it enabled by default actively broke websites that would
have otherwise worked without it.

https://marc.info/?l=openbsd-ports=154376428820247=2

IMO it was disabled for good reason. An environment variable exists
to override it for the few sites that need it.

I kind of wish this had also happened in Firefox, but that may soon
go in another direction..

-Bryan.

Re: dmesg - cpu, smt, core, package

[Bryan Steele]

pre-Ryzen AMD CPUs did not have SMT, but they had "CMT" or
"clustered multithreading" which is the shared-FPU stuff,
hw.smt=0 disables that too on these CPUs. I believe this
was intentional as this kind of resource sharing between
cores comes with inherent risk-- FPU state can contain
things like AES key data used by AESNI instructions, etc.

-Bryan.

Re: C states no longer recognized?

[Bryan Steele]

On Mon, Jan 31, 2022 at 02:16:20PM +0100, Jan Stary wrote:
> This is current/amd64 on a PC, dmesgs below.
> Looking at the diff between a Jan 24 and a Jan 31 dmesg,
> it seems that the C2 and C3 are no longer recognized:
> 
> -acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> -acpicpu1 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> -acpicpu2 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> -acpicpu3 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), 
> C1(1000@1 mwait.1), PSS
> +acpicpu0 at acpi0: C1(@1 halt!), PSS
> +acpicpu1 at acpi0: C1(@1 halt!), PSS
> +acpicpu2 at acpi0: C1(@1 halt!), PSS
> +acpicpu3 at acpi0: C1(@1 halt!), PSS
> 
> Is this expected? Is it related to the recent apm change
> of always running at full hw.setperf when on AC?
> 
>   Jan

Have you changed any settings in the BIOS or upgraded it recently? I've
seen this disable "Global C-state control" knob on some boards, not sure
if they'll find this on Intel boards or not.

-Bryan.

> 
> OpenBSD 7.0-current (GENERIC.MP) #0: Mon Jan 24 14:30:19 CET 2022
> h...@biblio.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 8419540992 (8029MB)
> avail mem = 8078901248 (7704MB)
> 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 "F2" date 04/20/2011
> bios0: Gigabyte Technology Co., Ltd. Z68MX-UD2H-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 MATS
> 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) i5-2400 CPU @ 3.10GHz, 3611.09 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 100MHz
> 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) i5-2400 CPU @ 3.10GHz, 3610.61 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) i5-2400 CPU @ 3.10GHz, 3610.61 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 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, 3610.61 MHz, 06-2a-07
> 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,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 0, core 3, 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 (PEG0)
> acpiprt2 at acpi0: bus -1 (PEG1)
> acpiprt3 at acpi0: bus 2 (PEX0)
> acpiprt4 at acpi0: bus -1 (PEX1)
> acpiprt5 at acpi0: bus -1 (PEX2)
> acpiprt6 at acpi0: bus 3 (PEX3)
> acpiprt7 at acpi0: bus 4 (PEX4)
> acpiprt8 at acpi0: bus 5 (PEX5)
> acpiprt9 at acpi0: bus 6 (PEX6)
> acpiprt10 at acpi0: bus 7 (PEX7)
> acpibtn0 at acpi0: PWRB
> acpipci0 at acpi0 PCI0
> acpicmos0 at acpi0
> com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 

Re: Samsung SSD X5 with OpenBSD - possible ?

[Bryan Steele]

On Mon, Oct 25, 2021 at 07:11:15PM +, Laura Smith wrote:
> 
> ‐‐‐ Original Message ‐‐‐
> 
> On Monday, October 25th, 2021 at 19:15, Stefan Sperling  
> wrote:
> 
> > On Mon, Oct 25, 2021 at 05:45:22PM +, Laura Smith wrote:
> >
> > > I'm struggling a bit as to what I need to do next here.
> > >
> > > Any time in the past I've connected a USB stick etc. to OpenBSD, 
> > > everything happened automagically in terms of recognition and assigning a 
> > > /dev/sd.
> > >
> > > However this time, its different.  This is the only line that appears in 
> > > dmesg when I plug it in:
> > >
> > > ugen0 at uhub0 port 4 "SAMSUNG ELECTRONICS CO., LTD Portable SSD X5" rev 
> > > 2.01/4.45 addr 2
> > >
> > > sysctl hw.disknames remains unchanged
> > >
> > > Any ideas ?
> >
> > I would guess that no driver is attaching because this drive requires
> >
> > Thunderbolt 3 rather than USB 3 (both use a USB-C type connector).
> 
> Makes sense, thanks !

Could you send a full dmesg with the device connected, and also try 
rebooting the machine with it still connected?

-Bryan.

Re: amd64 7.0 release where can I find original (patched) gcc 4x?

[Bryan Steele]

On Fri, Oct 22, 2021 at 06:20:30PM +, Martin wrote:
> Hi there!
> 
> After upgrading from source, there is no gcc installed into appropriate 
> location.

Upgrading between releases from source is not supported.

> ... how to enable original OpenBSD patched GCC 4x as default compiler?

You don't. clang has been the default compiler on amd64 since 6.2,
which was released back in 2017.

Sounds like the problem with you're having with mutt should be asked
on ports@ instead. You haven't said _what_ was supposedly still
depending on base-gcc, but making it work with clang or ports gcc is
clearly the way forward.

-Bryan.

Re: fna, fna3d packages GONE on 6.8

[Bryan Steele]

On Fri, Mar 05, 2021 at 02:49:19AM +, jpegb...@dismail.de wrote:

...

> I want to install fna and fna3d to be able to play terraria with fnaify
> but the packages seem to be nonexistant on 6.8-release, and they used
> to be available. I can't use -Dsnap because the new packages depend on
> a new version of sdl2, which depends on a new version of xenocara which
> is not available on 6.8. I would upgrade to 6.9-beta but as I sent in
> a previous email it does not boot on my computer, so I'm at a loss. 
> Does anyone know of a way to fix this? Or why the packages are no 
> longer available? Thanks.

The games/fna and graphics/fna3d ports were committed after 6.8, there
were never any packages for 6.8.

https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/games/fna/
https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/graphics/fna3d/

Re: Intel Turbo Memory in Thinkpad W500

[Bryan Steele]

On Sun, Feb 28, 2021 at 09:00:25PM +0100, Jan Stary wrote:
> This is 6.9-beta/amd64 on a Thinkpad W500 (dmesg below).
> 
> Taking out the unneeded stuff (I usually take out bluetooth,
> replace the wifi with Intel 7260 HMW etc), I also noticed this
> (see attachments). Taking it out, the difference in dmesg shows:
> 
> -"Intel Turbo Memory" rev 0x11 at pci4 dev 0 function 0 not configured
> 
> Given that it's "not configured", I don't think I'm missing much
> (and the Thinkpad's memory doesn't seem any less "Turbo"),
> but does anyone know what it does in the Thinkpad? AFAIG,
> is was supposed to be a thing before 4G of RAM and SSDs
> were common ...
> 
>   Jan

1-4GB of NAND flash on an option card.

There is an incomplete Linux reverse engineering effort, but it doesn't
look particularly all that interesting, and likely slower than an SSD by
today's standards.

https://github.com/yarrick/turbomem

-Bryan.

Re: audio stops frequently with current

[Bryan Steele]

...
> azalia1 at pci11 dev 0 function 4 "AMD 17h/3xh HD Audio" rev 0x00: msi
> azalia1: codecs: Realtek ALC892
> audio0 at azalia1

There is still an issue with MSI interrupts for HD Audio devices on
AMD systems, in the past we've been able to workaround it in the driver.
You can certainly try that. But from previous testing by other users
this trick no longer works for newer AMD chipsets.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/azalia.c.diff?r1=1.246=1.245

Your device would be "PCI_PRODUCT_AMD_17_3X_HDA".

-Bryan.

Re: i386 "panic: pci_make_tag: bad request" after acpi sleep states

[Bryan Steele]

On Tue, Dec 29, 2020 at 12:11:29PM -0500, Ian Darwin wrote:
> On Tue, Dec 29, 2020 at 09:42:59AM -0500, Bryan Steele wrote:
> > On Mon, Dec 28, 2020 at 01:20:29PM -0500, Ian Darwin wrote:
> > > Kernel is OpenBSD 6.8-current (GENERIC) #561: Sun Dec 27 18:29:43 MST 2020
> > > 
> > > Machine is a Wyse C90 - orignially sold as a "thin client" - tiny 
> > > machine, no serial port (ps and trace typed in).
> > > HW Info at https://www.parkytowers.me.uk/thin/wyse/cx0/
> > > Was planning to use it as a wifi bridge, so tiny is fine.
> > > 
> > > "Latest" BIOS (2012 edition). "BIOS reset" did not help.
> > > cpu info: VIA Eden Processor 1000MHz ("CentaurHauls" 686-class) 1.01 GHz, 
> > > 06-0d-00
> > > RAM: 1GB (despite reported as 3/4 of that)
> > 
> > Long shot, but could you maybe show the output of "machine memory" for
> > both boot/pxeboot? I'm curious if the memory map is reportedly
> > differently between a working boot and a bad one.
> 
> 
> Good suggestion, and indeed, it differs a little:
> 
> Using pxeboot:
> 
> CLIENT MAC ADDR: 00 80 64 xx xx xx GUID: C2020018-0403-0920-EE9A-0080648793AD
> CLIENT IP: 192.168.42.245 MASK: 255.255.255.0 DHCP IP: 192.168.42.254
> GATEWAY IP: 192.168.42.254
> probing: pc0 pci pxe![2.1] mem[546K 765M a20-on]
> disk: hd0+
> net: nac 00:80:64:xx:xx:xx, ip 192.168.42.245, server 192.168.42.254
> >> OpenBSD, i386 PXEBOOT 3.43 boot> machine mem
> Region 0: type 1 at 0x0 for 546KB
> Region 1: type 2 at 0x88800 for 94KB
> Region 2: type 2 at Oxe for 128KB
> Region 3: type 1 at 0x10 for 784192KB
> Region 4: type 3 at Ox2fed for 28KB
> Region 5: type 4 at 0x2fed7000 for 4KB
> Region 6: type 2 at Ox2fed8000 for 160KB
> Region 7: type 2 at Ox2ff0 for 1024KB
> Region 8: type 2 at Ox3000 for 262144KB
> Region 9: type 2 at Oxe000 for 262144KB
> Region 10: type 2 at Oxfec0 for 64KB
> Region 11: type 2 at Oxfee0 for 4KB
> Region 12: type 2 at Oxfff0 for 1024KB
> Low ram: 546KB High ram: 784192KB Total free nemory: 784738KB
> boot>
>  
> Using /boot:
> 
> >> OpenBSD/i386 BOOT 3.44
> boot> machine mem
> Region 0: Type 1 at 0x0x for 631KB
> Region 1: Type 2 at 0x9dc99 for 9KB
> Region 2: type 2 at 0xe for 128kb
> (remainder the same)
> 
> Could Region 1 being so microscopic cause problems? If it got used for 
> anything?
>
Type 2 here means the memory is reserved (not available for use), while
type 1 (and generally 3) can be used by the bootloader or kernel.

> Thx for looking.

No problem, it's interesting that pxeboot actually has less memory
below 1Meg compared to normal /boot, but I guess that makes sense
in that environmnet.

But curious to hear from people more familiar with the boot blocks
have an ideas.

> > > Full dmesg below; full ACPI attached.
> > > 
> > > Boot used Kernel  FromResult
> > > pxeboot   bsd.rd  tftpOK
> > > pxeboot   bsd hd0aOK (via 
> > > tftpboot/etc/conf)
> > > boot  bsd hd0apanic
> > > 
> > > I.e., Boots fine with pxeboot "set device hd0a", but booting exact same 
> > > kernel off same disk via /boot causes panic.
> > > 
> > > It's an older machine so it's likely a buggy acpi, not worth massive 
> > > investment of time, just wonder if there's an easy workaround.
> > > Presume it's getting something different in some AML, based on where boot 
> > > code loaded from,
> > > or else pxeboot vs boot setting environment slightly differently?
> > > 
> > > On screen after panic:
> > > 
> > > bios0: WYSE C CLASS
> > > acpi0 at bios0: ACPI 3.0
> > > acpi0: sleep states S0 S1 S3 s4 S5panic: pci_make_tag: bad request
> > > Stopped at db_enter+0x4: popl %eb
> > > 
> > > trace:
> > > 
> > > db_enter(d0e5e189,d10f6704,2,0,0) at db_enter+0x4
> > > panic(d0c3d47d,1,d10f6750,d0854f11,0) at panic+0xd3
> > > pci_make_tag(0,0,11,0) at pci_make_tag+0x95
> > > acpi_gasio(d2b1b400,0,2,6e,11,1,1,d10f67d8) at acpi_gasio+0x1f1
> > > aml_opreg_pcicfg_handler(0,0,6e,11,1,d10f67d8) at 
> > > aml_opreg_pcicfg_handler+0x21
> > > aml_rwgen(d2b338c4,373,1,d2b3f304,0,1) at aml_rwgen+0x571
> > > aml_rwfield(d2b2bc04,0,1,d2b3f304,0) at aml_rwfield+0x37a
> > > aml_eval(d2b40704,d2b2bc04,74,d10f692c,0) at aml_eval+0x17a
> > > aml_parse(d2b40704,74,d2b2f804) at aml_parse+0x2b15
> > > aml_parse(d2b4

Re: i386 "panic: pci_make_tag: bad request" after acpi sleep states

[Bryan Steele]

On Mon, Dec 28, 2020 at 01:20:29PM -0500, Ian Darwin wrote:
> Kernel is OpenBSD 6.8-current (GENERIC) #561: Sun Dec 27 18:29:43 MST 2020
> 
> Machine is a Wyse C90 - orignially sold as a "thin client" - tiny machine, no 
> serial port (ps and trace typed in).
> HW Info at https://www.parkytowers.me.uk/thin/wyse/cx0/
> Was planning to use it as a wifi bridge, so tiny is fine.
> 
> "Latest" BIOS (2012 edition). "BIOS reset" did not help.
> cpu info: VIA Eden Processor 1000MHz ("CentaurHauls" 686-class) 1.01 GHz, 
> 06-0d-00
> RAM: 1GB (despite reported as 3/4 of that)

Long shot, but could you maybe show the output of "machine memory" for
both boot/pxeboot? I'm curious if the memory map is reportedly
differently between a working boot and a bad one.

-Bryan.

> Full dmesg below; full ACPI attached.
> 
> Boot used Kernel  FromResult
> pxeboot   bsd.rd  tftpOK
> pxeboot   bsd hd0aOK (via 
> tftpboot/etc/conf)
> boot  bsd hd0apanic
> 
> I.e., Boots fine with pxeboot "set device hd0a", but booting exact same 
> kernel off same disk via /boot causes panic.
> 
> It's an older machine so it's likely a buggy acpi, not worth massive 
> investment of time, just wonder if there's an easy workaround.
> Presume it's getting something different in some AML, based on where boot 
> code loaded from,
> or else pxeboot vs boot setting environment slightly differently?
> 
> On screen after panic:
> 
> bios0: WYSE C CLASS
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S1 S3 s4 S5panic: pci_make_tag: bad request
> Stopped at db_enter+0x4: popl %eb
> 
> trace:
> 
> db_enter(d0e5e189,d10f6704,2,0,0) at db_enter+0x4
> panic(d0c3d47d,1,d10f6750,d0854f11,0) at panic+0xd3
> pci_make_tag(0,0,11,0) at pci_make_tag+0x95
> acpi_gasio(d2b1b400,0,2,6e,11,1,1,d10f67d8) at acpi_gasio+0x1f1
> aml_opreg_pcicfg_handler(0,0,6e,11,1,d10f67d8) at 
> aml_opreg_pcicfg_handler+0x21
> aml_rwgen(d2b338c4,373,1,d2b3f304,0,1) at aml_rwgen+0x571
> aml_rwfield(d2b2bc04,0,1,d2b3f304,0) at aml_rwfield+0x37a
> aml_eval(d2b40704,d2b2bc04,74,d10f692c,0) at aml_eval+0x17a
> aml_parse(d2b40704,74,d2b2f804) at aml_parse+0x2b15
> aml_parse(d2b40704,69,38) at aml_parse+0x351
> aml_parse(d2b40704,54,9,d2b36518,d2b40704) at aml_parse+0x351
> aml_eval(0,d2b36544,74,0,0) at aml_eval+0x277
> aml_evalnode(d10f6b10,d2b36504,0,0,d10f6ac0) at aml_evalnode+0xae
> aml_evalinteger(d1b1b400,d2b36a84,d0c17e38,0,0,d10f6b30) at 
> aml_evalinteger+0xae
> acpi_foundprw(d2b36d04,d2b1b400) at acpi_foundprw+0x2f
> aml_find_node(d2b36a84,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x?2
> aml_find_node(d2b336c4,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
> aml_find_node(d2b296c4,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
> aml_find_node(d2b31484,d0b9299b,d0859b90,d2b1b400) at aml_find node+0x9b 
> aml_find_node(d0eba1a8,d0b9299b,d0859b90,d2b1b400) at aml_find_node+0x9b
> acpi_init_gpes (d2b1b400) at acpi_init_gpes+0x195 
> acpi_attach_common(d2b1b400,f67a0) at acpi_attach_common+0x355
> acpi_attach(d2b210c0,d2b1b400,d10f6db8) at acpi_attach+0xZc
> config attach(d2b210c0,d0df60d4,d10f6db8,d0928b30) at config attach+0x18a
> config_found_sm(d2b210c0,d10f6db8,d0928630,0) at config_found_sm+0x29
> biosattach(d2b21080, d2b210c0,d10f6eb8) at biosattach+0x19a
> config attach (d2b21080, d0df 4c94,d10f6eb8, d02431f0) at config_attach+0x18a 
> config_found_sm(dZbZ1080, d10f beb8, d02431f0,0) at config_found_sm+0x29 
> mainbus_attach(0,d2b21080,0) at mainbus attach_0x5c
> config_attach(0,d0df 2614,0,0) at config_attach+0x18a
> cpu_configure(lie340b7,10f 4000, 1103000, 10 7000,0) at cpu_configure+0x24 
> main(0,0,0,0,0) at main+0x311
> ddb>
> 
> ps:
>TID   PID  UID  PRFLAGS  PFLAGS  CPU  COMMAND
> *0 00  0x1  0x200 0  swapper
> 
> Dmesg:
> ssh wyse cat /var/run/dmesg.boot
> OpenBSD 6.8-current (GENERIC) #561: Sun Dec 27 18:29:43 MST 2020
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem  = 803459072 (766MB)
> avail mem = 772513792 (736MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 01/16/12, BIOS32 rev. 0 @ 0xfdd30, SMBIOS rev. 2.6 @ 
> 0x2fed8000 (48 entries)
> bios0: vendor Phoenix Technologies version "1.0G" date 01/16/2012
> bios0: WYSE C CLASS
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S1 S3 S4 S5
> acpi0: tables DSDT FACP SSDT APIC MCFG HPET
> acpi0: wakeup devices PWRB(S4) PCI0(S5) PS2M(S3) PS2K(S3) USB1(S4) USB2(S4) 
> USB3(S4) USB4(S4) USB5(S4) HDAC(S5) SP2P(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: VIA Eden Processor 1000MHz ("CentaurHauls" 686-class) 1.01 GHz, 06-0d-00
> cpu0: 
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,CMOV,PAT,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE,SSE3,EST,TM2,xTPR,NXE
> mtrr: 

Re: gcc: error trying to exec 'cc1': execvp: no such file or directory

[Bryan Steele]

On Fri, Nov 20, 2020 at 02:02:56PM +, Rodrigo Readi wrote:
> 
> On Fri, 20 Nov 2020, Bryan Steele wrote:
> 
> > It took you *6* emails before finally mentioning which platform were
> > on, even after being asked..
> 
> Yes, excuse me, I answered to Nick Samsung nc10, but not mentioned i386.
> 
> > i386 removed the base gcc compiler in OpenBSD 6.6, so the binaries were
> 
> Your link for 6.8 says: "Disabled gcc in base on armv7 and i386."

I linked to the 6.6 page, not 6.8. Yes, it was disabled, and henced
removed from the distribution sets for i386 (and armv7), but not from
the tree as other architectures still use base-gcc. New installs do
not include them on i386/armv7, but upgrades do not removed obsolete
binaries in general.

> > obsolete even on your 6.7 install.. i386 has been a default clang arch
> > since OpenBSD /6.2/.
> 
> Clang was default, gcc may be obsolete, but /usr/bin/gcc is till now
> there, broken. In the upgrade instructions is not mentioned to delete
> it:
> 
> https://www.openbsd.org/66.html
> 
> The man page of gcc-local is till now (6.8) delivered in comp68.tgz

The man page is installed on all architectures so that's irrelevant.

> Rod.

Re: gcc: error trying to exec 'cc1': execvp: no such file or directory

[Bryan Steele]

On Fri, Nov 20, 2020 at 11:27:46AM +, Roderick wrote:
> 
> On Thu, 19 Nov 2020, Todd C. Miller wrote:
> 
> > On Thu, 19 Nov 2020 22:07:33 +, Roderick wrote:
> > 
> > > g++, gcc and gcov in /bin are from Apr 13, 2019. The rest are from
> > > Oct 5, 2020.
> > 
> > That explains your problem.  The upgrade would have removed any
> > obsolete /usr/lib/gcc-lib/amd64-unknown-openbsd* directory which
> > the old gcc binaries require.
> 
> tar tvzf base68.tgz | grep gcc
> 
> gives nothing. It seems, gcc was removed from i386. That explains
> the old date of my gcc binary that was never deleted. But that

...

It took you *6* emails before finally mentioning which platform you
were running, even after being asked..

i386 removed the base gcc compiler in OpenBSD 6.6, so the binaries were
obsolete even on your 6.7 install.. i386 has been a default clang arch
since OpenBSD /6.2/!

https://www.openbsd.org/66.html

Re: gcc: error trying to exec 'cc1': execvp: no such file or directory

[Bryan Steele]

Roderick wrote:
> It seems, gcc was removed from i386. That explains the old date of my
gcc binary that was never deleted.

It took you *6* emails before finally mentioning which platform were
on, even after being asked..

i386 removed the base gcc compiler in OpenBSD 6.6, so the binaries were
obsolete even on your 6.7 install.. i386 has been a default clang arch
since OpenBSD /6.2/.

https://www.openbsd.org/66.html

Re: support new

[Bryan Steele]

On Tue, Nov 17, 2020 at 04:55:55PM +0100, Emre Kal wrote:
> If my request is rejected again, please provide me with the *objective* 
> reasons why I am not allowed to list my services as a OpenBSD consultant.

Yeah, no.

> I believe I am entitled ...

There's your mistake right there.

-Bryan.

Re: OpenBSD 6.8 (release) guest (qemu/kvm) on Linux 5.9 host (amd64) fails with protection fault trap

[Bryan Steele]

On Sun, Nov 15, 2020 at 06:20:52PM +, Gabriel Garcia wrote:
> Hi,
> 
> I would like to run OpenBSD as stated on the subject - I have been able,
> however, to run it successfully with "-cpu Opteron_G2-v1", but I would
> rather use "-cpu host" instead. Also note that on an Intel host, OpenBSD
> appears to work successfully on the same Linux base.
> 
> qemu invocation that yields a trap:
> qemu-system-x86_64 -enable-kvm -machine q35 -cpu 
> host,-nodeid-msr,-vmx-msr-bitmap,-popcnt,-tsc-deadline,-mmxext,-fxsr-opt,-pdpe1gb,-rdtscp,-3dnow,-3dnowext,-cmp-legacy,-svm,-cr8legacy,-abm,-sse4a,-misalignsse,-3dnowprefetch,-osvw,-amd-no-ssb
> \
> 
>   -drive file=/path/to/raw.img,format=raw,if=virtio \
> 
>   -m 512M  \
> 
>   -display curses
> 
> (note that `-cpu host` without deactivating any flag also yields a trap)
> 
> dmesg output:
> ddb> dmesg
> 
>  OpenBSD 6.8 (GENERIC) #1: Tue Nov  3 09:04:47 MST 2020
> 
> 
> r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> 
>  real mem = 519954432 (495MB)
> 
>  avail mem = 489299968 (466MB)
> 
>  random: good seed from bootblocks
> 
>  mpath0 at root
> 
>  scsibus0 at mpath0: 256 targets
> 
>  mainbus0 at root
> 
>  bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5aa0 (9 entries)
> 
>  bios0: vendor SeaBIOS version
> "?-20190711_202441-buildvm-armv7-10.arm.fedorapro
> 
>  ject.org-2.fc31" date 04/01/2014
> 
>  bios0: QEMU Standard PC (Q35 + ICH9, 2009)
> 
>  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: AMD Turion(tm) II Neo N40L Dual-Core Processor, 1497.89 MHz, 10-06-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,CX16,x2APIC,POPCNT,DEADLINE,HV,NXE,MMXX,FFXSR,PAGE1GB,
> RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,
> 
> SSBDNR
> 
>  cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
> 64b/line 1
> 
>  6-way L2 cache, 16MB 64b/line 16-way L3 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
> 
>  kernel: protection fault trap, code=0
> 
>  Stopped at  amd64_errata_setmsr+0x4e:   wrmsr
> 
> 
> Contents of CPU registers:
> ddb> show registers
> 
>  rdi   0x9c5a203a
> 
>  rsi   0x820ff920errata+0xe0
> 
>  rbp   0x824c5740end+0x2c5740
> 
>  rbx 0x18
> 
>  rdx0
> 
>  rcx   0xc0011029
> 
>  rax  0x3
> 
>  r80x824c55a8end+0x2c55a8
> 
>  r9 0
> 
>  r10   0xbdf7dabff85d847b
> 
>  r11   0x51e076fef1dcfa7b
> 
>  r120
> 
>  r130
> 
>  r14   0x820ff940acpihid_ca
> 
>  r15   0x820ff920errata+0xe0
> 
>  rip   0x81bc6edeamd64_errata_setmsr+0x4e
> 
>  cs   0x8
> 
>  rflags   0x10256__ALIGN_SIZE+0xf256
> 
>  rsp   0x824c5730end+0x2c5730
> 
>  ss  0x10
> 
>  amd64_errata_setmsr+0x4e:   wrmsr
> 
> 
> 
> Working system dmesg (only change from invocation above is "-cpu
> Opteron_G2-v1"):
> OpenBSD 6.8 (GENERIC) #1: Tue Nov  3 09:04:47 MST 2020
> 
> 
> r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> 
> real mem = 519950336 (495MB)
> 
> avail mem = 489304064 (466MB)
> 
> random: good seed from bootblocks
> 
> mpath0 at root
> 
> scsibus0 at mpath0: 256 targets
> 
> mainbus0 at root
> 
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5aa0 (9 entries)
> 
> bios0: vendor SeaBIOS version
> "?-20190711_202441-buildvm-armv7-10.arm.fedoraproject.org-2.fc31" date
> 04/01/2014
> 
> bios0: QEMU Standard PC (Q35 + ICH9, 2009)
> 
> 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: AMD Opteron 22xx (Gen 2 Class Opteron), 1497.89 MHz, 0f-06-01
> 
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
> CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF
> 
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
> 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 cache
> 
> cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
> 
> cpu0: DTLB 255 4KB entries 

Re: Switching layout in vmm linux guest on OpenBSD host with english layout only

[Bryan Steele]

On Wed, Sep 30, 2020 at 07:44:46AM +, Martin wrote:
> I'm running headless Debian guest with two keyboard layouts. *.qcow2 qemu 
> image has been imported from Debian host.
> Graphical mode of vmm and qemu with Debian guest access using vncviewer for 
> both hosts. The guest itself has vncserver to share screen using headless 
> setup.
> 
> 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.
> 
> Martin

OpenBSD vmm/vmd(8) doesn't emulate a keyboard, so there can be no
keyboard layouts.

This sounds like something you should be configured in the VNC
client or server..

-Bryan.

Re: VMM vulns?

[Bryan Steele]

On Wed, Sep 02, 2020 at 09:36:17PM -0400, Bryan Steele wrote:
> The direct map issue on Intel CPUs hinted at by Maxime was also fixed
> by kettenis@, deraadt@ and millert@.

Sorry.. and mpi@

https://marc.info/?l=openbsd-cvs=158213132510408=2

> 
> -Bryan.

Re: VMM vulns?

[Bryan Steele]

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=158180761313544=2
https://marc.info/?l=openbsd-cvs=158269876318391=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=158196338821895=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=158269724517998=2

-Bryan.

Re: Could somebody please put unveil() in ftp(1)?

[Bryan Steele]

On Fri, May 29, 2020 at 11:41:43AM -0400, Christopher Turkel wrote:
> On Friday, May 29, 2020, Stuart Henderson  wrote:
> 
> > On 2020/05/29 08:30, Luke Small wrote:
> > > You mention a lot of files that need to be read, but a program like
> > pkg_add can make it the
> > > _pkgfetch (57) user which has no directory and I’m guessing not in
> > interactive mode. At the
> > > very least, in noninteractive mode you could unveil(“/“, “rx”); and
> > change the specified output
> > > file discover the name of the file that is to be downloaded and unveil
> > it as “cw” !
> > > --
> > > -Luke
> >
> > What problem are you trying to solve?
> >
> > If you are concerned about writes, use "ftp -o - $URL > somefile", it will
> > run without cpath/wpath, which is functionally similar to unveil("/", "rx")
> > (a bit stronger, because a program trying to write will be killed, rather
> > than just having a file access error).
> >
> > pkg_add(1) already uses "ftp -o -":
> >
> > # ktrace -di pkg_add -u moo
> > quirks-3.339 signed on 2020-05-27T20:05:28Z
> >
> > # kdump | grep promise=
> >  61644 ftp  STRU  promise="stdio rpath dns tty inet proc exec fattr"
> >  41938 signify  STRU  promise="stdio rpath wpath cpath tty"
> >  41938 signify  STRU  promise="stdio rpath"
> >  24897 ftp  STRU  promise="stdio rpath dns tty inet proc exec fattr"
> >  54324 signify  STRU  promise="stdio rpath wpath cpath tty"
> >  54324 signify  STRU  promise="stdio rpath"
> >   9188 ftp  STRU  promise="stdio rpath dns tty inet proc exec fattr"
> 
> 
> 
> If you need a diff written, I'm sure a developer would be willing in return
> for a donation.

No. That's not how any of this works.

Re: chattr on OpenBSD???

[Bryan Steele]

On Fri, Apr 17, 2020 at 09:11:15AM -0600, Raymond, David wrote:
> I noticed that chattr exists on OpenBSD.  The man page says it applies
> to Linux file systems (ext* etc).  Two questions:

No. You have e2fsprogs installed.

e2fsprogs-1.42.12p5:sysutils/e2fsprogs:/usr/local/man/man1/chattr.1


..bottom of chattr(1):

E2fsprogs version 1.42.12 August 2014CHATTR(1)

-Bryan.

Re: Openbsd supports pae?

[Bryan Steele]

Why should any of us exert more effort than you're willing to
put into writing an email?

Nikita Stepanov wrote:
> Why?

Re: strange dmesg

[Bryan Steele]

On Sat, Feb 08, 2020 at 03:27:55PM -0500, Bryan Steele wrote:
> On Sat, Feb 08, 2020 at 11:28:41AM +0100, whistlez...@riseup.net wrote:
> > Hi,
> > I have some strange output from dmesg, what could be ?
> > At the follwoing link I've posted some screenshots:
> > https://postimg.cc/gallery/1o4wsaw74/
> > Thank you
> 
> I thought this was pretty well known, but you're looking at garbage
> from previous boots. Something scribbled over that memory.
> 
>"On some systems the message buffer can survive reboot and be retained
> (in the hope of exposing information from a crash)."
> 
> https://man.openbsd.org/dmesg
> 
> -Bryan.

The dmesg buffer is a circular buffer, where old data is at the start
and new data is appeneded to it untill it is full, then it wraps around
to the start.

There are some "magic number" sanity checks, but those are not entirely
foolpoof. It's all done as a best effort attempt to preverve logging from
across a reboot.

-Bryan.

Re: strange dmesg

[Bryan Steele]

On Sat, Feb 08, 2020 at 11:28:41AM +0100, whistlez...@riseup.net wrote:
> Hi,
> I have some strange output from dmesg, what could be ?
> At the follwoing link I've posted some screenshots:
> https://postimg.cc/gallery/1o4wsaw74/
> Thank you

I thought this was pretty well known, but you're looking at garbage
from previous boots. Something scribbled over that memory.

   "On some systems the message buffer can survive reboot and be retained
(in the hope of exposing information from a crash)."

https://man.openbsd.org/dmesg

-Bryan.

Re: SSIZE_MAX

[Bryan Steele]

> I am confused about SSIZE_MAX and read(2)/write(2).  The POSIX
> SSIZE_MAX is something like 2^15 -1.  This seems to be a real
> limitation when writing to a TCP/IP socket, as I learned from
> experience.  However, much larger reads and writes seem to be possible
> to files and UNIX sockets (pipes).  This makes me uneasy, given the
> warning in the man pages for read(2)/write(2).
>
> Any insight on this topic would be appreciated.
>
> -- 
> David J. Raymond
> david.raym...@nmt.edu
> http://physics.nmt.edu/~raymond

Not in any reasonably modern version of POSIX..

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html

{SSIZE_MAX}
Maximum value for an object of type ssize_t.

$ grep -R "SSIZE_MAX" /usr/include
./amd64/limits.h:#define SSIZE_MAX  LONG_MAX/* max value for
a ssize_t */

/usr/include/sys/limits.h:
#ifdef __LP64__
..
# define LONG_MAX   0x7fffL
...
#else
..
# define LONG_MAX   0x7fffL

-Bryan.

Re: syspatch says 6.5 patch #011 (libexpat) is malformed

[Bryan Steele]

On Mon, Sep 23, 2019 at 12:20:40AM -0400, Bryan Steele wrote:
> On Sun, Sep 22, 2019 at 12:42:25PM -0700, Jonathan Thornburg wrote:
> > I'm trying to use syspatch to update a firewall (a PC Engines Alix)
> > running 6.5-stable/i386, but syspatch dies with an error message saying
> > that the patch file contains inappropriate filenames:
> > 
> > # uname -a
> > OpenBSD sodium.bkis-orchard.net 6.5 GENERIC#3 i386
> > # cat /etc/installurl
> > https://cdn.openbsd.org/pub/OpenBSD
> > # ls -gFlk /bsd*
> > -rwx--  2 root  wheel  13518991 Sep 10 18:23 /bsd*
> > -rwx--  2 root  wheel  13518991 Sep 10 18:23 /bsd.booted*
> > -rw---  1 root  wheel   8843776 May 12 16:43 /bsd.rd
> > # syspatch -l
> > 001_rip6cksum
> > 002_srtp
> > 004_bgpd
> > 005_libssl
> > 006_tcpsack
> > 007_smtpd
> > 010_frag6ecn
> > # syspatch -c
> > 011_expat
> > # syspatch 
> > Get/Verify syspatch65-011_expat.tgz 100% |**|   546 KB00:00 
> >
> > Installing patch 011_expat
> 
> 
> > tar: Pattern matching characters used in file names
> > tar: Use --wildcards to enable pattern matching, or --no-wildcards to 
> > suppress this warning
> > tar: @usr/share/relink/kernel/GENERIC.MP/.*@@g: Not found in archive
> > tar: Exiting with failure status due to previous errors
> > # 
> 
> That message is not from OpenBSD's tar(1) implementation.

There is a very good reason why GNU utilities installed from ports and
packages are prefixed with a 'g', so as to not conflict with utilites
from the base system. You changed the system-wide tar to GNU tar,
so you should expect there to be fallout.

> > Is this a known issue with this patch?  Is there an alternate way
> > (besides updating from source) to track -stable ?

Re: syspatch says 6.5 patch #011 (libexpat) is malformed

[Bryan Steele]

On Sun, Sep 22, 2019 at 12:42:25PM -0700, Jonathan Thornburg wrote:
> I'm trying to use syspatch to update a firewall (a PC Engines Alix)
> running 6.5-stable/i386, but syspatch dies with an error message saying
> that the patch file contains inappropriate filenames:
> 
> # uname -a
> OpenBSD sodium.bkis-orchard.net 6.5 GENERIC#3 i386
> # cat /etc/installurl
> https://cdn.openbsd.org/pub/OpenBSD
> # ls -gFlk /bsd*
> -rwx--  2 root  wheel  13518991 Sep 10 18:23 /bsd*
> -rwx--  2 root  wheel  13518991 Sep 10 18:23 /bsd.booted*
> -rw---  1 root  wheel   8843776 May 12 16:43 /bsd.rd
> # syspatch -l
> 001_rip6cksum
> 002_srtp
> 004_bgpd
> 005_libssl
> 006_tcpsack
> 007_smtpd
> 010_frag6ecn
> # syspatch -c
> 011_expat
> # syspatch 
> Get/Verify syspatch65-011_expat.tgz 100% |**|   546 KB00:00   
>  
> Installing patch 011_expat


> tar: Pattern matching characters used in file names
> tar: Use --wildcards to enable pattern matching, or --no-wildcards to 
> suppress this warning
> tar: @usr/share/relink/kernel/GENERIC.MP/.*@@g: Not found in archive
> tar: Exiting with failure status due to previous errors
> # 

That message is not from OpenBSD's tar(1) implementation.


> Is this a known issue with this patch?  Is there an alternate way
> (besides updating from source) to track -stable ?

Re: hardware assisted ethernet filtering

[Bryan Steele]

On Wed, Jul 31, 2019 at 11:48:24PM +0100, Tom Smyth wrote:
> Hi all,
> I was just wondering is there an ethtool equivalent in OpenBSD
> in particular Im interested in trying to harness some of the features
> in the xl710 and more advanced intel Ethernet chipsets where they
> allow a (limited) number of filter rules to be applied to a given network
> interface,
> example to drop high packet rate udp floods / amplification attacks
> #drop NTP responses (good and bad) inbound on interface  enp134s0f0
> ethtool --config-ntuple  enp134s0f0 flow-type udp4 src-port 123 action -1
> #drop DNS responses (good and bad) inbound on interface  enp134s0f0
> ethtool --config-ntuple  enp134s0f0 flow-type udp4 src-port 53 action -1
> 

Not hardware filter features, no. But you may be interested in the
bpf(4) "filter drop" feature extended recently by dlg@, and added to
tcpdump(8), it can be useful in cases where pf(4) cannot.

https://marc.info/?l=openbsd-cvs=155286777331151=2

https://man.openbsd.org/tcpdump#B

> the benefit of using the NICs ability to filter would be to reduce the
> effects
> of a high packet rate attack against the OpenBSD router
> what way would the openBSD devs think this should be done.
> extending ifconfig ?
> or a separate tool ?
> 
> It would be nice that the tools commands would be more like pf and less
> like eth tools (cause the syntax of ethtools sucks a little here)
> some downside risks of the  hardware filtering offload is that is not
> immediately obvious  to someone analysing the firewall rules that there is
> a hardware filter in place... perhaps this could be mitigated by some sort
> of
> 
> so it might be an idea to prepend a line comment to /etc.pf.conf to give
> the sysadmin a hint that there is a hardware filter in play before the
> firewall gets
> to see the packets...
> 
> any interest ? ideas? alternative view points on it ...
> Thanks for your time
> 
> Tom Smyth.
> 

Re: Lenovo V330-14 touchpad is not working at all

[Bryan Steele]

On Thu, Jun 13, 2019 at 11:38:24PM +0200, Tristan wrote:
> 
> 
> > On 13 Jun 2019, at 22:34, Tristan  wrote:
> > 
> > 
> > 
> >> On 13 Jun 2019, at 22:25, Bryan Steele  wrote:
> >> 
> >> On Thu, Jun 13, 2019 at 08:39:48PM +0200, Tristan wrote:
> >>> Hi there,
> >>> 
> >>> I got a new lenovo v330-14 it has an AMD Ryzen 5 2500U and Radeon RX Vega 
> >>> 8
> >>> and so was looking forward to using OpenBSD on this one. I'm currently 
> >>> running a
> >>> snapshot I grabbed today. To get the screen working I had to set 
> >>> machdep.allowaperture=2
> >>> unfortunately, but it works now and great as well. Video seems smooth. 
> >>> Audio works as well
> >> 
> >> You should avoid doing that -- see recent mailing lists post from Mark
> >> Kettenis.
> >> 
> >> https://marc.info/?l=openbsd-misc=156029398905090=2
> >> 
> >> For Vega graphics you need to recompile your kernel with the amdgpu
> >> driver lines uncommented, alternatively reinstall in UEFI mode to get the
> >> efifb(4) driver instead. This is probably better as amdgpu support is
> >> still a WIP.
> >> 
> > 
> > OK yes, I remember seeing something about it. Will give that a try. Much 
> > better then opening up :)
> > 
> > 
> >>> but the touchpad is not working at all. Wireless card does not work 
> >>> either, but using the 
> >>> ethernet port on it for now until I get an USB dongle for it.
> >>> 
> >>> wsconsctl | grep mouse gives me only:
> >>> mouse.type=ps2
> >>> 
> >>> In the dmesg output I can see only:
> >>> wsmouse0 at pms0 mux 0
> >> 
> >> Indeed, there's no pms(4) compatible touchpad on your machine. :-(
> >> 
> >>> "AMDI0010" at acpi0 not configured
> >>> "SYNA2B3F" at acpi0 not configured
> >> 
> >> And instead requires a driver to attach to the I2C HID controler. AMD's
> >> implementation seems to be somewhat compatible with dwiic(4) written by
> >> jcs@, however interrupts are not working-- hangs the machine. It does
> >> work if polling mode is forced.
> >> 
> >> This diff made the touchscreen and touchpad work be detected and mostly
> >> work on my Huawei MateBook D (AMD), however with the touchpad it seems
> >> to be break Tap-To-Drag. I don't know if this is a side effect of the
> >> drivers polling, unlike the pms(4) support-- which is working on that
> >> machine. We have no way to prefer one driver over other, which is why
> >> I haven't sent this diff yet.
> >> 
> >> Let me know if it works at all for you.
> > 
> > Much appreciated, will try this and report the outcome
> 
> Applying this patch gives me the following:
> 
> Hmm...  Looks like a unified diff to me...
> The text leading up to this was:
> --
> |Index: dwiic_acpi.c
> |===
> |RCS file: /cvs/src/sys/dev/acpi/dwiic_acpi.c,v
> |retrieving revision 1.8
> |diff -u -p -u -r1.8 dwiic_acpi.c
> |--- sys/dev/acpi/dwiic_acpi.c1 Jul 2018 11:37:11 -   1.8
> |+++ sys/dev/acpi/dwiic_acpi.c5 Jun 2019 00:25:29 -
> --
> Patching file dwiic_acpi.c using Plan A...
> patch:  malformed patch at line 9: };

Your mail client may have mangled it-- can you try grabbing it
from marc.info? If not, I'll send a direct link.

https://marc.info/?l=openbsd-misc=156045760827816=raw

Re: Lenovo V330-14 touchpad is not working at all

[Bryan Steele]

On Thu, Jun 13, 2019 at 08:39:48PM +0200, Tristan wrote:
> Hi there,
> 
> I got a new lenovo v330-14 it has an AMD Ryzen 5 2500U and Radeon RX Vega 8
> and so was looking forward to using OpenBSD on this one. I'm currently 
> running a
> snapshot I grabbed today. To get the screen working I had to set 
> machdep.allowaperture=2
> unfortunately, but it works now and great as well. Video seems smooth. Audio 
> works as well

You should avoid doing that -- see recent mailing lists post from Mark
Kettenis.

https://marc.info/?l=openbsd-misc=156029398905090=2

For Vega graphics you need to recompile your kernel with the amdgpu
driver lines uncommented, alternatively reinstall in UEFI mode to get the
efifb(4) driver instead. This is probably better as amdgpu support is
still a WIP.

> but the touchpad is not working at all. Wireless card does not work either, 
> but using the 
> ethernet port on it for now until I get an USB dongle for it.
> 
> wsconsctl | grep mouse gives me only:
> mouse.type=ps2
> 
> In the dmesg output I can see only:
> wsmouse0 at pms0 mux 0

Indeed, there's no pms(4) compatible touchpad on your machine. :-(

> "AMDI0010" at acpi0 not configured
> "SYNA2B3F" at acpi0 not configured

And instead requires a driver to attach to the I2C HID controler. AMD's
implementation seems to be somewhat compatible with dwiic(4) written by
jcs@, however interrupts are not working-- hangs the machine. It does
work if polling mode is forced.

This diff made the touchscreen and touchpad work be detected and mostly
work on my Huawei MateBook D (AMD), however with the touchpad it seems
to be break Tap-To-Drag. I don't know if this is a side effect of the
drivers polling, unlike the pms(4) support-- which is working on that
machine. We have no way to prefer one driver over other, which is why
I haven't sent this diff yet.

Let me know if it works at all for you.

-Bryan.

Index: dwiic_acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/dwiic_acpi.c,v
retrieving revision 1.8
diff -u -p -u -r1.8 dwiic_acpi.c
--- sys/dev/acpi/dwiic_acpi.c   1 Jul 2018 11:37:11 -   1.8
+++ sys/dev/acpi/dwiic_acpi.c   5 Jun 2019 00:25:29 -
@@ -66,6 +66,7 @@ struct cfattach dwiic_acpi_ca = {
 };
 
 const char *dwiic_hids[] = {
+   "AMDI0010",
"INT33C2",
"INT33C3",
"INT3432",
@@ -163,8 +164,11 @@ dwiic_acpi_attach(struct device *parent,
dwiic_enable(sc, 0);
dwiic_read(sc, DW_IC_CLR_INTR);
 
-   /* try to register interrupt with apic, but not fatal without it */
-   if (crs.irq_int > 0) {
+   /* XXX: AMD i2c controllers have a problem with interrupts enabled */
+   if (strcmp(sc->sc_hid, "AMDI0010") == 0)
+   sc->sc_poll = 1;
+   else if (crs.irq_int > 0) {
+   /* try to register interrupt with apic, not fatal without it */
printf(" irq %d", crs.irq_int);
 
sc->sc_ih = acpi_intr_establish(crs.irq_int, crs.irq_flags,
@@ -294,6 +298,9 @@ dwiic_acpi_bus_scan(struct device *iic, 
struct dwiic_softc *sc = (struct dwiic_softc *)aux;
 
sc->sc_iic = iic;
+   /* XXX: Workaround broken interrupts on AMD for i2c slave devices. */
+   if (strcmp(sc->sc_hid, "AMDI0010") == 0)
+   sc->sc_poll_ihidev = 1;
aml_find_node(sc->sc_devnode, "_HID", dwiic_acpi_found_hid, sc);
 }
 

Re: 6.5 : console font : no spleen?

[Bryan Steele]

On Mon, May 13, 2019 at 09:38:43AM +, Mayuresh Kathe wrote:
> i thought "spleen" was made the new default console
> font under 6.5+, it doesn't look like it's there on
> my fresh install under amd64?

It does if you have an EFI install (w/ efifb(4)), or have a graphics
device supported by inteldrm(4) or radeondrm(4).

(But you didn't send a dmesg, so ...)

Re: ws

[Bryan Steele]

On Sun, Apr 14, 2019 at 11:31:33AM +0900, Jerome Pinot wrote:
> Hi,
> 
> I'm curious to know what is the origin of the "w(s)" prefix we have
> on some OpenBSD specific places, like:
> - wscons
> -wsmoused
> - wskbd
> - wsrc
> - wobj
> etc
> 
> It seems to be a quite old practice and common with other BSDs.
> Anybody has the history for this?
> 
> Thanks!
> 
> -- 
> Jerome Pinot

'workstation console' at least sounds plausible.

https://www.netbsd.org/docs/guide/en/chap-cons.html

Re: amd64.iso KVM guest kernel panic pc=ffffffff811c303c (Opteron_G3 to Opteron_G5)

[Bryan Steele]

On Mon, Oct 22, 2018 at 09:49:54AM -0700, Mike Larkin wrote:
> On Mon, Oct 22, 2018 at 07:09:21AM +0300, snikolov wrote:
> > Dear All,
> > 
> > I have managed to configure and get the output of the serial console on
> > KVM and here is the output (with different CPU type only the name of
> > the CPU changes) :
> > ~~
> > >> OpenBSD/amd64 CDBOOT 3.40
> > boot> 
> > cannot open cd0a:/etc/random.seed: No such file or directory
> > booting cd0a:/6.4/amd64/bsd.rd: 354+1500160+3892040+0+598016
> > [372715+111+441072+293323]=0xa208a0
> > entry point at 0x1000158
> > Copyright (c) 1982, 1986, 1989, 1991, 1993
> > The Regents of the University of California.  All rights
> > reserved.
> > Copyright (c) 1995-2018 OpenBSD. All rights reserved.  https://www.Open
> > BSD.org
> > 
> > OpenBSD 6.4 (RAMDISK_CD) #348: Thu Oct 11 13:36:16 MDT 2018
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_C
> > D
> > real mem = 4278030336 (4079MB)
> > avail mem = 4144590848 (3952MB)
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6110 (11 entries)
> > bios0: vendor SeaBIOS version "1.11.0-2.el7" date 04/01/2014
> > bios0: Red Hat KVM
> > acpi0 at bios0: rev 0
> > acpi0: tables DSDT FACP APIC
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: AMD Opteron 63xx class CPU, 3992.09 MHz, 15-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,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2A
> > PIC,POPCNT,AES,XSAVE,AVX,F16C,HV,NXE,PAGE1GB,LONG,LAHF,ABM,SSE4A,MASSE,
> > 3DNOWP,XOP,FMA4,TBM
> > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
> > 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 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
> > fatal protection fault in supervisor mode
> > trap type 4 code 0 rip 811c303c cs 8 rflags 10202 cr2  0 cpl e
> > rsp 81a06a20
> > gsbase 0x81872ff0  kgsbase 0x0
> > panic: trap type 4, code=0, pc=811c303c
> > 
> > The operating system has halted.
> > Please press any key to reboot.
> > ~~
> > 
> > Should I report this as a bug ?
> > 
> > Best Regards,
> > Strahil Nikolov
> > 
> > 
> > On Sun, 2018-10-21 at 18:07 +0300, snikolov wrote:
> > > Hello All,
> > > 
> > > During install of install64.iso I experience a kernel panic during
> > > boot of the CD (pc=811c303c).
> > > install64.iso sha256sum is
> > > 81833b79e23dc0f961ac5fb34484bca66386deb3181ddb8236870fa4f488cdd2
> > > which
> > > matches https://cdn.openbsd.org/pub/OpenBSD/6.4/amd64/SHA256
> > > 
> > > I have tested with various CPUs on my RHEL 7.5 and it seems that
> > > Opteron_G3/G4/G5 and FX-8350 (host-passthrough) causes the
> > > panic,while
> > > Opteron_G1/G2 is OK. Booting install63.iso on the same VM is OK and I
> > > got the installer prompt.
> > > 
> > > Does anyone observes the same behaviour or it is only me ?
> > > 
> > > Best Regards,
> > > Strahil Nikolov
> > 
> 
> This appears to be related to the LFENCE serializing MSR change that went in
> during the last round of side channel analysis fixes:
> 
> 811c3037:   b9 29 10 01 c0  mov$0xc0011029,%ecx
> 811c303c:   0f 32   rdmsr
> 
> According to the commit, "This MSR is available on all AMD families >= 
> 10h...",
> and since yours is family 15h, it should work. Maybe that assumption was 
> wrong?
> 
> -ml

This appears to be another case of an outdated host kernel / KVM
combination. If you tried to boot OpenBSD on the bare hardware,
it wouldn't panic.

We're following AMD's recommendation here, as far as can tell.

https://marc.info/?l=openbsd-misc=153315801921789=2

-Bryan.

Re: 014_amdlfence.patch breaks OpenBSD VMs on AMD systems

[Bryan Steele]

On Wed, Aug 01, 2018 at 01:07:33PM -0700, Mike Larkin wrote:
> On Wed, Aug 01, 2018 at 12:14:59PM -0400, Bryan Steele wrote:
> > On Wed, Aug 01, 2018 at 11:27:26AM -0400, Bryan Steele wrote:
> > > On Wed, Aug 01, 2018 at 03:46:25PM +0200, Elmer Skjødt Henriksen wrote:
> > > > After installing the 014_amdlfence patch released yesterday for 6.3, my
> > > > OpenBSD VM crashes on boot. It's running under KVM on a Linux box 
> > > > (Ubuntu
> > > > 18.04 w/ kernel 4.15) on an AMD Ryzen 7 1700 (microcode 0x8001137).
> > > > I suppose this would also happen on vmm(4) and bhyve, however I don't 
> > > > have
> > > > any such AMD hosts available for testing.
> > > 
> > > Hi Elmer,
> > > 
> > > This was tested in vmm(4), which does work, unfortunately there was not
> > > extensive testing by in other virtualization software. The MSR that is
> > > being set here is only mentioned in AMDs whitepaper and I had no reason
> > > to believe any special consideration was needed for guest VMs on AMD
> > > processors.
> > > 
> > > > It occurs both using libvirt's "EPYC" CPU model and using 
> > > > "host-passthrough"
> > > > (i.e. no virtual CPU model), but the "core2duo" CPU model works fine.
> > > > 
> > > > I guess not many people are running OpenBSD as a VM, and even less on 
> > > > AMD
> > > > hardware. But still, a syspatch leaving the system unable to boot is
> > > > probably not a good thing. :)
> > > > 
> > > 
> > > Even so, I would like to apologize. This situation is unfortunate, and
> > > I'll try to work with other developers to find the best way forward.
> > > But, I regret I am only but an amateur magician.
> > > 
> > > -Bryan.
> > 
> > Actually, it looks like this is at least partially a KVM/QEMU bug. In
> > the meantime I guess the solution would be to do as you suggested and
> > set a different CPU model for now until Linux distros include a fix for
> > this.
> > 
> > https://lkml.org/lkml/2018/2/21/1202
> > 
> > Afterwards, on the OpenBSD side, it looks like one small change may be
> > required in addition..
> > 
> > -Bryan.
> > 
> > Index: sys/arch/amd64/amd64/identcpu.c
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
> > retrieving revision 1.95.2.2
> > diff -u -p -u -r1.95.2.2 identcpu.c
> > --- sys/arch/amd64/amd64/identcpu.c 30 Jul 2018 14:45:05 -  1.95.2.2
> > +++ sys/arch/amd64/amd64/identcpu.c 1 Aug 2018 16:09:50 -
> > @@ -650,8 +650,10 @@ identifycpu(struct cpu_info *ci)
> >  
> > msr = rdmsr(MSR_DE_CFG);
> >  #define DE_CFG_SERIALIZE_LFENCE(1 << 1)
> > -   msr |= DE_CFG_SERIALIZE_LFENCE;
> > -   wrmsr(MSR_DE_CFG, msr);
> > +   if ((msr & DE_CFG_SERIALIZE_LFENCE) == 0) {
> > +   msr |= DE_CFG_SERIALIZE_LFENCE;
> > +   wrmsr(MSR_DE_CFG, msr);
> > +   }
> > }
> > }
> >  
> > 
> 
> As expected, -current works properly on real AMD hardware. So my assumption
> about KVM doing something odd seems to be correct.
> 
> The issue should be reported upstream to the KVM folks. But if the diff above
> also fixes the issue (I didn't test because I cannot reproduce it), ok 
> mlarkin.
> 
> -ml

I committed a fix for the potential MSR write #GP bug to -current:

https://marc.info/?l=openbsd-cvs=153315564121057=2

Unfortunately, for the MSR read issue on older KVMs, it would require
adding additional code to determine if we're running under KVM, there's
really not much at all we can do here..

I agree these seem like KVM bugs, as this does not happen on real
hardware, and at least also not in OpenBSD vmm(4).

-Bryan.

Re: 014_amdlfence.patch breaks OpenBSD VMs on AMD systems

[Bryan Steele]

On Wed, Aug 01, 2018 at 11:27:26AM -0400, Bryan Steele wrote:
> On Wed, Aug 01, 2018 at 03:46:25PM +0200, Elmer Skjødt Henriksen wrote:
> > After installing the 014_amdlfence patch released yesterday for 6.3, my
> > OpenBSD VM crashes on boot. It's running under KVM on a Linux box (Ubuntu
> > 18.04 w/ kernel 4.15) on an AMD Ryzen 7 1700 (microcode 0x8001137).
> > I suppose this would also happen on vmm(4) and bhyve, however I don't have
> > any such AMD hosts available for testing.
> 
> Hi Elmer,
> 
> This was tested in vmm(4), which does work, unfortunately there was not
> extensive testing by in other virtualization software. The MSR that is
> being set here is only mentioned in AMDs whitepaper and I had no reason
> to believe any special consideration was needed for guest VMs on AMD
> processors.
> 
> > It occurs both using libvirt's "EPYC" CPU model and using "host-passthrough"
> > (i.e. no virtual CPU model), but the "core2duo" CPU model works fine.
> > 
> > I guess not many people are running OpenBSD as a VM, and even less on AMD
> > hardware. But still, a syspatch leaving the system unable to boot is
> > probably not a good thing. :)
> > 
> 
> Even so, I would like to apologize. This situation is unfortunate, and
> I'll try to work with other developers to find the best way forward.
> But, I regret I am only but an amateur magician.
> 
> -Bryan.

Actually, it looks like this is at least partially a KVM/QEMU bug. In
the meantime I guess the solution would be to do as you suggested and
set a different CPU model for now until Linux distros include a fix for
this.

https://lkml.org/lkml/2018/2/21/1202

Afterwards, on the OpenBSD side, it looks like one small change may be
required in addition..

-Bryan.

Index: sys/arch/amd64/amd64/identcpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
retrieving revision 1.95.2.2
diff -u -p -u -r1.95.2.2 identcpu.c
--- sys/arch/amd64/amd64/identcpu.c 30 Jul 2018 14:45:05 -  1.95.2.2
+++ sys/arch/amd64/amd64/identcpu.c 1 Aug 2018 16:09:50 -
@@ -650,8 +650,10 @@ identifycpu(struct cpu_info *ci)
 
msr = rdmsr(MSR_DE_CFG);
 #define DE_CFG_SERIALIZE_LFENCE(1 << 1)
-   msr |= DE_CFG_SERIALIZE_LFENCE;
-   wrmsr(MSR_DE_CFG, msr);
+   if ((msr & DE_CFG_SERIALIZE_LFENCE) == 0) {
+   msr |= DE_CFG_SERIALIZE_LFENCE;
+   wrmsr(MSR_DE_CFG, msr);
+   }
}
}
 

Re: 014_amdlfence.patch breaks OpenBSD VMs on AMD systems

[Bryan Steele]

On Wed, Aug 01, 2018 at 03:46:25PM +0200, Elmer Skjødt Henriksen wrote:
> After installing the 014_amdlfence patch released yesterday for 6.3, my
> OpenBSD VM crashes on boot. It's running under KVM on a Linux box (Ubuntu
> 18.04 w/ kernel 4.15) on an AMD Ryzen 7 1700 (microcode 0x8001137).
> I suppose this would also happen on vmm(4) and bhyve, however I don't have
> any such AMD hosts available for testing.

Hi Elmer,

This was tested in vmm(4), which does work, unfortunately there was not
extensive testing by in other virtualization software. The MSR that is
being set here is only mentioned in AMDs whitepaper and I had no reason
to believe any special consideration was needed for guest VMs on AMD
processors.

> It occurs both using libvirt's "EPYC" CPU model and using "host-passthrough"
> (i.e. no virtual CPU model), but the "core2duo" CPU model works fine.
> 
> I guess not many people are running OpenBSD as a VM, and even less on AMD
> hardware. But still, a syspatch leaving the system unable to boot is
> probably not a good thing. :)
> 

Even so, I would like to apologize. This situation is unfortunate, and
I'll try to work with other developers to find the best way forward.
But, I regret I am only but an amateur magician.

-Bryan.

> Kernel output:
> >> OpenBSD/amd64 BOOT 3.34
> boot>
> booting hd0a:/bsd: 8616075+2454544+262168+0+671744
> [646904+98+712056+493074]=0xd39630
> entry point at 0x1000158
> [ using 1852976 bytes of bsd ELF symbol table ]
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>   The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2018 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
> 
> OpenBSD 6.3 (GENERIC.MP) #7: Sun Jul 29 11:43:12 CEST 2018
> 
> r...@syspatch-63-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 2130546688 (2031MB)
> avail mem = 2058960896 (1963MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6880 (10 entries)
> bios0: vendor SeaBIOS version "1.10.2-1ubuntu1" date 04/01/2014
> bios0: QEMU Standard PC (i440FX + PIIX, 1996)
> acpi0 at bios0: rev 0
> acpi0: sleep states S5
> acpi0: tables DSDT FACP APIC
> 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: AMD Ryzen 7 1700 Eight-Core Processor, 2994.73 MHz
> 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,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
> 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 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
> kernel: protection fault trap, code=0
> Stopped at  identifycpu+0x7ad:  rdmsr
> ddb{0}> trace
> identifycpu(81a99ff0,80039400,81d40a58,8000210b9000
> ,81d40a60,12ad28e092a02002) at identifycpu+0x7ad
> cpu_attach(80023100,81d40a58,81a97040,80039400,
> 80039424,12ad28e092a02002) at cpu_attach+0x326
> config_attach(0,8001c744,8001c718,8001c744,81d4
> 0a38,813ce5d0) at config_attach+0x1d8
> acpimadt_attach(80020400,81d40b60,81aa84d0,8003
> 9b80,80039ba4,12ad28e092a02002) at acpimadt_attach+0x3be
> config_attach(81d40b60,80020400,80020470,800204
> 60,8001c700,81683350) at config_attach+0x1d8
> acpi_attach(80023180,81d40c50,81abf0d8,80020400
> ,80020424,12ad28e092a02002) at acpi_attach+0x5c1
> config_attach(8000210b7884,80023180,50,118,8000210b78b0,fff
> f81256180) at config_attach+0x1d8
> bios_attach(80023100,81d40d88,81aa2188,80023180
> ,800231a4,12ad28e092a02002) at bios_attach+0x636
> config_attach(81d40d88,80023100,81ab0bb0,800231
> 00,80023124,81456d90) at config_attach+0x1d8
> mainbus_attach(0,0,12ad28e092a02002,81d40db0,81d40e20,30001
> 0) at mainbus_attach+0x71
> config_attach(0,819a78b4,81ac8fd2,81d40e78,b28,0) at
> co
> nfig_attach+0x1d8
> config_rootfound(0,0,0,0,81d3a008,12ad28e092a02002) at
> config_rootfound
> +0xd3
> cpu_configure(0,0,8141440b,81d40ef0,0,0) at
> cpu_configure+0x1b
> main(0,0,0,12ad28e092a02002,814eff28,81d40f20) at main+0x4a8
> end trace frame: 0x0, count: -14
> ddb{0}> ps
>PID TID   PPID

Re: POWER9 hardware donation

[Bryan Steele]

On Tue, Jul 24, 2018 at 08:27:44PM +0200, Pascal de Kloe wrote:
> I'm offering my brand new IBM 9006-22P with two 16-core 2.9GHZ CPUs to
> the OpenBSD project for free. Who can make the hardware port happen?
> Serious attempts only.

Sounds like strings attached.

Re: Viewport for man.openbsd.org -- readability on phones

[Bryan Steele]

On Fri, May 18, 2018 at 02:47:29AM +0200, Ingo Schwarze wrote:
> Hi Aner,
> 
> Aner Perez wrote on Thu, May 17, 2018 at 06:32:44PM -0400:
> > On 05/17/2018 05:22 PM, x...@dr.com wrote:
> >> "Ingo Schwarze"  wrote:
> 
> >>> Absolutely not.
> >>> Mandoc output is not optimized for any device.
> >>>
> >>> Which elements or rules in the current HTML or CSS code
> >>> make you think it is optimized or it discriminates against
> >>> any device?
> 
> >> I don't know which element or rule is the problem, however
> >> if I delete mandoc.css the text does fill the screen.
> >> 
> >> I understand that what I am trying to do is not supported,
> >> so I'll do something else instead.
> 
> > First non-comment line of mandoc.css says:
> > 
> > html {  max-width: 100ex; }
> > 
> > Removing this line allows the use of the full browser width.
> 
> That is a very useful bit of information.
> Thanks for investigating and reporting it.
> 
> For testing purposes, i removed that line from
>   https://man.openbsd.org/mandoc.css
> 
> xcv@, could you check with your phone whether this solves
> your original issue?
> 
> > I'm sure that it was put there for a reason
> > (maybe to approximate the width of a terminal?).
> 
> Correct.  The original reason was that for -T ascii and -T utf8
> output, the default is -O width=78.  The reason for that is that
> it's conventional wisom in typography that readability of text
> suffers with excessive column width - even though some recent
> research raises doubts whether that is really true.  Either way,
> people tend to feel strongly about it.
> 
> I must say i never particularly liked that line in the CSS file.
> It always felt like fiddling with details that it might be better
> not to touch, given that display devices running browsers differ
> more than terminal emulators.  And here we are with a suspicion
> that it actually causes accessibility issues, even if the suspicion
> is still unconfirmed...
> 
> Depending on the feedback i get here with respect to how
>   https://man.openbsd.org/
> now looks, i shall consider deleting the offending line for good.
> 
> In general, i like the idea of making things better by *removing*
> harmful tweaks rather than adding new goo...
> 
> Yours,
>   Ingo

I needed to shift-refresh in chromium to see the changes reflected.

IMHO this looks far worse on desktop, stretching out the text to very
long lines.

Would rather not see this change become permanent.

-Bryan.

Re: Wondering if any of my hardware is working on -current

[Bryan Steele]

On Wed, Feb 07, 2018 at 09:03:09PM -0800, Chris Bennett wrote:
> Does any of my hardware work in -current?
> 
> OpenBSD 6.2 (GENERIC.MP) #2: Sun Dec 10 21:14:42 CET 2017
> 
> r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard, using wsdisplay0

The keyboard probably qwertz.

-Bryan.

Re: FOSDEM 2018 - Distributions Devroom Call for Participation

[Bryan Steele]

On Fri, Nov 03, 2017 at 08:57:52PM +0100, leo_...@volny.cz wrote:
> "Brian Exelbierd"  wrote:
> > Online at:
> > https://lists.fosdem.org/pipermail/fosdem/2017-October/002648.html
> > 
> > The Distributions devroom will take place Sunday 4 February 2018 at
> > FOSDEM, in Brussels, Belgium at the Université Libre de Bruxelles.
> 
> Interesting. What does this have to do with OpenBSD?

Quite a bit, actually. FOSDEM has had a BSD devroom track for years.

> And I'll sign it with my shit.
> 
> Stop spamming us, really.
> 
> --schaafuit.

I'd gladly welcome their mail if it means we'll never again receive 
any of yours.

Go away.

-Bryan.

Re: OT: protonmail mail body

[Bryan Steele]

On Wed, Jul 12, 2017 at 10:09:11AM +0200, Alarig Le Lay wrote:
> Hello,
> 
> It's just Base64 Content-Transfer-Encoding, and it's part of rfc2045.
> https://tools.ietf.org/html/rfc2045#section-6.8
> 
> So, the problem is on marc.info side. Moreover, it's working on
> mutt and on mail-archive:
> https://www.mail-archive.com/misc@openbsd.org/msg154853.html
> 
> -- 
> alarig

The mailing lists have very simple rules, messages should be in English,
plain/text and generally not be MIME. Attachments should be avoided and
sent inline, unless accepted by the list.

https://www.openbsd.org/mail.html

"ProtonMail" does not meet these requirements, by defalt. It's not just
marc.info archives, I suspect anyone using mail(1) is ignoring all of
your mails.

-Bryan.

Re: xwallpaper: a pledged wallpaper utility

[Bryan Steele]

On Sat, Apr 01, 2017 at 11:43:04AM +0200, Tobias Stoeckmann wrote:
> Hi misc@,
> 
> during the last weeks, I have reviewed quite some image tools out there
> because I needed one to set a wallpaper on my X server. I am not using
> a sophisticated desktop environment, so there was a need for a
> standalone tool. Let's keep it short: I have found and reported many
> bugs, and had to stop eventually after accepting that these libraries
> are either legacy/unmaintained or beyond repair (calling printf and free
> in signal handlers, anyone?).
> 
> To overcome this issue, I decided to write a simple utility, with the
> common OpenBSD focuses: Simplicity, security, doing exactly one thing.
> 
> The tool supports three file formats:
> 
> - JPEG; virtually everyone uses it
> - PNG; most popular lossless format
> - XPM; well, it's the most common agreement on X installations out there
> 
> I still want to be able to zoom into my pictures, so these modes of
> operations are supported:
> 
> - tile; tiles the image next to each other until screen/output is filled
> - center; centers the image
> - maximize; maximizes the image without cutting things off
> - stretch; destroys aspect ratio and fills the whole screen/output
> - zoom; maximizes the image and cuts things off, screen/output is filled
> 
> To get nice results, xwallpaper directly uses pixman for pixel
> operations. In case you don't know pixman: It is the direct foundation
> for the xorg-server to do pixel operations. No further dependencies!
> 
> Next to this, it avoids using the old (deprecated) X11 libraries. Found
> bugs in them as well and also got repeatedly told that they are not
> supposed to be used anymore either. So I decided to go with XCB.
> 
> Multi monitor setups are too regular by today to completely ignore them
> or using Xinerama with its weird numbering. Instead, it uses RandR if
> available, which makes it pretty nice to use. It even supports different
> modes (tiling, centering etc.) on different outputs! And if you are used
> to run xrandr, the syntax will be very familiar.
> 
> Last but not least, the tool is tightly pledged. We all know that file
> formats suck and they contain lots of bugs. For increased security, I
> have included pledge support right from the start. Before even one
> instruction of one of these image libraries is called, pledge is already
> down to "stdio". That's really tight! :)
> 
> All in all, it can be compiled with 0 dependencies with xenocara. Keep
> in mind that you just have XPM support then, though.
> 
> It's not in ports (yet?). It would be really great if you can give it a
> try, experiment a bit, and give me feedback. If you are an XCB expert
> and/or into code reviewing: Please do so! And if you have a big endian
> machine, it would be great if you can see if it works there as well.
> 
> The project as well as its release files can be found on GitHub:
> https://github.com/stoeckmann/xwallpaper
> 
> 
> Hope someone finds this tool useful, too.

It does what it says on the tin, really handy. Thanks for sharing.

> Tobias
>

-Bryan.

Re: pledging a portable program

[Bryan Steele]

On Mon, Jan 16, 2017 at 01:05:36PM -0600, Jordon wrote:
> What is the ???official" way to pledge(2) a portable program?
> 
> Put #ifdef __OpenBSD__ around the pledge call?
> 
> Make an #ifndef __OpenBSD__ block that defined the function to always return
> 0?
> 
> Something better?

pledge() itself serves as good annotation of the subsets of POSIX
used by a program, one option to avoid the #ifdef pollution is to
detect if it's available first, otherwise:

CPPFLAGS="$CPPFLAGS -D\"pledge(promises,paths)=0\""

Or similarly, in some header:

#define pledge(promises,paths) 0

-Bryan.

Re: Booting 6.0 on a Thinkpad Tablet 2, Almost

[Bryan Steele]

On Tue, Sep 13, 2016 at 06:59:11PM -0700, Lars Lehtonen wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I have a Lenovo Thinkpad 2 tablet that I'm attempting to install OpenBSD
> on. It originally shipped with Windows 8.
> 
> I've disabled Secure Boot in the BIOS, and the tablet makes it to the
> boot> prompt when started with a USB stick.
> 
> The boot process fails almost immediately. Is there a document I should
> be reading that explains the output, or have I come to the right place
> to report what happens?
> 
> Screenshot:
> https://imgur.com/a/zvyYV
> 
> - ---
> Lars Lehtonen

This device has a 32-bit processor according to the Intel Ark site, so
it's failing to load the OpenBSD/amd64 kernel.

The install60.fs/miniroot60.fs install media contains a 32-bit EFI boot
loader which is used going by your screenshot (BOOTIA32.EFI), but there
is no EFI support for OpenBSD/i386 currently.

A cursory Google search suggests there is no legacy BIOS support on the
Tablet 2, unfortunately..

-Bryan.

Re: audio codec RealTek ALC3263

[Bryan Steele]

On Sat, Sep 19, 2015 at 02:38:02PM +0200, Remi Locherer wrote:
> Hi
> 
> My Dell XPS 13 has a RealTek ALC3263 codec (according to the BIOS). In
> dmesg only the following shows up:
> 
> azalia0 at pci0 dev 3 function 0 "Intel Core 5G HD Audio" rev 0x09: msi
> azalia0: No codecs found

This device is related to unsupported HDMI audio output, there should
be a second azailia(4) device.

For example, my laptop has:

azalia1 at pci0 dev 27 function 0 "Intel 9 Series HD Audio" rev 0x03:
msi
azalia1: codecs: Realtek/0x0283
audio0 at azalia1

> Of course there is no audio :-(

It appears this function is disabled on your system, you might want
to check and see if there is a BIOS toggle, otherwise there's not
much else that can be done.

> Regards,
> Remi

-Bryan.

Re: audio codec RealTek ALC3263

[Bryan Steele]

On Sat, Sep 19, 2015 at 06:44:13PM -0400, Bryan Steele wrote:
> On Sat, Sep 19, 2015 at 02:38:02PM +0200, Remi Locherer wrote:
> > Hi
> > 
> > My Dell XPS 13 has a RealTek ALC3263 codec (according to the BIOS). In
> > dmesg only the following shows up:
> > 
> > azalia0 at pci0 dev 3 function 0 "Intel Core 5G HD Audio" rev 0x09: msi
> > azalia0: No codecs found
> 
> This device is related to unsupported HDMI audio output, there should
> be a second azailia(4) device.
> 
> For example, my laptop has:
> 
> azalia1 at pci0 dev 27 function 0 "Intel 9 Series HD Audio" rev 0x03:
> msi
> azalia1: codecs: Realtek/0x0283
> audio0 at azalia1
> 
> > Of course there is no audio :-(
> 
> It appears this function is disabled on your system, you might want
> to check and see if there is a BIOS toggle, otherwise there's not
> much else that can be done.
> 
> > Regards,
> > Remi
> 
> -Bryan.

Actually, there may be some funny ACPI interactions going on
that appear responsible for this.

Can you try the following diff?

Linux has this workaround for your model..
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=18d78b64fddc11eb336f01e46ad3303a3f55d039

Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.218
diff -u -p -u -r1.218 dsdt.c
--- src/sys/dev/acpi/dsdt.c 20 Aug 2015 20:50:10 -  1.218
+++ src/sys/dev/acpi/dsdt.c 19 Sep 2015 23:11:54 -
@@ -1457,7 +1457,7 @@ struct aml_defval {
struct aml_value**gval;
 } aml_defobj[] = {
{ "_OS_", AML_OBJTYPE_STRING, -1, osstring },
-   { "_REV", AML_OBJTYPE_INTEGER, 2, NULL },
+   { "_REV", AML_OBJTYPE_INTEGER, 5, NULL },
{ "_GL", AML_OBJTYPE_MUTEX, 1, NULL, _global_lock },
{ "_OSI", AML_OBJTYPE_METHOD, 1, aml_callosi },

Re: Typo in Upgrade Guide: 5.6 to 5.7

[Bryan Steele]

On Sat, Jul 25, 2015 at 06:10:30AM +0500, ?? ?? wrote:
 There is typo in Upgrade Guide: 5.6 to 5.7.
 
 In section Upgrade without the Install Kernel
 If using a single processor kernel
 
 cp bsd.rd bsd.mp /
 
 must be: cp bsd.rd /bsd.mp

No, that isn't a typo..

cp [-fip] [-R [-H | -L | -P]] source ... directory

Re: redhat - openbsd tcpdump

[Bryan Steele]

On Tue, Jun 16, 2015 at 11:25:46AM +0200, Frank Brodbeck wrote:
 Hi,
 
 is it possible to convert a pcap done with tcpdump under redhat to a 
 format I can read with tcpdump(8). At least I think the following error:
 
 tcpdump: unknown data link type 0x71
 
 is due to a format incompatibility.
 
 Frank.
 
 -- 

OpenBSD's tcpdump(8) does not support DLT_LINUX_SLL or
Linux cooked capture encapsulation format.

The tcpdump.org documentation about it is here:
http://www.tcpdump.org/linktypes.html
http://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html

If possible, try using -y EN10MB on Linux instead.

There is also support for this format in Wireshark, which is
in the ports tree, if recapturing isn't possible.

https://wiki.wireshark.org/SLL

-Bryan.

Re: hotmail rejecting messages relay=mx4.hotmail.com., dsn=5.1.2, stat=Host unknown (Unknown error: 275)

[Bryan Steele]

On Sat, May 23, 2015 at 07:31:27PM +0200, Matthieu Herrb wrote:
 On Sat, May 23, 2015 at 03:52:38PM +, Peter Fraser wrote:
  Any message sent to send mail seems to be rejected. The mx4 name changes, 
  but the rejection is always the same.
  It would be nice to know what the unknown error is
  
  Does anyone have any idea what is causing the problems
  
  I am currently using OpenBSD 5.5 with sendmail
  (I know I should update it but I haven't got around to it yet)
  
 hotmail recently added a 17th IP address to ther servers.
 There is a bug in libc's resolver that make it fail if there are more
 then 16 adresses for a name.
 
 This bug has been fixed in OpenBSD 5.7.
 I recently backported the commit to 5.5 for the very same reason
 (hotmail became unreachable) without trouble.
 
 http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/asr/gethostnamadr_async.c.diff?r1=1.34r2=1.35
 
 -- 
 Matthieu Herrb

I've committed a fix to 5.6 -stable, this bug was introduced when eric@
switched to the new async resolver (asr) in OpenBSD 5.4.

OpenBSD 5.6 and 5.7 are the two currently supported releases of OpenBSD,
so when possible, you should upgrade to 5.7 or at least 5.6-stable.

If you wish to prolong the inevitable, well, then you can do as Matthieu
suggests and backport this yourself.

:-)

-Bryan.

Re: Whatever happened to reop?

[Bryan Steele]

On Mon, Apr 27, 2015 at 05:34:43PM +0200, Christian Weisgerber wrote:
 A year ago, tedu@ published reop, which does everything you???d
 expect a PGP program to do.
 http://www.tedunangst.com/flak/post/reop
 
 There's GitHub site that's still active and there is ports/security/reop,
 maintained by jturner@, but generally it has been awfully silent.
 
 If anybody uses reop, they aren't exactly advertising it.  jturner@
 has a key and a Google search turned up bentley@'s key, but that's
 it.  If tedu@ has a key, I can't find it.
 
 Is reop stillborn?
 
 -- 
 Christian naddy Weisgerber  na...@mips.inka.de

reop(1) is pretty cool; I believe bmercer@ was working on the best way
to use it for signing mail, like PGP. I don't know if he posted a
writeup anywhere, but it would be interesting to read.

I also have a public key:

-BEGIN REOP PUBLIC KEY-
ident:brynet
RWRDU7CoNOy78+SNSm+/FcKYjYl9j5uLvDbVOStN4r2M82w7F2EtLixByi/u4oUx9gzRFIHCk9Hz
zgb+aJApmMoQ8XgZL6/SW5Lnfg==
-END REOP PUBLIC KEY-

..or http://brynet.biz.tm/reop-pubkey.txt

-Bryan.

Re: xkci recommendations

[Bryan Steele]

On Sat, Mar 21, 2015 at 08:47:27AM -0500, Ed Ahlsen-Girard wrote:
 I got a card to exploit the xkci support, and but it turned out to want
 a Windows driver and therefore doesn't work (don't buy Anker?? Uspeed
 USB 3.0 PCI-E Express Card with 4 USB 3.0 Ports and 5V 4-Pin Power
 Connector for Desktops [VL805 Chipset]).
 
 What are some USB 3 cards that DO work?
 
 
 -- 
 
 Edward Ahlsen-Girard
 Ft Walton Beach, FL

You didn't send a dmesg. xhci(4) support is new for 5.7.

Re: Libre/OpenSSL Patches in Latest amd64 Snapshot?

[Bryan Steele]

On Thu, Mar 19, 2015 at 08:53:57AM -0700, Scott Vanderbilt wrote:
 Given that the patches in tedu's announcement to the tech@ list are all
 time-stamped circa 18 Mar 2015 06:01:34 -, may I safely assume they are
 included in the amd64 snapshot dated 18-Mar-2015, the earliest file of which
 has a timestamp of 18:55?
 
 I need to bring my snapshots up-to-date anyway, and upgrading will probably
 be as fast or faster than re-building the libraries.
 
 Thanks.

No, assuming the contents of a snapshot seems like a particularly unsafe
thing to do.

-Bryan.

Re: Listening to a CD over the net

[Bryan Steele]

On Sun, Mar 08, 2015 at 01:57:05AM +0100, Christian Weisgerber wrote:
 Since I seem to be the only person using this feature (with the
 possible exception of ratchov@ himself), here's a periodic reminder
 that you can use sndio OVER THE NETWORK.
 
 Optical drives are kind of pass?, but I still keep a working USB
 one around.  I hooked it up to a convenient machine--an old sparc64
 with USB1.1, as it happens--slotted in an audio CD, then took my
 laptop and went into a different room.
 
 On the laptop I restarted sndiod with -L-, then ssh'ed to the machine
 with the CD and ran
 
 $ AUDIODEVICE=snd@laptop/0 cdio cdplay
 
 ... and that's it.  Music in my laptop headphones.
 
 Because we can.
 
 Sndio doesn't have any built-in authentication.  You can use ssh's
 port forwarding if you don't want to run it over the naked network.
 In my case, IPsec over the WPA2-secured wireless seemed enough.
 
 -- 
 Christian naddy Weisgerber  na...@mips.inka.de

This is cool, it seems ratchov@ included this feature in his Linux
port..

http://www.sndio.org/install.html

Something horrible like this lets me listen to music on a Linux
laptop (headphones), streamed from my OpenBSD desktop with no
speakers:

# ip6tables -A INPUT -p tcp -s fe80::/64 --dport 11025 -m state \
--state NEW -j ACCEPT
$ D_LIBRARY_PATH=. ./sndiod -L fe80::blah%wlan0

Because.. we.. can? :-)

-Bryan.

Re: OpenBSD projects

[Bryan Steele]

On Mon, Dec 29, 2014 at 12:14:11AM +0100, Ingo Schwarze wrote:
 Hi,
 
 as this request met quite a bit of interest, i have drafted
 a list at this *temporary* URI:
 
   http://mdocml.bsd.lv/openbsd_projects.html
 
 If developers want it, moving it to the OpenBSD web site would
 be fine with me.
 
 One thing that became obvious while drafting the list is that
 it is quite difficult to draw a line what to include and what
 to omit.  There are so many small things that were added and
 rewritten...  In case of doubt, i should probably include what
 any developer considers relevant.
 
 Information about what was ported to which other systems is
 still very sparse.
 
 I deliberately didn't include kernel space projects - both
 because these are by definition less portable and because
 i know much less about them than about userland.
 
 Yours,
   Ingo

AnonCVS is probably a worthy addition to the list. OpenBSD is the
first open source project to expose their repos publically. By this I
mean allowing read-only CVS access, history as it happened.

The functionally was added to GNU CVS by Theo and Chuck Cranor, and
prior to this work, you were lucky to get weekly source snapshots
with changelogs, which required manual reconstruction.

There's probably some historical significance to their work..

http://www.openbsd.org/papers/anoncvs-paper.pdf
http://www.openbsd.org/papers/anoncvs-slides.pdf

.. right? :-)

http://marc.info/?l=freebsd-hackersm=94346786026588w=2

-Bryan.

Re: Simple sendmail configuration

[Bryan Steele]

On Wed, Dec 24, 2014 at 09:59:27PM +0100, Ulrich Grassberger wrote:
 Hi,
 
 On 12/20/14 21:48, Vijay Sankar wrote:
 I would like to try to help -- but not sure that I have understood your
 problem correctly, so here is a guess.
 
 
 To clarify: Out of the box OpenBSD5.6 uses
 /usr/share/sendmail/cf/openbsd-localhost.mc as the config source for its
 mail system. This file defines LOCALHOST_ONLY and includes openbsd-proto.mc.
 So i am advised to compile a modified version of openbsd-proto.mc, right?

Except that, no, it doesn't. OpenBSD 5.6 uses smtpd(8) as the default
MTA and not sendmail. The only configuration file, save for aliases,
is /etc/mail/smtpd.conf.

 Cut short, my problem: Noone of OpenBSD helped the possibility, that
 someone on dial-up uses $mail.

What?

Please read smtpd.conf(5).

-Bryan.

Re: man -m not working with latest snapshot (Dec 20)

[Bryan Steele]

On Sat, Dec 20, 2014 at 04:10:05PM +0100, Alessandro DE LAURENZIS wrote:
 Greetings,
 
 just22@poseidon:[~] uname -a
 OpenBSD poseidon.atlantide.net 5.6 GENERIC.MP#714 amd64
 
 just22@poseidon:[~] type man
 man is hashed (/usr/bin/man)
 
 just22@poseidon:[~] man -m /home/just22/share/man/ man
 man: -m/home/just22/share/man/: Bad argument
 
 It seems a space is missing... Is it just me?
 
 -- 
 Alessandro DE LAURENZIS
 [mailto:just22@gmail.com]
 LinkedIn: http://it.linkedin.com/in/delaurenzis

schwarze@ switched the tree over to using the mandoc(1) implementation
of man(1). That probably just made it into snaps.

http://marc.info/?l=openbsd-cvsm=141857975006131w=2

-Bryan.

Re: Simple sendmail configuration

[Bryan Steele]

On Sat, Dec 20, 2014 at 05:23:06PM +0100, grasso...@versanet.de wrote:
 Hello,
 
 i installed OpenBSD5.6 on a laptop, because Windows is too insecure and
 commercial, and Linux is too radical. I am trying to use $mail for receiving 
 and
 sending e-mails over the remote e-mail account at my internet service 
 provider.
 With the default sendmail configuration, i can mail only locally. So i rewrote
 the config with masquerading but could not figure out how to link local users 
 to
 their remote mail accounts. And i made a mistake, for now local mailing is 
 also
 broken.
 
 I figure, that there are many people like me trying to hack a bit but 
 unwilling
 to get a master degree in Unix administration or to ask a Linux nerd. So I 
 would
 love to see a sample sendmail config for the stuff that is configured that
 easily in Thunderbird.
 
 Cheers,
 Uli Grassberger

OpenSMTPD is the new default MTA in 5.6, perhaps you would find that
easier to setup.. sendmail is moving to the ports tree for 5.7.

man 8 smtpd
man 8 smtpctl
man 5 smtpd.conf

-Bryan.

Re: OpenBSD Trademark Policy

[Bryan Steele]

On Sun, Dec 07, 2014 at 07:35:03PM +1100, Riley Baird wrote:
 I agree entirely. For this reason, I think it would be best to keep
 system internals (e.g. uname, includes, etc.) using the name OpenBSD
 with only the main user-visible parts changed to a new name.
 
 As for why I want to create the distro, I think that OpenBSD has
 excellent security, and I would like to create a version without the
 binary-only microcode included.

This is silly, all the firmware in /etc/firmware allows free
distribution and what isn't is installed via fw_update(1). You
can easily pkg_delete what you don't like.

If you're worried about scary evil Microcode, then you probably
shouldn't run a modern Intel or AMD machine, not including all the
firmware on flash or ROM, your BIOS likely loaded CPU microcode that
is almost entirely undocumented magic.

Hilarious..

-Bryan.

New hardware? Remember to send us your dmesg(8) and dumps!

[Bryan Steele]

If you have new hardware and would like to run OpenBSD on it, send in your
dmesgs and device dumps to dmesg@. Developers don't always have access to the
latest stuff, so it helps to know what works and what doesn't. Bug reports
go to the public bugs@ list.

Set $model to something specific, like the model of your machine. Also
check for typos below, mine or yours.

On OpenBSD (i386/amd64):
 $ sudo pkg_add usbutils
 $ mkdir $model; cd $model
 $ sudo acpidump -o $model
 $ for i in *; do b64encode $i $i  $model_dump.txt; done;
 $ dmesg  $model_dmesg.txt
 $ sudo pcidump -vxxx  $model_pcidump.txt
 $ sudo lsusb -v  $model_lsusb.txt

On Linux:
(..install pciutils usbutils sharutils acpidump)
 $ mkdir $model; cd $model
 $ sudo acpidump -o $model.hexdump
 $ acpixtract -a $model.hexdump  rm -f $model.hexdump
 $ dmesg  $model_lindmesg.txt
 $ for i in *; do uuencode -m $i $model.$i  $model_dump.txt; done;
 $ sudo lspci -vvxxx  $model_lspci.txt
 $ sudo lsusb -v  $model_lsusb.txt

Mail the resulting text files and your dmesg uncompressed and inline. A
descriptive subject with a few words in the message body are appreciated.

If you're in a position to donate, developers are always looking for
various things, including replacement laptops. Which helps to get
unsupported hardware into the hands of someone capable of fixing it.

http://www.openbsd.org/want.html
http://www.openbsd.org/donations.html

:-)

-Bryan.

Re: no keyboard during snapshot/amd64 installation on MacBookPro 11,1

[Bryan Steele]

On Wed, Oct 08, 2014 at 09:45:59PM +0200, Jind??ich Ka wrote:
 Hello list,
 
 Trying to install amd64 snapshot on MacBookPro 11,1. Boot process stops on 
 message: scsibus1at softraid0: 256 targets. After minute or more the install 
 program appear. But keyboard do not work. I tried to use another USB 
 keyboard, but its same. In pckbc(4) is written, that device flags should be 
 changed. I can use keyboard to go into boot_config, but in UKC I lost 
 keyboard too?it just blinking? no possibility to write even with external USB 
 keyboard.
 
 Thanks much for hint!
 Jindra

Some modern systems no longer emulate the legacy i8042 controller,
which is fine if there is a USB keyboard. Unfortunately, some newer
systems also lack the ehci(4) USB 2.0 controller and it's companions,
uhci(4) and ohci(4). Your Apple system may only include USB 3.0, or
an xHCI controller, which support is still being worked on.

The keyboard works at the boot prompt because boot(8) is using
BIOS services which are emulated by Apple's EFI firmware.

The future is encroaching, but we're catching up. Hold on! :-)

-Bryan.

Re: openbsdstore: enable javascript and buy something or gtfo

[Bryan Steele]

On Fri, Oct 03, 2014 at 10:09:36AM -0400, david...@ling.ohio-state.edu wrote:
 In my browser of choice, configured sensibly, this is all that can be
 seen at openbsdstore.com and openbsdeurope.com:
 
 | The OpenBSD Store
 
 | If you have JavaScript disabled you will not be able to order from
 | this site...
 
 And yes, it literally ends with an ellipsis.
 
 Strangely enough, this doesn't incline me to enable javascript.
 
 -wes

So, you visit an order page likely content on providing your billing
information and shipping address, but it's the use of Javascript that
sways your final decision to order?

Right...

-Bryan.