[wireless] iwx: small code nitpicking and removal of iwx_wait_tx_queues_empty
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->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(&sc->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->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->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 = &sc->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->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 -
Re: any work on port of rtw89? (realtek 8852 AE/BE/CE)
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)
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
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
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
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
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: 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,SS
Re: [installer] default answer to "Is the disk partition already mounted?"
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?"
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?"
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
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 = &argv[i]; if (execvp(progname, progargs) == -1) err(1, "execvp: %s", progname); return (0); }
Re: iwx(4) -77 firmware diff for testing
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
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&m=162737223625768&w=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
/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
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
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
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
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
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&m=166600434429788&w=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->sc_dev, &aaa, 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
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->sc_tables, q_next) { 1210 struct acpi_attach_args aaa; 1211 1212 memset(&aaa, 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->sc_dev, &aaa, 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
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,
Re: [acpi] patch for embedded controller detection
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,P
Re: [acpi] patch for embedded controller detection
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
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, &st)) 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)) - st = STA_PRESENT | STA_ENABLED | STA_DEV_OK; + aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "_STA", 0, NULL, &st); 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
Re: [patch] 802.11 printing akm and cipher suite lists in tcpdump
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
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
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
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
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
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
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
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
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
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
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: versio
Re: [patch] urndis: uncomment watchdog
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
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
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
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
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
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(&sqtd->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(&lsqtd->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 dev
[patch] urndis: uncomment watchdog
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
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(&sqtd->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(&lsqtd->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__);
Re: urndis0: IOERROR
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: ehci
Re: urndis0: IOERROR
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
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 &buf, &bufsz) != 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
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 &buf, &bufsz) != 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 0
urndis0: IOERROR
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
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
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
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
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 10
Re: [patch] man page improvement for sem* family of functions
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
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
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
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
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
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
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
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(&c->conf_file, "%s/%s", home, ".cwmrc"); > - xasprintf(&c->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
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(&file, "%s/openssl.cnf", X509_get_default_cert_area()) == -1) +#else + if (asprintf(&file, 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(&p, "%s/openssl.cnf", t) == -1) +#else + if (asprintf(&p, 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(&file, "%s/openssl.cnf", X509_get_default_cert_area()) == -1) +#else + if (asprintf(&file, 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(&p, "%s/openssl.cnf", t) == -1) +#else + if (asprintf(&p, X509_CONF_FILE) == -1) +#endif return NULL; return p; } -- 2.20.1
Fwd: new usb id for urtwn
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
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
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
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
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
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
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
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
On Fri, Oct 27, 2017 at 1:19 PM, Jeremie Courreges-Anglas wrote: > On Fri, Oct 27 2017, Mikhail 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
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, &buf, &bufsz) != 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
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)
On Sun, Sep 18, 2016 at 12:11 AM, Theo de Raadt 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)
> 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
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
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 sta
[patch] urtwn(4) 8188eu additions
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=revision&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:
Re: [patch] rtl8188eu support for urtwn(4)
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=revision&revision=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 + * Copyright (c) 2014 Kevin Lo * * 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
Re: [patch] rtl8188eu support for urtwn(4)
On 23:25 26-Apr 2015 patrick keshishian wrote: > On 4/26/15, Mikhail 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)
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
Re: [patch] rtl8188eu support for urtwn(4)
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.
[patch] acpithinkpad(4) unknown event 0x6000
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:
Re: [patch] rtl8188eu support for urtwn(4)
On 22:20 19-Apr 2015 Stuart Henderson wrote: > On 2015/04/19 11:27, Mikhail wrote: > > -.Dd $Mdocdate: March 30 2015 $ > > +.Dd $Mdocdate: April 19 2015 $ > > No need to change this, it happens at commit. > > > -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. > > This is now plural - "The ... are highly integrated .. adapters .." Thank you and Stefan for taking time for review. > > +.It /etc/firmware/urtwn-rtl8188eufw > > I can take care of the firmware package, can you confirm if this is correct? > > SHA256 (urtwn-rtl8188eufw) = > 1241ddbfc87f0495e0bf09d8b94c94680b60a3d8eeab89462b3c4d8d3e8a1ee0 Yes, that's correct. 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. 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 19 Apr 2015 20:27:41 - @@ -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 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. 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 19 Apr 2015 20:27:41 - @@ -2,6 +2,7 @@ /*- * Copyright (c) 2010 Damien Bergamini + * Copyright (c) 2014 Kevin Lo * * 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
[patch] rtl8188eu support for urtwn(4)
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=revision&revision=264912 [2] - http://svnweb.freebsd.org/base/head/sys/contrib/dev/urtwn/urtwn-rtl8188eufw.fw.uu?view=markup&pathrev=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 + * Copyright (c) 2014 Kevin Lo * * 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 *); inturtwn_read_chipid(struct urtwn_softc *); void