pkg_add exit status reporting

[Greg Steuck]

Hi Marc,

I was trying to automate an installation script around pkg_add
[0]
and noticed some cases where error reporting and/or documentation could be
improved. In particular, I want to have an "unattended" mode with a simple
way to check that all my package installations were successful. So far I
can't seem to do better than grepping pkg_add output. E.g.

ci-openbsd$ doas pkg_add foobar; echo $?
https://cloudflare.cdn.openbsd.org/pub/OpenBSD/6.4/packages/amd64/: no such
dir
Can't find foobar
0

Thanks
Greg

0)
https://github.com/google/syzkaller/blob/master/tools/create-openbsd-gce-ci.sh#L33

/bin/sh: ctags: Argument list too long (make tags)

[Greg Steuck]

Apparently the number files in kern is on the hairy edge of ARG_MAX on
openbsd 6.6-current amd64. If I run the same command in /usr/src, it works
making the problem easy to ignore until more files are added.

Should ctags grow an option to take a list of inputs from a file or is -a
smart enough to be used with xagrs to resolve this problem?

cd /home/greg/s/src/sys/kern; make tags
...
TDIR=`mktemp -d /tmp/_tagXX` || exit 1;  eval
"S=/home/greg/s/src/sys/arch/amd64/../.." &&  config -s
/home/greg/s/src/sys/arch/amd64/../.. -b ${TDIR}
/home/greg/s/src/sys/arch/amd64/conf/GENERIC.MP &&  eval "_arch=\"`make -V
_arch -f ${TDIR}/Makefile`\"" &&  eval "_mach=\"`make -V _mach -f
${TDIR}/Makefile`\"" &&  eval
"_machdir=\/home/greg/s/src/sys/arch/amd64/../../arch/${_mach}" &&  eval
"_archdir=\/home/greg/s/src/sys/arch/amd64/../../arch/${_arch}" &&  eval
"HFILES=\"`find /home/greg/s/src/sys/arch/amd64/../.. \( -path
/home/greg/s/src/sys/arch/amd64/../../'arch' -o -path
/home/greg/s/src/sys/arch/amd64/../../stand -o -path
/home/greg/s/src/sys/arch/amd64/../../lib/libsa -o -path
/home/greg/s/src/sys/arch/amd64/../..'/lib/libkern/arch' \) -prune -o -name
'*.h'; find ${_machdir} ${_archdir}
/home/greg/s/src/sys/arch/amd64/../../lib/libkern/arch/${_mach} \( -name
boot -o -name stand \) -prune -o -name '*.h'`\"" &&  eval "SFILES=\"`make
-V SFILES -f ${TDIR}/Makefile`\"" &&  eval "CFILES=\"`make -V CFILES -f
${TDIR}/Makefile`\"" &&  eval "AFILES=\"`make -V AFILES -f
${TDIR}/Makefile`\"" &&  ctags -wd -f /home/greg/s/src/sys/arch/amd64/tags
${CFILES} ${HFILES} &&  egrep "^[_A-Z]*ENTRY[_A-Z]*\(.*\)" ${SFILES}
${AFILES} |  sed "s;\\([^:]*\\):\\([^(]*\\)(\\([^, )]*\\)\\(.*\\);\\3 \\1
/^\\2(\\3\\4$/;"  >> /home/greg/s/src/sys/arch/amd64/tags &&  sort -o
/home/greg/s/src/sys/arch/amd64/tags /home/greg/s/src/sys/arch/amd64/tags
&&  rm -rf ${TDIR}
/bin/sh: ctags: Argument list too long
*** Error 1 in arch/amd64 (Makefile:42 'tags')

-- 
nest.cx is Gmail hosted, use PGP:
https://pgp.key-server.io/0x0B1542BD8DF5A1B0
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3  4D50 0B15 42BD 8DF5 A1B0

OK to GC net/hpodder?

[Greg Steuck]

The upstream has ceased hpodder development over 8 years ago. The port
has to be updated every time GHC is released and for all other
infrastructure changes. Even though we have enough patches for the
code to compile with GHC 8.10, there needs to be somebody who runs
this package to test it. Hence the proposal:

Can we remove net/hpodder?

Thanks
Greg
-- 
nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3  4D50 0B15 42BD 8DF5 A1B0

acpi interrupt storm on HP EliteBook 840 G1

[Greg Steuck]

I have a Hewlett-Packard HP EliteBook 840 G1 amd64 machine exhibiting
strange bouts of acpi0 interrupt storms. Depending on some
undetermined factor after a reboot the machine may come up with acpi0
interrupts firing 5k times per second. This boggles the machine
down. There's a sure fire way to avoid the problem by disabling acpi
in UKC. Naturally this makes the machine unable to sleep. I tried to
collect some obvious things, but happy to produce more upon request.

The contents of
   cp -R /var/db/acpi /tmp && iasl -d /tmp/acpi/*
are here: https://blackgnezdo.github.io/hp-elitebook-840.tgz

systat views:

2 users Load 1.31 1.49 1.40   hippy.nest.cx 10:13:13

memory totals (in KB)PAGING   SWAPPING Interrupts
   real   virtual free   in  out   in  out 5128 total
Active   426904426904 14395076   ops100 clock
All 1751896   1751896 31016684   pages  ipi
   5016 acpi0
Proc:r  d  s  wCsw   Trp   Sys   Int   Sof  Flt   forks inteldrm
 2   152 10051  1103   142  5027  1051   79   fkppw xhci0
  fksvm   1 em0
  18.6%Int   0.3%Spn   3.6%Sys   0.1%Usr  77.3%Idle   pwait azalia1
|||||||||||   relck  11 iwm0
|==   rlkok ehci0
  noram ahci0
Namei Sys-cacheProc-cacheNo-cache  19 ndcpy pckbc0
Calls hits%hits %miss   %   2 fltcp pckbc0
  101  101  10011 zfod
1 cow
Disks   sd0134558 fmin
seeks  179410 ftarg
xfers 1   itarg
speed   13K 12145 wired
  sec   0.0   pdfre
  pdscn   1 IPKTS
  pzidl   1 OPKTS

   2 users Load 1.38 1.48 1.40   hippy.nest.cx 10:14:29

 PID USERNAME CPU  20\ 40\
60\ 80\   100\
  74.80

   20461 rootacpi0  14.79 #
   56548 _x11Xorg   12.55 
   58356 gregchrome  3.27 #
   11548 gregemacs-26.3  2.64
   59152 gregxmobar  2.10
   48669 gregxmonad-x86_64-op2.05
   92413 gregxterm   1.42

dmesg:

OpenBSD 6.6 (GENERIC.MP) #370: Fri Oct 11 13:32:44 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17055608832 (16265MB)
avail mem = 16526012416 (15760MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbbe3f000 (33 entries)
bios0: vendor Hewlett-Packard version "L71 Ver. 01.20" date 07/28/2014
bios0: Hewlett-Packard HP EliteBook 840 G1
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG TCPA SSDT SSDT FPDT BGRT SSDT
SSDT SSDT SSDT SSDT ASF! DMAR
acpi0: wakeup devices LANC(S5) EHC1(S3) XHC_(S3) PCIB(S5) NIC_(S5)
RP04(S5) WNIC(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 1995.71 MHz, 06-45-01
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
tsc_timecounter_init: TSC skew=0 observed drift=0
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
TSC skew=-41
cpu1: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 1995.38 MHz, 06-45-01
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR

Re: Virtio fix for testing

[Greg Steuck]

Andrew Cagney  writes:

> Ref: https://marc.info/?l=openbsd-tech&m=168458764424059&w=2
> https://marc.info/?l=openbsd-misc&m=168071258109433&w=2

I see you found a similar issue and even a fix, good job. I believe
misc@ is a better place for such questions, so I'm cc'ing that.

> Is there a way to get an updated ISO or kernel with the fix?

Have you tried a snapshot? They are produced pretty regularly. The
project only has resource for the releases and snapshots. So if
you need a build with a back port, you are likely in the best
position to do that.

Thanks
Greg

Re: fido2 hardware key with PIN in browsers

[Greg Steuck]

rsyk...@disroot.org writes:

> Fabio Martins  wrote:
>> About your question, I believe you need to do a tail -f /var/log/messages
>
> this is what I see after pluging the key in the computer:
>
> Apr  7 19:02:06 odin /bsd: uhidev1 at uhub0 port 1 configuration 1 interface 
> 1 "GoTrust Idem Key" rev 2.00/1.11 addr 2
> Apr  7 19:02:06 odin /bsd: uhidev1: iclass 3/0
> Apr  7 19:02:06 odin /bsd: fido0 at uhidev1: input=64, output=64, feature=0
> Apr  7 19:02:06 odin /bsd: uhidev2 at uhub0 port 1 configuration 1 interface 
> 2 "GoTrust Idem Key" rev 2.00/1.11 addr 2
> Apr  7 19:02:06 odin /bsd: uhidev2: iclass 3/1
> Apr  7 19:02:06 odin /bsd: ukbd0 at uhidev2: 8 variable keys, 6 key codes
> Apr  7 19:02:06 odin /bsd: wskbd1 at ukbd0 mux 1
> Apr  7 19:02:06 odin /bsd: wskbd1: connecting to wsdisplay0
> Apr  7 19:02:06 odin /bsd: ugen0 at uhub0 port 1 configuration 1 "GoTrust 
> Idem Key" rev 2.00/1.11 addr 2

This is a good start of debugging effort. We can tell that the kernel is
happy enough with your device. Now you can go one step further and see
if ssh can use it.

If you are feeling ambitious about debugging this for chrome, try
running it with --enable-logging --v=1 and then look into
~/.config/chromium/chrome_debug.log for anything matching "fido".

You can then do the same on Linux and compare the outputs.

How much do you care about having this extra pin protection? I have been
using a few older FIDO devices for years now, so we know this much
works.

Thanks
Greg

Re: hw RNG on APUs

[Greg Steuck]

"Theo de Raadt"  writes:

> Maybe the driver is broken.
>
> Maybe it fails to initialize it.  Maybe in other cases, the BIOS initializes 
> it.
>
> So maybe on this machine, it is broken, but on other machines it is
> not broken.

Indeed, it works e.g. on this machine.

ccp0 at pci9 dev 0 function 2 "AMD 17h/1xh Crypto" rev 0x00
ccp: rng c61c2b7e
ccp: rng 95be2979
ccp: rng 9d99682f

Thanks
Greg

dhclient.leases.vio0: expecting colon delimited list of hex octets

[Greg Steuck]

I installed the Mar 21 snapshot on Google Compute Engine and noticed a
curious entry
on the system console:

starting network
vio0: /var/db/dhclient.leases.vio0 line 30: expecting colon delimited list
of hex octets.
vio0:   option domain-search c.
vio0: ^
vio0: bound to 10.128.0.237 from 169.254.169.254 (42:01:0a:80:00:01)

File contents:

openbsd$ doas cat /var/db/dhclient.leases.vio0
lease {
  fixed-address 10.0.2.15;
  next-server 10.0.2.2;
  option subnet-mask 255.255.255.0;
  option routers 10.0.2.2;
  option domain-name-servers 10.0.2.3;
  option dhcp-lease-time 86400;
  option dhcp-message-type 5;
  option dhcp-server-identifier 10.0.2.2;
  option dhcp-client-identifier 1:52:54:0:12:34:56;
  epoch 1553225096;
  renew 5 2019/03/22 15:24:56 UTC;
  rebind 6 2019/03/23 00:24:56 UTC;
  expire 6 2019/03/23 03:24:56 UTC;
}
lease {
  fixed-address 10.128.0.237;
  next-server 10.128.0.1;
  option subnet-mask 255.255.255.255;
  option routers 10.128.0.1;
  option domain-name-servers 169.254.169.254;
  option host-name "gnezdo-openbsd.c.syzkaller.internal";
  option domain-name "c.syzkaller.internal";
  option interface-mtu 1460;
  option ntp-servers 169.254.169.254;
  option dhcp-lease-time 86400;
  option dhcp-message-type 5;
  option dhcp-server-identifier 169.254.169.254;
  option dhcp-client-identifier 1:42:1:a:80:0:ed;
  option domain-search c.syzkaller.internal. google.internal.;
  option classless-static-routes 10.128.0.1/32 0.0.0.0, 0.0.0.0/0
10.128.0.1;
  epoch 1553227756;
  renew 5 2019/03/22 16:09:16 UTC;
  rebind 6 2019/03/23 01:09:16 UTC;
  expire 6 2019/03/23 04:09:16 UTC;
}


-- 
nest.cx is Gmail hosted, use PGP for anything private. Key:
http://goo.gl/6dMsr
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3  4D50 0B15 42BD 8DF5 A1B0

dhclient vio0 -> Segmentation fault

[Greg Steuck]

April 2 snapshot misbehaves badly on Google Compute Engine.

# dmesg | head
OpenBSD 6.5 (GENERIC.MP) #839: Tue Apr  2 20:38:19 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
# dhclient -v -d vio0
vio0: DHCPDISCOVER - interval 1
vio0: DHCPOFFER from 169.254.169.254 (42:01:0a:80:00:01)
Segmentation fault
# ls -l /sbin/dhclient

-r-xr-xr-x  1 root  bin  387640 Apr  2 19:24 /sbin/dhclient
# sha256 /sbin/dhclient

SHA256 (/sbin/dhclient) =
a3133d7c26d6bb77fab9b82738c68280863a67a6ef2141758725f502c3187cca

I don't know what source tree this corresponds to, but dhclient from this
revision works just fine:

commit 0459b7d7c4b6caf0847b615ddd2dc05e7ed59687 (HEAD, origin/master)
Author: benno 
Date:   Wed Apr 3 19:58:04 2019 +

YUL - Montreal Dorval International has been renamed Montreal-Pierre
Elliott Trudeau International on January 1, 2004.

Thanks
Greg

May 7 snap broken, ld.so: ld: can't load library 'libc++.so.2.2'

[Greg Steuck]

This is presumably already fixed by "Sync after libc++ bump", but in case
somebody else hits it...

The amd64 snapshot with this signature:
RWSZaRmt1LEQT+LPpgKcdukqjs3m1yYLE+J4zXB8YQ/iylbA3a/1IW31M6W9qKI+yIOxrbWghPno0HTSgbBfDyBZGwHWggiJBw4=

... produces these errors upon reboot into the newly installed system:
reordering libraries:ld.so: ld: can't load library 'libc++.so.2.2'
Killed
Abort trap
install: ld.so.test: No such file or directory
 failed.

Thanks
Greg

P.S.How useful would it be to automatically install amd64/i386 snapshots in
a vmm before declaring them worthy of publishing?

Is siteXX.tgz working in snapshots?

[Greg Steuck]

I have a script[1] which I run when "things change" to keep openbsd
syzbot current. Something changed between Apr 2 and now that made my
install procedure no longer execute install.site which I pack into
siteXX.tgz. I checked that siteXX is making it into the iso image that
I use for installation (the very bottom).

My basic question is: is siteXX working for other people in recent
snapshots (may 8)?

[1] 
https://github.com/google/syzkaller/blob/master/tools/create-openbsd-gce-ci.sh

Thanks
Greg

P.S. Complete log from installation attempt with the current snapshot:
%  ~/s/syzkaller/tools/create-openbsd-gce-ci.sh
install.site
etc/installurl
etc/rc.conf.local
etc/rc.local
etc/sysctl.conf
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000284258 s, 14.4 MB/s
Executing 'genisoimage -C 16,207120 -M /dev/fd/3 -l -R -graft-points
/6.5/amd64/site65.tgz=site65.tgz /auto_install.conf=auto_install.conf
/disklabel.template=disklabel.template /etc/boot.conf=boot.conf
/etc/random.seed=random.seed | builtin_dd
of=install65-amd64-patched.iso obs=32k seek=12945'
I: -input-charset not specified, using utf-8 (detected in locale settings)
Rock Ridge signatures found
Total translation table size: 0
Total rockridge attributes bytes: 2521
Total directory bytes: 8192
Path table size(bytes): 48
Max brk space used 0
207305 extents written (404 MB)
builtin_dd: 192*2KB out @ average infx1352KBps
install65-amd64-patched.iso: copying volume descriptor(s)
Formatting 'disk.raw', fmt=raw size=10737418240
spawn qemu-system-x86_64 -nographic -smp 2 -drive
if=virtio,file=disk.raw,format=raw -cdrom install65-amd64-patched.iso
-net nic,model=virtio -net user -boot once=d -m 4000 -enable-kvm
>> OpenBSD/amd64 CDBOOT 3.42
boot>
booting cd0a:/6.5/amd64/bsd.rd: 3695441+1532928+3893112+0+598016
[372212+128+451392+300364]=0xa59b08
entry point at 0x1001000
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2019 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.5-current (RAMDISK_CD) #14: Wed May  8 19:07:27 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 4177387520 (3983MB)
avail mem = 4046807040 (3859MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf68a0 (11 entries)
bios0: vendor SeaBIOS version "1.10.2-1" date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP APIC HPET
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: QEMU Virtual CPU version 2.5+, 2594.27 MHz, 06-06-03
cpu0: 
FPU,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,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: apic clock running at 1000MHz
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu at acpi0 not configured
"ACPI0006" at acpi0 not configured
"PNP0A03" at acpi0 not configured
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
pvbus0 at mainbus0: KVM
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
"Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured
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
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0:  ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
"Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured
vga1 at pci0 dev 2 function 0 "Bochs VGA" rev 0x02
vga1: aperture needed
wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio0: address 52:54:00:12:34:56
virtio0: msix shared
virtio1 at pci0 dev 4 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk0 at virtio1
scsibus1 at vioblk0: 2 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed
sd0: 10240MB, 512 bytes/sector, 20971520 sectors
virtio1: msix shared
isa0 at mainbus0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay1
softraid0 at root
scsibus2 at softraid0: 256 targets
root on rd0a swap on rd0b dump on rd0b
erase ^?, werase ^W, kill ^U, intr ^C, status ^T

Welcome to the OpenBSD/amd64 6.5 installation program.
(I)nsta

amd64 May 12 snapshot: extent_alloc_region: extent `ioport' (0x0 - 0xffff)

