Announcement

Collapse
No announcement yet.

Second suspend-to-ram kills wifi

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Second suspend-to-ram kills wifi

    On Kubuntu 18.04 with 4.15.0-32-generic running an Intel Wireless 7265 with the iwlwifi driver (driverversion=4.15.0-32-generic), suspend-to-RAM followed by wakeup will kill wireless the second time. The first suspend/wakeup is OK, but the second time, the Networks box (from clicking the network icon on the toolbar) shows nothing, neither my router nor any other routers in my neighborhood.

    In the past, when I've had problems like this, I sometimes could get it to work by turning on airplane mode (in the Networks box) and turning it off again, or trying other controls in the Networks box. But nothing like this works anymore.

    Assuming this is some kind of driver issue and I need to wait for a fix, is there a quick workaround (short of rebooting) I can use in the meantime? For instance, I see a process:

    $ ps aux | grep wifi
    root 482 0.0 0.0 0 0 ? S 11:09 0:03 [irq/131-iwlwifi]

    Is there some kind of signal I can send to this process ("sudo kill SIGwhatever 482") or some other mechanism to reset the driver so it starts up again without having to reboot?
    Last edited by Mister Pi; Aug 30, 2018, 12:07 AM. Reason: Added information

    #2
    You can try KSysMonitor's PID listing and right mouse on that line. Then select the kill signal to send to it.
    Or, you can open a Konsole and use the kill command:
    sudo kill -9 482
    If you own the process then sudo is not necessary.
    Code:
    :~$ kill -l
     1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
     6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
    11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
    16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
    21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
    26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR
    31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3
    38) SIGRTMIN+4  39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8
    43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
    48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
    53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7
    58) SIGRTMAX-6  59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2
    63) SIGRTMAX-1  64) SIGRTMAX
    "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
    – John F. Kennedy, February 26, 1962.

    Comment


      #3
      Originally posted by GreyGeek View Post
      You can try KSysMonitor's PID listing and right mouse on that line. Then select the kill signal to send to it.
      I can get the PID from ps. The point is, which signal do I send? Various programs are coded to respond to signals in various ways, and some provide a way to restart or reset the program at some level by sending it a specific signal. But without knowing about the particular driver, how do I know which signal?

      Originally posted by GreyGeek View Post
      Or, you can open a Konsole and use the kill command:
      sudo kill -9 482
      Then how do I restart it? Or will the OS do that automatically?

      Comment


        #4
        BTW, I searched around and found some pages with other suggestions. Some of these are probably outdated (Ubuntu versions several years old), but anyway, I tried these and none of these worked:

        sudo service network-manager restart

        sudo systemctl restart NetworkManager

        sudo nmcli networking off
        sudo nmcli networking on

        sudo iwconfig wlp1s0 txpower off
        sudo iwconfig wlp1s0 txpower on

        nmcli radio wifi off
        nmcli radio wifi on

        sudo ifconfig wlp1s0 down
        sudo ifconfig wlp1s0 up

        For the last pair, the "up" command responded with

        SIOCSIFFLAGS: Input/output error

        I don't know if that means anything, but maybe it means the driver is broken at some deep level.

        (BTW, when the wifi is working properly, and I run the ifconfig command pair as shown, I don't get the error. After the first command, the wifi goes down, as expected. What is interesting is that if I click on the wifi icon in the toolbar, and get the Networks notification popup, all the other available wifi's in my neighborhood disappear, as expected. Yet it still shows my router and says it's connected, even after a minute. It seems not to recognize that the network is down. When I execute the "up" command, all the other wifi's appear again. Is this a bug in that program, or is it just understood that that tool is only an approximation?)
        Last edited by Mister Pi; Aug 30, 2018, 12:05 PM. Reason: Added information

        Comment


          #5
          Does rfkill show any blocks?

          Code:
          :~$ rfkill list
          0: hci0: Bluetooth
                  Soft blocked: no
                  Hard blocked: no
          1: phy0: Wireless LAN
                  Soft blocked: no
                  Hard blocked: no
          2: acer-wireless: Wireless LAN
                  Soft blocked: no
                  Hard blocked: no
          3: acer-bluetooth: Bluetooth
                  Soft blocked: no
                  Hard blocked: no
          "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
          – John F. Kennedy, February 26, 1962.

          Comment


            #6
            Originally posted by GreyGeek View Post
            Does rfkill show any blocks?
            Code:
            $ rfkill list
            0: hci0: Bluetooth
                   Soft blocked: no
                   Hard blocked: no
            1: phy0: Wireless LAN
                   Soft blocked: no
                   Hard blocked: no

            Comment


              #7
              It seems like this problem has disappeared. I noticed just before the kernel updated to 34 that it didn't seem to be happening anymore. The firmware on the driver hasn't been updated, so I'm not sure what was changed.

              Comment


                #8
                Another way that worked for me a time or two is to restart Network Manager with this command:
                Code:
                systemctl restart NetworkManager
                But I too found when the last kernel update happened the problem seems to have gone away.
                Dave Kubuntu 20.04 Registered Linux User #462608

                Wireless Script: http://ubuntuforums.org/showthread.p...5#post12350385

                Comment

                Working...
                X