OpenSSL can't load library '

[Stefan Wollny]

Hi there! 
Having upgraded to last nights snapshots I am now faced with an only
partially working system: Neither is a cvs-update possible nor does X
start. I get the error message‎ at start"ssh-keygen: can't load library
'libcrypto.so.36.0'" and this library is required for cvs and X as well. 
What should I do???
TIA.
Best, STEFAN
Gesendet von meinem BlackBerry  10-Smartphone.

Re: OpenSSL can't load library '

[Stefan Wollny]

Thank you for the advice... I was afraid that this would be the way to go as 
for once I only have this machine at hand. Sigh...

My fault.

Anyway: I appreciate your gift ‎of creating such a fine OS and let the world 
participate!

Happy hacking, 
STEFAN 

Gesendet von meinem BlackBerry 10-Smartphone.
  Originalnachricht  
Von: Theo de Raadt
Gesendet: Montag, 14. September 2015 12:49
An: misc@openbsd.org; stefan.wol...@posteo.de
Betreff: Re: OpenSSL can't load library '

>Having upgraded to last nights snapshots I am now faced with an only
>partially working system: Neither is a cvs-update possible nor does X
>start. I get the error message��� at start"ssh-keygen: can't load library
>'libcrypto.so.36.0'" and this library is required for cvs and X as well. 
>What should I do???

Well, obviously you wait for the next snapshot.

During hackathons weeks, this can happen. They are an opportunity to move
forward quickly.

Toshiba Satellite Pro C660D - no brightness control

[Piotr Isajew]

I'm just trying out OpenBSD 5.7 on a Toshiba Satellite Pro C660D
laptop.

It seems to work almost perfect, but I'm not able to find any way
to control screen brightness. The display just stays at some
predefined level set during power on. 

Hotkey controls (Fn+F6, Fn+F7) do not work.

Command line controls do not work either. xbacklight says:
No outputs have backlight property

Is there anything I can do to get it working somehow? Thank you.

wsconsctl output:
keyboard.type=pc-xt
keyboard.bell.pitch=400
keyboard.bell.period=100
keyboard.bell.volume=50
keyboard.bell.pitch.default=400
keyboard.bell.period.default=100
keyboard.bell.volume.default=50
keyboard.repeat.del1=400
keyboard.repeat.deln=100
keyboard.repeat.del1.default=400
keyboard.repeat.deln.default=100
keyboard.ledstate=0
keyboard.encoding=pl
mouse.type=synaptics
mouse.rawmode=0
mouse.scale=1472,5692,1408,4680,0,66,102
display.type=radeondrm
display.emulations=vt100
display.screentypes=std
display.focus=4
display.screen_on=250
display.screen_off=0
display.vblank=off
display.kbdact=on
display.msact=on
display.outact=on


