Received: by 10.192.165.156 with SMTP id m28csp160202imm; Tue, 17 Apr 2018 08:06:05 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+MPUucNbwOeXch8FkdnMrVVCkg91QEsngBYM2y4qaJZxdg6/xRGsVaTDMV+sNFLgf2XPn4 X-Received: by 10.101.99.77 with SMTP id p13mr2126625pgv.307.1523977565600; Tue, 17 Apr 2018 08:06:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523977565; cv=none; d=google.com; s=arc-20160816; b=rljS/cP/Mi2H1VoX32GJ3/E0gxKOqSVfW+K0xqRoOfB2XLy3P231cbvnnlwqzwuVvK 55sacJia5bJDR7/BgMs9uOeheZ5MNxz7GIQZeCSL/mXe5iPKxdbn8eKWlAuoYjMl1cX8 CNmLktJwSqSCnEblDO4ginw2ATbtZQ+6naQnAFnDTbyYECrKZhK75e1KnRPRczXxhufZ SJodHYON8+68ApeldhKViFbAFME6Nd0tHN1kOhNMe6V5RFrHcnpKKxG1djdU4/MoS7dX a3V2JPxXeaNANOcita+sO8v9E/eoOG/iYUHRxchTT04by/8xBSi5lHxefrwFJJ/+qdjk /4ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :arc-authentication-results; bh=cE/T09M/effBCNL8k6CE1JxOFOgdp9YsWEJgBCNafFk=; b=WRguO+BnL8s+G/vEG1EKrVH/SadNQgPkURrjboVYqLdXyUxJsVS1FkpbPUMsx9Q9XW rpR5TozLHO4y3YuIcgyYsFs4QR93SxprJIirJf9RpK+uc+AiMsMjF/Gv+/LlBCcsLFZd z5qAW8Hx+NUZkC+B0wrPbVWi0f+W+cA/ojcoY/ou1h3GjB0Zbu+cNeDyysra7pmagksW /qRujPm+AVsrDjMnFQ17ByolYR8OYWRQqWousYzD6X6JE5AvpuK7GG1lwdOEmlibkT6C /Hyij47iIfUna6R+yycsdPGb35hKIY6TESPY6XsdDv8ky+97fYYdNGSmuYim4DNSAKq4 1nZg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a35-v6si14780711pli.71.2018.04.17.08.05.51; Tue, 17 Apr 2018 08:06:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752826AbeDQPEE (ORCPT + 99 others); Tue, 17 Apr 2018 11:04:04 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:59616 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751187AbeDQPEC (ORCPT ); Tue, 17 Apr 2018 11:04:02 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9B8014023112; Tue, 17 Apr 2018 15:04:01 +0000 (UTC) Received: from ovpn-112-35.rdu2.redhat.com (ovpn-112-35.rdu2.redhat.com [10.10.112.35]) by smtp.corp.redhat.com (Postfix) with ESMTP id A375310FFE6B; Tue, 17 Apr 2018 15:04:00 +0000 (UTC) Message-ID: <3ee2cc80d1ceeee472fe2f8392585e986620d5d9.camel@redhat.com> Subject: Re: linux-next on x60: network manager often complains "network is disabled" after resume From: Dan Williams To: Pavel Machek Cc: Woody Suwalski , "Rafael J. Wysocki" , kernel list , Linux-pm mailing list , Netdev list Date: Tue, 17 Apr 2018 10:03:59 -0500 In-Reply-To: <20180415161604.GG10802@amd> References: <20180318104023.GA10392@amd> <70721f83-344a-0f23-223b-9c81f6e9e32a@gmail.com> <20180319092106.GA5683@amd> <1521474008.20208.2.camel@redhat.com> <20180319173356.GA28462@amd> <1521481549.20208.8.camel@redhat.com> <20180320080334.GA31772@amd> <1521551568.16848.5.camel@redhat.com> <20180325061927.GA2148@amd> <95efbba35c3389015d4919a59f8d01bc2d375a19.camel@redhat.com> <20180415161604.GG10802@amd> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 17 Apr 2018 15:04:01 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 17 Apr 2018 15:04:01 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'dcbw@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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