Is my network card bypassing "ignore lid" settings, because download still halts when I close lid?

winger9 · 11-16-2019, 02:34 PM

Summary

When I run get-iplayer or youtube-dl at the bash prompt to download a TV program
or video, I find that if I close the laptop lid, the download halts. With
youtube-dl, after re-opening the lid, it resumes the download after about 1
minute. With get-iplayer, after re-opening the lid, it sometimes doesn't resume
the download at all.

Similarly, when downloading a video using Firefox web browser, the download
halts when the lid is closed (and resumes after the lid is re-opened).

I use a wifi connection.

MAIN QUESTION 1:

What is causing this halting when the lid is closed? And what do I need to do
to fix it?

I've tried several lid disabling methods, but none of them cure the problem. I
also discovered an ACPI message that dmesg displays about the lid. See Full
Details about the disabling methods and about dmesg.

MAIN QUESTION 2:

Because the problem occurs with downloading, COULD THE PROBLEM BE SPECIFIC TO
THE NETWORK CARD? If so, is there some way of accessing the network card and
telling it to ignore the lid?

lspci and lshw show that the "wireless interface" is

Network controller: Broadcom Corporation BCM43227 802.11b/g/n.

Full Details

1. SPEC:

Laptop model is Acer Aspire 5755G, i5, running live knoppix 7.7.1 with
persistence, on USB stick. I've been using this setup for a year with few other
problems.

2. With the "ignore lid" settings in place, other (non-downloading) processes
continue to work happily when the lid is closed. For example, at the bash
prompt, if I play an mp3 audio file (a song), then close the lid, it continues
playing. Similarly, if I echo the numbers 1 to 100 with a 1 second sleep
between them, there is no interruption when I close the lid.

3. I've tried all the following lid disablings but none of them cure the
download halting problem:

Code:

a) In /etc/systemd/logind.conf, the following were already as follows:
HandleLidSwitch=ignore
#LidSwitchIgnoreInhibited=yes (commented-out)
b) I put IgnoreLid=true in /etc/UPower/UPower.conf
c) In /etc/default/acpi-support, "#LID_SLEEP=true" was already commented-out.
d) In /etc/acpi/events/lidbtn, I commented-out the following 2 lines
#event=button[ /]lid
#action=/etc/acpi/lid.sh
Actually there is no file called /etc/acpi/lid.sh.
e) I was going to do the following: gconf-editor, in apps > gnome-power-manager
> buttons, set lid_ac and lid_battery to nothing. However, in my gconf-editor
there is no "gnome-power-manager" under "apps".
f) $ sudo echo PNP0C0D:00 > /sys/bus/acpi/drivers/button/unbind
(where PNP0C0D:00 is the device name of the lid).
g) $ systemd-inhibit --what=handle-lid-switch youtube-dl ...
h) At boot prompt I typed "knoppix acpi=off".

4. I discovered the following (when acpi is on). After I close the lid (or after
I open it), dmesg displays the entry

[ 278.729314] ACPI: More than one Lid device found!

Is this a clue as to what the problem is? However, when acpi is off, the
download halting problem still exists. So acpi appears not to be the problem,
and so perhaps this acpi message isn't a clue.

uteck · 11-16-2019, 03:03 PM

I think this is Network Manager being its usual helpful self. Found this post: https://superuser.com/questions/1378...-fi-connection that mentionst he same problem as you. There is a powersave feature you can adjust mentioned it the link.

winger9 · 11-19-2019, 04:57 PM

Thanks so much uteck (#2). I really appreciate your superb idea.

I tried the method in the link, but unfortunately the download still
halts when I close the lid.

When I think about it, I've already got the lid switch completely disabled
at the kernel level, using the command at "3.f)" under "Full Details" in my
thread, ie

Code:

$ sudo echo PNP0C0D:00 > /sys/bus/acpi/drivers/button/unbind

(where PNP0C0D:00 is the device name of the lid).

So if NetworkManager had been trying to put powersave into effect when the lid
was closed, (causing downloading to halt), presumably it WOULDN'T BE ABLE TO effect that because the lid switch is disabled.

As I say, I can't help thinking that the network card (or its driver*) has some
sort of direct access to the lid switch state, and ignores any operating system
settings. I'm GUESSING that the card has built into it a setting which is
presently set to "Suspend transmission if lid closed", but which can be changed
to "DON'T suspend transmission if lid closed".

(*My wifi driver (module) is called "wl".)

But I dont know how to determine if I'm right, or how to change the setting.

business_kid · 12-09-2019, 05:08 AM

All lid switches are picked up by ACPI, which issues a suspend. Suspend is a sort of sleep state, the processor is put in the low power S3 state, and personally I imagine that rather than closing the lid kills the download.

My first advice is don't suspend while you're downloading. I don't believe the download will complete while in suspend. The system is written to memory and the cpu nods off.

If you don't want that, but want to close the lid, you can disable the lid closing initiating a suspend. In previous times, ACPI events (e.g. lid closing) trigger ACPI scripts (e.g. suspending). That's still the case with Slackware, which I use. Most distros have replaced a perfectly good and relatively simple system with systemd, and you are definitely on your own there. A look in /etc/acpi will tell you if ACPI is doing the work, or it's being told to go and play in the traffic. /etc/acpi should have events and scripts doing stuff. Otherwise, good luck with systemd; you'll need it.

ondoho · 12-10-2019, 01:46 PM

Quote:

Originally Posted by business_kid

If you don't want that, but want to close the lid, you can disable the lid closing initiating a suspend. In previous times, ACPI events (e.g. lid closing) trigger ACPI scripts (e.g. suspending). That's still the case with Slackware, which I use. Most distros have replaced a perfectly good and relatively simple system with systemd, and you are definitely on your own there. A look in /etc/acpi will tell you if ACPI is doing the work, or it's being told to go and play in the traffic. /etc/acpi should have events and scripts doing stuff. Otherwise, good luck with systemd; you'll need it.

Why the drama?
/etc/systemd/logind.conf:

Code:

<snip>
HandleLidSwitch=ignore
<snip>

business_kid · 12-11-2019, 04:34 AM

Why the drama?
/etc/systemd/logind.conf:

Yes, yes very good if it works. I have never got under the hood in systemd for one reason. I never want to get under the hood of anything that makes pppd look simple!
So that goes for systemd, selinux, and any other 'creeping growth' viruses which come out.

"Do one thing and do it well." I second that.