Re: Audio issue: noise/interference

2023-07-10 Thread Ricky Cintron

On 2023-07-08 05:22, Alexandre Ratchov wrote:

On Fri, Jul 07, 2023 at 06:23:26PM -0400, Ricky Cintron wrote:
I recently resolved an audio issue where I could hear a constant, 
light
static noise in my earphones. It wasn't loud or distracting, but it 
was
always there. The solution was to remove 'mix' as a source for mix2 
and

mix3.

However, once I got rid of that static, I noticed some additional 
noise

that was apparently hidden behind the original static. Compared to the
first issue, this noise is quieter and not constant. Anyway, it
manifests itself in the following ways:

1) Very light static noise that never increases, but I've noticed that
when I load a web page (YouTube, for example), the noise is silenced
until the page finishes loading. This also sometimes happens when I
move the mouse cursor around the web browser window, but very briefly.
It's easier to notice when loading a page since it lasts longer.

2) Moving the mouse generates a barely audible buzzing sound, but this
either doesn't occur or is barely noticeable when moving the cursor on
a web browser window.

To troubleshoot, I inspected all the cables in the back of the
computer (power, DP, ethernet, USB keyboard, USB mouse, 
speakers/line),

and unplugged them (except the power cable) one at a time. I didn't
hear a difference, good or bad. I also turned some mixerctl knobs with
no noticeable effects.

Does anyone have any ideas? This isn't a big deal since I can't notice
it while listening to audio, and it's pretty easy to tune out even
without audio, but I'd still like to remove it if possible. I'm
considering buying a USB audio interface, so if that even works, that
could be a solution.


Check that your AC power plug is connected to the ground. Possibly
plug the computer in another plug, in another room, and see if this
makes any difference.

FWIW, I managed to reduce similar noises by putting ferrite rings on
most cables, the HDMI cable was a significant source of noise in my
case. I didn't try to put ferrite rings on the internal cables
(ex. those between the power supply and the motherboard), but it might
make sense as well.

Certain motherboards are just not well designed and noise might
remain, no matter what you do. A good audio interface would solve this
problem, assuming you're using speakers that don't generate noise or
passive headphones.

HTH


I'm definitely going to try different outlets later on, along with a
few other tests dealing with the power delivery. Fortunately the
noise is light so I can wait until a better time to disconnect and
move things around.

In your case, were the noises loud and audible through speakers?
Also, how did you determine which cables needed ferrite rings?



Re: Audio issue: noise/interference

2023-07-10 Thread Ricky Cintron

On 2023-07-07 23:26, Chris Bennett wrote:

On Fri, Jul 07, 2023 at 06:23:26PM -0400, Ricky Cintron wrote:
I recently resolved an audio issue where I could hear a constant, 
light
static noise in my earphones. It wasn't loud or distracting, but it 
was
always there. The solution was to remove 'mix' as a source for mix2 
and

mix3.



I wouldn't call this resolved. This is just a useful step in
troubleshooting. You now have more information towards a resolution.
That's a good thing, but not enough.
"My toaster shocks me every time I touch the metal case. I resolved it 
by

not touching the metal part of the toaster."

However, once I got rid of that static, I noticed some additional 
noise

that was apparently hidden behind the original static. Compared to the
first issue, this noise is quieter and not constant.


Don't assume that there are actually two issues here. It may all have
one cause or be two (or more) different problems.



Anyway, it
manifests itself in the following ways:

1) Very light static noise that never increases, but I've noticed that
when I load a web page (YouTube, for example), the noise is silenced
until the page finishes loading. This also sometimes happens when I
move the mouse cursor around the web browser window, but very briefly.
It's easier to notice when loading a page since it lasts longer.

2) Moving the mouse generates a barely audible buzzing sound, but this
either doesn't occur or is barely noticeable when moving the cursor on
a web browser window.

To troubleshoot, I inspected all the cables in the back of the
computer (power, DP, ethernet, USB keyboard, USB mouse, 
speakers/line),

and unplugged them (except the power cable) one at a time. I didn't
hear a difference, good or bad. I also turned some mixerctl knobs with
no noticeable effects.



Did you troubleshoot your earphones? It is very reasonable that they
could now have bad wires or other problems. Do you still hear these
noises with other earphones or speakers?


