Re: Boot NVME device on sparc64

[Aaron Mason]

Could you boot from another bootable device and use boot.conf(8) to
tell it to boot the kernel on the SSD?  Bit of a round-about way of
doing it but it could work if boot(8) can see the SSD.

If the CD boot loader can see the SSD, you could burn it to a CD-R
along with your boot.conf and use it to boot - just make sure you put
it back if you use the drive to install software.

Just spitballing here, I don't have a sparc64 device readily available
for testing.

On Fri, Jul 26, 2019 at 8:31 AM John Gould  wrote:
>
> Hi there, Does anyone have a way of booting a pcie nvme device on sparc64.
> I can install OBSD on the device but of course there is no way OBP can see
> it
> as a boot device. I can also use it for storage under OpenBSD which works
> fine.
>
> But! Is there any way to boot OpenBSD 6.5 installed on this drive on
> sparc64.
>
> I'm using a Sun t5120.
>
> Kind regards John.



-- 
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse

Re: RNG question

[Brent Cook]

> On Jul 30, 2019, at 5:15 AM, Remco  wrote:
> 
> On 30-07-19 09:51, Peter J. Philipp wrote:
>> Hi,
>> I had considered doing some programming in visual studio on windows and I
>> really miss the easy arc4random*() routines there.
> 
> You may be able to get the arc4ramdon interface on systems other than OpenBSD 
> by extracting the necessary files from:
> - src/lib/libc/crypt/
> - src/lib/libcrypto/arc4random/
> 
> This appears to work fine on Linux, I haven't tried it on Windows.
> 

Correct, these were built to be easily reusable within other projects. The 
LibreSSL Windows port uses these as well.

https://github.com/libressl-portable/portable/blob/master/crypto/CMakeLists.txt#L889
 


 - Brent

Re: Kerberos SSH routing tables problem

[Byte Skeptical]

Ran into a similar issue on my ERL when I used egress in my pf rules.
Ended up trunking the ethernet ports using aggr(4) and switched to using
that interface in my rules, got failover as a bonus. Still not sure why
egress behaves this way and if its a bug or my own misunderstanding.
Running OpenBSD 6.5-current (GENERIC.MP). If this doesn't apply to your
situation apologies and disregard.

On Mon, Jul 29, 2019 at 03:05:14PM -0400, Predrag Punosevac wrote:

Hi Misc,

I am using Edgerouter lite as a firewall/DNS cashing resolver for one of
our remote location

ubnt1# uname -mrsv
OpenBSD 6.5 GENERIC.MP#0 octeon

The desktops behind the firewall have to use Kerberised SSH to perform
some work on one of .mil servers. I opened egress ports kerberos,
klogin, kshell TCP protocol as well as kerberos UDP. After the work is
finished and desktops are "logged out" routing tables (dns) are in a bad
state on the firewall. A simple

pfctl -F all -f /etc/pf.conf

fixes the problem and desktops can again do DNS resolving and surfing
the Internet.

Could somebody give me a head start how to go about further trouble
shooting and fixing the problem? Obviously flashing states is not very
convenient.

Most Kind Regards,
Predrag Punosevac



--
Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses 
remove it.


signature.asc
Description: PGP signature

Re: RNG question

[Roderick]

On Tue, 30 Jul 2019, Peter J. Philipp wrote:


On Tue, Jul 30, 2019 at 06:11:15AM -0600, Theo de Raadt wrote:

Peter J. Philipp  wrote:

[...]
I'm not misreading.  Why is this done?


That is a low-grade question.


OK I retract it then.  Don't worry about it.


You cannot retract it. Impossible.

Rod.

lrint(INT_MAX) != INT_MAX

[hans]

This is what happens on my relatively current
OpenBSD bbb.stare.cz 6.5 GENERIC#0 armv7(BeagleBone Black)
OpenBSD ppc.stare.cz 6.5 GENERIC#0 macppc   (an old MacMini)

#include 
#include 
#include 

