Created attachment 1401983 [details] /var/log/messages grep from Feb 28 happened twice (in the morning and at 14:11) Description of problem: I have Fedora 27 running on a Thinkpad E460. I connect my iPhone for USB internet tethering and every time (after 5 or so minutes) KDE / Gnome (tried both) just freezes and I have to do a hard reset. Is the phone attempting to draw too much power or something? Version-Release number of selected component (if applicable): - Fedora 27 - iPhone 7 Plus / iOS 11.2.6 - ThinkPad T460 How reproducible: Easily Steps to Reproduce: 1. Turn on iPhone tethering. 2. Connect the iPhone on USB power in a ThinkPad T4xx family. 3. Open Firefox and start browsing. The freezing will eventually happen. Actual results: The system just freezes. Needs a hard reset every time. Expected results: That the system doesn't freezes during tethering. Additional info: This bug was also "reported" on Fedora 25 at this Reddit thread [1]. The problem just happened today (Feb 28) at 14:11. Logs attached. [1] - https://www.reddit.com/r/Fedora/comments/63dvit/fedora_25_freezes_on_usb_internet_tethering/
Hi Ricardo, you probably filed the bug against the wrong component. Anyway, I given a look at the log you provided: at 8:56 NetworkManager detects your iPhone exposed network interface (on usb) as ethernet device enp0s20f0u1c4i2: then spawns for you a connection and get the IP config via DHCP. From that point on you can navigate and connect to the VPN too. at 10:14 something happens. Nothing bad is tracked in the logs but logs show a reboot just after. The only think that I can see is that last thing logs says was going on, is NetworkManager requesting a scan to the wireless interface. I guess that when you don't use the iPhone to connect you are associated to a Wireless Network, keeping your WiFi device busy. The first thing I would do is to try to switch your WiFi device off while you are connecting via the iPhone. As easy as opening a terminal and doing a: nmcli radio wifi off (when you need your wifi connectivity back, a "nmcli radio wifi on" will restore it) Please, as a first step, check if this fixes your issue. Thanks
Hi Francisco! Many thanks for your quick reply!! My answers are listed bellow: >> you probably filed the bug against the wrong component. R. Yeah, probably! I really didn't know where to filed, that put I'll really appreciate any direction you could give to right path. >> at 10:14 something happens. Nothing bad is tracked in the logs but logs show a reboot just after. R. The system locked about this time, so I made a hard reset. >> The only think that I can see is that last thing logs says was going on, is NetworkManager requesting a scan to the wireless interface. I guess that when you don't use the iPhone to connect you are associated to a Wireless Network, keeping your WiFi device busy. R. Indeed we've spotted this behavior yesterday while filing this BZ. I've turned the WiFi off and so far so good! >> The first thing I would do is to try to switch your WiFi device off while you are connecting via the iPhone. R. Yeah! Today I'm going to do the final test by leaving the WiFi device off all the day long while tethering. If this experiment works, do you think it would be possible to have a fix or a note somewhere to alert the community about this? :) Many thanks!
If with the WiFi switched off the issue disappears I would do another test: I would disable the MAC address randomization during background scans. It is as easy as putting in your /etc/NetworkManager/NetworkManager.conf a new section: [device] wifi.scan-rand-mac-address=no Then simply reboot... or if you prefer, just trigger a reload in NetworkManager conf: sudo kill -SIGHUP `pidof NetworkManager Be sure you let the WiFi device enabled so that the background scanning is triggered. If everything seems to work... well, please use it for a few days to be sure it fixes the issue.
Created attachment 1402647 [details] /var/log/messages grep from Mar 1
Created attachment 1402648 [details] spool from adrcli
Hi Francesco! Happened again even with the WiFi device disabled. I'm attaching the log files and the spool generated after the kernel panic. Happened twice (~09:44 and at 13:46). I'll proceed to test your next suggestion. Many thanks!
(In reply to Ricardo Zanini from comment #6) > Hi Francesco! > > Happened again even with the WiFi device disabled. I'm attaching the log > files and the spool generated after the kernel panic. Happened twice (~09:44 > and at 13:46). > > I'll proceed to test your next suggestion. Well, I guess this is not needed: if the WiFi device was disabled (WiFi switched off, so that no background scanning was performed) that further test would be used. Reassigning to kernel, hoping the could shed some light on this.
Many thanks for your help, Francesco.
Hi Ricardo, Although I do see a kernel warning in the logs, it happened at 10:11. I see both reboots at the time you indicated so I assume the problem happened just prior to those reboots. Is this a problem that just started happening, or has it happened as long as you've had the hardware? When the laptop seems to freeze, can you press a button on the keyboard that has an LED (caps lock, perhaps) and does the LED turn on/off? Is it possible to SSH to the laptop when it is frozen?
(In reply to Jeremy Cline from comment #9) > Hi Ricardo, > > Although I do see a kernel warning in the logs, it happened at 10:11. I see > both reboots at the time you indicated so I assume the problem happened just > prior to those reboots. > > Is this a problem that just started happening, or has it happened as long as > you've had the hardware? When the laptop seems to freeze, can you press a > button on the keyboard that has an LED (caps lock, perhaps) and does the LED > turn on/off? Is it possible to SSH to the laptop when it is frozen? Hi Jeremy, Thanks for your attention on this ticket. I've been experiencing this behaviour since Fedora 25 in this same hardware. I've turned the following parameters on and now when this problem arise, the machine just boots (I hope to see something on /var/crash, but nothing so far): kernel.hardlockup_panic = 1 kernel.panic = 1 kernel.panic_on_io_nmi = 1 kernel.panic_on_oops = 0 kernel.panic_on_rcu_stall = 0 kernel.panic_on_stackoverflow = 1 kernel.panic_on_unrecovered_nmi = 0 kernel.panic_on_warn = 0 kernel.softlockup_panic = 1 kernel.unknown_nmi_panic = 1 I've never tried to ssh into it (didn't have the resources to do it). Do I have to turn it off again? But to answer your question stricly, I all keyboard buttons freezes as well. The only button that responds was the turn on/off that's how I've been doing the hard reset.
Reproduced on a Dell E7470 on Fedora 28 ( all kernels impacted, up to 4.16.14-300). I connect my iPhone 6 Plus on USB, then enables the network tethering, after 10/20mn of internet usage, the system hangs ( no led answers when i press capslock/numlock), i have to do a hard reboot
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs. Fedora 27 has now been rebased to 4.17.7-100.fc27. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 5 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
Reproduced on a Lenovo T480s + iPhone 7 Plus. The kernel version is 4.19.4-300.fc29.x86_64, there is nothing present in /var/crash.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.