[wireless] iwx: small code nitpicking and removal of iwx_wait_tx_queues_empty

[Mikhail Pchelin]

Inlined patch does the following:

- removes functions in initialization per style(9) (splnet)
- removes double definition of IWX_NVM_GET_INFO
- removes unused 'ring' variable from iwx_sta_tx_agg_start
- removes unused 'iwx_tid_to_ac' array
- removes iwx_wait_tx_queues_empty function

Regarding the last thing - in our testing of a derivative product we've
found that sometimes the queue has some queued packets, the function has
to wait until all frames will be de-queued, but there are two problems:

1. There is no corresponding wakeup() for a ring, so this tsleep()
should always fail with EWOULDBLOCK, if we have queued frams. This leads
to the situation when needed softc flags aren't cleared, and on the next
join we get a panic with "MAC already added".

2. Linux driver does the flushes a slightly differently:

https://github.com/torvalds/linux/blob/master/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c#L5592

[...]
if (drop) {
if (iwl_mvm_flush_sta(mvm, mvmsta, false))
IWL_ERR(mvm, "flush request fail\n");
} else {
if (iwl_mvm_has_new_tx_api(mvm))
iwl_mvm_wait_sta_queues_empty(mvm, mvmsta);
else /* only used for !iwl_mvm_has_new_tx_api() below */
msk |= mvmsta->tfd_queue_msk;
}
[...]

'drop' var is from Linux 80211 API - "If the parameter drop is set to
true, pending frames may be dropped." per
https://www.kernel.org/doc/html/v6.5/driver-api/80211/mac80211.html

As I can see OpenBSD driver tries to do both things, I propose to drop
this iwx_wait_tx_queues_empty function and follow 'drop = true' case
from the linux driver. Removal of this function has fixed panics for us.

Debugging and code have been sponsored by Serenity Cybersecurity, LLC.

diff /usr/src
commit - a8cd26ec98e16ab36053bf0a84ae2e4d88c286ea
path + /usr/src
blob - 612b68e3c6982a8ed4c0bcaca01d8c4e0a81d115
file + sys/dev/pci/if_iwx.c
--- sys/dev/pci/if_iwx.c
+++ sys/dev/pci/if_iwx.c
@@ -402,7 +402,6 @@ voidiwx_tx_update_byte_tbl(struct iwx_softc *, 
struct
uint16_t, uint16_t);
 intiwx_tx(struct iwx_softc *, struct mbuf *, struct ieee80211_node *);
 intiwx_flush_sta_tids(struct iwx_softc *, int, uint16_t);
-intiwx_wait_tx_queues_empty(struct iwx_softc *);
 intiwx_drain_sta(struct iwx_softc *sc, struct iwx_node *, int);
 intiwx_flush_sta(struct iwx_softc *, struct iwx_node *);
 intiwx_beacon_filter_send_cmd(struct iwx_softc *,
@@ -2792,18 +2791,6 @@ iwx_nic_init(struct iwx_softc *sc)
return 0;
 }
 