dmesg output:
OpenBSD 5.7 (GENERIC) #825: Sun Mar  8 10:59:14 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 6002049024 (5724MB)
avail mem = 5838393344 (5567MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xa7b22018 (22 entries)
bios0: vendor TOSHIBA version "1.40" date 02/22/2011
bios0: TOSHIBA Satellite Pro C660D
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIC HPET SSDT SSDT
acpi0: wakeup devices SBAZ(S4) P0PC(S4) GEC_(S4) PE20(S4) PE21(S4) PE22(S4)
PE23(S4) UHC1(S4) UHC2(S4) BR14(S4) PCE5(S4) LID_(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD E-240 Processor, 1496.68 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,MWAIT,SSSE3,CX16,POPCNT,
NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,
3DNOWP,IBS,SKINIT,ITSC
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 21, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 0
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318180 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PE20)
acpiprt2 at acpi0: bus -1 (PE21)
acpiprt3 at acpi0: bus -1 (PE22)
acpiprt4 at acpi0: bus -1 (PE23)
acpiprt5 at acpi0: bus -1 (PCE7)
acpiprt6 at acpi0: bus -1 (PCE8)
acpiprt7 at acpi0: bus -1 (BR14)
acpiprt8 at acpi0: bus 1 (PCE5)
acpiprt9 at acpi0: bus 2 (PCE6)
acpiec0 at acpi0
acpicpu0 at acpi0: C2, PSS
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT1 model "PA3817U-1BRS" serial 41167 type Li-Ion oem
"TOSHIBA"
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID_
acpivideo0 at acpi0: VGA_
cpu0: 1496 MHz: speeds: 1500 1200 750 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00
radeondrm0 at pci0 dev 1 function 0 "ATI Radeon HD 6310" rev 0x00
drm0 at radeondrm0
radeondrm0: msi
ppb0 at pci0 dev 5 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
re0 at pci1 dev 0 function 0 "Realtek 8101E" rev 0x05: RTL8105E (0x4080),
msi, address 1c:75:08:8a:2a:4d
rlphy0 at re0 phy 7: RTL8201E 10/100 PHY, rev. 2
ppb1 at pci0 dev 6 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi
pci2 at ppb1 bus 2
athn0 at pci2 dev 0 function 0 "Atheros AR9285" rev 0x01: apic 0 int 18
athn0: AR9285 rev 2 (1T1R), ROM rev 14, address 68:a3:c4:1c:99:c9
ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x40: apic 0 int 19,
AHCI 1.2
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct
fixed naa.539402b86706
sd0: 305245MB, 512 bytes/sector, 625142448 sectors
cd0 at scsibus1 targ 1 lun 0:  ATAPI 5/cdrom
removable
ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 0 int 18,
version 1.0, legacy support
ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00: apic 0 int 17
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "ATI EHCI root hub" rev 2.00/1.00 addr 1
ohci1 at pci0 dev 19 function 0 "ATI SB700 USB" rev 0x00: apic 0 int 18,
version 1.0, legacy support
ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00: apic 0 int 17
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 "ATI EHCI root hub" rev 2.00/1.00 addr 1
piixpm0 at pci0 dev 20 function 0 "ATI SBx00 SMBus" rev 0x42: polling
iic0 at piixpm0
spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM PC3-10600 SO-DIMM
spdmem1 at iic0 addr 0x52: 4GB DDR3 SDRAM PC3-8500 

Re: OpenSSL can't load library '

[Stefan Wollny]

‎I just noticed that X requests 'libssl.so.37.0' in order to create a
cookie. Thus this may be a different issue. 
Gesendet von meinem BlackBerry 10-Smartphone.

Von: Stefan WollnyGesendet: Montag, 14. September 2015 12:24An:
misc@openbsd.orgBetreff: OpenSSL can't load library '

Hi there! 
Having upgraded to last nights snapshots I am now faced with an only
partially working system: Neither is a cvs-update possible nor does X
start. I get the error message‎ at start"ssh-keygen: can't load library
'libcrypto.so.36.0'" and this library is required for cvs and X as well. 
What should I do???
TIA.
Best, STEFAN
Gesendet von meinem BlackBerry  10-Smartphone.

bootparamd and non-default subnet masks

[Marko Cupać]

Hi,

I am trying to implement diskless setup in VLAN-segmented network.
Server which hosts dhcpd, tftpd, nfsd, rarpd and bootparamd is on
10.30.7.38/27, on separate vlan from client which should be on
10.30.7.51/27.

Client obtains IP address, executes pxeboot and boots bsd from tftp
successfully. However, after that I get messages:
nfs_boot: using interface rl0, with revarp & bootparams
nfs_boot: client_addr=10.30.7.51
RPC timeout for server 10.255.255.255 (0xaff) prog 10

The problem is apparently with non-standard subnet mask for class A
network, but AFAIK rarpd does not supply subnet mask information. How
can I make this work?

Regards,
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: OpenSSL can't load library '

[Theo de Raadt]

>Having upgraded to last nights snapshots I am now faced with an only
>partially working system: Neither is a cvs-update possible nor does X
>start. I get the error message‎ at start"ssh-keygen: can't load library
>'libcrypto.so.36.0'" and this library is required for cvs and X as well. 
>What should I do???

Well, obviously you wait for the next snapshot.

During hackathons weeks, this can happen.  They are an opportunity to move
forward quickly.

Re: OpenSSL can't load library '

[Philip Guenther]

On Mon, Sep 14, 2015 at 12:24 PM, Stefan Wollny  wrote:
> Having upgraded to last nights snapshots I am now faced with an only
> partially working system: Neither is a cvs-update possible nor does X
> start. I get the error message‎ at start"ssh-keygen: can't load library
>d 'libcrypto.so.36.0'" and this library is required for cvs and X as well.
> What should I do???

Wait for the next snapshot (should be soon) and install it.  We're
just wrapping up a hackathon and you caught a snapshot built in the
middle of a library version bump.


Philip Guenther

Re: requesting help working around boot failures with supermicro atom board

[Kurt Mosiejczuk]

On Sat, Sep 12, 2015 at 03:51:36PM +, Dewey Hylton wrote:

> the only real differences i see are:
> 1) bios revision
> 2) secondary disk attached to different sata port
> 3) sensors only present on working machine

