Re: Please test: UVM fault unlocking (aka vmobjlock)
Hi, I've tested the second diff (containing the bug fix and I get a lock order reversal on bootup. On the first patch I was getting the same lock order reversal while using X and sometimes (only sometimes) would crash X. witness: lock order reversal: 1st 0xfd83fef05248 uobjlk (>vmobjlock) 2nd 0x8119f700 objmm (>mm.lock) lock order ">mm.lock"(rwlock) -> ">vmobjlock"(rwlock) first seen at: #0 rw_enter+0x65 #1 uvm_obj_wire+0x46 #2 shmem_get_pages+0xaf #3 __i915_gem_object_get_pages+0x9d #4 i915_vma_pin_ww+0x49b #5 i915_ggtt_pin+0x61 #6 intel_execlists_submission_setup+0x3b2 #7 intel_engines_init+0x2ff #8 intel_gt_init+0x133 #9 i915_gem_init+0xa3 #10 i915_driver_probe+0x75a #11 inteldrm_attachhook+0x45 #12 config_process_deferred_mountroot+0x6b #13 main+0x743 lock order ">vmobjlock"(rwlock) -> ">mm.lock"(rwlock) first seen at: #0 rw_enter+0x65 #1 __i915_gem_object_get_pages+0x30 #2 i915_gem_fault+0x1aa #3 drm_fault+0x156 #4 uvm_fault+0x179 #5 upageflttrap+0x62 #6 usertrap+0x18b #7 recall_trap+0x8 Dmesg: OpenBSD 7.0-current (GENERIC.MP) #3: Thu Dec 2 18:38:43 GMT 2021 pertho@pertho.local:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17040445440 (16251MB) avail mem = 16376905728 (15618MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7b288000 (41 entries) bios0: vendor American Megatrends Inc. version "1.05.07" date 09/29/2017 bios0: PC Specialist LTD N13xWU acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT HPET UEFI SSDT SSDT SSDT DBGP DBG2 DMAR BGRT ASF! WSMT acpi0: wakeup devices RP17(S4) PXSX(S4) RP18(S4) PXSX(S4) RP19(S4) PXSX(S4) RP20(S4) PXSX(S4) RP21(S4) PXSX(S4) RP22(S4) PXSX(S4) RP23(S4) PXSX(S4) RP24(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.05 MHz, 06-8e-0a 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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.05 MHz, 06-8e-0a 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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.05 MHz, 06-8e-0a 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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.05 MHz, 06-8e-0a cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM)
Re: cwm: add group-last command [Was: Re: cwm: add last-group command]
Tom Murphy wrote:
> Hi,
>
> Here's an updated diff from Omar Polo's addition of group-last
> command to cwm. I've been using it without issues and it's
> really handy to be able to switch back to the previous
> workspace you were on with it.
>
> Many thanks to Omar Polo for doing all the original work. I've
> just updated the diff so it applies cleanly.
>
> OK?
>
> Tom
>
>
> Index: calmwm.h
> ===
> RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
> retrieving revision 1.375
> diff -u -p -r1.375 calmwm.h
> --- calmwm.h 16 Apr 2020 13:32:35 - 1.375
> +++ calmwm.h 10 Oct 2021 19:13:41 -
> @@ -214,6 +214,7 @@ struct screen_ctx {
> struct region_q regionq;
> struct group_q groupq;
> struct group_ctx*group_active;
> + int group_last;
> Colormap colormap;
> Visual *visual;
> struct {
> @@ -501,6 +502,7 @@ void
> kbfunc_client_toggle_group(void
> void kbfunc_client_movetogroup(void *, struct cargs *);
> void kbfunc_group_toggle(void *, struct cargs *);
> void kbfunc_group_only(void *, struct cargs *);
> +void kbfunc_group_last(void *, struct cargs *);
> void kbfunc_group_close(void *, struct cargs *);
> void kbfunc_group_cycle(void *, struct cargs *);
> void kbfunc_group_toggle_all(void *, struct cargs *);
> Index: conf.c
> ===
> RCS file: /cvs/xenocara/app/cwm/conf.c,v
> retrieving revision 1.252
> diff -u -p -r1.252 conf.c
> --- conf.c16 Apr 2020 13:32:35 - 1.252
> +++ conf.c10 Oct 2021 19:13:41 -
> @@ -139,6 +139,7 @@ static const struct {
>
> { FUNC_SC(group-cycle, group_cycle, (CWM_CYCLE_FORWARD)) },
> { FUNC_SC(group-rcycle, group_cycle, (CWM_CYCLE_REVERSE)) },
> + { FUNC_SC(group-last, group_last, 0) },
> { FUNC_SC(group-toggle-all, group_toggle_all, 0) },
> { FUNC_SC(group-toggle-1, group_toggle, 1) },
> { FUNC_SC(group-toggle-2, group_toggle, 2) },
> Index: cwmrc.5
> ===
> RCS file: /cvs/xenocara/app/cwm/cwmrc.5,v
> retrieving revision 1.76
> diff -u -p -r1.76 cwmrc.5
> --- cwmrc.5 16 Apr 2020 13:32:35 - 1.76
> +++ cwmrc.5 10 Oct 2021 19:13:41 -
> @@ -273,6 +273,8 @@ menu.
> Toggle visibility of group n, where n is 1-9.
> .It group-only-[n]
> Show only group n, where n is 1-9, hiding other groups.
> +.It group-last
> +Show only the last viewed group.
> .It group-close-[n]
> Close all windows in group n, where n is 1-9.
> .It group-toggle-all
> Index: group.c
> ===
> RCS file: /cvs/xenocara/app/cwm/group.c,v
> retrieving revision 1.137
> diff -u -p -r1.137 group.c
> --- group.c 27 Feb 2020 14:56:39 - 1.137
> +++ group.c 10 Oct 2021 19:13:41 -
> @@ -215,6 +215,9 @@ group_only(struct screen_ctx *sc, int id
> {
> struct group_ctx*gc;
>
> + if (sc->group_active->num != idx)
> + sc->group_last = sc->group_active->num;
> +
> TAILQ_FOREACH(gc, >groupq, entry) {
> if (gc->num == idx)
> group_show(gc);
> Index: kbfunc.c
> ===
> RCS file: /cvs/xenocara/app/cwm/kbfunc.c,v
> retrieving revision 1.170
> diff -u -p -r1.170 kbfunc.c
> --- kbfunc.c 20 Mar 2020 18:50:08 - 1.170
> +++ kbfunc.c 10 Oct 2021 19:13:41 -
> @@ -479,6 +479,14 @@ kbfunc_group_only(void *ctx, struct carg
> }
>
> void
> +kbfunc_group_last(void *ctx, struct cargs *cargs)
> +{
> + struct screen_ctx *sc = ctx;
> +
> + group_only(ctx, sc->group_last);
> +}
> +
> +void
> kbfunc_group_toggle(void *ctx, struct cargs *cargs)
> {
> group_toggle(ctx, cargs->flag);
> Index: screen.c
> ===
> RCS file: /cvs/xenocara/app/cwm/screen.c,v
> retrieving revision 1.97
> diff -u -p -r1.97 screen.c
> --- screen.c 24 Mar 2020 14:47:29 - 1.97
> +++ screen.c 10 Oct 2021 19:13:41 -
> @@ -53,6 +53,7 @@ screen_init(int which)
> sc->visual = DefaultVisual(X_Dpy, sc->which);
> sc->cycling = 0;
> sc->hideall = 0;
> + sc->group_last = 1;
>
> conf_scree
Re: cwm: add group-last command [Was: Re: cwm: add last-group command]
Hi,
Here's an updated diff from Omar Polo's addition of group-last
command to cwm. I've been using it without issues and it's
really handy to be able to switch back to the previous
workspace you were on with it.
Many thanks to Omar Polo for doing all the original work. I've
just updated the diff so it applies cleanly.
OK?
Tom
Index: calmwm.h
===
RCS file: /cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.375
diff -u -p -r1.375 calmwm.h
--- calmwm.h16 Apr 2020 13:32:35 - 1.375
+++ calmwm.h10 Oct 2021 19:13:41 -
@@ -214,6 +214,7 @@ struct screen_ctx {
struct region_q regionq;
struct group_q groupq;
struct group_ctx*group_active;
+ int group_last;
Colormap colormap;
Visual *visual;
struct {
@@ -501,6 +502,7 @@ void
kbfunc_client_toggle_group(void
voidkbfunc_client_movetogroup(void *, struct cargs *);
voidkbfunc_group_toggle(void *, struct cargs *);
voidkbfunc_group_only(void *, struct cargs *);
+voidkbfunc_group_last(void *, struct cargs *);
voidkbfunc_group_close(void *, struct cargs *);
voidkbfunc_group_cycle(void *, struct cargs *);
voidkbfunc_group_toggle_all(void *, struct cargs *);
Index: conf.c
===
RCS file: /cvs/xenocara/app/cwm/conf.c,v
retrieving revision 1.252
diff -u -p -r1.252 conf.c
--- conf.c 16 Apr 2020 13:32:35 - 1.252
+++ conf.c 10 Oct 2021 19:13:41 -
@@ -139,6 +139,7 @@ static const struct {
{ FUNC_SC(group-cycle, group_cycle, (CWM_CYCLE_FORWARD)) },
{ FUNC_SC(group-rcycle, group_cycle, (CWM_CYCLE_REVERSE)) },
+ { FUNC_SC(group-last, group_last, 0) },
{ FUNC_SC(group-toggle-all, group_toggle_all, 0) },
{ FUNC_SC(group-toggle-1, group_toggle, 1) },
{ FUNC_SC(group-toggle-2, group_toggle, 2) },
Index: cwmrc.5
===
RCS file: /cvs/xenocara/app/cwm/cwmrc.5,v
retrieving revision 1.76
diff -u -p -r1.76 cwmrc.5
--- cwmrc.5 16 Apr 2020 13:32:35 - 1.76
+++ cwmrc.5 10 Oct 2021 19:13:41 -
@@ -273,6 +273,8 @@ menu.
Toggle visibility of group n, where n is 1-9.
.It group-only-[n]
Show only group n, where n is 1-9, hiding other groups.
+.It group-last
+Show only the last viewed group.
.It group-close-[n]
Close all windows in group n, where n is 1-9.
.It group-toggle-all
Index: group.c
===
RCS file: /cvs/xenocara/app/cwm/group.c,v
retrieving revision 1.137
diff -u -p -r1.137 group.c
--- group.c 27 Feb 2020 14:56:39 - 1.137
+++ group.c 10 Oct 2021 19:13:41 -
@@ -215,6 +215,9 @@ group_only(struct screen_ctx *sc, int id
{
struct group_ctx*gc;
+ if (sc->group_active->num != idx)
+ sc->group_last = sc->group_active->num;
+
TAILQ_FOREACH(gc, >groupq, entry) {
if (gc->num == idx)
group_show(gc);
Index: kbfunc.c
===
RCS file: /cvs/xenocara/app/cwm/kbfunc.c,v
retrieving revision 1.170
diff -u -p -r1.170 kbfunc.c
--- kbfunc.c20 Mar 2020 18:50:08 - 1.170
+++ kbfunc.c10 Oct 2021 19:13:41 -
@@ -479,6 +479,14 @@ kbfunc_group_only(void *ctx, struct carg
}
void
+kbfunc_group_last(void *ctx, struct cargs *cargs)
+{
+ struct screen_ctx *sc = ctx;
+
+ group_only(ctx, sc->group_last);
+}
+
+void
kbfunc_group_toggle(void *ctx, struct cargs *cargs)
{
group_toggle(ctx, cargs->flag);
Index: screen.c
===
RCS file: /cvs/xenocara/app/cwm/screen.c,v
retrieving revision 1.97
diff -u -p -r1.97 screen.c
--- screen.c24 Mar 2020 14:47:29 - 1.97
+++ screen.c10 Oct 2021 19:13:41 -
@@ -53,6 +53,7 @@ screen_init(int which)
sc->visual = DefaultVisual(X_Dpy, sc->which);
sc->cycling = 0;
sc->hideall = 0;
+ sc->group_last = 1;
conf_screen(sc);
Add Gear Head keyboard usbdev
Hi,
I noticed the kernel was just printing out the generic hex device id
rather than the name of my keyboard so I did some checking and
there is a vendor id for "Gear Head" keyboards. These keyboards are
sometimes resold under different names like Octogen or Sanoxy, but
they are rebranded Gear Head keyboards.
Attached is a diff that identifies them as such. I got the usb id
info from http://www.linux-usb.org/usb.ids
Output of usbdevs -v for the aforementioned device on kernel
without patch:
addr 04: 0b38:0010 vendor 0x0b38, product 0x0010
low speed, power 100 mA, config 1, rev 1.02
driver: uhidev2
driver: uhidev3
Same output on kernel as per diff below:
addr 04: 0b38:0010 Gear Head, 107-Key Keyboard
low speed, power 100 mA, config 1, rev 1.02
driver: uhidev2
driver: uhidev3
Hope the naming scheme is OK, I can change it if needed.
Thanks,
Tom
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.719
diff -u -p -r1.719 usbdevs
--- sys/dev/usb/usbdevs 22 Jul 2020 11:12:40 - 1.719
+++ sys/dev/usb/usbdevs 3 Aug 2020 14:08:51 -
@@ -406,6 +406,7 @@ vendor NEODIO 0x0aec Neodio
vendor OPTION 0x0af0 Option
vendor ASUS0x0b05 ASUS
vendor TODOS 0x0b0c Todos Data System
+vendor GEARHEAD0x0b38 Gear Head
vendor OCT 0x0b39 Omnidirectional Control Technology
vendor TEKRAM 0x0b3b Tekram Technology
vendor HAL 0x0b41 HAL Corporation
@@ -2054,6 +2055,10 @@ product GARMIN GPSMAP62S 0x2459 GPSmap 6
/* GCT Semiconductor products */
product GCTSEMICON INSTALL 0x7f40 GDM720x MASS storage mode
+
+/* Gear Head products */
+product GEARHEAD GHKB 0x0003 Gear Head Keyboard
+product GEARHEAD GHKB107 0x0010 Gear Head 107-Key Keyboard
/* GEMPLUS products */
product GEMPLUS PROXPU 0x5501 Prox-PU/CU
Index: sys/dev/usb/usbdevs.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.731
diff -u -p -r1.731 usbdevs.h
--- sys/dev/usb/usbdevs.h 22 Jul 2020 11:13:20 - 1.731
+++ sys/dev/usb/usbdevs.h 3 Aug 2020 14:08:51 -
@@ -413,6 +413,7 @@
#defineUSB_VENDOR_OPTION 0x0af0 /* Option */
#defineUSB_VENDOR_ASUS 0x0b05 /* ASUS */
#defineUSB_VENDOR_TODOS0x0b0c /* Todos Data System */
+#define USB_VENDOR_GEARHEAD0x0b38 /* Gear Head */
#defineUSB_VENDOR_OCT 0x0b39 /* Omnidirectional Control
Technology */
#defineUSB_VENDOR_TEKRAM 0x0b3b /* Tekram Technology */
#defineUSB_VENDOR_HAL 0x0b41 /* HAL Corporation */
@@ -2061,6 +2062,10 @@
/* GCT Semiconductor products */
#defineUSB_PRODUCT_GCTSEMICON_INSTALL 0x7f40 /* GDM720x MASS
storage mode */
+
+/* Gear Head products */
+#define USB_PRODUCT_GEARHEAD_GHKB 0x0003 /* Gear Head Keyboard */
+#define USB_PRODUCT_GEARHEAD_GHKB107 0x0010 /* Gear Head 107-key
Keyboard */
/* GEMPLUS products */
#defineUSB_PRODUCT_GEMPLUS_PROXPU 0x5501 /* Prox-PU/CU */
Index: sys/dev/usb/usbdevs_data.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.725
diff -u -p -r1.725 usbdevs_data.h
--- sys/dev/usb/usbdevs_data.h 22 Jul 2020 11:13:20 - 1.725
+++ sys/dev/usb/usbdevs_data.h 3 Aug 2020 14:08:51 -
@@ -4210,6 +4210,14 @@ const struct usb_known_product usb_known
"GDM720x MASS storage mode",
},
{
+ USB_VENDOR_GEARHEAD, USB_PRODUCT_GEARHEAD_GHKB,
+ "Keyboard",
+ },
+ {
+ USB_VENDOR_GEARHEAD, USB_PRODUCT_GEARHEAD_GHKB107,
+ "107-Key Keyboard",
+ },
+ {
USB_VENDOR_GEMPLUS, USB_PRODUCT_GEMPLUS_PROXPU,
"Prox-PU/CU",
},
@@ -14280,6 +14288,10 @@ const struct usb_known_vendor usb_known_
{
USB_VENDOR_HP2,
"Hewlett Packard",
+ },
+ {
+ USB_VENDOR_GEARHEAD,
+ "Gear Head",
},
{ 0, NULL }
};
Re: 11n support for athn(4)
Hi Stefan, Thanks very much for the 11n support in athn(4)! Here's mine: athn0 at pci5 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16 athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:24:c8:4f I did some netperf tests between OpenBSD athn(4) in hostap mode (11n) and a Linux wifi client (using an iwn(4) type chipset) and couldn't get up to 4 MBps: # netperf -4 -H 10.13.0.2 -t TCP_STREAM -C -c -l 60 MIGRATED TCP STREAM TEST from (null) (0.0.0.0) port 0 AF_INET to (null) () port 0 AF_INET : demo Recv SendSend Utilization Service Demand Socket Socket Message Elapsed Send Recv SendRecv Size SizeSize Time Throughput localremote local remote bytes bytes bytessecs.10^6bits/s % C % ? us/KB us/KB 87380 16384 1638460.18 3.92 7.94 3.61 331.990 -151.019 # netperf -4 -H 10.13.0.2 -t TCP_STREAM -C -c -l 60 MIGRATED TCP STREAM TEST from (null) (0.0.0.0) port 0 AF_INET to (null) () port 0 AF_INET : demo Recv SendSend Utilization Service Demand Socket Socket Message Elapsed Send Recv SendRecv Size SizeSize Time Throughput localremote local remote bytes bytes bytessecs.10^6bits/s % C % ? us/KB us/KB 87380 16384 1638461.11 3.95 7.41 2.11 307.442 -87.524 Linux iwconfig client shows Bit rate of 1 MB/s which doesn't look right. Any ideas? Thanks, Tom
Re: ral rt2661 tx interrupt race fix
Stefan, Your patch works well on my system: ral0 at pci0 dev 14 function 0 Ralink RT2661 rev 0x00: irq 10, address 00:14:85:d5:39:bb ral0: MAC/BBP RT2661D, RF RT2529 (MIMO XR) Only problem is downloading from the net is extremely slow. Benchmarks have it at 512 KB/sec as opposed to 10 megabits/s. This is (internet) - OpenBSD - ral0 - wifi client But it doesn't crash or bring up OACTIVE flag anymore which is fantastic.. however, it's a little to slow to use with any regularity. Uploads are fine (wifi - ral(4) - OpenBSD - out to the net). Tom
October 13 2011 NAT update
You guys might want to add a note to current.html that from October 13 2011, the NAT updates have made it impossible to not use an address family in a nat-to statement. The following statement fails now: match out on egress from ($int_if:network) nat-to (egress) Gives the error: /etc/pf.conf:74: af-to is not supported on match rules /etc/pf.conf:74: skipping rule due to errors Changing it to: match out on egress inet from ($int_if:network) nat-to (egress) Fixes it. I wasn't sure how many people explicitly use the address family in their nat-to lines, but this one caught me out when I updated to a newer snapshot earlier this month. Tom
Re: mmuagp driver
Many thanks to oga@ for this. I have been using this patch for at least a month now and not had any issues. Relevant bits of dmesg: pchb0 at pci0 dev 0 function 0 NVIDIA nForce3 250 PCI Host rev 0xa1 mmuagp0 at pchb0: 1 Miscellaneous Control unit(s) found agp0 at mmuagp0: aperture at 0xf000, size 0x200 I also swapped out the Nvidia GeForce 7800 card and put in an ATI/Sapphire X1950 Pro (all AGP) and 3D worked, even though it was a little choppy, but oga@ said that was more down to the version of the intel driver in Xenocara than anything else. Tom
lii(4) causes panic when attempting to nfs_boot
Hi, I originally sent this to misc@ but it probably got lost in all the noise, so here it is again. I went through the PR database and found a case where someone was having problems with the MAC address being different between dmesg/ kernel time and later. I did not find that to be an issue at all. Here's the message again with dmesg and panic. Any ideas on how to fix? My best guess is it's the lii(4) driver itself, but I am not good at tracing these things. While attempting to network boot my Asus EEE with its lii(4) wired ethernet, I get an error and panic when it attempts to boot via nfs_boot. When I hook the network cable up to a switch to watch the link, it stays on until the kernel boots, then goes off during the devices detection, then goes back on briefly, then turns off before it tries to do the nfs_mount root. Thinking it could be a slow PHY, I modified line 1020 in netinet/if_ether.c to read: result = tsleep((caddr_t)myip, PSOCK, revarp, hz*20); However, all this did was make the kernel wait forever at the nfs_boot: line. I watched for link light again, and it stayed off almost the whole time, flickered for about quarter of a second, then went out again. For comparison, I hooked up another laptop (an Acer TravelMate with a bce(4) ethernet device) and attempted to boot diskless with it with the same kernel and config (except for changing the MAC address in /etc/ethers and dhcpd.conf) and it worked fine. I'm thinking it could have something to do with the lii(4) driver. Attached is the panic with trace and ps as well as a dmesg of the machine when it boots normally (with the kernel on a USB stick.) Tom PXE boot MAC address 00:22:15:14:89:d6, interface lii0 nfs_boot: using interface lii0, with revarp bootparams panic: reverse arp not answered by rarpd(8) or dhcpd(8) Stopped at Debugger+0x4: popl%ebp RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! DO NOT EVEN BOTHER REPORTING WITHOUT INCLUDING THAT INFORMATION! ddb trace Debugger(d08dea35,d0ba3cd4,d08d2434.d0ba3cd4,d156a094) at Debugger+0x4 panic(d08d2434,d156a094,d0ba3d18,d0a2f500,746f6f) at panic+0x5d nfs_boot_init(d0ba3df0,d0a2f500,128,d03ec0f9,a) at nfs_boot_init+0x3ca nfs_mountroot(d08b4257,0,d08b9faa,0,0) at nfs_mountroot+0x4c main(d02004ba,d02004c2,0,0,0) at main+0x57b ddb ps PID PPID PGRPUID S FLAGS WAIT COMMAND 10 0 0 0 30x100200 bored crypto 9 0 0 0 30x100200 pftm pfpurge 8 0 0 0 30x100200 usbtskusbtask 7 0 0 0 30x100200 usbatsk usbatsk 6 0 0 0 30x100200 bored intelrel 5 0 0 0 30x100200 acpi0 acpi0 4 0 0 0 30x100200 bored syswq 3 0 0 0 30x100200idle0 2 0 0 0 3 0x40100200 kmalloc kmthread 1 0 0 0 30x100200 initexec swapper *0 -1 0 0 7 0x80200swapper OpenBSD 4.9-current (GENERIC) #0: Thu Apr 28 21:01:49 BST 2011 r...@jera.pertho.net:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Celeron(R) M processor 900MHz (GenuineIntel 686-class) 631 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF real mem = 527527936 (503MB) avail mem = 508755968 (485MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 03/11/09, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @ 0xf06e0 (37 entries) bios0: vendor American Megatrends Inc. version 1302 date 03/11/2009 bios0: ASUSTeK Computer INC. 701 acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC OEMB MCFG acpi0: wakeup devices P0P3(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) MC97(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) EUSB(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 70MHz ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 5 (P0P3) acpiprt2 at acpi0: bus 3 (P0P5) acpiprt3 at acpi0: bus 1 (P0P6) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2 acpitz0 at acpi0: critical temperature 90 degC acpibat0 at acpi0: BAT0 model 701 serial type LION oem ASUS acpiac0 at acpi0: AC unit online acpiasus0 at acpi0 acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibtn2 at acpi0: PWRB acpivideo0 at acpi0: VGA_ bios0: ROM list: 0xc/0xf800! 0xcf800/0x1000 pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82915GM Host rev 0x04 vga1 at pci0 dev 2 function 0 Intel 82915GM Video rev 0x04 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5
Re: resurect and fix bce(4)
Janne Johansson wrote: 2011/4/3 Claudio Jeker cje...@diehard.n-r-g.com bce(4) was turned off because of limitations in the DMA engine that allows the chip to access only 1G of memory. On systems with more then 1G of memory hilarity ensued. Now I rewrote the driver to use bcopy() to copy the mbufs into a savely allocated DMA memory buffer. So the chip will now work with any ammount of memory in the machine. It works for me so if you own a bce(4) please test. FWIW, my loaner laptop from the job works fine with this, giving me bce0 back. (I used to limit ram to 1G when I needed bce before, don't have to anymore. I don't care for the performance drop, its far above 0 now) I can confirm this works nicely on my Acer TravelMate 4020 series laptop which has a built-in bce(4). The laptop only has half a gig of RAM so this was never an issue. Thanks for re-enabling this driver! Regards, Tom
Re: Add support to AR5424
On 21/05/10 18:42, Giovanni Bechis wrote: Il 21/05/2010 19.31, Tom Murphy ha scritto: Is there any update on this? Is it possible to get the chipset working? At least latest version breaks this chip (found on IBM x40): ath0 at pci1 dev 2 function 0 Atheros AR5212 (IBM MiniPCI) rev 0x01: irq 11 ath0: AR5213A 5.9 phy 4.3 rf5112a 3.6, MKK2A Cheers Giovanni Hi all, Any chance to get this patch work ingon the AR5424 in Asus 4g (701) laptops? The aforementioned patch here at least gets the machine no longer locking up so I think it would be a good candidate for going into the tree. Tom
Re: Add support to AR5424
On Sun, Apr 25, 2010 at 10:49:26PM +0100, Luis Henriques wrote: On Sun, Apr 25, 2010 at 08:29:35PM +0100, Tom Murphy wrote: Luis, I have an Asus EEE with uses an AR5424 chipset: ath0 at pci3 dev 0 function 0 Atheros AR5424 rev 0x01: apic 1 int 18 (irq 10) ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address 00:15:af:b5:36:7f I tried the latest patch you posted and it locks OpenBSD completely up when bringing the network up (even ifconfig ath0 up locks the system.) Thanks for testing and reporting this, Tom. Just curious about something: the dmesg you show in your email has been collected _without_ the patch, right? Because with the patch I would expect that the rf would be different from 0.0. -- Luis Hi Luis, Yes, that is correct. Do you need the rf value from the patched kernel? I basically patched the latest -CURRENT (cvs tree as of yesterday). Please let me know if you need any more information. Thanks! Tom
Re: Add support to AR5424
On Mon, Apr 26, 2010 at 03:38:19PM +0100, Luis Henriques wrote: On Mon, Apr 26, 2010 at 7:57 AM, Tom Murphy open...@pertho.net wrote: Hi Luis, Yes, that is correct. Do you need the rf value from the patched kernel? I basically patched the latest -CURRENT (cvs tree as of yesterday). Ok, thanks. I just wanted to make sure the patch was identifing correctly your card. The rf value should be different from 0.0. Hi Luis, Yes, it is different from 0.0. This is what I got when I booted up: ath0 at pci3 dev 0 function 0 Atheros AR5424 rev 0x01: apic 1 int 18 (irq 10) ath0: AR5424 14.2 phy 7.0 rf 10.2, WOR0W, address 00:15:af:b5:36:7f Regards, Tom
Re: Add support to AR5424
Luis, I have an Asus EEE with uses an AR5424 chipset: ath0 at pci3 dev 0 function 0 Atheros AR5424 rev 0x01: apic 1 int 18 (irq 10) ath0: AR5424 14.2 phy 7.0 rf 0.0, WOR0W, address 00:15:af:b5:36:7f I tried the latest patch you posted and it locks OpenBSD completely up when bringing the network up (even ifconfig ath0 up locks the system.) Tom
Re: rt2661 patch to fix interrupt handling under load
Marco Peereboom wrote: Has this been tested on all variants of the chip? Well, not by me, but other people on misc mentioned it fixed ral(4) issues for them. I only have a RT2661 and a RT2860 (the patch does not touch RT2860). I still do get the odd wireless dropout now and then, but it basically makes the system go for not working/useless/hard lockup to working with intermittent drops which I'd say is a HUGE improvement, even thuogh it's not perfect. Tom
rt2661 patch to fix interrupt handling under load
Hi, I'd like to point out that Roland Dreier's patch as detailed here: http://www.mail-archive.com/m...@openbsd.org/msg83528.html Works great on my little Soekris 5501 with a RT2661. (dmesg attached to end of this email.) I do still get the odd wireless drop for 15-20 seconds, but it no longer brings up the OACTIVE flag on ral0 and it doesn't make the system completely freeze (no way of getting a dump, have to hard reset.) I emailed damien@ on December 1st and got no response. The author of the patch has expressed his frustration at being able to contact a developer to get this committed. I would be more than happy to do testing. Feel free to contact me.. I know it's hard to test all hardware devices when there is a lack of them. Regards, Tom (kernel was compiled by me, with aforementioned patch above, and is GENERIC) OpenBSD 4.6-current (GENERIC) #2: Fri Nov 27 12:20:04 GMT 2009 r...@pertho.net:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 500 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX real mem = 536440832 (511MB) avail mem = 511152128 (487MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 20/80/26, BIOS32 rev. 0 @ 0xfac40 pcibios0 at bios0: rev 2.0 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc8000/0xa800 cpu0 at mainbus0: (uniprocessor) amdmsr0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) io address conflict 0x6100/0x100 io address conflict 0x6200/0x200 pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x33 glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES vr0 at pci0 dev 6 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:00:24:cb:a6:64 ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 7 function 0 VIA VT6105M RhineIII rev 0x96: irq 5, address 00:00:24:cb:a6:65 ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 8 function 0 VIA VT6105M RhineIII rev 0x96: irq 9, address 00:00:24:cb:a6:66 ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr3 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 12, address 00:00:24:cb:a6:67 ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 ral0 at pci0 dev 14 function 0 Ralink RT2661 rev 0x00: irq 10, address 00:14:85:d5:39:bb ral0: MAC/BBP RT2661D, RF RT2529 (MIMO XR) glxpcib0 at pci0 dev 20 function 0 AMD CS5536 ISA rev 0x03: rev 0, 32-bit 3579545Hz timer, watchdog, gpio gpio0 at glxpcib0: 32 pins pciide0 at pci0 dev 20 function 2 AMD CS5536 IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 1: WDC WD1200BEVS-00VAT0 wd0: 16-sector PIO, LBA48, 114473MB, 234441648 sectors wd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) ohci0 at pci0 dev 21 function 0 AMD CS5536 USB rev 0x02: irq 15, version 1.0, legacy support ehci0 at pci0 dev 21 function 1 AMD CS5536 USB rev 0x02: irq 15 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1 isa0 at glxpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS gpio1 at nsclpcsio0: 29 pins npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 AMD OHCI root hub rev 1.00/1.00 addr 1 biomask e1c7 netmask ffe7 ttymask mtrr: K6-family MTRR support (2 registers) vscsi0 at root scsibus0 at vscsi0: 256 targets softraid0 at root root on wd0a swap on wd0b dump on wd0b