int
main()
{
long l;
double d = INT_MAX;

l = lrint(d);
printf("%f is %ld\n", d, l);

l = lround(d);
printf("%f is %ld\n", d, l);

return 0;
}

2147483647.00 is -1
2147483647.00 is -1

That doesn't seem right: isn't INT_MAX representable as a long,
even on these machines where sizeof(int) == sizeof(long)?
If so, shouldn't lrint(INT_MAX) == INT_MAX = lround(INT_MAX)?

On i386 (an ALIX), I see

2147483647.00 is 2147483647
2147483647.00 is -1

so lrint() returns the expected value but lround() does not.

On the amd64s I have, I see the expected:
2147483647.00 is 2147483647
2147483647.00 is 2147483647

Is this a bug or am I missing something obvious?

Jan

Re: PCI-Passthrough XL710 NIC ixl OpenBSD Guest reboot Resets Hypervisor OS

[Mike Hammett]

Did that fix it? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Tom Smyth"  
To: "Misc"  
Sent: Tuesday, July 30, 2019 8:30:04 AM 
Subject: PCI-Passthrough XL710 NIC ixl OpenBSD Guest reboot Resets Hypervisor 
OS 

Hello all, 

I recently have been playing with PCI Pass through, IO MMU 
/ SR-IOV with Intel NIC XL710 based 40G nic ixl drivers 
with proxmox / kvm and qemu as a hypervisor and OpenBSD 
as the guest vms, 

we encountered an issue where if I passed through the 
Physical Function (full nic pass through) that when 
reboot / halt -p command was entered on the guest the 
hypervisor / proxmox would reset and reboot also 


after diagnosing and trying to pass-through other devices 
such as the intel pro 1000 em nics 
they did not seem to cause the hypervisor to reboot 
when rebooting the openBSD Guest 

I got on to the friendly people at HotLava systems 
(my nic vendor) and they suggested the firmware of the 
NICs be upgraded, 

I installed the version 7.00 nic firmware (replacing 
version 6.01 firmware 

the tool I used to update the firmware on the hypervisor 
was 
./nvmupdate64e and comes with the firmware package 
from the Intel Download site... 

I hope this helps anyone trying to run openBSD on 
a KVM / Qemu based hypervisor like Proxmox 

I couldnt find this issue documented anywhere 
so im sending this to the list... 

im sure there is also a security issue where the hypervisor 
can be hard reset, by a guest being rebooted ... 
but this is a question for the Hypervisor and not OpenBSD 

Hope this helps anyone who has encountered it in the past 
and those who may encounter it in the future 


-- 
Kindest regards, 
Tom Smyth. 

Re: RNG question

[Peter J. Philipp]

On Tue, Jul 30, 2019 at 06:11:15AM -0600, Theo de Raadt wrote:
> Peter J. Philipp  wrote:
> 
> > Before twisting the pool, enqueue_randomness() has a component of time if
> > I'm not misreading.  Why is this done?
> 
> That is a low-grade question.

OK I retract it then.  Don't worry about it.

Regards,
-peter

Re: PCI-Passthrough XL710 NIC ixl OpenBSD Guest reboot Resets Hypervisor OS

[Tom Smyth]

Good question... Yes it did :) sorry for the suspense ;)

On Tue, 30 Jul 2019 at 14:38, Mike Hammett  wrote:

