Kernel debugging without serial port?
Hello, I have an x86_64 PC with no serial port - is it possible to run ddb remotely via a PCI-express or USB serial port adapter? Or does it only work on an actual motherboard serial port connection? If not, how do most kernel developers do their development work? In VMs, or on older hardware that actually does have a real serial port?:
Re: Can't press left shift+2 while caps lock is held
Confirmed that the issue persists in BIOS, and so it is not an OpenBSD issue. Thanks for the tip. On 3/30/21 7:06 AM, Petr Ročkai wrote: Hi, On Mon, Mar 29, 2021 at 09:53:52PM -0400, Brennan Vincent wrote: Strange issue on current. The key combination Caps + Left Shift + 2 produces no output, either in X or text console. Caps + Right Shift + 2 produces an '@', as expected. most likely a hardware limitation of the keyboard. Perhaps try it in the firmware setup if you can find a text box. I had the same issue on a thinkpad (definitely capslock was involved, and i think it was the exact same combo). Petr
Can't press left shift+2 while caps lock is held
Strange issue on current. The key combination Caps + Left Shift + 2 produces no output, either in X or text console. Caps + Right Shift + 2 produces an '@', as expected. Dmesg attached. OpenBSD 6.9-beta (CUSTOM.MP) #15: Mon Mar 29 19:45:36 EDT 2021 bren...@incheon.my.domain:/home/brennan/openbsd/src/sys/arch/amd64/compile/CUSTOM.MP real mem = 16867749888 (16086MB) avail mem = 16345214976 (15588MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xe7450 (97 entries) bios0: vendor Dell Inc. version "1.14.1" date 12/17/2020 bios0: Dell Inc. XPS 15 9575 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT BOOT SSDT SSDT HPET SSDT UEFI SSDT LPIT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT SSDT MSDM SLIC SSDT NHLT TPM2 SSDT ASF! DMAR BGRT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(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-8705G CPU @ 3.10GHz, 3692.82 MHz, 06-9e-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,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-8705G CPU @ 3.10GHz, 3691.40 MHz, 06-9e-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,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-8705G CPU @ 3.10GHz, 3691.40 MHz, 06-9e-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,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-8705G CPU @ 3.10GHz, 3691.40 MHz, 06-9e-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,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) i7-8705G CPU @ 3.10GHz, 3691.40 MHz, 06-9e-09 cpu4: 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 cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz, 3691.40 MHz, 06-9e-09 cpu5:
Is there any way I can help with ath10k?
I do not know how to write wifi drivers, but I am willing to donate hardware or other resources if that would be helpful to someone. Please contact me if so.
Re: Mouse hotplug in X?
Thanks for the report. That is odd. I have both a laptop trackpad and a USB mouse. The trackpad is mouse0 and the USB is mouse1. When I hotplug the mouse, only the trackpad works, but when I boot with it plugged in, both work fine. I have hotplugd running, but nothing special about USB mice in /etc/hotplug/attach - should I? /etc/hotplug/attach follows: #!/bin/sh DEVCLASS=$1 DEVNAME=$2 case $DEVCLASS in 3) sh /etc/netstart $DEVNAME ;; esac On 11/1/20 4:57 PM, Christopher Turkel wrote: I have had never had any issues hot plugging usb mice or keyboards. On Sunday, November 1, 2020, wrote: note that ps/2 is not actually designed for hotplug (I fried a keyboard controller to bring you this knowledge) On Nov 1, 2020, at 11:11 AM, Tomasz Rola wrote: On Sun, Nov 01, 2020 at 01:51:45PM -0500, Brennan Vincent wrote: Is it possible to get hot-plugging of USB mice to work? Can't find it in Google or man pages. My X is hardly the newest one and I can testplug usb mice at will. They work along ps/2 mouse (but just one mouse cursor/arrow, if I recall - it was a bit of time since I did it last). Same for keyboards. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_r...@bigfoot.com **
Mouse hotplug in X?
Is it possible to get hot-plugging of USB mice to work? Can't find it in Google or man pages.
Re: Issue updating spidermonkey
On 10/22/20 4:31 AM, Antoine Jacoutot wrote: On Wed, Oct 21, 2020 at 06:43:13PM -0400, Brennan Vincent wrote: On 10/21/20 4:40 AM, Stuart Henderson wrote: On 2020-10-21, Chris Bennett wrote: On Tue, Oct 20, 2020 at 08:26:05PM -0400, Brennan Vincent wrote: Updated yesterday from 6.7 to a snapshot, and now: $ doas pkg_add -u doas pkg_add -u -Dsnap You need to do some things different once you change to -current snapshots. Might also have to wait for -current packages to match the -current snapshot sometimes. -Dsnap does nothing for most of the year. The only thing it's useful for is pointing to the snapshots directory whdn you're running a kernel with no -beta/-current suffix (i.e. a release, or snapshot in the short period in the run-up to release). quirks-3.458 signed on 2020-10-18T13:56:14Z This shows that it is indeed looking at a snapshot directory not release. Can't update spidermonkey-60.9.0v1->spidermonkey78-78.3.1v1: no update found for spidermonkey-60.9.0v1 Can't install polkit-0.116p1->0.118: can't resolve spidermonkey78-78.3.1v1 Is this expected soon after updating? Do I just need to wait for some inconsistency in the pkg repo to be resolved? This could either be: - a bug in some port - a package source that does not have a consistent set of files from one build (can happen when a mirror is updating) First thing to do if this happens is check file dates in the mirror's directory listing and see if they're consistent (no big jump between the a* and z* files). Will the URL to check look something like https://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ ? I checked there; all the files were touched within a 10 minute period. Issue is persisting. Should be fixed in a current. Wait a few days for new packages. Thanks. What was the issue? Can you link to the diff that fixed it? (Just curious for my own culture).
Re: Issue updating spidermonkey
On 10/21/20 4:40 AM, Stuart Henderson wrote: On 2020-10-21, Chris Bennett wrote: On Tue, Oct 20, 2020 at 08:26:05PM -0400, Brennan Vincent wrote: Updated yesterday from 6.7 to a snapshot, and now: $ doas pkg_add -u doas pkg_add -u -Dsnap You need to do some things different once you change to -current snapshots. Might also have to wait for -current packages to match the -current snapshot sometimes. -Dsnap does nothing for most of the year. The only thing it's useful for is pointing to the snapshots directory whdn you're running a kernel with no -beta/-current suffix (i.e. a release, or snapshot in the short period in the run-up to release). quirks-3.458 signed on 2020-10-18T13:56:14Z This shows that it is indeed looking at a snapshot directory not release. Can't update spidermonkey-60.9.0v1->spidermonkey78-78.3.1v1: no update found for spidermonkey-60.9.0v1 Can't install polkit-0.116p1->0.118: can't resolve spidermonkey78-78.3.1v1 Is this expected soon after updating? Do I just need to wait for some inconsistency in the pkg repo to be resolved? This could either be: - a bug in some port - a package source that does not have a consistent set of files from one build (can happen when a mirror is updating) First thing to do if this happens is check file dates in the mirror's directory listing and see if they're consistent (no big jump between the a* and z* files). Will the URL to check look something like https://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/ ? I checked there; all the files were touched within a 10 minute period. Issue is persisting.
Issue updating spidermonkey
Updated yesterday from 6.7 to a snapshot, and now: $ doas pkg_add -u quirks-3.458 signed on 2020-10-18T13:56:14Z Can't update spidermonkey-60.9.0v1->spidermonkey78-78.3.1v1: no update found for spidermonkey-60.9.0v1 Can't install polkit-0.116p1->0.118: can't resolve spidermonkey78-78.3.1v1 Is this expected soon after updating? Do I just need to wait for some inconsistency in the pkg repo to be resolved? Thanks
wait6 ?
{Free,Net}BSD have wait6(2), which is even more general than wait4(2),
and allows one to implement POSIX-mandated waitid(2). See e.g.
https://man.netbsd.org/wait.2 .
Is the reason this (or something substantially similar) is missing from
OpenBSD that we don't want it, or just that nobody has done the work to
implement it?
If it is the latter, I can try to make a patch.
Re: Disable touchpad acceleration? (wsmouse)
I have found something that makes it feel linear, finally.
doas wsconsctl mouse.tp.deceleration=0
With the following patch. Maybe this does the same thing as your
mouse0.param suggestion? Although I didn't touch the x/y hysteresis
values (34/35).
diff --git sbin/wsconsctl/mouse.c sbin/wsconsctl/mouse.c
index e04642dacbc..0f1594e17e0 100644
--- sbin/wsconsctl/mouse.c
+++ sbin/wsconsctl/mouse.c
@@ -61,6 +61,7 @@ struct field mouse_field_tab[] = {
{ "tp.swapsides", _swapsides, FMT_CFG,
FLG_NORDBACK },
{ "tp.disable", _disable, FMT_CFG,
FLG_NORDBACK },
{ "tp.edges", _edges, FMT_CFG, FLG_NORDBACK },
+ { "tp.deceleration", _decel, FMT_CFG, FLG_NORDBACK },
{ "tp.param", _param, FMT_CFG, FLG_WRONLY },
/* Add an alias. This field is valid for all wsmouse devices. */
{ "param", _param, FMT_CFG, FLG_WRONLY },
diff --git sbin/wsconsctl/mousecfg.c sbin/wsconsctl/mousecfg.c
index 6d52bcbfc9c..6162df5c229 100644
--- sbin/wsconsctl/mousecfg.c
+++ sbin/wsconsctl/mousecfg.c
@@ -109,6 +109,12 @@ struct wsmouse_parameters cfg_revscroll = {
1
};
+struct wsmouse_parameters cfg_decel = {
+ (struct wsmouse_param[]) {
+ { WSMOUSECFG_DECELERATION, 0 }, },
+ 1
+};
+
struct wsmouse_parameters cfg_param = {
(struct wsmouse_param[]) {
{ -1, 0 },
diff --git sbin/wsconsctl/mousecfg.h sbin/wsconsctl/mousecfg.h
index 8e99139d280..97ef153fcb3 100644
--- sbin/wsconsctl/mousecfg.h
+++ sbin/wsconsctl/mousecfg.h
@@ -22,6 +22,7 @@ extern struct wsmouse_parameters cfg_edges;
extern struct wsmouse_parameters cfg_swapsides;
extern struct wsmouse_parameters cfg_disable;
extern struct wsmouse_parameters cfg_revscroll;
+extern struct wsmouse_parameters cfg_decel;
extern struct wsmouse_parameters cfg_param;
extern int cfg_touchpad;
On 10/14/20 2:12 PM, Ulf Brosziewski wrote:
Could you tell us why it feels weird?
If you are really serious about a completely "linear" response, you might
want to try
$ doas wsconsctl mouse0.param=34:0,35:0,36:0
This turns off noise filtering and deceleration (very low speeds are slowed
down even further, which may be helpful if you want to hit a 1-pixel window
border, for example). What remains is the filtering performed by the firmware,
which may be decent nowadays, or not.
On 10/14/20 8:22 AM, Brennan Vincent wrote:
On 10/14/20 1:49 AM, Otto Moerbeek wrote:
On Tue, Oct 13, 2020 at 11:38:11PM -0400, Brennan Vincent wrote:
Hello,
I am using the wsmouse driver with x11, and no amount of googling or reading
man pages has helped me figure out how to disable acceleration and have
completely flat/linear response. Is this possible?
I know that I can change sensitivity with `mouse.tp.scaling=`, but
I don't think this affects acceleration.
Check xset (and maybe xinput, but I;ve never used that).
-Otto
Thanks. `xinput --set-prop /dev/wsmouse0 'Device Accel Profile' -1` seems to
have made things a lot better, although it still feels a bit weird. I could
just be imagining it.
Anyway, thanks for the pointers!
Re: Disable touchpad acceleration? (wsmouse)
On 10/14/20 1:49 AM, Otto Moerbeek wrote: On Tue, Oct 13, 2020 at 11:38:11PM -0400, Brennan Vincent wrote: Hello, I am using the wsmouse driver with x11, and no amount of googling or reading man pages has helped me figure out how to disable acceleration and have completely flat/linear response. Is this possible? I know that I can change sensitivity with `mouse.tp.scaling=`, but I don't think this affects acceleration. Check xset (and maybe xinput, but I;ve never used that). -Otto Thanks. `xinput --set-prop /dev/wsmouse0 'Device Accel Profile' -1` seems to have made things a lot better, although it still feels a bit weird. I could just be imagining it. Anyway, thanks for the pointers!
Disable touchpad acceleration? (wsmouse)
Hello, I am using the wsmouse driver with x11, and no amount of googling or reading man pages has helped me figure out how to disable acceleration and have completely flat/linear response. Is this possible? I know that I can change sensitivity with `mouse.tp.scaling=`, but I don't think this affects acceleration.
Re: Dell XPS 9575: Can't resume from standby or suspend
, On 10/12/20 7:37 AM, prototyp3 wrote: On 10/10/20 4:40 PM, Brennan Vincent wrote: On 10/10/20 3:29 PM, Brennan Vincent wrote: On `apm -S` or `zzz`, the system appears to power down, but when I try to wake it back up, the power does come on (fans spin, keyboard lights come on) but the screen is black and the system is unresponsive. /var/log/messages attached. Anyone have some idea what steps I should take to investigate/debug this? Thanks Brennan Forgot to mention: I am running -current. If I boot with `disable amdgpu`, the issue goes away. It is probably related to this issue, which I reported previously, and which was at least partially fixed (I don't get panics now, at any rate): http://openbsd-archive.7691.n7.nabble.com/Dell-XPS-9575-with-dual-discrete-integrated-GPU-amdgpu-causes-kernel-panic-td377365.html I believe I have a related issue on a Dell Latitude E6500, currently running 6.7-stable, but affected since at least 6.5. My system appears to become unresponsive, but in reality only the display is broken (screen turned off) after unsuspend. I can still ssh into it from the outside. Is this also the case for you? Unfortunately it has an NVIDIA card for which there is no driver so I cannot `disable $dev` to get around it. In my case, I don't have ssh access, which presumably means that nothing is working (because when things _are_ working, I bring up networking in /etc/resume, so ssh should work). Thus, I don't think it's the same issue.
Re: Dell XPS 9575: Can't resume from standby or suspend
On 10/10/20 4:40 PM, Brennan Vincent wrote: On 10/10/20 3:29 PM, Brennan Vincent wrote: On `apm -S` or `zzz`, the system appears to power down, but when I try to wake it back up, the power does come on (fans spin, keyboard lights come on) but the screen is black and the system is unresponsive. /var/log/messages attached. Anyone have some idea what steps I should take to investigate/debug this? Thanks Brennan Forgot to mention: I am running -current. If I boot with `disable amdgpu`, the issue goes away. It is probably related to this issue, which I reported previously, and which was at least partially fixed (I don't get panics now, at any rate): http://openbsd-archive.7691.n7.nabble.com/Dell-XPS-9575-with-dual-discrete-integrated-GPU-amdgpu-causes-kernel-panic-td377365.html
Re: Dell XPS 9575: Can't resume from standby or suspend
On 10/10/20 3:29 PM, Brennan Vincent wrote: On `apm -S` or `zzz`, the system appears to power down, but when I try to wake it back up, the power does come on (fans spin, keyboard lights come on) but the screen is black and the system is unresponsive. /var/log/messages attached. Anyone have some idea what steps I should take to investigate/debug this? Thanks Brennan Forgot to mention: I am running -current.
Dell XPS 9575: Can't resume from standby or suspend
On `apm -S` or `zzz`, the system appears to power down, but when I try to wake it back up, the power does come on (fans spin, keyboard lights come on) but the screen is black and the system is unresponsive. /var/log/messages attached. Anyone have some idea what steps I should take to investigate/debug this? Thanks Brennan Oct 10 15:09:28 Incheon syslogd[81622]: start Oct 10 15:09:28 Incheon /bsd: syncing disks... done Oct 10 15:09:28 Incheon /bsd: newstate RUN -> INIT Oct 10 15:09:28 Incheon /bsd: RX status=6 Oct 10 15:09:28 Incheon /bsd: rebooting... Oct 10 15:09:28 Incheon /bsd: OpenBSD 6.8-current (GENERIC.MP) #1: Sat Oct 10 14:59:29 EDT 2020 Oct 10 15:09:28 Incheon /bsd: bren...@incheon.my.domain:/home/brennan/openbsd/src/sys/arch/amd64/compile/GENERIC.MP Oct 10 15:09:28 Incheon /bsd: real mem = 16867749888 (16086MB) Oct 10 15:09:28 Incheon /bsd: avail mem = 16341458944 (15584MB) Oct 10 15:09:28 Incheon /bsd: random: good seed from bootblocks Oct 10 15:09:28 Incheon /bsd: mpath0 at root Oct 10 15:09:28 Incheon /bsd: scsibus0 at mpath0: 256 targets Oct 10 15:09:28 Incheon /bsd: mainbus0 at root Oct 10 15:09:28 Incheon /bsd: bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xe7450 (96 entries) Oct 10 15:09:28 Incheon /bsd: bios0: vendor Dell Inc. version "1.7.1" date 07/07/2019 Oct 10 15:09:28 Incheon /bsd: bios0: Dell Inc. XPS 15 9575 Oct 10 15:09:28 Incheon /bsd: acpi0 at bios0: ACPI 5.0 Oct 10 15:09:28 Incheon /bsd: acpi0: sleep states S0 S3 S4 S5 Oct 10 15:09:28 Incheon /bsd: acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT BOOT SSDT SSDT HPET SSDT UEFI SSDT LPIT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT SSDT MSDM SLIC SSDT NHLT BGRT TPM2 SSDT ASF! DMAR Oct 10 15:09:28 Incheon /bsd: acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) PXSX(S4) [...] Oct 10 15:09:28 Incheon /bsd: acpitimer0 at acpi0: 3579545 Hz, 24 bits Oct 10 15:09:28 Incheon /bsd: acpimadt0 at acpi0 addr 0xfee0: PC-AT compat Oct 10 15:09:28 Incheon /bsd: cpu0 at mainbus0: apid 0 (boot processor) Oct 10 15:09:28 Incheon /bsd: cpu0: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz, 3692.88 MHz, 06-9e-09 Oct 10 15:09:28 Incheon /bsd: 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 Oct 10 15:09:28 Incheon /bsd: cpu0: 256KB 64b/line 8-way L2 cache Oct 10 15:09:28 Incheon /bsd: cpu0: smt 0, core 0, package 0 Oct 10 15:09:28 Incheon /bsd: mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges Oct 10 15:09:28 Incheon /bsd: cpu0: apic clock running at 24MHz Oct 10 15:09:28 Incheon /bsd: cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE Oct 10 15:09:28 Incheon /bsd: cpu1 at mainbus0: apid 2 (application processor) Oct 10 15:09:28 Incheon /bsd: cpu1: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz, 3691.40 MHz, 06-9e-09 Oct 10 15:09:28 Incheon /bsd: 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 Oct 10 15:09:28 Incheon /bsd: cpu1: 256KB 64b/line 8-way L2 cache Oct 10 15:09:28 Incheon /bsd: cpu1: smt 0, core 1, package 0 Oct 10 15:09:28 Incheon /bsd: cpu2 at mainbus0: apid 4 (application processor) Oct 10 15:09:28 Incheon /bsd: cpu2: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz, 3691.40 MHz, 06-9e-09 Oct 10 15:09:28 Incheon /bsd: 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 Oct 10 15:09:28 Incheon /bsd: cpu2: 256KB 64b/line 8-way L2 cache Oct 10 15:09:28 Incheon /bsd: cpu2: smt 0, core 2, package 0 Oct 10 15:09:28 Incheon /bsd: cpu3 at mainbus0: apid 6 (application processor) Oct 10 15:09:28 Incheon /bsd: cpu3: Intel(R) Core(TM)
Re: urtwn(4) gets wedged periodically
> On Nov 13, 2019, at 2:24 PM, Ian Darwin wrote: > > On Wed, Nov 13, 2019 at 01:25:46PM -0500, Ted Unangst wrote: >>> Can you give me the exact model of the one you bought recently? I have >>> half a mind to just write >>> off mine as a loss and buy something else. >> >> I am using this one: (the TL-WN725N N150 single band one) >> >> https://www.amazon.com/TP-Link-wireless-network-Adapter-SoftAP/dp/B008IFXQFU/ > > I have that one and it wedges occasionally (on a MacBook Pro > with 6.6-current), though infrequently. That’s fine. Mine wedges every few hours or less. If “infrequently” means less than once a day, I am okay with it. Do you need to reboot when it gets screwed up, or does a remove+reinsert get you up and running again?
Re: urtwn(4) gets wedged periodically
On 11/13/19 1:56 AM, Ted Unangst wrote: Brennan Vincent wrote: Hello, I have a Wi-Fi USB adapter. urtwn(4) normally works fine, but it's a bit flaky... I don't think this is a hardware issue because the device is working fine on Ubuntu. I think this is and isn't a hardware issue? I had the same problem with an edimax a few years ago. I lost it and recently replaced it with a TP Link model and it works a little better? There doesn't seem to be much variation in hardware designs, but I noticed the old one was frequently very hot, and the new one is not. Ah, I think I am in a similar boat. Mine is an Edimax also, and it does frequently get hot. Can you give me the exact model of the one you bought recently? I have half a mind to just write off mine as a loss and buy something else.
Re: urtwn(4) gets wedged periodically
On 11/13/19 1:41 AM, Brennan Vincent wrote: Hello, I have a Wi-Fi USB adapter. urtwn(4) normally works fine, but it's a bit flaky... The issue happens both on 6.6 and on -current. When my adapter gets into the bad state, it appears (from dmesg output) that the driver is scanning for access points over and over, never finding any. When I get into this wedged state, I don't know any way to bring the card back up other than unplugging it and re-inserting. (`ifconfig urtwn0 down && sleep 10 && sh /etc/netstart urtwn0` is no help). I am attaching the relevant snippets of the dmesg output (Kernel built with URTWN_DEBUG and urtwn_debug level set to 3). Another interesting thing is these "RX status=6" error messages in the output. Apparently, "6" corresponds to "USBD_CANCELLED" in sys/dev/usb/usbdi.h . I don't think this is a hardware issue because the device is working fine on Ubuntu. Please let me know if there is anything more I can do to help debug this. I am a beginner with OpenBSD so I'm not sure exactly what is relevant. Just to clarify: the parts of that dmesg output where the device is wedged is where you see tons of lines of `urtwn0: SCAN -> SCAN` and little else. The parts where it's actually printing out access point names and so on are when things are working fine.
urtwn(4) gets wedged periodically
Hello, I have a Wi-Fi USB adapter. urtwn(4) normally works fine, but it's a bit flaky... The issue happens both on 6.6 and on -current. When my adapter gets into the bad state, it appears (from dmesg output) that the driver is scanning for access points over and over, never finding any. When I get into this wedged state, I don't know any way to bring the card back up other than unplugging it and re-inserting. (`ifconfig urtwn0 down && sleep 10 && sh /etc/netstart urtwn0` is no help). I am attaching the relevant snippets of the dmesg output (Kernel built with URTWN_DEBUG and urtwn_debug level set to 3). Another interesting thing is these "RX status=6" error messages in the output. Apparently, "6" corresponds to "USBD_CANCELLED" in sys/dev/usb/usbdi.h . I don't think this is a hardware issue because the device is working fine on Ubuntu. Please let me know if there is anything more I can do to help debug this. I am a beginner with OpenBSD so I'm not sure exactly what is relevant. OpenBSD 6.6-current (GENERIC.MP) #5: Tue Nov 12 23:44:31 EST 2019 bren...@washington.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16867749888 (16086MB) avail mem = 16344203264 (15587MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xe7450 (96 entries) bios0: vendor Dell Inc. version "1.7.1" date 07/07/2019 bios0: Dell Inc. XPS 15 9575 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT BOOT SSDT SSDT HPET SSDT UEFI SSDT LPIT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT SSDT MSDM SLIC SSDT NHLT BGRT TPM2 SSDT ASF! DMAR acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(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-8705G CPU @ 3.10GHz, 3692.80 MHz, 06-9e-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,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,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-8705G CPU @ 3.10GHz, 3691.41 MHz, 06-9e-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,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,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-8705G CPU @ 3.10GHz, 3691.41 MHz, 06-9e-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,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,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-8705G CPU @ 3.10GHz, 3691.41 MHz, 06-9e-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,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,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) i7-8705G CPU @ 3.10GHz, 3691.40 MHz, 06-9e-09 cpu4:
vi in ramdisk?
Hello, I am asking this out of pure curiosity, not to criticize or start a debate. Why does the ramdisk not include /usr/bin/vi by default? To date, it is the only UNIX-like environment I have ever seen without some form of vi.
