[PATCH] /etc/netstart: unquoted command substitution inside arithmetic expression
Index: netstart === RCS file: /cvs/src/etc/netstart,v retrieving revision 1.216 diff -u -p -u -r1.216 netstart --- netstart2 Sep 2021 19:38:20 - 1.216 +++ netstart8 Oct 2021 02:43:30 - @@ -365,7 +365,7 @@ ifmstart "tun tap gif etherip gre egre p if [[ $ip6kernel == YES ]]; then # Ensure IPv6 Duplicate Address Detection (DAD) is completed. count=0 - while ((count++ < 10 && $(sysctl -n net.inet6.ip6.dad_pending) != 0)); do + while ((count++ < 10 && "$(sysctl -n net.inet6.ip6.dad_pending)" != 0)); do sleep 1 done fi
Re: [PATCH] /etc/netstart: unquoted command substitution inside arithmetic expression
On Fri, Oct 08, 2021 at 05:15:36AM +, bm1les wrote: > The first problem is the lack of correctness; that should be enough. > The second problem is that such command actually breaks when run using bsd.rd. netstart(8) has nothing to do in or with bsd.rd, whatever you do: you own all the pieces. Either you manually run /etc/netstart during the installer (who knows why) and/or you run a kernel without IPv6 support. At this point, we don't care -- don't waste time with such mails lacking any trace of reasoning, justification or explanation.
Re: [PATCH] /etc/netstart: unquoted command substitution inside arithmetic expression
On Thu, Oct 7, 2021 at 5:57 PM bm1les wrote: > --- netstart2 Sep 2021 19:38:20 - 1.216 > +++ netstart8 Oct 2021 02:43:30 - > @@ -365,7 +365,7 @@ ifmstart "tun tap gif etherip gre egre p > if [[ $ip6kernel == YES ]]; then > # Ensure IPv6 Duplicate Address Detection (DAD) is completed. > count=0 > - while ((count++ < 10 && $(sysctl -n net.inet6.ip6.dad_pending) != > 0)); do > + while ((count++ < 10 && "$(sysctl -n net.inet6.ip6.dad_pending)" > != 0)); do > sleep 1 > done > fi > I can't figure out what problem you think this could solve. Can you explain the circumstances under which those quotes could make a difference? Philip Guenther
Re: hostctl does not work on Xen
Attached obsd69-dmesg.txt and ubuntu-dmesg.txt. regards. -- ASOU Masato From: Brian Brombacher Date: Thu, 7 Oct 2021 23:21:59 -0400 >> On Oct 7, 2021, at 9:46 PM, Masato Asou wrote: >> >> How can I use the hostctl command on Xen virtual machine? >> >> The hostctl command doesn't work on my Ubuntu (bear metal PC) + Xen + >> OpenBSD 6.9 release as follows: >> $ hostctl device >> hostctl: open: /dev/pvbus0: Operation not supported by device >> $ doas hostctl device >> doas (a...@obsd69.my.domain) password: >> hostctl: open: /dev/pvbus0: Operation not supported by device >> $ ls -l /dev/pvbus0 >> crw-r- 1 root wheel 95, 0 Oct 7 04:21 /dev/pvbus0 >> $ >> >> Could not found pvbus as follows: >> $ dmesg | grep pvbus >> $ >> >> >> On the other hand, hostctl command works correctly for OpenBSD 6.9 >> release on ESXi and Hyper-V. >> >> On ESXi as follows: >> $ hostctl guestinfo.ip >> 192.168.10.113 >> $ dmesg | egrep '(pvbus|vmt)' >> pvbus0 at mainbus0: VMware >> vmt0 at pvbus0 >> $ >> >> On Hyper-V as follows: >> $ hostctl GUest/Parameters/HostName >> DESKTOP-4AL1JIR >> $ dmesg | egrep '(pvbus|hyperv)' >> pvbus0 at mainbus0: Hyper-V 10.0 >> hyperv0 at pvbus0: protocol 4.0, features 0x2e7f >> hyperv0: heartbeat, kvp, shutdown, timesync >> hvs0 at hyperv0 channel 2: ide, protocol 6.2 >> hvs1 at hyperv0 channel 15: scsi, protocol 6.2 >> hvn0 at hyperv0 channel 14: NVS 5.0 NDIS 6.30, address >> 00:15:5d:0a:80:00 >> $ >> -- >> ASOU Masato >> > > Provide a dmesg > OpenBSD 6.9 (GENERIC.MP) #473: Mon Apr 19 10:40:28 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4278026240 (4079MB) avail mem = 4132995072 (3941MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xbd80 (13 entries) bios0: vendor SeaBIOS version "1.13.0-1ubuntu1.1" date 04/01/2014 bios0: QEMU Standard PC (i440FX + PIIX, 1996) acpi0 at bios0: ACPI 1.0 acpi0: sleep states S5 acpi0: tables DSDT FACP APIC acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD EPYC Processor, 3194.29 MHz, 17-01-02 cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,RDRAND,HV,NXE,MMXX,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,SVM,AMCR8,ABM,SSE4A,FSGSBASE,BMI1,SMEP,BMI2,ERMS,MPX,ADX,SMAP,PCOMMIT,CLFLUSHOPT,CLWB,PKU,XSAVEOPT,XGETBV1 cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 999MHz cpu0: mwait min=0, max=0, IBE (bogus) cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD EPYC Processor, 3194.40 MHz, 17-01-02 cpu1: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,RDRAND,HV,NXE,MMXX,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,SVM,AMCR8,ABM,SSE4A,FSGSBASE,BMI1,SMEP,BMI2,ERMS,MPX,ADX,SMAP,PCOMMIT,CLFLUSHOPT,CLWB,PKU,XSAVEOPT,XGETBV1 cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu1: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu1: disabling user TSC (skew=-23997) cpu1: smt 0, core 0, package 1 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD EPYC Processor, 3192.81 MHz, 17-01-02 cpu2: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,RDRAND,HV,NXE,MMXX,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,SVM,AMCR8,ABM,SSE4A,FSGSBASE,BMI1,SMEP,BMI2,ERMS,MPX,ADX,SMAP,PCOMMIT,CLFLUSHOPT,CLWB,PKU,XSAVEOPT,XGETBV1 cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu2: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu2: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu2: smt 0, core 0, package 2 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD EPYC Processor, 3192.23 MHz, 17-01-02 cpu3: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,RDRAND,HV,NXE,MMXX,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,SVM,AMCR8,ABM,SSE4A,FSGSBASE,BMI1,SMEP,BMI2,ERMS,MPX,ADX,SMAP,PCOMMIT,CLFLUSHOPT,CLWB,PKU,XSAVEOPT,XGETBV1 cpu3: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu3: ITLB 255 4KB entries
Re: hostctl does not work on Xen
> On Oct 7, 2021, at 9:46 PM, Masato Asou wrote: > > How can I use the hostctl command on Xen virtual machine? > > The hostctl command doesn't work on my Ubuntu (bear metal PC) + Xen + > OpenBSD 6.9 release as follows: > $ hostctl device > hostctl: open: /dev/pvbus0: Operation not supported by device > $ doas hostctl device > doas (a...@obsd69.my.domain) password: > hostctl: open: /dev/pvbus0: Operation not supported by device > $ ls -l /dev/pvbus0 > crw-r- 1 root wheel 95, 0 Oct 7 04:21 /dev/pvbus0 > $ > > Could not found pvbus as follows: > $ dmesg | grep pvbus > $ > > > On the other hand, hostctl command works correctly for OpenBSD 6.9 > release on ESXi and Hyper-V. > > On ESXi as follows: > $ hostctl guestinfo.ip > 192.168.10.113 > $ dmesg | egrep '(pvbus|vmt)' > pvbus0 at mainbus0: VMware > vmt0 at pvbus0 > $ > > On Hyper-V as follows: > $ hostctl GUest/Parameters/HostName > DESKTOP-4AL1JIR > $ dmesg | egrep '(pvbus|hyperv)' > pvbus0 at mainbus0: Hyper-V 10.0 > hyperv0 at pvbus0: protocol 4.0, features 0x2e7f > hyperv0: heartbeat, kvp, shutdown, timesync > hvs0 at hyperv0 channel 2: ide, protocol 6.2 > hvs1 at hyperv0 channel 15: scsi, protocol 6.2 > hvn0 at hyperv0 channel 14: NVS 5.0 NDIS 6.30, address > 00:15:5d:0a:80:00 > $ > -- > ASOU Masato > Provide a dmesg
hostctl does not work on Xen
How can I use the hostctl command on Xen virtual machine? The hostctl command doesn't work on my Ubuntu (bear metal PC) + Xen + OpenBSD 6.9 release as follows: $ hostctl device hostctl: open: /dev/pvbus0: Operation not supported by device $ doas hostctl device doas (a...@obsd69.my.domain) password: hostctl: open: /dev/pvbus0: Operation not supported by device $ ls -l /dev/pvbus0 crw-r- 1 root wheel 95, 0 Oct 7 04:21 /dev/pvbus0 $ Could not found pvbus as follows: $ dmesg | grep pvbus $ On the other hand, hostctl command works correctly for OpenBSD 6.9 release on ESXi and Hyper-V. On ESXi as follows: $ hostctl guestinfo.ip 192.168.10.113 $ dmesg | egrep '(pvbus|vmt)' pvbus0 at mainbus0: VMware vmt0 at pvbus0 $ On Hyper-V as follows: $ hostctl GUest/Parameters/HostName DESKTOP-4AL1JIR $ dmesg | egrep '(pvbus|hyperv)' pvbus0 at mainbus0: Hyper-V 10.0 hyperv0 at pvbus0: protocol 4.0, features 0x2e7f hyperv0: heartbeat, kvp, shutdown, timesync hvs0 at hyperv0 channel 2: ide, protocol 6.2 hvs1 at hyperv0 channel 15: scsi, protocol 6.2 hvn0 at hyperv0 channel 14: NVS 5.0 NDIS 6.30, address 00:15:5d:0a:80:00 $ -- ASOU Masato
iwm: initial 40Mhz channel support
This patch adds initial support for 40Mhz channels to the iwm driver.
There are a few changes in net80211 to support this feature in RA and
when parsing beacons. The work for net80211 is not yet complete but
more can be done incrementally later. What is missing in particular
is integration with ifconfig to display the use of a 40 MHz channel.
And there is no way to force 40 MHz off at the client side yet.
If the AP announces support for 40MHz we will always use it. Whether or
not we'll need an override to handle some edge case remains to be seen.
Please test this on any supported iwm(4) device. Thanks!
diff 4056ab6b22f0b2cb4f14b2b237355717bf154e4f refs/heads/40mhz
blob - fbf2059a1571c2c55b40fce5ffd7d145ab6b1f21
blob + 3bf02ee0969978149c20498a469c1a2dcf4d7177
--- sys/dev/ic/ar5008.c
+++ sys/dev/ic/ar5008.c
@@ -1150,7 +1150,7 @@ ar5008_tx_process(struct athn_softc *sc, int qid)
/* Update rate control statistics. */
if ((ni->ni_flags & IEEE80211_NODE_HT) && ic->ic_fixed_mcs == -1) {
const struct ieee80211_ht_rateset *rs =
- ieee80211_ra_get_ht_rateset(bf->bf_txmcs,
+ ieee80211_ra_get_ht_rateset(bf->bf_txmcs, 0 /* chan40 */,
ieee80211_node_supports_ht_sgi20(ni));
unsigned int retries = 0, i;
int mcs = bf->bf_txmcs;
blob - 6a145720d3070bd0c1eabae1bedddb5da8fb72a2
blob + 687cbf94f135f6586193b1724e52b80e7f16a529
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -335,9 +335,11 @@ void iwm_init_channel_map(struct iwm_softc *, const
ui
intiwm_mimo_enabled(struct iwm_softc *);
void iwm_setup_ht_rates(struct iwm_softc *);
void iwm_mac_ctxt_task(void *);
+void iwm_phy_ctxt_task(void *);
void iwm_updateprot(struct ieee80211com *);
void iwm_updateslot(struct ieee80211com *);
void iwm_updateedca(struct ieee80211com *);
+void iwm_updatechan(struct ieee80211com *);
void iwm_init_reorder_buffer(struct iwm_reorder_buffer *, uint16_t,
uint16_t);
void iwm_clear_reorder_buffer(struct iwm_softc *, struct iwm_rxba_data *);
@@ -408,13 +410,13 @@ void iwm_rx_bmiss(struct iwm_softc *, struct
iwm_rx_pa
struct iwm_rx_data *);
intiwm_binding_cmd(struct iwm_softc *, struct iwm_node *, uint32_t);
intiwm_phy_ctxt_cmd_uhb(struct iwm_softc *, struct iwm_phy_ctxt *, uint8_t,
- uint8_t, uint32_t, uint32_t);
+ uint8_t, uint32_t, uint32_t, uint8_t);
void iwm_phy_ctxt_cmd_hdr(struct iwm_softc *, struct iwm_phy_ctxt *,
struct iwm_phy_context_cmd *, uint32_t, uint32_t);
void iwm_phy_ctxt_cmd_data(struct iwm_softc *, struct iwm_phy_context_cmd *,
- struct ieee80211_channel *, uint8_t, uint8_t);
+ struct ieee80211_channel *, uint8_t, uint8_t, uint8_t);
intiwm_phy_ctxt_cmd(struct iwm_softc *, struct iwm_phy_ctxt *, uint8_t,
- uint8_t, uint32_t, uint32_t);
+ uint8_t, uint32_t, uint32_t, uint8_t);
intiwm_send_cmd(struct iwm_softc *, struct iwm_host_cmd *);
intiwm_send_cmd_pdu(struct iwm_softc *, uint32_t, uint32_t, uint16_t,
const void *);
@@ -479,7 +481,7 @@ int iwm_umac_scan_abort(struct iwm_softc *);
intiwm_lmac_scan_abort(struct iwm_softc *);
intiwm_scan_abort(struct iwm_softc *);
intiwm_phy_ctxt_update(struct iwm_softc *, struct iwm_phy_ctxt *,
- struct ieee80211_channel *, uint8_t, uint8_t, uint32_t);
+ struct ieee80211_channel *, uint8_t, uint8_t, uint32_t, uint8_t);
intiwm_auth(struct iwm_softc *);
intiwm_deauth(struct iwm_softc *);
intiwm_run(struct iwm_softc *);
@@ -3075,8 +3077,11 @@ iwm_init_channel_map(struct iwm_softc *sc, const uint1
if (!(ch_flags & IWM_NVM_CHANNEL_ACTIVE))
channel->ic_flags |= IEEE80211_CHAN_PASSIVE;
- if (data->sku_cap_11n_enable)
+ if (data->sku_cap_11n_enable) {
channel->ic_flags |= IEEE80211_CHAN_HT;
+ if (ch_flags & IWM_NVM_CHANNEL_40MHZ)
+ channel->ic_flags |= IEEE80211_CHAN_40MHZ;
+ }
}
}
@@ -3409,6 +3414,51 @@ iwm_updateedca(struct ieee80211com *ic)
iwm_add_task(sc, systq, &sc->mac_ctxt_task);
}
+void
+iwm_phy_ctxt_task(void *arg)
+{
+ struct iwm_softc *sc = arg;
+ struct ieee80211com *ic = &sc->sc_ic;
+ struct iwm_node *in = (void *)ic->ic_bss;
+ struct ieee80211_node *ni = &in->in_ni;
+ uint8_t chains, sco;
+ int err, s = splnet();
+
+ if ((sc->sc_flags & IWM_FLAG_SHUTDOWN) ||
+ ic->ic_state != IEEE80211_S_RUN ||
+ in->in_phyctxt == NULL) {
+ refcnt_rele_wake(&sc->task_refs);
+ splx(s);
+ return;
+ }
+
+ chains = iwm_mimo_enabled(sc) ? 2 : 1;
+ if (ieee80211_node_supports_ht_chan40(ni))
+ sco = (ni->ni_htop0 & IEEE80211_HTOP0_SCO_MASK);
+
Re: sigwaitinfo(2) and sigtimedwait(2)
On Sun, Sep 26, 2021 at 02:36:02PM +0200, Mark Kettenis wrote: > > Date: Fri, 24 Sep 2021 19:36:21 +0200 > > From: Rafael Sadowski > > > > I'm trying to port the more KDE stuff so my question is from porter > > perspective. > > > > I need sigwaitinfo(2)/sigtimedwait(2) and I found both functions in > > lib/libc/gen/sigwait.c with the comment "need kernel to fill in more > > siginfo_t bits first". Is the comment still up to date? If no, is it > > possible to unlock the functions? > > Still true. These functions are somewhat underspecified by POSIX so > it isn't really obvious whatadditional bits need to be filled in. > Having examples of code that use these interfaces from ports could > help with that. Not in ports, but in a Lua Unix bindings module I ended up writing an incomplete sigtimedwait emulation for OpenBSD and macOS targets. It's not thread-safe and lacks siginfo support, but sufficed for the most pressing use case, which was to provide a standard (non-kqueue, non-signalfd), simple (i.e. robust to subtle race conditions that might leave a process hung or drop a signal on the floor) mechanism to receive and *clear* signals in Lua code without having to deal with catching and invoking signal handlers asynchronously in Lua or otherwise writing some complex, fiddly mechanism for bridging the language and runtime divide. By emulating sigtimedwait I in fact ended up writing a fiddly and incomplete mechanism for bridging C and Lua runtime behaviors, but only because sigtimedwait didn't exist on OpenBSD or macOS; from the perspective of Lua code relying on POSIX APIs, it still made sense. At least in my case a sigtimedwait lacking siginfo support would have been infinitely better than no sigtimedwait at all. It's the ability to clear a signal without using a signal handler, while also being able to specify a timeout so you don't accidentally end up hung in sigwait, that was most important. Technically sigpending+sigwait would suffice for non-blocking polling (potential thread races notwithstanding), but when looking at POSIX APIs sigtimedwait is the most obvious solution for that as well as some more complex scenarios.