I've had this issue with the same systems.  Never guessed it would be OpenBSD
specific.  What I've found to make it stop happening is pulling the board
out and redoing the thermal paste for the CPU heatsink.  I had found 
some reference indicating that the alarm I got might be because of overheating.

The difference between the boxes may be the attention to detail the factory
worker who put it together had that day.

Hearing that Linux doesn't trip it, I'm wondering if it's an ACPI difference
between OpenBSD and Linux.  Perhaps OpenBSD runs the CPU hotter before
turning it back over to the BIOS on reboot?

--Kurt

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Patrick Dohman  comcast.net> writes:

> 
> Any thermal settings in the bios? CPU performance, Fan Speed etc..
> 
> Does the fan idle correctly? Often intel chipsets will throttle the fan
during a bios test.
> 
> Perhaps ACPI is not routing an interrupt??

Not much is available to be tweaked in this particular setup, though i do
have the options of acpi 1, 2, 3. changing those doesn't appear to result in
any difference.

regarding ACPI not routing an interrupt ... can you be more specific? is
there some way i could test this?

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Kurt Mosiejczuk  se.rit.edu> writes:

> 
> On Sat, Sep 12, 2015 at 03:51:36PM +, Dewey Hylton wrote:
> 
> > the only real differences i see are:
> > 1) bios revision
> > 2) secondary disk attached to different sata port
> > 3) sensors only present on working machine
> 
> I've had this issue with the same systems.  Never guessed it would be OpenBSD
> specific.  What I've found to make it stop happening is pulling the board
> out and redoing the thermal paste for the CPU heatsink.  I had found 
> some reference indicating that the alarm I got might be because of
overheating.
> 
> The difference between the boxes may be the attention to detail the factory
> worker who put it together had that day.
> 
> Hearing that Linux doesn't trip it, I'm wondering if it's an ACPI difference
> between OpenBSD and Linux.  Perhaps OpenBSD runs the CPU hotter before
> turning it back over to the BIOS on reboot?
> 
> --Kurt

this is great information; thanks. any idea where the temperature reference
can be found?

i may be able to log the cpu temperature in both operating systems in order
to compare ...

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Kurt Mosiejczuk  se.rit.edu> writes:

> 
> On Mon, Sep 14, 2015 at 05:15:01PM +, Dewey Hylton wrote:
> 
> > > I've had this issue with the same systems.  Never guessed it would
> > > be OpenBSD specific.  What I've found to make it stop happening is
> > > pulling the board out and redoing the thermal paste for the CPU
> > > heatsink.  I had found some reference indicating that the alarm I
> > > got might be because of overheating.
> 
> > > The difference between the boxes may be the attention to detail the
> > > factory worker who put it together had that day.
> 
> > > Hearing that Linux doesn't trip it, I'm wondering if it's an ACPI
> > > difference between OpenBSD and Linux.  Perhaps OpenBSD runs the CPU
> > > hotter before turning it back over to the BIOS on reboot?
> 
> > this is great information; thanks. any idea where the temperature
> > reference can be found?
> 
> I don't remember, it was at least a couple years ago.  It was only one
> reference too.  Most talked about listening to beep codes, which this
> wasn't really beep codes...
> 
> > i may be able to log the cpu temperature in both operating systems in
> > order to compare ...
> 
> Possibly, but noticed I said "before turning it back over to the BIOS".
> If it's a difference in OS shutdown, it will be difficult to log the
> temperature.
> 
> --Kurt

understood, but i did uncover something that might provide a hint ... i
haven't duplicated the results more than half a dozen times, but so far it's
been consistent:

after first booting openbsd, i see the following output:

# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=31.00 degC
hw.sensors.lm1.temp0=48.00 degC
hw.sensors.lm1.temp1=52.50 degC
hw.sensors.lm1.temp2=36.00 degC
# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=30.00 degC
hw.sensors.lm1.temp0=48.00 degC
hw.sensors.lm1.temp1=52.50 degC
hw.sensors.lm1.temp2=36.00 degC
# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=31.00 degC
hw.sensors.lm1.temp0=48.00 degC
hw.sensors.lm1.temp1=52.50 degC
hw.sensors.lm1.temp2=36.00 degC
# reboot

and meet with success ... if i wait just a few minutes (2) i end up with this:

# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=30.00 degC
hw.sensors.lm1.temp0=48.00 degC
hw.sensors.lm1.temp1=52.00 degC
hw.sensors.lm1.temp2=35.50 degC
# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=30.00 degC
hw.sensors.lm1.temp0=0.00 degC
hw.sensors.lm1.temp1=14.00 degC
hw.sensors.lm1.temp2=14.00 degC
# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=30.00 degC
hw.sensors.lm1.temp0=0.00 degC
hw.sensors.lm1.temp1=14.00 degC
hw.sensors.lm1.temp2=14.00 degC
# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=30.00 degC
hw.sensors.lm1.temp0=0.00 degC
hw.sensors.lm1.temp1=14.00 degC
hw.sensors.lm1.temp2=14.00 degC
# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=30.00 degC
hw.sensors.lm1.temp0=0.00 degC
hw.sensors.lm1.temp1=14.00 degC
hw.sensors.lm1.temp2=14.00 degC
# sysctl -a|grep 'sensors.*temp'
hw.sensors.cpu0.temp0=30.00 degC
hw.sensors.lm1.temp0=0.00 degC
hw.sensors.lm1.temp1=14.00 degC
hw.sensors.lm1.temp2=14.00 degC
# reboot

BEEEP!

again, not a very scientific/exacting approach, but half a dozen times i've
seen the same results. i don't know what it is that trips up the sensors,
but that's when i seem to have the issue.

now, this is running the 5.4 installation (i downgraded at someone's
suggestion for testing) and i can easily reinstall from current snapshot to
see if this may be an unrelated bug.

but until then, does this scenario make sense to anyone?

Re: requesting help working around boot failures with supermicro atom board

[Mark Kettenis]

> # sysctl -a|grep 'sensors.*temp'
> hw.sensors.cpu0.temp0=30.00 degC
> hw.sensors.lm1.temp0=0.00 degC
> hw.sensors.lm1.temp1=14.00 degC
> hw.sensors.lm1.temp2=14.00 degC
> # reboot
> 
> BEEEP!

Oh that is interesting.  Can you try disabling the lm(4) driver in
your kernel?  You can do:

# config -ef /bsd
...
ukc> disable lm
254 lm0 disabled
255 lm* disabled
256 lm* disabled
ukc> quit
Saving modified kernel.
# reboot

That reboot will probably still hang.  But it'd be interesting to see
if any subsequent reboots work better.

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Mike Larkin  azathoth.net> writes:

> 
> On Fri, Sep 11, 2015 at 06:38:23PM -0400, dewey.hylton  gmail.com wrote:
> > hi all. i???m having difficulty with this board:
> > 
> > Supermicro X7SPE-HD-D525 rev1
> > 
> > i have several similar systems, each running an older version of OpenBSD
for a few years without incident.
> except this one ???
> > 
> > running OpenBSD 5.7 i386, from cold start it boots just fine and runs
until rebooted. once rebooted,
> however, prior to anything being displayed (i assume this is early in the
bios post phase) i get one very
> long beep. super micro tells me this indicates inability to correctly
initialize the memory. okay, so
> i???ve changed memory for known working components and have the same
issue. at this point, the only thing
> that gets me booting again is to remove power and then restore power. it
then boots fine from cold start, and
> fails on the next reboot (as in, ???reboot??? from the command line). once
in long-beep failure mode,
> neither the hardware reset button nor the power button can make the
machine boot again. the only thing that
> works is removing power. every once in a while it will reboot s
>  uccessfully, only to fail in the same manner on the next attempt.
> > 
> > super micro has had me flash bios, clear cmos, boot from different
devices and with nothing connected,
> etc. the results are the same: when rebooting from openbsd, next boot
fails until power is
> removed/restored. super micro blames openbsd.
> > 
> > i installed linux (same hardware, overwrite openbsd 5.7) and scheduled a
reboot every 5 minutes and left
> it overnight. i logged 554 successful reboots.
> > 
> > i have since installed the latest available openbsd amd64 snapshot, and
am seeing the same failures.
> > 
> > i???m wondering if something could be disabled (boot -c ?) or if
something else raises a red flag and might
> have a workaround. this has me stumped. i would very much appreciate a
clue stick. 
> > 
> > dmesg follows:
> > 
> 
> acpidump please.