> Did that fix it?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Tom Smyth" 
> *To: *"Misc" 
> *Sent: *Tuesday, July 30, 2019 8:30:04 AM
> *Subject: *PCI-Passthrough XL710 NIC ixl OpenBSD Guest reboot Resets
> Hypervisor OS
>
> Hello all,
>
> I recently have been playing with PCI Pass through, IO MMU
> / SR-IOV with Intel NIC XL710 based 40G nic ixl drivers
> with proxmox / kvm and qemu as a hypervisor and OpenBSD
> as the guest vms,
>
> we encountered an issue where if I passed through the
> Physical Function (full nic pass through) that when
> reboot / halt -p  command was entered on the guest the
> hypervisor / proxmox  would reset and reboot also
>
>
> after diagnosing and trying to pass-through other devices
> such as the intel pro 1000 em nics
> they did not seem to cause the hypervisor to reboot
> when rebooting the openBSD Guest
>
> I got on to the friendly people at HotLava systems
> (my nic vendor) and they suggested the firmware of the
> NICs be upgraded,
>
> I installed the version 7.00 nic firmware (replacing
> version 6.01 firmware
>
> the tool I used to update the firmware on the hypervisor
> was
> ./nvmupdate64e   and comes with the firmware package
> from the Intel Download site...
>
> I hope this helps anyone trying to run openBSD on
> a KVM / Qemu based hypervisor like Proxmox
>
> I couldnt find this issue documented anywhere
> so im sending this to the list...
>
> im sure there is also a security issue where the hypervisor
> can be hard reset,  by a guest being rebooted ...
> but this is a question for the Hypervisor and not OpenBSD
>
> Hope this helps anyone who has encountered it in the past
> and those who may encounter it in the future
>
>
> --
> Kindest regards,
> Tom Smyth.
>
>
>

-- 
Kindest regards,
Tom Smyth.

Re: [www] faq/ports/testing.html - adding link for portslogger(1)'s man

[Daniel Jakots]

On Mon, 29 Jul 2019 22:22:01 +0200, Alex Naumov
 wrote:

> just a small update for the port testing guide ;-)

Thanks committed!

Daniel

PCI-Passthrough XL710 NIC ixl OpenBSD Guest reboot Resets Hypervisor OS

[Tom Smyth]

Hello all,

I recently have been playing with PCI Pass through, IO MMU
/ SR-IOV with Intel NIC XL710 based 40G nic ixl drivers
with proxmox / kvm and qemu as a hypervisor and OpenBSD
as the guest vms,

we encountered an issue where if I passed through the
Physical Function (full nic pass through) that when
reboot / halt -p  command was entered on the guest the
hypervisor / proxmox  would reset and reboot also


after diagnosing and trying to pass-through other devices
such as the intel pro 1000 em nics
they did not seem to cause the hypervisor to reboot
when rebooting the openBSD Guest

I got on to the friendly people at HotLava systems
(my nic vendor) and they suggested the firmware of the
NICs be upgraded,

I installed the version 7.00 nic firmware (replacing
version 6.01 firmware

the tool I used to update the firmware on the hypervisor
was
./nvmupdate64e   and comes with the firmware package
from the Intel Download site...

I hope this helps anyone trying to run openBSD on
a KVM / Qemu based hypervisor like Proxmox

I couldnt find this issue documented anywhere
so im sending this to the list...

im sure there is also a security issue where the hypervisor
can be hard reset,  by a guest being rebooted ...
but this is a question for the Hypervisor and not OpenBSD

Hope this helps anyone who has encountered it in the past
and those who may encounter it in the future


-- 
Kindest regards,
Tom Smyth.

Re: How to debug hanging machines / proc: table is full

[Raimo Niskanen]

On Mon, Jul 29, 2019 at 01:20:58PM +, Stuart Henderson wrote:
> On 2019-07-29, Raimo Niskanen  wrote:
> > A new hang, I tried to invstigate:
> >
> > At July 19 the last log entry from my 'ps' log was from 14:55, which is
> > also the time on the 'systat vmstat' screen when it froze.  Then the machine
> > hums along but just after midnight at 00:42:01 the first "/bsd: process:
> > table is full" entry appears.  That message repeats until I rebooted it
> > today at July 29 10:48.
> >
> > I had a terminal with top running.  It was still updating.  It showed about
> > 98% sys and 2% spin on one of 4 CPUs, the others 100% idle.  Then (after
> > the process table had gotten full) it had 1282 idle processes and 1 on
> > processor, which was 'top' itself.
> > Memory: Real: 456M/1819M act/tot Free: 14G Cache: 676M Swap: 0K/16G.
> >
> > I had 8 shells under tmux ready for debugging.  'ls worked.
> > 'systat' on one hung.  'top' on another failed with "cannot fork".
> > 'exec ps ajxww" printed two lines with /sbin/init and /sbin/slaac
> > and then hung.  'exec reboot' did not succeed.  Neither did a short power
> > button, that at least caused a printout "stopping daemon nginx(failed)",
> > but got no further.  I had to do a hard power off. 
> >
> > My theory now is that our daily tests right before 14:55 started a process
> > (this process is the top 'top' process with 10:14 execution time) that
> > triggers a lock or other contention problem in the kernel which causes
> > one CPU to spin in the system, and blocks processes from dying.
> > About 10 hours later the process table gets full.
> >
> > Any, ANY ideas of how to proceed would be appreciated!
> >
> > Best Regards
> 
> Did you notice any odd waitchan's (WAIT in top output)?

I do not think so:
  select (for the possibly triggering process), - (for 'top'), kqread, netlock,
  bpf, wait, piperd.

> 
> Maybe set ddb.console=1 in sysctl.conf and reboot (if not already
> set), then try to break into DDB during a hang and see how things look
> in ps there. (Test breaking into DDB before a hang first so you know
> that you can do it .. you can just "c" to continue).
> 
> There might also be clues in things like "sh malloc" or "sh all pools".

Sounds like fun - will try that!

> 
> Perhaps you could also get clues from running a kernel built with
> 'option WITNESS', you may get some messages in dmesg, or it adds commands
> to ddb like "show locks", "show all locks", "show witness" (see ddb(4) for
> details).

Maybe later.  I have gotten used to not compiling my kernel...

> 
> Can you provoke a hang by running this process manually?

Might be worth a try to repeat the suspected test case many times.
I will try.

Thanks for the hints!
-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

Re: RNG question

[Theo de Raadt]

Peter J. Philipp  wrote:

> Before twisting the pool, enqueue_randomness() has a component of time if
> I'm not misreading.  Why is this done?

That is a low-grade question.

Re: RNG question

[Remco]

On 30-07-19 09:51, Peter J. Philipp wrote:

Hi,

I had considered doing some programming in visual studio on windows and I
really miss the easy arc4random*() routines there.



You may be able to get the arc4ramdon interface on systems other than 
OpenBSD by extracting the necessary files from:

- src/lib/libc/crypt/
- src/lib/libcrypto/arc4random/

This appears to work fine on Linux, I haven't tried it on Windows.

HID keyboard + usbhidctl weirdness

[Anatoli]

Hi all,

I have a Logitech diNovo Edge USB keyboard with multimedia keys.

By default no multimedia keys work, but also the printscreen button 
doesn't work.


With usbhidctl I can make most of the keys work, but they are split 
between 2 uhid devices. I have found no way to make printscreen key work 
(no feedback in xev, nor via usbhidctl).


Also I tried setxkbmap -model logidinovoedge (initially it's pc105), but 
with no effect, probably I don't understand well what it does.


dmesg goes below.

# with the keyboard attached
$ usbdevs
Controller /dev/usb0:
addr 01: 8086: Intel, xHCI root hub
addr 02: 0424:2504 Standard Microsystems, Hub
addr 03: 046d:c52b Logitech, USB Receiver
addr 04: 046d:0b04 Logitech, Logitech BT Mini-Receiver
addr 05: 046d:c713 Logitech, Logitech BT Mini-Receiver
addr 06: 046d:c714 Logitech, Logitech BT Mini-Receiver

# without the keyboard
$ usbdevs
Controller /dev/usb0:
addr 01: 8086: Intel, xHCI root hub
addr 02: 0424:2504 Standard Microsystems, Hub
addr 03: 046d:c52b Logitech, USB Receiver

$ setxkbmap -model logidinovoedge
$ setxkbmap -query
rules:  base
model:  logidinovoedge
layout: us

$ usbhidctl -rvv -f /dev/uhid7
report ID=3
Report descriptor:
Collection page=Consumer usage=Consumer_Control (12:0x1)
Input  size=16 count=2 Array page=Consumer 
usage=Consumer_Control..AC_Send (12:0x1..12:0x28c), logical range 1..652

End collection
Total  input size 4 bytes
Total  output size 0 bytes
Total  feature size 0 bytes

$ usbhidctl -rvv -f /dev/uhid8
report ID=4
Report descriptor:
Collection page=Generic_Desktop usage=System_Control (1:0x80)
Input   size=2 count=1 Array page=Generic_Desktop usage=System_Sleep 
(1:0x82), logical range 1..3
Input   size=6 count=1 Const page=0x usage=0x (0:0x0), logical 
range 1..3

End collection
Total   input size 1 bytes
Total   output size 0 bytes
Total   feature size 0 bytes

# Redundant output removed (pressing multimedia keys)
$ usbhidctl -l -f /dev/uhid7
Consumer_Control.AC_Go_To=1 [0]
Consumer_Control.AL_Newsreader=1 [0]
Consumer_Control.AC_Back=1 [0]
Consumer_Control.Stop=1 [0]
Consumer_Control.Eject=1 [0]
Consumer_Control.Play/Skip=1 [0]
Consumer_Control.Scan_Previous_Track=1 [0]
Consumer_Control.AL_Word_Processor=1 [0]
Consumer_Control.AC_Zoom_Out=1 [0]
Consumer_Control.AC_Zoom=1 [0]
Consumer_Control.AC_Full_Screen_View=1 [0]
Consumer_Control.Volume_Decrement=1 [0]
Consumer_Control.Bass=1 [0]

$ usbhidctl -l -f /dev/uhid8
System_Control.System_Sleep=1
System_Control.System_Sleep=0

# On Linux xev event for printscreen key
KeyRelease event, serial 37, synthetic NO, window 0xe01,
root 0x149, subw 0x0, time 266293215, (-940,-320), root:(485,528),
state 0x10, keycode 107 (keysym 0xff61, Print), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False



So, I have the following questions:
 1. Why are there 2 HID devices for the same keyboard and the sleep 
button is the only button that is available only on the 2nd device (uhid8)?
 2. Why not all keys are responding via usbhid (though the same happens 
on Linux)? The are 12 multimedia buttons for F1-F12 that are activated 
with Fn key, only 7 of them are working via usbhid, the other 5 don't 
respond on any uhid device. Other multimedia keys like zoom, volume 
control, etc. are all working fine via the 1st uhid device (uhid7).
 3. Why printscreen key it not working? It looks like a standard key 
that should respond in xev. On Linux it's working fine and its scancode 
in xev is 107 (see above).
 4. What does setxkbmap -model logidinovoedge is supposed to do? Is 
there anything it could help with? Should I put XkbModel in xorg.conf? 
What should then go in the `Identifier "idevname"` param?
 5. In FreeBSD there's devd.conf where some action could be defined 
when a device with a specific vendor & product is attached. How should 
this be accomplished in OpenBSD? I suppose the /dev/uhid{7,8} could 
change depending on the order of initialization of the devices and it 
may be present or not, so I can't use it directly in usbhidaction.


Thanks,
Anatoli


OpenBSD 6.5-current (GENERIC.MP) #154: Mon Jul 29 00:51:01 MDT 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34240577536 (32654MB)
avail mem = 33192677376 (31655MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7aeba000 (82 entries)
bios0: vendor American Megatrends Inc. version "5.12" date 06/29/2018
bios0: Default string Default string
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT HPET SSDT SSDT 
SSDT UEFI SSDT LPIT SSDT SSDT SSDT SSDT DBGP DBG2 DMAR WSMT
acpi0: wakeup devices RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) 
PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) 
PXSX(S4) RP03(S4) PXSX(S4) [...]

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot proc

RNG question

[Peter J. Philipp]

Hi,

I had considered doing some programming in visual studio on windows and I
really miss the easy arc4random*() routines there.

Out of boredom I started looking at /sys/dev/rnd.c and have a question now.
Before twisting the pool, enqueue_randomness() has a component of time if
I'm not misreading.  Why is this done?

Thanks!
-peter