New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RTL8188ce: frequent loss of connectivity, lts works #203

Closed
Soukyuu opened this Issue Jan 14, 2017 · 15 comments

Comments

Projects
None yet
3 participants
@Soukyuu

Soukyuu commented Jan 14, 2017

I'm using the arch linux's rtlwifi_new-dkms AUR package, but the same problem was present on stable modules as well. I'm currently using systemd-networkd systemd-resolved and wpa_supplicant. Before that, I was using NetworkManager. The behavior is essentially the same.

Pinging a remote server usually results in high packet loss:

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=8 ttl=50 time=44.5 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=50 time=1057 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=50 time=320 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=50 time=1054 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=50 time=1103 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=50 time=130 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=50 time=1278 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=50 time=279 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=50 time=130 ms
64 bytes from 8.8.8.8: icmp_seq=22 ttl=50 time=335 ms
64 bytes from 8.8.8.8: icmp_seq=23 ttl=50 time=131 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=50 time=278 ms

Pinging a local PC sometimes works fine and sometimes results in stuff like

PING 192.168.178.2 (192.168.178.2) 56(84) bytes of data.
64 bytes from 192.168.178.2: icmp_seq=1 ttl=64 time=102 ms
64 bytes from 192.168.178.2: icmp_seq=1 ttl=64 time=103 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=2 ttl=64 time=386 ms
64 bytes from 192.168.178.2: icmp_seq=2 ttl=64 time=386 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=3 ttl=64 time=3423 ms
64 bytes from 192.168.178.2: icmp_seq=3 ttl=64 time=3423 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=4 ttl=64 time=2407 ms
64 bytes from 192.168.178.2: icmp_seq=4 ttl=64 time=2407 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=5 ttl=64 time=1399 ms
64 bytes from 192.168.178.2: icmp_seq=5 ttl=64 time=1399 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=6 ttl=64 time=386 ms
64 bytes from 192.168.178.2: icmp_seq=6 ttl=64 time=386 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=7 ttl=64 time=103 ms
64 bytes from 192.168.178.2: icmp_seq=7 ttl=64 time=104 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=8 ttl=64 time=277 ms
64 bytes from 192.168.178.2: icmp_seq=8 ttl=64 time=585 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=9 ttl=64 time=106 ms
64 bytes from 192.168.178.2: icmp_seq=9 ttl=64 time=107 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=10 ttl=64 time=231 ms
64 bytes from 192.168.178.2: icmp_seq=10 ttl=64 time=424 ms (DUP!)
64 bytes from 192.168.178.2: icmp_seq=11 ttl=64 time=103 ms
64 bytes from 192.168.178.2: icmp_seq=11 ttl=64 time=103 ms (DUP!)

At other times there are no duplicate packets, but ping suddenly fluctuates between 2ms and 1000ms. A third failure pattern is that sometimes I suddenly start getting "Destination host unreachable" for about 10 seconds, then the connection comes back. Or sometimes does not, and I have to toggle wifi (rfkill) to make it work again. Once, dmsg showed an oops message as I mentioned in #201 , so maybe that is somehow related, as this happened right when I was starting to get timeouts again.

I have tried toggling power saving as well as software encoding, to no avail.

Is there any information I can provide to make this work?
On an otherwise good laptop, this is driving me insane. It works fine on Windows 10, btw.

@Soukyuu Soukyuu changed the title from RTL8192ce: frequent loss of connectivity to RTL8188ce: frequent loss of connectivity, lts works Jan 24, 2017

@Soukyuu

This comment has been minimized.

Show comment
Hide comment
@Soukyuu

Soukyuu Jan 24, 2017

So following a hint on the arch linux forums I tried the current lts kernel instead. The card works flawlessly. Seems like the newer versions introduced a regression.

Soukyuu commented Jan 24, 2017

So following a hint on the arch linux forums I tried the current lts kernel instead. The card works flawlessly. Seems like the newer versions introduced a regression.

@lwfinger

This comment has been minimized.

Show comment
Hide comment
@lwfinger

lwfinger Jan 25, 2017

Owner

Too bad no one ever does a bisection to see what, if any, regression there is. I do not see it.

Owner

lwfinger commented Jan 25, 2017

Too bad no one ever does a bisection to see what, if any, regression there is. I do not see it.

@Soukyuu

This comment has been minimized.

Show comment
Hide comment
@Soukyuu

Soukyuu Jan 25, 2017

Jumping between linux packages in the arch linux archive, it seems that the first version that causes high packet loss is 4.4.5. Does that help? I've only gotten this laptop recently, so I am late to the game, so to speak.

P.S.: I assume reporting it on the kernel bugzilla would just notify you, as well, and is thus redundant?

Soukyuu commented Jan 25, 2017

Jumping between linux packages in the arch linux archive, it seems that the first version that causes high packet loss is 4.4.5. Does that help? I've only gotten this laptop recently, so I am late to the game, so to speak.

P.S.: I assume reporting it on the kernel bugzilla would just notify you, as well, and is thus redundant?

@cnzhx

This comment has been minimized.

Show comment
Hide comment
@cnzhx

cnzhx Jan 28, 2017

I am new to this kind of thing. So please pardon me if I make a mistake here.

I think I have similar issue with this one. Network controller is Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01), with driver rtl8192ce.

The wireless network works very well before kernel version 4.9.0. However, after v4.9.0, the connection of this wireless card started to behaviour odd. From what I understand, the symptoms are,

  1. After updating to kernel 4.9.0, wifi connection works well in a very short time (about several minutes) after boot, then the system cannot connect to any website although the wireless connection seems fine from the indicator of NetworkManager in the systray area. However, the wireless signal indicator changes to full if not before the problem starts. And pinging any IP including local IPs will result in "Destination unreachable" error.
  2. To turn off wireless connection then turn it on from NetworkManager yields connection failure, throwing out message of IP configuration is unavailable.
  3. The wireless connection will connect and work for a very short while if I issue the following commands, sudo modprobe -r rtl8192ce && sudo modprobe rtl8192ce. I guess this is equivalent to a reboot for wireless card.
  4. Manually set rtl8192ce option fwlps to 0 (disabled) will bring the wireless connection to normal but the system will experience high latency and/or package loss when signal from AP is not so strong (e.g. less than 65%).
  5. Wireless connection works very well when installing and booting with kernel 4.8.14 with default options of the driver (meaning no need to set fwlps=0).
  6. Workaround mentioned in 4. works with kernel 4.9.3 and 4.9.4, but with kernel 4.9.0 and 4.9.5, this wireless connection works well when AP signal is strong but experiences high latency and/or package loss when AP signal is poor resulting a very bad connection speed from full bandwidth of the xDSL to only tens of KB/s.
  7. I installed wifi driver from the master branch here just now with kernel 4.9.5, the problem of high latency and/or package loss disappeared again (with fwlps=0 of course).

Hopefully these symptoms are helpful to find the culprit of this issue. Similar reports appear in [1] and [2]:
[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1017471
[2] https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1415339

cnzhx commented Jan 28, 2017

I am new to this kind of thing. So please pardon me if I make a mistake here.

I think I have similar issue with this one. Network controller is Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01), with driver rtl8192ce.

The wireless network works very well before kernel version 4.9.0. However, after v4.9.0, the connection of this wireless card started to behaviour odd. From what I understand, the symptoms are,

  1. After updating to kernel 4.9.0, wifi connection works well in a very short time (about several minutes) after boot, then the system cannot connect to any website although the wireless connection seems fine from the indicator of NetworkManager in the systray area. However, the wireless signal indicator changes to full if not before the problem starts. And pinging any IP including local IPs will result in "Destination unreachable" error.
  2. To turn off wireless connection then turn it on from NetworkManager yields connection failure, throwing out message of IP configuration is unavailable.
  3. The wireless connection will connect and work for a very short while if I issue the following commands, sudo modprobe -r rtl8192ce && sudo modprobe rtl8192ce. I guess this is equivalent to a reboot for wireless card.
  4. Manually set rtl8192ce option fwlps to 0 (disabled) will bring the wireless connection to normal but the system will experience high latency and/or package loss when signal from AP is not so strong (e.g. less than 65%).
  5. Wireless connection works very well when installing and booting with kernel 4.8.14 with default options of the driver (meaning no need to set fwlps=0).
  6. Workaround mentioned in 4. works with kernel 4.9.3 and 4.9.4, but with kernel 4.9.0 and 4.9.5, this wireless connection works well when AP signal is strong but experiences high latency and/or package loss when AP signal is poor resulting a very bad connection speed from full bandwidth of the xDSL to only tens of KB/s.
  7. I installed wifi driver from the master branch here just now with kernel 4.9.5, the problem of high latency and/or package loss disappeared again (with fwlps=0 of course).