[Greg Steuck]

My snapshot installation routine[1] worked for May 11th snapshots and
breaks on May 12. I have a reason to suspect fowl play by QEMU (running on
Linux) because I can only trigger the error when the same instance that
just finished the install then fails to reboot into a newly installed
system. If I boot the image into a separate qemu instance, it boots
just fine.
[1]
https://github.com/google/syzkaller/blob/master/tools/create-openbsd-gce-ci.sh

Here's the panic fragment in case it helps somebody to diagnose the issue.
Because the whole script is running in expect(1) I can't easily get a more
complete log
extent_alloc_region: extent `ioport' (0x0 - 0x)
extent_alloc_region: start 0x397d08e8, end 0x397d08e80001
panic: extent_alloc_region: region lies outside extent
Stopped at  db_enter+0x10:  popq%rbp
TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
* 0  0  0 0x1  0x2000K swapper
db_enter(10,820078f0,282,8,81939c80,820078f0) at
db_enter+0x10
panic(81acd0d7,81acd0d7,397d08e8,81d69140,397d08e80001,2)
at panic+0x128
extent_alloc_region(81d69140,397d08e8,2,10,3ced4451d34a019e,16)
at extent_alloc_region+0x31b
bus_space_map(81c38c68,397d08e8,2,0,80021510,81c38c68)
at bus_space_map+0x96
acpi_map_pmregs(80021400,80021400,b296f5ec31720e1a,800022000850,80021400,80021478)
at acpi_map_pmregs+0x222
acpi_attach_common(80021400,f6850,8538a42a2600eff,80023180,82007c58,81d0d6b0)
at acpi_attach_common+0x1b5
config_attach(80023180,81d09848,82007c58,816f9240,75168f425d9711b9,50)
at config_attach+0x1ee
bios_attach(80023100,80023180,82007db8,80023100,e7cf2825b72b017d,80023100)
at bios_attach+0x71d
config_attach(80023100,81d043a0,82007db8,815dd580,75168f425da54253,82007db8)
at config_attach+0x1ee
mainbus_attach(0,80023100,0,0,7baefe45dce7d4a4,0) at
mainbus_attach+0x8

Complete log:
+ today=may12
+ IP=35.238.236.99
+ IMAGE=ci-openbsd-may12-root
+ INSTANCE=ci-openbsd
+ /usr/local/google/home/gnezdo/s/syzkaller/tools/create-openbsd-gce-ci.sh
  % Total% Received % Xferd  Average Speed   TimeTime Time
Current
 Dload  Upload   Total   SpentLeft
Speed
100  404M  100  404M0 0   107M  0  0:00:03  0:00:03 --:--:--
107M
install.site
etc/installurl
etc/rc.conf.local
etc/rc.local
etc/sysctl.conf
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000239465 s, 17.1 MB/s
Executing 'genisoimage -C 16,207248 -M /dev/fd/3 -l -R -graft-points
/6.5/amd64/site65.tgz=site65.tgz /auto_install.conf=auto_install.conf
/disklabel.template=disklabel.template /etc/boot.conf=boot.conf
/etc/random.seed=random.seed | builtin_dd of=install65-amd64-patched.iso
obs=32k seek=12953'
I: -input-charset not specified, using utf-8 (detected in locale settings)
Rock Ridge signatures found
Total translation table size: 0
Total rockridge attributes bytes: 2521
Total directory bytes: 8192
Path table size(bytes): 48
Max brk space used 0
207433 extents written (405 MB)
builtin_dd: 192*2KB out @ average infx1352KBps
install65-amd64-patched.iso: copying volume descriptor(s)
Formatting 'disk.raw', fmt=raw size=10737418240
spawn qemu-system-x86_64 -nographic -smp 2 -drive
if=virtio,file=disk.raw,format=raw -cdrom install65-amd64-patched.iso -net
nic,model=virtio -net user -boot once=d -m 4000 -enable-kvm
>> OpenBSD/amd64 CDBOOT 3.43
boot>
booting cd0a:/6.5/amd64/bsd.rd: 3695441+1532928+3889016+0+593920
[372197+128+451296+300417]=0xa57ad0
entry point at 0x81001000
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2019 OpenBSD. All rights reserved.
https://www.OpenBSD.org

OpenBSD 6.5-current (RAMDISK_CD) #17: Sun May 12 01:00:54 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 4177387520 (3983MB)
avail mem = 4046807040 (3859MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf68a0 (11 entries)
bios0: vendor SeaBIOS version "1.10.2-1" date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP APIC HPET
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: QEMU Virtual CPU version 2.5+, 2594.27 MHz, 06-06-03
cpu0:
FPU,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,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: apic clock running at 999MHz
cpu a

ftp: child terminated: signal 11

[Greg Steuck]

Looks like new ftp is not quite a drop-in replacement for the old one. My
install script[1] that worked for in May 12 snapshot is broken in May 15.
Most likely it's because of file:// url, but I haven't root-caused it.
[1]
https://github.com/google/syzkaller/blob/master/tools/create-openbsd-gce-ci.sh

The relevant section is:

Setting OpenBSD MBR partition to whole sd0...done.
URL to autopartitioning template for disklabel? [none]
file://disklabel.template
Fetching file://disklabel.template
ftp: child terminated: signal 11
No autopartitioning template found.
failed; check /tmp/ai/ai.log

Full transcript below.
% ~/s/syzkaller/tools/create-openbsd-gce-ci.sh
install.site
etc/installurl
etc/rc.conf.local
etc/rc.local
etc/sysctl.conf
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000326984 s, 12.5 MB/s
Executing 'genisoimage -C 16,207104 -M /dev/fd/3 -l -R -graft-points
/6.5/amd64/site65.tgz=site65.tgz /auto_install.conf=auto_install.conf
/disklabel.template=disklabel.template /etc/boot.conf=boot.conf
/etc/random.seed=random.seed | builtin_dd of=install65-amd64-patched.iso
obs=32k seek=12944'
I: -input-charset not specified, using utf-8 (detected in locale settings)
Rock Ridge signatures found
Total translation table size: 0
Total rockridge attributes bytes: 2521
Total directory bytes: 8192
Path table size(bytes): 48
Max brk space used 0
207289 extents written (404 MB)
builtin_dd: 192*2KB out @ average infx1352KBps
install65-amd64-patched.iso: copying volume descriptor(s)
Formatting 'disk.raw', fmt=raw size=10737418240
spawn qemu-system-x86_64 -nographic -smp 2 -drive
if=virtio,file=disk.raw,format=raw -cdrom install65-amd64-patched.iso -net
nic,model=virtio -net user -boot once=d -m 4000 -enable-kvm
>> OpenBSD/amd64 CDBOOT 3.43
boot>
booting cd0a:/6.5/amd64/bsd.rd: 3707729+1532928+3893112+0+598016
[372407+128+451320+300418]=0xa5cbb8
entry point at 0x81001000
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2019 OpenBSD. All rights reserved.
https://www.OpenBSD.org

OpenBSD 6.5-current (RAMDISK_CD) #22: Wed May 15 10:09:19 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 4177387520 (3983MB)
avail mem = 4046807040 (3859MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf68a0 (11 entries)
bios0: vendor SeaBIOS version "1.10.2-1" date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP APIC HPET
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: QEMU Virtual CPU version 2.5+, 2594.33 MHz, 06-06-03
cpu0:
FPU,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,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: apic clock running at 1000MHz
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu at acpi0 not configured
"ACPI0006" at acpi0 not configured
"PNP0A03" at acpi0 not configured
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
pvbus0 at mainbus0: KVM
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
"Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured
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
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0:  ATAPI 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
"Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured
vga1 at pci0 dev 2 function 0 "Bochs VGA" rev 0x02
vga1: aperture needed
wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio0: address 52:54:00:12:34:56
virtio0: msix shared
virtio1 at pci0 dev 4 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk0 at virtio1
scsibus1 at vioblk0: 2 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed
sd0: 10240MB, 512 bytes/sector, 20971520 sectors
virtio1: msix shared
isa0 at mainbus0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay1
softraid0 at root
scsibus2 at softraid0: 256 targets
root on rd0a swap on rd0b dump on rd0b
erase ^?, werase ^W, kill ^U, intr ^C, status ^T

Welcome to t

Re: ftp: child terminated: signal 11

[Greg Steuck]

>
> I am preparing a diff to not crash on an invalid URI. Meanwhile,
> IIRC, a valid file URI must one of file:/path, file:///path or
> file://hostname/path.  While omitting hostname, the slash should
> not be omitted. Does file:///disklabel.template work?
>

Thanks Sunil, file:///disklabel.template  does work.

Thanks
Greg
-- 
nest.cx is Gmail hosted, use PGP:
https://pgp.key-server.io/0x0B1542BD8DF5A1B0
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3  4D50 0B15 42BD 8DF5 A1B0

arpresolve: 10.128.0.1: route contains no arp information

[Greg Steuck]

Looks like I'm on a roll with finding snapshot bugs today. May 15 snapshot
(unlike May 11) experiences arp problems on Google Compute. Full dmesg way
below, but in general it appears dhclient is not getting what it wants and
keeps on asking.
# arp -an
Host Ethernet AddressNetif Expire
Flags
10.128.0.1   (incomplete) vio0 expired
10.128.15.23542:01:0a:80:0f:ebvio0 permanent l
# tcpdump -i vio0 -n -nnXSs 1000
tcpdump: listening on vio0, link-type EN10MB
12:02:30.438513 10.128.15.235.68 > 255.255.255.255.67:  xid:0x6e483c2c
vend-rfc1048 DHCP:REQUEST RQ:10.128.15.235
PR:SM+BR+TZ+121+DG+DN+119+NS+HN+BF+TFTP CID:1.66.1.10.128.15.235 [tos 0x10]
  : 4510 0148   8011 1f2b 0a80 0feb  E..H...+
  0010:   0044 0043 0134 d219 0101 0600  .D.C.4..
  0020: 6e48 3c2c        nH<,
  0030:     4201 0a80 0feb   B...
  0040:          
  0050:          
  0060:          
  0070:          
  0080:          
  0090:          
  00a0:          
  00b0:          
  00c0:          
  00d0:          
  00e0:          
  00f0:          
  0100:     6382 5363 3501 0332  c.Sc5..2
  0110: 040a 800f eb37 0b01 1c02 7903 0f77 060c  .7y..w..
  0120: 4342 3d07 0142 010a 800f ebff    CB=..B..
  0130:          
  0140:      

12:02:30.438647 169.254.169.254.67 > 10.128.15.235.68:  xid:0x6e483c2c
Y:10.128.15.235 S:10.128.0.1 G:10.128.0.1 vend-rfc1048 DHCP:ACK
SID:169.254.169.254 NS:169.254.169.254 LT:86400 DN:"c.syzkaller.internal"
T119:1.99.9.115.121.122.107.97.108.108.101.114.8.105.110.116.101.114.110.97.108.0.6.103.111.111.103.108.101.8.105.110.116.101.114.110.97.108.0
SM:255.255.255.255 DG:10.128.0.1 T121:8202,32768,256,0,0,2688,1 MTU:1460
HN:"ci-openbsd.c.syzkaller.internal" NTP:169.254.169.254 [ttl 1]
  : 4500 01a8   0111 49de a9fe a9fe  E.I.
  0010: 0a80 0feb 0043 0044 0194 6746 0201 0600  .C.D..gF
  0020: 6e48 3c2c     0a80 0feb  nH<,
  0030: 0a80 0001 0a80 0001 4201 0a80 0feb   B...
  0040:          
  0050:          
  0060:          
  0070:          
  0080:          
  0090:          
  00a0:          
  00b0:          
  00c0:          
  00d0:          
  00e0:          
  00f0:          
  0100:     6382 5363 3501 0536  c.Sc5..6
  0110: 04a9 fea9 fe06 04a9 fea9 fe33 0400 0151  ...3...Q
  0120: 800f 1463 2e73 797a 6b61 6c6c 6572 2e69  ...c.syzkaller.i
  0130: 6e74 6572 6e61 6c77 2701 6309 7379 7a6b  nternalw'.c.syzk
  0140: 616c 6c65 7208 696e 7465 726e 616c 0006  aller.internal..
  0150: 676f 6f67 6c65 0869 6e74 6572 6e61 6c00  google.internal.
  0160: 0104   0304 0a80 0001 790e 200a  y. .
  0170: 8000 0100   0a80 0001 1a02 05b4  
  0180: 0c1f 6369 2d6f 7065 6e62 7364 2e63 2e73  ..ci-openbsd.c.s
  0190: 797a 6b61 6c6c 6572 2e69 6e74 6572 6e61  yzkaller.interna
  01a0: 6c2a 04a9 fea9 feff  l*..

May 15 11:55:03 /bsd: OpenBSD 6.5-current (GENERIC.MP) #22: Wed May 15
10:02:36 MDT 2019
May 15 11:55:03 /bsd: dera...@amd64.openbsd.org:
/usr/src/sys/arch/amd64/compile/GENERIC.MP
May 15 11:55:03 /bsd: real mem = 8573145088 (8175MB)
May 15 11:55:03 /bsd: avail mem = 8303222784 (7918MB)
May 15 11:55:03 /bsd: mpath0 at root
May 15 11:55:03 /bsd: scsibus0 at mpath0: 256 targets
May 15 11:55:03 /bsd: mainbus0 at root
May 15 11:55:03 /bsd: bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xbcc0 (20
entries)
May 15 11:55:03 /bsd: bios0: vendor Google version "Google" date 01/01/2011
May 15 11:55:03 /bsd: bios0: Goo

dhclient unhappy on GCE (was: arpresolve: 10.128.0.1: route contains no arp information)

[Greg Steuck]

One would hope that https://marc.info/?l=openbsd-cvs&m=155812577615112
should fix my issue. Unfortunately while no longer looping, dhclient is
still not functioning on GCE. Here's what I see from the latest dhclient
vs. the one two revisions back which is working:

Broken (https://marc.info/?l=openbsd-cvs&m=155812577615112):
# ./dhclient.e8bab990985b2fbc3ce2b20fb1a70e38a89b1aa4 -d vio0
vio0: link up -> down
vio0: link down -> up
vio0: DHCPREQUEST to 255.255.255.255
vio0: DHCPACK from 169.254.169.254 (42:01:0a:80:00:01)
vio0: bound to 10.128.15.235 from 169.254.169.254 (42:01:0a:80:00:01)
vio0: DHCPREQUEST to 255.255.255.255
vio0 [priv]: add route 10.128.0.1/255.255.255.255 via 10.128.15.235: File
exists
vio0: DHCPACK from 169.254.169.254 (42:01:0a:80:00:01)
vio0: bound to 10.128.15.235 from 169.254.169.254 (42:01:0a:80:00:01)
vio0 [priv]: add route 10.128.0.1/255.255.255.255 via 10.128.15.235: File
exists
vio0 [priv]: add route 0.0.0.0/0.0.0.0 via 10.128.0.1: File exists

Working (https://marc.info/?l=openbsd-cvs&m=155750708324326)
# ./dhclient.c3ddc4b5b42eaa55a0d45cd2e871fadb439824f4 -d vio0
vio0: link up -> down
vio0: link down -> up
vio0: DHCPREQUEST to 255.255.255.255
vio0: DHCPACK from 169.254.169.254 (42:01:0a:80:00:01)
vio0: bound to 10.128.15.235 from 169.254.169.254 (42:01:0a:80:00:01)
vio0 [priv]: add route 10.128.0.1/255.255.255.255 via 10.128.15.235: File
exists


On Wed, May 15, 2019 at 12:07 PM Greg Steuck  wrote:

> Looks like I'm on a roll with finding snapshot bugs today. May 15 snapshot
> (unlike May 11) experiences arp problems on Google Compute. Full dmesg way
> below, but in general it appears dhclient is not getting what it wants and
> keeps on asking.
> # arp -an
> Host Ethernet AddressNetif Expire
> Flags
> 10.128.0.1   (incomplete) vio0 expired
> 10.128.15.23542:01:0a:80:0f:ebvio0 permanent l
> # tcpdump -i vio0 -n -nnXSs 1000
> tcpdump: listening on vio0, link-type EN10MB
> 12:02:30.438513 10.128.15.235.68 > 255.255.255.255.67:  xid:0x6e483c2c
> vend-rfc1048 DHCP:REQUEST RQ:10.128.15.235
> PR:SM+BR+TZ+121+DG+DN+119+NS+HN+BF+TFTP CID:1.66.1.10.128.15.235 [tos 0x10]
>   : 4510 0148   8011 1f2b 0a80 0feb  E..H...+
>   0010:   0044 0043 0134 d219 0101 0600  .D.C.4..
>   0020: 6e48 3c2c        nH<,
>   0030:     4201 0a80 0feb   B...
>   0040:          
>   0050:          
>   0060:          
>   0070:          
>   0080:          
>   0090:          
>   00a0:          
>   00b0:          
>   00c0:          
>   00d0:          
>   00e0:          
>   00f0:          
>   0100:     6382 5363 3501 0332  c.Sc5..2
>   0110: 040a 800f eb37 0b01 1c02 7903 0f77 060c  .7y..w..
>   0120: 4342 3d07 0142 010a 800f ebff    CB=..B..
>   0130:          
>   0140:      
>
> 12:02:30.438647 169.254.169.254.67 > 10.128.15.235.68:  xid:0x6e483c2c
> Y:10.128.15.235 S:10.128.0.1 G:10.128.0.1 vend-rfc1048 DHCP:ACK
> SID:169.254.169.254 NS:169.254.169.254 LT:86400 DN:"c.syzkaller.internal"
> T119:1.99.9.115.121.122.107.97.108.108.101.114.8.105.110.116.101.114.110.97.108.0.6.103.111.111.103.108.101.8.105.110.116.101.114.110.97.108.0
> SM:255.255.255.255 DG:10.128.0.1 T121:8202,32768,256,0,0,2688,1 MTU:1460
> HN:"ci-openbsd.c.syzkaller.internal" NTP:169.254.169.254 [ttl 1]
>   : 4500 01a8   0111 49de a9fe a9fe  E.I.
>   0010: 0a80 0feb 0043 0044 0194 6746 0201 0600  .C.D..gF
>   0020: 6e48 3c2c     0a80 0feb  nH<,
>   0030: 0a80 0001 0a80 0001 4201 0a80 0feb   B...
>   0040:          
>   0050:          
>   0060:          
>   0070:          
>   0080:          
>   0090:  0

Slow umass(4) on xhci(4)

[Greg Steuck]

I observe ~90x difference in bandwidth between Linux and OpenBSD on the
same hardware. The test case is reading big files from a USB-attached
flash drive[0].  The drive is plugged into a sole USB-c port on the back
of the motherboard.

On Linux I get about 900MB/s. OpenBSD shows ~10MB/s:

# dd if=/dev/sd1i of=/dev/null bs=1M count=1000  
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 95.617 secs (10966340 bytes/sec)

While a transfer is going, I can see consistently slow performance:

% iostat 1
  ttycd0 sd0 sd1
cpu
 tin tout  KB/t  t/sMB/s   KB/t  t/sMB/s   KB/t  t/sMB/s  us ni sy 
sp in id
   3  397  0.0000.00  19.43   781.47   4.00  3191.24   0  0  0  
0  0 99
   2  264  0.0000.00   0.0000.00   4.00 2679   10.47   0  0  0  
0  1 99
   0   88  0.0000.00   0.0000.00   4.00 2683   10.48   0  0  1  
0  0 99
   0   88  0.0000.00  16.0040.06   4.00 2683   10.48   0  0  1  
0  1 98
   0   89  0.0000.00   0.0000.00   4.00 2710   10.59   0  0  0  
0  0100
   0   87  0.0000.00   0.0000.00   4.00 2657   10.38   0  0  1  
0  1 98
   0   88  0.0000.00  64.0010.06   4.00 2683   10.48   0  0  0  
0  1 99

Is 4K/t typical/normal for USB drives?

systat shows consistent interrupt rate: 1006 xhci0

The devices details from usbdevs:

Controller /dev/usb0:
addr 01: 1022: AMD, xHCI root hub
 super speed, self powered, config 1, rev 1.00
 driver: uhub0
addr 02: 2109:2812 VIA Labs, Inc., USB2.0 Hub
 high speed, self powered, config 1, rev b.e0
 driver: uhub4
addr 03: 045e:0040 Microsoft, Microsoft 3-Button Mouse with IntelliEye(TM)
 low speed, power 100 mA, config 1, rev 3.00
 driver: uhidev0
addr 04: 29ea:0102 Kinesis, Advantage2 Keyboard
 full speed, power 100 mA, config 1, rev 1.00, iSerial 
 driver: uhidev1
 driver: uhidev2
 driver: uhidev3
addr 05: 0bda:8153 Realtek, USB 10/100/1000 LAN
 high speed, power 180 mA, config 1, rev 30.00, iSerial 0100
 driver: ure0
addr 06: 1050:0200 Yubico, Yubico Gnubby (gnubby1)
 full speed, power 30 mA, config 1, rev 0.97
 driver: uhidev4
addr 07: 1058:264f Western Digital, My Passport 264F
 super speed, power 224 mA, config 1, rev 20.07, iSerial
 driver: umass0
Controller /dev/usb1:
addr 01: 1022: AMD, xHCI root hub
 super speed, self powered, config 1, rev 1.00
 driver: uhub1
Controller /dev/usb2:
addr 01: 1022: AMD, xHCI root hub
 super speed, self powered, config 1, rev 1.00
 driver: uhub2
Controller /dev/usb3:
addr 01: 1022: AMD, xHCI root hub
 super speed, self powered, config 1, rev 1.00
 driver: uhub3

lsusb on Linux lists more stuff (followed by dmesgs at the end):

Bus 003 Device 003: ID 1058:264f Western Digital Technologies, Inc. My Passport 
264F
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.20
  bDeviceClass0 
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize0 9
  idVendor   0x1058 Western Digital Technologies, Inc.
  idProduct  0x264f 
  bcdDevice   20.07
  iManufacturer   2 Western Digital
  iProduct3 My Passport 264F
  iSerial 1 xxx
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x0079
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  896mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 80 Bulk-Only
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst  15
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0400  1x 1024 bytes
bInterval   0
bMaxBurst  15
Interface Descrip

Re: Slow umass(4) on xhci(4)

[Greg Steuck]

Mike Larkin  writes:

> On Sat, Jun 04, 2022 at 06:24:36PM -0700, Greg Steuck wrote:
>> I observe ~90x difference in bandwidth between Linux and OpenBSD on the
>> same hardware. The test case is reading big files from a USB-attached
>> flash drive[0].  The drive is plugged into a sole USB-c port on the back
>> of the motherboard.
>>
>> On Linux I get about 900MB/s. OpenBSD shows ~10MB/s:
>>
>> # dd if=/dev/sd1i of=/dev/null bs=1M count=1000
>> 1000+0 records in
>> 1000+0 records out
>> 1048576000 bytes transferred in 95.617 secs (10966340 bytes/sec)
>>
>
> does /dev/rsd1i make any difference?

I was somehow sure I tried rsd1i before, but now I can see a 17x
difference:

# dd if=/dev/rsd1i of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes transferred in 6.038 secs (173,659,835 bytes/sec)

Looking at iostat I see that using the "r" device causes transactions to
go up to 64KB/t.

Now, the real issue I had was with a slow ext2 file systems on the
drive.  I get 10MB/s reading the files and I observe 4KB/t in iostat.

So, yeah, I can get faster transfers which means xhci and umass are
capable of more than filesystems (at least ext2) extract out of them.

Thanks
Greg

Re: Slow umass(4) on xhci(4)

[Greg Steuck]

Greg Steuck  writes:

> I was somehow sure I tried rsd1i before, but now I can see a 17x
> difference:
>
> # dd if=/dev/rsd1i of=/dev/null bs=1M count=1000
> 1000+0 records in
> 1000+0 records out
> 1048576000 bytes transferred in 6.038 secs (173,659,835 bytes/sec)

I received an excellent suggestion off-list to do another experiment on
Linux to have a more comparable baseline.

Disabling uas reduces performance quite a bit, but it remains much
better than OpenBSD:

root@ubuntu:/mnt/stats# dd if=/dev/sda1 of=/dev/null bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (10 GB, 9.8 GiB) copied, 14.698 s, 713 MB/s


[0.00] Linux version 5.15.0-25-generic (buildd@ubuntu) (gcc (Ubuntu 
11.2.0-19ubuntu1) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #25-Ubuntu SMP 
Wed Mar 30 15:54:22 UTC 2022 (Ubuntu 5.15.0-25.25-generic 5.15.30)
[0.00] Command line: BOOT_IMAGE=/casper/vmlinuz 
file=/cdrom/preseed/ubuntu.seed maybe-ubiquity usb-storage.quirks=1058:264f:u 
splash ---
...
[1.829835] usb 3-1: new SuperSpeed Plus Gen 2x1 USB device number 2 using 
xhci_hcd
[1.850958] usb 3-1: New USB device found, idVendor=1058, idProduct=264f, 
bcdDevice=20.07
[1.851458] usb 3-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[1.851963] usb 3-1: Product: My Passport 264F
[1.852466] usb 3-1: Manufacturer: Western Digital
[1.852834] usb 3-1: SerialNumber: 
[1.876809] usb 3-1: UAS is ignored for this device, using usb-storage 
instead
[1.877364] usb-storage 3-1:1.0: USB Mass Storage device detected
[1.877962] usb-storage 3-1:1.0: Quirks match for vid 1058 pid 264f: 80
[1.878525] scsi host4: usb-storage 3-1:1.0

...
[2.798242] usb 2-5.2: new full-speed USB device number 4 using xhci_hcd
[2.902789] scsi 4:0:0:0: Direct-Access WD   My Passport 264F 2007 
PQ: 0 ANSI: 6
[2.902960] scsi 4:0:0:1: Enclosure WD   SES Device   2007 
PQ: 0 ANSI: 6
[2.904303] sd 4:0:0:0: Attached scsi generic sg1 type 0
[2.904549] scsi 4:0:0:1: Attached scsi generic sg2 type 13
[2.904579] sd 4:0:0:0: [sda] 3906963617 512-byte logical blocks: (2.00 
TB/1.82 TiB)
[2.904879] sd 4:0:0:0: [sda] Write Protect is off
[2.904883] sd 4:0:0:0: [sda] Mode Sense: 17 00 10 00
[2.905178] sd 4:0:0:0: [sda] No Caching mode page found
[2.905182] sd 4:0:0:0: [sda] Assuming drive cache: write through
[2.954970]  sda: sda1
[2.988933] sd 4:0:0:0: [sda] Attached SCSI disk
[3.053942] scsi 4:0:0:1: Failed to get diagnostic page 0x1
[3.053945] scsi 4:0:0:1: Failed to bind enclosure -19
[3.053966] ses 4:0:0:1: Attached Enclosure device
...
[4.407558] EXT4-fs (sda1): mounting ext2 file system using the ext4 
subsystem
[4.414707] EXT4-fs (sda1): mounted filesystem without journal. Opts: 
(null). Quota mode: none.

Re: AI-Driven Security Enhancements for OpenBSD Kernel

[Greg Steuck]

Alfredo Ortega  writes:

> Hi! Sorry if this is not the appropriate list to share openbsd-related
> projects (perhaps it was misc?)
>
> I want to inform you about this project about using LLMs to inject
> thousands of security checks into the OpenBSD kernel automatically.
>
> I'm sharing the first results at
> https://github.com/ortegaalfredo/openbsd-hardcore , where I used the
> automated tool to add thousands of additional security checks to the
> netinet/netinet6 stack of kernel 7.5. My plan is to continue this
> process with other subsystems, which will be largely automated, and to
> improve the tool so it can be used in other projects. The tool is not
> yet public but the idea is quite simple and can be implemented easily.
> This is a demonstration of the capabilities of LLMs as a
> code-refactoring tool.

I had an idea in this space which should have a much better ROI and
chances of acceptance. I'd start by grabbing a syzkaller report from
https://syzkaller.appspot.com/openbsd. Ideally you want something with a
reproducer. You should probably verify the repro still works.  Then feed
whatever data you find relevant into the magic box and ask it to give
you a fix for the problem. Some relevant pieces would include the panic
stack trace and the code around it.

Since you know it is a real problem and have a way to verify the
proposed solution, people will take you more seriously. When you have
the first real fix - do let us know, I'll personally be very excited to
look at the patches.

Thanks
Greg

P.S. As much as I'd love for you to focus on OpenBSD, you'll find many
more bugs to fix in other systems there.

Re: panic: rlphy_service: attempt to isolate phy

[Greg Steuck]

Alexander Nasonov wrote:
> > OpenBSD 4.6 panics on my 4 core amd64 HP workstation when I do
> > ifconfig -a.

Same here with 4.8-current i386 on HP Mini 311. I did not try the patch yet:

panic: rlphy_service: attempt to isolate phy
Stopped at  Debugger+0x4:   popl%ebp
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb> Debugger(d08bbf5c,dbd5ba08,d08c07e8,dbd5ba08,d240) at Debugger+0x4
panic(d08c07e8,0,d0c076a0,0,dbd5ba54) at panic+0x5d
rlphy_service(d1cc5000,d1bc12ac,4,dbd5ba4c,d1bc1030) at rlphy_service+0x13d
mii_down(d1bc12ac,d051ed07,d09f94c0,d0a06240,d1bc1000) at mii_down+0x26
nfe_stop(d1bc1030,0,c8,2,8020690c) at nfe_stop+0x35
nfe_init(d1bc1030,6,d0202fe5,2,3) at nfe_init+0x1d
nfe_ioctl(d1bc1030,8020690c,d1d9c000,20,0) at nfe_ioctl+0x149
in6_ifinit(d1bc1030,d1d9c000,1,d040ad09,50) at in6_ifinit+0xac
in6_update_ifa(d1bc1030,dbd5bc34,0,d040eded,d68ea754) at in6_update_ifa+0x272
in6_ifattach_linklocal(d1bc1030,0,cc771184,ab,50) at
in6_ifattach_linklocal+0x122
in6_ifattach(d1bc1030,0,dbd5bd8c,d03e0d85,dbd5bd7c) at in6_ifattach+0xf0
in6_if_up(d1bc1030,d089eb83,dbd5bdbc,d0418080,80206910) at in6_if_up+0x1b
if_up(d1bc1030,0,0,dbd5bdcc,d67816a4) at if_up+0x6f
ifioctl(d67816a4,80206910,dbd5be8c,d67868ac,20) at ifioctl+0xc9a
sys_ioctl(d67868ac,dbd5bf64,dbd5bf84,dbd5bfa8,d67868ac) at sys_ioctl+0x1b8
syscall() at syscall+0x2f0

dmesg and pcidump -vv below.

OpenBSD 4.8-current (GENERIC) #312: Tue Aug 31 21:59:22 MDT 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz ("GenuineIntel" 686-class) 1.61
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,A
CPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM
,MOVBE
real mem  = 936554496 (893MB)
avail mem = 911273984 (869MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 11/07/09, SMBIOS rev. 2.6 @ 0xe8310 (22
entries)
bios0: vendor Hewlett-Packard version "F.12" date 11/07/2009
bios0: Hewlett-Packard HP Mini 311-1000
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG HPET WDRT SLIC SSDT
acpi0: wakeup devices XVR0(S5) XVR1(S5) XVR2(S5) XVR5(S5) XVR6(S5) XVR7(S5)
XVR8(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) AZAD(S5) MAC0(S5) P2P_(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 133MHz
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 11, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 4
acpihpet0 at acpi0: 2500 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (P2P_)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2, C1, PSS
acpitz0 at acpi0acpitz0: TZ0_: failed to read _CRT
: no critical temperature defined
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: SLPB
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 not present
acpibtn2 at acpi0: PWRB
acpivideo0 at acpi0: IGPU
acpivout0 at acpivideo0: LCD0
bios0: ROM list: 0xc/0xec00
cpu0: Enhanced SpeedStep 1601 MHz: speeds: 1600, 1333, 1066, 800 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "NVIDIA MCP79 Host" rev 0xb1
"NVIDIA MCP79 Memory" rev 0xb1 at pci0 dev 0 function 1 not configured
pcib0 at pci0 dev 3 function 0 "NVIDIA MCP79 ISA" rev 0xb3
"NVIDIA MCP79 Memory" rev 0xb1 at pci0 dev 3 function 1 not configured
nviic0 at pci0 dev 3 function 2 "NVIDIA MCP79 SMBus" rev 0xb1
iic0 at nviic0
iic1 at nviic0
"NVIDIA MCP79 Memory" rev 0xb1 at pci0 dev 3 function 3 not configured
"NVIDIA MCP79 Co-processor" rev 0xb1 at pci0 dev 3 function 5 not configured
ohci0 at pci0 dev 4 function 0 "NVIDIA MCP79 USB" rev 0xb1: apic 4 int 5 (irq
5), version 1.0, legacy support
ehci0 at pci0 dev 4 function 1 "NVIDIA MCP79 USB" rev 0xb1: apic 4 int 7 (irq
7)
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "NVIDIA EHCI root hub" rev 2.00/1.00 addr 1
ohci1 at pci0 dev 6 function 0 "NVIDIA MCP79 USB" rev 0xb1: apic 4 int 11
(irq
11), version 1.0, legacy support
ehci1 at pci0 dev 6 function 1 "NVIDIA MCP79 USB" rev 0xb1: apic 4 int
11 (irq 11)
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "NVIDIA EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 8 function 0 "NVIDIA MCP79 HD Audio" rev 0xb1: apic 4 int
11
(irq 11)
azalia0: codecs: IDT 92HD81B1X, NVIDIA/0x0007, using IDT 92HD81B1X
audio0 at azalia0
ppb0 at pci0 dev 9 function 0 "NVIDIA MCP79 PCIE" rev 0xb1
pci1 at ppb0 bus 1
nfe0 at pci0 dev 10 function 0 "NVIDIA MCP79 LAN" rev 0xb1: apic 4 int 15
(irq
15), address 00:26:9e:db:7c:f5
rlphy0 at nfe0 phy 0: RTL8201L 10/100 PHY, rev. 1
rlphy1 at nfe0 phy 1: RTL8201L 10/100 PHY, rev. 1
rlphy2 at nfe0 phy 2: RTL8201L 10/100 PHY, rev. 1
rlphy3 at nfe0 phy 3: RTL8201L 10/100 PHY, rev. 1
rlphy4 at nfe0 phy 4: RTL8201L 10/100 PHY, rev. 1
rlphy5 at nfe0 phy 5: RTL8201L 10/

Wifi host AP thoughts

[Greg Steuck]

I was thinking of building a new wifi AP. The following is a stream of
thoughts on the subject. Any constructive suggestions are welcome.

Requirements:
  * Compatibility with Androids, Kindles, x86 Linux, OpenBSD wifi clients
  * Strong in-doors signal
  * Maximum control

Nice to have:
  * Combine the AP with the wired Ethernet OpenBSD router.
  * Low power & noise.

Complications:
  * A few wireless networks in nearby houses
  * OpenBSD AP capable devices have a CAVEAT: Host AP mode doesn't
support power saving.  Clients attempting to use power saving mode
may experience significant packet loss (disabling power saving on
the client will fix this).

Possible design:
  * OpenBSD host with 2 or more wired Ethernets
  * USB wifi device (free to switch host hardware)
  * External Hi-Gain antenna

Detailed implementation:
 * small i386 or armish machine for the host (Soekris?)
 * Hawking HWUG1 (rum(4)) ( http://goo.gl/ccd6Q )
 * Hawking HAI7SIP Antenna ( http://goo.gl/Axg7j )

Does anybody know if the CAVEAT above present a problem in real life for
the clients I listed?

Thanks
Greg
--
nest.cx is Gmail hosted, use PGP for anything private. Key:
http://tinyurl.com/ho8qg
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3  4D50 0B15 42BD 8DF5 A1B0