my pleasure:

[demime removed a uuencoded section named supermicro-X7SPE-HF-D525-acpidump.tgz 
which was 276 lines]

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Dewey Hylton  gmail.com> writes:



> # sysctl -a|grep 'sensors.*temp'
> hw.sensors.cpu0.temp0=31.00 degC
> hw.sensors.lm1.temp0=48.00 degC
> hw.sensors.lm1.temp1=52.50 degC
> hw.sensors.lm1.temp2=36.00 degC
> # reboot
> 
> and meet with success ... if i wait just a few minutes (2) i end up with this:
> 
> # sysctl -a|grep 'sensors.*temp'
> hw.sensors.cpu0.temp0=30.00 degC
> hw.sensors.lm1.temp0=48.00 degC
> hw.sensors.lm1.temp1=52.00 degC
> hw.sensors.lm1.temp2=35.50 degC
> # sysctl -a|grep 'sensors.*temp'
> hw.sensors.cpu0.temp0=30.00 degC
> hw.sensors.lm1.temp0=0.00 degC
> hw.sensors.lm1.temp1=14.00 degC
> hw.sensors.lm1.temp2=14.00 degC
> # sysctl -a|grep 'sensors.*temp'
> hw.sensors.cpu0.temp0=30.00 degC
> hw.sensors.lm1.temp0=0.00 degC
> hw.sensors.lm1.temp1=14.00 degC
> hw.sensors.lm1.temp2=14.00 degC
> # sysctl -a|grep 'sensors.*temp'
> hw.sensors.cpu0.temp0=30.00 degC
> hw.sensors.lm1.temp0=0.00 degC
> hw.sensors.lm1.temp1=14.00 degC
> hw.sensors.lm1.temp2=14.00 degC
> # sysctl -a|grep 'sensors.*temp'
> hw.sensors.cpu0.temp0=30.00 degC
> hw.sensors.lm1.temp0=0.00 degC
> hw.sensors.lm1.temp1=14.00 degC
> hw.sensors.lm1.temp2=14.00 degC
> # sysctl -a|grep 'sensors.*temp'
> hw.sensors.cpu0.temp0=30.00 degC
> hw.sensors.lm1.temp0=0.00 degC
> hw.sensors.lm1.temp1=14.00 degC
> hw.sensors.lm1.temp2=14.00 degC
> # reboot
> 
> BEEEP!
> 
> again, not a very scientific/exacting approach, but half a dozen times i've
> seen the same results. i don't know what it is that trips up the sensors,
> but that's when i seem to have the issue.
> 
> now, this is running the 5.4 installation (i downgraded at someone's
> suggestion for testing) and i can easily reinstall from current snapshot to
> see if this may be an unrelated bug.
> 
> but until then, does this scenario make sense to anyone?

i now have a fresh install of current/amd64. the snapshot appears to be a
bit on the broken side, as some of the libcrypto/libssl stuff is missing
(this on both i386 and amd64 snapshots) and this prevents me from logging in
via ssh and copy/pasting from terminal. i see this has been reported on the
list already, so a newer snapshot (tomorrow?) may fix this.

but still i have several -current boots under my belt, and the sysctl
temperature thing appears to be similar to what it was with the 5.4
installation. the lm temps are showing negative numbers instead of 0 and 14,
but once that happens the box fails to reboot properly as before.

one other thing i've noticed now that i've reinstalled so many times in the
past few days: it does not matter how long i've been booted into the ramdisk
kernel for installation or whatever - it can sit for hours, and always
reboots properly. no support for sensors in the ramdisk kernel. coincidence?

Re: requesting help working around boot failures with supermicro atom board

[Dewey Hylton]

Mark Kettenis  xs4all.nl> writes:

