Re: Doesn't reconnect to wifi after resuming from suspend
poma wrote: > On 06.02.2015 18:42, Ferry Toth wrote: >> poma wrote: >> >>> On 05.02.2015 22:00, Ferry Toth wrote: poma wrote: > On 05.02.2015 20:12, Ferry Toth wrote: > >> Would that be after a certain kernel? But I used 14.04 with kernel >> 3.17 (no problem) and 14.10 with 3.17 (and now 3.18) >> > > See if it can help > https://wireless.wiki.kernel.org/en/users/drivers/ath9k/bugs Thanks by I don't find my case there. >>> >>> /etc/systemd/system/ath9k-reload.service >>> [Unit] >>> Description=Reload Atheros 802.11n wireless LAN cards driver >>> After=hibernate.target suspend.target hybrid-sleep.target >>> >>> [Service] >>> Type=oneshot >>> ExecStart=/usr/sbin/modprobe -r ath9k >>> ExecStart=/usr/sbin/modprobe ath9k >>> >>> [Install] >>> WantedBy=hibernate.target suspend.target hybrid-sleep.target >>> >>> >>> # systemctl enable ath9k-reload.service >>> >>> # systemctl suspend >>> & RESUME >>> >>> # systemctl hibernate >>> & THAW >>> >>> # systemctl hybrid-sleep >>> & RESUME||THAW >>> >>> >>> Does it work? >> >> Actually no, it doesn't. I already suspected that as I tried other >> similar (non-systemd) scripts that restart stuff on resume. >> >> With this script, it doesn't even autoreconnect on boot (which did work >> before). >> > > "After=hibernate.target suspend.target hybrid-sleep.target" > > As you can read, in the mechanism of ath9k-reload.service, it by any means > should not affect the Soft-Off/boot, but only Suspend-to-Disk/thaw and/or > Suspend-to-RAM/resume. > > >> I am starting to believe that after the drivers go up, an event scan is >> started, and the ath9k incorrectly reports that it is done (but might not >> be, as I have 2.4G and 5G and am trying to reconnect to the 5G). >> >> Just restarting drivers won't fix this (if it is indeed so). >> >> I need a delay after resume and scan, and before the autoconnect starts. >> >> >> BTW when I do: >> lsmod | grep ath >> >> ath9k 162133 0 >> ath9k_common 25638 1 ath9k >> ath9k_hw 460416 2 ath9k_common,ath9k >> ath29397 3 ath9k_common,ath9k,ath9k_hw >> mac80211 697212 1 ath9k >> ath3k 13381 0 >> cfg80211 520257 4 ath,ath9k_common,ath9k,mac80211 >> bluetooth 486890 7 bnep,ath3k,btusb,rfcomm >> > > > Rather than speculate, try to contact and consult with folks at > http://linuxwireless.sipsolutions.net/en/users/Drivers/ath9k/#Mailing_list > http://vger.kernel.org/vger-lists.html#linux-wireless > > Good luck Actually I'm not speculating, but hypothesizing. I tried manually connecting, but then as fast as possible after resume and I get the same problem as with autoconnect. So apparently, manual connect is working good, when attempted > 5 sec or after resume. This leads me to believe that 'something is busy' without networkmanager knowing it. A network scan is what comes to mind. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] build: install nm-settings-ifcfg-rh.5 man page conditionally
Am 09.02.2015 um 11:20 schrieb Lubomir Rintel: > Hi Michael, > > Thanks you for the patch. > > On Mon, 2015-02-09 at 01:31 +0100, Michael Biebl wrote: >> Only install nm-settings-ifcfg-rh.5 man page if the ifcfg-rh >> configuration plugin has been enabled. It's confusing to have this man >> page around on e.g. a Debian based distro. >> >> See attached patch. >> >> There might be small issue here, i.e. if you build the release tarball >> and you don't have ifcfg-rh enabled, then the nm-settings-ifcfg-rh.5 man >> page would be missing from the release tarball as it's not added to >> EXTRA_DIST >> >> If that is a concern, please let me know and I'll rework to the patch to >> always unconditionally build and dist the man pages, but only install >> them conditionally. > > The distribution tarball contents indeed should not depend on the > configuration configuration options. Please rework it the way you > suggest. On second thought, the pre-generated man pages are removed on "make clean", so the release tarball can't be built twice in a row. So I wonder if we should bother at all to ship pre-generated man pages. After all, xsltproc is not that an uncommon dependency. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] build: install nm-settings-ifcfg-rh.5 man page conditionally
Hi Michael, Thanks you for the patch. On Mon, 2015-02-09 at 01:31 +0100, Michael Biebl wrote: > Only install nm-settings-ifcfg-rh.5 man page if the ifcfg-rh > configuration plugin has been enabled. It's confusing to have this man > page around on e.g. a Debian based distro. > > See attached patch. > > There might be small issue here, i.e. if you build the release tarball > and you don't have ifcfg-rh enabled, then the nm-settings-ifcfg-rh.5 man > page would be missing from the release tarball as it's not added to > EXTRA_DIST > > If that is a concern, please let me know and I'll rework to the patch to > always unconditionally build and dist the man pages, but only install > them conditionally. The distribution tarball contents indeed should not depend on the configuration configuration options. Please rework it the way you suggest. Thank you, Lubo (By the way, the preferred way to submit patches by e-mail is inline as opposed to adding an attachment. git send-email makes that easy. Not a big deal really, especially for small patches, but it makes it a bit more convenient to quickly review and reply inline in some e-mail clients.) ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