Yes, when I first noticed the noise, I tested the earphones with a
MacBook Pro, and there weren't any audible sounds at all (silent as
far as my ears could measure). Before installing OpenBSD on this
computer, it was running Windows 11 for about 8 months, and I never
noticed any noises, but I can't guarantee they weren't there either.
I'm going to do some additional testing soon, and one thing I want to
try is to load up a Linux live environment with working audio. As far
as speakers go, I can't hear the noise through them (it's too faint
and not affected by volume level).


Does anyone have any ideas? This isn't a big deal since I can't notice
it while listening to audio, and it's pretty easy to tune out even
without audio, but I'd still like to remove it if possible. I'm
considering buying a USB audio interface, so if that even works, that
could be a solution.



I advise finding out what the problem is before buying anything new. 
You
might find the same problem getting passed through another audio 
device.

I suspect that you will need to fix a hardware problem.
Don't assume that audio noise is in software.
You are surrounded by 50/60Hz noise caused by the power in your
house/office/workshop.


I agree. I've been looking at audio interfaces for a while, and wouldn't
buy one simply to avoid noise.


Electrolytic capacitors can go bad (Even brand new capacitors can be
defective). Look up bad motherboard capacitors and you can find some
pretty good pictures and information. You can find some good YouTube
videos on it too.

I would also suspect grounding problems as a possibility.
Which can mean bad connections with cables even if they look good.
You can be having a power supply problem too.
Check for loose motherboard screws.

Are you using the computer with the cover off?
Do you get these noises with the computer on, but then turning off the
monitor and moving the mouse around?

Nope, the cover's on. I didn't turn the monitor off, but I did 
disconnect

the display port cable, and the noises were still present.

Is your electrical wiring done properly? Do you have any other 
equipment

hooked up that might be causing ground loops? Excellent videos on
YouTube about ground loops and audio problems. Do you have any OLD 
radio

or TV equipment that could be latching onto the computer noise and
amplifying it?

Also, if you can, go unplug (not turn off) things around that could be
defective. For example, I have to throw away 3-4 USB chargers every
year. Nowadays, hardly anything is actually turned off anymore.

I used to hear noises like these too, but that was a long time ago...
I could hear them in my memory while reading your email.


Thanks for the ideas. I've compiled a list of additional tests I want to
perform (some will have to wait though).


Good luck,
Chris Bennett




Audio issue: noise/interference

2023-07-07 Thread Ricky Cintron

I recently resolved an audio issue where I could hear a constant, light
static noise in my earphones. It wasn't loud or distracting, but it was
always there. The solution was to remove 'mix' as a source for mix2 and
mix3.

However, once I got rid of that static, I noticed some additional noise
that was apparently hidden behind the original static. Compared to the
first issue, this noise is quieter and not constant. Anyway, it
manifests itself in the following ways:

1) Very light static noise that never increases, but I've noticed that
when I load a web page (YouTube, for example), the noise is silenced
until the page finishes loading. This also sometimes happens when I
move the mouse cursor around the web browser window, but very briefly.
It's easier to notice when loading a page since it lasts longer.

2) Moving the mouse generates a barely audible buzzing sound, but this
either doesn't occur or is barely noticeable when moving the cursor on
a web browser window.

To troubleshoot, I inspected all the cables in the back of the
computer (power, DP, ethernet, USB keyboard, USB mouse, speakers/line),
and unplugged them (except the power cable) one at a time. I didn't
hear a difference, good or bad. I also turned some mixerctl knobs with
no noticeable effects.

Does anyone have any ideas? This isn't a big deal since I can't notice
it while listening to audio, and it's pretty easy to tune out even
without audio, but I'd still like to remove it if possible. I'm
considering buying a USB audio interface, so if that even works, that
could be a solution.