> 
> > # sysctl -a|grep 'sensors.*temp'
> > hw.sensors.cpu0.temp0=30.00 degC
> > hw.sensors.lm1.temp0=0.00 degC
> > hw.sensors.lm1.temp1=14.00 degC
> > hw.sensors.lm1.temp2=14.00 degC
> > # reboot
> > 
> > BEEEP!
> 
> Oh that is interesting.  Can you try disabling the lm(4) driver in
> your kernel?  You can do:
> 
> # config -ef /bsd
> ...
> ukc> disable lm
> 254 lm0 disabled
> 255 lm* disabled
> 256 lm* disabled
> ukc> quit
> Saving modified kernel.
> # reboot
> 
> That reboot will probably still hang.  But it'd be interesting to see
> if any subsequent reboots work better.

*this* interests me, and was basically what i was asking in the original
post - except i had no idea what might need to be disabled. one step at a
time, it's been interesting the things that have popped up.

still no idea whether this has anything to do with the seemingly
openbsd-only issue, but ...

i made this change, booted the new kernel, ran 'cksum /dev/mem' a bunch of
times in hopes of raising the temperature somewhat (did get to 36C, which is
higher than in my previous tests). then i rebooted, and the box came back up
without incident.

so i'm going to run through this several times with reboots in every 20
minutes or so and see if it survives the night.

Re: edit UTF-8 text files under vi or mg?

[Alexander Hall]

On September 12, 2015 11:02:13 AM GMT+02:00, Jiri Navratil  
wrote:
>Hello,
>
>Is it possible to edit UTF-8 text files under vi or mg?

I'll add to the replies that you've already received that it is quite possible 
to edit UTF-8 files with vi from base, just that you won't be able to see the 
proper glyphs, but instead "\xc3\xa5" etc.

So while is inconvenient for text editing, the characters themselves are not a 
showstopper.

/Alexander

>
>I'm using some machines, where I need to touch UTF-8 encoded files only
>rarely. I would prefer to avoid installation of Vim there and instead
>use a "in OS included" text editor. Is that possible and how to use and
>configure them?
>
>Thank you,
>Jiri

Re: requesting help working around boot failures with supermicro atom board

[Chris Cappuccio]

Kurt Mosiejczuk [kurt-open...@se.rit.edu] wrote:
> 
> Hearing that Linux doesn't trip it, I'm wondering if it's an ACPI difference
> between OpenBSD and Linux.  Perhaps OpenBSD runs the CPU hotter before
> turning it back over to the BIOS on reboot?
> 

OpenBSD 5.8-current enters deeper C states than the ACPI describes. The
ACPI documentation is not to be taken literally, according to Intel. So
now OpenBSD's behavior should be similar to Linux in this regard, and
therefore, you'll see lower CPU temperatures. (With the C states and 
mwait features that are enabled today, your temps are already lower
than previous releases.)

Re: requesting help working around boot failures with supermicro atom board

[Kurt Mosiejczuk]

On Mon, Sep 14, 2015 at 05:15:01PM +, Dewey Hylton wrote:

> > I've had this issue with the same systems.  Never guessed it would
> > be OpenBSD specific.  What I've found to make it stop happening is
> > pulling the board out and redoing the thermal paste for the CPU
> > heatsink.  I had found some reference indicating that the alarm I
> > got might be because of overheating.

> > The difference between the boxes may be the attention to detail the
> > factory worker who put it together had that day.

> > Hearing that Linux doesn't trip it, I'm wondering if it's an ACPI
> > difference between OpenBSD and Linux.  Perhaps OpenBSD runs the CPU
> > hotter before turning it back over to the BIOS on reboot?

> this is great information; thanks. any idea where the temperature
> reference can be found?

I don't remember, it was at least a couple years ago.  It was only one
reference too.  Most talked about listening to beep codes, which this
wasn't really beep codes...

> i may be able to log the cpu temperature in both operating systems in
> order to compare ...

Possibly, but noticed I said "before turning it back over to the BIOS".
If it's a difference in OS shutdown, it will be difficult to log the
temperature.

--Kurt

Re: requesting help working around boot failures with supermicro atom board

[Mike Larkin]