-/* Map a TID to an ieee80211_edca_ac category. */
-const uint8_t iwx_tid_to_ac[IWX_MAX_TID_COUNT] = {
-   EDCA_AC_BE,
-   EDCA_AC_BK,
-   EDCA_AC_BK,
-   EDCA_AC_BE,
-   EDCA_AC_VI,
-   EDCA_AC_VI,
-   EDCA_AC_VO,
-   EDCA_AC_VO,
-};
-
 /* Map ieee80211_edca_ac categories to firmware Tx FIFO. */
 const uint8_t iwx_ac_to_tx_fifo[] = {
IWX_GEN2_EDCA_TX_FIFO_BE,
@@ -3548,8 +3535,10 @@ iwx_mac_ctxt_task(void *arg)
struct iwx_softc *sc = arg;
struct ieee80211com *ic = >sc_ic;
struct iwx_node *in = (void *)ic->ic_bss;
-   int err, s = splnet();
+   int err, s;
 
+   s = splnet();
+
if ((sc->sc_flags & IWX_FLAG_SHUTDOWN) ||
ic->ic_state != IEEE80211_S_RUN) {
refcnt_rele_wake(>task_refs);
@@ -3575,8 +3564,10 @@ iwx_phy_ctxt_task(void *arg)
struct iwx_node *in = (void *)ic->ic_bss;
struct ieee80211_node *ni = >in_ni;
uint8_t chains, sco, vht_chan_width;
-   int err, s = splnet();
+   int err, s;
 
+   s = splnet();
+
if ((sc->sc_flags & IWX_FLAG_SHUTDOWN) ||
ic->ic_state != IEEE80211_S_RUN ||
in->in_phyctxt == NULL) {
@@ -3668,7 +3659,6 @@ iwx_sta_tx_agg_start(struct iwx_softc *sc, struct ieee
struct ieee80211com *ic = >sc_ic;
struct ieee80211_tx_ba *ba;
int err, qid;
-   struct iwx_tx_ring *ring;
 
/* Ensure we can map this TID to an aggregation queue. */
if (tid >= IWX_MAX_TID_COUNT)
@@ -3711,7 +3701,6 @@ iwx_sta_tx_agg_start(struct iwx_softc *sc, struct ieee
 
ba->ba_winend = (ba->ba_winstart + ba->ba_winsize - 1) & 0xfff;
 
-   ring = >txq[qid];
ba->ba_timeout_val = 0;
ieee80211_addba_resp_accept(ic, ni, tid);
sc->aggqid[tid] = qid;
@@ -3723,9 +3712,11 @@ iwx_ba_task(void *arg)
struct iwx_softc *sc = arg;
struct ieee80211com *ic = >sc_ic;
struct ieee80211_node *ni = ic->ic_bss;
-   int s = splnet();
+   int s;
int tid;
 
+   s = splnet();
+
for (tid = 0; tid < IWX_MAX_TID_COUNT; tid++) {
if (sc->sc_flags & IWX_FLAG_SHUTDOWN)
break;
@@ -6429,31 +6420,7 @@ out:
return err;
 }
 
-#define IWX_FLUSH_WAIT_MS  2000
-
 int

Re: any work on port of rtw89? (realtek 8852 AE/BE/CE)

[Mikhail Pchelin]

On Sun, Oct 01, 2023 at 11:17:32AM -0600, Theo de Raadt wrote:
> >I'm interested if anyone has already done any research or code regarding
> >these drivers to save double effort.
> 
> Over in freebsd land won't you just use the linux drivers, to "save double
> effort"?  And how's that going.

Linux80211 is a wrong approach to anyone who has ever cared about
software stability, but I don't care about those decisions, this layer
is sponsored work with specially appointed person, I can only wish a
good luck to him.

any work on port of rtw89? (realtek 8852 AE/BE/CE)

[Mikhail Pchelin]

I'm interested if anyone has already done any research or code regarding
these drivers to save double effort.

Re: Have sysupgrade run fw_update -vv

[Mikhail]

On Sun, Aug 13, 2023 at 10:02:26PM -0700, Kevin Williams wrote:
> What about giving sysupgrade the same verbosity options as fw_update?
> This would mean -v and -vv I sysupgrade would pass through the same
> options to fw_update.
>
> And for the installer, maybe another question: “Verbose download &
> install progress?” Or no, as default.

I think it's overengineering for such simple task.

Regarding installer - probably simple notice about what's happening will
be enough too - user will either understand that some network activity
in process or will get immediate message that installer can't resolve
whatever etc.

Proposed patch:

diff /usr/src
commit - 8afcf90fb39e4a84606e93137c2b6c20f44312cb
path + /usr/src
blob - 4386ec9873c433a99fa83b9a9091c06bd952
file + distrib/miniroot/install.sub
--- distrib/miniroot/install.sub
+++ distrib/miniroot/install.sub
@@ -3008,7 +3008,9 @@ __EOT
 fi
 __EOT
 
-   [ -x /mnt/usr/sbin/fw_update ] && DESTDIR=/mnt /mnt/usr/sbin/fw_update
+   [ -x /mnt/usr/sbin/fw_update ] &&
+   echo "Downloading firmware..." &&
+   DESTDIR=/mnt /mnt/usr/sbin/fw_update
 
if [[ -f $_kernel_dir.tgz ]]; then
echo -n "Relinking to create unique kernel..."

Re: Have sysupgrade run fw_update -vv

[Mikhail]

On Sun, Aug 13, 2023 at 11:44:33AM -0700, Andrew Hewus Fresh wrote:
> My laptop doesn't have the fastest wifi and sysupgrade already uses a
> progress bar to show what it's doing, so I'd really like to provide more
> feedback on what it is doing:
> 
> $ doas fw_update -d intel
> fw_update: deleted intel
> $ time doas fw_update 
> fw_update: added intel; updated none; kept inteldrm,iwm,uvideo,vmm
> 0m58.45s real 0m00.51s user 0m00.35s system
> $ doas fw_update -d intel 
> fw_update: deleted intel
> $ time doas fw_update -vv 
> Detect firmware ... found.
> Get/Verify SHA256.sig   100% |**|  2371   00:00   
>  
> Get/Verify intel-firmware-2023080... 100% |*| 12155 KB01:04   
>  
> Install intel-firmware-2023080... 100% || 12155 KB00:00   
>  
> fw_update: added intel; updated none; kept inteldrm,iwm,uvideo,vmm
> 1m17.46s real 0m00.56s user 0m00.34s system
> 
> 
> Comments, OK?
> 
> Index: usr.sbin/sysupgrade/sysupgrade.sh
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> retrieving revision 1.48
> diff -u -p -r1.48 sysupgrade.sh
> --- usr.sbin/sysupgrade/sysupgrade.sh 8 Jun 2022 09:03:11 -   1.48
> +++ usr.sbin/sysupgrade/sysupgrade.sh 13 Aug 2023 18:22:02 -
> @@ -205,7 +205,7 @@ if [[ ${_NEXTKERNV[1]} == '-current' ]];
>  else
>   FW_URL=http://firmware.openbsd.org/firmware/${_NEXTKERNV[0]}/
>  fi
> -VNAME="${_NEXTKERNV[0]}" fw_update -p ${FW_URL} || true
> +VNAME="${_NEXTKERNV[0]}" fw_update -vv -p ${FW_URL} || true
>  
>  install -F -m 700 bsd.rd /bsd.upgrade
>  logger -t sysupgrade -p kern.info "installed new /bsd.upgrade. Old kernel 
> version: $(sysctl -n kern.version)"

This will be useful in the installer too, when I first installed OpenBSD
with network connection I thought installation was stuck after
"Multiprocessor machine; using bsd.mp instead of bsd.", only after
some time I understood that the installer was downloading firmware.

(untested patch)

diff /usr/src
commit - 8afcf90fb39e4a84606e93137c2b6c20f44312cb
path + /usr/src
blob - 4386ec9873c433a99fa83b9a9091c06bd952
file + distrib/miniroot/install.sub
--- distrib/miniroot/install.sub
+++ distrib/miniroot/install.sub
@@ -3008,7 +3008,7 @@ __EOT
 fi
 __EOT
 
-   [ -x /mnt/usr/sbin/fw_update ] && DESTDIR=/mnt /mnt/usr/sbin/fw_update
+   [ -x /mnt/usr/sbin/fw_update ] && DESTDIR=/mnt /mnt/usr/sbin/fw_update 
-vv
 
if [[ -f $_kernel_dir.tgz ]]; then
echo -n "Relinking to create unique kernel..."

Re: uvm_meter: remove wakeup of proc0

[Mikhail]

On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote:
> On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote:
> > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote:
> > > This is the culprit:
> > > 
> > > schedule_timeout_uninterruptible(long timeout)
> > > {
> > > tsleep(curproc, PWAIT, "schtou", timeout);
> > > return 0;
> > > }
> > > 
> > 
> > Please give this a try. I think on initialization
> > intel_dp_wait_source_oui() is called before intel_dp->last_oui_write is
> > set and this results in a 10min timeout because our jiffies are set to
> > ULONG_MAX - (10 * 60 * HZ);
> 
> After talking with kettenis@ I think the following diff is better.
> Starting with 0 jiffies should fix this issue.
> Unless we want to do the linux madness and set it to
>   ((unsigned long)(unsigned int) (-300*HZ))

This patch on top of the original one doesn't hang my machine anymore.

Re: uvm_meter: remove wakeup of proc0

[Mikhail]

On Sat, Jul 29, 2023 at 11:16:14AM +0200, Claudio Jeker wrote:
> proc0 aka the swapper does not do anything. So there is no need to wake it
> up. Now the problem is that last time this was tried some inteldrm systems
> did hang during bootup because the drm code unexpectedly depended on this
> wakeup.
> 
> I think I fixed all possible cases of this in the drm stack and so it is
> time to retry this. People with affected machines please give this a try.

With this patch my machine hangs on "root on sd0a...", the patch was
applied on top of 7b0c383483702d9a26856c2b4754abb44950ed82, dmesg of the
last successful boot: 

OpenBSD 7.3-current (GENERIC.MP) #1320: Fri Jul 28 11:14:52 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8363110400 (7975MB)
avail mem = 8089972736 (7715MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x439de000 (70 entries)
bios0: vendor LENOVO version "GCCN32WW" date 11/18/2022
bios0: LENOVO 81X7
efi0 at bios0: UEFI 2.7
efi0: INSYDE Corp. rev 0x59474032
acpi0 at bios0: ACPI 6.1Undefined scope: \\_SB_.PCI0

acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT TPM2 MSDM NHLT SSDT 
LPIT WSMT SSDT SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT FPDT PTDT 
BGRT
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) XHCI(S4) XDCI(S4) 
HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
PXSX(S4) RP05(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,DOITM,FBSDP_NO,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 38MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.58 MHz, 06-8c-01
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,DOITM,FBSDP_NO,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,DOITM,FBSDP_NO,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01
cpu3: 

Re: [installer] default answer to "Is the disk partition already mounted?"

[Mikhail]

On Sat, Apr 01, 2023 at 04:33:39PM +0300, Mikhail wrote:
> Currently default answer for the question is 'yes', which is not true
> for install case, but correct for upgrade one.
> 
> Changing default answer depending on the mode of the installer looks
> like a good approach. Idea by Christian (naddy@), implementation and
> testing are mine.

In conversation with Klemens (kn@) new iteration has been born, it
follows to what Omar (op@) has suggested - we're not trying to change
the default answer for all cases, since no one complained for all these
years, but just flip default for installation mode, which should save
some keystrokes and back-and-forth movement for novice users.

Next attempt (with input from kn@):

diff /usr/src
commit - 3f266bdacd577948d2ae789cfe31cc2939a83cf9
path + /usr/src
blob - 5919eeece326bed27a65b43e96be50e7c72471e1
file + distrib/miniroot/install.sub
--- distrib/miniroot/install.sub
+++ distrib/miniroot/install.sub
@@ -2043,7 +2043,12 @@ install_disk() {
 # Install sets from disk.
 # Ask for the disk device containing the set files.
 install_disk() {
-   if ! ask_yn "Is the disk partition already mounted?" yes; then
+   local _ismounted=yes
+
+   # No partitions are mounted prior to regular installation.
+   [[ $MODE == install ]] && _ismounted=no
+
+   if ! ask_yn "Is the disk partition already mounted?" $_ismounted; then
ask_which "disk" "contains the $MODE media" \
'$(bsort $(get_dkdevs))' \
'$(get_dkdevs_uninitialized)'

Re: [installer] default answer to "Is the disk partition already mounted?"

[Mikhail]

On Sat, Apr 01, 2023 at 04:31:59PM +, Klemens Nanni wrote:
> 01.04.2023 13:33, Mikhail пишет:
> $_answer may be unset, but you still pass it and thus rely on ask_yn()'s
> default 'no' answer.
> 
> I'd just default-initialise up front and flip if conditions are met.
> This should read and reflect your intentions more clearly:
> 
>   local _answer=no
> 
>   [[ $MODE == upgrade ]] && _answer=yes

I agree with your and Omar's comments regarding the logic, here is
revised patch:

diff /usr/src
commit - 05633f8622c7ca2ec993bbb49b8324988d6be874
path + /usr/src
blob - 537a9ae361201fb685525ac31c6ab7cf374799a4
file + distrib/miniroot/install.sub
--- distrib/miniroot/install.sub
+++ distrib/miniroot/install.sub
@@ -2042,7 +2042,12 @@ install_disk() {
 # Install sets from disk.
 # Ask for the disk device containing the set files.
 install_disk() {
-   if ! ask_yn "Is the disk partition already mounted?" yes; then
+   local _answer=no
+
+   # In upgrade mode root disk's /etc/fstab are automounted
+   [[ $MODE == upgrade ]] && _answer=yes
+
+   if ! ask_yn "Is the disk partition already mounted?" $_answer; then
ask_which "disk" "contains the $MODE media" \
'$(bsort $(get_dkdevs))' \
'$(get_dkdevs_uninitialized)'

[installer] default answer to "Is the disk partition already mounted?"

[Mikhail]

Currently default answer for the question is 'yes', which is not true
for install case, but correct for upgrade one.

Changing default answer depending on the mode of the installer looks
like a good approach. Idea by Christian (naddy@), implementation and
testing are mine.

diff /usr/src
commit - c5d97e146b0b84b5aaf0732c7ffb8b845cadd04d
path + /usr/src
blob - c5d0d7f129960a410a8c89af1d480135f6a18d09
file + distrib/miniroot/install.sub
--- distrib/miniroot/install.sub
+++ distrib/miniroot/install.sub
@@ -2042,7 +2042,12 @@ install_disk() {
 # Install sets from disk.
 # Ask for the disk device containing the set files.
 install_disk() {
-   if ! ask_yn "Is the disk partition already mounted?" yes; then
+   local _answer
+
+   # In installation mode installer doesn't automount partitions
+   [[ $MODE == install ]] || _answer=yes
+
+   if ! ask_yn "Is the disk partition already mounted?" $_answer; then
ask_which "disk" "contains the $MODE media" \
'$(bsort $(get_dkdevs))' \
'$(get_dkdevs_uninitialized)'

pledge utility

[Mikhail]

While reviewing Bob's presentation[1] on pledge and unveil I came across
his idea about pledge utility which will take unveil paths, pledge
promises and execute a program with the restrictions (slide 12).

What do you think about the idea and implementation?

[1] - https://www.openbsd.org/papers/BeckPledgeUnveilBSDCan2018.pdf

#include 
#include 
#include 
#include 
#include 

void
usage(void)
{
fprintf(stderr, "%s: [-p path mode ...] <-P \"promises\"> "
" [arguments]\n", getprogname());
exit(1);
}

int
main(int argc, char **argv)
{
int i, j, k, Pflag = 0, pflag = 0;
char promises[1024] = { 0 };
char **paths = NULL;
char **modes = NULL;

for (i = 1; i < argc; i++) {
if (strcmp(argv[i], "-P") == 0) {
if (Pflag)
usage();
Pflag = 1;
strlcpy(promises, argv[++i], sizeof(promises));
break;
}
if (strcmp(argv[i], "-p") == 0) {
if (pflag)
usage();
pflag = 1;
i++;
j = 0;
while (argv[i] != NULL && strcmp(argv[i], "-P") != 0) {
paths = reallocarray(paths, j+1,
sizeof(*paths));
modes = reallocarray(modes, j+1,
sizeof(*modes));
paths[j] = strdup(argv[i++]);
/* We've advanced 'i', check if it's not EOL */
if (argv[i] == NULL)
usage();
modes[j++] = strdup(argv[i++]);
}
/* If we have no args after -p */
if (j == 0)
usage();
/* Last cycle advanced i to -P, shift it back */
i--;
continue;
}
}

/* -P is mandatory */
if (Pflag == 0)
usage();

if (pledge("stdio exec unveil", promises) == -1)
err(1, "pledge");

if (pflag) {
for (k = 0; k < j; k++) {
if (unveil(paths[k], modes[k]) == -1)
err(1, "unveil: %s mode %s", paths[k],
modes[k]);
}
unveil(NULL, NULL);
}

char *progname = argv[++i];
char **progargs = [i];
if (execvp(progname, progargs) == -1)
err(1, "execvp: %s", progname);

return (0);
}

Re: iwx(4) -77 firmware diff for testing

[Mikhail]

On Wed, Feb 22, 2023 at 03:31:28PM +0100, Stefan Sperling wrote:
> Below is my work-in-progress diff to update iwx(4) to latest firmware.
> Every system tracking -current should already have the new -77 firmware 
> images.
> 
> The new images contain security fixes of (to me) unknown severity.
> Unfortunately there have been quite a number of firmware API changes since
> our last upgrade and it took me quite some time to get all the required new
> bits in place and arrive at an operational state.
> 
> While testing please enable additional debug output with:
>   ifconfig iwx0 debug
> To activate it at boot time: echo debug >> /etc/hostname.iwx0
> 
> There are some known issue with occasional firmware errors.
> My devices eventually manage to connect and work regardless. If you see a
> firmware error in dmesg please include the extra information shown in dmesg
> after enabling the debugging mode as above. This information is hidden by
> default and the driver will only print "fatal firmware error" to dmesg
> without more context, but the extra context is needed for debugging.
> 
> If you hit an error which looks like this:
> 
>iwx0: firmware parse error 22, section type 19
>iwx0: failed to load init firmware
> 
> Then you will need to increase this constant in if_iwxvar.h until you
> get past the error:
> 
> #define IWX_UCODE_SECT_MAX 56
> 
> It will probably just need a +1 or +2.
> It is possible to find the required maximum by parsing all the
> firmware files, but I haven't gotten around to that yet.
> 
> Tested and known to work with occasional firmware errors on:
> 
> iwx0 at pci2 dev 0 function 0 "Intel Wi-Fi 6 AX200" rev 0x1a, msix
> iwx0: hw rev 0x340, fw 77.f92b5fed.0
> 
> iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX201" rev 0x00, msix
> iwx0: hw rev 0x350, fw 77.f92b5fed.0,
> 
> iwx0 at pci4 dev 0 function 0 "Intel Wi-Fi 6 AX210" rev 0x1a, msix
> iwx0: hw rev 0x420, fw 77.f92b5fed.0, pnvm dbd9582f,

iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX201" rev 0x20, msix
iwx0: hw rev 0x350, fw 77.f92b5fed.0, address X

iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX211" rev 0x01, msix
iwx0: hw rev 0x370, fw 77.f92b5fed.0, pnvm dbd9582f, address X

Working fine. AX211 required IWX_UCODE_SECT_MAX 57 to start.

Tested with usual activity and iperf3 --bidir overnight.

Re: [xenocara] xenodm.man fix

[Mikhail]

On Sat, Feb 18, 2023 at 08:00:26AM +0100, Matthieu Herrb wrote:
> On Fri, Feb 17, 2023 at 11:52:44AM +, Laurence Tratt wrote:
> > On Thu, Feb 16, 2023 at 09:29:53PM +0300, Mikhail wrote:
> > 
> > Hello Mikhail,
> > 
> > > /etc/X11/xenodm/Xsession file has a check for x bit
> > 
> > Yes, this one caught me out a few years back:
> > 
> >   https://marc.info/?l=openbsd-bugs=162737223625768=2
> > 
> > In subsequent discussions with Matthieu and Theo, I *think* the
> > eventual thought was that it would be better to get rid of the `-x`
> > check. I might be misremembering that, though.
> > 
> 
> I'm fine with not runing the script if not executable.  I don't
> remember exactly why I didn't do it when you brought the issue up in
> 2021. But I prefer to use the fallback session when the script exists
> and isn't executable rather than letting the session fail immediatly.
> 
> ok?

It will break setups which people have working now, but what do we get
in return? Just to be complaint with the docs?

[xenocara] xenodm.man fix

[Mikhail]

/etc/X11/xenodm/Xsession file has a check for x bit

startup=$HOME/.xsession
[...]
if [ -s "$startup" ]; then
if [ -x "$startup" ]; then
"$startup"
else
/bin/sh "$startup"
fi
[...]

diff /var/git/xenocara
commit - 1322100d794a22f2ed024540585b4b8cbd0ebd3e
path + /var/git/xenocara
blob - 748a8c16624bec701895533a501ee9d54f6843a3
file + app/xenodm/man/xenodm.man
--- app/xenodm/man/xenodm.man
+++ app/xenodm/man/xenodm.man
@@ -1118,7 +1118,6 @@ Don't forget that the file must have execute permissio
 The user's
 .Pa .xsession
 file might look something like this example.
-Don't forget that the file must have execute permission.
 .Bd -literal -offset Ds
 #! /bin/sh
 xrdb -merge "$HOME/.Xresources"

typo in if_urtwn.c

[Mikhail]

diff /usr/src
commit - 810555b25bf5444b727efabdb7f5ed0506159a65
path + /usr/src
blob - a615fdea5fca69bcd980bdc027050f59be89d0ed
file + sys/dev/usb/if_urtwn.c
--- sys/dev/usb/if_urtwn.c
+++ sys/dev/usb/if_urtwn.c
@@ -1659,7 +1659,7 @@ urtwn_tx(void *cookie, struct mbuf *m, struct ieee8021
qos = ieee80211_get_qos(wh);
tid = qos & IEEE80211_QOS_TID;
qid = ieee80211_up_to_ac(ic, tid);
-   } else if ((wh->i_fc[1] & IEEE80211_FC0_TYPE_MASK)
+   } else if ((wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK)
!= IEEE80211_FC0_TYPE_DATA) {
/* Use AC VO for management frames. */
qid = EDCA_AC_VO;

Re: [acpi] patch to run _INI methods before table devices attach

[Mikhail]

On Sat, Oct 22, 2022 at 01:41:23PM +0200, Mark Kettenis wrote:
> Identifying which of the "table-driven" device attachments is the
> culprit here might help.

I have following tables:

acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT TPM2 MSDM NHLT SSDT 
LPIT WSMT SSDT SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT FPDT PTDT 
BGRT

if I run

aml_find_node(sc->sc_root, "_INI", acpi_inidev, sc);

here:
DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT TPM2 MSDM NHLT SSDT LPIT WSMT SSDT 
SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT FPDT PTDT BGRT
^
brightness keys works, if here (right before ECDT):

DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT TPM2 MSDM NHLT SSDT LPIT WSMT SSDT 
SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT FPDT PTDT BGRT

  ^

still works, but if I run it here (after ECDT):


DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT TPM2 MSDM NHLT SSDT LPIT WSMT SSDT 
SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT FPDT PTDT BGRT

   ^
it doesn't work.

Re: [acpi] patch for embedded controller detection

[Mikhail]

On Sat, Oct 08, 2022 at 03:10:18PM +0300, Mikhail wrote:
> I'm troubleshooting battery status for my Lenovo IdeaPad 3 14ITL05, on
> latest -current it shows that battery is absent and AC not connected:
> 
> Battery state: absent, 0% remaining, unknown life estimate
> AC adapter state: not connected
> Performance adjustment mode: manual (2900 MHz)

Thinking about this a little bit more, I thought that we can just check
if EC_ID from ECDT is actually present, and if it's not - fail the
attach.

With the patch I see two ECs in my dmesg:

acpiec0 at acpi0
acpiec0: failed to find EC_ID
acpiec0: Failed to read resource settings
[...]
acpiec1 at acpi0

which is of course wrong.

But these things works:

 - apm status
 - capslock led
 - brightness keys

diff /usr/src
commit - 924a158ae16809f41bf3f03c54fb2a8cdfa1d6e8
path + /usr/src
blob - 5ef24d5179de52d5321e578b3b73dd9524e7c1de
file + sys/dev/acpi/acpiec.c
--- sys/dev/acpi/acpiec.c
+++ sys/dev/acpi/acpiec.c
@@ -429,6 +429,14 @@ acpiec_getcrs(struct acpiec_softc *sc, struct acpi_att
 
/* Check if this is ECDT initialization */
if (ecdt) {
+   /* Get devnode from header */
+   sc->sc_devnode = aml_searchname(sc->sc_acpi->sc_root,
+   ecdt->ec_id);
+   if (sc->sc_devnode == NULL) {
+   printf("%s: failed to find EC_ID\n", DEVNAME(sc));
+   return (1);
+   }
+
/* Get GPE, Data and Control segments */
sc->sc_gpe = ecdt->gpe_bit;
 
@@ -444,10 +452,6 @@ acpiec_getcrs(struct acpiec_softc *sc, struct acpi_att
sc->sc_data_bt = sc->sc_acpi->sc_memt;
sc->sc_ec_data = ecdt->ec_data.address;
 
-   /* Get devnode from header */
-   sc->sc_devnode = aml_searchname(sc->sc_acpi->sc_root,
-   ecdt->ec_id);
-
goto ecdtdone;
}
 

Re: [acpi] patch to run _INI methods before table devices attach

[Mikhail]

On Sat, Oct 22, 2022 at 01:41:23PM +0200, Mark Kettenis wrote:
> > I continue my fight with ACPI on Lenovo IdeaPad 3 14ITL05, now, when
> > battery status problem has been resolved[1] next target is backlight
> > brightness keys.
> 
> Well it hasn't been resolved yet.  The firmware is clearly broken, and
> we still have to find a workaround that doesn't break other
> machines...

If I replace

sc->sc_devnode = aml_searchname(sc->sc_acpi->sc_root, ecdt->ec_id);

with

sc->sc_devnode = aml_searchname(sc->sc_acpi->sc_root, "\\_SB.PC00.LPCB.EC0");

(Firmware has "\_SB.PC00.LPCB.H_EC", and that's what I meant by
"explicitly specified correct EC_ID")

in this code:

430 /* Check if this is ECDT initialization */
431 if (ecdt) {
432 /* Get GPE, Data and Control segments */
433 sc->sc_gpe = ecdt->gpe_bit;
434 
435 if (ecdt->ec_control.address_space_id == GAS_SYSTEM_IOSPACE)
436 sc->sc_cmd_bt = sc->sc_acpi->sc_iot;
437 else
438 sc->sc_cmd_bt = sc->sc_acpi->sc_memt;
439 sc->sc_ec_sc = ecdt->ec_control.address;
440 
441 if (ecdt->ec_data.address_space_id == GAS_SYSTEM_IOSPACE)
442 sc->sc_data_bt = sc->sc_acpi->sc_iot;
443 else
444 sc->sc_data_bt = sc->sc_acpi->sc_memt;
445 sc->sc_ec_data = ecdt->ec_data.address;
446 
447 /* Get devnode from header */
448 sc->sc_devnode = aml_searchname(sc->sc_acpi->sc_root,
449 ecdt->ec_id);
450 
451 goto ecdtdone;
452 }

I can see battery status, so only firmware has to be patched, no other
modifications to OpenBSD are necessary, ECDT attach will work,
brightness problem looks like a different one.

Lenovo guy told that he will "inform needed departments" regarding wrong
EC_ID.

> > With the inlined patch and explicitly specified correct EC_ID in the
> > code I'm able to control brightness with functional keys. The patch
> > moves _INI methods evaluation "immediately before" table-defined device
> > attach, before the patch it was "immediately after".
> > 
> > Only reference which I found in the spec is [2], and it doesn't make it
> > clear when _INI should be eval'ed: "This control method is located under
> > a device object and is run only when OSPM loads a description table."
> > Another reference in the same chapter: "_INI - Device initialization
> > method that is run shortly after ACPI has been enabled." Term "shortly"
> > isn't very precise description of when to run _INI either.
> 
> Welcome to ACPI.  More than 1000 pages of documentation and still
> woefully underspecified.
> 
> Your interpretation doesn't make a lot of sense to me.  The whole
> purpose of the tables is to have certain things (such as access to PCI
> config space or accessing the Embedded Controller) work before running
> any of the AML methods.
> 
> > I understand that this isn't very grown up engineering attitude "I do
> > this and everything works", but currently I lack explanation why this
> > approach helps.  If anyone has ideas how to investigate this further - I
> > will be appreciated.
> 
> Identifying which of the "table-driven" device attachments is the
> culprit here might help.

Thank you, I'll give it a shot on a workweek.

[acpi] patch to run _INI methods before table devices attach

[Mikhail]

I continue my fight with ACPI on Lenovo IdeaPad 3 14ITL05, now, when
battery status problem has been resolved[1] next target is backlight
brightness keys.

With the inlined patch and explicitly specified correct EC_ID in the
code I'm able to control brightness with functional keys. The patch
moves _INI methods evaluation "immediately before" table-defined device
attach, before the patch it was "immediately after".

Only reference which I found in the spec is [2], and it doesn't make it
clear when _INI should be eval'ed: "This control method is located under
a device object and is run only when OSPM loads a description table."
Another reference in the same chapter: "_INI - Device initialization
method that is run shortly after ACPI has been enabled." Term "shortly"
isn't very precise description of when to run _INI either.

I understand that this isn't very grown up engineering attitude "I do
this and everything works", but currently I lack explanation why this
approach helps.  If anyone has ideas how to investigate this further - I
will be appreciated.

If your brightness keys or other ACPI stuff doesn't work, you can give
this patch a try.

Will be grateful for testing and reviews.

[1] - https://marc.info/?l=openbsd-tech=166600434429788=2
[2] - https://uefi.org/specs/ACPI/6.5/06_Device_Configuration.html#ini-init

diff /usr/src
commit - 3fb2197480c345a19f2098d1b787c28b9c717dcb
path + /usr/src
blob - fc3c1d160ee0ccc7217d77be184c253b29422983
file + sys/dev/acpi/acpi.c
--- sys/dev/acpi/acpi.c
+++ sys/dev/acpi/acpi.c
@@ -1203,6 +1203,9 @@ acpi_attach_common(struct acpi_softc *sc, paddr_t base
}
 #endif /* SMALL_KERNEL */
 
+   /* initialize runtime environment */
+   aml_find_node(sc->sc_root, "_INI", acpi_inidev, sc);
+
/*
 * Attach table-defined devices
 */
@@ -1217,9 +1220,6 @@ acpi_attach_common(struct acpi_softc *sc, paddr_t base
config_found_sm(>sc_dev, , acpi_print, acpi_submatch);
}
 
-   /* initialize runtime environment */
-   aml_find_node(sc->sc_root, "_INI", acpi_inidev, sc);
-
/* Get PCI mapping */
aml_walknodes(sc->sc_root, AML_WALK_PRE, acpi_getpci, sc);
 

Re: [acpi] patch for embedded controller detection

[Mikhail]

On Sat, Oct 08, 2022 at 03:10:18PM +0300, Mikhail wrote:
> I'm troubleshooting battery status for my Lenovo IdeaPad 3 14ITL05, on
> latest -current it shows that battery is absent and AC not connected:
> 
> Battery state: absent, 0% remaining, unknown life estimate
> AC adapter state: not connected
> Performance adjustment mode: manual (2900 MHz)

Digging further, third attempt.

The sequence of actions is following:

first acpi_attach_common() tries to attach EC through ECDT with the
following code:

1206 /*
1207  * Attach table-defined devices
1208  */
1209 SIMPLEQ_FOREACH(entry, >sc_tables, q_next) {
1210 struct acpi_attach_args aaa;
1211 
1212 memset(, 0, sizeof(aaa));
1213 aaa.aaa_iot = sc->sc_iot;
1214 aaa.aaa_memt = sc->sc_memt;
1215 aaa.aaa_dmat = sc->sc_ci_dmat;
1216 aaa.aaa_table = entry->q_table;
1217 config_found_sm(>sc_dev, , acpi_print, 
acpi_submatch);
1218 }

I see no way how we can set aaa.aaa_node with this code, so it's zero
after memset().

config_found_sm eventually calls acpiec_match for ECDT table, since ECDT
table is presented on my laptop, acpiec_match wins with this probe:

261 /* Check for early ECDT table attach */
262 if (ecdt && 
263 !memcmp(ecdt->hdr.signature, ECDT_SIG, sizeof(ECDT_SIG) - 1))
264 return (1);


then acpiec_attach() is called, and we have following line there:

281 sc->sc_devnode = aa->aaa_node;

and we can't properly eval expressions with NULL as devnode (as I noted,
aaa_node was memset() to zero in acpi_attach_common()).

Since we can't eval the expressions, we can't eval _REG method, which in
turns means that we can't access EC memory region and ECAV (Embedded
Controll AVailable - spent long time deciphering) won't be set in AML,
and from ASL for DSDT, it means that battery status will be returned as
'not present' and plus all other oddities. 

I was interested why this "early ECDT" attach procedure isn't working
for me, and found the following:

430 /* Check if this is ECDT initialization */
431 if (ecdt) {
[...]
447 /* Get devnode from header */
448 sc->sc_devnode = aml_searchname(sc->sc_acpi->sc_root,
449 ecdt->ec_id);
450 
451 goto ecdtdone;
452 }

The reason for the fail is my ECDT, it has wrong ec_id attribute:

Namepath : "\_SB.PC00.LPCB.H_EC"

there is no such device, proper path is "\_SB.PC00.LPCB.EC0"

So, if I remove ecdt table matching code from acpiec_match(), then loop
from acpi_attach_common() will fail to attach it, and actual setup will
be made by this line further down:

1231 aml_find_node(sc->sc_root, "_HID", acpi_foundec, sc);

which works perfectly fine, since it looks for _HID and strcmp() it with
EC Device ID in acpi_foundec(), finding correct node.

If ecdt table match stays, then the line won't take affect, since there
is logic in acpi_foundec() which prevents double attach.

Currently I have no idea how to properly fix this, without breaking
other devices (if you look in 4cfbe39155 why this early ECDT attach was
added).

I've asked for the ACPI fix in Lenovo support forum, to work on this
further, but I suspect such kind of support is like a unicorn - no such
thing.

Re: [acpi] patch for embedded controller detection

[Mikhail]

On Sat, Oct 08, 2022 at 03:10:18PM +0300, Mikhail wrote:
> I'm troubleshooting battery status for my Lenovo IdeaPad 3 14ITL05, on
> latest -current it shows that battery is absent and AC not connected:
> 
> Battery state: absent, 0% remaining, unknown life estimate
> AC adapter state: not connected
> Performance adjustment mode: manual (2900 MHz)

I'm still digging for this. 

Currently I don't understand why there have to be two acpiec devices
(see dmesg in previous mail - one acpiec0 and second "acpiec not
configured", or acpiec1 in patched version), while ASL has only one -
EC0, and having two ECs simply makes no sense. It brought me to match
logic of auto configuration for EC, with inlined patch I'm also able to
see battery status:

Battery state: high, 95% remaining, 178 minutes life estimate
AC adapter state: not connected
Performance adjustment mode: manual (2900 MHz)

This attempt is mostly for archive purpose and in hope, if anyone more
skilled may have immediate thought about the problem.

diff /usr/src
commit - 49f1cedec1baee518af868485e6367f5118073da
path + /usr/src
blob - 5ef24d5179de52d5321e578b3b73dd9524e7c1de
file + sys/dev/acpi/acpiec.c
--- sys/dev/acpi/acpiec.c
+++ sys/dev/acpi/acpiec.c
@@ -255,13 +255,8 @@ acpiec_match(struct device *parent, void *match, void 
 {
struct acpi_attach_args *aa = aux;
struct cfdata   *cf = match;
-   struct acpi_ecdt*ecdt = aa->aaa_table;
struct acpi_softc   *acpisc = (struct acpi_softc *)parent;
 
-   /* Check for early ECDT table attach */
-   if (ecdt && 
-   !memcmp(ecdt->hdr.signature, ECDT_SIG, sizeof(ECDT_SIG) - 1))
-   return (1);
if (acpisc->sc_ec)
return (0);
 
dmesg with the patch (now only one acpiec device):

OpenBSD 7.2-current (GENERIC.MP) #21: Wed Oct 12 09:06:10 MSK 2022
mi...@idea.lab.local:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8363110400 (7975MB)
avail mem = 8092250112 (7717MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x439df000 (70 entries)
bios0: vendor LENOVO version "GCCN26WW" date 03/11/2022
bios0: LENOVO 81X7
acpi0 at bios0: ACPI 6.1Undefined scope: \\_SB_.PCI0

acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT TPM2 MSDM NHLT SSDT 
LPIT WSMT SSDT SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT FPDT PTDT 
BGRT
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) XHCI(S4) XDCI(S4) 
HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
PXSX(S4) RP05(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 38MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.58 MHz, 06-8c-01
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01
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,S

Re: [acpi] patch for embedded controller detection

[Mikhail]

On Sat, Oct 08, 2022 at 05:10:31PM +0200, Mark Kettenis wrote:
> > Date: Sat, 8 Oct 2022 16:36:09 +0300
> > From: Mikhail 
> > 
> > On Sat, Oct 08, 2022 at 02:56:18PM +0200, Mark Kettenis wrote:
> > > The patch isn't quite right, but you're on the right track here.  Can
> > > you send me the contents of /var/db/acpi for this machine?
> > > Alternatively you can use sendbug(1), which will create a report with
> > > all the necessary information attached.
> > 
> > Yeah, I should have 'tog blame' the file, the commit explains the
> > decision for such var assignment.
> > 
> > ACPI stuff has been sent in direct mail.
> 
> Does the diff below work?

No, it doesn't.

Battery state: absent, 0% remaining, unknown life estimate
AC adapter state: not connected
Performance adjustment mode: manual (2900 MHz)

OpenBSD 7.2-current (GENERIC.MP) #10: Sun Oct  9 14:41:51 MSK 2022
mi...@idea.lab.local:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8363110400 (7975MB)
avail mem = 8092237824 (7717MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x439df000 (70 entries)
bios0: vendor LENOVO version "GCCN26WW" date 03/11/2022
bios0: LENOVO 81X7
acpi0 at bios0: ACPI 6.1Undefined scope: \\_SB_.PCI0

acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT TPM2 MSDM NHLT SSDT 
LPIT WSMT SSDT SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT FPDT PTDT 
BGRT
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) XHCI(S4) XDCI(S4) 
HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
PXSX(S4) RP05(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 38MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
20-way L2 cache, 6MB 64b/line 12-way L3 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz, 4090.57 MHz, 06-8c-01
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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,

Re: [acpi] patch for embedded controller detection

[Mikhail]

On Sat, Oct 08, 2022 at 02:56:18PM +0200, Mark Kettenis wrote:
> The patch isn't quite right, but you're on the right track here.  Can
> you send me the contents of /var/db/acpi for this machine?
> Alternatively you can use sendbug(1), which will create a report with
> all the necessary information attached.

Yeah, I should have 'tog blame' the file, the commit explains the
decision for such var assignment.

ACPI stuff has been sent in direct mail.

[acpi] patch for embedded controller detection

[Mikhail]

I'm troubleshooting battery status for my Lenovo IdeaPad 3 14ITL05, on
latest -current it shows that battery is absent and AC not connected:

Battery state: absent, 0% remaining, unknown life estimate
AC adapter state: not connected
Performance adjustment mode: manual (2900 MHz)

while reviewing the code and ASL dump for DSDT I found strange code path
in acpiec.c:

284 if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "_STA", 0, NULL, 
))
285 st = STA_PRESENT | STA_ENABLED | STA_DEV_OK;
286 if ((st & STA_PRESENT) == 0) {
287 printf(": not present\n");
288 return;
289 }

In my case, for acpiec0,  sc->sc_devnode is NULL, and aml_evalinteger
returns (ACPI_E_BADVALUE), which is (1), so 'if' statement becomes true
and 'st' got set, further down we check for 'st' value which looks
useless.

With the patch inlined I was able to see my battery and AC status:

Battery state: high, 100% remaining, unknown life estimate
AC adapter state: connected
Performance adjustment mode: manual (2900 MHz)

If I unplug the AC, change is also detected.

Old, new and diff of dmesg's are also inlined. Notable change - new
acpiec1 device in new dmesg, acpiec0 is detected as 'not present'.

Can somebody with broader understanding of ACPI and auto configuration
procedure take a look at the patch and assess it?

diff /usr/src
commit - 5cb1d9dce18f152bf9f5d7d4251dafe18a5c0c82
path + /usr/src
blob - 5ef24d5179de52d5321e578b3b73dd9524e7c1de
file + sys/dev/acpi/acpiec.c
--- sys/dev/acpi/acpiec.c
+++ sys/dev/acpi/acpiec.c
@@ -275,14 +275,13 @@ acpiec_attach(struct device *parent, struct device *se
struct acpiec_softc *sc = (struct acpiec_softc *)self;
struct acpi_attach_args *aa = aux;
struct aml_value res;
-   int64_t st;
+   int64_t st = 0;
 
sc->sc_acpi = (struct acpi_softc *)parent;
sc->sc_devnode = aa->aaa_node;
sc->sc_cantburst = 0;
 
-   if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "_STA", 0, NULL, ))
-   st = STA_PRESENT | STA_ENABLED | STA_DEV_OK;
+   aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "_STA", 0, NULL, );
if ((st & STA_PRESENT) == 0) {
printf(": not present\n");
return;

dmesg diff:

--- dmesg.old   Sat Oct  8 14:45:40 2022
+++ dmesg.new   Sat Oct  8 14:48:25 2022
@@ -1,7 +1,7 @@
-OpenBSD 7.2-current (GENERIC.MP) #7: Sat Oct  8 14:41:01 MSK 2022
+OpenBSD 7.2-current (GENERIC.MP) #8: Sat Oct  8 14:46:04 MSK 2022
 mi...@idea.lab.local:/sys/arch/amd64/compile/GENERIC.MP
 real mem = 8363110400 (7975MB)
-avail mem = 8092237824 (7717MB)
+avail mem = 8092213248 (7717MB)
 random: good seed from bootblocks
 mpath0 at root
 scsibus0 at mpath0: 256 targets
@@ -15,7 +15,7 @@
 acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT TPM2 MSDM NHLT SSDT 
LPIT WSMT SSDT SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT FPDT PTDT 
BGRT
 acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) XHCI(S4) XDCI(S4) 
HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
PXSX(S4) RP05(S4) [...]
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
-acpiec0 at acpi0
+acpiec0 at acpi0: not present
 acpihpet0 at acpi0: 1920 Hz
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
@@ -70,9 +70,9 @@
 acpiprt23 at acpi0: bus -1 (RP22)
 acpiprt24 at acpi0: bus -1 (RP23)
 acpiprt25 at acpi0: bus -1 (RP24)
-acpiec at acpi0 not configured
+acpiec1 at acpi0
 acpipci0 at acpi0 PC00: 0x 0x0011 0x0001
-acpibat0 at acpi0: BAT0 not present
+acpibat0 at acpi0: BAT0 model "L16M2PB2" serial   411 type LiP oem "SMP"
 "VPC2004" at acpi0 not configured
 "IDEA2004" at acpi0 not configured
 "INTC1043" at acpi0 not configured
@@ -82,7 +82,7 @@
 "MSFT0001" at acpi0 not configured
 "ACPI000E" at acpi0 not configured
 pchgpio0 at acpi0 GPI0 addr 0xfd6e/0x1 0xfd6d/0x1 
0xfd6a/0x1 0xfd69/0x1 irq 14, 360 pins
-acpiac0 at acpi0: AC unit offline
+acpiac0 at acpi0: AC unit online
 acpibtn0 at acpi0: LID0
 acpibtn1 at acpi0: PWRB
 "PNP0C14" at acpi0 not configured

old:

OpenBSD 7.2-current (GENERIC.MP) #7: Sat Oct  8 14:41:01 MSK 2022
mi...@idea.lab.local:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8363110400 (7975MB)
avail mem = 8092237824 (7717MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x439df000 (70 entries)
bios0: vendor LENOVO version "GCCN26WW" date 03/11/2022
bios0: LENOVO 81X7
acpi0 at bios0: ACPI 6.1Undefined scope: \\_SB_.PCI0

acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT TPM2 MSDM NHLT SSDT 
LPIT WSMT SSDT SSDT DBGP DBG2 ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT FPDT PTDT 
BGRT
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) XHCI(S4) XDCI(S4) 
HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 

Re: [patch] 802.11 printing akm and cipher suite lists in tcpdump

[Mikhail]

Friendly weekly ping

On Thu, Jun 02, 2022 at 11:43:30PM +0300, Mikhail wrote:
> Recently I bought a router with WPA3 support and decided to investigate
> wireless dump with WPA3 config, during the process I've found a small
> bug in tcpdump - it doesn't print all akms, also the printing logic is
> flawed if more than one akm or pairwise cipher is presented - there is
> extra addition to the data index.
> 
> Tested with multiple akms, can't test with multiple ciphers, since my
> router doesn't support such configuration.
> 
> diff --git usr.sbin/tcpdump/print-802_11.c usr.sbin/tcpdump/print-802_11.c
> index b0641a29279..14ecbdc6cfc 100644
> --- usr.sbin/tcpdump/print-802_11.c
> +++ usr.sbin/tcpdump/print-802_11.c
> @@ -860,6 +860,9 @@ ieee80211_print_akm(uint8_t selector[4])
>   case 6:
>   printf("SHA256-PSK");
>   break;
> + case 8:
> + printf("SAE");
> + break;
>   default:
>   printf("%d", selector[3]);
>   break;
> @@ -910,7 +913,7 @@ ieee80211_print_rsn(u_int8_t *data, u_int len)
>   printf(",cipher%s ", nciphers > 1 ? "s" : "");
>   for (i = 0; i < nciphers; i++) {
>   for (j = 0; j < 4; j++)
> - selector[j] = data[i + j];
> + selector[j] = data[j];
>   ieee80211_print_rsncipher(selector);
>   if (i < nciphers - 1)
>   printf(" ");
> @@ -931,11 +934,11 @@ ieee80211_print_rsn(u_int8_t *data, u_int len)
>   }
>  
>   printf(",akm%s ", nakms > 1 ? "s" : "");
> - for (i = 0; i < nciphers; i++) {
> + for (i = 0; i < nakms; i++) {
>   for (j = 0; j < 4; j++)
> - selector[j] = data[i + j];
> + selector[j] = data[j];
>   ieee80211_print_akm(selector);
> - if (i < nciphers - 1)
> + if (i < nakms - 1)
>   printf(" ");
>   data += 4;
>   }

[patch] 802.11 printing akm and cipher suite lists in tcpdump

[Mikhail]

Recently I bought a router with WPA3 support and decided to investigate
wireless dump with WPA3 config, during the process I've found a small
bug in tcpdump - it doesn't print all akms, also the printing logic is
flawed if more than one akm or pairwise cipher is presented - there is
extra addition to the data index.

Tested with multiple akms, can't test with multiple ciphers, since my
router doesn't support such configuration.

diff --git usr.sbin/tcpdump/print-802_11.c usr.sbin/tcpdump/print-802_11.c
index b0641a29279..14ecbdc6cfc 100644
--- usr.sbin/tcpdump/print-802_11.c
+++ usr.sbin/tcpdump/print-802_11.c
@@ -860,6 +860,9 @@ ieee80211_print_akm(uint8_t selector[4])
case 6:
printf("SHA256-PSK");
break;
+   case 8:
+   printf("SAE");
+   break;
default:
printf("%d", selector[3]);
break;
@@ -910,7 +913,7 @@ ieee80211_print_rsn(u_int8_t *data, u_int len)
printf(",cipher%s ", nciphers > 1 ? "s" : "");
for (i = 0; i < nciphers; i++) {
for (j = 0; j < 4; j++)
-   selector[j] = data[i + j];
+   selector[j] = data[j];
ieee80211_print_rsncipher(selector);
if (i < nciphers - 1)
printf(" ");
@@ -931,11 +934,11 @@ ieee80211_print_rsn(u_int8_t *data, u_int len)
}
 
printf(",akm%s ", nakms > 1 ? "s" : "");
-   for (i = 0; i < nciphers; i++) {
+   for (i = 0; i < nakms; i++) {
for (j = 0; j < 4; j++)
-   selector[j] = data[i + j];
+   selector[j] = data[j];
ieee80211_print_akm(selector);
-   if (i < nciphers - 1)
+   if (i < nakms - 1)
printf(" ");
data += 4;
}

openrsync man page fix

[Mikhail]

Replace rsync command with openrsync in EXAMPLES.

diff --git usr.bin/rsync/rsync.1 usr.bin/rsync/rsync.1
index 8144754695a..9bcf3566bb9 100644
--- usr.bin/rsync/rsync.1
+++ usr.bin/rsync/rsync.1
@@ -290,7 +290,7 @@ with the local
 and
 .Pa ../src/baz :
 .Pp
-.Dl % rsync -t ../src/bar ../src/baz host:dest
+.Dl % openrsync -t ../src/bar ../src/baz host:dest
 .Pp
 To update the out-of-date local files
 .Pa bar
@@ -301,7 +301,7 @@ with the remote files
 and
 .Pa host:src/baz :
 .Pp
-.Dl % rsync -t host:src/bar :src/baz \&.
+.Dl % openrsync -t host:src/bar :src/baz \&.
 .Pp
 To update the out-of-date local files
 .Pa ../dest/bar
@@ -312,7 +312,7 @@ with
 and
 .Pa baz :
 .Pp
-.Dl % rsync -t bar baz ../dest
+.Dl % openrsync -t bar baz ../dest
 .\" .Sh DIAGNOSTICS
 .Sh SEE ALSO
 .Xr ssh 1

Re: initial iwx(4) 11ac patch for testing

[Mikhail]

On Wed, Mar 09, 2022 at 01:07:47PM +0100, Stefan Sperling wrote:
> This patch adds initial 11ac support to the iwx(4) driver.
> This means that 80MHz channels can be used. No other 11ac features
> are enabled yet.
> 
> This is not yet a patch which could be committed. Apart from debug
> prints which need to go, there is a known issue found by dv@ where
> this patch causes a firmware error, sysassert 0x20101A25. The reason
> for this is not known.
> It would help to get more testing to see if more clues can be found
> based on where this error pops up. I cannot reproduce the error myself.
> 
> When sending feedback, please be clear about which iwx(4) device and
> which access point has been tested. Thanks!
> 
> The patch works for me on AX200 and AX201 with a pepwave AC one mini AP,
> although throughput is not much different to 11n 40MHz with this AP.

I can't test the functionality of the patch, because I don't own Intel
hardware and proper AP, but during 'git apply' process it warned about
improper whitespacing, the patch for this is inlined at the end of the
mail (need to be applied above your patch).

>  
>  /*
> + * Install received VHT caps information in the node's state block.
> + */
> +void
> +ieee80211_setup_vhtcaps(struct ieee80211_node *ni, const uint8_t *data,
> +uint8_t len)
> +{
> + if (len != 12)
> + return;
> +
> + ni->ni_vhtcaps = (data[0] | (data[1] << 8) | data[2] << 16 |
> + data[3] << 24);
> + ni->ni_vht_rxmcs = (data[4] | (data[5] << 8));
> + ni->ni_vht_rx_max_lgi_mbit_s = ((data[6] | (data[7] << 8)) &
> + IEEE80211_VHT_MAX_LGI_MBIT_S_MASK);
> + ni->ni_vht_txmcs = (data[8] | (data[9] << 8));
> + ni->ni_vht_tx_max_lgi_mbit_s = ((data[10] | (data[11] << 8)) &
> + IEEE80211_VHT_MAX_LGI_MBIT_S_MASK);
> +
> + ni->ni_flags |= IEEE80211_NODE_VHTCAP;
> +}

I understand that this function do things like ieee80211_setup_htcaps()
(HT, 802.11n), which is mature, working and stable, but is there a
reason not to return 0 on error, 1 on success, and check it in the
caller (like in ieee80211_setup_vhtop())?

> +/* Check if the peer supports VHT short guard interval (SGI) on 160 MHz. */
> +static inline int
> +ieee80211_node_supports_vht_sgi160(struct ieee80211_node *ni)
> +{
> + return ieee80211_node_supports_vht(ni) &&
> + (ni->ni_vhtcaps & IEEE80211_VHTCAP_SGI160);
> +}

This function is unused.

The patch for whitespacing:

diff --git sys/dev/pci/if_iwx.c sys/dev/pci/if_iwx.c
index a56c59f82c8..9efa429df07 100644
--- sys/dev/pci/if_iwx.c
+++ sys/dev/pci/if_iwx.c
@@ -5384,7 +5384,7 @@ iwx_tx_fill_cmd(struct iwx_softc *sc, struct iwx_node *in,
rate_flags |= IWX_RATE_MCS_CHAN_WIDTH_80;
if (ieee80211_node_supports_vht_sgi80(ni))
rate_flags |= IWX_RATE_MCS_SGI_MSK;
-   } else if ((sco == IEEE80211_HTOP0_SCO_SCA || 
+   } else if ((sco == IEEE80211_HTOP0_SCO_SCA ||
sco == IEEE80211_HTOP0_SCO_SCB) &&
in->in_phyctxt != NULL && in->in_phyctxt->sco == sco) {
rate_flags |= IWX_RATE_MCS_CHAN_WIDTH_40;
@@ -7020,7 +7020,7 @@ iwx_rs_vht_rates(struct iwx_softc *sc, struct 
ieee80211_node *ni, int num_ss)
/* Should not happen; Values above cover the possible range. */
panic("invalid VHT Rx MCS value %u", rx_mcs);
}
-   
+
return ((1 << (max_mcs + 1)) - 1);
 }
 
diff --git sys/net80211/ieee80211_node.c sys/net80211/ieee80211_node.c
index c874c874657..a6833e255ff 100644
--- sys/net80211/ieee80211_node.c
+++ sys/net80211/ieee80211_node.c
@@ -2458,7 +2458,7 @@ ieee80211_setup_vhtop(struct ieee80211_node *ni, const 
uint8_t *data,
 }
 
 #ifndef IEEE80211_STA_ONLY
-/* 
+/*
  * Handle nodes switching from 11ac into legacy modes.
  */
 void
diff --git sys/net80211/ieee80211_node.h sys/net80211/ieee80211_node.h
index e64e3ec26b2..a0c82378eb4 100644
--- sys/net80211/ieee80211_node.h
+++ sys/net80211/ieee80211_node.h
@@ -420,8 +420,8 @@ struct ieee80211_node {
 #define IEEE80211_NODE_VHT 0x1 /* VHT negotiated */
 #define IEEE80211_NODE_HTCAP   0x2 /* claims to support HT */
 #define IEEE80211_NODE_VHTCAP  0x4 /* claims to support VHT */
-#define IEEE80211_NODE_VHT_SGI80   0x8 /* SGI on 80 MHz negotiated */ 
-#define IEEE80211_NODE_VHT_SGI160  0x10 /* SGI on 160 MHz negotiated 
*/ 
+#define IEEE80211_NODE_VHT_SGI80   0x8 /* SGI on 80 MHz negotiated */
+#define IEEE80211_NODE_VHT_SGI160  0x10 /* SGI on 160 MHz negotiated */
 
/* If not NULL, this function gets called when ni_refcnt hits zero. */
void(*ni_unref_cb)(struct ieee80211com *,
@@ -516,7 +516,7 @@ ieee80211_node_supports_ht_chan40(struct ieee80211_node *ni)
(ni->ni_htop0 & IEEE80211_HTOP0_CHW));
 }
 
-/* 
+/*
  * Check if the peer supports VHT.
  

Re: mg and trailing whitespaces

[Mikhail]

On Wed, Mar 02, 2022 at 09:47:31AM +0100, Omar Polo wrote:
> Hello tech,
> 
> mg(1) has this tendency to leave a lot of trailing whitespaces around in
> auto-indent-mode and c-mode which I find annoying.  Yes, there's
> delete-trailing-space but it works only on the current line (and not the
> whole buffer as in emacs) and one has to manually call it anyway.
> Emacs, and even vi in base, are clever in this regard: trailing
> whitespaces before the cursor are delete upon RET before adding a new
> line.
> 
> So, here's the same heuristic for mg when auto-indent-mode or c-mode is
> enabled.  It's still possible to leave trailing whitespace in a buffer
> in those modes, it only gets a little bit harder to do.
> 
> (as a next step I guess we could also garbage collect cc_strip_trailp,
> it was used in only one place before this patch and is unconditionally
> set to TRUE.)
> 
> Thoughts/OK?

I've tested the patch and it works as intended.

I like new behavior for c-mode, but not sure if it is good for
auto-indent one. If user presses  and then  I'd argue that
removing first tab is good idea in this particular mode, but no hard
objections, since I don't use auto-indent.

Re: [patch] ksh: backspace in search-history buffer with UTF8 chars

[Mikhail]

On Tue, Mar 08, 2022 at 03:15:55PM +0300, Mikhail wrote:
> Inlined diff helps ksh search-history function (ctrl-r) to handle
> backspace for UTF8 characters properly, without the patch, if I have
> UTF8 characters in my search buffer, I need to press backspace twice to
> push cursor to the left.
> 
> The search itself is not perfect for UTF8 either, sometimes I get
> patterns which are not handled properly, or the input prompt becomes
> mangled, but the issue with backspace is what currently bothers me the
> most.
> 
> Comments, objections?

Better version, behavior is not changed:


diff --git bin/ksh/emacs.c bin/ksh/emacs.c
index 5370e814f70..a5ed4095ae5 100644
--- bin/ksh/emacs.c
+++ bin/ksh/emacs.c
@@ -907,8 +907,11 @@ x_search_hist(int c)
offset = -1;
break;
}
-   if (p > pat)
-   *--p = '\0';
+   if (p > pat) {
+   while (isu8cont(*--p))
+   ;
+   *p ='\0';
+   }
if (p == pat)
offset = -1;
else

[patch] ksh: backspace in search-history buffer with UTF8 chars

[Mikhail]

Inlined diff helps ksh search-history function (ctrl-r) to handle
backspace for UTF8 characters properly, without the patch, if I have
UTF8 characters in my search buffer, I need to press backspace twice to
push cursor to the left.

The search itself is not perfect for UTF8 either, sometimes I get
patterns which are not handled properly, or the input prompt becomes
mangled, but the issue with backspace is what currently bothers me the
most.

Comments, objections?

diff --git bin/ksh/emacs.c bin/ksh/emacs.c
index 5370e814f70..0058bad9adb 100644
--- bin/ksh/emacs.c
+++ bin/ksh/emacs.c
@@ -908,7 +908,9 @@ x_search_hist(int c)
break;
}
if (p > pat)
-   *--p = '\0';
+   while (isu8cont(*--p))
+   ;
+   *p ='\0';
if (p == pat)
offset = -1;
else

Re: fix net80211 ioctl name collision

[Mikhail]

On Fri, Mar 04, 2022 at 10:46:29PM +0100, Stefan Sperling wrote:
> The net80211 ioctl which ifconfig is using to obtain a list of all
> supported channels is using a struct name that belongs to the kernel.
> 
> Fix this by renaming struct ieee80211_channel to struct ieee80211_chaninfo
> in ieee80211_ioctl.h. The way this is done here keeps both old and new
> ifconfig binaries happy.
> 
> Passes make release on amd64.
> I don't expect fallout in ports from this, though just in case I will
> wait for a build which sthen@ is running.

I've tested the diff with old and new ifconfig binaries on urtwn
hardware - everything works as expected.

chrome crash on latest snapshot with intel driver

[Mikhail]

On latest snapshot I see Xorg crash when trying to launch chrome browser
(firefox works fine), I can reproduce it with 'intel' driver,
'modesetting' crashed for me too, but it took about two weeks of uptime
and wasn't related to chrome launch (no logs for 'modesetting' crash
unfortunately, but it was something about not being able to access
address 0x0, this 'modesettnig' crash lead me to changing the driver to
'intel', that's how original crash was found, no idea how long it is
there).

sysctl.conf:

vm.malloc_conf=CFGS
hw.smt=1
kern.allowdt=1
kern.video.record=1
kern.audio.record=1
kern.allowkmem=1
machdep.allowaperture=1

Xorg.0.log.old:

[  2267.648] (--) checkDevMem: using aperture driver /dev/xf86
[  2267.670] (--) Using wscons driver on /dev/ttyC4
[  2267.689] 
X.Org X Server 1.21.1.3
X Protocol Version 11, Revision 0
[  2267.689] Current Operating System: OpenBSD edge.lab.local 7.1 
GENERIC.MP#395 amd64
[  2267.689]  
[  2267.689] Current version of pixman: 0.40.0
[  2267.689]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  2267.689] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  2267.690] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Mar  2 12:52:12 
2022
[  2267.690] (==) Using config file: "/etc/xorg.conf"
[  2267.690] (==) Using system config directory 
"/usr/X11R6/share/X11/xorg.conf.d"
[  2267.691] (==) No Layout section.  Using the first Screen section.
[  2267.691] (==) No screen section available. Using defaults.
[  2267.691] (**) |-->Screen "Default Screen Section" (0)
[  2267.691] (**) |   |-->Monitor ""
[  2267.691] (==) No device specified for screen "Default Screen Section".
Using the first device section listed.
[  2267.691] (**) |   |-->Device "Intel Graphics"
[  2267.691] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[  2267.692] (==) Automatically adding devices
[  2267.692] (==) Automatically enabling devices
[  2267.692] (==) Not automatically adding GPU devices
[  2267.692] (==) Automatically binding GPU devices
[  2267.692] (==) Max clients allowed: 256, resource mask: 0x1f
[  2267.692] (==) FontPath set to:
/usr/X11R6/lib/X11/fonts/misc/,
/usr/X11R6/lib/X11/fonts/TTF/,
/usr/X11R6/lib/X11/fonts/OTF/,
/usr/X11R6/lib/X11/fonts/Type1/,
/usr/X11R6/lib/X11/fonts/100dpi/,
/usr/X11R6/lib/X11/fonts/75dpi/
[  2267.692] (==) ModulePath set to "/usr/X11R6/lib/modules"
[  2267.692] (II) The server relies on wscons to provide the list of input 
devices.
If no devices become available, reconfigure wscons or disable 
AutoAddDevices.
[  2267.692] (II) Loader magic: 0x7dc25daf7c0
[  2267.692] (II) Module ABI versions:
[  2267.692]X.Org ANSI C Emulation: 0.4
[  2267.692]X.Org Video Driver: 25.2
[  2267.692]X.Org XInput driver : 24.4
[  2267.692]X.Org Server Extension : 10.0
[  2267.692] (--) PCI:*(0@0:2:0) 8086:0166:17aa:5001 rev 9, Mem @ 
0xf000/4194304, 0xe000/268435456, I/O @ 0x5000/64
[  2267.692] (II) LoadModule: "glx"
[  2267.693] (II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
[  2267.696] (II) Module glx: vendor="X.Org Foundation"
[  2267.696]compiled for 1.21.1.3, module version = 1.0.0
[  2267.696]ABI class: X.Org Server Extension, version 10.0
[  2267.696] (II) LoadModule: "intel"
[  2267.697] (II) Loading /usr/X11R6/lib/modules/drivers/intel_drv.so
[  2267.698] (II) Module intel: vendor="X.Org Foundation"
[  2267.698]compiled for 1.21.1.3, module version = 2.99.916
[  2267.698]Module class: X.Org Video Driver
[  2267.698]ABI class: X.Org Video Driver, version 25.2
[  2267.698] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
[  2267.698] (II) intel: Driver for Intel(R) HD Graphics: 2000-6000
[  2267.698] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100, 6100
[  2267.698] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200, 6200, 
P6300
[  2267.703] (II) intel(0): Using Kernel Mode Setting driver: i915, version 
1.6.0 20201103
[  2267.704] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 
4000
[  2267.704] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, sse4.2, avx
[  2267.704] (II) intel(0): Creating default Display subsection in Screen 
section
"Default Screen Section" for depth/fbbpp 24/32
[  2267.705] (==) intel(0): Depth 24, (--) framebuffer bpp 32
[  2267.705] (==) intel(0): RGB weight 888
[  2267.705] (==) intel(0): Default visual is TrueColor

Re: tcpdump core's on the latest snapshot

[Mikhail]

On Sun, Feb 13, 2022 at 12:54:19PM +0100, Otto Moerbeek wrote:
> I can see two problems:
> 
> 1. setjump returning 1
> 2. freechunks() segfaulting.
> 
> Here I'll concentrate on 2), as I suspect 1) has a cause that is already in
> the process of being diagnosed/fixed elsewhere.

The patch works - no segfault and proper error message is printed, thank
you.

tcpdump core's on the latest snapshot

[Mikhail]

Running this command on the latest snapshot produces core file for me:

doas tcpdump -i urtwn0 proto ip6

Core details:

misha:/home/misha:3959$ doas lldb --core tcpdump.core tcpdump
(lldb) target create "tcpdump" --core "tcpdump.core"
Core file '/home/misha/tcpdump.core' (x86_64) was loaded.
(lldb) bt
* thread #1, stop reason = signal SIGSEGV
  * frame #0: 0x07b299d82607 libpcap.so.9.0`pcap_compile [inlined] 
freechunks at gencode.c:209:9
frame #1: 0x07b299d825c2 libpcap.so.9.0`pcap_compile(p=, 
program=, buf=, optimize=, 
mask=) at gencode.c:287:3
frame #2: 0x07aff4d7a74f tcpdump`___lldb_unnamed_symbol311 + 159
frame #3: 0x07aff4d783a6 tcpdump`___lldb_unnamed_symbol286 + 3510
frame #4: 0x07aff4d73f61 tcpdump`___lldb_unnamed_symbol259 + 97
frame #5: 0x07aff4d73b32 tcpdump`___lldb_unnamed_symbol253 + 290

It looks like setjmp() call on gencode.c:286 returns "1", while the man
page says it must return only "0".

Dmesg:

OpenBSD 7.0-current (GENERIC.MP) #298: Mon Jan 31 13:42:43 MST 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4117065728 (3926MB)
avail mem = 3975090176 (3790MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (65 entries)
bios0: vendor LENOVO version "H0ET96WW (2.56 )" date 06/12/2015
bios0: LENOVO 3259KNG
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI UEFI 
POAT UEFI DBG2
acpi0: wakeup devices P0P1(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S3) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S5) RP05(S4) 
PXSX(S4) RP06(S4) [...]
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) i5-3210M CPU @ 2.50GHz, 2494.70 MHz, 06-3a-09
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,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,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 1 (application processor)
cpu1: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.33 MHz, 06-3a-09
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,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: disabling user TSC (skew=116)
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09
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,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.33 MHz, 06-3a-09
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,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,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus 3 (RP02)
acpiprt4 at acpi0: bus 4 (RP03)
acpiprt5 at acpi0: bus 12 (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
acpipci0 at acpi0 PCI0: 0x0004 0x0011 0x0001
acpicmos0 at acpi0
acpithinkpad0 at acpi0: 

Re: [patch] urndis: uncomment watchdog

[Mikhail]

On Wed, Dec 08, 2021 at 03:26:25PM +0100, Gerhard Roth wrote:
> > I don't want to fight for this diff, if you think that it's too naive to
> > expect proper reset from unresponsive device - that's fine, I'm ready to
> > drop the diff, but who knows how those devices are engineered and trade
> > of of not being able to run other watchdogs comparing to possible
> > network recovery does look reasonable to me.
> > 
> 
> I don't blame the idea of revitializing urndis_watchdog(). But that
> code has been disabled for more than 10 years. And its quite different
> for what all the other watchdog routines of USB network interface
> drivers do. Maybe the code needs rethinking.

I was looking on other implementations and didn't find any signs of the
same protocol logic - with keepalives and reset messages, so this flow
is pretty unique for urndis driver, and I currently don't understand how
to re-do it to avoid waiting on timeout. It already looks pretty
straightforward and complete.

Re: [patch] urndis: uncomment watchdog

[Mikhail]

On Wed, Dec 08, 2021 at 02:43:04PM +0100, Gerhard Roth wrote:
> Well, the RNDIS device doesn't respond to REMOTE_NDIS_KEEPALIVE_MSG
> messages anymore, but now you hope that it'll still process the
> REMOTE_NDIS_RESET_MSG we are sending? Sounds like wishful thinking.
> I'd say a usbd_reset_port() might be more effective.

> BTW: I was wrong about the 5 seconds. In fact its 10 seconds since the
> same timeout applies to the reset message.
> 

I think if the device don't ack the keepalive message the driver will
just output an error to the log and return, there should be no second 5
sec timeout:

 748 rval = urndis_ctrl_send(sc, keep, sizeof(*keep));
 749 free(keep, M_TEMP, sizeof *keep);
 750 
 751 if (rval != RNDIS_STATUS_SUCCESS) {
 752 printf("%s: keepalive failed\n", DEVNAME(sc));
 753 return rval;
 754 }
 755 
 756 if ((hdr = urndis_ctrl_recv(sc)) == NULL) {
 757 printf("%s: unable to get keepalive response\n", 
DEVNAME(sc));
 758 return RNDIS_STATUS_FAILURE;
 759 }

 
I don't want to fight for this diff, if you think that it's too naive to
expect proper reset from unresponsive device - that's fine, I'm ready to
drop the diff, but who knows how those devices are engineered and trade
of of not being able to run other watchdogs comparing to possible
network recovery does look reasonable to me.

Re: [patch] urndis: uncomment watchdog

[Mikhail]

On Wed, Dec 08, 2021 at 02:10:49PM +0100, Gerhard Roth wrote:
> Well, there's only one watchdog thread for all of the
> network interfaces. If it is blocked, not other watchdogs
> can run.

I don't think this is a big loss. On one side - no other watchdogs can
run for 5 secs, but on other side - watchdog can potentially recover the
network service with automatic reset of urndis device and return network
connectivity.

Isn't it a fair trade of?

Re: [patch] urndis: uncomment watchdog

[Mikhail]

On Wed, Dec 08, 2021 at 10:39:15AM +0100, Gerhard Roth wrote:
> urndis_watchdog() calls urndis_ctrl_keepalive() which sends an RNDIS
> keepalive msg and then waits for the reply with USBD_DEFAULT_TIMEOUT.
> That means if the device stopped responding, the if_watchdog_thread
> will be blocked for 5 seconds. Not sure if that's a good idea.

Hello, I think this behavior is like it is supposed to work.

What are drawbacks of having this keepalive thread being blocked while
waiting the answer for keepalive? - in case of timeout we will have
error message in the logs and user will be able to handle the problem
manually.

Re: [patch] urndis: uncomment watchdog

[Mikhail]

On Tue, Nov 30, 2021 at 09:40:35PM +0300, Mikhail wrote:
> Currently watchdog functionality for urndis driver is disabled
> (commented), I've tested it and it works properly - reset messages are
> correctly sent and cmplt packets are received according to RNDIS spec (I
> patched the driver to forcedly send reset message and act on it with
> device reset every 5 seconds). I suggest to uncomment it.
> 
> The hardware is Megafon 4G МM200-1:
> 
> urndis0 at uhub3 port 2 configuration 1 interface 0 "Qualcomm MM200-1" rev 
> 2.00/3.18 addr 5
> 
> Tests, comments or objections?

Ping.

Commenting was introduced by mk@ in 61cec9357e4f with the following
note:

> At some point we probably want to use the watchdog functionality but the
> current code is completely untested so disable it entirely rather than
> enabling it this close to release.

I've tested it and it works, maybe there will be a committer who can
enable the watchdog? - the functionality is widely used in other drivers
and seem to be useful in general.

Re: [patch] ehci: change explicit function names to __func__ in debugging printfs

[Mikhail]

Ping

On Sat, Nov 27, 2021 at 09:36:32PM +0300, Mikhail wrote:
> While fiddling with ehci.c and fighting with urndis I noticed that most
> of the debugging printf's use explicit names, which is inconvenient for
> grep'ing. Also, couple of items used wrong function names
> (ehci_check_intr instead of ehci_check_qh_intr).
> 
> Compilation tested with DIAGNOSTIC and EHCI_DEBUG defines.
> 
> diff --git sys/dev/usb/ehci.c sys/dev/usb/ehci.c
> index afc423dbbb6..37ff3beeb7a 100644
> --- sys/dev/usb/ehci.c
> +++ sys/dev/usb/ehci.c
> @@ -314,10 +314,10 @@ ehci_init(struct ehci_softc *sc)
>   sc->sc_offs = EREAD1(sc, EHCI_CAPLENGTH);
>  
>   sparams = EREAD4(sc, EHCI_HCSPARAMS);
> - DPRINTF(("ehci_init: sparams=0x%x\n", sparams));
> + DPRINTF(("%s: sparams=0x%x\n", __func__, sparams));
>   sc->sc_noport = EHCI_HCS_N_PORTS(sparams);
>   cparams = EREAD4(sc, EHCI_HCCPARAMS);
> - DPRINTF(("ehci_init: cparams=0x%x\n", cparams));
> + DPRINTF(("%s: cparams=0x%x\n", __func__, cparams));
>  
>   /* MUST clear segment register if 64 bit capable. */
>   if (EHCI_HCC_64BIT(cparams))
> @@ -521,7 +521,7 @@ ehci_intr1(struct ehci_softc *sc)
>   /* In case the interrupt occurs before initialization has completed. */
>   if (sc == NULL) {
>  #ifdef DIAGNOSTIC
> - printf("ehci_intr1: sc == NULL\n");
> + printf("%s: sc == NULL\n", __func__);
>  #endif
>   return (0);
>   }
> @@ -704,7 +704,7 @@ ehci_check_qh_intr(struct ehci_softc *sc, struct 
> usbd_xfer *xfer)
>* short packet (SPD and not ACTIVE).
>*/
>   if (letoh32(lsqtd->qtd.qtd_status) & EHCI_QTD_ACTIVE) {
> - DPRINTFN(12, ("ehci_check_intr: active ex=%p\n", ex));
> + DPRINTFN(12, ("%s: active ex=%p\n", __func__, ex));
>   for (sqtd = ex->sqtdstart; sqtd != lsqtd; sqtd=sqtd->nextqtd) {
>   usb_syncmem(>dma,
>   sqtd->offs + offsetof(struct ehci_qtd, qtd_status),
> @@ -724,7 +724,7 @@ ehci_check_qh_intr(struct ehci_softc *sc, struct 
> usbd_xfer *xfer)
>   if (EHCI_QTD_GET_BYTES(status) != 0)
>   goto done;
>   }
> - DPRINTFN(12, ("ehci_check_intr: ex=%p std=%p still active\n",
> + DPRINTFN(12, ("%s: ex=%p std=%p still active\n", __func__,
> ex, ex->sqtdstart));
>   usb_syncmem(>dma,
>   lsqtd->offs + offsetof(struct ehci_qtd, qtd_status),
> @@ -876,7 +876,7 @@ ehci_idone(struct usbd_xfer *xfer)
>   int s = splhigh();
>   if (ex->isdone) {
>   splx(s);
> - printf("ehci_idone: ex=%p is done!\n", ex);
> + printf("%s: ex=%p is done!\n", __func__, ex);
>   return;
>   }
>   ex->isdone = 1;
> @@ -904,8 +904,8 @@ ehci_idone(struct usbd_xfer *xfer)
>   }
>  
>   cerr = EHCI_QTD_GET_CERR(status);
> - DPRINTFN(/*10*/2, ("ehci_idone: len=%d, actlen=%d, cerr=%d, "
> - "status=0x%x\n", xfer->length, actlen, cerr, status));
> + DPRINTFN(/*10*/2, ("%s: len=%d, actlen=%d, cerr=%d, "
> + "status=0x%x\n", __func__, xfer->length, actlen, cerr, status));
>   xfer->actlen = actlen;
>   if ((status & EHCI_QTD_HALTED) != 0) {
>   if ((status & EHCI_QTD_BABBLE) == 0 && cerr > 0)
> @@ -920,7 +920,7 @@ ehci_idone(struct usbd_xfer *xfer)
>   usbd_xfer_isread(xfer) ?
>   BUS_DMASYNC_POSTREAD : BUS_DMASYNC_POSTWRITE);
>   usb_transfer_complete(xfer);
> - DPRINTFN(/*12*/2, ("ehci_idone: ex=%p done\n", ex));
> + DPRINTFN(/*12*/2, ("%s: ex=%p done\n", __func__, ex));
>  }
>  
>  void
> @@ -1367,7 +1367,7 @@ ehci_open(struct usbd_pipe *pipe)
>   int ival, speed, naks;
>   int hshubaddr, hshubport;
>  
> - DPRINTFN(1, ("ehci_open: pipe=%p, addr=%d, endpt=%d\n",
> + DPRINTFN(1, ("%s: pipe=%p, addr=%d, endpt=%d\n", __func__,
>   pipe, addr, ed->bEndpointAddress));
>  
>   if (sc->sc_bus.dying)
> @@ -1408,7 +1408,7 @@ ehci_open(struct usbd_pipe *pipe)
>   speed = EHCI_QH_SPEED_HIGH;
>   break;
>   default:
> - panic("ehci_open: bad device speed %d", dev->speed);
> + panic("%s: bad device speed %d", __func__, dev-

[patch] urndis: uncomment watchdog

[Mikhail]

Currently watchdog functionality for urndis driver is disabled
(commented), I've tested it and it works properly - reset messages are
correctly sent and cmplt packets are received according to RNDIS spec (I
patched the driver to forcedly send reset message and act on it with
device reset every 5 seconds). I suggest to uncomment it.

The hardware is Megafon 4G МM200-1:

urndis0 at uhub3 port 2 configuration 1 interface 0 "Qualcomm MM200-1" rev 
2.00/3.18 addr 5

Tests, comments or objections?

diff --git sys/dev/usb/if_urndis.c sys/dev/usb/if_urndis.c
index 551197fbfc3..7347712f282 100644
--- sys/dev/usb/if_urndis.c
+++ sys/dev/usb/if_urndis.c
@@ -64,9 +64,7 @@
 int urndis_newbuf(struct urndis_softc *, struct urndis_chain *);
 
 int urndis_ioctl(struct ifnet *, u_long, caddr_t);
-#if 0
 void urndis_watchdog(struct ifnet *);
-#endif
 
 void urndis_start(struct ifnet *);
 void urndis_rxeof(struct usbd_xfer *, void *, usbd_status);
@@ -100,10 +98,8 @@ u_int32_t urndis_ctrl_query(struct urndis_softc *, 
u_int32_t, void *, size_t,
 u_int32_t urndis_ctrl_set(struct urndis_softc *, u_int32_t, void *, size_t);
 u_int32_t urndis_ctrl_set_param(struct urndis_softc *, const char *, u_int32_t,
 void *, size_t);
-#if 0
 u_int32_t urndis_ctrl_reset(struct urndis_softc *);
 u_int32_t urndis_ctrl_keepalive(struct urndis_softc *);
-#endif
 
 int urndis_encap(struct urndis_softc *, struct mbuf *, int);
 void urndis_decap(struct urndis_softc *, struct urndis_chain *, u_int32_t);
@@ -680,7 +676,6 @@ urndis_ctrl_set_param(struct urndis_softc *sc,
return rval;
 }
 
-#if 0
 /* XXX : adrreset, get it from response */
 u_int32_t
 urndis_ctrl_reset(struct urndis_softc *sc)
@@ -765,7 +760,6 @@ urndis_ctrl_keepalive(struct urndis_softc *sc)
 
return rval;
 }
-#endif
 
 int
 urndis_encap(struct urndis_softc *sc, struct mbuf *m, int idx)
@@ -1048,7 +1042,6 @@ urndis_ioctl(struct ifnet *ifp, u_long command, caddr_t 
data)
return (error);
 }
 
-#if 0
 void
 urndis_watchdog(struct ifnet *ifp)
 {
@@ -1064,7 +1057,6 @@ urndis_watchdog(struct ifnet *ifp)
 
urndis_ctrl_keepalive(sc);
 }
-#endif
 
 void
 urndis_init(struct urndis_softc *sc)
@@ -1451,9 +1443,7 @@ urndis_attach(struct device *parent, struct device *self, 
void *aux)
ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
ifp->if_start = urndis_start;
ifp->if_ioctl = urndis_ioctl;
-#if 0
ifp->if_watchdog = urndis_watchdog;
-#endif
 
strlcpy(ifp->if_xname, DEVNAME(sc), IFNAMSIZ);
 

[patch] ehci: change explicit function names to __func__ in debugging printfs

[Mikhail]

While fiddling with ehci.c and fighting with urndis I noticed that most
of the debugging printf's use explicit names, which is inconvenient for
grep'ing. Also, couple of items used wrong function names
(ehci_check_intr instead of ehci_check_qh_intr).

Compilation tested with DIAGNOSTIC and EHCI_DEBUG defines.

diff --git sys/dev/usb/ehci.c sys/dev/usb/ehci.c
index afc423dbbb6..37ff3beeb7a 100644
--- sys/dev/usb/ehci.c
+++ sys/dev/usb/ehci.c
@@ -314,10 +314,10 @@ ehci_init(struct ehci_softc *sc)
sc->sc_offs = EREAD1(sc, EHCI_CAPLENGTH);
 
sparams = EREAD4(sc, EHCI_HCSPARAMS);
-   DPRINTF(("ehci_init: sparams=0x%x\n", sparams));
+   DPRINTF(("%s: sparams=0x%x\n", __func__, sparams));
sc->sc_noport = EHCI_HCS_N_PORTS(sparams);
cparams = EREAD4(sc, EHCI_HCCPARAMS);
-   DPRINTF(("ehci_init: cparams=0x%x\n", cparams));
+   DPRINTF(("%s: cparams=0x%x\n", __func__, cparams));
 
/* MUST clear segment register if 64 bit capable. */
if (EHCI_HCC_64BIT(cparams))
@@ -521,7 +521,7 @@ ehci_intr1(struct ehci_softc *sc)
/* In case the interrupt occurs before initialization has completed. */
if (sc == NULL) {
 #ifdef DIAGNOSTIC
-   printf("ehci_intr1: sc == NULL\n");
+   printf("%s: sc == NULL\n", __func__);
 #endif
return (0);
}
@@ -704,7 +704,7 @@ ehci_check_qh_intr(struct ehci_softc *sc, struct usbd_xfer 
*xfer)
 * short packet (SPD and not ACTIVE).
 */
if (letoh32(lsqtd->qtd.qtd_status) & EHCI_QTD_ACTIVE) {
-   DPRINTFN(12, ("ehci_check_intr: active ex=%p\n", ex));
+   DPRINTFN(12, ("%s: active ex=%p\n", __func__, ex));
for (sqtd = ex->sqtdstart; sqtd != lsqtd; sqtd=sqtd->nextqtd) {
usb_syncmem(>dma,
sqtd->offs + offsetof(struct ehci_qtd, qtd_status),
@@ -724,7 +724,7 @@ ehci_check_qh_intr(struct ehci_softc *sc, struct usbd_xfer 
*xfer)
if (EHCI_QTD_GET_BYTES(status) != 0)
goto done;
}
-   DPRINTFN(12, ("ehci_check_intr: ex=%p std=%p still active\n",
+   DPRINTFN(12, ("%s: ex=%p std=%p still active\n", __func__,
  ex, ex->sqtdstart));
usb_syncmem(>dma,
lsqtd->offs + offsetof(struct ehci_qtd, qtd_status),
@@ -876,7 +876,7 @@ ehci_idone(struct usbd_xfer *xfer)
int s = splhigh();
if (ex->isdone) {
splx(s);
-   printf("ehci_idone: ex=%p is done!\n", ex);
+   printf("%s: ex=%p is done!\n", __func__, ex);
return;
}
ex->isdone = 1;
@@ -904,8 +904,8 @@ ehci_idone(struct usbd_xfer *xfer)
}
 
cerr = EHCI_QTD_GET_CERR(status);
-   DPRINTFN(/*10*/2, ("ehci_idone: len=%d, actlen=%d, cerr=%d, "
-   "status=0x%x\n", xfer->length, actlen, cerr, status));
+   DPRINTFN(/*10*/2, ("%s: len=%d, actlen=%d, cerr=%d, "
+   "status=0x%x\n", __func__, xfer->length, actlen, cerr, status));
xfer->actlen = actlen;
if ((status & EHCI_QTD_HALTED) != 0) {
if ((status & EHCI_QTD_BABBLE) == 0 && cerr > 0)
@@ -920,7 +920,7 @@ ehci_idone(struct usbd_xfer *xfer)
usbd_xfer_isread(xfer) ?
BUS_DMASYNC_POSTREAD : BUS_DMASYNC_POSTWRITE);
usb_transfer_complete(xfer);
-   DPRINTFN(/*12*/2, ("ehci_idone: ex=%p done\n", ex));
+   DPRINTFN(/*12*/2, ("%s: ex=%p done\n", __func__, ex));
 }
 
 void
@@ -1367,7 +1367,7 @@ ehci_open(struct usbd_pipe *pipe)
int ival, speed, naks;
int hshubaddr, hshubport;
 
-   DPRINTFN(1, ("ehci_open: pipe=%p, addr=%d, endpt=%d\n",
+   DPRINTFN(1, ("%s: pipe=%p, addr=%d, endpt=%d\n", __func__,
pipe, addr, ed->bEndpointAddress));
 
if (sc->sc_bus.dying)
@@ -1408,7 +1408,7 @@ ehci_open(struct usbd_pipe *pipe)
speed = EHCI_QH_SPEED_HIGH;
break;
default:
-   panic("ehci_open: bad device speed %d", dev->speed);
+   panic("%s: bad device speed %d", __func__, dev->speed);
}
 
/*
@@ -1512,18 +1512,18 @@ ehci_open(struct usbd_pipe *pipe)
}
/* Spec page 271 says intervals > 16 are invalid */
if (ed->bInterval == 0 || ed->bInterval > 16) {
-   printf("ehci: opening pipe with invalid bInterval\n");
+   printf("%s: opening pipe with invalid bInterval\n", 
__func__);
return (USBD_INVAL);
}
if (UGETW(ed->wMaxPacketSize) == 0) {
-   printf("ehci: zero length endpoint open request\n");
+   printf("%s: zero length endpoint open request\n", 
__func__);
return 

Re: urndis0: IOERROR

[Mikhail]

On Mon, Nov 22, 2021 at 04:28:54PM +0100, Gerhard Roth wrote:
> 
> Your OpenBSD pcap contains not "URB_CONTROL in" packets. Don't know where
> they got lost but since you cannot see any data sent by the function on the
> control pipe, it is almost impossible to do any debugging here. You only see
> what the host sends to the function by miss the replies.
> 

I did some more investigation and patched ehci.c to dump qTDs and USB
registers in ehci_idone function, dump shows that transaction is HALTED
and has XACTERR, also sometimes I see such errors:

Nov 27 17:55:00 edge /bsd: uhub3: device problem, disabling port 2

Spec[1] says the following about XactErr:

> Transaction Error (XactErr). Set to a 1 by the Host Controller during
> status update in the case where the host did not receive a valid
> response from the device (Timeout, CRC, Bad PID, etc.). This bit will
> only be set for IN transactions.

I also tested latest FreeBSD and NetBSD, but they didn't even show
description string, and NetBSD ended with the same "device problem"
output as above.

The modem works on Debian Linux 11, but in journal it says that it uses
CDC.

qTD dump follows, maybe someone will have quick clue what's happening (I
added a comment about a thing which looks strange), but I tend to an
idea of changing the modem.

[1] - 
https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/ehci-specification-for-usb.pdf

Nov 26 21:30:49 edge /bsd: urndis0 at uhub3 port 2 configuration 2 interface 0 
"Yota Devices LTD Modem YOTA 4G LTE" rev 2.00/3.34 addr 5
Nov 26 21:30:49 edge /bsd: urndis0: using RNDIS
Nov 26 21:30:50 edge /bsd: ehci_check_qh_intr: no EHCI_QTD_ACTIVE
Nov 26 21:30:50 edge /bsd: QTD(0xfd80d8438f80) at 0xd8438f80:
Nov 26 21:30:50 edge /bsd:   next=0xd8438e80<> altnext=0xd8438e80<>
Nov 26 21:30:50 edge /bsd:   status=0x8e00: toggle=1 bytes=0x0 ioc=0 
c_page=0x0
Nov 26 21:30:50 edge /bsd: cerr=3 pid=2 stat=0x0
Nov 26 21:30:50 edge /bsd:   buffer[0]=0xd8439ac8
Nov 26 21:30:50 edge /bsd:   buffer[1]=0x
Nov 26 21:30:50 edge /bsd:   buffer[2]=0x
Nov 26 21:30:50 edge /bsd:   buffer[3]=0x
Nov 26 21:30:50 edge /bsd:   buffer[4]=0x
Nov 26 21:30:50 edge /bsd: QTD(0xfd80d8438e80) at 0xd8438e80:
Nov 26 21:30:50 edge /bsd:   next=0x0001 altnext=0x0001
Nov 26 21:30:50 edge /bsd:   status=0x80008148: toggle=1 bytes=0x0 ioc=1 
c_page=0x0
Nov 26 21:30:50 edge /bsd: cerr=0 pid=1 stat=0x48
Nov 26 21:30:50 edge /bsd:   buffer[0]=0x
Nov 26 21:30:50 edge /bsd:   buffer[1]=0x
Nov 26 21:30:50 edge /bsd:   buffer[2]=0x
Nov 26 21:30:50 edge /bsd:   buffer[3]=0x
Nov 26 21:30:50 edge /bsd:   buffer[4]=0x
Nov 26 21:30:50 edge /bsd: cmd=0x00020031, sts=0xc008, ien=0x0037
Nov 26 21:30:50 edge /bsd: frindex=0x3712 ctrdsegm=0x 
periodic=0xd844b000 async=0xd8437e80
Nov 26 21:30:50 edge /bsd: port 1 status=0x1005
Nov 26 21:30:50 edge /bsd: port 2 status=0x1000
Nov 26 21:30:50 edge /bsd: port 3 status=0x1000

Nov 26 21:30:50 edge /bsd: ehci_check_qh_intr: status & EHCI_QTD_HALTED
Nov 26 21:30:50 edge /bsd: QTD(0xfd80d8438e80) at 0xd8438e80:
Nov 26 21:30:50 edge /bsd:   next=0xd8438e00<> altnext=0xd8438e00<>
Nov 26 21:30:50 edge /bsd:   status=0x00080248: toggle=0 bytes=0x8 ioc=0 
c_page=0x0
Nov 26 21:30:50 edge /bsd: cerr=0 pid=2 stat=0x48
  ^
This is strange, the spec says that XactErr can be set only for IN
transactions, but pid=2 means it's SETUP. Also, this qTD address is the
same (0xfd80d8438e80) as previous one, which was also HALTED and
XACTERR.

Nov 26 21:30:50 edge /bsd:   buffer[0]=0xd8439ac0
Nov 26 21:30:50 edge /bsd:   buffer[1]=0x
Nov 26 21:30:50 edge /bsd:   buffer[2]=0x
Nov 26 21:30:50 edge /bsd:   buffer[3]=0x
Nov 26 21:30:50 edge /bsd:   buffer[4]=0x
Nov 26 21:30:50 edge /bsd: QTD(0xfd80d8438e00) at 0xd8438e00:
Nov 26 21:30:50 edge /bsd:   next=0xd8438f80<> altnext=0xd8438f80<>
Nov 26 21:30:50 edge /bsd:   status=0x80180c80: toggle=1 bytes=0x18 ioc=0 
c_page=0x0
Nov 26 21:30:50 edge /bsd: cerr=3 pid=0 stat=0x80
Nov 26 21:30:50 edge /bsd:   buffer[0]=0xd8459dc0
Nov 26 21:30:50 edge /bsd:   buffer[1]=0x
Nov 26 21:30:50 edge /bsd:   buffer[2]=0x
Nov 26 21:30:50 edge /bsd:   buffer[3]=0x
Nov 26 21:30:50 edge /bsd:   buffer[4]=0x
Nov 26 21:30:50 edge /bsd: QTD(0xfd80d8438f80) at 0xd8438f80:
Nov 26 21:30:50 edge /bsd:   next=0x0001 altnext=0x0001
Nov 26 21:30:50 edge /bsd:   status=0x80008d80: toggle=1 bytes=0x0 ioc=1 
c_page=0x0
Nov 26 21:30:50 edge /bsd: cerr=3 pid=1 stat=0x80
Nov 26 21:30:50 edge /bsd:   buffer[0]=0x
Nov 26 21:30:50 edge /bsd:   buffer[1]=0x
Nov 26 21:30:50 edge /bsd:   buffer[2]=0x
Nov 26 21:30:50 edge /bsd:   buffer[3]=0x
Nov 26 21:30:50 edge /bsd:   buffer[4]=0x
Nov 26 21:30:50 edge /bsd: 

Re: urndis0: IOERROR

[Mikhail]

On Mon, Nov 22, 2021 at 12:32:30PM +0300, Mikhail wrote:
> On Mon, Nov 22, 2021 at 09:31:59AM +0100, Gerhard Roth wrote:
> > On 11/20/21 17:12, Mikhail wrote:
> > > Comparing Windows and OpenBSD tcpdumps I noticed some differences:
> > > 
> > > 1) In REMOTE_NDIS_INITIALIZE_MSG (I patched the kernel to send it before
> > > getting MAC address and with proper minor version) bInterfaceClass on
> > > OpenBSD is set to Unknown (0x), on Windows it's properly set to
> > > Wireless Controller (0xe0).
> > > 
> > > 2) The control transfer stage for this message on OpenBSD is set to
> > > Data, on Windows it is Setup.
> > > 
> > > 3) The answer for the message on Windows is with USBD_STATUS_SUCCESS
> > > (0x), on OpenBSD it's Unknown (0x000d).
> > > 
> > > 4) The answer for the message on Windows contains "Control transfer
> > > stage: Complete" message, on OpenBSD it's set to Status.
> > > 
> > > Maybe someone can prompt me:
> > > 
> > > 1) Does those differences matter at all?
> > > 
> > > 2) Where to look regarding changing bInterfaceClass for outgoing
> > > messages? I can see it's properly set in urndis driver (line 133 of
> > > if_urndis.c), but not passed anywhere down to USB stack.
> > 
> > You're getting something wrong here. It is the USB function that sets
> > bInterfaceClass in its device descriptor, not the host.
> 
> It's what I see in wireshark - bInterfaceClass is set for outgoing
> packets, for windows it is in frame 27, in patched openbsd it is in fram
> 172.

Oh, I think I understand what's happening  - this line about
bInterfaceClass in the capture is in square brackets, and according to
the docs it is generated by wireshark:

https://www.wireshark.org/docs/wsug_html_chunked/AppMessages.html

Wireshark provides you with additional information generated out of the
plain packet data or it may need to indicate dissection problems.
Messages generated by Wireshark are usually placed in square brackets
(“[]”).

But it is still a difference between windows and openbsd, not sure how
critical it is.

Re: urndis0: IOERROR

[Mikhail]

Comparing Windows and OpenBSD tcpdumps I noticed some differences:

1) In REMOTE_NDIS_INITIALIZE_MSG (I patched the kernel to send it before
getting MAC address and with proper minor version) bInterfaceClass on
OpenBSD is set to Unknown (0x), on Windows it's properly set to
Wireless Controller (0xe0).

2) The control transfer stage for this message on OpenBSD is set to
Data, on Windows it is Setup.

3) The answer for the message on Windows is with USBD_STATUS_SUCCESS
(0x), on OpenBSD it's Unknown (0x000d).

4) The answer for the message on Windows contains "Control transfer
stage: Complete" message, on OpenBSD it's set to Status.

Maybe someone can prompt me:

1) Does those differences matter at all?

2) Where to look regarding changing bInterfaceClass for outgoing
messages? I can see it's properly set in urndis driver (line 133 of
if_urndis.c), but not passed anywhere down to USB stack.

On Sun, Nov 14, 2021 at 02:39:33PM +0300, Mikhail wrote:
> On Sat, Nov 13, 2021 at 08:27:21PM +0300, Mikhail wrote:
> > Hello, I get aforesaid error when trying to plug in my 4G usb modem, it
> > works well on another laptop with windows 10.
> > 
> > I enabled debug info, but seem the failure somewhere deeper in usb stack
> > and I wasn't able to catch it, can someone advice me on further
> > debugging efforts?
> 
> I did some further investigation with wireshark - in attachment two
> captures - from windows (modem is working) and from openbsd (not
> working).
> 
> I also found some differences in behavior of the device attachment and
> processing. According to RNDIS specs[1]:
> 
> 1) MinorVersion of REMOTE_NDIS_INITIALIZE_MSG must be set to 0x
>(paragraph 2.2.2), but in our code it's set to 1:
> 
> sys/dev/usb/if_urndis.c:
>  459 msg->rm_ver_minor = htole32(1);
> 
> 2) The REMOTE_NDIS_INITIALIZE_MSG message must come first, but in
>OpenBSD first message is getting hardware address (same file):
> 
> 1462 if (urndis_ctrl_query(sc, OID_802_3_PERMANENT_ADDRESS, NULL, 0,
> 1463 , ) != RNDIS_STATUS_SUCCESS) {
> 1464 printf(": unable to get hardware address\n");
> 1465 splx(s);
> 1466 return;
> 1467 }
> 
> In yota-windows.pcapng the REMOTE_NDIS_INITIALIZE_MSG is in frame 27.
> 
> In yota-openbsd.pcapng OID_802_3_PERMANENT_ADDRESS is in fram 290.
> 
> Maybe someone with USB protocol understanding can take a look at the
> captures and note the problems in device responses?
> 
> I also tried latest snapshot, the problem still persist.
> 
> [1] - 
> https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/WinArchive/%5BMS-RNDIS%5D.pdf
> 
> 


yota-patched2.pcapng
Description: Binary data

Re: urndis0: IOERROR

[Mikhail]

On Sat, Nov 13, 2021 at 08:27:21PM +0300, Mikhail wrote:
> Hello, I get aforesaid error when trying to plug in my 4G usb modem, it
> works well on another laptop with windows 10.
> 
> I enabled debug info, but seem the failure somewhere deeper in usb stack
> and I wasn't able to catch it, can someone advice me on further
> debugging efforts?

I did some further investigation with wireshark - in attachment two
captures - from windows (modem is working) and from openbsd (not
working).

I also found some differences in behavior of the device attachment and
processing. According to RNDIS specs[1]:

1) MinorVersion of REMOTE_NDIS_INITIALIZE_MSG must be set to 0x
   (paragraph 2.2.2), but in our code it's set to 1:

sys/dev/usb/if_urndis.c:
 459 msg->rm_ver_minor = htole32(1);

2) The REMOTE_NDIS_INITIALIZE_MSG message must come first, but in
   OpenBSD first message is getting hardware address (same file):

1462 if (urndis_ctrl_query(sc, OID_802_3_PERMANENT_ADDRESS, NULL, 0,
1463 , ) != RNDIS_STATUS_SUCCESS) {
1464 printf(": unable to get hardware address\n");
1465 splx(s);
1466 return;
1467 }

In yota-windows.pcapng the REMOTE_NDIS_INITIALIZE_MSG is in frame 27.

In yota-openbsd.pcapng OID_802_3_PERMANENT_ADDRESS is in fram 290.

Maybe someone with USB protocol understanding can take a look at the
captures and note the problems in device responses?

I also tried latest snapshot, the problem still persist.

[1] - 
https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/WinArchive/%5BMS-RNDIS%5D.pdf


OpenBSD 7.0-current (GENERIC.MP) #32: Sun Nov 14 13:50:09 MSK 2021
mi...@edge.lab.local:/sys/arch/amd64/compile/GENERIC.MP
real mem = 4117065728 (3926MB)
avail mem = 3976323072 (3792MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (65 entries)
bios0: vendor LENOVO version "H0ET96WW (2.56 )" date 06/12/2015
bios0: LENOVO 3259KNG
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI UEFI 
POAT UEFI DBG2
acpi0: wakeup devices P0P1(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S3) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S5) RP05(S4) 
PXSX(S4) RP06(S4) [...]
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) i5-3210M CPU @ 2.50GHz, 2494.72 MHz, 06-3a-09
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,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,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 1 (application processor)
cpu1: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09
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,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.35 MHz, 06-3a-09
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,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz, 2494.34 MHz, 06-3a-09
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,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,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 2

urndis0: IOERROR

[Mikhail]

Hello, I get aforesaid error when trying to plug in my 4G usb modem, it
works well on another laptop with windows 10.

I enabled debug info, but seem the failure somewhere deeper in usb stack
and I wasn't able to catch it, can someone advice me on further
debugging efforts?

urndis0 at uhub3 port 2 configuration 2 interface 0 "Yota Devices LTD Modem 
YOTA 4G LTE" rev 2.00/3.34 addr 5
urndis0: using RNDIS
ehci_idone: len=0, actlen=0, cerr=0, status=0x80008108
ehci_idone: ex=0xfd811de86de0 done
urndis0: in=0x81, out=0x2
urndis0: urndis_ctrl_query send: type 4 len 28 rid 0 oid 0x1010101 infobuflen 0 
infobufoffset 0 devicevchdl 0
ehci_alloc_sqtd_chain: start len=28
ehci_alloc_sqtd_chain: dataphys=0xd8459dc0 dataphyslastpage=0xd8459000 len=28 
curlen=28
ehci_idone: len=28, actlen=0, cerr=0, status=0x80248
ehci_idone: ex=0xfd811de86de0 done
urndis0: IOERROR
urndis0: query failed
: unable to get hardware address
ehci_alloc_sqtd_chain: start len=4
ehci_alloc_sqtd_chain: dataphys=0xd8459dc0 dataphyslastpage=0xd8459000 len=4 
curlen=4
ehci_idone: len=4, actlen=4, cerr=3, status=0x8c00
ehci_idone: ex=0xfd811de86de0 done
ehci_idone: len=0, actlen=0, cerr=3, status=0x8d00
ehci_idone: ex=0xfd811de86de0 done
urndis_detach: urndis0 flags 1
urndis0 detached

Re: [PATCH] Change maximum size of /usr/src to 3G for autoinstall

[Mikhail]

On Sat, Oct 30, 2021 at 11:39:54AM +0300, Mikhail wrote:
> On Sun, Oct 24, 2021 at 02:17:25PM +0300, Mikhail wrote:
> > On Sun, Oct 24, 2021 at 11:32:26AM +0100, Stuart Henderson wrote:
> > > The minimum needs to go up too, a cvs checkout is 1.3G already.
> > > 
> > > (Not that I use auto defaults without changes anyway, they don't
> > > work too well for ports dev..)
> > 
> > Changed minimum to 1.5G.
> 
> Weekly friendly ping. Comments, objections, feedback?
> 
> Maybe someone has another opinion on max (3G) and min (1.5G) values?
> 
> I think bumping them makes sense, since more and more users use git.

Last ping, maybe interested committer appeared on this week.

Re: [PATCH] Change maximum size of /usr/src to 3G for autoinstall

[Mikhail]

On Sun, Oct 24, 2021 at 02:17:25PM +0300, Mikhail wrote:
> On Sun, Oct 24, 2021 at 11:32:26AM +0100, Stuart Henderson wrote:
> > The minimum needs to go up too, a cvs checkout is 1.3G already.
> > 
> > (Not that I use auto defaults without changes anyway, they don't
> > work too well for ports dev..)
> 
> Changed minimum to 1.5G.

Weekly friendly ping. Comments, objections, feedback?

Maybe someone has another opinion on max (3G) and min (1.5G) values?

I think bumping them makes sense, since more and more users use git.

Re: [PATCH] Change maximum size of /usr/src to 3G for autoinstall

[Mikhail]

On Sun, Oct 24, 2021 at 11:32:26AM +0100, Stuart Henderson wrote:
> The minimum needs to go up too, a cvs checkout is 1.3G already.
> 
> (Not that I use auto defaults without changes anyway, they don't
> work too well for ports dev..)

Changed minimum to 1.5G.

diff --git regress/sbin/disklabel/12000.ok regress/sbin/disklabel/12000.ok
index 57045cfd829..a481efd897a 100644
--- regress/sbin/disklabel/12000.ok
+++ regress/sbin/disklabel/12000.ok
@@ -2,25 +2,25 @@
 Writing MBR at offset 0.
 
   a: 0.2G  128  4.2BSD   2048 16384 1 # /
-  a:   432000  128  4.2BSD   2048 16384 1 
-  b: 0.2G   432128swap
-  b:   413470   432128swap
-  d: 0.2G   845600  4.2BSD   2048 16384 1 # /tmp
-  d:   445440   845600  4.2BSD   2048 16384 1 
-  e: 0.2G  1291040  4.2BSD   2048 16384 1 # /var
-  e:   488352  1291040  4.2BSD   2048 16384 1 
-  f: 1.6G  1779392  4.2BSD   2048 16384 1 # /usr
-  f:  3321600  1779392  4.2BSD   2048 16384 1 
-  g: 0.4G  5100992  4.2BSD   2048 16384 1 # /usr/X11R6
-  g:   861312  5100992  4.2BSD   2048 16384 1 
-  h: 1.2G  5962304  4.2BSD   2048 16384 1 # /usr/local
-  h:  2471584  5962304  4.2BSD   2048 16384 1 
-  i: 1.3G  8433888  4.2BSD   2048 16384 1 # /usr/src
-  i:  2712320  8433888  4.2BSD   2048 16384 1 
-  j: 5.0G 11146208  4.2BSD   2048 16384 1 # /usr/obj
-  j: 10585600 11146208  4.2BSD   2048 16384 1 
-  k: 1.4G 21731808  4.2BSD   2048 16384 1 # /home
-  k:  2846176 21731808  4.2BSD   2048 16384 1 
+  a:   411520  128  4.2BSD   2048 16384 1 
+  b: 0.2G   411648swap
+  b:   372510   411648swap
+  d: 0.2G   784160  4.2BSD   2048 16384 1 # /tmp
+  d:   412672   784160  4.2BSD   2048 16384 1 
+  e: 0.2G  1196832  4.2BSD   2048 16384 1 # /var
+  e:   435104  1196832  4.2BSD   2048 16384 1 
+  f: 1.6G  1631936  4.2BSD   2048 16384 1 # /usr
+  f:  3280640  1631936  4.2BSD   2048 16384 1 
+  g: 0.4G  4912576  4.2BSD   2048 16384 1 # /usr/X11R6
+  g:   849024  4912576  4.2BSD   2048 16384 1 
+  h: 1.1G  5761600  4.2BSD   2048 16384 1 # /usr/local
+  h:  2410144  5761600  4.2BSD   2048 16384 1 
+  i: 1.5G  8171744  4.2BSD   2048 16384 1 # /usr/src
+  i:  3113728  8171744  4.2BSD   2048 16384 1 
+  j: 5.0G 11285472  4.2BSD   2048 16384 1 # /usr/obj
+  j: 10569216 11285472  4.2BSD   2048 16384 1 
+  k: 1.3G 21854688  4.2BSD   2048 16384 1 # /home
+  k:  2723296 21854688  4.2BSD   2048 16384 1 
 
 /dev/vnd0a / ffs rw 1 1
 /dev/vnd0k /home ffs rw 1 2
diff --git regress/sbin/disklabel/18000.ok regress/sbin/disklabel/18000.ok
index f66cefa2f63..9a80be91e1b 100644
--- regress/sbin/disklabel/18000.ok
+++ regress/sbin/disklabel/18000.ok
@@ -2,25 +2,25 @@
 Writing MBR at offset 0.
 
   a: 0.5G  128  4.2BSD   2048 16384 1 # /
-  a:  1046400  128  4.2BSD   2048 16384 1 
-  b: 0.8G  1046528swap
-  b:  1642270  1046528swap
-  d: 0.7G  2688800  4.2BSD   2048 16384 1 # /tmp
-  d:  1428480  2688800  4.2BSD   2048 16384 1 
-  e: 1.0G  4117280  4.2BSD   2048 16384 1 # /var
-  e:  2085792  4117280  4.2BSD   2048 16384 1 
-  f: 2.2G  6203072  4.2BSD   2048 16384 1 # /usr
-  f:  4550400  6203072  4.2BSD   2048 16384 1 
-  g: 0.6G 10753472  4.2BSD   2048 16384 1 # /usr/X11R6
-  g:  1229952 10753472  4.2BSD   2048 16384 1 
-  h: 2.1G 11983424  4.2BSD   2048 16384 1 # /usr/local
-  h:  4314784 11983424  4.2BSD   2048 16384 1 
-  i: 1.4G 16298208  4.2BSD   2048 16384 1 # /usr/src
-  i:  2958080 16298208  4.2BSD   2048 16384 1 
-  j: 5.3G 19256288  4.2BSD   2048 16384 1 # /usr/obj
-  j: 11077120 19256288  4.2BSD   2048 16384 1 
-  k: 3.1G 30333408  4.2BSD   2048 16384 1 # /home
-  k:  6532576 30333408  4.2BSD   2048 16384  

[PATCH] Change maximum size of /usr/src to 3G for autoinstall

[Mikhail]

Hello, current maximum size of /usr/src in large disk autoinstall
configuration is set to 2G, which in insufficient for 'git clone', where
the repo already exceeded this size, I suggest to change it to 3G, since
most users have disks large enough to handle it.

diff --git regress/sbin/disklabel/30.ok regress/sbin/disklabel/30.ok
index c43d6f75cab..20f0bd3901e 100644
--- regress/sbin/disklabel/30.ok
+++ regress/sbin/disklabel/30.ok
@@ -15,12 +15,12 @@ Writing MBR at offset 0.
   g:  2097152130680064  4.2BSD   2048 16384 1 
   h:20.0G132777216  4.2BSD   2048 16384 1 # /usr/local
   h: 41943040132777216  4.2BSD   2048 16384 1 
-  i: 2.0G174720256  4.2BSD   2048 16384 1 # /usr/src
-  i:  4194304174720256  4.2BSD   2048 16384 1 
-  j: 6.0G178914560  4.2BSD   2048 16384 1 # /usr/obj
-  j: 12582912178914560  4.2BSD   2048 16384 1 
-  k:   201.7G191497472  4.2BSD   4096 32768 1 # /home
-  k:422904512191497472  4.2BSD   4096 32768 1 
+  i: 3.0G174720256  4.2BSD   2048 16384 1 # /usr/src
+  i:  6291456174720256  4.2BSD   2048 16384 1 
+  j: 6.0G181011712  4.2BSD   2048 16384 1 # /usr/obj
+  j: 12582912181011712  4.2BSD   2048 16384 1 
+  k:   200.7G193594624  4.2BSD   4096 32768 1 # /home
+  k:420807360193594624  4.2BSD   4096 32768 1 
 
 /dev/vnd0a / ffs rw 1 1
 /dev/vnd0k /home ffs rw 1 2
diff --git regress/sbin/disklabel/9.ok regress/sbin/disklabel/9.ok
index ce3ac0a0136..7a6257ff3c4 100644
--- regress/sbin/disklabel/9.ok
+++ regress/sbin/disklabel/9.ok
@@ -15,12 +15,12 @@ Writing MBR at offset 0.
   g:  2097152 60711712  4.2BSD   2048 16384 1 
   h:12.6G 62808864  4.2BSD   2048 16384 1 # /usr/local
   h: 26433184 62808864  4.2BSD   2048 16384 1 
-  i: 2.0G 89242048  4.2BSD   2048 16384 1 # /usr/src
-  i:  4194304 89242048  4.2BSD   2048 16384 1 
-  j: 6.0G 93436352  4.2BSD   2048 16384 1 # /usr/obj
-  j: 12582912 93436352  4.2BSD   2048 16384 1 
-  k:37.3G106019264  4.2BSD   2048 16384 1 # /home
-  k: 78302720106019264  4.2BSD   2048 16384 1 
+  i: 2.8G 89242048  4.2BSD   2048 16384 1 # /usr/src
+  i:  5907200 89242048  4.2BSD   2048 16384 1 
+  j: 6.0G 95149248  4.2BSD   2048 16384 1 # /usr/obj
+  j: 12582912 95149248  4.2BSD   2048 16384 1 
+  k:36.5G107732160  4.2BSD   2048 16384 1 # /home
+  k: 76589824107732160  4.2BSD   2048 16384 1 
 
 /dev/vnd0a / ffs rw 1 1
 /dev/vnd0k /home ffs rw 1 2
diff --git regress/sbin/disklabel/90.ok regress/sbin/disklabel/90.ok
index 1ab20a962ab..3b01eaba657 100644
--- regress/sbin/disklabel/90.ok
+++ regress/sbin/disklabel/90.ok
@@ -15,12 +15,12 @@ Writing MBR at offset 0.
   g:  2097152130680064  4.2BSD   2048 16384 1 
   h:20.0G132777216  4.2BSD   2048 16384 1 # /usr/local
   h: 41943040132777216  4.2BSD   2048 16384 1 
-  i: 2.0G174720256  4.2BSD   2048 16384 1 # /usr/src
-  i:  4194304174720256  4.2BSD   2048 16384 1 
-  j: 6.0G178914560  4.2BSD   2048 16384 1 # /usr/obj
-  j: 12582912178914560  4.2BSD   2048 16384 1 
-  k:   300.0G191497472  4.2BSD   4096 32768 1 # /home
-  k:629145600191497472  4.2BSD   4096 32768 1 
+  i: 3.0G174720256  4.2BSD   2048 16384 1 # /usr/src
+  i:  6291456174720256  4.2BSD   2048 16384 1 
+  j: 6.0G181011712  4.2BSD   2048 16384 1 # /usr/obj
+  j: 12582912181011712  4.2BSD   2048 16384 1 
+  k:   300.0G193594624  4.2BSD   4096 32768 1 # /home
+  k:629145600193594624  4.2BSD   4096 32768 1 
 
 /dev/vnd0a / ffs rw 1 1
 /dev/vnd0k /home ffs rw 1 2
diff --git sbin/disklabel/disklabel.8 sbin/disklabel/disklabel.8
index b38c5e74d22..81c25b5a6e5 100644
--- sbin/disklabel/disklabel.8
+++ sbin/disklabel/disklabel.8
@@ -532,7 +532,7 @@ swap10% of disk.   80M \(en 2x max physical 
memory
 /usr   10% of disk. 1500M \(en 6G
 /usr/X11R6  3% of disk.  384M \(en 1G
 /usr/local 15% of disk.1G \(en 20G
-/usr/src2% of disk. 1300M \(en 2G
+/usr/src2% of disk. 1300M \(en 3G
 /usr/obj4% of disk.5G \(en 6G
 /home  30% of disk.1G \(en 300G
 .Ed
@@ -568,7 +568,7 @@ swap80M-256M 

Re: [patch] man page improvement for sem* family of functions

[Mikhail]

On Sat, Oct 23, 2021 at 11:45:03AM +0100, Jason McIntyre wrote:
> i think this is fine. are you asking for an ok because you are a
> developer? if not i'll commit it unless i hear anyone object.

I'm not a developer, so please commit on your behalf.

Re: [patch] man page improvement for sem* family of functions

[Mikhail]

On Sat, Oct 16, 2021 at 03:13:39PM +0300, Mikhail wrote:
> Hello, I was troubleshooting postgresql not being able to start after
> 'pkill -6 postgres'. The error was:
> 
> FATAL: could not create semaphores: No space left on device
> DETAIL: Failed system call was semget(78927, 17, 03600).
> HINT: This error does *not* mean that you have run out of disk space. It
> occurs when either the system limit for the maximum number of semaphore
> sets (SEMMNI), or the system wide maximum number of semaphores (SEMMNS),
> would be exceeded. You need to raise the respective kernel parameter.
> Alternatively, reduce PostgreSQL's consumption of semaphores by reducing
> its max_connections parameter. The PostgreSQL documentation contains
> more information about configuring your system for PostgreSQL.
> 
> It would have saved me about half a day, if ipcs(1) was mentioned on
> semget(2) man page, web is very short of information about SysV
> semaphore management.
> 
> I thought about adding ipcrm(1) ref too, but decided that it's already
> mentioned on ipcs(1) man page and it would be nice to keep things short,
> but I can redo the patch, if it will be found useful at all.

It turns out that shmat(2) and shmdt(2) man page already mentions
ipcrm(1) and ipcs(1), but it's not mentioned on shmctl(2) and sem*
functions - inlined patch makes things even.

mandoc -T lint is passed.

Comments, OKs?

diff --git lib/libc/sys/semctl.2 lib/libc/sys/semctl.2
index b76b9812692..811270269b8 100644
--- lib/libc/sys/semctl.2
+++ lib/libc/sys/semctl.2
@@ -235,5 +235,7 @@ or the values in
 are greater than the system-imposed limit.
 .El
 .Sh SEE ALSO
+.Xr ipcrm 1 ,
+.Xr ipcs 1 ,
 .Xr semget 2 ,
 .Xr semop 2
diff --git lib/libc/sys/semget.2 lib/libc/sys/semget.2
index 7627e49549a..e06023d16f7 100644
--- lib/libc/sys/semget.2
+++ lib/libc/sys/semget.2
@@ -147,6 +147,8 @@ and no semaphore set associated with
 was found.
 .El
 .Sh SEE ALSO
+.Xr ipcrm 1 ,
+.Xr ipcs 1 ,
 .Xr semctl 2 ,
 .Xr semop 2 ,
 .Xr ftok 3
diff --git lib/libc/sys/semop.2 lib/libc/sys/semop.2
index 691cb5b1b95..6b023207664 100644
--- lib/libc/sys/semop.2
+++ lib/libc/sys/semop.2
@@ -152,5 +152,7 @@ was set in
 points to an illegal address.
 .El
 .Sh SEE ALSO
+.Xr ipcrm 1 ,
+.Xr ipcs 1 ,
 .Xr semctl 2 ,
 .Xr semget 2
diff --git lib/libc/sys/shmctl.2 lib/libc/sys/shmctl.2
index 801c7cecbda..a272d1f482d 100644
--- lib/libc/sys/shmctl.2
+++ lib/libc/sys/shmctl.2
@@ -185,6 +185,8 @@ is not a valid command.
 specifies an invalid address.
 .El
 .Sh SEE ALSO
+.Xr ipcrm 1 ,
+.Xr ipcs 1 ,
 .Xr shmat 2 ,
 .Xr shmget 2
 .Sh STANDARDS

Re: Increase of kern.seminfo.semmns sysctl

[Mikhail]

On Sun, Oct 17, 2021 at 01:36:02PM +0100, Stuart Henderson wrote:
> On 2021/10/17 15:31, Mikhail wrote:
> > Hello, current git of postgresql requires more semaphores than OpenBSD
> > currently suggests as a default, I propose to rise the limit to 100.
> > FreeBSD has 340, as a comparison.
> > 
> > Another solution may be to add the note to README of postgresql's port
> > to rise the limit for the future version, but it looks inconvenient.
> 
> It is there already. Perhaps we could lower the suggested value a bit though:
> 
> $ cvs blame README-server | grep semmns 
> Annotations for README-server
> ***
> 1.13 (sthen22-Nov-12):kern.seminfo.semmns=1024

README talks about busy servers, and implicitly states that OpenBSD
defaults are ok for default configuration, the text can be changed of
course, but I still think that changing OS default is a proper solution.

Full excerpt from README:

Tuning for busy servers
===
The default sizes in the GENERIC kernel for SysV semaphores are only
just large enough for a database with the default configuration
(max_connections 40) if no other running processes use semaphores.
In other cases you will need to increase the limits. Adding the
following in /etc/sysctl.conf will be reasonable for many systems:

kern.seminfo.semmni=60
kern.seminfo.semmns=1024

Increase of kern.seminfo.semmns sysctl

[Mikhail]

Hello, current git of postgresql requires more semaphores than OpenBSD
currently suggests as a default, I propose to rise the limit to 100.
FreeBSD has 340, as a comparison.

Another solution may be to add the note to README of postgresql's port
to rise the limit for the future version, but it looks inconvenient.

Comments, OKs?

diff --git sys/sys/sem.h sys/sys/sem.h
index 184482d7810..03edc2e1d9e 100644
--- sys/sys/sem.h
+++ sys/sys/sem.h
@@ -153,7 +153,7 @@ extern struct seminfo   seminfo;
 #define SEMMNI 10  /* # of semaphore identifiers */
 #endif
 #ifndef SEMMNS
-#define SEMMNS 60  /* # of semaphores in system */
+#define SEMMNS 100 /* # of semaphores in system */
 #endif
 #ifndef SEMUME
 #define SEMUME 10  /* max # of undo entries per process */

[patch] man page improvement for sem* family of functions

[Mikhail]

Hello, I was troubleshooting postgresql not being able to start after
'pkill -6 postgres'. The error was:

FATAL: could not create semaphores: No space left on device
DETAIL: Failed system call was semget(78927, 17, 03600).
HINT: This error does *not* mean that you have run out of disk space. It
occurs when either the system limit for the maximum number of semaphore
sets (SEMMNI), or the system wide maximum number of semaphores (SEMMNS),
would be exceeded. You need to raise the respective kernel parameter.
Alternatively, reduce PostgreSQL's consumption of semaphores by reducing
its max_connections parameter. The PostgreSQL documentation contains
more information about configuring your system for PostgreSQL.

It would have saved me about half a day, if ipcs(1) was mentioned on
semget(2) man page, web is very short of information about SysV
semaphore management.

I thought about adding ipcrm(1) ref too, but decided that it's already
mentioned on ipcs(1) man page and it would be nice to keep things short,
but I can redo the patch, if it will be found useful at all.

man -T lint is passed.

diff --git lib/libc/sys/semctl.2 lib/libc/sys/semctl.2
index b76b9812692..fbf81a5e835 100644
--- lib/libc/sys/semctl.2
+++ lib/libc/sys/semctl.2
@@ -235,5 +235,6 @@ or the values in
 are greater than the system-imposed limit.
 .El
 .Sh SEE ALSO
+.Xr ipcs 1 ,
 .Xr semget 2 ,
 .Xr semop 2
diff --git lib/libc/sys/semget.2 lib/libc/sys/semget.2
index 7627e49549a..0c8033f3bf7 100644
--- lib/libc/sys/semget.2
+++ lib/libc/sys/semget.2
@@ -147,6 +147,7 @@ and no semaphore set associated with
 was found.
 .El
 .Sh SEE ALSO
+.Xr ipcs 1 ,
 .Xr semctl 2 ,
 .Xr semop 2 ,
 .Xr ftok 3
diff --git lib/libc/sys/semop.2 lib/libc/sys/semop.2
index 691cb5b1b95..910f8508da7 100644
--- lib/libc/sys/semop.2
+++ lib/libc/sys/semop.2
@@ -152,5 +152,6 @@ was set in
 points to an illegal address.
 .El
 .Sh SEE ALSO
+.Xr ipcs 1 ,
 .Xr semctl 2 ,
 .Xr semget 2

Re: ieee80211_node diff

[Mikhail]

OK? Anyone?

On Thu, Jan 23, 2020 at 6:08 PM Mikhail  wrote:
>
> There is no way ic_bgscan_fail can be less then zero, since it's unsigned[1].
>
> Sorry for the attachment - web browser mail in act.
>
> [1] - http://bxr.su/OpenBSD/sys/net80211/ieee80211_var.h#251

ieee80211_node diff

[Mikhail]

There is no way ic_bgscan_fail can be less then zero, since it's unsigned[1].

Sorry for the attachment - web browser mail in act.

[1] - http://bxr.su/OpenBSD/sys/net80211/ieee80211_var.h#251


ieee80211_node.patch
Description: Binary data

Re: cwm: remove menu-ssh

[Mikhail]

Can you elaborate on tools for menu-ssh replacement?

On Wed, Jan 22, 2020 at 11:16 PM Okan Demirmen  wrote:
>
> Hi,
>
> I think we've (or at least I have) mused about this for a while; a
> recent mail reminded me that this feature should go - a window manager
> doesn't need to parse the ssh known_hosts file for a menu; there are
> better tools for this.
>
> Remove menu-ssh.
>
> okay?
>
> Index: calmwm.h
> ===
> RCS file: /home/open/cvs/xenocara/app/cwm/calmwm.h,v
> retrieving revision 1.372
> diff -u -p -r1.372 calmwm.h
> --- calmwm.h22 Jan 2020 19:58:35 -  1.372
> +++ calmwm.h22 Jan 2020 20:09:13 -
> @@ -304,7 +304,6 @@ struct conf {
> int  xrandr;
> int  xrandr_event_base;
> char*conf_file;
> -   char*known_hosts;
> char*wm_argv;
> int  debug;
>  };
> @@ -517,7 +516,6 @@ void kbfunc_menu_cmd(void *, 
> struct c
>  voidkbfunc_menu_group(void *, struct cargs *);
>  voidkbfunc_menu_wm(void *, struct cargs *);
>  voidkbfunc_menu_exec(void *, struct cargs *);
> -voidkbfunc_menu_ssh(void *, struct cargs *);
>  voidkbfunc_client_menu_label(void *, struct cargs *);
>  voidkbfunc_exec_cmd(void *, struct cargs *);
>  voidkbfunc_exec_lock(void *, struct cargs *);
> Index: conf.c
> ===
> RCS file: /home/open/cvs/xenocara/app/cwm/conf.c,v
> retrieving revision 1.249
> diff -u -p -r1.249 conf.c
> --- conf.c  7 Mar 2019 12:54:21 -   1.249
> +++ conf.c  22 Jan 2020 20:09:24 -
> @@ -179,7 +179,6 @@ static const struct {
>
> { FUNC_SC(menu-cmd, menu_cmd, 0) },
> { FUNC_SC(menu-group, menu_group, 0) },
> -   { FUNC_SC(menu-ssh, menu_ssh, 0) },
> { FUNC_SC(menu-window, menu_client, CWM_MENU_WINDOW_ALL) },
> { FUNC_SC(menu-window-hidden, menu_client, CWM_MENU_WINDOW_HIDDEN) },
> { FUNC_SC(menu-exec, menu_exec, 0) },
> @@ -210,7 +209,6 @@ static const struct {
> { "CM-Delete",  "lock" },
> { "M-question", "menu-exec" },
> { "CM-w",   "menu-exec-wm" },
> -   { "M-period",   "menu-ssh" },
> { "M-Return",   "window-hide" },
> { "M-Down", "window-lower" },
> { "M-Up",   "window-raise" },
> @@ -316,7 +314,6 @@ conf_init(struct conf *c)
> home = "/";
> }
> xasprintf(>conf_file, "%s/%s", home, ".cwmrc");
> -   xasprintf(>known_hosts, "%s/%s", home, ".ssh/known_hosts");
>  }
>
>  void
> @@ -363,7 +360,6 @@ conf_clear(struct conf *c)
> free(c->color[i]);
>
> free(c->conf_file);
> -   free(c->known_hosts);
> free(c->font);
> free(c->wmname);
>  }
> Index: cwm.1
> ===
> RCS file: /home/open/cvs/xenocara/app/cwm/cwm.1,v
> retrieving revision 1.65
> diff -u -p -r1.65 cwm.1
> --- cwm.1   9 Jul 2019 21:38:44 -   1.65
> +++ cwm.1   22 Jan 2020 20:08:19 -
> @@ -140,15 +140,6 @@ Resize window by a large amount; see
>  Spawn
>  .Dq exec program
>  dialog.
> -.It Ic M-period
> -Spawn
> -.Dq ssh to
> -dialog.
> -This parses
> -.Pa $HOME/.ssh/known_hosts
> -to provide host auto-completion.
> -.Xr ssh 1
> -will be executed via the configured terminal emulator.
>  .It Ic CM-w
>  Spawn
>  .Dq exec WindowManager
> Index: cwmrc.5
> ===
> RCS file: /home/open/cvs/xenocara/app/cwm/cwmrc.5,v
> retrieving revision 1.73
> diff -u -p -r1.73 cwmrc.5
> --- cwmrc.5 2 Jul 2019 23:37:47 -   1.73
> +++ cwmrc.5 22 Jan 2020 20:07:57 -
> @@ -280,10 +280,6 @@ menu.
>  Launch
>  .Dq exec WindowManager
>  menu.
> -.It menu-ssh
> -Launch
> -.Dq ssh
> -menu.
>  .It group-toggle-[n]
>  Toggle visibility of group n, where n is 1-9.
>  .It group-only-[n]
> Index: kbfunc.c
> ===
> RCS file: /home/open/cvs/xenocara/app/cwm/kbfunc.c,v
> retrieving revision 1.167
> diff -u -p -r1.167 kbfunc.c
> --- kbfunc.c21 Jan 2020 15:50:03 -  1.167
> +++ kbfunc.c22 Jan 2020 20:09:03 -
> @@ -647,72 +647,6 @@ out:
>  }
>
>  void
> -kbfunc_menu_ssh(void *ctx, struct cargs *cargs)
> -{
> -   struct screen_ctx   *sc = ctx;
> -   struct cmd_ctx  *cmd;
> -   struct menu *mi;
> -   struct menu_qmenuq;
> -   FILE*fp;
> -   char*buf, *lbuf, *p;
> -   char hostbuf[HOST_NAME_MAX+1];
> -   char path[PATH_MAX];
> -   int 

libressl: Allow custom config location

[Mikhail Novosyolov]

Hi,

I was packaging LibreSSL for a GNU/Linux distro (ROSA) and had to 
slightly patch it to adopt for needed usage scenario.


I wanted LibreSSL to:
- coexist with OpenSSL
- be installed into /opt
- do not conflict with OpenSSL devel packages
- use /etc/ssl (/etc/pki/tls in ROSA) from OpenSSL

For this purpose, it is required to be able to separate configs of 
OpenSSL and LibreSSL.


Example:
export CFLAGS="$CFLAGS -DX509_CONF_FILE='\"/etc/ssl/libressl.cnf\"'"

Proof that this patch works:

[root@rosa-2019 ~]# strace -f libressl -h 2>&1 | grep -E 
'openssl.cnf|libressl.cnf'

openat(AT_FDCWD, "/etc/pki/tls/libressl.cnf", O_RDONLY) = 3
[root@rosa-2019 ~]#

Full build spec is here: https://abf.io/import/libressl

Patch is attached, diff is also copypasted bellow.
-

diff --git a/src/lib/libcrypto/conf/conf_mod.c 
b/src/lib/libcrypto/conf/conf_mod.c

index 9f252385e..f5271c89d 100644
--- a/src/lib/libcrypto/conf/conf_mod.c
+++ b/src/lib/libcrypto/conf/conf_mod.c
@@ -545,8 +545,12 @@ CONF_get1_default_config_file(void)
 {
 char *file = NULL;

+#ifndef X509_CONF_FILE
 if (asprintf(, "%s/openssl.cnf",
     X509_get_default_cert_area()) == -1)
+#else
+    if (asprintf(, X509_CONF_FILE) == -1)
+#endif
     return (NULL);
 return file;
 }
diff --git a/src/usr.bin/openssl/apps.c b/src/usr.bin/openssl/apps.c
index c9a2f34b2..313d6ecee 100644
--- a/src/usr.bin/openssl/apps.c
+++ b/src/usr.bin/openssl/apps.c
@@ -1213,7 +1213,11 @@ make_config_name()
 const char *t = X509_get_default_cert_area();
 char *p;

+#ifndef X509_CONF_FILE
 if (asprintf(, "%s/openssl.cnf", t) == -1)
+#else
+    if (asprintf(, X509_CONF_FILE) == -1)
+#endif
     return NULL;
 return p;
 }

>From 4074611c49806fa5e8937a5aa24d9084235a89a5 Mon Sep 17 00:00:00 2001
From: Mikhail Novosyolov 
Date: Fri, 29 Nov 2019 21:24:49 +0300
Subject: [PATCH] Allow custom config location

I want LibreSSL to:
- coexist with OpenSSL
- be installed into /opt
- do not conflict with OpenSSL devel packages
- use /etc/ssl (/etc/pki/tls in ROSA) from OpenSSL

For this purpose, it is required to be able to separate configs of OpenSSL and LibreSSL.

Example:
export CFLAGS="$CFLAGS -DX509_CONF_FILE='\"/etc/ssl/libressl.cnf\"'"
---
 src/lib/libcrypto/conf/conf_mod.c | 4 
 src/usr.bin/openssl/apps.c| 4 
 2 files changed, 8 insertions(+)

diff --git a/src/lib/libcrypto/conf/conf_mod.c b/src/lib/libcrypto/conf/conf_mod.c
index 9f252385e..f5271c89d 100644
--- a/src/lib/libcrypto/conf/conf_mod.c
+++ b/src/lib/libcrypto/conf/conf_mod.c
@@ -545,8 +545,12 @@ CONF_get1_default_config_file(void)
 {
 	char *file = NULL;
 
+#ifndef X509_CONF_FILE
 	if (asprintf(, "%s/openssl.cnf",
 	X509_get_default_cert_area()) == -1)
+#else
+	if (asprintf(, X509_CONF_FILE) == -1)
+#endif
 		return (NULL);
 	return file;
 }
diff --git a/src/usr.bin/openssl/apps.c b/src/usr.bin/openssl/apps.c
index c9a2f34b2..313d6ecee 100644
--- a/src/usr.bin/openssl/apps.c
+++ b/src/usr.bin/openssl/apps.c
@@ -1213,7 +1213,11 @@ make_config_name()
 	const char *t = X509_get_default_cert_area();
 	char *p;
 
+#ifndef X509_CONF_FILE
 	if (asprintf(, "%s/openssl.cnf", t) == -1)
+#else
+	if (asprintf(, X509_CONF_FILE) == -1)
+#endif
 		return NULL;
 	return p;
 }
-- 
2.20.1

Fwd: new usb id for urtwn

[Mikhail]

Anyone?


-- Forwarded message --
From: Mikhail 
Date: Wed, Jul 11, 2018 at 6:12 PM
Subject: Re: new usb id for urtwn
To: Stuart Henderson 
Cc: tech@openbsd.org


Sorry, new patch attached.

On Wed, Jul 11, 2018 at 4:45 PM, Stuart Henderson  wrote:
> On 2018/07/11 16:27, Mikhail wrote:
>> Ping? Ok?
>>
>> On Thu, 21 Jun 2018 at 18:28, Mikhail  wrote:
>>
>> > Taken from FreeBSD:
>> >
>> > diff --git a/sys/dev/usb/if_urtwn.c b/sys/dev/usb/if_urtwn.c
>> > index 0e204a196b1..d9aee16b05f 100644
>> > --- a/sys/dev/usb/if_urtwn.c
>> > +++ b/sys/dev/usb/if_urtwn.c
>> > @@ -306,6 +306,7 @@ static const struct urtwn_type {
>> > URTWN_DEV_8192CU(TRENDNET,  RTL8192CU),
>> > URTWN_DEV_8192CU(ZYXEL, RTL8192CU),
>> > /* URTWN_RTL8188E */
>> > +   URTWN_DEV_8188EU(ABOCOM,RTL8188EU),
>> > URTWN_DEV_8188EU(DLINK, DWA123D1),
>> > URTWN_DEV_8188EU(DLINK, DWA125D1),
>> > URTWN_DEV_8188EU(ELECOM,WDC150SU2M),
>> >
>
> Not OK. Try compiling it...
>
diff --git a/sys/dev/usb/if_urtwn.c b/sys/dev/usb/if_urtwn.c
index 0e204a196b1..e6152e8fb13 100644
--- a/sys/dev/usb/if_urtwn.c
+++ b/sys/dev/usb/if_urtwn.c
@@ -306,6 +306,7 @@ static const struct urtwn_type {
 	URTWN_DEV_8192CU(TRENDNET,	RTL8192CU),
 	URTWN_DEV_8192CU(ZYXEL,		RTL8192CU),
 	/* URTWN_RTL8188E */
+	URTWN_DEV_8188EU(ABOCOM,RTL8188EU),
 	URTWN_DEV_8188EU(DLINK,		DWA123D1),
 	URTWN_DEV_8188EU(DLINK,		DWA125D1),
 	URTWN_DEV_8188EU(ELECOM,	WDC150SU2M),
diff --git a/sys/dev/usb/usbdevs.h b/sys/dev/usb/usbdevs.h
index 0fc246400a5..d8688378143 100644
--- a/sys/dev/usb/usbdevs.h
+++ b/sys/dev/usb/usbdevs.h
@@ -727,6 +727,7 @@
 #define	USB_PRODUCT_ABOCOM_XX9	0x4104		/* XX9 */
 #define	USB_PRODUCT_ABOCOM_WL54	0x6001		/* WL54 */
 #define	USB_PRODUCT_ABOCOM_RTL8192CU	0x8178		/* RTL8192CU */
+#define	USB_PRODUCT_ABOCOM_RTL8188EU	0x8179		/* RTL8188EU */
 #define	USB_PRODUCT_ABOCOM_RTL8188CU_1	0x8188		/* RTL8188CU */
 #define	USB_PRODUCT_ABOCOM_RTL8188CU_2	0x8189		/* RTL8188CU */
 #define	USB_PRODUCT_ABOCOM_XX10	0xabc1		/* XX10 */

Re: new usb id for urtwn

[Mikhail]

Sorry, new patch attached.

On Wed, Jul 11, 2018 at 4:45 PM, Stuart Henderson  wrote:
> On 2018/07/11 16:27, Mikhail wrote:
>> Ping? Ok?
>>
>> On Thu, 21 Jun 2018 at 18:28, Mikhail  wrote:
>>
>> > Taken from FreeBSD:
>> >
>> > diff --git a/sys/dev/usb/if_urtwn.c b/sys/dev/usb/if_urtwn.c
>> > index 0e204a196b1..d9aee16b05f 100644
>> > --- a/sys/dev/usb/if_urtwn.c
>> > +++ b/sys/dev/usb/if_urtwn.c
>> > @@ -306,6 +306,7 @@ static const struct urtwn_type {
>> > URTWN_DEV_8192CU(TRENDNET,  RTL8192CU),
>> > URTWN_DEV_8192CU(ZYXEL, RTL8192CU),
>> > /* URTWN_RTL8188E */
>> > +   URTWN_DEV_8188EU(ABOCOM,RTL8188EU),
>> > URTWN_DEV_8188EU(DLINK, DWA123D1),
>> > URTWN_DEV_8188EU(DLINK, DWA125D1),
>> > URTWN_DEV_8188EU(ELECOM,WDC150SU2M),
>> >
>
> Not OK. Try compiling it...
>
diff --git a/sys/dev/usb/if_urtwn.c b/sys/dev/usb/if_urtwn.c
index 0e204a196b1..e6152e8fb13 100644
--- a/sys/dev/usb/if_urtwn.c
+++ b/sys/dev/usb/if_urtwn.c
@@ -306,6 +306,7 @@ static const struct urtwn_type {
 	URTWN_DEV_8192CU(TRENDNET,	RTL8192CU),
 	URTWN_DEV_8192CU(ZYXEL,		RTL8192CU),
 	/* URTWN_RTL8188E */
+	URTWN_DEV_8188EU(ABOCOM,RTL8188EU),
 	URTWN_DEV_8188EU(DLINK,		DWA123D1),
 	URTWN_DEV_8188EU(DLINK,		DWA125D1),
 	URTWN_DEV_8188EU(ELECOM,	WDC150SU2M),
diff --git a/sys/dev/usb/usbdevs.h b/sys/dev/usb/usbdevs.h
index 0fc246400a5..d8688378143 100644
--- a/sys/dev/usb/usbdevs.h
+++ b/sys/dev/usb/usbdevs.h
@@ -727,6 +727,7 @@
 #define	USB_PRODUCT_ABOCOM_XX9	0x4104		/* XX9 */
 #define	USB_PRODUCT_ABOCOM_WL54	0x6001		/* WL54 */
 #define	USB_PRODUCT_ABOCOM_RTL8192CU	0x8178		/* RTL8192CU */
+#define	USB_PRODUCT_ABOCOM_RTL8188EU	0x8179		/* RTL8188EU */
 #define	USB_PRODUCT_ABOCOM_RTL8188CU_1	0x8188		/* RTL8188CU */
 #define	USB_PRODUCT_ABOCOM_RTL8188CU_2	0x8189		/* RTL8188CU */
 #define	USB_PRODUCT_ABOCOM_XX10	0xabc1		/* XX10 */

Re: new usb id for urtwn

[Mikhail]

Ping? Ok?

On Thu, 21 Jun 2018 at 18:28, Mikhail  wrote:

> Taken from FreeBSD:
>
> diff --git a/sys/dev/usb/if_urtwn.c b/sys/dev/usb/if_urtwn.c
> index 0e204a196b1..d9aee16b05f 100644
> --- a/sys/dev/usb/if_urtwn.c
> +++ b/sys/dev/usb/if_urtwn.c
> @@ -306,6 +306,7 @@ static const struct urtwn_type {
> URTWN_DEV_8192CU(TRENDNET,  RTL8192CU),
> URTWN_DEV_8192CU(ZYXEL, RTL8192CU),
> /* URTWN_RTL8188E */
> +   URTWN_DEV_8188EU(ABOCOM,RTL8188EU),
> URTWN_DEV_8188EU(DLINK, DWA123D1),
> URTWN_DEV_8188EU(DLINK, DWA125D1),
> URTWN_DEV_8188EU(ELECOM,WDC150SU2M),
>

Re: integer divide fault trap: ilk_compute_vm_level panic

[Mikhail]

ping?

On Fri, Jun 15, 2018 at 8:47 PM, Mikhail  wrote:
> Hello, tech@, I'm running freshly upgraded -current (upgraded via
> today snapshot from -stable 6.3 where I had similar issue) on my
> ThinkPad Edge 530.
>
> I get attached panic when my monitor is connected through HDMI port,
> the panic happens just after the boot, on the moment when xenodm is
> starting. If I unplug HDMI port before the boot then everything
> working fine, same if I connect it back after xenodm already up and
> running.
>
> Photo of the panic: https://ibb.co/ip4bNy
>
> dmesg: https://pastebin.com/J466MiYc

new usb id for urtwn

[Mikhail]

Taken from FreeBSD:

diff --git a/sys/dev/usb/if_urtwn.c b/sys/dev/usb/if_urtwn.c
index 0e204a196b1..d9aee16b05f 100644
--- a/sys/dev/usb/if_urtwn.c
+++ b/sys/dev/usb/if_urtwn.c
@@ -306,6 +306,7 @@ static const struct urtwn_type {
URTWN_DEV_8192CU(TRENDNET,  RTL8192CU),
URTWN_DEV_8192CU(ZYXEL, RTL8192CU),
/* URTWN_RTL8188E */
+   URTWN_DEV_8188EU(ABOCOM,RTL8188EU),
URTWN_DEV_8188EU(DLINK, DWA123D1),
URTWN_DEV_8188EU(DLINK, DWA125D1),
URTWN_DEV_8188EU(ELECOM,WDC150SU2M),

integer divide fault trap: ilk_compute_vm_level panic

[Mikhail]

Hello, tech@, I'm running freshly upgraded -current (upgraded via
today snapshot from -stable 6.3 where I had similar issue) on my
ThinkPad Edge 530.

I get attached panic when my monitor is connected through HDMI port,
the panic happens just after the boot, on the moment when xenodm is
starting. If I unplug HDMI port before the boot then everything
working fine, same if I connect it back after xenodm already up and
running.

Photo of the panic: https://ibb.co/ip4bNy

dmesg: https://pastebin.com/J466MiYc

missed keybinding in cwm.1

[Mikhail]

Missed keybinding in the man page:

diff --git a/app/cwm/cwm.1 b/app/cwm/cwm.1
index 3b4e76e83..3f8f5d241 100644
--- a/app/cwm/cwm.1
+++ b/app/cwm/cwm.1
@@ -103,6 +103,8 @@ Reverse cycle through currently visible windows.
 Delete current window.
 .It Ic CM-[n]
 Toggle visibility of group n, where n is 1-9.
+.It Ic CM-0
+Toggle visibility of all groups.
 .It Ic CM-a
 Toggle visibility of all groups.
 .It Ic CM-g

netintro.4 fix

[Mikhail]

Nuke non-existing chapter link in netintro.4.

Index: netintro.4
===
RCS file: /home/misha/work/cvs/src/share/man/man4/netintro.4,v
retrieving revision 1.52
diff -u -p -r1.52 netintro.4
--- netintro.4  28 Apr 2018 16:16:43 -  1.52
+++ netintro.4  13 Jun 2018 15:00:28 -
@@ -97,14 +97,6 @@ specification of the related drivers for
 to the
 .Xr config 8
 program.
-The
-.Sx DIAGNOSTICS
-section lists messages which may appear on the console
-and/or in the system error log,
-.Pa /var/log/messages
-(see
-.Xr syslogd 8 ) ,
-due to errors in device operation.
 .Pp
 Network interfaces may be collected together into interface groups.
 An interface group is a container that can be used generically when

Re: urndis printf cleanup

[Mikhail]

On Fri, Oct 27, 2017 at 1:19 PM, Jeremie Courreges-Anglas
<j...@wxcvbn.org> wrote:
> On Fri, Oct 27 2017, Mikhail <mp39...@gmail.com> wrote:
>> add missed DEVNAME's and \n's
>
> They are not missing.  The point is to have _attach() print a single
> line in dmesg.
>
> PS: your diff would not apply (mangled whitespace)
>

it doesn't print like a single line anyway:

urndis0 at uhub3 port 2 configuration 2 interface 0 "Yota Devices LTD
Modem YOTA 4G LTE" rev 2.00/3.34 addr 5
urndis0: using RNDISurndis0: IOERROR
urndis0: query failed
: unable to get hardware address
urndis0 detached

patch is attached


rndis_printf.patch
Description: Binary data

urndis printf cleanup

[Mikhail]

add missed DEVNAME's and \n's

Index: dev/usb/if_urndis.c
===
RCS file: /home/misha/work/cvs/src/sys/dev/usb/if_urndis.c,v
retrieving revision 1.67
diff -u -p -r1.67 if_urndis.c
--- dev/usb/if_urndis.c 19 Jul 2017 16:31:56 - 1.67
+++ dev/usb/if_urndis.c 27 Oct 2017 12:10:28 -
@@ -1396,7 +1396,7 @@ urndis_attach(struct device *parent, str
  }

  uc = urndis_lookup(id);
- printf("%s: using %s", DEVNAME(sc), uc->typestr);
+ printf("%s: using %s\n", DEVNAME(sc), uc->typestr);

  id = usbd_get_interface_descriptor(sc->sc_iface_data);
  cd = usbd_get_config_descriptor(sc->sc_udev);
@@ -1404,7 +1404,8 @@ urndis_attach(struct device *parent, str

  for (j = 0; j < altcnt; j++) {
  if (usbd_set_interface(sc->sc_iface_data, j)) {
- printf(": interface alternate setting %u failed\n", j);
+ printf("%s: interface alternate setting %u failed\n",
+ DEVNAME(sc), j);
  return;
  }
  /* Find endpoints. */
@@ -1414,8 +1415,8 @@ urndis_attach(struct device *parent, str
  ed = usbd_interface2endpoint_descriptor(
  sc->sc_iface_data, i);
  if (!ed) {
- printf(": no descriptor for bulk endpoint "
- "%u\n", i);
+ printf("%s: no descriptor for bulk endpoint "
+ "%u\n", DEVNAME(sc), i);
  return;
  }
  if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_IN &&
@@ -1439,9 +1440,9 @@ urndis_attach(struct device *parent, str
  }

  if (sc->sc_bulkin_no == -1)
- printf(": could not find data bulk in\n");
+ printf("%s: could not find data bulk in\n", DEVNAME(sc));
  if (sc->sc_bulkout_no == -1 )
- printf(": could not find data bulk out\n");
+ printf("%s: could not find data bulk out\n", DEVNAME(sc));
  return;

  found:
@@ -1461,7 +1462,7 @@ urndis_attach(struct device *parent, str

  if (urndis_ctrl_query(sc, OID_802_3_PERMANENT_ADDRESS, NULL, 0,
  , ) != RNDIS_STATUS_SUCCESS) {
- printf(": unable to get hardware address\n");
+ printf("%s: unable to get hardware address\n", DEVNAME(sc));
  splx(s);
  return;
  }

[patch] acpithinkpad(4) unknown event 0x6005

[Mikhail]

Hello, when I press 'Fn' key on on thinkpad e530 I see aforesaid message
on console log.

Can someone review inlined patch?


Index: dev/acpi/acpithinkpad.c
===
RCS file: /home/misha/work/cvs/src/sys/dev/acpi/acpithinkpad.c,v
retrieving revision 1.57
diff -u -p -r1.57 acpithinkpad.c
--- dev/acpi/acpithinkpad.c 28 Feb 2017 10:39:07 -  1.57
+++ dev/acpi/acpithinkpad.c 25 May 2017 05:51:58 -
@@ -94,6 +94,7 @@
 #defineTHINKPAD_TABLET_PEN_INSERTED0x500b
 #defineTHINKPAD_TABLET_PEN_REMOVED 0x500c
 #defineTHINKPAD_SWITCH_NUMLOCK 0x6000
+#defineTHINKPAD_SWITCH_FN  0x6005
 #defineTHINKPAD_BUTTON_ROTATION_LOCK   0x6020
 #defineTHINKPAD_THERMAL_TABLE_CHANGED  0x6030
 #defineTHINKPAD_POWER_CHANGED  0x6040
@@ -460,6 +461,7 @@ thinkpad_hotkey(struct aml_node *node, i
case THINKPAD_TABLET_PEN_INSERTED:
case THINKPAD_TABLET_PEN_REMOVED:
case THINKPAD_SWITCH_NUMLOCK:
+   case THINKPAD_SWITCH_FN:
case THINKPAD_BUTTON_ROTATION_LOCK:
case THINKPAD_TABLET_SCREEN_NORMAL:
case THINKPAD_TABLET_SCREEN_ROTATED:

Re: merge ping6(8) into ping(8)

[Mikhail]

On Sun, Sep 18, 2016 at 12:11 AM, Theo de Raadt <dera...@openbsd.org> wrote:
>>  > this does 2 things:
>>  > [...]
>>
>> I may recall what I have sent to you in private email, excerpt from
>> FreeBSD ping6 manpage:
>> [...]
>> When we have two binaries I have more trust when one of them is working
>> *only* with IPv4 and another one *only* with IPv6.
>>
>> So, what user problems are you trying to solve with this merge?
>>
>
> Mikhail, with great regret I am informing you that the opinion of some
> random gmail user does not actually matter around here.

It's not about opinion, everyone has it. It's about understanding why
a thing was done. If a person can't answer to the question "why" a
thing was done, I suppose he don't fully understand a solution to a
problem he is trying to solve.

Random gmail users can bring value as much as fullnamed developers.

Re: merge ping6(8) into ping(8)

[Mikhail]

> this does 2 things:
> [...]

I may recall what I have sent to you in private email, excerpt from 
FreeBSD ping6 manpage:


8<8<8<8<8<8<
There have been many discussions on why we separate ping6 and ping(8).
Some people argued that it would be more convenient to uniform the ping
command for both IPv4 and IPv6.  The followings are an answer to the 
request.


From a developer's point of view: since the underling raw sockets API is
totally different between IPv4 and IPv6, we would end up having two 
types of code base.  There would actually be less benefit to uniform the 
two commands into a single command from the developer's standpoint.


From an operator's point of view: unlike ordinary network applications 
like remote login tools, we are usually aware of address family when 
using network management tools.  We do not just want to know the

reachability to the host, but want to know the reachability to the host
via a particular network protocol such as IPv6.  Thus, even if we had a
unified ping(8) command for both IPv4 and IPv6, we would usually type a
-6 or -4 option (or something like those) to specify the particular
address family.  This essentially means that we have two different
commands.
8<8<8<8<8<8<

When we have two binaries I have more trust when one of them is working 
*only* with IPv4 and another one *only* with IPv6.


So, what user problems are you trying to solve with this merge?

Re: Further cleanup of Russian calendars

[Mikhail]

2015-10-23 14:15 GMT+03:00 Vadim Zhukov :
> Further cleanup in Russian calendars:
>
>   * Fix #ifndef safeguards (rename/add where missing);
>   * Use consistent spelling for year when it's mentioned in day desc;
>   * Tweak some wrong casing cases;
>   * Remove calendar.msk since Moscow doesn't have summer time anymore,
> and that was the only thing this file was about;
>   * A few other corrections.
>
> Still seeking for a way to define a day with fixed shift from the year
> start: the Programmer's Day is official in Russia, happens at 256th
> day of the year, but calendar(1) handles up to 31 days per month max.
>
> Okay?
> --

Hello.

>  07/Sun+3   День металлурга
> -07/Sun+4   День Военно-Морского Флота
> +07/Sun+4   День военно-морского флота

This one should stay capitalized: http://kremlin.ru/acts/bank/23860

>  /* Август */
>  08/02  День воздушно-десантных войск России
>  08/06  Всемирный день борьбы за запрещение ядерного оружия.
>  08/09  Всемирный день коренных народов мира
> -08/22  День Государственного Флага Российской Федерации
> +08/22  День государственного флага Российской Федерации

I think "государственного" should be capitalized too (флаг is okay)

>  08/27  День российского кино
>  08/SunFirstДень железнодорожника
>  08/Sat+2   День физкультурника
>  08/Sun+2   День строителя
> -08/Sun+3   День Воздушного Флота России
> +08/Sun+3   День воздушного флота России

Same thing as with naval forces.

[patch] urtwn(4) hostap mode support for 8188eu

[Mikhail]

Hello, inlined patch adds support for hostap mode for 8188eu chip.

One known issue is documented in urtwn(4), I would like to know if
people with other hw will see it too, or if it's my local issue.

If you want to help, please test the patch and in case of problems
provide as much as you can from this list:

 - commands with which you started the AP
 - dmesg | grep urtwn
 - ifconfig 
 - tcpdump -i urtwn0 -y IEEE802_11 -w test.pcap (command must be run on
   the AP before problem occurs; I assume mailing the file to maillist
   isn't appropriate, so mail it to me directly)
 - if you can - sniff from the client (or, ideally, from third PC) too,
   since previous command won't give radiotap headers and won't show
   beacons.

Patch has been tested with tl-wn725n, and mac mini as a client, running
802.11g and wpa2, speed is about 3-4 mbits in presence of ~20 ssids.
Also, usual client mode with 8188eu chip is confirmed to work as before.

Since the patch touches some bits in STA mode initialization, it would
be helpful, if people with non-8188eu chip test it too in usual client
mode.

Any feedback and advice are appreciated.

diff --git share/man/man4/urtwn.4 share/man/man4/urtwn.4
index d2007a7..00928d4 100644
--- share/man/man4/urtwn.4
+++ share/man/man4/urtwn.4
@@ -58,6 +58,8 @@ capture packets from networks which it wouldn't normally have 
access to,
 or to scan for access points.
 .El
 .Pp
+The RTL8188EUS chip can also operate in Host AP mode.
+.Pp
 The
 .Nm
 driver can be configured to use
@@ -180,3 +182,8 @@ adapters.
 Additional work is required in
 .Xr ieee80211 9
 before those features can be supported.
+.Pp
+Beacon transmission, when operating in Host AP mode, is not started
+immidiatelly, but with timeout of around 40 seconds, it means that if you
+associate within this time frame, your client card will eventually disconnect
+you, assuming that you've left range of AP.
diff --git sys/dev/usb/if_urtwn.c sys/dev/usb/if_urtwn.c
index db47398..18a4200 100644
--- sys/dev/usb/if_urtwn.c
+++ sys/dev/usb/if_urtwn.c
@@ -216,6 +216,7 @@ voidurtwn_rxeof(struct usbd_xfer *, void *,
usbd_status);
 void   urtwn_txeof(struct usbd_xfer *, void *,
usbd_status);
+inturtwn_txbcn(struct urtwn_softc *, struct ieee80211_node *);
 inturtwn_tx(struct urtwn_softc *, struct mbuf *,
struct ieee80211_node *);
 void   urtwn_start(struct ifnet *);
@@ -347,6 +348,11 @@ urtwn_attach(struct device *parent, struct device *self, 
void *aux)
IEEE80211_C_WEP |   /* WEP. */
IEEE80211_C_RSN;/* WPA/RSN. */
 
+#ifndef IEEE80211_STA_ONLY
+   if (sc-chip  URTWN_CHIP_88E)
+   ic-ic_caps |= IEEE80211_C_HOSTAP; /* HostAp mode supported */
+#endif
+
 #ifndef IEEE80211_NO_HT
/* Set HT capabilities. */
ic-ic_htcaps =
@@ -1319,7 +1325,7 @@ urtwn_newstate_cb(struct urtwn_softc *sc, void *arg)
struct ieee80211_node *ni;
enum ieee80211_state ostate;
uint32_t reg;
-   int s;
+   int s, error;
 
s = splnet();
ostate = ic-ic_state;
@@ -1422,22 +1428,62 @@ urtwn_newstate_cb(struct urtwn_softc *sc, void *arg)
}
ni = ic-ic_bss;
 
-   /* Set media status to 'Associated'. */
-   reg = urtwn_read_4(sc, R92C_CR);
-   reg = RW(reg, R92C_CR_NETTYPE, R92C_CR_NETTYPE_INFRA);
-   urtwn_write_4(sc, R92C_CR, reg);
+   if (ic-ic_opmode == IEEE80211_M_STA) {
+   /* Set BSSID. */
+   urtwn_write_4(sc, R92C_BSSID + 0, 
LE_READ_4(ni-ni_bssid[0]));
+   urtwn_write_4(sc, R92C_BSSID + 4, 
LE_READ_2(ni-ni_bssid[4]));
 
-   /* Set BSSID. */
-   urtwn_write_4(sc, R92C_BSSID + 0, LE_READ_4(ni-ni_bssid[0]));
-   urtwn_write_4(sc, R92C_BSSID + 4, LE_READ_2(ni-ni_bssid[4]));
+   if (ic-ic_curmode == IEEE80211_MODE_11B)
+   urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 0);
+   else/* 802.11b/g */
+   urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 3);
 
-   if (ic-ic_curmode == IEEE80211_MODE_11B)
-   urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 0);
-   else/* 802.11b/g */
-   urtwn_write_1(sc, R92C_INIRTS_RATE_SEL, 3);
+   /* Enable Rx of data frames. */
+   urtwn_write_2(sc, R92C_RXFLTMAP2, 0x);
 
-   /* Enable Rx of data frames. */
-   urtwn_write_2(sc, R92C_RXFLTMAP2, 0x);
+   /* Allow Rx from our BSSID only. */
+   urtwn_write_4(sc, R92C_RCR, urtwn_read_4(sc, R92C_RCR) |
+   R92C_RCR_CBSSID_DATA | R92C_RCR_CBSSID_BCN);
+
+   /* Set media status to 

[patch] urtwn(4) 8188eu additions

[Mikhail]

Hello, inlined patch is a compilation of fixes which were pushed into
FreeBSD tree after 8188eu driver came in.

It adds four new usbdevs (r270191, r273589, r282120), fixes efuse length
and replaces magic numbers with proper defines (r281918), fixes efuse
access (r281592, r282623), and fixes man typo.

All revisions can be viewed by this url pattern:

https://svnweb.freebsd.org/base?view=revisionrevision=revision

Efuse changes from those revisions are overlapping, patch incorporates
final version.
Index: share/man/man4/urtwn.4
===
RCS file: /cvs/src/share/man/man4/urtwn.4,v
retrieving revision 1.33
diff -u -p -r1.33 urtwn.4
--- share/man/man4/urtwn.4  4 May 2015 14:30:06 -   1.33
+++ share/man/man4/urtwn.4  11 May 2015 12:20:23 -
@@ -28,7 +28,7 @@ The
 driver supports USB 2.0 wireless network devices based on Realtek
 RTL8188CUS, RTL8188CE-VAU, RTL8188EUS, RTL8188RU and RTL8192CU chipsets.
 .Pp
-The RTL8188CUS and RTL8188EUS are a highly integrated 802.11n adapter
+The RTL8188CUS and RTL8188EUS are a highly integrated 802.11n adapters
 that combines a MAC, a 1T1R capable baseband and an RF in a single chip.
 It operates in the 2GHz spectrum only.
 The RTL8188RU is a high-power variant of the RTL8188CUS.
@@ -98,11 +98,14 @@ The following adapters should work:
 .It B-Link BL-LW05-5R
 .It Belkin F7D1102 Surf Wireless Micro
 .It D-Link DWA-121
+.It D-Link DWA-123 rev D1
+.It D-Link DWA-125 rev D1
 .It D-Link DWA-131 rev B
 .It D-Link DWA-133
 .It D-Link DWA-135
 .It Digitus DN-7042
 .It Edimax EW-7811Un
+.It Elecom WDC-150SU2M
 .It EDUP EP-N8508
 .It Full River FR-W100NUL
 .It Hercules Wireless N USB Pico HWNUp-150
Index: sys/dev/usb/if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.46
diff -u -p -r1.46 if_urtwn.c
--- sys/dev/usb/if_urtwn.c  10 May 2015 19:40:56 -  1.46
+++ sys/dev/usb/if_urtwn.c  11 May 2015 12:20:23 -
@@ -126,6 +126,7 @@ static const struct usb_devno urtwn_devs
{ USB_VENDOR_REALTEK,   USB_PRODUCT_REALTEK_RTL8188CU_0 },
{ USB_VENDOR_REALTEK,   USB_PRODUCT_REALTEK_RTL8188CU_1 },
{ USB_VENDOR_REALTEK,   USB_PRODUCT_REALTEK_RTL8188CU_2 },
+   { USB_VENDOR_REALTEK,   USB_PRODUCT_REALTEK_RTL8188CU_3 },
{ USB_VENDOR_REALTEK,   USB_PRODUCT_REALTEK_RTL8188CU_COMBO },
{ USB_VENDOR_REALTEK,   USB_PRODUCT_REALTEK_RTL8188CUS },
{ USB_VENDOR_REALTEK,   USB_PRODUCT_REALTEK_RTL8188RU },
@@ -143,6 +144,9 @@ static const struct usb_devno urtwn_devs
{ USB_VENDOR_TRENDNET,  USB_PRODUCT_TRENDNET_RTL8192CU },
{ USB_VENDOR_ZYXEL, USB_PRODUCT_ZYXEL_RTL8192CU },
/* URTWN_RTL8188E */
+   { USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DWA123D1 },
+   { USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DWA125D1 },
+   { USB_VENDOR_ELECOM,USB_PRODUCT_ELECOM_WDC150SU2M },
{ USB_VENDOR_REALTEK,   USB_PRODUCT_REALTEK_RTL8188ETV },
{ USB_VENDOR_REALTEK,   USB_PRODUCT_REALTEK_RTL8188EU }
 };
@@ -305,7 +309,10 @@ urtwn_attach(struct device *parent, stru
return;
}
 
-   if (uaa-product == USB_PRODUCT_REALTEK_RTL8188EU ||
+   if (uaa-product == USB_PRODUCT_DLINK_DWA123D1 ||
+   uaa-product == USB_PRODUCT_DLINK_DWA125D1 ||
+   uaa-product == USB_PRODUCT_ELECOM_WDC150SU2M ||
+   uaa-product == USB_PRODUCT_REALTEK_RTL8188EU ||
uaa-product == USB_PRODUCT_REALTEK_RTL8188ETV)
sc-chip |= URTWN_CHIP_88E;
 
@@ -922,6 +929,8 @@ urtwn_efuse_read(struct urtwn_softc *sc)
printf(\n);
}
 #endif
+
+   urtwn_write_1(sc, R92C_EFUSE_ACCESS, R92C_EFUSE_ACCESS_OFF);
 }
 
 void
@@ -929,6 +938,8 @@ urtwn_efuse_switch_power(struct urtwn_so
 {
uint32_t reg;
 
+   urtwn_write_1(sc, R92C_EFUSE_ACCESS, R92C_EFUSE_ACCESS_ON);
+
reg = urtwn_read_2(sc, R92C_SYS_ISO_CTRL);
if (!(reg  R92C_SYS_ISO_CTRL_PWC_EV12V)) {
urtwn_write_2(sc, R92C_SYS_ISO_CTRL,
@@ -1014,7 +1025,7 @@ urtwn_r88e_read_rom(struct urtwn_softc *
 
/* Read full ROM image. */
memset(sc-r88e_rom, 0xff, sizeof(sc-r88e_rom));
-   while (addr  1024) {
+   while (addr  512) {
reg = urtwn_efuse_read_1(sc, addr);
if (reg == 0xff)
break;
@@ -1040,6 +1051,8 @@ urtwn_r88e_read_rom(struct urtwn_softc *
}
}
 
+   urtwn_write_1(sc, R92C_EFUSE_ACCESS, R92C_EFUSE_ACCESS_OFF);
+
addr = 0x10;
for (i = 0; i  6; i++)
sc-cck_tx_pwr[i] = sc-r88e_rom[addr++];
@@ -1178,7 +1191,7 @@ urtwn_r88e_ra_init(struct urtwn_softc *s
reg = RW(reg, R92C_RRSR_RATE_BITMAP, rates);
urtwn_write_4(sc, R92C_RRSR, reg);
 
-   /* 
+   /*
 * Workaround for performance problems with firmware rate adaptation:
 * If 

Re: [patch] rtl8188eu support for urtwn(4)

[Mikhail]

On 20:20 26-Apr 2015 Stefan Sperling wrote:
 The chunk below is wrong for OpenBSD since it sets the intitial transmit
 rate to an 11n rate. 0x13 corresponds to the MCS7 11n rate,
 see linux/drivers/net/wireless/rtlwifi/rtl8188ee/def.h enum rtl_desc92c_rate.
 The value 11 corresponds to OFDM 54Mbit which is fine for OpenBSD.
 We only support 11a/b/g at present.
 
 --- sys/dev/usb/if_urtwn.c14 Mar 2015 03:38:49 -  1.43
 +++ sys/dev/usb/if_urtwn.c19 Apr 2015 20:27:41 -
 @@ -1813,7 +2011,10 @@ urtwn_tx(struct urtwn_softc *sc, struct 
   txd-txdw4 |= htole32(SM(R92C_TXDW4_RTSRATE, 8));
   txd-txdw5 |= htole32(0x0001ff00);
   /* Send data at OFDM54. */
 - txd-txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11));
 + if (sc-chip  URTWN_CHIP_88E)
 + txd-txdw5 |= htole32(0x13  0x3f);
 + else
 + txd-txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11));
  
   } else {
   txd-txdw1 |= htole32(

Hello, yes, this change, maybe harmless, but not accurate. I inline new
patch against head with this change incorporated and with fix for USB
aggregation mode, which Kevin has pushed into FreeBSD[1] to fix
performance issues.

[1] - https://svnweb.freebsd.org/base?view=revisionrevision=282266

Index: share/man/man4/urtwn.4
===
RCS file: /cvs/src/share/man/man4/urtwn.4,v
retrieving revision 1.31
diff -u -p -r1.31 urtwn.4
--- share/man/man4/urtwn.4  30 Mar 2015 12:35:15 -  1.31
+++ share/man/man4/urtwn.4  4 May 2015 10:09:59 -
@@ -19,17 +19,17 @@
 .Os
 .Sh NAME
 .Nm urtwn
-.Nd Realtek RTL8188CU/RTL8192CU USB IEEE 802.11b/g/n wireless network device
+.Nd Realtek RTL8188CU/RTL8188EU/RTL8192CU USB IEEE 802.11b/g/n wireless 
network device
 .Sh SYNOPSIS
 .Cd urtwn* at uhub? port ?
 .Sh DESCRIPTION
 The
 .Nm
 driver supports USB 2.0 wireless network devices based on Realtek
-RTL8188CUS, RTL8188CE-VAU, RTL8188RU and RTL8192CU chipsets.
+RTL8188CUS, RTL8188CE-VAU, RTL8188EUS, RTL8188RU and RTL8192CU chipsets.
 .Pp
-The RTL8188CUS is a highly integrated 802.11n adapter that combines
-a MAC, a 1T1R capable baseband and an RF in a single chip.
+The RTL8188CUS and RTL8188EUS are a highly integrated 802.11n adapter
+that combines a MAC, a 1T1R capable baseband and an RF in a single chip.
 It operates in the 2GHz spectrum only.
 The RTL8188RU is a high-power variant of the RTL8188CUS.
 The RTL8188CE-VAU is a PCI Express Mini Card adapter that attaches
@@ -83,6 +83,7 @@ which are loaded when an interface is at
 .It /etc/firmware/urtwn-rtl8192cfwT
 .It /etc/firmware/urtwn-rtl8192cfwU
 .It /etc/firmware/urtwn-rtl8723fw
+.It /etc/firmware/urtwn-rtl8188eufw
 .El
 .Pp
 A prepackaged version of the firmware can be installed using
@@ -119,6 +120,8 @@ The following adapters should work:
 .It Solwise NET-WL-UMD-606N
 .It TP-Link TL-WN821N v4
 .It TRENDnet TEW-648UBM
+.It TP-LINK TL-WN723N v3
+.It TP-LINK TL-WN725N v2
 .El
 .Sh EXAMPLES
 The following example scans for available networks:
Index: sys/dev/usb/if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.43
diff -u -p -r1.43 if_urtwn.c
--- sys/dev/usb/if_urtwn.c  14 Mar 2015 03:38:49 -  1.43
+++ sys/dev/usb/if_urtwn.c  4 May 2015 10:10:00 -
@@ -2,6 +2,7 @@
 
 /*-
  * Copyright (c) 2010 Damien Bergamini damien.bergam...@free.fr
+ * Copyright (c) 2014 Kevin Lo ke...@freebsd.org
  *
  * Permission to use, copy, modify, and distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -17,7 +18,7 @@
  */
 
 /*
- * Driver for Realtek RTL8188CE-VAU/RTL8188CUS/RTL8188RU/RTL8192CU.
+ * Driver for Realtek RTL8188CE-VAU/RTL8188CUS/RTL8188EU/RTL8188RU/RTL8192CU.
  */
 
 #include bpfilter.h
@@ -140,7 +141,10 @@ static const struct usb_devno urtwn_devs
{ USB_VENDOR_TPLINK,USB_PRODUCT_TPLINK_RTL8192CU },
{ USB_VENDOR_TRENDNET,  USB_PRODUCT_TRENDNET_RTL8188CU },
{ USB_VENDOR_TRENDNET,  USB_PRODUCT_TRENDNET_RTL8192CU },
-   { USB_VENDOR_ZYXEL, USB_PRODUCT_ZYXEL_RTL8192CU }
+   { USB_VENDOR_ZYXEL, USB_PRODUCT_ZYXEL_RTL8192CU },
+   /* URTWN_RTL8188E */
+   { USB_VENDOR_REALTEK,   USB_PRODUCT_REALTEK_RTL8188ETV },
+   { USB_VENDOR_REALTEK,   USB_PRODUCT_REALTEK_RTL8188EU }
 };
 
 inturtwn_match(struct device *, void *, void *);
@@ -167,14 +171,17 @@ uint8_t   urtwn_read_1(struct urtwn_softc
 uint16_t   urtwn_read_2(struct urtwn_softc *, uint16_t);
 uint32_t   urtwn_read_4(struct urtwn_softc *, uint16_t);
 inturtwn_fw_cmd(struct urtwn_softc *, uint8_t, const void *, int);
-void   urtwn_rf_write(struct urtwn_softc *, int, uint8_t, uint32_t);
+void   urtwn_r92c_rf_write(struct urtwn_softc *, int, uint8_t, 
uint32_t);
+void   

Re: [patch] rtl8188eu support for urtwn(4)

[Mikhail]

On 23:25 26-Apr 2015 patrick keshishian wrote:
 On 4/26/15, Mikhail mp39...@gmail.com wrote:
 
  urtwn_write_1(sc, R92C_USB_SPECIAL_OPTION,
  urtwn_read_1(sc, R92C_USB_SPECIAL_OPTION) |
  -   R92C_USB_SPECIAL_OPTION_AGG_EN);
  +   (sc-chip  URTWN_CHIP_88E ?
  +   ~R92C_USB_SPECIAL_OPTION_AGG_EN :
 
 umm... maybe 0, as it is being ORed with what read returns.
 But maybe the check should be against URTWN_CHIP_92C since
 the option is specific to it (or at least implied to be so).

It's what original driver does:

https://github.com/lwfinger/rtl8188eu/blob/master/hal/usb_halinit.c#L520

Re: [patch] rtl8188eu support for urtwn(4)

[Mikhail]

On 20:20 26-Apr 2015 Stefan Sperling wrote:
 On Sun, Apr 26, 2015 at 01:31:17PM +0200, Stefan Sperling wrote:
  On Sun, Apr 19, 2015 at 11:48:32PM +0300, Mikhail wrote:
   Bellow new version of the patch with above things fixed, also I've fixed
   detection of ETV chip in urtwn_attach(), nothing else is changed.
  
  I'm seeing very low data transmission rates with your patch and a
  TP-Link TL-WN725N device. In both 11b and 11g mode, the data rate
  remains very low (less than 100Kbit/s). A different urtwn(4) device
  (with 8188CUS chip) has much better throughput.
  
  Are you seeing this, too?
 
 The chunk below is wrong for OpenBSD since it sets the intitial transmit
 rate to an 11n rate. 0x13 corresponds to the MCS7 11n rate,
 see linux/drivers/net/wireless/rtlwifi/rtl8188ee/def.h enum rtl_desc92c_rate.
 The value 11 corresponds to OFDM 54Mbit which is fine for OpenBSD.
 We only support 11a/b/g at present.
 
 --- sys/dev/usb/if_urtwn.c14 Mar 2015 03:38:49 -  1.43
 +++ sys/dev/usb/if_urtwn.c19 Apr 2015 20:27:41 -
 @@ -1813,7 +2011,10 @@ urtwn_tx(struct urtwn_softc *sc, struct 
   txd-txdw4 |= htole32(SM(R92C_TXDW4_RTSRATE, 8));
   txd-txdw5 |= htole32(0x0001ff00);
   /* Send data at OFDM54. */
 - txd-txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11));
 + if (sc-chip  URTWN_CHIP_88E)
 + txd-txdw5 |= htole32(0x13  0x3f);
 + else
 + txd-txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11));
  
   } else {
   txd-txdw1 |= htole32(
 
 Reverting this change doesn't fix the transmit speed problem, unfortunately.
 
 I wonder if we're making some mistake while setting up the TX descriptor?
 There are several differences in the TX descriptors of 88E vs 92C.
 For example, 88E has third antenna C available.

Hello, in urtwn_init(), in part:

if (sc-chip  URTWN_CHIP_88E)
urtwn_write_1(sc, R92C_RXDMA_AGG_PG_TH + 1, 4);
else
urtwn_write_1(sc, R92C_USB_DMA_AGG_TO, 4);

comment first 3 lines. It fixes speed problem for me, but I need to
understand the issue further, before proposing any solution.

Re: [patch] rtl8188eu support for urtwn(4)

[Mikhail]

On 21:22 26-Apr 2015 Mikhail wrote:
 On 20:20 26-Apr 2015 Stefan Sperling wrote:
  On Sun, Apr 26, 2015 at 01:31:17PM +0200, Stefan Sperling wrote:
   On Sun, Apr 19, 2015 at 11:48:32PM +0300, Mikhail wrote:
Bellow new version of the patch with above things fixed, also I've fixed
detection of ETV chip in urtwn_attach(), nothing else is changed.
   
   I'm seeing very low data transmission rates with your patch and a
   TP-Link TL-WN725N device. In both 11b and 11g mode, the data rate
   remains very low (less than 100Kbit/s). A different urtwn(4) device
   (with 8188CUS chip) has much better throughput.
   
   Are you seeing this, too?
  
  The chunk below is wrong for OpenBSD since it sets the intitial transmit
  rate to an 11n rate. 0x13 corresponds to the MCS7 11n rate,
  see linux/drivers/net/wireless/rtlwifi/rtl8188ee/def.h enum 
  rtl_desc92c_rate.
  The value 11 corresponds to OFDM 54Mbit which is fine for OpenBSD.
  We only support 11a/b/g at present.
  
  --- sys/dev/usb/if_urtwn.c  14 Mar 2015 03:38:49 -  1.43
  +++ sys/dev/usb/if_urtwn.c  19 Apr 2015 20:27:41 -
  @@ -1813,7 +2011,10 @@ urtwn_tx(struct urtwn_softc *sc, struct 
  txd-txdw4 |= htole32(SM(R92C_TXDW4_RTSRATE, 8));
  txd-txdw5 |= htole32(0x0001ff00);
  /* Send data at OFDM54. */
  -   txd-txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11));
  +   if (sc-chip  URTWN_CHIP_88E)
  +   txd-txdw5 |= htole32(0x13  0x3f);
  +   else
  +   txd-txdw5 |= htole32(SM(R92C_TXDW5_DATARATE, 11));
   
  } else {
  txd-txdw1 |= htole32(
  
  Reverting this change doesn't fix the transmit speed problem, unfortunately.
  
  I wonder if we're making some mistake while setting up the TX descriptor?
  There are several differences in the TX descriptors of 88E vs 92C.
  For example, 88E has third antenna C available.
 
 Hello, in urtwn_init(), in part:
 
 if (sc-chip  URTWN_CHIP_88E)
 urtwn_write_1(sc, R92C_RXDMA_AGG_PG_TH + 1, 4);
 else
 urtwn_write_1(sc, R92C_USB_DMA_AGG_TO, 4);
 
 comment first 3 lines. It fixes speed problem for me, but I need to
 understand the issue further, before proposing any solution.

The issue isn't in those lines, but a little bit higher - the driver
enables usb and dma aggregations, but native linux implementation
enables only dma and disables usb one.

I've submitted bug report to FreeBSD[1] with a patch, which I see as a
proper solution:

urtwn_write_1(sc, R92C_USB_SPECIAL_OPTION,
urtwn_read_1(sc, R92C_USB_SPECIAL_OPTION) |
-   R92C_USB_SPECIAL_OPTION_AGG_EN);
+   (sc-chip  URTWN_CHIP_88E ?
+   ~R92C_USB_SPECIAL_OPTION_AGG_EN :
+R92C_USB_SPECIAL_OPTION_AGG_EN));

I'd suggest to wait some time for feedback. Testing is welcome, of
course. Thank you for pointing this out and review in general.

[1] - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199718

[patch] acpithinkpad(4) unknown event 0x6000

[Mikhail]

Hello, when I switch numlock on thinkpad e530 I see aforesaid message on
console log.

Can someone review inlined patch?

Index: sys/dev/acpi/acpithinkpad.c
===
RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
retrieving revision 1.43
diff -u -p -r1.43 acpithinkpad.c
--- sys/dev/acpi/acpithinkpad.c 6 Feb 2015 08:16:49 -   1.43
+++ sys/dev/acpi/acpithinkpad.c 24 Apr 2015 10:57:25 -
@@ -90,6 +90,7 @@
 #defineTHINKPAD_BRIGHTNESS_CHANGED 0x5010
 #defineTHINKPAD_TABLET_PEN_INSERTED0x500b
 #defineTHINKPAD_TABLET_PEN_REMOVED 0x500c
+#defineTHINKPAD_SWITCH_NUMLOCK 0x6000
 #defineTHINKPAD_THERMAL_TABLE_CHANGED  0x6030
 #defineTHINKPAD_POWER_CHANGED  0x6040
 #defineTHINKPAD_BACKLIGHT_CHANGED  0x6050
@@ -393,6 +394,7 @@ thinkpad_hotkey(struct aml_node *node, i
case THINKPAD_SWITCH_WIRELESS:
case THINKPAD_TABLET_PEN_INSERTED:
case THINKPAD_TABLET_PEN_REMOVED:
+   case THINKPAD_SWITCH_NUMLOCK:
case THINKPAD_TABLET_SCREEN_NORMAL:
case THINKPAD_TABLET_SCREEN_ROTATED:
case THINKPAD_TABLET_SCREEN_CHANGED:

[patch] rtl8188eu support for urtwn(4)

[Mikhail]

Hello, I inline the patch for rtl8188eu chip support in urtwn driver,
origins for this patch are in r264912[1] from FreeBSD. In order to work,
correct firmware must be presented in /etc/firmware - one can be found
in FreeBSD commit itself[2] - I'm not sure what is the correct procedure
of submitting it to firmware.openbsd.org.

I've tested it with TP-LINK TL-WN725N with usual network activity.

[1] - http://svnweb.freebsd.org/base?view=revisionrevision=264912
[2] - 
http://svnweb.freebsd.org/base/head/sys/contrib/dev/urtwn/urtwn-rtl8188eufw.fw.uu?view=markuppathrev=264912

Index: share/man/man4/urtwn.4
===
RCS file: /cvs/src/share/man/man4/urtwn.4,v
retrieving revision 1.31
diff -u -p -u -r1.31 urtwn.4
--- share/man/man4/urtwn.4  30 Mar 2015 12:35:15 -  1.31
+++ share/man/man4/urtwn.4  18 Apr 2015 19:44:00 -
@@ -14,22 +14,22 @@
 .\ ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 .\ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 .\
-.Dd $Mdocdate: March 30 2015 $
+.Dd $Mdocdate: April 19 2015 $
 .Dt URTWN 4
 .Os
 .Sh NAME
 .Nm urtwn
-.Nd Realtek RTL8188CU/RTL8192CU USB IEEE 802.11b/g/n wireless network device
+.Nd Realtek RTL8188CU/RTL8188EU/RTL8192CU USB IEEE 802.11b/g/n wireless 
network device
 .Sh SYNOPSIS
 .Cd urtwn* at uhub? port ?
 .Sh DESCRIPTION
 The
 .Nm
 driver supports USB 2.0 wireless network devices based on Realtek
-RTL8188CUS, RTL8188CE-VAU, RTL8188RU and RTL8192CU chipsets.
+RTL8188CUS, RTL8188CE-VAU, RTL8188EUS, RTL8188RU and RTL8192CU chipsets.
 .Pp
-The RTL8188CUS is a highly integrated 802.11n adapter that combines
-a MAC, a 1T1R capable baseband and an RF in a single chip.
+The RTL8188CUS and RTL8188EUS is a highly integrated 802.11n adapter
+that combines a MAC, a 1T1R capable baseband and an RF in a single chip.
 It operates in the 2GHz spectrum only.
 The RTL8188RU is a high-power variant of the RTL8188CUS.
 The RTL8188CE-VAU is a PCI Express Mini Card adapter that attaches
@@ -83,6 +83,7 @@ which are loaded when an interface is at
 .It /etc/firmware/urtwn-rtl8192cfwT
 .It /etc/firmware/urtwn-rtl8192cfwU
 .It /etc/firmware/urtwn-rtl8723fw
+.It /etc/firmware/urtwn-rtl8188eufw
 .El
 .Pp
 A prepackaged version of the firmware can be installed using
@@ -119,6 +120,8 @@ The following adapters should work:
 .It Solwise NET-WL-UMD-606N
 .It TP-Link TL-WN821N v4
 .It TRENDnet TEW-648UBM
+.It TP-LINK TL-WN723N v3
+.It TP-LINK TL-WN725N v2
 .El
 .Sh EXAMPLES
 The following example scans for available networks:
Index: sys/dev/usb/if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.43
diff -u -p -u -r1.43 if_urtwn.c
--- sys/dev/usb/if_urtwn.c  14 Mar 2015 03:38:49 -  1.43
+++ sys/dev/usb/if_urtwn.c  18 Apr 2015 19:44:00 -
@@ -2,6 +2,7 @@
 
 /*-
  * Copyright (c) 2010 Damien Bergamini damien.bergam...@free.fr
+ * Copyright (c) 2014 Kevin Lo ke...@freebsd.org
  *
  * Permission to use, copy, modify, and distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -17,7 +18,7 @@
  */
 
 /*
- * Driver for Realtek RTL8188CE-VAU/RTL8188CUS/RTL8188RU/RTL8192CU.
+ * Driver for Realtek RTL8188CE-VAU/RTL8188CUS/RTL8188EU/RTL8188RU/RTL8192CU.
  */
 
 #include bpfilter.h
@@ -140,7 +141,10 @@ static const struct usb_devno urtwn_devs
{ USB_VENDOR_TPLINK,USB_PRODUCT_TPLINK_RTL8192CU },
{ USB_VENDOR_TRENDNET,  USB_PRODUCT_TRENDNET_RTL8188CU },
{ USB_VENDOR_TRENDNET,  USB_PRODUCT_TRENDNET_RTL8192CU },
-   { USB_VENDOR_ZYXEL, USB_PRODUCT_ZYXEL_RTL8192CU }
+   { USB_VENDOR_ZYXEL, USB_PRODUCT_ZYXEL_RTL8192CU },
+   /* URTWN_RTL8188E */
+   { USB_VENDOR_REALTEK,   USB_PRODUCT_REALTEK_RTL8188ETV },
+   { USB_VENDOR_REALTEK,   USB_PRODUCT_REALTEK_RTL8188EU }
 };
 
 inturtwn_match(struct device *, void *, void *);
@@ -167,14 +171,17 @@ uint8_t   urtwn_read_1(struct urtwn_softc
 uint16_t   urtwn_read_2(struct urtwn_softc *, uint16_t);
 uint32_t   urtwn_read_4(struct urtwn_softc *, uint16_t);
 inturtwn_fw_cmd(struct urtwn_softc *, uint8_t, const void *, int);
-void   urtwn_rf_write(struct urtwn_softc *, int, uint8_t, uint32_t);
+void   urtwn_r92c_rf_write(struct urtwn_softc *, int, uint8_t, 
uint32_t);
+void   urtwn_r88e_rf_write(struct urtwn_softc *, int, uint8_t, 
uint32_t);
 uint32_t   urtwn_rf_read(struct urtwn_softc *, int, uint8_t);
 void   urtwn_cam_write(struct urtwn_softc *, uint32_t, uint32_t);
 inturtwn_llt_write(struct urtwn_softc *, uint32_t, uint32_t);
 uint8_turtwn_efuse_read_1(struct urtwn_softc *, uint16_t);
 void   urtwn_efuse_read(struct urtwn_softc *);
+void   urtwn_efuse_switch_power(struct urtwn_softc *);
 int