$ dmesg
OpenBSD 7.3-current (GENERIC.MP) #1269: Sun Jul  2 12:21:03 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16934760448 (16150MB)
avail mem = 16401862656 (15642MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xe (99 entries)
bios0: vendor Dell Inc. version "1.20.0" date 12/15/2022
bios0: Dell Inc. OptiPlex 5070
efi0 at bios0: UEFI 2.7
efi0: American Megatrends rev 0x5000d
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT BOOT SSDT SSDT HPET 
SSDT SSDT UEFI LPIT SSDT SSDT DBGP DBG2 MSDM SLIC DMAR SSDT VFCT BGRT 
TPM2 ASF! WSMT
acpi0: wakeup devices PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) RP01(S4) 
PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) 
PXSX(S4) RP06(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-9700 CPU @ 3.00GHz, 2993.03 MHz, 06-9e-0d
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,SMX,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,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 
64b/line 4-way L2 cache, 12MB 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 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-9700 CPU @ 3.00GHz, 2993.04 MHz, 06-9e-0d
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,SMX,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,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 
64b/line 4-way L2 cache, 12MB 64b/line 12-way L3 cache

cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz, 2993.04 MHz, 06-9e-0d
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,SMX,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,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 

Re: Data source of record.bytes in audioctl

2023-07-04 Thread Ricky Cintron

On 2023-07-04 12:00, Alexandre Ratchov wrote:

On Mon, Jul 03, 2023 at 05:18:13PM -0400, Ricky Cintron wrote:

While troubleshooting some audio issues, I noticed that the values of
play.bytes and record.bytes in audioctl's output were identical, even
when only playing audio.

1) Is this expected behavior?


yes, by default the device always does DMA in both directions
(synchronously), so record.bytes increases like play.bytes


Great to know! This, along with the other details you've provided, will
help me understand what I'm seeing much more clearly now.

Thank you.


2) What is the source of this data (record.bytes)?



The source is the audio hardware interrupts. The audio(4) driver
handles them and increments its couter. The counter is readable by
userland with the AUDIO_GETPOS ioctl.


I found it interesting that the values were the same, so I took a look
at mixerctl, and noticed that 'line' (which is an output) and 'mix'
(which has line as its only source) were the sources for both
record.adc variables. At that point I figured that simply removing
all sources from those two variables would eliminate all audio data
from those recording channels, but record.bytes continued to match
play.bytes. I even attempted to mute both ADCs and to disable 
recording

in mixerctl (without rebooting), but nothing changed.

I'm probably going to remove 'line' and 'mix' as sources for the ADCs
because they don't make sense there, but I'm still hoping to 
understand

what's going on.



The mixer is a completely different thing and is completely
independent from DMA. It is supposed to control the analog
knobs/selectors, jack sensors, and alike.

Setting the record level to 0 (or removing all sources) would make the
ADC sample silence and produce zeros without affecting how it
works. That's why record.bytes still increases.


# mixerctl -v
inputs.dac-2:3=126,126
inputs.dac-0:1=126,126
record.adc-0:1_mute=off  [ off on ]
record.adc-0:1=124,124
record.adc-2:3_mute=off  [ off on ]
record.adc-2:3=124,124
inputs.mix_source=line  { line }
inputs.mix_line=120,120
inputs.mix2_source=dac-2:3  { dac-2:3 mix }
inputs.mix3_source=dac-0:1  { dac-0:1 mix }
outputs.spkr_source=mix2  [ mix2 ]
outputs.spkr_mute=on  [ off on ]
outputs.spkr_eapd=on  [ off on ]
outputs.line_source=mix3  [ mix2 mix3 ]
outputs.line_mute=off  [ off on ]
inputs.line=85,85
outputs.line_dir=output  [ none output input input-vr0 input-vr50 
input-vr80

input-vr100 ]
outputs.line_boost=off  [ off on ]
outputs.line_eapd=on  [ off on ]
outputs.hp_source=mix2  [ mix2 mix3 ]
outputs.hp_mute=off  [ off on ]
outputs.hp_boost=off  [ off on ]
outputs.hp_eapd=on  [ off on ]
record.adc-2:3_source=line,mix  { line mix }
record.adc-0:1_source=line,mix  { line mix }
outputs.line_sense=plugged  [ unplugged plugged ]
outputs.hp_sense=unplugged  [ unplugged plugged ]
outputs.spkr_muters=line,hp  { line hp }
outputs.master=126,126
outputs.master.mute=off  [ off on ]
outputs.master.slaves=dac-2:3,dac-0:1,spkr,line,hp  { dac-2:3 dac-0:1 
spkr

line hp }
record.volume=124,124
record.volume.mute=off  [ off on ]
record.volume.slaves=adc-0:1,adc-2:3  { adc-0:1 adc-2:3 line }
record.enable=sysctl  [ off on sysctl ]