On Fri, Sep 11, 2015 at 06:38:23PM -0400, dewey.hyl...@gmail.com wrote:
> hi all. i???m having difficulty with this board:
> 
> Supermicro X7SPE-HD-D525 rev1
> 
> i have several similar systems, each running an older version of OpenBSD for 
> a few years without incident. except this one ???
> 
> running OpenBSD 5.7 i386, from cold start it boots just fine and runs until 
> rebooted. once rebooted, however, prior to anything being displayed (i assume 
> this is early in the bios post phase) i get one very long beep. super micro 
> tells me this indicates inability to correctly initialize the memory. okay, 
> so i???ve changed memory for known working components and have the same 
> issue. at this point, the only thing that gets me booting again is to remove 
> power and then restore power. it then boots fine from cold start, and fails 
> on the next reboot (as in, ???reboot??? from the command line). once in 
> long-beep failure mode, neither the hardware reset button nor the power 
> button can make the machine boot again. the only thing that works is removing 
> power. every once in a while it will reboot successfully, only to fail in the 
> same manner on the next attempt.
> 
> super micro has had me flash bios, clear cmos, boot from different devices 
> and with nothing connected, etc. the results are the same: when rebooting 
> from openbsd, next boot fails until power is removed/restored. super micro 
> blames openbsd.
> 
> i installed linux (same hardware, overwrite openbsd 5.7) and scheduled a 
> reboot every 5 minutes and left it overnight. i logged 554 successful reboots.
> 
> i have since installed the latest available openbsd amd64 snapshot, and am 
> seeing the same failures.
> 
> i???m wondering if something could be disabled (boot -c ?) or if something 
> else raises a red flag and might have a workaround. this has me stumped. i 
> would very much appreciate a clue stick. 
> 
> dmesg follows:
> 

acpidump please.

> OpenBSD 5.8-current (GENERIC.MP) #1364: Wed Sep  9 17:32:01 MDT 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4277665792 (4079MB)
> avail mem = 4144070656 (3952MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP APIC MCFG OEMB HPET EINJ BERT ERST HEST
> acpi0: wakeup devices P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) 
> USB5(S4) EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4) P0P4(S4) P0P5(S4) 
> P0P6(S4) P0P7(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.23 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
> cpu0: 512KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 199MHz
> cpu0: mwait min=64, max=64, C-substates=0.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.00 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
> cpu1: 512KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 1 (application processor)
> cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.00 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
> cpu2: 512KB 64b/line 8-way L2 cache
> cpu2: smt 1, core 0, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.00 MHz
> 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR
> cpu3: 512KB 64b/line 8-way L2 cache
> cpu3: smt 1, core 1, package 0
> ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins
> ioapic0: misconfigured as apic 1, remapped to apid 4
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 4 (P0P1)
> acpiprt2 at acpi0: bus 1 (P0P4)
> acpiprt3 at acpi0: bus 2 (P0P8)
> acpiprt4 at acpi0: bus 3 (P0P9)
> acpicpu0 at acpi0: C1(@1 halt!)
> acpicpu1 at acpi0: C1(@1 halt!)
> acpicpu2 at acpi0: C1(@1 halt!)
> acpicpu3 at acpi0: C1(@1 halt!)
> acpibtn0 at acpi0: SLPB
> acpibtn1 at acpi0: PWRB
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 

Re: OpenSSL can't load library '

[Stefan Wollny]

‎Hi Stuart,

Thank you very much for this hint:‎ cvs is just now updating the sources.

Will proceed as suggested.

Again thank you and have a nice hacking-week!
STEFAN

Gesendet von meinem BlackBerry 10-Smartphone.
  Originalnachricht  
Von: Stuart Henderson
Gesendet: Montag, 14. September 2015 19:16
An: Stefan Wollny
Betreff: Re: OpenSSL can't load library '

In gmane.os.openbsd.misc, you wrote:
> Hi there! 
> Having upgraded to last nights snapshots I am now faced with an only
> partially working system: Neither is a cvs-update possible nor does X
> start. I get the error message‎ at start"ssh-keygen: can't load library
> 'libcrypto.so.36.0'" and this library is required for cvs and X as well. 
> What should I do???
> TIA.
> Best, STEFAN
> Gesendet von meinem BlackBerry 10-Smartphone.
>
>

cp the previous libs across to the new version. this is dirty but should
be good enough to let you cvs up and rebuild libssl/libcrypto.

Re: IPv6 transport for pflow(4)

[Denis Fondras]

Hi,

Is anyone working to add sFlow support to PF ?

Denis

Re: make bootable CD by bootable USB

[Duncan Patton a Campbell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 13 Sep 2015 21:12:37 -0400
Quartz  wrote:

> > hi all .
> >
> > i make bootable openbsd USB stick by ordinaly installatin .
> >
> > if i can make bootable CD from this USB , it is very happy .
> >
> > are there any methods ?
> >
> > is linux's isolinux or so possible ?
> > is it very difficult to solve ?
> 
> Just for clarification, are you trying to make a customized 'live' 
> OpenBSD CD that will boot into a fully functional state, or are you
> just trying to install OpenBSD from a CD onto a drive?
> 
At one point in time the easiest way to make a bootable cd was 
with an mfs like is done with bsd.rd.

Dhu

- -- 

http://babayaga.neotext.ca/PublicKeys/Duncan_Patton_a_Campbell_pubkey.txt

Ne obliviscaris, vix ea nostra voco.
iF4EAREIAAYFAlX2iVcACgkQiY6AzzR1lzy/hgEAj0ByUp+ncm2EVWIjCaSI4zIu
zHN85GYZahtZVmGoVDQA/jWElOP045CQsDmieYkQjikQdRTBHHNdwmL/IQArLgtD
=L2Ma
-END PGP SIGNATURE-

Re: a fanless board with msata

[Harald Dunkel]

On 08/28/15 16:53, Lars wrote:
> 
> There is a barebone system from Shuttle DS437 that fits your requirements. I 
> don't know it so I can not tell if it works as workstation.
> 

I am using the DS437 as a firewall, network tunnel, spam filter and
internal DNS/DHCP server at home. Performance is fine. Of course it
cannot compete with an i7.

Important to know is that you have to run it in "portrait mode" to
support convection.

dmesg is attached, if anymody is interested.


Hope this helps
Harri

OpenBSD 5.8 (GENERIC.MP) #0: Sat Aug  8 17:34:59 CEST 2015
r...@marvin.afaics.de:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8462303232 (8070MB)
avail mem = 8201945088 (7821MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb530 (73 entries)
bios0: vendor American Megatrends Inc. version "1.01" date 09/25/2013
bios0: Shuttle Inc. DS437
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG SLIC HPET SSDT SSDT SSDT
acpi0: wakeup devices P0P1(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) 
USB6(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) 
PXSX(S4) RP04(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz, 1796.22 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,XSAVE,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
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) Celeron(R) CPU 1037U @ 1.80GHz, 1795.92 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,XSAVE,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus 2 (RP02)
acpiprt4 at acpi0: bus 3 (RP03)
acpiprt5 at acpi0: bus 4 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiprt7 at acpi0: bus -1 (RP06)
acpiprt8 at acpi0: bus -1 (RP07)
acpiprt9 at acpi0: bus -1 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID0
acpivideo0 at acpi0: GFX0
cpu0: Enhanced SpeedStep 1796 MHz: speeds: 1800, 1700, 1600, 1500, 1400, 1300, 
1200, 1100, 1000, 900, 800, 774 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09
vga1 at pci0 dev 2 function 0 "Intel HD Graphics 2500" rev 0x09
intagp at vga1 not configured
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1024x768
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0 "Intel 7 Series USB" rev 0x04: apic 2 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 7 Series HD Audio" rev 0x04: msi
azalia0: codecs: Realtek ALC662, Intel/0x2806, using Realtek ALC662
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 7 Series PCIE" rev 0xc4: msi
pci1 at ppb0 bus 1
rtwn0 at pci1 dev 0 function 0 "Realtek 8188CE" rev 0x01: msi
rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R, address 64:5a:04:35:83:0a
ppb1 at pci0 dev 28 function 1 "Intel 7 Series PCIE" rev 0xc4: msi
pci2 at ppb1 bus 2
re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x0c: RTL8168G/8111G (0x4c00), 
msi, address 80:ee:73:95:c1:0c
rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
ppb2 at pci0 dev 28 function 2 

Re: pf_rules

[Harald Dunkel]

Hi Holger,

You might want to use something like this in your
/etc/rc.local:

pf=/etc/pf.local.conf
if pfctl -nf ${pf}; then
pfctl -f ${pf}
fi

This would make the regular /etc/pf.conf a fallback, if
pf.local.conf doesn't load.


Just a suggestion, of course. Regards
Harri