Hopefully these symptoms are helpful to find the culprit of this issue. Similar reports appear in [1] and [2]:
[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1017471
[2] https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1415339

@lwfinger

This comment has been minimized.

Show comment
Hide comment
@lwfinger

lwfinger Jan 28, 2017

Owner

There was a problem with power save, but it was fixed in kernel 4.9.4. The workaround for that problem was to use the option "ips=0". To my knowledge, despite what has been posted, no other combination of any of the "ps" options has ever worked, or even made sense. As the basic power-save mechanism was broken, it made little sense whether software or firmware controlled it. The only fix was to disable it completely, which is what ips=0 does.

I do not run TumbleWeed, thus I have not used the official 4.9.5 kernels, but as I said in the bugzilla entry, I have run the mainline kernels up to my current version of 4.10-rc5. Using that kernel, and the master branch of this repo, I just ran 2000 pings with 0 losses. The maximum return time was 175 msec. My base system is a fully-patched Leap 42.2 KDE. A scan with iw shows my signal strength at -58 dBm.

Owner

lwfinger commented Jan 28, 2017

There was a problem with power save, but it was fixed in kernel 4.9.4. The workaround for that problem was to use the option "ips=0". To my knowledge, despite what has been posted, no other combination of any of the "ps" options has ever worked, or even made sense. As the basic power-save mechanism was broken, it made little sense whether software or firmware controlled it. The only fix was to disable it completely, which is what ips=0 does.

I do not run TumbleWeed, thus I have not used the official 4.9.5 kernels, but as I said in the bugzilla entry, I have run the mainline kernels up to my current version of 4.10-rc5. Using that kernel, and the master branch of this repo, I just ran 2000 pings with 0 losses. The maximum return time was 175 msec. My base system is a fully-patched Leap 42.2 KDE. A scan with iw shows my signal strength at -58 dBm.

@cnzhx

This comment has been minimized.

Show comment
Hide comment
@cnzhx

cnzhx Jan 28, 2017

IIRC, the default options are ips=1 fwlps=1 swlps=0. Does it mean that if fwlps is set to 0, then all lpss are disabled resulting an effectively inactive ips? For my case, if I set only fwlps=0, the wireless can work fine when signal strength is not so weak. (But I have no specific values.)

But with kernel 4.9.5, my wireless network could even have problem when fwlps=0 is set. And the driver from here makes it better. However, I cannot get my wireless working as well as before kernel 4.9.0. Back then, with kernel 4.8.14 and before, I had never experienced any problem with my wireless card.

Although I am using TW, but I am not an power user and have not tinkled with the system.

After reading your comment, I did the following tries. With all custom options in a file /etc/modprobe.d/rtl8192ce.conf created by myself (I do not know where are the default values set).

  1. Driver from master branch with kernel 4.9.5.

sudo modinfo rtl8192ce | grep srcversion srcversion: AF7B0DC7BE4DAC4E0F1759F

1.1. All options are default.

  • ping 192.168.1.1 returns little latency and no package loss
  • After around 1 minute, ping 192.168.1.1 returns Destination Host Unreachable.

1.2. Option ips=0 (keeping default fwlps=1).

  • sudo vim /etc/modprobe.d/rtl8192ce.conf and set only ips=0;
  • Reboot for sure
    Then I have no connection after login. ping 192.168.1.1 returns Destination Host Unreachable.

1.3. Options fwlps=0 (keeping default ips=1)

  • sudo vim /etc/modprobe.d/rtl8192ce.conf and set only fwlps=0 (ips=0 is commented out);
  • sudo modprobe -r rtl8192ce
  • sudo modprobe rtl8192ce
    Then the wireless connection resumed automatically. 1000 pings to the router (192.168.1.1) shows,
    --- 192.168.1.1 ping statistics --- 1000 packets transmitted, 1000 received, 0% packet loss, time 1000689ms rtt min/avg/max/mdev = 0.789/6.498/344.700/20.965 ms
    This looks quite well to me.
  1. Driver from kernel 4.9.5 and with kernel 4.9.5.

I replaced the driver folder in /lib/modules/$(uname -r)/kernel/drivers/net/wireless/realtek with backup and reload the module rtl8192ce.
srcversion: 2342051B3DB62D6CF069F77

2.1. Options fwlps=0 (keeping default ips=1)

  • sudo vim /etc/modprobe.d/rtl8192ce.conf and set only fwlps=0 (ips=0 is commented out);
  • sudo modprobe -r rtl8192ce
  • sudo modprobe rtl8192ce
    Then the wireless connection resumed automatically. 1000 pings to the router (192.168.1.1) shows
    --- 192.168.1.1 ping statistics --- 1000 packets transmitted, 937 received, 6% packet loss, time 1001478ms rtt min/avg/max/mdev = 0.864/85.821/2521.686/244.881 ms, pipe 3
    This time, it looks better than the time I just updated the snapshot of TW with kernel 4.9.5. And another run gets,
    --- 192.168.1.1 ping statistics --- 1000 packets transmitted, 654 received, 34% packet loss, time 1007695ms rtt min/avg/max/mdev = 0.830/496.388/3701.599/647.471 ms, pipe 4

2.2. Option ips=0 (keeping default fwlps=1).

  • sudo vim /etc/modprobe.d/rtl8192ce.conf and set only ips=0;
  • sudo modprobe -r rtl8192ce
  • sudo modprobe rtl8192ce
    1000 pings to the router (192.168.1.1) shows,
    --- 192.168.1.1 ping statistics --- 1000 packets transmitted, 663 received, 33% packet loss, time 1007384ms rtt min/avg/max/mdev = 0.886/475.683/3781.237/637.294 ms, pipe 4
    2.3. All options are default.
  • ping 192.168.1.1 returns,
    --- 192.168.1.1 ping statistics --- 1000 packets transmitted, 653 received, 34% packet loss, time 1008099ms rtt min/avg/max/mdev = 0.865/439.983/10596.736/763.726 ms, pipe 11
    But I don't know how to check the right signal strength. sudo iw wlp3s0 scan | grep signal returns,
    signal: -54.00 dBm
    signal: -80.00 dBm
    signal: -64.00 dBm
    signal: -80.00 dBm
    signal: -84.00 dBm
    signal: -50.00 dBm
    signal: -72.00 dBm
    signal: -78.00 dBm
    NetworkManager systray icon shows the signal strength is between 63% to 70%.

cnzhx commented Jan 28, 2017

IIRC, the default options are ips=1 fwlps=1 swlps=0. Does it mean that if fwlps is set to 0, then all lpss are disabled resulting an effectively inactive ips? For my case, if I set only fwlps=0, the wireless can work fine when signal strength is not so weak. (But I have no specific values.)

But with kernel 4.9.5, my wireless network could even have problem when fwlps=0 is set. And the driver from here makes it better. However, I cannot get my wireless working as well as before kernel 4.9.0. Back then, with kernel 4.8.14 and before, I had never experienced any problem with my wireless card.

Although I am using TW, but I am not an power user and have not tinkled with the system.

After reading your comment, I did the following tries. With all custom options in a file /etc/modprobe.d/rtl8192ce.conf created by myself (I do not know where are the default values set).

  1. Driver from master branch with kernel 4.9.5.

sudo modinfo rtl8192ce | grep srcversion srcversion: AF7B0DC7BE4DAC4E0F1759F

1.1. All options are default.

  • ping 192.168.1.1 returns little latency and no package loss
  • After around 1 minute, ping 192.168.1.1 returns Destination Host Unreachable.

1.2. Option ips=0 (keeping default fwlps=1).

  • sudo vim /etc/modprobe.d/rtl8192ce.conf and set only ips=0;
  • Reboot for sure
    Then I have no connection after login. ping 192.168.1.1 returns Destination Host Unreachable.

1.3. Options fwlps=0 (keeping default ips=1)

  • sudo vim /etc/modprobe.d/rtl8192ce.conf and set only fwlps=0 (ips=0 is commented out);
  • sudo modprobe -r rtl8192ce
  • sudo modprobe rtl8192ce
    Then the wireless connection resumed automatically. 1000 pings to the router (192.168.1.1) shows,
    --- 192.168.1.1 ping statistics --- 1000 packets transmitted, 1000 received, 0% packet loss, time 1000689ms rtt min/avg/max/mdev = 0.789/6.498/344.700/20.965 ms
    This looks quite well to me.
  1. Driver from kernel 4.9.5 and with kernel 4.9.5.

I replaced the driver folder in /lib/modules/$(uname -r)/kernel/drivers/net/wireless/realtek with backup and reload the module rtl8192ce.
srcversion: 2342051B3DB62D6CF069F77

2.1. Options fwlps=0 (keeping default ips=1)

  • sudo vim /etc/modprobe.d/rtl8192ce.conf and set only fwlps=0 (ips=0 is commented out);
  • sudo modprobe -r rtl8192ce
  • sudo modprobe rtl8192ce
    Then the wireless connection resumed automatically. 1000 pings to the router (192.168.1.1) shows
    --- 192.168.1.1 ping statistics --- 1000 packets transmitted, 937 received, 6% packet loss, time 1001478ms rtt min/avg/max/mdev = 0.864/85.821/2521.686/244.881 ms, pipe 3
    This time, it looks better than the time I just updated the snapshot of TW with kernel 4.9.5. And another run gets,
    --- 192.168.1.1 ping statistics --- 1000 packets transmitted, 654 received, 34% packet loss, time 1007695ms rtt min/avg/max/mdev = 0.830/496.388/3701.599/647.471 ms, pipe 4

2.2. Option ips=0 (keeping default fwlps=1).

  • sudo vim /etc/modprobe.d/rtl8192ce.conf and set only ips=0;
  • sudo modprobe -r rtl8192ce
  • sudo modprobe rtl8192ce
    1000 pings to the router (192.168.1.1) shows,
    --- 192.168.1.1 ping statistics --- 1000 packets transmitted, 663 received, 33% packet loss, time 1007384ms rtt min/avg/max/mdev = 0.886/475.683/3781.237/637.294 ms, pipe 4
    2.3. All options are default.
  • ping 192.168.1.1 returns,
    --- 192.168.1.1 ping statistics --- 1000 packets transmitted, 653 received, 34% packet loss, time 1008099ms rtt min/avg/max/mdev = 0.865/439.983/10596.736/763.726 ms, pipe 11
    But I don't know how to check the right signal strength. sudo iw wlp3s0 scan | grep signal returns,
    signal: -54.00 dBm
    signal: -80.00 dBm
    signal: -64.00 dBm
    signal: -80.00 dBm
    signal: -84.00 dBm
    signal: -50.00 dBm
    signal: -72.00 dBm
    signal: -78.00 dBm
    NetworkManager systray icon shows the signal strength is between 63% to 70%.
@lwfinger

This comment has been minimized.

Show comment
Hide comment
@lwfinger

lwfinger Jan 29, 2017

Owner

Use sudo iw wlp3s0 scan | egrep "signal|SSID". That way the SSID will be listed on the line following the signal. Your AP is likely either -50 or -54 dBm.

The default options are built into the driver. I do not know whether the driver uses firmware or software power save if ips=1 and fwlps=0; however, I do know that power save is enabled, AND that means that kernels between 4.9.0 and 4.9.3 will NOT work correctly, unless ips=0.

I have no idea why your system fails. I have been running the master branch of this repo for nearly 9 hours without a single loss of connection. The work load during this time has been normal web browsing. E-mail downloads, and zypper updates of my main Leap 42.2 system as well as two TW virtual machines. During the update, the downloads reached as high as 4 MB/s.

Have you done a recent pull of this repo? If so, I cannot duplicate your results, which means I have no possibility of debugging your failure. I have the openSUSE kernel git repo on my system, and I am currently building a 4.9.0 kernel from that source. I will test it with ips=0 to see if it works here. As soon as I have run that test, I will report my results.

Owner

lwfinger commented Jan 29, 2017

Use sudo iw wlp3s0 scan | egrep "signal|SSID". That way the SSID will be listed on the line following the signal. Your AP is likely either -50 or -54 dBm.

The default options are built into the driver. I do not know whether the driver uses firmware or software power save if ips=1 and fwlps=0; however, I do know that power save is enabled, AND that means that kernels between 4.9.0 and 4.9.3 will NOT work correctly, unless ips=0.

I have no idea why your system fails. I have been running the master branch of this repo for nearly 9 hours without a single loss of connection. The work load during this time has been normal web browsing. E-mail downloads, and zypper updates of my main Leap 42.2 system as well as two TW virtual machines. During the update, the downloads reached as high as 4 MB/s.

Have you done a recent pull of this repo? If so, I cannot duplicate your results, which means I have no possibility of debugging your failure. I have the openSUSE kernel git repo on my system, and I am currently building a 4.9.0 kernel from that source. I will test it with ips=0 to see if it works here. As soon as I have run that test, I will report my results.

@cnzhx

This comment has been minimized.

Show comment
Hide comment
@cnzhx

cnzhx Jan 29, 2017

Yes, you're right. My signal strength is around -53dBm. Based on my experience, I think the signal strength matters a lot in this issue. I encounter the problem only when signal is not so strong with the same configuration. It seems the marginal value is about -53dBm.

I changed the option to ips=0 yielding
Parameters: debug = "0" fwlps = "Y" ips = "N" swenc = "N" swlps = "N"
And tried to ping the router just now with the master branch driver of this repo and the same relative distance to the router getting a good result,
1000 packets transmitted, 1000 received, 0% packet loss, time 1000512ms rtt min/avg/max/mdev = 0.967/12.317/458.860/24.638 ms
This is opposite to the result of yesterday with only ips=0. So I guess whether 'ips=0orfwlps=0` does the trick. The only strange thing to me is that all things go well before kernel 4.9.0 and not stable/constant after that.

As you said the problem was fixed in kernel 4.9.3. Do you mean that no need to set 'ips=0orfwlps=0`? And for me, from kernel 4.9.3 to 4.9.4 and 4.9.5, the experiences are not the same. Especially, with kernel 4.9.5, I have to change to the master branch of this repo to make my wireless work fine.

The master branch of this repo works for me as well. But I need to set extra option as fwlps=0. Otherwise, it does not work well. I only learnt to use this repo yesterday, and I downloaded it using link "https://codeload.github.com/lwfinger/rtlwifi_new/tar.gz/master" about 22 hours ago.

I do not know much about this stuff. So if you need any information, please ask for it directly.

cnzhx commented Jan 29, 2017

Yes, you're right. My signal strength is around -53dBm. Based on my experience, I think the signal strength matters a lot in this issue. I encounter the problem only when signal is not so strong with the same configuration. It seems the marginal value is about -53dBm.

I changed the option to ips=0 yielding
Parameters: debug = "0" fwlps = "Y" ips = "N" swenc = "N" swlps = "N"
And tried to ping the router just now with the master branch driver of this repo and the same relative distance to the router getting a good result,
1000 packets transmitted, 1000 received, 0% packet loss, time 1000512ms rtt min/avg/max/mdev = 0.967/12.317/458.860/24.638 ms
This is opposite to the result of yesterday with only ips=0. So I guess whether 'ips=0orfwlps=0` does the trick. The only strange thing to me is that all things go well before kernel 4.9.0 and not stable/constant after that.

As you said the problem was fixed in kernel 4.9.3. Do you mean that no need to set 'ips=0orfwlps=0`? And for me, from kernel 4.9.3 to 4.9.4 and 4.9.5, the experiences are not the same. Especially, with kernel 4.9.5, I have to change to the master branch of this repo to make my wireless work fine.

The master branch of this repo works for me as well. But I need to set extra option as fwlps=0. Otherwise, it does not work well. I only learnt to use this repo yesterday, and I downloaded it using link "https://codeload.github.com/lwfinger/rtlwifi_new/tar.gz/master" about 22 hours ago.

I do not know much about this stuff. So if you need any information, please ask for it directly.

@Soukyuu

This comment has been minimized.

Show comment
Hide comment
@Soukyuu

Soukyuu Jan 29, 2017

Well, it's not signal strength in my case. sudo iw wlp3s0 scan | egrep "signal|SSID" gives
signal: -21.00 dBm

Device ID is:

03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter [10ec:8176] (rev 01)

On current lts, systool gives the following default configuration:

Module = "rtl8192ce"

Parameters:
    debug               = "0"
    fwlps               = "Y"
    ips                 = "Y"
    swenc               = "N"
    swlps               = "N"

This is the same configuration as is displayed with the freshly updated 4.9.6. The connection is as unstable as it was on 4.8.13, though. I will try messing with ips/fwlps options, but I don't think that's it.

Soukyuu commented Jan 29, 2017

Well, it's not signal strength in my case. sudo iw wlp3s0 scan | egrep "signal|SSID" gives
signal: -21.00 dBm

Device ID is:

03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter [10ec:8176] (rev 01)

On current lts, systool gives the following default configuration:

Module = "rtl8192ce"

Parameters:
    debug               = "0"
    fwlps               = "Y"
    ips                 = "Y"
    swenc               = "N"
    swlps               = "N"

This is the same configuration as is displayed with the freshly updated 4.9.6. The connection is as unstable as it was on 4.8.13, though. I will try messing with ips/fwlps options, but I don't think that's it.

@Soukyuu

This comment has been minimized.

Show comment
Hide comment
@Soukyuu

Soukyuu Jan 29, 2017

Running 4.9.6 with

Module = "rtl8192ce"

Parameters:
    debug               = "0"
    fwlps               = "Y"
    ips                 = "N"
    swenc               = "N"
    swlps               = "N"

results in 8 working pings, followed by 100% packet loss.

Running 4.9.6 with

Module = "rtl8192ce"

Parameters:
    debug               = "0"
    fwlps               = "N"
    ips                 = "Y"
    swenc               = "N"
    swlps               = "N" 

works fine so far. Low ping, no packet loss. I tried moving between floors (I have a repeater on each of them) and there were some packet lost when moving from one station to another, but the connection did not die.

So maybe it's the fwlps option that's causing issues now. On 4.8.13, even setting fwlps/ips to 0 didn't help, though.

Soukyuu commented Jan 29, 2017

Running 4.9.6 with

Module = "rtl8192ce"

Parameters:
    debug               = "0"
    fwlps               = "Y"
    ips                 = "N"
    swenc               = "N"
    swlps               = "N"

results in 8 working pings, followed by 100% packet loss.

Running 4.9.6 with

Module = "rtl8192ce"

Parameters:
    debug               = "0"
    fwlps               = "N"
    ips                 = "Y"
    swenc               = "N"
    swlps               = "N" 

works fine so far. Low ping, no packet loss. I tried moving between floors (I have a repeater on each of them) and there were some packet lost when moving from one station to another, but the connection did not die.

So maybe it's the fwlps option that's causing issues now. On 4.8.13, even setting fwlps/ips to 0 didn't help, though.

@lwfinger

This comment has been minimized.

Show comment
Hide comment
@lwfinger

lwfinger Jan 29, 2017

Owner

First of all, the default options have not changed in a long time, thus systool or modinfo will give the same result no matter what version you are running. It was the underlying code that changed. As I said before, there was a BUG in that code that caused failures in the power-save function for kernels before version 4.9.4. The problem showed up as lond as ips was not zero. Period! The bug was introduced in 4.9.0, but some distros backport changes and you may see it earlier. In any case, you need to set "ips=0". No other fix will do. This repo does contain that fix and a bunch of other changes - it is essentially the code from kernel 4.10-rc5.

My experience is that signal strengths of -58 dBm or higher work OK.

Owner

lwfinger commented Jan 29, 2017

First of all, the default options have not changed in a long time, thus systool or modinfo will give the same result no matter what version you are running. It was the underlying code that changed. As I said before, there was a BUG in that code that caused failures in the power-save function for kernels before version 4.9.4. The problem showed up as lond as ips was not zero. Period! The bug was introduced in 4.9.0, but some distros backport changes and you may see it earlier. In any case, you need to set "ips=0". No other fix will do. This repo does contain that fix and a bunch of other changes - it is essentially the code from kernel 4.10-rc5.

My experience is that signal strengths of -58 dBm or higher work OK.

@lwfinger

This comment has been minimized.

Show comment
Hide comment
@lwfinger

lwfinger Jan 30, 2017

Owner

I just got mail from a Debian user who reported and fixed a problem that caused the wrong firmware to be loaded for some models of the RTL81{88,92}CE. As it happens, my test chip is not affected, thus I did not see the problem. That likely explains why I could not reproduce the problem.

A fix has been prepared and was pushed a few minutes ago into the master branch. I will also push the fix to mainline, but that may take some time to propagate through the system.

Owner

lwfinger commented Jan 30, 2017

I just got mail from a Debian user who reported and fixed a problem that caused the wrong firmware to be loaded for some models of the RTL81{88,92}CE. As it happens, my test chip is not affected, thus I did not see the problem. That likely explains why I could not reproduce the problem.

A fix has been prepared and was pushed a few minutes ago into the master branch. I will also push the fix to mainline, but that may take some time to propagate through the system.

@cnzhx

This comment has been minimized.

Show comment
Hide comment
@cnzhx

cnzhx Jan 30, 2017

Yes, this new master branch works for me now. Tested with the default parameters on kernel 4.9.5 in openSUSE Tumbleweed in my work place.

P.S. Could you please tell me how to check which firmware is loaded?

cnzhx commented Jan 30, 2017

Yes, this new master branch works for me now. Tested with the default parameters on kernel 4.9.5 in openSUSE Tumbleweed in my work place.

P.S. Could you please tell me how to check which firmware is loaded?

@lwfinger

This comment has been minimized.

Show comment
Hide comment
@lwfinger

lwfinger Jan 30, 2017

Owner

It is logged in the dmesg output.

Owner

lwfinger commented Jan 30, 2017

It is logged in the dmesg output.

@lwfinger lwfinger closed this Jan 30, 2017

fengguang added a commit to 0day-ci/linux that referenced this issue Jan 30, 2017

rtlwifi: rtl8192ce: Fix loading of incorrect firmware
In commit cf4747d ("rtlwifi: Fix regression caused by commit
d86e647, an error in the edit results in the wrong firmware
being loaded for some models of the RTL8188/8192CE. In this condition,
the connection suffered from high ping latency, slow transfer rates,
 and required higher signal strengths to work at all

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853073,
https://bugzilla.opensuse.org/show_bug.cgi?id=1017471, and
lwfinger/rtlwifi_new#203 for descriptions
of the problems. This patch fixes all of those problems.

Fixes: cf4747d ("rtlwifi: Fix regression caused by commit d86e647")
Signed-off-by: Jurij Smakov <jurij@wooyd.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> # 4.9+

fengguang added a commit to 0day-ci/linux that referenced this issue Jan 30, 2017

rtlwifi: rtl8192ce: Fix loading of incorrect firmware
In commit cf4747d ("rtlwifi: Fix regression caused by commit
d86e647, an error in the edit results in the wrong firmware
being loaded for some models of the RTL8188/8192CE. In this condition,
the connection suffered from high ping latency, slow transfer rates,
 and required higher signal strengths to work at all

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853073,
https://bugzilla.opensuse.org/show_bug.cgi?id=1017471, and
lwfinger/rtlwifi_new#203 for descriptions
of the problems. This patch fixes all of those problems.

Fixes: cf4747d ("rtlwifi: Fix regression caused by commit d86e647")
Signed-off-by: Jurij Smakov <jurij@wooyd.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> # 4.9+

sudipm-mukherjee pushed a commit to sudipm-mukherjee/parport that referenced this issue Feb 1, 2017

rtlwifi: rtl8192ce: Fix loading of incorrect firmware
In commit cf4747d ("rtlwifi: Fix regression caused by commit
d86e647, an error in the edit results in the wrong firmware
being loaded for some models of the RTL8188/8192CE. In this condition,
the connection suffered from high ping latency, slow transfer rates,
 and required higher signal strengths to work at all

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853073,
https://bugzilla.opensuse.org/show_bug.cgi?id=1017471, and
lwfinger/rtlwifi_new#203 for descriptions
of the problems. This patch fixes all of those problems.

Fixes: cf4747d ("rtlwifi: Fix regression caused by commit d86e647")
Signed-off-by: Jurij Smakov <jurij@wooyd.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> # 4.9+
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
@Soukyuu

This comment has been minimized.

Show comment
Hide comment
@Soukyuu

Soukyuu Feb 4, 2017

This seems to be what was causing the issue. After building the aur package with the current rtlwifi_new master, the card works fine with default module options - many thanks for fixing this.

Soukyuu commented Feb 4, 2017

This seems to be what was causing the issue. After building the aur package with the current rtlwifi_new master, the card works fine with default module options - many thanks for fixing this.

fengguang pushed a commit to 0day-ci/linux that referenced this issue Feb 8, 2017

origin
GIT 926af6273fc683cd98cd0ce7bf0d04a02eed6742

commit b6789123bccba8b5feb9901ed2e8c3c39181979d
Author: Hugh Dickins <hughd@google.com>
Date:   Tue Feb 7 11:11:16 2017 -0800

    mm: fix KPF_SWAPCACHE in /proc/kpageflags
    
    Commit 6326fec1122c ("mm: Use owner_priv bit for PageSwapCache, valid
    when PageSwapBacked") aliased PG_swapcache to PG_owner_priv_1 (and
    depending on PageSwapBacked being true).
    
    As a result, the KPF_SWAPCACHE bit in '/proc/kpageflags' should now be
    synthesized, instead of being shown on unrelated pages which just happen
    to have PG_owner_priv_1 set.
    
    Signed-off-by: Hugh Dickins <hughd@google.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Nicholas Piggin <npiggin@gmail.com>
    Cc: Wu Fengguang <fengguang.wu@intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 912964eacb111551db73429719eb5fadcab0ff8a
Author: Xin Long <lucien.xin@gmail.com>
Date:   Tue Feb 7 20:56:08 2017 +0800

    sctp: check af before verify address in sctp_addr_id2transport
    
    Commit 6f29a1306131 ("sctp: sctp_addr_id2transport should verify the
    addr before looking up assoc") invoked sctp_verify_addr to verify the
    addr.
    
    But it didn't check af variable beforehand, once users pass an address
    with family = 0 through sockopt, sctp_get_af_specific will return NULL
    and NULL pointer dereference will be caused by af->sockaddr_len.
    
    This patch is to fix it by returning NULL if af variable is NULL.
    
    Fixes: 6f29a1306131 ("sctp: sctp_addr_id2transport should verify the addr before looking up assoc")
    Signed-off-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit a524c218bc94c705886a0e0fedeee45d1931da32
Author: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Date:   Tue Feb 7 09:44:58 2017 -0800

    ARC: [arcompact] brown paper bag bug in unaligned access delay slot fixup
    
    Reported-by: Jo-Philipp Wich <jo@mein.io>
    Fixes: 9aed02feae57bf7 ("ARC: [arcompact] handle unaligned access delay slot")
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-snps-arc@lists.infradead.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 2dcab598484185dea7ec22219c76dcdd59e3cb90
Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date:   Mon Feb 6 18:10:31 2017 -0200

    sctp: avoid BUG_ON on sctp_wait_for_sndbuf
    
    Alexander Popov reported that an application may trigger a BUG_ON in
    sctp_wait_for_sndbuf if the socket tx buffer is full, a thread is
    waiting on it to queue more data and meanwhile another thread peels off
    the association being used by the first thread.
    
    This patch replaces the BUG_ON call with a proper error handling. It
    will return -EPIPE to the original sendmsg call, similarly to what would
    have been done if the association wasn't found in the first place.
    
    Acked-by: Alexander Popov <alex.popov@linux.com>
    Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
    Reviewed-by: Xin Long <lucien.xin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit bd4ce941c8d5b862b2f83364be5dbe8fc8ab48f8
Author: Benjamin Poirier <bpoirier@suse.com>
Date:   Mon Feb 6 10:14:31 2017 -0800

    mlx4: Invoke softirqs after napi_reschedule
    
    mlx4 may schedule napi from a workqueue. Afterwards, softirqs are not run
    in a deterministic time frame and the following message may be logged:
    NOHZ: local_softirq_pending 08
    
    The problem is the same as what was described in commit ec13ee80145c
    ("virtio_net: invoke softirqs after __napi_schedule") and this patch
    applies the same fix to mlx4.
    
    Fixes: 07841f9d94c1 ("net/mlx4_en: Schedule napi when RX buffers allocation fails")
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 69629464e0b587f3711739b3aa2bcdaf2e075276
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Feb 5 09:25:24 2017 -0800

    udp: properly cope with csum errors
    
    Dmitry reported that UDP sockets being destroyed would trigger the
    WARN_ON(atomic_read(&sk->sk_rmem_alloc)); in inet_sock_destruct()
    
    It turns out we do not properly destroy skb(s) that have wrong UDP
    checksum.
    
    Thanks again to syzkaller team.
    
    Fixes : 7c13f97ffde6 ("udp: do fwd memory scheduling on dequeue")
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Paolo Abeni <pabeni@redhat.com>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 2d6a0e9de03ee658a9adc3bfb2f0ca55dff1e478
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sat Feb 4 16:57:04 2017 +0000

    catc: Use heap buffer for memory size test
    
    Allocating USB buffers on the stack is not portable, and no longer
    works on x86_64 (with VMAP_STACK enabled as per default).
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit d41149145f98fe26dcd0bfd1d6cc095e6e041418
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sat Feb 4 16:56:56 2017 +0000

    catc: Combine failure cleanup code in catc_probe()
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 7926aff5c57b577ab0f43364ff0c59d968f6a414
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sat Feb 4 16:56:32 2017 +0000

    rtl8150: Use heap buffers for all register access
    
    Allocating USB buffers on the stack is not portable, and no longer
    works on x86_64 (with VMAP_STACK enabled as per default).
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 5593523f968bc86d42a035c6df47d5e0979b5ace
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sat Feb 4 16:56:03 2017 +0000

    pegasus: Use heap buffers for all register access
    
    Allocating USB buffers on the stack is not portable, and no longer
    works on x86_64 (with VMAP_STACK enabled as per default).
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    References: https://bugs.debian.org/852556
    Reported-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
    Tested-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 837585a5375c38d40361cfe64e6fd11e1addb936
Author: Willem de Bruijn <willemb@google.com>
Date:   Fri Feb 3 18:20:49 2017 -0500

    macvtap: read vnet_hdr_size once
    
    When IFF_VNET_HDR is enabled, a virtio_net header must precede data.
    Data length is verified to be greater than or equal to expected header
    length tun->vnet_hdr_sz before copying.
    
    Macvtap functions read the value once, but unless READ_ONCE is used,
    the compiler may ignore this and read multiple times. Enforce a single
    read and locally cached value to avoid updates between test and use.
    
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Suggested-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit e1edab87faf6ca30cd137e0795bc73aa9a9a22ec
Author: Willem de Bruijn <willemb@google.com>
Date:   Fri Feb 3 18:20:48 2017 -0500

    tun: read vnet_hdr_sz once
    
    When IFF_VNET_HDR is enabled, a virtio_net header must precede data.
    Data length is verified to be greater than or equal to expected header
    length tun->vnet_hdr_sz before copying.
    
    Read this value once and cache locally, as it can be updated between
    the test and use (TOCTOU).
    
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    CC: Eric Dumazet <edumazet@google.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit ccf7abb93af09ad0868ae9033d1ca8108bdaec82
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 3 14:59:38 2017 -0800

    tcp: avoid infinite loop in tcp_splice_read()
    
    Splicing from TCP socket is vulnerable when a packet with URG flag is
    received and stored into receive queue.
    
    __tcp_splice_read() returns 0, and sk_wait_data() immediately
    returns since there is the problematic skb in queue.
    
    This is a nice way to burn cpu (aka infinite loop) and trigger
    soft lockups.
    
    Again, this gem was found by syzkaller tool.
    
    Fixes: 9c55e01c0cc8 ("[TCP]: Splice receive support.")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Dmitry Vyukov  <dvyukov@google.com>
    Cc: Willy Tarreau <w@1wt.eu>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit b3f2d07f4649adcf6905953a10d217b5683e4077
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Feb 3 17:35:46 2017 +0100

    hns: avoid stack overflow with CONFIG_KASAN
    
    The use of ACCESS_ONCE() looks like a micro-optimization to force gcc to use
    an indexed load for the register address, but it has an absolutely detrimental
    effect on builds with gcc-5 and CONFIG_KASAN=y, leading to a very likely
    kernel stack overflow aside from very complex object code:
    
    hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_update_stats':
    hisilicon/hns/hns_dsaf_gmac.c:419:1: error: the frame size of 2912 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_reset_common':
    hisilicon/hns/hns_dsaf_ppe.c:390:1: error: the frame size of 1184 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_get_regs':
    hisilicon/hns/hns_dsaf_ppe.c:621:1: error: the frame size of 3632 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_common_regs':
    hisilicon/hns/hns_dsaf_rcb.c:970:1: error: the frame size of 2784 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_get_regs':
    hisilicon/hns/hns_dsaf_gmac.c:641:1: error: the frame size of 5728 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_ring_regs':
    hisilicon/hns/hns_dsaf_rcb.c:1021:1: error: the frame size of 2208 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_comm_init':
    hisilicon/hns/hns_dsaf_main.c:1209:1: error: the frame size of 1904 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_xgmac.c: In function 'hns_xgmac_get_regs':
    hisilicon/hns/hns_dsaf_xgmac.c:748:1: error: the frame size of 4704 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_update_stats':
    hisilicon/hns/hns_dsaf_main.c:2420:1: error: the frame size of 1088 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_get_regs':
    hisilicon/hns/hns_dsaf_main.c:2753:1: error: the frame size of 10768 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    
    This does not seem to happen any more with gcc-7, but removing the ACCESS_ONCE
    seems safe anyway and it avoids a serious issue for some people. I have verified
    that with gcc-5.3.1, the object code we get is better in the new version
    both with and without CONFIG_KASAN, as we no longer allocate a 1344 byte
    stack frame for hns_dsaf_get_regs() but otherwise have practically identical
    object code.
    
    With gcc-7.0.0, removing ACCESS_ONCE has no effect, the object code is already
    good either way.
    
    This patch is probably not urgent to get into 4.11 as only KASAN=y builds
    with certain compilers are affected, but I still think it makes sense to
    backport into older kernels.
    
    Cc: stable@vger.kernel.org
    Fixes: 511e6bc ("net: add Hisilicon Network Subsystem DSAF support")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit a088d1d73a4bcfd7bc482f8d08375b9b665dc3e5
Author: Linus Lüssing <linus.luessing@c0d3.blue>
Date:   Fri Feb 3 08:11:03 2017 +0100

    ipv6: Fix IPv6 packet loss in scenarios involving roaming + snooping switches
    
    When for instance a mobile Linux device roams from one access point to
    another with both APs sharing the same broadcast domain and a
    multicast snooping switch in between:
    
    1)    (c) <~~~> (AP1) <--[SSW]--> (AP2)
    
    2)              (AP1) <--[SSW]--> (AP2) <~~~> (c)
    
    Then currently IPv6 multicast packets will get lost for (c) until an
    MLD Querier sends its next query message. The packet loss occurs
    because upon roaming the Linux host so far stayed silent regarding
    MLD and the snooping switch will therefore be unaware of the
    multicast topology change for a while.
    
    This patch fixes this by always resending MLD reports when an interface
    change happens, for instance from NO-CARRIER to CARRIER state.
    
    Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit ebf6c9cb23d7e56eec8575a88071dec97ad5c6e2
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Feb 5 20:23:22 2017 -0800

    ipv6: tcp: add a missing tcp_v6_restore_cb()
    
    Dmitry reported use-after-free in ip6_datagram_recv_specific_ctl()
    
    A similar bug was fixed in commit 8ce48623f0cf ("ipv6: tcp: restore
    IP6CB for pktoptions skbs"), but I missed another spot.
    
    tcp_v6_syn_recv_sock() can indeed set np->pktoptions from ireq->pktopts
    
    Fixes: 971f10eca186 ("tcp: better TCP_SKB_CB layout to reduce cache line misses")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit fd551bac4795854adaa87bad7e5136083719802b
Author: Masashi Honma <masashi.honma@gmail.com>
Date:   Thu Jan 26 08:56:13 2017 +0900

    nl80211: Fix mesh HT operation check
    
    A previous change to fix checks for NL80211_MESHCONF_HT_OPMODE
    missed setting the flag when replacing FILL_IN_MESH_PARAM_IF_SET
    with checking codes. This results in dropping the received HT
    operation value when called by nl80211_update_mesh_config(). Fix
    this by setting the flag properly.
    
    Fixes: 9757235f451c ("nl80211: correct checks for NL80211_MESHCONF_HT_OPMODE value")
    Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
    [rewrite commit message to use Fixes: line]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

commit da7061c82e4a1bc6a5e134ef362c86261906c860
Author: Thorsten Horstmann <thorsten@defutech.de>
Date:   Fri Feb 3 14:38:29 2017 +0100

    mac80211: Fix adding of mesh vendor IEs
    
    The function ieee80211_ie_split_vendor doesn't return 0 on errors. Instead
    it returns any offset < ielen when WLAN_EID_VENDOR_SPECIFIC is found. The
    return value in mesh_add_vendor_ies must therefore be checked against
    ifmsh->ie_len and not 0. Otherwise all ifmsh->ie starting with
    WLAN_EID_VENDOR_SPECIFIC will be rejected.
    
    Fixes: 082ebb0c258d ("mac80211: fix mesh beacon format")
    Signed-off-by: Thorsten Horstmann <thorsten@defutech.de>
    Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    [sven@narfation.org: Add commit message]
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

commit 01fba20b5976e445676febbdf6dc78d71c6d7b62
Author: Jouni Malinen <jouni@qca.qualcomm.com>
Date:   Sat Feb 4 18:08:42 2017 +0200

    mac80211: Allocate a sync skcipher explicitly for FILS AEAD
    
    The skcipher could have been of the async variant which may return from
    skcipher_encrypt() with -EINPROGRESS after having queued the request.
    The FILS AEAD implementation here does not have code for dealing with
    that possibility, so allocate a sync cipher explicitly to avoid
    potential issues with hardware accelerators.
    
    This is based on the patch sent out by Ard.
    
    Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode association frames")
    Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

commit e479ab651f071dbd1518ce8fb121c7f42f2bb97d
Author: Jouni Malinen <jouni@qca.qualcomm.com>
Date:   Sat Feb 4 13:59:22 2017 +0200

    mac80211: Fix FILS AEAD protection in Association Request frame
    
    Incorrect num_elem parameter value (1 vs. 5) was used in the
    aes_siv_encrypt() call. This resulted in only the first one of the five
    AAD vectors to SIV getting included in calculation. This does not
    protect all the contents correctly and would not interoperate with a
    standard compliant implementation.
    
    Fix this by using the correct number. A matching fix is needed in the AP
    side (hostapd) to get FILS authentication working properly.
    
    Fixes: 39404feee691 ("mac80211: FILS AEAD protection for station mode association frames")
    Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

commit 7892032cfe67f4bde6fc2ee967e45a8fbaf33756
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Feb 4 23:18:55 2017 -0800

    ip6_gre: fix ip6gre_err() invalid reads
    
    Andrey Konovalov reported out of bound accesses in ip6gre_err()
    
    If GRE flags contains GRE_KEY, the following expression
    *(((__be32 *)p) + (grehlen / 4) - 1)
    
    accesses data ~40 bytes after the expected point, since
    grehlen includes the size of IPv6 headers.
    
    Let's use a "struct gre_base_hdr *greh" pointer to make this
    code more readable.
    
    p[1] becomes greh->protocol.
    grhlen is the GRE header length.
    
    Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit d71b7896886345c53ef1d84bda2bc758554f5d61
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Feb 3 00:03:26 2017 -0800

    netlabel: out of bound access in cipso_v4_validate()
    
    syzkaller found another out of bound access in ip_options_compile(),
    or more exactly in cipso_v4_validate()
    
    Fixes: 20e2a8648596 ("cipso: handle CIPSO options correctly when NetLabel is disabled")
    Fixes: 446fda4f2682 ("[NetLabel]: CIPSOv4 engine")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Dmitry Vyukov  <dvyukov@google.com>
    Cc: Paul Moore <paul@paul-moore.com>
    Acked-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 34b2cef20f19c87999fff3da4071e66937db9644
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Feb 4 11:16:52 2017 -0800

    ipv4: keep skb->dst around in presence of IP options
    
    Andrey Konovalov got crashes in __ip_options_echo() when a NULL skb->dst
    is accessed.
    
    ipv4_pktinfo_prepare() should not drop the dst if (evil) IP options
    are present.
    
    We could refine the test to the presence of ts_needtime or srr,
    but IP options are not often used, so let's be conservative.
    
    Thanks to syzkaller team for finding this bug.
    
    Fixes: d826eb14ecef ("ipv4: PKTINFO doesnt need dst reference")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Andrey Konovalov <andreyknvl@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit bfb34527a32a1a576d9bfb7026d3ab0369a6cd60
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Sat Feb 4 14:47:31 2017 -0800

    libnvdimm, pfn: fix memmap reservation size versus 4K alignment
    
    When vmemmap_populate() allocates space for the memmap it does so in 2MB
    sized chunks. The libnvdimm-pfn driver incorrectly accounts for this
    when the alignment of the device is set to 4K. When this happens we
    trigger memory allocation failures in altmap_alloc_block_buf() and
    trigger warnings of the form:
    
     WARNING: CPU: 0 PID: 3376 at arch/x86/mm/init_64.c:656 arch_add_memory+0xe4/0xf0
     [..]
     Call Trace:
      dump_stack+0x86/0xc3
      __warn+0xcb/0xf0
      warn_slowpath_null+0x1d/0x20
      arch_add_memory+0xe4/0xf0
      devm_memremap_pages+0x29b/0x4e0
    
    Fixes: 315c562536c4 ("libnvdimm, pfn: add 'align' attribute, default to HPAGE_SIZE")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit a9306a63631493afc75893a4ac405d4e1cbae6aa
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Sat Feb 4 00:44:36 2017 +0100

    PM / runtime: Avoid false-positive warnings from might_sleep_if()
    
    The might_sleep_if() assertions in __pm_runtime_idle(),
    __pm_runtime_suspend() and __pm_runtime_resume() may generate
    false-positive warnings in some situations.  For example, that
    happens if a nested pm_runtime_get_sync()/pm_runtime_put() pair
    is executed with disabled interrupts within an outer
    pm_runtime_get_sync()/pm_runtime_put() section for the same device.
    [Generally, pm_runtime_get_sync() may sleep, so it should not be
    called with disabled interrupts, but in this particular case the
    previous pm_runtime_get_sync() guarantees that the device will not
    be suspended, so the inner pm_runtime_get_sync() will return
    immediately after incrementing the device's usage counter.]
    
    That started to happen in the i915 driver in 4.10-rc, leading to
    the following splat:
    
     BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1032
     in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
     1 lock held by Xorg/1500:
      #0:  (&dev->struct_mutex){+.+.+.}, at:
      [<ffffffffa0680c13>] i915_mutex_lock_interruptible+0x43/0x140 [i915]
     CPU: 0 PID: 1500 Comm: Xorg Not tainted
     Call Trace:
      dump_stack+0x85/0xc2
      ___might_sleep+0x196/0x260
      __might_sleep+0x53/0xb0
      __pm_runtime_resume+0x7a/0x90
      intel_runtime_pm_get+0x25/0x90 [i915]
      aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
      i915_vma_bind+0xaf/0x1e0 [i915]
      i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
      i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
      ? trace_hardirqs_on+0xd/0x10
      ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
      ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
      i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
      ? __might_fault+0x4e/0xb0
      i915_gem_execbuffer2+0xc5/0x260 [i915]
      ? __might_fault+0x4e/0xb0
      drm_ioctl+0x206/0x450 [drm]
      ? i915_gem_execbuffer+0x340/0x340 [i915]
      ? __fget+0x5/0x200
      do_vfs_ioctl+0x91/0x6f0
      ? __fget+0x111/0x200
      ? __fget+0x5/0x200
      SyS_ioctl+0x79/0x90
      entry_SYSCALL_64_fastpath+0x23/0xc6
    
    even though the code triggering it is correct.
    
    Unfortunately, the might_sleep_if() assertions in question are
    too coarse-grained to cover such cases correctly, so make them
    a bit less sensitive in order to avoid the false-positives.
    
    Reported-and-tested-by: Sedat Dilek <sedat.dilek@gmail.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 6e978b22efa1db9f6e71b24440b5f1d93e968ee3
Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date:   Fri Feb 3 14:18:39 2017 -0800

    cpufreq: intel_pstate: Disable energy efficiency optimization
    
    Some Kabylake desktop processors may not reach max turbo when running in
    HWP mode, even if running under sustained 100% utilization.
    
    This occurs when the HWP.EPP (Energy Performance Preference) is set to
    "balance_power" (0x80) -- the default on most systems.
    
    It occurs because the platform BIOS may erroneously enable an
    energy-efficiency setting -- MSR_IA32_POWER_CTL BIT-EE, which is not
    recommended to be enabled on this SKU.
    
    On the failing systems, this BIOS issue was not discovered when the
    desktop motherboard was tested with Windows, because the BIOS also
    neglects to provide the ACPI/CPPC table, that Windows requires to enable
    HWP, and so Windows runs in legacy P-state mode, where this setting has
    no effect.
    
    Linux' intel_pstate driver does not require ACPI/CPPC to enable HWP, and
    so it runs in HWP mode, exposing this incorrect BIOS configuration.
    
    There are several ways to address this problem.
    
    First, Linux can also run in legacy P-state mode on this system.
    As intel_pstate is how Linux enables HWP, booting with
    "intel_pstate=disable"
    will run in acpi-cpufreq/ondemand legacy p-state mode.
    
    Or second, the "performance" governor can be used with intel_pstate,
    which will modify HWP.EPP to 0.
    
    Or third, starting in 4.10, the
    /sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference
    attribute in can be updated from "balance_power" to "performance".
    
    Or fourth, apply this patch, which fixes the erroneous setting of
    MSR_IA32_POWER_CTL BIT_EE on this model, allowing the default
    configuration to function as designed.
    
    Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Reviewed-by: Len Brown <len.brown@intel.com>
    Cc: 4.6+ <stable@vger.kernel.org> # 4.6+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 5fa8bbda38c668e56b0c6cdecced2eac2fe36dec
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Feb 2 10:31:35 2017 -0800

    net: use a work queue to defer net_disable_timestamp() work
    
    Dmitry reported a warning [1] showing that we were calling
    net_disable_timestamp() -> static_key_slow_dec() from a non
    process context.
    
    Grabbing a mutex while holding a spinlock or rcu_read_lock()
    is not allowed.
    
    As Cong suggested, we now use a work queue.
    
    It is possible netstamp_clear() exits while netstamp_needed_deferred
    is not zero, but it is probably not worth trying to do better than that.
    
    netstamp_needed_deferred atomic tracks the exact number of deferred
    decrements.
    
    [1]
    [ INFO: suspicious RCU usage. ]
    4.10.0-rc5+ #192 Not tainted
    -------------------------------
    ./include/linux/rcupdate.h:561 Illegal context switch in RCU read-side
    critical section!
    
    other info that might help us debug this:
    
    rcu_scheduler_active = 2, debug_locks = 0
    2 locks held by syz-executor14/23111:
     #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83a35c35>] lock_sock
    include/net/sock.h:1454 [inline]
     #0:  (sk_lock-AF_INET6){+.+.+.}, at: [<ffffffff83a35c35>]
    rawv6_sendmsg+0x1e65/0x3ec0 net/ipv6/raw.c:919
     #1:  (rcu_read_lock){......}, at: [<ffffffff83ae2678>] nf_hook
    include/linux/netfilter.h:201 [inline]
     #1:  (rcu_read_lock){......}, at: [<ffffffff83ae2678>]
    __ip6_local_out+0x258/0x840 net/ipv6/output_core.c:160
    
    stack backtrace:
    CPU: 2 PID: 23111 Comm: syz-executor14 Not tainted 4.10.0-rc5+ #192
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
    01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:15 [inline]
     dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
     lockdep_rcu_suspicious+0x139/0x180 kernel/locking/lockdep.c:4452
     rcu_preempt_sleep_check include/linux/rcupdate.h:560 [inline]
     ___might_sleep+0x560/0x650 kernel/sched/core.c:7748
     __might_sleep+0x95/0x1a0 kernel/sched/core.c:7739
     mutex_lock_nested+0x24f/0x1730 kernel/locking/mutex.c:752
     atomic_dec_and_mutex_lock+0x119/0x160 kernel/locking/mutex.c:1060
     __static_key_slow_dec+0x7a/0x1e0 kernel/jump_label.c:149
     static_key_slow_dec+0x51/0x90 kernel/jump_label.c:174
     net_disable_timestamp+0x3b/0x50 net/core/dev.c:1728
     sock_disable_timestamp+0x98/0xc0 net/core/sock.c:403
     __sk_destruct+0x27d/0x6b0 net/core/sock.c:1441
     sk_destruct+0x47/0x80 net/core/sock.c:1460
     __sk_free+0x57/0x230 net/core/sock.c:1468
     sock_wfree+0xae/0x120 net/core/sock.c:1645
     skb_release_head_state+0xfc/0x200 net/core/skbuff.c:655
     skb_release_all+0x15/0x60 net/core/skbuff.c:668
     __kfree_skb+0x15/0x20 net/core/skbuff.c:684
     kfree_skb+0x16e/0x4c0 net/core/skbuff.c:705
     inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
     inet_frag_put include/net/inet_frag.h:133 [inline]
     nf_ct_frag6_gather+0x1106/0x3840
    net/ipv6/netfilter/nf_conntrack_reasm.c:617
     ipv6_defrag+0x1be/0x2b0 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
     nf_hook_entry_hookfn include/linux/netfilter.h:102 [inline]
     nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
     nf_hook include/linux/netfilter.h:212 [inline]
     __ip6_local_out+0x489/0x840 net/ipv6/output_core.c:160
     ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
     ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
     ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
     rawv6_push_pending_frames net/ipv6/raw.c:613 [inline]
     rawv6_sendmsg+0x2d1a/0x3ec0 net/ipv6/raw.c:927
     inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
     sock_sendmsg_nosec net/socket.c:635 [inline]
     sock_sendmsg+0xca/0x110 net/socket.c:645
     sock_write_iter+0x326/0x600 net/socket.c:848
     do_iter_readv_writev+0x2e3/0x5b0 fs/read_write.c:695
     do_readv_writev+0x42c/0x9b0 fs/read_write.c:872
     vfs_writev+0x87/0xc0 fs/read_write.c:911
     do_writev+0x110/0x2c0 fs/read_write.c:944
     SYSC_writev fs/read_write.c:1017 [inline]
     SyS_writev+0x27/0x30 fs/read_write.c:1014
     entry_SYSCALL_64_fastpath+0x1f/0xc2
    RIP: 0033:0x445559
    RSP: 002b:00007f6f46fceb58 EFLAGS: 00000292 ORIG_RAX: 0000000000000014
    RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000445559
    RDX: 0000000000000001 RSI: 0000000020f1eff0 RDI: 0000000000000005
    RBP: 00000000006e19c0 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000292 R12: 0000000000700000
    R13: 0000000020f59000 R14: 0000000000000015 R15: 0000000000020400
    BUG: sleeping function called from invalid context at
    kernel/locking/mutex.c:752
    in_atomic(): 1, irqs_disabled(): 0, pid: 23111, name: syz-executor14
    INFO: lockdep is turned off.
    CPU: 2 PID: 23111 Comm: syz-executor14 Not tainted 4.10.0-rc5+ #192
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
    01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:15 [inline]
     dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
     ___might_sleep+0x47e/0x650 kernel/sched/core.c:7780
     __might_sleep+0x95/0x1a0 kernel/sched/core.c:7739
     mutex_lock_nested+0x24f/0x1730 kernel/locking/mutex.c:752
     atomic_dec_and_mutex_lock+0x119/0x160 kernel/locking/mutex.c:1060
     __static_key_slow_dec+0x7a/0x1e0 kernel/jump_label.c:149
     static_key_slow_dec+0x51/0x90 kernel/jump_label.c:174
     net_disable_timestamp+0x3b/0x50 net/core/dev.c:1728
     sock_disable_timestamp+0x98/0xc0 net/core/sock.c:403
     __sk_destruct+0x27d/0x6b0 net/core/sock.c:1441
     sk_destruct+0x47/0x80 net/core/sock.c:1460
     __sk_free+0x57/0x230 net/core/sock.c:1468
     sock_wfree+0xae/0x120 net/core/sock.c:1645
     skb_release_head_state+0xfc/0x200 net/core/skbuff.c:655
     skb_release_all+0x15/0x60 net/core/skbuff.c:668
     __kfree_skb+0x15/0x20 net/core/skbuff.c:684
     kfree_skb+0x16e/0x4c0 net/core/skbuff.c:705
     inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
     inet_frag_put include/net/inet_frag.h:133 [inline]
     nf_ct_frag6_gather+0x1106/0x3840
    net/ipv6/netfilter/nf_conntrack_reasm.c:617
     ipv6_defrag+0x1be/0x2b0 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
     nf_hook_entry_hookfn include/linux/netfilter.h:102 [inline]
     nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
     nf_hook include/linux/netfilter.h:212 [inline]
     __ip6_local_out+0x489/0x840 net/ipv6/output_core.c:160
     ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
     ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
     ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
     rawv6_push_pending_frames net/ipv6/raw.c:613 [inline]
     rawv6_sendmsg+0x2d1a/0x3ec0 net/ipv6/raw.c:927
     inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
     sock_sendmsg_nosec net/socket.c:635 [inline]
     sock_sendmsg+0xca/0x110 net/socket.c:645
     sock_write_iter+0x326/0x600 net/socket.c:848
     do_iter_readv_writev+0x2e3/0x5b0 fs/read_write.c:695
     do_readv_writev+0x42c/0x9b0 fs/read_write.c:872
     vfs_writev+0x87/0xc0 fs/read_write.c:911
     do_writev+0x110/0x2c0 fs/read_write.c:944
     SYSC_writev fs/read_write.c:1017 [inline]
     SyS_writev+0x27/0x30 fs/read_write.c:1014
     entry_SYSCALL_64_fastpath+0x1f/0xc2
    RIP: 0033:0x445559
    
    Fixes: b90e5794c5bd ("net: dont call jump_label_dec from irq context")
    Suggested-by: Cong Wang <xiyou.wangcong@gmail.com>
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit e471486c13b82b1338d49c798f78bb62b1ed0a9e
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Feb 2 10:31:00 2017 -0800

    acpi, nfit: fix acpi_nfit_flush_probe() crash
    
    We queue an on-stack work item to 'nfit_wq' and wait for it to complete
    as part of a 'flush_probe' request. However, if the user cancels the
    wait we need to make sure the item is flushed from the queue otherwise
    we are leaving an out-of-scope stack address on the work list.
    
     BUG: unable to handle kernel paging request at ffffbcb3c72f7cd0
     IP: [<ffffffffa9413a7b>] __list_add+0x1b/0xb0
     [..]
     RIP: 0010:[<ffffffffa9413a7b>]  [<ffffffffa9413a7b>] __list_add+0x1b/0xb0
     RSP: 0018:ffffbcb3c7ba7c00  EFLAGS: 00010046
     [..]
     Call Trace:
      [<ffffffffa90bb11a>] insert_work+0x3a/0xc0
      [<ffffffffa927fdda>] ? seq_open+0x5a/0xa0
      [<ffffffffa90bb30a>] __queue_work+0x16a/0x460
      [<ffffffffa90bbb08>] queue_work_on+0x38/0x40
      [<ffffffffc0cf2685>] acpi_nfit_flush_probe+0x95/0xc0 [nfit]
      [<ffffffffc0cf25d0>] ? nfit_visible+0x40/0x40 [nfit]
      [<ffffffffa9571495>] wait_probe_show+0x25/0x60
      [<ffffffffa9546b30>] dev_attr_show+0x20/0x50
    
    Fixes: 7ae0fa439faf ("nfit, libnvdimm: async region scrub workqueue")
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 3808d34838184fd29088d6b3a364ba2f1c018fb6
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Thu Feb 2 13:32:10 2017 +0100

    ethtool: do not vzalloc(0) on registers dump
    
    If ->get_regs_len() callback return 0, we allocate 0 bytes of memory,
    what print ugly warning in dmesg, which can be found further below.
    
    This happen on mac80211 devices where ieee80211_get_regs_len() just
    return 0 and driver only fills ethtool_regs structure and actually
    do not provide any dump. However I assume this can happen on other
    drivers i.e. when for some devices driver provide regs dump and for
    others do not. Hence preventing to to print warning in ethtool code
    seems to be reasonable.
    
    ethtool: vmalloc: allocation failure: 0 bytes, mode:0x24080c2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_ZERO)
    <snip>
    Call Trace:
    [<ffffffff813bde47>] dump_stack+0x63/0x8c
    [<ffffffff811b0a1f>] warn_alloc+0x13f/0x170
    [<ffffffff811f0476>] __vmalloc_node_range+0x1e6/0x2c0
    [<ffffffff811f0874>] vzalloc+0x54/0x60
    [<ffffffff8169986c>] dev_ethtool+0xb4c/0x1b30
    [<ffffffff816adbb1>] dev_ioctl+0x181/0x520
    [<ffffffff816714d2>] sock_do_ioctl+0x42/0x50
    <snip>
    Mem-Info:
    active_anon:435809 inactive_anon:173951 isolated_anon:0
     active_file:835822 inactive_file:196932 isolated_file:0
     unevictable:0 dirty:8 writeback:0 unstable:0
     slab_reclaimable:157732 slab_unreclaimable:10022
     mapped:83042 shmem:306356 pagetables:9507 bounce:0
     free:130041 free_pcp:1080 free_cma:0
    Node 0 active_anon:1743236kB inactive_anon:695804kB active_file:3343288kB inactive_file:787728kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:332168kB dirty:32kB writeback:0kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 1225424kB writeback_tmp:0kB unstable:0kB pages_scanned:0 all_unreclaimable? no
    Node 0 DMA free:15900kB min:136kB low:168kB high:200kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15984kB managed:15900kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
    lowmem_reserve[]: 0 3187 7643 7643
    Node 0 DMA32 free:419732kB min:28124kB low:35152kB high:42180kB active_anon:541180kB inactive_anon:248988kB active_file:1466388kB inactive_file:389632kB unevictable:0kB writepending:0kB present:3370280kB managed:3290932kB mlocked:0kB slab_reclaimable:217184kB slab_unreclaimable:4180kB kernel_stack:160kB pagetables:984kB bounce:0kB free_pcp:2236kB local_pcp:660kB free_cma:0kB
    lowmem_reserve[]: 0 0 4456 4456
    
    Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 013e8167899d389075160412a8c0c5e0581e1f13
Author: David Lebrun <david.lebrun@uclouvain.be>
Date:   Thu Feb 2 11:29:38 2017 +0100

    ipv6: sr: remove cleanup flag and fix HMAC computation
    
    In the latest version of the IPv6 Segment Routing IETF draft [1] the
    cleanup flag is removed and the flags field length is shrunk from 16 bits
    to 8 bits. As a consequence, the input of the HMAC computation is modified
    in a non-backward compatible way by covering the whole octet of flags
    instead of only the cleanup bit. As such, if an implementation compatible
    with the latest draft computes the HMAC of an SRH who has other flags set
    to 1, then the HMAC result would differ from the current implementation.
    
    This patch carries those modifications to prevent conflict with other
    implementations of IPv6 SR.
    
    [1] https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-05
    
    Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit f5b0cba8f23915e92932f11eb063e37d70556a89
Author: Ondrej Kozina <okozina@redhat.com>
Date:   Tue Jan 31 15:47:11 2017 +0100

    dm crypt: replace RCU read-side section with rwsem
    
    The lockdep splat below hints at a bug in RCU usage in dm-crypt that
    was introduced with commit c538f6ec9f56 ("dm crypt: add ability to use
    keys from the kernel key retention service").  The kernel keyring
    function user_key_payload() is in fact a wrapper for
    rcu_dereference_protected() which must not be called with only
    rcu_read_lock() section mark.
    
    Unfortunately the kernel keyring subsystem doesn't currently provide
    an interface that allows the use of an RCU read-side section.  So for
    now we must drop RCU in favour of rwsem until a proper function is
    made available in the kernel keyring subsystem.
    
    ===============================
    [ INFO: suspicious RCU usage. ]
    4.10.0-rc5 #2 Not tainted
    -------------------------------
    ./include/keys/user-type.h:53 suspicious rcu_dereference_protected() usage!
    other info that might help us debug this:
    rcu_scheduler_active = 2, debug_locks = 1
    2 locks held by cryptsetup/6464:
     #0:  (&md->type_lock){+.+.+.}, at: [<ffffffffa02472a2>] dm_lock_md_type+0x12/0x20 [dm_mod]
     #1:  (rcu_read_lock){......}, at: [<ffffffffa02822f8>] crypt_set_key+0x1d8/0x4b0 [dm_crypt]
    stack backtrace:
    CPU: 1 PID: 6464 Comm: cryptsetup Not tainted 4.10.0-rc5 #2
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014
    Call Trace:
     dump_stack+0x67/0x92
     lockdep_rcu_suspicious+0xc5/0x100
     crypt_set_key+0x351/0x4b0 [dm_crypt]
     ? crypt_set_key+0x1d8/0x4b0 [dm_crypt]
     crypt_ctr+0x341/0xa53 [dm_crypt]
     dm_table_add_target+0x147/0x330 [dm_mod]
     table_load+0x111/0x350 [dm_mod]
     ? retrieve_status+0x1c0/0x1c0 [dm_mod]
     ctl_ioctl+0x1f5/0x510 [dm_mod]
     dm_ctl_ioctl+0xe/0x20 [dm_mod]
     do_vfs_ioctl+0x8e/0x690
     ? ____fput+0x9/0x10
     ? task_work_run+0x7e/0xa0
     ? trace_hardirqs_on_caller+0x122/0x1b0
     SyS_ioctl+0x3c/0x70
     entry_SYSCALL_64_fastpath+0x18/0xad
    RIP: 0033:0x7f392c9a4ec7
    RSP: 002b:00007ffef6383378 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 00007ffef63830a0 RCX: 00007f392c9a4ec7
    RDX: 000000000124fcc0 RSI: 00000000c138fd09 RDI: 0000000000000005
    RBP: 00007ffef6383090 R08: 00000000ffffffff R09: 00000000012482b0
    R10: 2a28205d34383336 R11: 0000000000000246 R12: 00007f392d803a08
    R13: 00007ffef63831e0 R14: 0000000000000000 R15: 00007f392d803a0b
    
    Fixes: c538f6ec9f56 ("dm crypt: add ability to use keys from the kernel key retention service")
    Reported-by: Milan Broz <mbroz@redhat.com>
    Signed-off-by: Ondrej Kozina <okozina@redhat.com>
    Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit 4087a1fffe38106e10646606a27f10d40451862d
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Wed Jan 25 16:24:52 2017 +0100

    dm rq: cope with DM device destruction while in dm_old_request_fn()
    
    Fixes a crash in dm_table_find_target() due to a NULL struct dm_table
    being passed from dm_old_request_fn() that races with DM device
    destruction.
    
    Reported-by: artem@flashgrid.io
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>
    Cc: stable@vger.kernel.org

commit d19a55ccad15a486ffe03030570744e5d5bd9f8e
Author: Mike Snitzer <snitzer@redhat.com>
Date:   Fri Jan 6 15:33:14 2017 -0500

    dm mpath: cleanup -Wbool-operation warning in choose_pgpath()
    
    Reported-by: David Binderman <dcb314@hotmail.com>
    Signed-off-by: Mike Snitzer <snitzer@redhat.com>

commit 7c2cf1c4615cc2f576d0604406cdf0065f00b83b
Author: Harsh Jain <harsh@chelsio.com>
Date:   Fri Jan 27 16:09:06 2017 +0530

    crypto: chcr - Fix key length for RFC4106
    
    Check keylen before copying salt to avoid wrap around of Integer.
    
    Signed-off-by: Harsh Jain <harsh@chelsio.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit 0b529f143e8baad441a5aac9ad55ec2434d8fb46
Author: Harsh Jain <harsh@chelsio.com>
Date:   Wed Feb 1 21:10:28 2017 +0530

    crypto: algif_aead - Fix kernel panic on list_del
    
    Kernel panics when userspace program try to access AEAD interface.
    Remove node from Linked List before freeing its memory.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Harsh Jain <harsh@chelsio.com>
    Reviewed-by: Stephan Müller <smueller@chronox.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit c26819900036f5b91608051a0fc7c76f6b4ffc7b
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Wed Feb 1 22:17:39 2017 +0800

    crypto: aesni - Fix failure when pcbc module is absent
    
    When aesni is built as a module together with pcbc, the pcbc module
    must be present for aesni to load.  However, the pcbc module may not
    be present for reasons such as its absence on initramfs.  This patch
    allows the aesni to function even if the pcbc module is enabled but
    not present.
    
    Reported-by: Arkadiusz Miśkiewicz <arekm@maven.pl>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit e5da5c5667381d2772374ee6a2967b3576c9483d
Author: Gary R Hook <gary.hook@amd.com>
Date:   Fri Jan 27 17:09:04 2017 -0600

    crypto: ccp - Fix double add when creating new DMA command
    
    Eliminate a double-add by creating a new list to manage
    command descriptors when created; move the descriptor to
    the pending list when the command is submitted.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Gary R Hook <gary.hook@amd.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit 500c0106e638e08c2c661c305ed57d6b67e10908
Author: Gary R Hook <gary.hook@amd.com>
Date:   Fri Jan 27 15:28:45 2017 -0600

    crypto: ccp - Fix DMA operations when IOMMU is enabled
    
    An I/O page fault occurs when the IOMMU is enabled on a
    system that supports the v5 CCP.  DMA operations use a
    Request ID value that does not match what is expected by
    the IOMMU, resulting in the I/O page fault.  Setting the
    Request ID value to 0 corrects this issue.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Gary R Hook <gary.hook@amd.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit f5f7bebc91ab378dea5aad5277c4d283e46472d9
Author: Harsh Jain <harsh@chelsio.com>
Date:   Tue Jan 24 10:34:33 2017 +0530

    crypto: chcr - Check device is allocated before use
    
    Ensure dev is allocated for crypto uld context before using the device
    for crypto operations.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit 94e1dab1c94715e18bb0bada503de3f3d7593076
Author: Harsh Jain <harsh@chelsio.com>
Date:   Tue Jan 24 10:34:32 2017 +0530

    crypto: chcr - Fix panic on dma_unmap_sg
    
    Save DMA mapped sg list addresses to request context buffer.
    
    Signed-off-by: Atul Gupta <atul.gupta@chelsio.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit cafe8df8b9bc9aa3dffa827c1a6757c6cd36f657
Author: Mao Wenan <maowenan@huawei.com>
Date:   Tue Jan 31 18:46:43 2017 -0800

    net: phy: Fix lack of reference count on PHY driver
    
    There is currently no reference count being held on the PHY driver,
    which makes it possible to remove the PHY driver module while the PHY
    state machine is running and polling the PHY. This could cause crashes
    similar to this one to show up:
    
    [   43.361162] BUG: unable to handle kernel NULL pointer dereference at 0000000000000140
    [   43.361162] IP: phy_state_machine+0x32/0x490
    [   43.361162] PGD 59dc067
    [   43.361162] PUD 0
    [   43.361162]
    [   43.361162] Oops: 0000 [#1] SMP
    [   43.361162] Modules linked in: dsa_loop [last unloaded: broadcom]
    [   43.361162] CPU: 0 PID: 1299 Comm: kworker/0:3 Not tainted 4.10.0-rc5+ #415
    [   43.361162] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
    BIOS Ubuntu-1.8.2-1ubuntu2 04/01/2014
    [   43.361162] Workqueue: events_power_efficient phy_state_machine
    [   43.361162] task: ffff880006782b80 task.stack: ffffc90000184000
    [   43.361162] RIP: 0010:phy_state_machine+0x32/0x490
    [   43.361162] RSP: 0018:ffffc90000187e18 EFLAGS: 00000246
    [   43.361162] RAX: 0000000000000000 RBX: ffff8800059e53c0 RCX:
    ffff880006a15c60
    [   43.361162] RDX: ffff880006782b80 RSI: 0000000000000000 RDI:
    ffff8800059e5428
    [   43.361162] RBP: ffffc90000187e48 R08: ffff880006a15c40 R09:
    0000000000000000
    [   43.361162] R10: 0000000000000000 R11: 0000000000000000 R12:
    ffff8800059e5428
    [   43.361162] R13: ffff8800059e5000 R14: 0000000000000000 R15:
    ffff880006a15c40
    [   43.361162] FS:  0000000000000000(0000) GS:ffff880006a00000(0000)
    knlGS:0000000000000000
    [   43.361162] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   43.361162] CR2: 0000000000000140 CR3: 0000000005979000 CR4:
    00000000000006f0
    [   43.361162] Call Trace:
    [   43.361162]  process_one_work+0x1b4/0x3e0
    [   43.361162]  worker_thread+0x43/0x4d0
    [   43.361162]  ? __schedule+0x17f/0x4e0
    [   43.361162]  kthread+0xf7/0x130
    [   43.361162]  ? process_one_work+0x3e0/0x3e0
    [   43.361162]  ? kthread_create_on_node+0x40/0x40
    [   43.361162]  ret_from_fork+0x29/0x40
    [   43.361162] Code: 56 41 55 41 54 4c 8d 67 68 53 4c 8d af 40 fc ff ff
    48 89 fb 4c 89 e7 48 83 ec 08 e8 c9 9d 27 00 48 8b 83 60 ff ff ff 44 8b
    73 98 <48> 8b 90 40 01 00 00 44 89 f0 48 85 d2 74 08 4c 89 ef ff d2 8b
    
    Keep references on the PHY driver module right before we are going to
    utilize it in phy_attach_direct(), and conversely when we don't use it
    anymore in phy_detach().
    
    Signed-off-by: Mao Wenan <maowenan@huawei.com>
    [florian: rebase, rework commit message]
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 770f82253dbd7e6892a88018f2f6cd395f48d214
Author: Martin KaFai Lau <kafai@fb.com>
Date:   Tue Jan 31 22:35:33 2017 -0800

    mlx4: xdp_prog becomes inactive after ethtool '-L' or '-G'
    
    After calling mlx4_en_try_alloc_resources (e.g. by changing the
    number of rx-queues with ethtool -L), the existing xdp_prog becomes
    inactive.
    
    The bug is that the xdp_prog ptr has not been carried over from
    the old rx-queues to the new rx-queues
    
    Fixes: 47a38e155037 ("net/mlx4_en: add support for fast rx drop bpf program")
    Cc: Brenden Blanco <bblanco@plumgrid.com>
    Cc: Saeed Mahameed <saeedm@mellanox.com>
    Cc: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: Martin KaFai Lau <kafai@fb.com>
    Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit f32b20e89e82c9ff1825fc5c5d69753ff5558ccd
Author: Martin KaFai Lau <kafai@fb.com>
Date:   Tue Jan 31 22:35:32 2017 -0800

    mlx4: Fix memory leak after mlx4_en_update_priv()
    
    In mlx4_en_update_priv(), dst->tx_ring[t] and dst->tx_cq[t]
    are over-written by src->tx_ring[t] and src->tx_cq[t] without
    first calling kfree.
    
    One of the reproducible code paths is by doing 'ethtool -L'.
    
    The fix is to do the kfree in mlx4_en_free_resources().
    
    Here is the kmemleak report:
    unreferenced object 0xffff880841211800 (size 2048):
      comm "ethtool", pid 3096, jiffies 4294716940 (age 528.353s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff81930718>] kmemleak_alloc+0x28/0x50
        [<ffffffff8120b213>] kmem_cache_alloc_trace+0x103/0x260
        [<ffffffff8170e0a8>] mlx4_en_try_alloc_resources+0x118/0x1a0
        [<ffffffff817065a9>] mlx4_en_set_ringparam+0x169/0x210
        [<ffffffff818040c5>] dev_ethtool+0xae5/0x2190
        [<ffffffff8181b898>] dev_ioctl+0x168/0x6f0
        [<ffffffff817d7a72>] sock_do_ioctl+0x42/0x50
        [<ffffffff817d819b>] sock_ioctl+0x21b/0x2d0
        [<ffffffff81247a73>] do_vfs_ioctl+0x93/0x6a0
        [<ffffffff812480f9>] SyS_ioctl+0x79/0x90
        [<ffffffff8193d7ea>] entry_SYSCALL_64_fastpath+0x18/0xad
        [<ffffffffffffffff>] 0xffffffffffffffff
    unreferenced object 0xffff880841213000 (size 2048):
      comm "ethtool", pid 3096, jiffies 4294716940 (age 528.353s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff81930718>] kmemleak_alloc+0x28/0x50
        [<ffffffff8120b213>] kmem_cache_alloc_trace+0x103/0x260
        [<ffffffff8170e0cb>] mlx4_en_try_alloc_resources+0x13b/0x1a0
        [<ffffffff817065a9>] mlx4_en_set_ringparam+0x169/0x210
        [<ffffffff818040c5>] dev_ethtool+0xae5/0x2190
        [<ffffffff8181b898>] dev_ioctl+0x168/0x6f0
        [<ffffffff817d7a72>] sock_do_ioctl+0x42/0x50
        [<ffffffff817d819b>] sock_ioctl+0x21b/0x2d0
        [<ffffffff81247a73>] do_vfs_ioctl+0x93/0x6a0
        [<ffffffff812480f9>] SyS_ioctl+0x79/0x90
        [<ffffffff8193d7ea>] entry_SYSCALL_64_fastpath+0x18/0xad
        [<ffffffffffffffff>] 0xffffffffffffffff
    
    (gdb) list *mlx4_en_try_alloc_resources+0x118
    0xffffffff8170e0a8 is in mlx4_en_try_alloc_resources (drivers/net/ethernet/mellanox/mlx4/en_netdev.c:2145).
    2140                    if (!dst->tx_ring_num[t])
    2141                            continue;
    2142
    2143                    dst->tx_ring[t] = kzalloc(sizeof(struct mlx4_en_tx_ring *) *
    2144                                              MAX_TX_RINGS, GFP_KERNEL);
    2145                    if (!dst->tx_ring[t])
    2146                            goto err_free_tx;
    2147
    2148                    dst->tx_cq[t] = kzalloc(sizeof(struct mlx4_en_cq *) *
    2149                                            MAX_TX_RINGS, GFP_KERNEL);
    (gdb) list *mlx4_en_try_alloc_resources+0x13b
    0xffffffff8170e0cb is in mlx4_en_try_alloc_resources (drivers/net/ethernet/mellanox/mlx4/en_netdev.c:2150).
    2145                    if (!dst->tx_ring[t])
    2146                            goto err_free_tx;
    2147
    2148                    dst->tx_cq[t] = kzalloc(sizeof(struct mlx4_en_cq *) *
    2149                                            MAX_TX_RINGS, GFP_KERNEL);
    2150                    if (!dst->tx_cq[t]) {
    2151                            kfree(dst->tx_ring[t]);
    2152                            goto err_free_tx;
    2153                    }
    2154            }
    
    Fixes: ec25bc04ed8e ("net/mlx4_en: Add resilience in low memory systems")
    Cc: Eugenia Emantayev <eugenia@mellanox.com>
    Cc: Saeed Mahameed <saeedm@mellanox.com>
    Cc: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: Martin KaFai Lau <kafai@fb.com>
    Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 685ce0626840e2673fe64ea8807684f7324fec5f
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Thu Dec 22 15:00:24 2016 +0000

    crypto: qat - zero esram only for DH85x devices
    
    Zero embedded ram in DH85x devices. This is not
    needed for newer generations as it is done by HW.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit 3484ecbe0e9deb94afb0b9b6172d77e98eb72b94
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date:   Thu Dec 22 15:00:12 2016 +0000

    crypto: qat - fix bar discovery for c62x
    
    Some accelerators of the c62x series have only two bars.
    This patch skips BAR0 if the accelerator does not have it.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

commit 9d032f4201d39e5cf43a8709a047e481f5723fdc
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Jan 25 00:54:07 2017 +0530

    libnvdimm, namespace: do not delete namespace-id 0
    
    Given that the naming of pmem devices changes from the pmemX form to the
    pmemX.Y form when namespace id is greater than 0, arrange for namespaces
    with id-0 to be exempt from deletion. Otherwise a simple reconfiguration
    of an existing namespace to a new mode results in a name change of the
    resulting block device:
    
        # ndctl list --namespace=namespace1.0
        {
          "dev":"namespace1.0",
          "mode":"raw",
          "size":2147483648,
          "uuid":"3dadf3dc-89b9-4b24-b20e-abc8a4707ce3",
          "blockdev":"pmem1"
        }
    
        # ndctl create-namespace --reconfig=namespace1.0 --mode=memory --force
        {
          "dev":"namespace1.1",
          "mode":"memory",
          "size":2111832064,
          "uuid":"7b4a6341-7318-4219-a02c-fb57c0bbf613",
          "blockdev":"pmem1.1"
        }
    
    This change does require tooling changes to explicitly look for
    namespaceX.0 if the seed has already advanced to another namespace.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 98a29c39dc68 ("libnvdimm, namespace: allow creation of multiple pmem-namespaces per region")
    Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 970d14e3989160ee9e97c7d75ecbc893fd29dab9
Author: Bhumika Goyal <bhumirks@gmail.com>
Date:   Wed Jan 25 00:54:07 2017 +0530

    nvdimm: constify device_type structures
    
    Declare device_type structure as const as it is only stored in the
    type field of a device structure. This field is of type const, so add
    const to declaration of device_type structure.
    
    File size before:
      text	   data	    bss	    dec	    hex	filename
      19278	   3199	     16	  22493	   57dd	nvdimm/namespace_devs.o
    
    File size after:
      text	   data	    bss	    dec	    hex	filename
      19929	   3160	     16	  23105	   5a41	nvdimm/namespace_devs.o
    
    Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 52f5631a4c056ad01682393be56d2be237e81610
Author: Jurij Smakov <jurij@wooyd.org>
Date:   Mon Jan 30 15:41:36 2017 -0600

    rtlwifi: rtl8192ce: Fix loading of incorrect firmware
    
    In commit cf4747d7535a ("rtlwifi: Fix regression caused by commit
    d86e64768859, an error in the edit results in the wrong firmware
    being loaded for some models of the RTL8188/8192CE. In this condition,
    the connection suffered from high ping latency, slow transfer rates,
     and required higher signal strengths to work at all
    
    See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853073,
    https://bugzilla.opensuse.org/show_bug.cgi?id=1017471, and
    https://github.com/lwfinger/rtlwifi_new/issues/203 for descriptions
    of the problems. This patch fixes all of those problems.
    
    Fixes: cf4747d7535a ("rtlwifi: Fix regression caused by commit d86e64768859")
    Signed-off-by: Jurij Smakov <jurij@wooyd.org>
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Stable <stable@vger.kernel.org> # 4.9+
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

commit f9f96fc10c09ca16e336854c08bc1563eed97985
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date:   Tue Jan 10 09:44:54 2017 -0200

    [media] cec: fix wrong last_la determination
    
    Due to an incorrect condition the last_la used for the initial attempt at
    claiming a logical address could be wrong.
    
    The last_la wasn't converted to a mask when ANDing with type2mask, so that
    test was broken.
    
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

commit 8015d6b83cadc8f9f94c7bc8430255090ddf43d4
Author: Hans Verkuil <hansverk@cisco.com>
Date:   Mon Jan 2 09:54:24 2017 -0200

    [media] cec-intro.rst: mention the v4l-utils package and CEC utilities
    
    Mention where to find the CEC utilities.
    
    Signed-off-by: Hans Verkuil <hansverk@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

commit ed72b81bb7a49e8bfaa8dd6ab0b0e103ff0771ae
Author: Hans Verkuil <hansverk@cisco.com>
Date:   Mon Jan 2 09:41:40 2017 -0200

    [media] cec rst: remove "This API is not yet finalized" notice
    
    The API is now finalized, so this notice should be dropped.
    
    Signed-off-by: Hans Verkuil <hansverk@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

commit 3c223c19aea85d3dda1416c187915f4a30b04b1f
Author: Markus Mayer <mmayer@broadcom.com>
Date:   Mon Dec 19 12:10:28 2016 -0800

    cpufreq: brcmstb-avs-cpufreq: properly retrieve P-state upon suspend
    
    The AVS GET_PMAP command does return a P-state along with the P-map
    information. However, that P-state is the initial P-state when the
    P-map was first downloaded to AVS. It is *not* the current P-state.
    
    Therefore, we explicitly retrieve the P-state using the GET_PSTATE
    command.
    
    Signed-off-by: Markus Mayer <mmayer@broadcom.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 9b02c54bc951fca884ba5719f42a27e8240965bf
Author: Markus Mayer <mmayer@broadcom.com>
Date:   Mon Dec 19 12:10:27 2016 -0800

    cpufreq: brcmstb-avs-cpufreq: extend sysfs entry brcm_avs_pmap
    
    We extend the brcm_avs_pmap sysfs entry (which issues the GET_PMAP
    command to AVS) to include all fields from struct pmap. This means
    adding mode (AVS, DVS, DVFS) and state (the P-state) to the output.
    
    Signed-off-by: Markus Mayer <mmayer@broadcom.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

electrikjesus added a commit to BlissRoms-x86/old_kernel_common that referenced this issue Feb 12, 2017

rtlwifi: rtl8192ce: Fix loading of incorrect firmware
In commit cf4747d ("rtlwifi: Fix regression caused by commit
d86e647, an error in the edit results in the wrong firmware
being loaded for some models of the RTL8188/8192CE. In this condition,
the connection suffered from high ping latency, slow transfer rates,
 and required higher signal strengths to work at all

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853073,
https://bugzilla.opensuse.org/show_bug.cgi?id=1017471, and
lwfinger/rtlwifi_new#203 for descriptions
of the problems. This patch fixes all of those problems.

Fixes: cf4747d ("rtlwifi: Fix regression caused by commit d86e647")
Signed-off-by: Jurij Smakov <jurij@wooyd.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> # 4.9+
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

electrikjesus added a commit to BlissRoms-x86/old_kernel_common that referenced this issue Feb 14, 2017

rtlwifi: rtl8192ce: Fix loading of incorrect firmware
In commit cf4747d ("rtlwifi: Fix regression caused by commit
d86e647, an error in the edit results in the wrong firmware
being loaded for some models of the RTL8188/8192CE. In this condition,
the connection suffered from high ping latency, slow transfer rates,
 and required higher signal strengths to work at all

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853073,
https://bugzilla.opensuse.org/show_bug.cgi?id=1017471, and
lwfinger/rtlwifi_new#203 for descriptions
of the problems. This patch fixes all of those problems.

Fixes: cf4747d ("rtlwifi: Fix regression caused by commit d86e647")
Signed-off-by: Jurij Smakov <jurij@wooyd.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> # 4.9+
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

woodsts pushed a commit to woodsts/linux-stable that referenced this issue Feb 14, 2017

rtlwifi: rtl8192ce: Fix loading of incorrect firmware
commit 52f5631 upstream.

In commit cf4747d ("rtlwifi: Fix regression caused by commit
d86e647, an error in the edit results in the wrong firmware
being loaded for some models of the RTL8188/8192CE. In this condition,
the connection suffered from high ping latency, slow transfer rates,
 and required higher signal strengths to work at all

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853073,
https://bugzilla.opensuse.org/show_bug.cgi?id=1017471, and
lwfinger/rtlwifi_new#203 for descriptions
of the problems. This patch fixes all of those problems.

Fixes: cf4747d ("rtlwifi: Fix regression caused by commit d86e647")
Signed-off-by: Jurij Smakov <jurij@wooyd.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

markgross added a commit to intel/linux-intel-4.9 that referenced this issue Mar 3, 2017

rtlwifi: rtl8192ce: Fix loading of incorrect firmware
commit 52f5631a4c056ad01682393be56d2be237e81610 upstream.

In commit cf4747d ("rtlwifi: Fix regression caused by commit
d86e647, an error in the edit results in the wrong firmware
being loaded for some models of the RTL8188/8192CE. In this condition,
the connection suffered from high ping latency, slow transfer rates,
 and required higher signal strengths to work at all

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853073,
https://bugzilla.opensuse.org/show_bug.cgi?id=1017471, and
lwfinger/rtlwifi_new#203 for descriptions
of the problems. This patch fixes all of those problems.

Fixes: cf4747d ("rtlwifi: Fix regression caused by commit d86e647")
Signed-off-by: Jurij Smakov <jurij@wooyd.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

chunkeey added a commit to chunkeey/rtl8192su that referenced this issue Mar 31, 2017

rtlwifi: rtl8192ce: Fix loading of incorrect firmware
In commit cf4747d7535a ("rtlwifi: Fix regression caused by commit
d86e64768859, an error in the edit results in the wrong firmware
being loaded for some models of the RTL8188/8192CE. In this condition,
the connection suffered from high ping latency, slow transfer rates,
 and required higher signal strengths to work at all

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853073,
https://bugzilla.opensuse.org/show_bug.cgi?id=1017471, and
lwfinger/rtlwifi_new#203 for descriptions
of the problems. This patch fixes all of those problems.

Fixes: cf4747d7535a ("rtlwifi: Fix regression caused by commit d86e64768859")
Signed-off-by: Jurij Smakov <jurij@wooyd.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> # 4.9+
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>

pkshih pushed a commit to pkshih/rtlwifi_sync that referenced this issue Apr 14, 2017

rtlwifi: rtl8192ce: Fix loading of incorrect firmware
In commit cf4747d7535a ("rtlwifi: Fix regression caused by commit
d86e64768859, an error in the edit results in the wrong firmware
being loaded for some models of the RTL8188/8192CE. In this condition,
the connection suffered from high ping latency, slow transfer rates,
 and required higher signal strengths to work at all

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853073,
https://bugzilla.opensuse.org/show_bug.cgi?id=1017471, and
lwfinger/rtlwifi_new#203 for descriptions
of the problems. This patch fixes all of those problems.

Fixes: cf4747d7535a ("rtlwifi: Fix regression caused by commit d86e64768859")
Signed-off-by: Jurij Smakov <jurij@wooyd.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> # 4.9+
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

pkshih pushed a commit to pkshih/rtlwifi_rtl8723de that referenced this issue Dec 29, 2017

rtlwifi: rtl8192ce: Fix loading of incorrect firmware
In commit cf4747d7535a ("rtlwifi: Fix regression caused by commit
d86e64768859, an error in the edit results in the wrong firmware
being loaded for some models of the RTL8188/8192CE. In this condition,
the connection suffered from high ping latency, slow transfer rates,
 and required higher signal strengths to work at all

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853073,
https://bugzilla.opensuse.org/show_bug.cgi?id=1017471, and
lwfinger/rtlwifi_new#203 for descriptions
of the problems. This patch fixes all of those problems.

Fixes: cf4747d7535a ("rtlwifi: Fix regression caused by commit d86e64768859")
Signed-off-by: Jurij Smakov <jurij@wooyd.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> # 4.9+
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment