The case of the phantom reboot
OpenBSD 6.8 GENERIC#5 i386 One of my systems rebooted at 03:01 local time today. I've seen kernel panics and bad hardware but I've never seen OpenBSD "just reboot" by itself, ever. There's no cron job that would do this. last(1) is no help; it shows the reboot command but not the shutdown that preceded it: root@ns ~ 4# last -f /var/log/wtmp.0 reboot~ Sat Mar 27 03:01 root ttyp0192.168.0.132Wed Mar 24 11:23 - 11:23 (00:00) wtmp.0 begins Wed Mar 24 11:23 2021 root@ns ~ 5# last -f /var/log/wtmp.1 root ttyp0192.168.0.132Tue Mar 16 21:30 - 21:30 (00:00) root ttyp075.82.86.131 Tue Mar 16 13:14 - 21:30 (08:15) root ttyp075.82.86.131 Sun Mar 14 21:20 - 21:29 (00:08) root ttyp075.82.86.131 Sat Mar 13 17:42 - 21:13 (03:31) The date gaps seem odd. I've ssh'd into this system multiple times between March 16-27. I don't see other signs of trouble in /var/log. I could use some help in looking for evidence of foul play, or "just" a hardware or software problem. Thanks in advance for further troubleshooting clues. dn
Re: vmm page fault with VM upgraded from Ubuntu 18LTS to 20LTS
Noah writes: > vmm crashes during boot after upgrading a VM from Ubuntu 18 to Ubuntu 20. > Host is running 6.8 with all syspatches > > vmd -dvvv output provides a log entry of: > vcpu_run_loop: vm 7 / vcpu 0 run ioctl failed: Bad address > > and this coincides with a kernel message: > vmx_fault_page: uvm_fault returns 14, GPA=0xfe001818, rip=0xb98a31b4 It's a known issue. Newer Ubuntu kernels are built with an Intel PMC driver that probes mmio registers on (IIRC) Intel Skylake and newer systems. vmm(4) and vmd(8) do not support mmio like this at the moment. There's no way to disable the probing as it's not a kernel module, so no combination of linux boot args will help. There are some hacky patches that would work if you were on -current, but unless you want to stay on bleeding edge, it's probably a bigger hastle than it's worth. This is in my backlog, however...I have a Kaby Lake system impacted by this. -Dave
vmm page fault with VM upgraded from Ubuntu 18LTS to 20LTS
vmm crashes during boot after upgrading a VM from Ubuntu 18 to Ubuntu 20. Host is running 6.8 with all syspatches vmd -dvvv output provides a log entry of: vcpu_run_loop: vm 7 / vcpu 0 run ioctl failed: Bad address and this coincides with a kernel message: vmx_fault_page: uvm_fault returns 14, GPA=0xfe001818, rip=0xb98a31b4 vmd output (piped through uniq to remove thousands of dupe messages), dmesg, vm.conf and vmctl status output follows. [axon@chimaera ~]$ cat vmd.out | uniq startup /etc/vm.conf:4: switch "local" registered /etc/vm.conf:8: switch "bridged" registered vm_register: registering vm 1 /etc/vm.conf:20: vm "OBSD-Stable.vm" registered (disabled) vm_register: registering vm 2 /etc/vm.conf:32: vm "OBSD-Current.vm" registered (disabled) vm_register: registering vm 3 /etc/vm.conf:45: vm "Alpine.vm" registered (disabled) vm_register: registering vm 4 /etc/vm.conf:58: vm "Blackarch.vm" registered (disabled) vm_register: registering vm 5 /etc/vm.conf:70: vm "Ubuntu.vm" registered (disabled) vm_priv_brconfig: interface bridge0 description switch1-local vm_priv_brconfig: interface bridge2 description switch2-bridged vmd_configure: setting staggered start configuration to parallelism: 4 and delay: 30 vmd_configure: starting vms in staggered fashion start_vm_batch: starting batch of 4 vms start_vm_batch: not starting vm OBSD-Stable.vm (disabled) start_vm_batch: not starting vm OBSD-Current.vm (disabled) start_vm_batch: not starting vm Alpine.vm (disabled) start_vm_batch: not starting vm Blackarch.vm (disabled) start_vm_batch: not starting vm Ubuntu.vm (disabled) start_vm_batch: done starting vms config_getconfig: vmm retrieving config config_getconfig: priv retrieving config config_getconfig: control retrieving config vm_opentty: vm Ubuntu.vm tty /dev/ttyp3 uid 1000 gid 4 mode 620 vm_register: registering vm 5 vm_priv_ifconfig: interface tap0 description vm5-if0-Ubuntu.vm vm_priv_ifconfig: switch "local" interface bridge0 add tap0 Ubuntu.vm: started vm 5 successfully, tty /dev/ttyp3 loadfile_bios: loaded BIOS image run_vm: initializing hardware for vm Ubuntu.vm pic_set_elcr: setting level triggered mode for irq 3 pic_set_elcr: setting level triggered mode for irq 5 virtio_init: vm "Ubuntu.vm" vio0 lladdr fe:e1:ba:d0:eb:af pic_set_elcr: setting level triggered mode for irq 6 qc2_open: qcow2 disk version 3 size 42949672960 end 8361213952 snap 0 qc2_open: qcow2 disk version 3 size 42949672960 end 393216 snap 0 pic_set_elcr: setting level triggered mode for irq 7 run_vm: starting vcpu threads for vm Ubuntu.vm vcpu_reset: resetting vcpu 0 for vm 7 run_vm: waiting on events for VM Ubuntu.vm vcpu_exit_fw_cfg: selector 0x vcpu_exit_fw_cfg: selector 0x0001 fw_cfg_handle_dma: selector 0x0004 fw_cfg_handle_dma: selector 0x000d fw_cfg_select: unhandled selector d fw_cfg_handle_dma: selector 0x000f fw_cfg_select: unhandled selector f fw_cfg_handle_dma: selector 0x8000 fw_cfg_select: unhandled selector 8000 fw_cfg_handle_dma: selector 0x8001 fw_cfg_select: unhandled selector 8001 fw_cfg_handle_dma: selector 0x0019 fw_cfg_file_dir: file directory with 1 files 4B 0020 etc/screen-and-debug fw_cfg_handle_dma: selector 0x8003 fw_cfg_select: unhandled selector 8003 i8259_write_datareg: master pic, reset IRQ vector to 0x8 i8259_write_datareg: slave pic, reset IRQ vector to 0x70 fw_cfg_handle_dma: selector 0x000f fw_cfg_select: unhandled selector f fw_cfg_handle_dma: selector 0x0005 fw_cfg_select: unhandled selector 5 vcpu_exit_i8253: channel 0 reset, mode=2, start=65535 fw_cfg_handle_dma: selector 0x0020 fw_cfg_select_file: accessing file etc/screen-and-debug virtio_blk_io: device reset vcpu_process_com_lcr: set baudrate = 115200 vcpu_exit_i8253_misc: counter 2 clear, returning 0x0 vcpu_exit_i8253_misc: discarding data written to PIT misc port vcpu_exit_i8253: channel 2 reset, mode=0, start=65535 vcpu_exit_i8253_misc: counter 2 clear, returning 0x0 vcpu_exit_i8253_misc: discarding data written to PIT misc port vcpu_exit_i8253_misc: counter 2 clear, returning 0x0 vcpu_exit_i8253_misc: counter 2 fired, returning 0x20 vcpu_exit_i8253_misc: discarding data written to PIT misc port i8259_write_datareg: master pic, reset IRQ vector to 0x30 i8259_write_datareg: slave pic, reset IRQ vector to 0x38 vcpu_exit_i8253: channel 0 reset, mode=2, start=4773 virtio_net_io: device reset virtio_blk_io: device reset vcpu_process_com_lcr: set baudrate = 115200 vcpu_run_loop: vm 7 / vcpu 0 run ioctl failed: Bad address vmm_sighdlr: handling signal 20 vmm_sighdlr: terminated vm Ubuntu.vm (id 5) vm_remove: vmm vmm_sighdlr removing vm 5 from running config vm_stop: vmm vmm_sighdlr stopping vm 5 vm_stop: parent vmd_dispatch_vmm stopping vm 5 [axon@chimaera ~]$ dmesg OpenBSD 6.8 (GENERIC.MP) #5: Mon Feb 22 04:36:10 MST 2021 r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ GENERIC.MP real mem = 16774819840 (15997MB) avail mem = 16251387904 (15498MB) random: good seed from bootblocks mpath0 at root scsibus0
Re: Intel wifi ipw showing up but not working
Hi Riccardo, Any feedback regarding the proposed patch below? Thanks, Stefan On Wed, Mar 17, 2021 at 04:09:32PM +0100, Stefan Sperling wrote: > On Mon, Mar 15, 2021 at 02:11:39PM +0100, Riccardo Mottola wrote: > > Stefan Sperling wrote: > > > > That means there is another bug. I will try to find it. > > > Could you show what 'netstat -W ipw0' looks like after an unsuccesful > > > attempt of connecting to a WEP access point? > > > > ipw0: flags=8843 mtu 1500 > > lladdr 00:0c:f1:1f:b2:a0 > > index 1 priority 4 llprio 3 > > groups: wlan > > media: IEEE802.11 autoselect (DS11 mode 11b) > > status: active > > ieee80211: nwid westernesse chan 2 bssid 94:0c:6d:f7:a4:9c -61dBm > > nwkey > > > > > > then I run dhclient > > > > ieee80211 on ipw0: > > 0 input packets with bad version > > 0 input packets too short > > 0 input packets from wrong bssid > > 0 input packet duplicates discarded > > 0 input packets with wrong direction > > 0 input multicast echo packets discarded > > 0 input packets from unassociated station discarded > > 0 input encrypted packets without wep/wpa config discarded > > 0 input unencrypted packets with wep/wpa config discarded > > 0 input wep/wpa packets processing failed > > 0 input packet decapsulations failed > > 2 input management packets discarded > > 0 input control packets discarded > > 0 input packets with truncated rate set > > 0 input packets with missing elements > > 0 input packets with elements too big > > 0 input packets with elements too small > > 0 input packets with invalid channel > > 3 input packets with mismatched channel > > 0 node allocations failed > > 0 input packets with mismatched ssid > > 0 input packets with unsupported auth algorithm > > 0 input authentications failed > > 0 input associations from wrong bssid > > 0 input associations without authentication > > 0 input associations with mismatched capabilities > > 0 input associations without matching rates > > 0 input associations with bad rsn ie > > 0 input deauthentication packets > > 0 input disassociation packets > > 0 input packets with unknown subtype > > 0 input packets failed for lack of mbufs > > 0 input decryptions failed on crc > > 0 input ahdemo management packets discarded > > 0 input packets with bad auth request > > 0 input eapol-key packets > > 0 input eapol-key packets with bad mic > > 0 input eapol-key packets replayed > > 0 input packets with bad tkip mic > > 0 input tkip mic failure notifications > > 0 input packets on unauthenticated port > > 0 output packets failed for lack of mbufs > > 0 output packets failed for no nodes > > 0 output packets of unknown management type > > 0 output packets on unauthenticated port > > 1 active scan started > > 0 passive scans started > > 0 nodes timed out > > 0 failures with no memory for crypto ctx > > 0 ccmp decryption errors > > 0 ccmp replayed frames > > 0 cmac icv errors > > 0 cmac replayed frames > > 0 tkip icv errors > > 0 tkip replays > > 0 pbac errors > > 0 HT negotiation failures because peer does not support MCS 0-7 > > 0 HT negotiation failures because we do not support basic MCS set > > 0 HT negotiation failures because peer uses bad crypto > > 0 HT protection changes > > 0 new input block ack agreements > > 0 new output block ack agreements > > 0 input frames below block ack window start > > 0 input frames above block ack window end > > 0 input block ack window slides > > 0 input block ack window jumps > > 0 duplicate input block ack frames > > 0 expected input block ack frames never arrived > > 0 input block ack window gaps timed out > > 0 input block ack agreements timed out > > 0 output block ack agreements timed out > > > > > > The two "suspect" values im my humble opinion are: > > 2 input management packets discarded > > 3 input packets with mismatched channel > > > > Riccardo > > > > My best guess is that because ipw doesn't bother with calling into > the net80211 newstate function, the interface's link state is never > updated and packets cannot flow. With WPA, link state gets updated > as a side-effect of a successful WPA handshake. > > Does this fix it? > > diff 1ff4cf56fdff3473d72fc4b29d69428c688d47c6 /usr/src > blob - ab16cd51ba6a2efdf89ac588801a1ae2bc714ed5 > file + sys/dev/pci/if_ipw.c > --- sys/dev/pci/if_ipw.c > +++ sys/dev/pci/if_ipw.c > @@ -679,7 +679,11 @@ int > ipw_newstate(struct
Re: Split-horizon dns
just run a second nsd on separate (ip)/port, then use unbound as a router On 3/25/21 12:52 PM, Родин Максим wrote: > Hello, > Is there a way to do split horizon dns using NSD? > I did not find anything similar in man nsd.conf
Layer2 Tunneling Over pppoe(4)
Hi Misc, Can we set up egre(4), etherip(4) or vxlan(4) tunnel over pppoe ? Sent with [ProtonMail](https://protonmail.com) Secure Email.
Re: Layer2 Tunneling Over pppoe(4)
On 2021-03-27, Valdrin Muja wrote: > Can we set up egre(4), etherip(4) or vxlan(4) tunnel over pppoe ? Yes, but watch out for MTU problems especially if you have pppoe on one endpoint and ethernet at the other. See pppoe(4) about RFC 4638, if your provider supports this it may be useful. If not then you may need to lower the MTU on the ethernet interface on the ethernet- connected endpoint to match pppoe's MTU.
Re: Go programs only using one CPU core
On Sat, Mar 27, 2021 at 06:44:52PM +1100, john slee wrote: > Hi, > > > On 2021-03-26, Richard Ulmer wrote: > > > The `go` directive starts a new goroutine, which I would expect to be > > > put into it's own process here. However, using htop(1) I can see, that > > > only one of my two cores gets load. Running the same program on Linux, > > > two cores are utilized. > > That's not how the Go runtime works, I think? > > You shouldn't expect to see a 1:1 mapping of goroutines:OS processes. > > Quoting Russ Cox on the golang-nuts list: > > "This is a popular split but hardly the only definition > of those terms. One reason we use the name goroutine > is to avoid preconceptions about what those terms mean. > For many people threads also connotes management by > the operating system, while goroutines are managed first > by the Go runtime" > > More here: > > https://medium.com/the-polyglot-programmer/what-are-goroutines-and-how-do-they-actually-work-f2a734f6f991 > > Are you actually seeing a problem (an actual problem, not "I can only see > one line for my app in "top") specific to OpenBSD? > > John The actual problem is that htop is buggy on OpenBSD. It is much better to use the native tools, they are more activly maintained. -Otto
Re: Go programs only using one CPU core
Hi, > On 2021-03-26, Richard Ulmer wrote: > > The `go` directive starts a new goroutine, which I would expect to be > > put into it's own process here. However, using htop(1) I can see, that > > only one of my two cores gets load. Running the same program on Linux, > > two cores are utilized. That's not how the Go runtime works, I think? You shouldn't expect to see a 1:1 mapping of goroutines:OS processes. Quoting Russ Cox on the golang-nuts list: "This is a popular split but hardly the only definition of those terms. One reason we use the name goroutine is to avoid preconceptions about what those terms mean. For many people threads also connotes management by the operating system, while goroutines are managed first by the Go runtime" More here: https://medium.com/the-polyglot-programmer/what-are-goroutines-and-how-do-they-actually-work-f2a734f6f991 Are you actually seeing a problem (an actual problem, not "I can only see one line for my app in "top") specific to OpenBSD? John
