Hi!
With recent linux-next, after resume networkmanager often claims that
"network is disabled". Sometimes suspend/resume clears that.
Any ideas? Does it work for you?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
> Pavel Machek wrote:
> >Hi!
> >
> >With recent linux-next, after resume networkmanager often claims that
> >"network is disabled". Sometimes suspend/resume clears that.
> >
> >Any ideas? Does it work for you?
> > Pavel
> Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
Thanks for testing... but yes, 4.16 should be ok. If not fixed,
problem will appear in 4.17-rc1.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek wrote:
> Hi!
>
> With recent linux-next, after resume networkmanager often claims that
> "network is disabled". Sometimes suspend/resume clears that.
>
> Any ideas? Does it work for you?
> Pavel
Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
Woody
On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:
> On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
> > Pavel Machek wrote:
> > > Hi!
> > >
> > > With recent linux-next, after resume networkmanager often claims
> > > that
> > > "network is disabled". Sometimes suspend/resume clears that.
> > >
> > > Any ideas? Does it work for you?
> > >
> > > Pavel
> >
> > Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
>
> Thanks for testing... but yes, 4.16 should be ok. If not fixed,
> problem will appear in 4.17-rc1.
Where does the complaint occur? In the GUI, or with nmcli, or
somewhere else? Also, what's the output of "nmcli dev" after resume?
Dan
On Mon 2018-03-19 10:40:08, Dan Williams wrote:
> On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:
> > On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
> > > Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > With recent linux-next, after resume networkmanager often claims
> > > > that
> > > > "network is disabled". Sometimes suspend/resume clears that.
> > > >
> > > > Any ideas? Does it work for you?
> > > >
> > > > Pavel
> > >
> > > Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
> >
> > Thanks for testing... but yes, 4.16 should be ok. If not fixed,
> > problem will appear in 4.17-rc1.
>
> Where does the complaint occur? In the GUI, or with nmcli, or
> somewhere else? Also, what's the output of "nmcli dev" after resume?
In the GUI. I click in place where I'd select access point, and menu
does not show up, telling me that "network is disabled".
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 2018-03-19 at 18:33 +0100, Pavel Machek wrote:
> On Mon 2018-03-19 10:40:08, Dan Williams wrote:
> > On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:
> > > On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
> > > > Pavel Machek wrote:
> > > > > Hi!
> > > > >
> > > > > With recent linux-next, after resume networkmanager often
> > > > > claims
> > > > > that
> > > > > "network is disabled". Sometimes suspend/resume clears that.
> > > > >
> > > > > Any ideas? Does it work for you?
> > > > >
> > > > >
> > > > > Pavel
> > > >
> > > > Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
> > >
> > > Thanks for testing... but yes, 4.16 should be ok. If not fixed,
> > > problem will appear in 4.17-rc1.
> >
> > Where does the complaint occur? In the GUI, or with nmcli, or
> > somewhere else? Also, what's the output of "nmcli dev" after
> > resume?
>
> In the GUI. I click in place where I'd select access point, and menu
> does not show up, telling me that "network is disabled".
Ok, what does 'nmcli dev' and 'nmcli radio' show?
Dan
On Mon 2018-03-19 12:45:49, Dan Williams wrote:
> On Mon, 2018-03-19 at 18:33 +0100, Pavel Machek wrote:
> > On Mon 2018-03-19 10:40:08, Dan Williams wrote:
> > > On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:
> > > > On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
> > > > > Pavel Machek wrote:
> > > > > > Hi!
> > > > > >
> > > > > > With recent linux-next, after resume networkmanager often
> > > > > > claims
> > > > > > that
> > > > > > "network is disabled". Sometimes suspend/resume clears that.
> > > > > >
> > > > > > Any ideas? Does it work for you?
> > > > > >
> > > > > >
> > > > > > Pavel
> > > > >
> > > > > Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
> > > >
> > > > Thanks for testing... but yes, 4.16 should be ok. If not fixed,
> > > > problem will appear in 4.17-rc1.
> > >
> > > Where does the complaint occur? In the GUI, or with nmcli, or
> > > somewhere else? Also, what's the output of "nmcli dev" after
> > > resume?
> >
> > In the GUI. I click in place where I'd select access point, and menu
> > does not show up, telling me that "network is disabled".
>
> Ok, what does 'nmcli dev' and 'nmcli radio' show?
Broken state.
pavel@amd:~$ nmcli dev
DEVICE TYPE STATE CONNECTION
eth1 ethernet unavailable --
lo loopback unmanaged --
wlan0 wifi unmanaged --
pavel@amd:~$ nmcli radio
WIFI-HW WIFI WWAN-HW WWAN
enabled enabled enabled enabled
pavel@amd:~$ uname -a
Linux amd 4.16.0-rc5-next-20180314+ #31 SMP Thu Mar 15 14:27:19 CET
2018 i686 GNU/Linux
Let me suspend/resume. I was lucky and got it into working state:
pavel@amd:~$ nmcli dev
DEVICE TYPE STATE CONNECTION
wlan0 wifi connected openwireless.org
eth1 ethernet unavailable --
lo loopback unmanaged --
pavel@amd:~$ nmcli radio
WIFI-HW WIFI WWAN-HW WWAN
enabled enabled enabled enabled
pavel@amd:~$
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, 2018-03-20 at 09:03 +0100, Pavel Machek wrote:
> On Mon 2018-03-19 12:45:49, Dan Williams wrote:
> > On Mon, 2018-03-19 at 18:33 +0100, Pavel Machek wrote:
> > > On Mon 2018-03-19 10:40:08, Dan Williams wrote:
> > > > On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:
> > > > > On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
> > > > > > Pavel Machek wrote:
> > > > > > > Hi!
> > > > > > >
> > > > > > > With recent linux-next, after resume networkmanager often
> > > > > > > claims
> > > > > > > that
> > > > > > > "network is disabled". Sometimes suspend/resume clears
> > > > > > > that.
> > > > > > >
> > > > > > > Any ideas? Does it work for you?
> > > > > > >
> > > > > > >
> > > > > > > Pavel
> > > > > >
> > > > > > Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
> > > > >
> > > > > Thanks for testing... but yes, 4.16 should be ok. If not
> > > > > fixed,
> > > > > problem will appear in 4.17-rc1.
> > > >
> > > > Where does the complaint occur? In the GUI, or with nmcli, or
> > > > somewhere else? Also, what's the output of "nmcli dev" after
> > > > resume?
> > >
> > > In the GUI. I click in place where I'd select access point, and
> > > menu
> > > does not show up, telling me that "network is disabled".
> >
> > Ok, what does 'nmcli dev' and 'nmcli radio' show?
>
> Broken state.
>
> pavel@amd:~$ nmcli dev
> DEVICE TYPE STATE CONNECTION
> eth1 ethernet unavailable --
> lo loopback unmanaged --
> wlan0 wifi unmanaged --
If the state is "unmanaged" on resume, that would indicate a problem
with sleep/wake and likely not a kernel network device issue.
We should probably move this discussion to the NM lists to debug
further. Before you suspend, run "nmcli gen log level trace" to turn
on full debug logging, then reproduce the issue, and send a pointer to
those logs (scrubbed for anything you consider sensitive) to the NM
mailing list.
Dan
> pavel@amd:~$ nmcli radio
> WIFI-HW WIFI WWAN-HW WWAN
> enabled enabled enabled enabled
> pavel@amd:~$ uname -a
> Linux amd 4.16.0-rc5-next-20180314+ #31 SMP Thu Mar 15 14:27:19 CET
> 2018 i686 GNU/Linux
>
> Let me suspend/resume. I was lucky and got it into working state:
>
> pavel@amd:~$ nmcli dev
> DEVICE TYPE STATE CONNECTION
> wlan0 wifi connected openwireless.org
> eth1 ethernet unavailable --
> lo loopback unmanaged --
> pavel@amd:~$ nmcli radio
> WIFI-HW WIFI WWAN-HW WWAN
> enabled enabled enabled enabled
> paveamd:~$
>
> Best regards,
>
> Pavel
>
Pavel Machek wrote:
> On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
>> Pavel Machek wrote:
>>> Hi!
>>>
>>> With recent linux-next, after resume networkmanager often claims that
>>> "network is disabled". Sometimes suspend/resume clears that.
>>>
>>> Any ideas? Does it work for you?
>>> Pavel
>> Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
> Thanks for testing... but yes, 4.16 should be ok. If not fixed,
> problem will appear in 4.17-rc1.
>
Works here OK. Tried ~10 suspends, all restarted OK.
kernel next-20180320
nmcli shows that Wifi always connects OK
Woody
Woody Suwalski wrote:
> Pavel Machek wrote:
>> On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
>>> Pavel Machek wrote:
>>>> Hi!
>>>>
>>>> With recent linux-next, after resume networkmanager often claims that
>>>> "network is disabled". Sometimes suspend/resume clears that.
>>>>
>>>> Any ideas? Does it work for you?
>>>> Pavel
>>> Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
>> Thanks for testing... but yes, 4.16 should be ok. If not fixed,
>> problem will appear in 4.17-rc1.
>>
> Works here OK. Tried ~10 suspends, all restarted OK.
> kernel next-20180320
> nmcli shows that Wifi always connects OK
>
> Woody
>
Contrary, it just happened to me on a 64-bit build 4.16-rc5 on T440.
I think that Dan's suspicion is correct - it is a snafu in the PM:
trying to hibernate results in a message:
Failed to hibernate system via logind: There's already a shutdown or
sleep operation in progress.
And ps shows "Ds /lib/systemd/systemd-sleep suspend"...
Woody
> > > Ok, what does 'nmcli dev' and 'nmcli radio' show?
> >
> > Broken state.
> >
> > pavel@amd:~$ nmcli dev
> > DEVICE TYPE STATE CONNECTION
> > eth1 ethernet unavailable --
> > lo loopback unmanaged --
> > wlan0 wifi unmanaged --
>
> If the state is "unmanaged" on resume, that would indicate a problem
> with sleep/wake and likely not a kernel network device issue.
>
> We should probably move this discussion to the NM lists to debug
> further. Before you suspend, run "nmcli gen log level trace" to turn
> on full debug logging, then reproduce the issue, and send a pointer to
> those logs (scrubbed for anything you consider sensitive) to the NM
> mailing list.
Hmm :-)
root@amd:/data/pavel# nmcli gen log level trace
Error: Unknown log level 'trace'
root@amd:/data/pavel# nmcli gen log level help
Error: Unknown log level 'help'
root@amd:/data/pavel# nmcli gen log level
Error: value for 'level' argument is required.
root@amd:/data/pavel# nmcli gen log level debug
root@amd:/data/pavel# cat /var/log/sys/log
Where do I get the logs? I don't see much in the syslog...
And.. It seems that it is "every other suspend". One resume results in
broken network, one in working one, one in broken one...
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:
> > > > Ok, what does 'nmcli dev' and 'nmcli radio' show?
> > >
> > > Broken state.
> > >
> > > pavel@amd:~$ nmcli dev
> > > DEVICE TYPE STATE CONNECTION
> > > eth1 ethernet unavailable --
> > > lo loopback unmanaged --
> > > wlan0 wifi unmanaged --
> >
> > If the state is "unmanaged" on resume, that would indicate a
> > problem
> > with sleep/wake and likely not a kernel network device issue.
> >
> > We should probably move this discussion to the NM lists to debug
> > further. Before you suspend, run "nmcli gen log level trace" to
> > turn
> > on full debug logging, then reproduce the issue, and send a pointer
> > to
> > those logs (scrubbed for anything you consider sensitive) to the NM
> > mailing list.
>
> Hmm :-)
>
> root@amd:/data/pavel# nmcli gen log level trace
> Error: Unknown log level 'trace'
What NM version? 'trace' is pretty old (since 1.0 from December 2014)
so unless you're using a really, really old version of Debian I'd
expect you'd have it. Anyway, debug would do.
> root@amd:/data/pavel# nmcli gen log level help
> Error: Unknown log level 'help'
nmcli gen help
> root@amd:/data/pavel# nmcli gen log level
> Error: value for 'level' argument is required.
> root@amd:/data/pavel# nmcli gen log level debug
This should be OK.
> root@amd:/data/pavel# cat /var/log/sys/log
It routes it to whatever the syslog 'daemon' facility logs to (however
that's configured on your system). Usually /var/log/messages or
/var/log/daemon.log or sometimes your distro configures it to
/var/log/NetworkManager.log.
Or if you're using a systemd-based distro, it would probably be in the
systemd journal so "journalctl -b -u NetworkManager"
> Where do I get the logs? I don't see much in the syslog...
> And.. It seems that it is "every other suspend". One resume results
> in
> broken network, one in working one, one in broken one...
Does your distro use pm-utils, upower, or systemd for suspend/resume
handling?
Dan
Hi!
I wanted to re-test next (4.16.0-rc7-next-20180329), but that one does
not suspend at all.
I normally suspend by pressing power button in MATE, but that action
currently results in machine hanging.
Pavel
On Mon 2018-03-26 10:33:55, Dan Williams wrote:
> On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:
> > > > > Ok, what does 'nmcli dev' and 'nmcli radio' show?
> > > >
> > > > Broken state.
> > > >
> > > > pavel@amd:~$ nmcli dev
> > > > DEVICE TYPE STATE CONNECTION
> > > > eth1 ethernet unavailable --
> > > > lo loopback unmanaged --
> > > > wlan0 wifi unmanaged --
> > >
> > > If the state is "unmanaged" on resume, that would indicate a
> > > problem
> > > with sleep/wake and likely not a kernel network device issue.
> > >
> > > We should probably move this discussion to the NM lists to debug
> > > further. Before you suspend, run "nmcli gen log level trace" to
> > > turn
> > > on full debug logging, then reproduce the issue, and send a pointer
> > > to
> > > those logs (scrubbed for anything you consider sensitive) to the NM
> > > mailing list.
> >
> > Hmm :-)
> >
> > root@amd:/data/pavel# nmcli gen log level trace
> > Error: Unknown log level 'trace'
>
> What NM version? 'trace' is pretty old (since 1.0 from December 2014)
> so unless you're using a really, really old version of Debian I'd
> expect you'd have it. Anyway, debug would do.
>
> > root@amd:/data/pavel# nmcli gen log level help
> > Error: Unknown log level 'help'
>
> nmcli gen help
>
> > root@amd:/data/pavel# nmcli gen log level
> > Error: value for 'level' argument is required.
> > root@amd:/data/pavel# nmcli gen log level debug
>
> This should be OK.
>
> > root@amd:/data/pavel# cat /var/log/sys/log
>
> It routes it to whatever the syslog 'daemon' facility logs to (however
> that's configured on your system). Usually /var/log/messages or
> /var/log/daemon.log or sometimes your distro configures it to
> /var/log/NetworkManager.log.
>
> Or if you're using a systemd-based distro, it would probably be in the
> systemd journal so "journalctl -b -u NetworkManager"
>
> > Where do I get the logs? I don't see much in the syslog...
>
> > And.. It seems that it is "every other suspend". One resume results
> > in
> > broken network, one in working one, one in broken one...
>
> Does your distro use pm-utils, upower, or systemd for suspend/resume
> handling?
>
> Dan
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon 2018-03-19 18:33:56, Pavel Machek wrote:
> On Mon 2018-03-19 10:40:08, Dan Williams wrote:
> > On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:
> > > On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
> > > > Pavel Machek wrote:
> > > > > Hi!
> > > > >
> > > > > With recent linux-next, after resume networkmanager often claims
> > > > > that
> > > > > "network is disabled". Sometimes suspend/resume clears that.
> > > > >
> > > > > Any ideas? Does it work for you?
> > > > >
> > > > > Pavel
> > > >
> > > > Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
> > >
> > > Thanks for testing... but yes, 4.16 should be ok. If not fixed,
> > > problem will appear in 4.17-rc1.
> >
> > Where does the complaint occur? In the GUI, or with nmcli, or
> > somewhere else? Also, what's the output of "nmcli dev" after resume?
>
> In the GUI. I click in place where I'd select access point, and menu
> does not show up, telling me that "network is disabled".
Ouch and the bug now crept to mainline.. and it happens on X220,
too. With ethernet, bug is harder to see, because "network is
disabled" and "no network" icon is there, but ethernet still works.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue 2018-03-20 21:11:54, Woody Suwalski wrote:
> Woody Suwalski wrote:
> >Pavel Machek wrote:
> >>On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
> >>>Pavel Machek wrote:
> >>>>Hi!
> >>>>
> >>>>With recent linux-next, after resume networkmanager often claims that
> >>>>"network is disabled". Sometimes suspend/resume clears that.
> >>>>
> >>>>Any ideas? Does it work for you?
> >>>>??????????????????????????????????? Pavel
> >>>Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
> >>Thanks for testing... but yes, 4.16 should be ok. If not fixed,
> >>problem will appear in 4.17-rc1.
> >>
> >Works here OK. Tried ~10 suspends, all restarted OK.
> >kernel next-20180320
> >nmcli shows that Wifi always connects OK
> >
> >Woody
> >
> Contrary, it just happened to me on a 64-bit build 4.16-rc5 on T440.
> I think that Dan's suspicion is correct - it is a snafu in the PM: trying to
> hibernate results in a message:
> Failed to hibernate system via logind: There's already a shutdown or sleep
> operation in progress.
>
> And ps shows "Ds /lib/systemd/systemd-sleep suspend"...
Problem now seems to be in the mainline.
But no, I don't see systemd-sleep in my process list :-(.
I guess you can't reproduce it easily? I tried bisecting, but while it
happens often enough to make v4.17 hard to use, it does not permit
reliable bisect.
These should be bad according to my notes
b04240a33b99b32cf6fbdf5c943c04e505a0cb07
ed80dc19e4dd395c951f745acd1484d61c4cfb20
52113a0d3889d6e2738cf09bf79bc9cac7b5e1c6
4fc97ef94bbfa185d16b3e44199b7559d0668747
14ebdb2c814f508936fe178a2abc906a16a3ab48
639adbeef5ae1bb8eeebbb0cde0b885397bde192
bisection claimed
c16add24522547bf52c189b3c0d1ab6f5c2b4375
is first bad commit, but I'm not sure if I trust that.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon 2018-03-26 10:33:55, Dan Williams wrote:
> On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:
> > > > > Ok, what does 'nmcli dev' and 'nmcli radio' show?
> > > >
> > > > Broken state.
> > > >
> > > > pavel@amd:~$ nmcli dev
> > > > DEVICE TYPE STATE CONNECTION
> > > > eth1 ethernet unavailable --
> > > > lo loopback unmanaged --
> > > > wlan0 wifi unmanaged --
> > >
> > > If the state is "unmanaged" on resume, that would indicate a
> > > problem
> > > with sleep/wake and likely not a kernel network device issue.
> > >
> > > We should probably move this discussion to the NM lists to debug
> > > further. Before you suspend, run "nmcli gen log level trace" to
> > > turn
> > > on full debug logging, then reproduce the issue, and send a pointer
> > > to
> > > those logs (scrubbed for anything you consider sensitive) to the NM
> > > mailing list.
> >
> > Hmm :-)
> >
> > root@amd:/data/pavel# nmcli gen log level trace
> > Error: Unknown log level 'trace'
>
> What NM version? 'trace' is pretty old (since 1.0 from December 2014)
> so unless you're using a really, really old version of Debian I'd
> expect you'd have it. Anyway, debug would do.
Hmm.
pavel@duo:~$ /usr/sbin/NetworkManager --version
You must be root to run NetworkManager!
pavel@duo:~$ sudo /usr/sbin/NetworkManager --version
0.9.10.0
So I set the log level, but I still don't see much in the log:
Apr 14 18:14:29 duo dbus[3009]: [system] Successfully activated
service 'org.freedesktop.nm_dispatcher'
Apr 14 18:14:29 duo nm-dispatcher: Dispatching action 'down' for wlan1
Apr 14 18:14:29 duo systemd[1]: Started Network Manager Script
Dispatcher Service.
Apr 14 18:14:29 duo systemd-sleep[6853]: Suspending system...
Apr 14 21:27:53 duo systemd[1]: systemd-journald.service watchdog
timeout (limit 1min)!
pavel@duo:~$ date
Sun Apr 15 12:26:32 CEST 2018
pavel@duo:~$
Is it possible that time handling accross suspend changed in v4.17?
I get some weird effects. With display backlight...
> > Where do I get the logs? I don't see much in the syslog...
>
> > And.. It seems that it is "every other suspend". One resume results
> > in
> > broken network, one in working one, one in broken one...
>
> Does your distro use pm-utils, upower, or systemd for suspend/resume
> handling?
upower, I guess:
pavel@duo:/data/l/linux$ ps aux | grep upower
root 3820 0.0 0.1 42848 7984 ? Ssl Apr14 0:01
/usr/lib/upower/upowerd
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sun, 2018-04-15 at 18:16 +0200, Pavel Machek wrote:
> On Mon 2018-03-26 10:33:55, Dan Williams wrote:
> > On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:
> > > > > > Ok, what does 'nmcli dev' and 'nmcli radio' show?
> > > > >
> > > > > Broken state.
> > > > >
> > > > > pavel@amd:~$ nmcli dev
> > > > > DEVICE TYPE STATE CONNECTION
> > > > > eth1 ethernet unavailable --
> > > > > lo loopback unmanaged --
> > > > > wlan0 wifi unmanaged --
> > > >
> > > > If the state is "unmanaged" on resume, that would indicate a
> > > > problem
> > > > with sleep/wake and likely not a kernel network device issue.
> > > >
> > > > We should probably move this discussion to the NM lists to
> > > > debug
> > > > further. Before you suspend, run "nmcli gen log level trace"
> > > > to
> > > > turn
> > > > on full debug logging, then reproduce the issue, and send a
> > > > pointer
> > > > to
> > > > those logs (scrubbed for anything you consider sensitive) to
> > > > the NM
> > > > mailing list.
> > >
> > > Hmm :-)
> > >
> > > root@amd:/data/pavel# nmcli gen log level trace
> > > Error: Unknown log level 'trace'
> >
> > What NM version? 'trace' is pretty old (since 1.0 from December
> > 2014)
> > so unless you're using a really, really old version of Debian I'd
> > expect you'd have it. Anyway, debug would do.
>
> Hmm.
>
> pavel@duo:~$ /usr/sbin/NetworkManager --version
> You must be root to run NetworkManager!
> pavel@duo:~$ sudo /usr/sbin/NetworkManager --version
> 0.9.10.0
>
> So I set the log level, but I still don't see much in the log:
>
> Apr 14 18:14:29 duo dbus[3009]: [system] Successfully activated
> service 'org.freedesktop.nm_dispatcher'
> Apr 14 18:14:29 duo nm-dispatcher: Dispatching action 'down' for
> wlan1
> Apr 14 18:14:29 duo systemd[1]: Started Network Manager Script
> Dispatcher Service.
> Apr 14 18:14:29 duo systemd-sleep[6853]: Suspending system...
I think if systemd really is handling the suspend/resume, you'll need
to make sure NM has systemd suspend/resume handling enabled as well.
NM 0.9.10 has build-time support for both:
[--with-suspend-resume=upower|systemd]
while later versions also support ConsoleKit2 and elogind.
Any idea what your NM was compiled with? Though honestly I'm not sure
how all the suspend/resume stuff is supposed to work these days on
different distros that provide the choice between systemd/upower/pm-
utils/CK2/etc.
Dan
> Apr 14 21:27:53 duo systemd[1]: systemd-journald.service watchdog
> timeout (limit 1min)!
> pavel@duo:~$ date
> Sun Apr 15 12:26:32 CEST 2018
> pavel@duo:~$
>
> Is it possible that time handling accross suspend changed in v4.17?
>
> I get some weird effects. With display backlight...
>
> > > Where do I get the logs? I don't see much in the syslog...
> > > And.. It seems that it is "every other suspend". One resume
> > > results
> > > in
> > > broken network, one in working one, one in broken one...
> >
> > Does your distro use pm-utils, upower, or systemd for
> > suspend/resume
> > handling?
>
> upower, I guess:
>
> pavel@duo:/data/l/linux$ ps aux | grep upower
> root 3820 0.0 0.1 42848 7984 ? Ssl Apr14 0:01
> /usr/lib/upower/upowerd
>
>
> Pavel
Hi!
On Mon 2018-03-26 10:33:55, Dan Williams wrote:
> On Sun, 2018-03-25 at 08:19 +0200, Pavel Machek wrote:
> > > > > Ok, what does 'nmcli dev' and 'nmcli radio' show?
> > > >
> > > > Broken state.
> > > >
> > > > pavel@amd:~$ nmcli dev
> > > > DEVICE TYPE STATE CONNECTION
> > > > eth1 ethernet unavailable --
> > > > lo loopback unmanaged --
> > > > wlan0 wifi unmanaged --
> > >
> > > If the state is "unmanaged" on resume, that would indicate a
> > > problem
> > > with sleep/wake and likely not a kernel network device issue.
> > >
> > > We should probably move this discussion to the NM lists to debug
> > > further. Before you suspend, run "nmcli gen log level trace" to
> > > turn
> > > on full debug logging, then reproduce the issue, and send a pointer
> > > to
> > > those logs (scrubbed for anything you consider sensitive) to the NM
> > > mailing list.
> >
> > Hmm :-)
> >
> > root@amd:/data/pavel# nmcli gen log level trace
> > Error: Unknown log level 'trace'
>
> What NM version? 'trace' is pretty old (since 1.0 from December 2014)
> so unless you're using a really, really old version of Debian I'd
> expect you'd have it. Anyway, debug would do.
...
Hmm. I also noticed now screen saver kicks in _right after I resume
the machine_. That did not use to be the case (and is a bit annoying
on its own).
Do we have any changes with time across suspend/resume in v4.17?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek wrote:
> On Tue 2018-03-20 21:11:54, Woody Suwalski wrote:
>> Woody Suwalski wrote:
>>> Pavel Machek wrote:
>>>> On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
>>>>> Pavel Machek wrote:
>>>>>> Hi!
>>>>>>
>>>>>> With recent linux-next, after resume networkmanager often claims that
>>>>>> "network is disabled". Sometimes suspend/resume clears that.
>>>>>>
>>>>>> Any ideas? Does it work for you?
>>>>>> ??????????????????????????????????? Pavel
>>>>> Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
>>>> Thanks for testing... but yes, 4.16 should be ok. If not fixed,
>>>> problem will appear in 4.17-rc1.
>>>>
>>> Works here OK. Tried ~10 suspends, all restarted OK.
>>> kernel next-20180320
>>> nmcli shows that Wifi always connects OK
>>>
>>> Woody
>>>
>> Contrary, it just happened to me on a 64-bit build 4.16-rc5 on T440.
>> I think that Dan's suspicion is correct - it is a snafu in the PM: trying to
>> hibernate results in a message:
>> Failed to hibernate system via logind: There's already a shutdown or sleep
>> operation in progress.
>>
>> And ps shows "Ds /lib/systemd/systemd-sleep suspend"...
> Problem now seems to be in the mainline.
>
> But no, I don't see systemd-sleep in my process list :-(.
>
> I guess you can't reproduce it easily? I tried bisecting, but while it
> happens often enough to make v4.17 hard to use, it does not permit
> reliable bisect.
>
> These should be bad according to my notes
>
> b04240a33b99b32cf6fbdf5c943c04e505a0cb07
> ed80dc19e4dd395c951f745acd1484d61c4cfb20
> 52113a0d3889d6e2738cf09bf79bc9cac7b5e1c6
> 4fc97ef94bbfa185d16b3e44199b7559d0668747
> 14ebdb2c814f508936fe178a2abc906a16a3ab48
> 639adbeef5ae1bb8eeebbb0cde0b885397bde192
>
> bisection claimed
>
> c16add24522547bf52c189b3c0d1ab6f5c2b4375
>
> is first bad commit, but I'm not sure if I trust that.
> Pavel
It has not happen on any of my systems in the last month. Good, but bad
for getting more info :-(
Woody
Hi!
> >I guess you can't reproduce it easily? I tried bisecting, but while it
> >happens often enough to make v4.17 hard to use, it does not permit
> >reliable bisect.
> >
> >These should be bad according to my notes
> >
> >b04240a33b99b32cf6fbdf5c943c04e505a0cb07
> > ed80dc19e4dd395c951f745acd1484d61c4cfb20
> > 52113a0d3889d6e2738cf09bf79bc9cac7b5e1c6
> > 4fc97ef94bbfa185d16b3e44199b7559d0668747
> > 14ebdb2c814f508936fe178a2abc906a16a3ab48
> > 639adbeef5ae1bb8eeebbb0cde0b885397bde192
> >
> >bisection claimed
> >
> >c16add24522547bf52c189b3c0d1ab6f5c2b4375
> >
> >is first bad commit, but I'm not sure if I trust that.
> > Pavel
> It has not happen on any of my systems in the last month. Good, but bad for
> getting more info :-(
My current theory is that it only happens if you suspend your machine
for > ten minutes, or something like that.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html