Bug 981162
| Summary: | BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 comm: Chrome_IOThread Tainted: PF | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | engine.warp | ||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 18 | CC: | engine.warp, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, rhbug | ||||
| Target Milestone: | --- | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2013-11-27 16:11:12 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
engine.warp
2013-07-04 07:17:54 UTC
Forgot to mention that I use also often Skype and Wuala, but I'm forced to close both of them from time to time because they make X process to runaway eating up 100% of one CPU core. I'm still looking on Internet to troubleshoot this issue... Please reopen if you can recreate this without the virtual box and proprietary modules loaded. I'm also getting these on fully up-to-date Fedora 18. Seems to happen when an L2TP/IPSec tunnel gets disconnected (client is running Android 4.2.2 on Linux 3.0.8). This started when I assigned the IP address (the client connects to) directly to the server, before it was behind a NAT router which has now been set to bridge mode. On the client side there is a NAT setup, I'm using these static xfrm policies because racoon uses the wrong ip for them in case of NAT. src 0.0.0.0/0 dst my.glo.bal.ip/32 proto udp dport 1701 dir in priority 0 ptype main tmpl src 0.0.0.0 dst 0.0.0.0 proto esp reqid 0 mode transport src my.glo.bal.ip/32 dst 0.0.0.0/0 proto udp sport 1701 dir out priority 0 ptype main tmpl src 0.0.0.0 dst 0.0.0.0 proto esp reqid 0 mode transport The machine completely freezes (sometimes with keyboard leds flashing) 10-60 seconds after the Oops, most of the time with just the messages about pppd terminating logged between. Earlier today it logged some more backtraces before locking up, I will attach the log for that occurence. Created attachment 770125 [details]
/var/log/messages
I've uninstalled virtual box, but I don't know what you mean for proprietary modules, is that the NVIDIA drivers? I hope not. Anyway I'll try with virtual box uninstalled, if the freeze happen again I will post here the logs and re-open the issue. PS. Will the new kernel 3.9.8 be released soon for F18? I saw it have a patch for an oops which happen with the old kernel, might be related with this problem? Removing Virtual Box looks like does fix the issue. So far uptime is 4h hours and no error or crash have occurred. Though I would like to push this to the 8h at least before calling the truce. If this indeed is the source of the issue, what about then? Should I open an issue for the virtual box application instead? With Oracle? This is a supported and distributed package from Fedora repo, I don't know exactly how to proceed in this case. Thanks! I Reopen this, I've talk to early... Just crashed after more or less 5h uptime. I was editing a txt file with kwrite and then suddenly without any warning or error the mouse froze and all the led started blinking. I've rebooted with the power button and there's no error message in the /var/log/messages. If you need any other logs just let me know. Yes, the proprietary module is the nVidia module. Please recreate without that. As for 3.9.8 in F18, we have 3.9.9 in updates-testing at the moment. 3.9.8 will be skipped. Thanks, So far I've been able to reproduce the issue with the nouveau driver too, as I said in my description the issue was first shown with the open source drivers and in an effort to solve it I've try the proprietary drivers NVIDIA. Also because with nouveau driver some time X was giving some errors. In my latest attempt I've been able to check that the problem seems indeed related with my VPN connection. When I connect it is more likely that the crash occur in a less time span then 2h. Uptime 2:49h looks like disabling the NAT Traversal in the VPN might do the trick, but I still want to wait till an uptime of 8h and VPN connected. Will update on results tomorrow then. Anyway if it's the NAT it should not crash the system like this... Nope it has just happened again, another crash same behavior this time it took much more to crash (+5h) but it did it again same modality as before. Looks like indeed the issue might be related with the network, I'm using wlan0 to connect to my router. This time the screen was off after 20min of inactivity and when I was back I found the led blinking and the computer was completely unresponsive, forcing me to shutdown with the power button. The VPN was up without NET Traversal which seem to have an impact to the issue anyway, but it could be just random as I said in my first post. In the messages log there's nothing this time, before the crash there was this: .............. Jul 8 19:43:29 marco-DellPrecisionM6300 dbus-daemon[582]: dbus[582]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Jul 8 19:43:29 marco-DellPrecisionM6300 dbus[582]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Jul 8 19:43:29 marco-DellPrecisionM6300 dbus-daemon[582]: dbus[582]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Jul 8 19:43:29 marco-DellPrecisionM6300 dbus[582]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Jul 8 19:46:41 marco-DellPrecisionM6300 dbus-daemon[582]: dbus[582]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Jul 8 19:46:41 marco-DellPrecisionM6300 dbus[582]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Jul 8 19:46:41 marco-DellPrecisionM6300 dbus-daemon[582]: dbus[582]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Jul 8 19:46:41 marco-DellPrecisionM6300 dbus[582]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Jul 8 19:47:56 marco-DellPrecisionM6300 dbus-daemon[582]: dbus[582]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Jul 8 19:47:56 marco-DellPrecisionM6300 dbus[582]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Jul 8 19:47:56 marco-DellPrecisionM6300 dbus-daemon[582]: dbus[582]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Jul 8 19:47:56 marco-DellPrecisionM6300 dbus[582]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Jul 8 19:49:11 marco-DellPrecisionM6300 dbus-daemon[582]: dbus[582]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Jul 8 19:49:11 marco-DellPrecisionM6300 dbus[582]: [system] Activating service name='org.kde.powerdevil.backlighthelper' (using servicehelper) Jul 8 19:49:11 marco-DellPrecisionM6300 dbus-daemon[582]: dbus[582]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Jul 8 19:49:11 marco-DellPrecisionM6300 dbus[582]: [system] Successfully activated service 'org.kde.powerdevil.backlighthelper' Here we go again, it just crashed. I've tried to disable wlan0 and use wired network instead but it did not work. Looks like the issue is VPN dependent. I'm from now using a VM to enable the VPN from within it and work from there. Let's see if in this way I can work around the issue. Anyway I've discovered that the VPN I use, tunnel on a lan which have the same addresses pool that I have in my lan, so the addresses below 192.168.1.93 are mapped on my lan and the others are in the VPN lan. This might be the cause of the issue but still IMHO it should not result in a crash of the system. If working from a VM with the VPN, do not crash anymore the system then this is it, I'll update the thread after few hours of testing. uptime 8:36 minutes! Ok I think the problem was found and it is the VPN. Anyway as I said before it should not crash the system, I think this should be investigated further in order to fix it at least in the next Kernel release. This issue disappeared for me after updating to kernel-3.9.9-201.fc18.x86_64 *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is 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 18 kernel bugs. Fedora 18 has now been rebased to 3.11.4-101.fc18. 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 19, and are still experiencing this issue, please change the version to Fedora 19. If you experience different issues, please open a new bug report for those. *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. It has been over a month since we asked you to test the 3.11 kernel updates and let us know if your issue has been resolved or is still a problem. When this happened, the bug was set to needinfo. Because the needinfo is still set, we assume either this is no longer a problem, or you cannot provide additional information to help us resolve the issue. As a result we are closing with insufficient data. If this is still a problem, we apologize, feel free to reopen the bug and provide more information so that we can work towards a resolution If you experience different issues, please open a new bug report for those. The problem was due to VPN connection which was forced with an IP of the same LAN where the computer was connected. So the VPN has for instance 192.168.1.34 and the LAN had 192.168.1.20. This seam to trigger the Kernel panic after a couple of hours so that is why it was difficult to identify, but testing without having this VPN configuration resulted in no problem. |