Data source of record.bytes in audioctl

2023-07-03 Thread Ricky Cintron

While troubleshooting some audio issues, I noticed that the values of
play.bytes and record.bytes in audioctl's output were identical, even
when only playing audio.

1) Is this expected behavior?
2) What is the source of this data (record.bytes)?

I found it interesting that the values were the same, so I took a look
at mixerctl, and noticed that 'line' (which is an output) and 'mix'
(which has line as its only source) were the sources for both
record.adc variables. At that point I figured that simply removing
all sources from those two variables would eliminate all audio data
from those recording channels, but record.bytes continued to match
play.bytes. I even attempted to mute both ADCs and to disable recording
in mixerctl (without rebooting), but nothing changed.

I'm probably going to remove 'line' and 'mix' as sources for the ADCs
because they don't make sense there, but I'm still hoping to understand
what's going on.

# mixerctl -v
inputs.dac-2:3=126,126
inputs.dac-0:1=126,126
record.adc-0:1_mute=off  [ off on ]
record.adc-0:1=124,124
record.adc-2:3_mute=off  [ off on ]
record.adc-2:3=124,124
inputs.mix_source=line  { line }
inputs.mix_line=120,120
inputs.mix2_source=dac-2:3  { dac-2:3 mix }
inputs.mix3_source=dac-0:1  { dac-0:1 mix }
outputs.spkr_source=mix2  [ mix2 ]
outputs.spkr_mute=on  [ off on ]
outputs.spkr_eapd=on  [ off on ]
outputs.line_source=mix3  [ mix2 mix3 ]
outputs.line_mute=off  [ off on ]
inputs.line=85,85
outputs.line_dir=output  [ none output input input-vr0 input-vr50 
input-vr80 input-vr100 ]

outputs.line_boost=off  [ off on ]
outputs.line_eapd=on  [ off on ]
outputs.hp_source=mix2  [ mix2 mix3 ]
outputs.hp_mute=off  [ off on ]
outputs.hp_boost=off  [ off on ]
outputs.hp_eapd=on  [ off on ]
record.adc-2:3_source=line,mix  { line mix }
record.adc-0:1_source=line,mix  { line mix }
outputs.line_sense=plugged  [ unplugged plugged ]
outputs.hp_sense=unplugged  [ unplugged plugged ]
outputs.spkr_muters=line,hp  { line hp }
outputs.master=126,126
outputs.master.mute=off  [ off on ]
outputs.master.slaves=dac-2:3,dac-0:1,spkr,line,hp  { dac-2:3 dac-0:1 
spkr line hp }

record.volume=124,124
record.volume.mute=off  [ off on ]
record.volume.slaves=adc-0:1,adc-2:3  { adc-0:1 adc-2:3 line }
record.enable=sysctl  [ off on sysctl ]



Firefox and DPMS

2023-05-18 Thread Ricky Cintron
When watching fullscreen videos in Firefox on my OpenBSD desktop, 
Firefox
doesn't inhibit DPMS, allowing the display to turn off. This isn't new 
for me,
since I noticed the same thing back in 2018. At that time, I tested 
Chromium as

well, and it performed as expected by keeping my display on.

I've looked into this a couple of times since then, and at this point 
I'm sure
it has nothing to do with OpenBSD. Instead, it seems to be due to the 
way
Firefox attempts to inhibit DPMS and/or the screensaver, which 
apparently
doesn't work with a simple window manager setup like mine. I assume it 
works

fine under XFCE and Gnome.

I've worked around this issue by creating keybindings to disable and 
enable DPMS
manually when needed (using xset), so this isn't a high-priority problem 
for me.
However, I was hoping to see if others have experienced the same 
behavior, if
anyone can confirm my assumption about WMs/DEs, and if there's a better 
way to

deal with it.



Re: Suspend/resume does not work on Lenovo X1 Carbon 3rd gen laptop

2021-04-04 Thread Ricky Cintron
That's great. If hibernating is what you're really after, I hope that gets 
worked out
at some point. I don't currently use OpenBSD on laptops, so I don't know what 
else can
be done. At least suspending works though.


‐‐‐ Original Message ‐‐‐

On Saturday, April 3rd, 2021 at 1:09 PM, Mark Hesselink 
 wrote:

> Hi Ricky,
>
> I tested your suspend suggestion and interestingly suspend works like a
>
> charm. Hibernate however still does not work. I still suspect the tpm(4)
>
> driver may lack support for this particular Lenovo X1 Carbon 3rd gen
>
> machine, but have no proof to conclusively claim this.
>
> Cheersm
>
> Mark
>
> P.S. If any OpenBSD developer is reading this email, I am more than
>
> happy to try out tpm(4) patches and report back.
>
> On 3/23/2021 3:48 AM, Ricky Cintron wrote:
>
> > Hey Mark, I don't have an X1C so I can't offer any hardware-specific advice,
> >
> > but I see you're using the ZZZ command to hibernate the system, yet it 
> > appears
> >
> > you want to suspend the system (based on wording). Have you tested zzz
> >
> > (lowercase) instead? Maybe your hardware/setup doesn't support hibernation.
> >
> > If you are indeed trying to hibernate, then I have nothing. Sorry.
> >
> > ‐‐‐ Original Message ‐‐‐
> >
> > On Monday, March 22nd, 2021 at 8:20 AM, Mark Hesselink 
> > mhess...@alumni.caltech.edu wrote:
> >
> > > Hi,
> > >
> > > I'm sending the below bug report to misc@openbsd.org as I have
> > >
> > > deliberately not configured my OpenBSD workstations to be able to send
> > >
> > > mail -- they are mostly used by my children -- and a bug report sent
> > >
> > > directly to b...@openbsd.org never seems to have arrived. Hopefully this
> > >
> > > email does arrive.
> > >
> > > Cheers,
> > >
> > > Mark
> > >
> > > > Synopsis:    Suspend/resume does not work on Lenovo X2 Carbon 3rd gen
> > > >
> > > > laptop
> > >
> > > > Category:    system
> > > >
> > > > Environment:
> > > >
> > > > System  : OpenBSD 6.9
> > >
> > > Details : OpenBSD 6.9-beta (GENERIC.MP) #398: Fri Mar 12
> > >
> > > 15:01:24 MST 2021
> > >
> > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > >
> > > Architecture: OpenBSD.amd64
> > >
> > > Machine : amd64
> > >
> > > > Description:
> > > >
> > > > Suspend/resume unfortunately does not work on my Lenovo X1 Carbon
> > >
> > > 3rd gen laptop. Suspending the laptop using the ZZZ command does
> > >
> > > seem to suspend the laptop, but restarting the laptop afterwards
> > >
> > > does not result in the expected boot loader prompt of:
> > >
> > > >> OpenBSD/amd64 BOOT 3.53
> > >
> > > unhibernate detected: switching to /bsd.booted
> > >
> > > boot>
> > >
> > > Instead a standard boot prompt is presented as if the laptop never
> > >
> > > completed the suspend request, but instead was abruptly shut down.
> > >
> > > During boot the system detects that 1 or more filesystems were not
> > >
> > > cleanly unmounted as well.
> > >
> > > I have tried playing around with the various TPM settings in the
> > >
> > > BIOS, i.e. disabled, hidden and enabled TPM. Neither of these
> > >
> > > settings seem to have an effects on the laptop's ability to cleanly
> > >
> > > suspend/resume.
> > >
> > > > How-To-Repeat:
> > > >
> > > > ZZZ followed by booting of the laptop.
> > >
> > > > Fix:
> > > >
> > > > No known work around.
> > >
> > > dmesg:
> > >
> > > OpenBSD 6.9-beta (GENERIC.MP) #398: Fri Mar 12 15:01:24 MST 2021
> > >
> > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > >
> > > real mem = 8261603328 (7878MB)
> > >
> > > avail mem = 7995826176 (7625MB)
> > >
> > > random: good seed from bootblocks
> > >
> > > mpath0 at root
> > >
> > > scsibus0 at mpath0: 256 targets
> > >
> > > mainbus0 at root
> > >
> > > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries)
> > >
> > > bios0: vendor LENOVO version "N14ET54W (1.32 

Re: Suspend/resume does not work on Lenovo X1 Carbon 3rd gen laptop

2021-03-23 Thread Ricky Cintron
Hey Mark, I don't have an X1C so I can't offer any hardware-specific advice,
but I see you're using the ZZZ command to hibernate the system, yet it appears
you want to suspend the system (based on wording). Have you tested zzz
(lowercase) instead? Maybe your hardware/setup doesn't support hibernation.

If you are indeed trying to hibernate, then I have nothing. Sorry.


‐‐‐ Original Message ‐‐‐

On Monday, March 22nd, 2021 at 8:20 AM, Mark Hesselink 
 wrote:

> Hi,
>
> I'm sending the below bug report to misc@openbsd.org as I have
>
> deliberately not configured my OpenBSD workstations to be able to send
>
> mail -- they are mostly used by my children -- and a bug report sent
>
> directly to b...@openbsd.org never seems to have arrived. Hopefully this
>
> email does arrive.
>
> Cheers,
>
> Mark
>
> ---
>
> > Synopsis:    Suspend/resume does not work on Lenovo X2 Carbon 3rd gen
>
> laptop
>
> > Category:    system
>
> > Environment:
>
> System  : OpenBSD 6.9
>
>     Details : OpenBSD 6.9-beta (GENERIC.MP) #398: Fri Mar 12
>
> 15:01:24 MST 2021
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
>     Architecture: OpenBSD.amd64
>
>     Machine : amd64
>
> > Description:
>
> Suspend/resume unfortunately does not work on my Lenovo X1 Carbon
>
>     3rd gen laptop. Suspending the laptop using the ZZZ command does
>
>     seem to suspend the laptop, but restarting the laptop afterwards
>
>     does not result in the expected boot loader prompt of:
>
>     >> OpenBSD/amd64 BOOT 3.53
>
> unhibernate detected: switching to /bsd.booted
>
>     boot>
>
>     Instead a standard boot prompt is presented as if the laptop never
>
>     completed the suspend request, but instead was abruptly shut down.
>
>     During boot the system detects that 1 or more filesystems were not
>
>     cleanly unmounted as well.
>
>     I have tried playing around with the various TPM settings in the
>
>     BIOS, i.e. disabled, hidden and enabled TPM. Neither of these
>
>     settings seem to have an effects on the laptop's ability to cleanly
>
>     suspend/resume.
>
> > How-To-Repeat:
>
> ZZZ followed by booting of the laptop.
>
> > Fix:
>
> No known work around.
>
> dmesg:
>
> OpenBSD 6.9-beta (GENERIC.MP) #398: Fri Mar 12 15:01:24 MST 2021
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> real mem = 8261603328 (7878MB)
>
> avail mem = 7995826176 (7625MB)
>
> random: good seed from bootblocks
>
> mpath0 at root
>
> scsibus0 at mpath0: 256 targets
>
> mainbus0 at root
>
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries)
>
> bios0: vendor LENOVO version "N14ET54W (1.32 )" date 03/19/2020
>
> bios0: LENOVO 20BTS0MX00
>
> acpi0 at bios0: ACPI 5.0
>
> acpi0: sleep states S0 S3 S4 S5
>
> acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT
>
> SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI MSDM BATB FPDT UEFI
>
> acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3)
>
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
>
> acpihpet0 at acpi0: 14318179 Hz
>
> acpiec0 at acpi0
>
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>
> cpu0 at mainbus0: apid 0 (boot processor)
>
> cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.63 MHz, 06-3d-04
>
> 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,SMX,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,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,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.2.4.1.1.1, IBE
>
> cpu1 at mainbus0: apid 2 (application processor)
>
> cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.24 MHz, 06-3d-04
>
> 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,SMX,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,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
>
> cpu1: 256KB 64b/line 8-way L2 cache

Re: OpenBSD Monitor Sleep No Response

2020-12-21 Thread Ricky Cintron
As previously mentioned, you can use xset(1) to disable DPMS (and the 
screensaver,
if necessary). I use the following commands to disable and re-enable these
temporarily.

xset s off -dpms
xset s on +dpms

Since your keyboard also becomes unresponsive, it looks like you're problem is
something else, but if that problem is triggered when your display enters power
saving mode, this could help until you find a solution.


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Monday, December 21, 2020 5:09 PM, ben  wrote:

> > Did you see Jordan's reply?
>
> Yes, I did. My keyboard is also non-responsive after the monitor goes off, so
> CTRL-ALT-F* is not an option.
>
> Ben Raskin