Re: physmem is 0 on this G5 macppc

2018-07-04 Thread Peter J. Philipp

Hi,

Can you let us know if the PowerMac11,2 has 4 DIMM slots or more?  If it 
is 4, then that means a DIMM can be 4 GB in size, which means my second 
update patch may fail and a 16 GB memory PowerMac may get the same 0 MB 
that my PowerMac7,3 is getting. The fix isn't trivial for that though 
and should probably be a second patch to make OF_* (openfirmware) 
routines be able to parse 64 bit entities), since a DIMM with 4 GB would 
wrap over again on an unsigned int and represent 0.


A dmesg would rock.

Regards,
-peter

On 07/05/18 04:03, Bryan Vyhmeister wrote:

On Thu, Jul 05, 2018 at 01:12:32AM +0200, Peter J. Philipp wrote:

According to wikipedia only the PowerMac11,2 supports up to 16 GB the rest
are all maximum 4GB, and I don't think the PowerMac11,2 is supported.

https://en.wikipedia.org/wiki/Power_Mac_G5

I'm not sure what the correct fix for this is but I wanted to set the
record straight. The PowerMac11,2 is supported but does have some DMA
issues with the SATA controller that can result in timeouts. All
OpenBSD/macppc machines are 32-bit or run in 32-bit mode like the
PowerMac G5. I believe that is why there are issues with large amounts
of memory. I have a PowerMac11,2 that has more than 8GB of memory (I
can't remember the exact amount) and it only uses 2GB as well under
OpenBSD. I also ran into some radeon(4) issues which I documented in
some older threads. I have not had time to get back to working on
anything further with my PowerMac G5 units but the model you have should
work reasonably well except for possible SATA issues.

Bryan




Re: physmem is 0 on this G5 macppc

2018-07-04 Thread Bryan Vyhmeister
On Thu, Jul 05, 2018 at 01:12:32AM +0200, Peter J. Philipp wrote:
> According to wikipedia only the PowerMac11,2 supports up to 16 GB the rest
> are all maximum 4GB, and I don't think the PowerMac11,2 is supported.
> 
> https://en.wikipedia.org/wiki/Power_Mac_G5

I'm not sure what the correct fix for this is but I wanted to set the
record straight. The PowerMac11,2 is supported but does have some DMA
issues with the SATA controller that can result in timeouts. All
OpenBSD/macppc machines are 32-bit or run in 32-bit mode like the
PowerMac G5. I believe that is why there are issues with large amounts
of memory. I have a PowerMac11,2 that has more than 8GB of memory (I
can't remember the exact amount) and it only uses 2GB as well under
OpenBSD. I also ran into some radeon(4) issues which I documented in
some older threads. I have not had time to get back to working on
anything further with my PowerMac G5 units but the model you have should
work reasonably well except for possible SATA issues.

Bryan



Re: physmem is 0 on this G5 macppc

2018-07-04 Thread Peter J. Philipp
On Wed, Jul 04, 2018 at 08:19:25PM +0200, Peter J. Philipp wrote:
> Hi again,
> 
> I came up with a fix, but not sure if it's correct.  The problem is that the
> physical memory here is 32 bits (paddr_t defined in 
> arch/powerpc/include/_types.h).
> So when we have 4 banks of 1 GB we end up with 2^32 which wraps around to 0 on
> the paddr_t so we report as 0MB.  My fix/workaround is simple I steal a page 
> upon atop() so that upon wrap-around at 4GB (selfish I know) some pages are 
> missing and it ends up below MAX of unsigned long.  
> 
> According to wikipedia only the PowerMac11,2 supports up to 16 GB the rest
> are all maximum 4GB, and I don't think the PowerMac11,2 is supported.
> 
> https://en.wikipedia.org/wiki/Power_Mac_G5
> 
> -peter

So sorry, it was erroneous... second attempt.  The first attempt wasn't safe 
for replies from OFW that were of size 0.  Also on my box the dmesg starts 
like so on this:
 
OpenBSD 6.3-current (GENERIC.MP) #8: Thu Jul  5 00:59:43 CEST 2018
p...@iota.centroid.eu:/usr/src/sys/arch/macppc/compile/GENERIC.MP
real mem = 4294950912 (4095MB)
avail mem = 2020478976 (1926MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root: model PowerMac7,3
cpu0 at mainbus0: 970FX (Revision 0x300): 1800 MHz
cpu1 at mainbus0: 970FX (Revision 0x300): 1800 MHz
mem0 at mainbus0

Also to show that a disklabel works it looks like so:

iota# disklabel -E wd0
Label editor (enter '?' for help at any prompt)
> A
> p
OpenBSD area: 4096-625142448; size: 625138352; free: 48
#size   offset  fstype [fsize bsize   cpg]
  a:  2097152 4096  4.2BSD   2048 16384 1 # /
  b:  8912864  2101248swap
  c:6251424480  unused
  d:  8388608 11014112  4.2BSD   2048 16384 1 # /tmp
  e: 25165760 19402720  4.2BSD   2048 16384 1 # /var
  f:  4194304 44568480  4.2BSD   2048 16384 1 # /usr
  g:  2097152 48762784  4.2BSD   2048 16384 1 # /usr/X11R6
  h: 20971520 50859936  4.2BSD   2048 16384 1 # /usr/local
  i: 20481   MSDOS
  j:  4194304 71831456  4.2BSD   2048 16384 1 # /usr/src
  k: 12582912 76025760  4.2BSD   2048 16384 1 # /usr/obj
  l:536533728 88608672  4.2BSD   4096 32768 1 # /home
> x
iota# 

Which would seem correct.

Regards,

-peter


Index: ofw_machdep.c
===
RCS file: /cvs/src/sys/arch/macppc/macppc/ofw_machdep.c,v
retrieving revision 1.56
diff -u -p -u -r1.56 ofw_machdep.c
--- ofw_machdep.c   22 Jul 2017 18:33:38 -  1.56
+++ ofw_machdep.c   4 Jul 2018 23:03:05 -
@@ -133,7 +133,7 @@ ofw_read_mem_regions(int phandle, int ad
 {
int nreg, navail;
int i, j;
-   uint physpages;
+   uint physpages, tmp;
 
switch (address_cells) {
default:
@@ -171,16 +171,22 @@ ofw_read_mem_regions(int phandle, int ad
case 2:
physpages = 0;
for (i = 0, j = 0; i < nreg; i++) {
-   if (OFmem64[i].size == 0)
+   tmp = OFmem64[i].size;
+   if (tmp == 0)
continue;
-   physpages += atop(OFmem64[i].size);
+   /* 
+* we steal a page here per memory bank if there is
+* some to steal, this will ultimately prevent 
+* wrapover to 0
+*/
+   physpages += (atop(tmp) ? atop(tmp) - 1 : 0);
if (OFmem64[i].start >= 1ULL << 32)
continue;
OFmem[j].start = OFmem64[i].start;
-   if (OFmem64[i].start + OFmem64[i].size >= 1ULL << 32)
+   if (OFmem64[i].start + tmp >= 1ULL << 32)
OFmem[j].size = (1ULL << 32) - OFmem64[i].start;
else
-   OFmem[j].size = OFmem64[i].size;
+   OFmem[j].size = tmp;
j++;
}
physmem = physpages;



Re: physmem is 0 on this G5 macppc

2018-07-04 Thread Peter J. Philipp
Hi again,

I came up with a fix, but not sure if it's correct.  The problem is that the
physical memory here is 32 bits (paddr_t defined in 
arch/powerpc/include/_types.h).
So when we have 4 banks of 1 GB we end up with 2^32 which wraps around to 0 on
the paddr_t so we report as 0MB.  My fix/workaround is simple I steal a page 
upon atop() so that upon wrap-around at 4GB (selfish I know) some pages are 
missing and it ends up below MAX of unsigned long.  

According to wikipedia only the PowerMac11,2 supports up to 16 GB the rest
are all maximum 4GB, and I don't think the PowerMac11,2 is supported.

https://en.wikipedia.org/wiki/Power_Mac_G5

-peter


Index: ofw_machdep.c
===
RCS file: /cvs/src/sys/arch/macppc/macppc/ofw_machdep.c,v
retrieving revision 1.56
diff -u -p -u -r1.56 ofw_machdep.c
--- ofw_machdep.c   22 Jul 2017 18:33:38 -  1.56
+++ ofw_machdep.c   4 Jul 2018 18:05:59 -
@@ -173,7 +173,8 @@ ofw_read_mem_regions(int phandle, int ad
for (i = 0, j = 0; i < nreg; i++) {
if (OFmem64[i].size == 0)
continue;
-   physpages += atop(OFmem64[i].size);
+   /* we steal a page here per memory bank, sorry */
+   physpages += (atop(OFmem64[i].size) - 1);
if (OFmem64[i].start >= 1ULL << 32)
continue;
OFmem[j].start = OFmem64[i].start;



Re: panic witness_warn

2018-07-04 Thread Kenneth R Westerback
On Wed, Jul 04, 2018 at 05:48:21PM +0200, Alexander Bluhm wrote:
> On Mon, Jun 04, 2018 at 08:53:49PM +0200, Alexander Bluhm wrote:
> > userret: returning with the following locks held:
> > exclusive rrwlock inode r = 0 (0xff023d492b48) locked @ 
> > /usr/src/sys/ufs/uf
> > s/ufs_vnops.c:1559
> > #0  witness_lock+0x254
> > #1  _rw_enter+0x29b
> > #2  _rrw_enter+0x3e
> > #3  VOP_LOCK+0x3d
> > #4  vn_lock+0x34
> > #5  vget+0xf7
> > #6  cache_lookup+0x217
> > #7  ufs_lookup+0x112
> > #8  VOP_LOOKUP+0x4f
> > #9  vfs_lookup+0x27e
> > #10 namei+0x226
> > #11 vn_open+0xcf
> > #12 doopenat+0x1af
> > #13 syscall+0x32a
> > #14 Xsyscall_untramp+0xc0
> > panic: witness_warn
> 
> We are leaking a vnode in namei().  The mount check was copied from
> NetBSD in 2003.  Later in 2006 they added a vput().  As we have not
> locked the directory vnode, call vrele() there.
> 
> ok?
> 
> bluhm
> 
> Index: kern/vfs_lookup.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/kern/vfs_lookup.c,v
> retrieving revision 1.69
> diff -u -p -r1.69 vfs_lookup.c
> --- kern/vfs_lookup.c 2 May 2018 02:24:56 -   1.69
> +++ kern/vfs_lookup.c 4 Jul 2018 10:44:48 -
> @@ -203,6 +203,8 @@ fail:
>   if (!dp->v_mount) {
>   /* Give up if the directory is no longer mounted */
>   pool_put(_pool, cnp->cn_pnbuf);
> + vrele(dp);
> + ndp->ni_vp = NULL;
>   return (ENOENT);
>   }
>   cnp->cn_nameptr = cnp->cn_pnbuf;
> 

Makes sense to me. ok krw@ fwiw.

 Ken



Re: panic witness_warn

2018-07-04 Thread Alexander Bluhm
On Mon, Jun 04, 2018 at 08:53:49PM +0200, Alexander Bluhm wrote:
> userret: returning with the following locks held:
> exclusive rrwlock inode r = 0 (0xff023d492b48) locked @ 
> /usr/src/sys/ufs/uf
> s/ufs_vnops.c:1559
> #0  witness_lock+0x254
> #1  _rw_enter+0x29b
> #2  _rrw_enter+0x3e
> #3  VOP_LOCK+0x3d
> #4  vn_lock+0x34
> #5  vget+0xf7
> #6  cache_lookup+0x217
> #7  ufs_lookup+0x112
> #8  VOP_LOOKUP+0x4f
> #9  vfs_lookup+0x27e
> #10 namei+0x226
> #11 vn_open+0xcf
> #12 doopenat+0x1af
> #13 syscall+0x32a
> #14 Xsyscall_untramp+0xc0
> panic: witness_warn

We are leaking a vnode in namei().  The mount check was copied from
NetBSD in 2003.  Later in 2006 they added a vput().  As we have not
locked the directory vnode, call vrele() there.

ok?

bluhm

Index: kern/vfs_lookup.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/kern/vfs_lookup.c,v
retrieving revision 1.69
diff -u -p -r1.69 vfs_lookup.c
--- kern/vfs_lookup.c   2 May 2018 02:24:56 -   1.69
+++ kern/vfs_lookup.c   4 Jul 2018 10:44:48 -
@@ -203,6 +203,8 @@ fail:
if (!dp->v_mount) {
/* Give up if the directory is no longer mounted */
pool_put(_pool, cnp->cn_pnbuf);
+   vrele(dp);
+   ndp->ni_vp = NULL;
return (ENOENT);
}
cnp->cn_nameptr = cnp->cn_pnbuf;



physmem is 0 on this G5 macppc

2018-07-04 Thread pjp
>Synopsis:  physmem is reported as 0 on this G5 macppc
>Category:  kernel
>Environment:
System  : OpenBSD 6.3
Details : OpenBSD 6.3-current (GENERIC.MP) #106: Tue Jul  3 
18:16:21 MDT 2018
 
dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC.MP

Architecture: OpenBSD.macppc
Machine : macppc
>Description:
As you can see from the dmesg the physmem is reported as 0MB.

real mem = 0 (0MB)
avail mem = 2020474880 (1926MB)

This has side-effects on disklabel in the installer as swap seems
to be shared with the /tmp filesystem probably due to disklabel
reading physmem per sysctl and doing multiplication.  What then
results is that /tmp partition is on wd0b with swap and does not
get mounted (device busy) as it is consumed by swap.  The root
cause of this is probably the kernel's memory detection.

>How-To-Repeat:
I bought this computer a few days ago for 185 EUR used, here is some
quick specs.

Apple G5 PowerMac, 2 x 1.8 GHz CPU, 4 GB RAM, 320 GB HD.

I'm gonna show you what I mean with disklabel by doing the 'A' auto
layout in disklabel -E:

> A
> p
OpenBSD area: 4096-625142448; size: 625138352; free: 48
#size   offset  fstype [fsize bsize   cpg]
  a:  2097152 4096  4.2BSD   2048 16384 1 # /
  b:  8388608  2101248  4.2BSD   2048 16384 1 # /tmp
  c:6251424480  unused
  d:  8388608 10489856  4.2BSD   2048 16384 1 # /var
  e:  4194304 18878464  4.2BSD   2048 16384 1 # /usr
  f:  2097152 23072768  4.2BSD   2048 16384 1 # /usr/X11R6
  g: 20971520 25169920  4.2BSD   2048 16384 1 # /usr/local
  h:  4194304 46141440  4.2BSD   2048 16384 1 # /usr/src
  i: 20481   MSDOS
  j: 12582912 50335744  4.2BSD   2048 16384 1 # /usr/obj
  k:562223744 62918656  4.2BSD   4096 32768 1 # /home
> x


>Fix:
I looked over /sys/arch/macppc/macppc/ofw_machdep.c and here is where
physmem gets seeded from physpages.  However I wasn't able to make out
why or how, and having slept on it I thought I'd write a bug report 
before going further.  I have also explored a little in openfirmware
and have made this photo:  http://centroid.eu/private/iota-memory.jpg

I don't know if it'll help though, and it is partially cut off.

I'm really happy about this purchase and hope there is a future for
G5 in the macppc port.  



dmesg:
OpenBSD 6.3-current (GENERIC.MP) #106: Tue Jul  3 18:16:21 MDT 2018
dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC.MP
real mem = 0 (0MB)
avail mem = 2020474880 (1926MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root: model PowerMac7,3
cpu0 at mainbus0: 970FX (Revision 0x300): 1800 MHz
cpu1 at mainbus0: 970FX (Revision 0x300): 1800 MHz
mem0 at mainbus0
spdmem0 at mem0: 1GB DDR SDRAM non-parity PC3200CL2.5
spdmem1 at mem0: 1GB DDR SDRAM non-parity PC3200CL2.5
spdmem2 at mem0: 1GB DDR SDRAM non-parity PC3200CL2.5
spdmem3 at mem0: 1GB DDR SDRAM non-parity PC3200CL2.5
memc0 at mainbus0: u3 rev 0xb3
kiic0 at memc0 offset 0xf8001000
iic0 at kiic0
lmtemp0 at iic0 addr 0x4a: ds1775
maxtmp0 at iic0 addr 0x4c: max6690
maxtmp1 at iic0 addr 0x4e: max6690
"cy28508" at iic0 addr 0x69 not configured
"cy2213" at iic0 addr 0x65 not configured
fcu0 at iic0 addr 0xaf
"pca9556" at iic0 addr 0x18 not configured
adc0 at iic0 addr 0x2c: ad7417
"24256" at iic0 addr 0x50 not configured
"pca9556" at iic0 addr 0x19 not configured
adc1 at iic0 addr 0x2d: ad7417
"24256" at iic0 addr 0x51 not configured
"dart" at memc0 offset 0xf8033000 not configured
"mpic" at memc0 offset 0xf804 not configured
mpcpcibr0 at mainbus0 pci: u3-agp
pci0 at mpcpcibr0 bus 0
pchb0 at pci0 dev 11 function 0 "Apple U3 AGP" rev 0x00
appleagp0 at pchb0
agp0 at appleagp0: aperture at 0x0, size 0x1000
vgafb0 at pci0 dev 16 function 0 "NVIDIA GeForce FX 5200 Ultra" rev 0xa1
wsdisplay0 at vgafb0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
ht0 at mainbus0: u3-ht, 6 devices
pci1 at ht0 bus 0
hpb0 at pci1 dev 1 function 0 "Apple U3" rev 0x00: 85 sources
pci2 at hpb0 bus 1
macobio0 at pci2 dev 7 function 0 "Apple K2 Macio" rev 0x60
openpic0 at macobio0 offset 0x4: version 0x4614 feature 770302 LE
macgpio0 at macobio0 offset 0x50
"pmu-interrupt" at macgpio0 offset 0x9 not configured
"programmer-switch" at macgpio0 offset 0x11 not configured
"modem-reset" at macgpio0 offset 0x1d not configured
"modem-power" at macgpio0 offset 0x1e not configured
"fcu-interrupt" at macgpio0 offset 0x15 not configured
"fcu-hw-reset" at macgpio0 offset 0x3a 

Re: certbot problem on sparc64 (probably python)

2018-07-04 Thread Stuart Henderson
On 2018/07/03 19:29, and...@grillet.co.uk wrote:
> >Synopsis:Unable to use certbot
> >Category:very annoying
> >Environment:
>   System  : OpenBSD 6.3
>   Details : OpenBSD 6.3 (GENERIC.MP) #486: Sat Mar 24 22:37:16 MDT 
> 2018
>
> dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.sparc64
>   Machine : sparc64
> >Description:
>   tried to run "certbot certonly [selection of options]" it always fails 
> in the same way
> From the log, it looks like bits are missing from the python install, 
> but I don't know
> python, and I could be wrong.
> >How-To-Repeat:
>   at the shell prompt type
> > certbot certonly --manual .
> >Fix:
>   Don't know (I do have a log created with script, but don't know how to 
> attach it)
> 
> 
> dmesg:
> OpenBSD 6.3 (GENERIC.MP) #486: Sat Mar 24 22:37:16 MDT 2018
> dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
> real mem = 1572864000 (1500MB)
> avail mem = 1524817920 (1454MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root: Sun Fire T200
> cpu0 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1000 MHz
> cpu1 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1000 MHz
> vbus0 at mainbus0
> "flashprom" at vbus0 not configured
> cbus0 at vbus0
> vdsk0 at cbus0 chan 0x2: ivec 0x4, 0x5
> scsibus1 at vdsk0: 2 targets
> sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed
> sd0: 6144MB, 512 bytes/sector, 12582912 sectors
> vdsk1 at cbus0 chan 0x3: ivec 0x6, 0x7
> scsibus2 at vdsk1: 2 targets
> sd1 at scsibus2 targ 0 lun 0:  SCSI3 0/direct fixed
> sd1: 2MB, 512 bytes/sector, 5760 sectors
> vnet0 at cbus0 chan 0x4: ivec 0x8, 0x9, address 00:14:4f:fa:57:21
> vcons0 at vbus0: ivec 0x111, console
> vrtc0 at vbus0
> vscsi0 at root
> scsibus3 at vscsi0: 256 targets
> softraid0 at root
> scsibus4 at softraid0: 256 targets
> bootpath: /virtual-devices@100,0/channel-devices@200,0/disk@0,0
> root on sd0a (31c2d1155bc86970.a) swap on sd0b dump on sd0b
> WARNING: / was not properly unmounted
> 
> usbdevs:
> usbdevs: no USB controllers found
> 
> pcidump:
> 
> acpidump:
> 

This is the same as https://github.com/certbot/certbot/issues/6019.
There's a problem with py-cryptography on OpenBSD on sparc64 (and likely
some other arches), between lack of time and lack of budget to power a
suitable machine I haven't been able to dig into it further yet .. if
anyone wants to look into it this is the starting point:

python2.7 -c 'from cryptography.hazmat.bindings._openssl import ffi, lib'

python2.7:/usr/local/lib/python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so:
 undefined symbol '__builtin_unreachable'




Re: certbot problem on sparc64 (probably python)

2018-07-04 Thread Daniel Jakots
On Tue, 3 Jul 2018 19:29:07 +0100 (BST), and...@grillet.co.uk wrote:

> From the log, it looks like bits are missing from the python
> install, but I don't know python, and I could be wrong.

Can you share the log (so we don't have to guess) please?


Cheers,
Daniel



2012 Mac Mini shows ~45% intr in CPU thread 0

2018-07-04 Thread pjp
>Synopsis:  2012 Mac Mini shows ~50% intr in CPU thread 0
>Category:  system
>Environment:
System  : OpenBSD 6.3
Details : OpenBSD 6.3-current (GENERIC.MP) #83: Mon Jul  2 10:36:36 
MDT 2018
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Architecture: OpenBSD.amd64
Machine : amd64
>Description:
A top output:
load averages:  0.06,  0.01,  0.00   earth.centroid.eu 08:43:19
44 processes: 43 idle, 1 on processor  up 13:05
CPU0:  0.0% user,  0.0% nice,  0.0% sys,  0.2% spin, 43.8% intr, 56.0% idle
CPU1:  0.0% user,  0.0% nice,  0.1% sys,  0.0% spin,  0.0% intr, 99.9% idle
CPU2:  0.0% user,  0.0% nice,  0.1% sys,  0.0% spin,  0.0% intr, 99.9% idle
CPU3:  0.0% user,  0.0% nice,  0.0% sys,  0.0% spin,  0.0% intr,  100% idle
CPU4:  0.0% user,  0.0% nice,  0.0% sys,  0.0% spin,  0.0% intr,  100% idle
CPU5:  0.0% user,  0.0% nice,  0.0% sys,  0.0% spin,  0.0% intr,  100% idle
CPU6:  0.0% user,  0.0% nice,  0.0% sys,  0.0% spin,  0.0% intr,  100% idle
CPU7:  0.0% user,  0.0% nice,  0.0% sys,  0.0% spin,  0.0% intr,  100% idle
Memory: Real: 71M/649M act/tot Free: 15G Cache: 443M Swap: 0K/16G

I have tried the following:
1) turn off pf, no change
2) turn off sndiod, no change (this mac mini is a sound server)
3) turn off all sorts of daemons, no change
4) turned off X11 and turned off inteldrm, no change

A vmstat -i output looks like this:

interrupt   total rate
irq0/clock   37889382  799
irq0/ipi   2045464
irq144/acpi010
irq145/inteldrm0385290
irq102/xhci0 95540
irq103/ehci0   230
irq176/azalia0 3573127
irq114/bge0519009   10
irq108/ehci1  2050
irq109/ahci0880771
Total39106638  825

Have you seen this?  Is it just my computer?  

Here is one more fact on this computer:

dual boots with refind between mac os high sierra and openbsd-current.

>How-To-Repeat:
unknown.
>Fix:
unknown.


dmesg:
OpenBSD 6.3-current (GENERIC.MP) #83: Mon Jul  2 10:36:36 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17063546880 (16273MB)
avail mem = 16537944064 (15771MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0x8ad12000 (83 entries)
bios0: vendor Apple Inc. version "MM61.88Z.010E.B00.180436" date 04/11/2018
bios0: Apple Inc. Macmini6,2
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT 
SSDT SSDT SSDT SSDT SSDT DMAR MCFG
acpi0: wakeup devices P0P2(S3) EC__(S3) GMUX(S3) HDEF(S3) RP01(S3) GIGE(S3) 
SDXC(S3) RP02(S3) ARPT(S3) RP03(S3) EHC1(S3) EHC2(S3) XHC1(S3)
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-3615QM CPU @ 2.30GHz, 2295.12 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz, 2294.79 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz, 2294.79 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,IBRS,IBPB,STIBP,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) i7-3615QM CPU @ 

certbot problem on sparc64 (probably python)

2018-07-04 Thread andrew
>Synopsis:  Unable to use certbot
>Category:  very annoying
>Environment:
System  : OpenBSD 6.3
Details : OpenBSD 6.3 (GENERIC.MP) #486: Sat Mar 24 22:37:16 MDT 
2018
 
dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP

Architecture: OpenBSD.sparc64
Machine : sparc64
>Description:
tried to run "certbot certonly [selection of options]" it always fails 
in the same way
From the log, it looks like bits are missing from the python install, 
but I don't know
python, and I could be wrong.
>How-To-Repeat:
at the shell prompt type
> certbot certonly --manual .
>Fix:
Don't know (I do have a log created with script, but don't know how to 
attach it)


dmesg:
OpenBSD 6.3 (GENERIC.MP) #486: Sat Mar 24 22:37:16 MDT 2018
dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC.MP
real mem = 1572864000 (1500MB)
avail mem = 1524817920 (1454MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root: Sun Fire T200
cpu0 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1000 MHz
cpu1 at mainbus0: SUNW,UltraSPARC-T1 (rev 0.0) @ 1000 MHz
vbus0 at mainbus0
"flashprom" at vbus0 not configured
cbus0 at vbus0
vdsk0 at cbus0 chan 0x2: ivec 0x4, 0x5
scsibus1 at vdsk0: 2 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct fixed
sd0: 6144MB, 512 bytes/sector, 12582912 sectors
vdsk1 at cbus0 chan 0x3: ivec 0x6, 0x7
scsibus2 at vdsk1: 2 targets
sd1 at scsibus2 targ 0 lun 0:  SCSI3 0/direct fixed
sd1: 2MB, 512 bytes/sector, 5760 sectors
vnet0 at cbus0 chan 0x4: ivec 0x8, 0x9, address 00:14:4f:fa:57:21
vcons0 at vbus0: ivec 0x111, console
vrtc0 at vbus0
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
scsibus4 at softraid0: 256 targets
bootpath: /virtual-devices@100,0/channel-devices@200,0/disk@0,0
root on sd0a (31c2d1155bc86970.a) swap on sd0b dump on sd0b
WARNING: / was not properly unmounted

usbdevs:
usbdevs: no USB controllers found

pcidump:

acpidump: