S3 lid state - weird things happening.

Crivens

Crivens

Administrator
Staff member
Administrator
Moderator
I have a most interesting thing going on with S3 and the lid switch on my Thinkpad.

- The lid state is set to S3 in the sysctrl.conf.
- Close lid, machine goes to sleep.
- Open lid, machine resumes. So far, no problem.
- Close lid, nothing happens (laptop continues to operate)
- Open lid, issue "acpiconf -s3" - laptop goes to sleep. Close lid, Open lid - no factor.
- Press power, machine resumes.

So S3 works, but only once when done with the lid state.

Anyone who has seen this before?
 
Crivens said:
I have a most interesting thing going on with S3 and the lid switch on my Thinkpad.
Click to expand...

Which model? [edit: and OS version]

Crivens said:
- The lid state is set to S3 in the sysctrl.conf.
Click to expand...

Typo? Please confirm /etc/sysctl.conf

Crivens said:
- Close lid, machine goes to sleep.
- Open lid, machine resumes. So far, no problem.
- Close lid, nothing happens
Click to expand...

With any delay after resuming?

Crivens said:
(laptop continues to operate)
- Open lid, issue "acpiconf -s3" - laptop goes to sleep. Close lid, Open lid - no factor.
Click to expand...

What means 'factor' here?

Crivens said:
- Press power, machine resumes.

So S3 works, but only once when done with the lid state.
Click to expand...

Does that whole sequence repeat? Like every second time?

Crivens said:
Anyone who has seen this before?
Click to expand...

I've seen similar reported in these forums, but can't recall when, or what title ...

Check % sysctl -a | grep lid (and/or egrep 'wake|sleep') for any others maybe relevant?
 
It's an A475, running releng/14.
S3 by lid switch works exactly once.
S3 by acpiconf can be repeated.
Exact versions will have to wait, I'm currently traveling. "No factor" means it does not matter, can be done 0..x times without impacting the result.
 
Crivens said:
It's an A475, running releng/14.
Click to expand...

I gather this is separate from your A485, as in various posts l eventually found such as:
https://forums.freebsd.org/threads/freebsd-friendly-laptop-recommendations.91382/post-633357

Crivens said:
S3 by lid switch works exactly once.
S3 by acpiconf can be repeated.
Click to expand...

Thanks. Not that I'm any the wiser, nor can l find who else had a similar if not same issue.

Crivens said:
"No factor" means it does not matter, can be done 0..x times without impacting the result.
Click to expand...

Ok. It is a strange one, as if something that was set right at or after boot, got set wrong after first lid switch suspend/resume?

Maybe a 'sysctl -a >fileN' before and after each step from boot, then a diff of each fileN with fileN+1 may show something? ... but remote debugging is all guesswork ...

Best of luck.
 
Correction: it is a 485. See what traveling with children does to you? I'll investigate, if I find the time.
 
Crivens said:
Correction: it is a 485. See what traveling with children does to you? I'll investigate, if I find the time.
Click to expand...

Anything further?

What if you suspend by using Fn-F4 instead of acpiconf -s3, then closing the lid?

There's another sysctl to do with waking on lid open that's usually on, but I haven't access right now.

You won't need the lid switch sysctl anymore - though it may be worth a test before removing it. Still, it's a mystery.
 
It doesn't help you much, but as a sanity check, I have suspend/resume working reliably on my X201 here. Close lid, suspend, open lid, resume, repeatable. Also Fn-f4 suspends, and Fn alone resumes. I can intermix them, so suspend with Fn-F4, then close lid, then open lid, results in resume. I'm running 14.0-RELEASE. It's actually pretty good.

It's hard to know where in the stack it might be failing on your box. It could be something very low level, hardware or firmware, but I'm guessing. Did it ever work properly on that machine?
 
The diff is more than 3600 lines, mostly counters. Nothing with how. Or acpi. ...

The thing is, Fun F4 does switch off the Mike. No sleep. And after one suspend&resume cycle, the lid switch does not work, no matter how that was done.
 
Crivens said:
The diff is more than 3600 lines, mostly counters. Nothing with how. Or acpi. ...
Click to expand...

I was wondering about sysctls including 'suspend|resume', 'sleep|wake' and such - but it's too hard to do remotely, and I'm not well enough to hunt deeper.

Crivens said:
The thing is, Fun F4 does switch off the Mike. No sleep.
Click to expand...

Weird. A clear departure from T and X series behaviour of your A485.

Crivens said:
And after one suspend&resume cycle, the lid switch does not work, no matter how that was done.
Click to expand...

I'm out of ideas, sorry. At least you know what not to do to get reliable S/R ...
 
Yes, I'll make me a button for this on the tray. No biggie, it's a nice rig nonetheless.
 
Are you sure the opening/closing of the lid is correctly reported? What does devd(8) report when you read /var/run/devd.pipe with cat /var/run/devd.pipe while opening/closing the lid, both before and after a S/R cycle?
 
remove the lid_switch_state line in sysctl.conf and set NONE for runtime, see what report driver after close and open lid.

in tcsh:

while (1)
sysctl dev.acpi_lid.0.state
sleep 1
end
 
I did the cat of /var/run/devd.pipe

The second closing of the lid does not produce the lid event.

And all the vtswitch entries do nothing to change it. I think this is buried in some EC and needs some special prodding.
 
You must log in or register to reply here.
Back
Top