Bug 587727 - kerneloops after wireless connection established
kerneloops after wireless connection established
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On: 585072
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-30 13:44 EDT by John W. Linville
Modified: 2010-06-15 21:46 EDT (History)
9 users (show)

See Also:
Fixed In Version: kernel-2.6.32.12-115.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 585072
Environment:
Last Closed: 2010-06-14 17:09:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John W. Linville 2010-04-30 13:44:02 EDT
+++ This bug was initially created as a clone of Bug #585072 +++

Description of problem: Right after I tried to connect to my wireless network (successfully), I came with a kerneloops error. (I reported this once on Fedora 12 too, but at first I thought it had something to do with VirtualBox).


How reproducible: Simply connected to my wireless network, and abrt said there was a kerneloops.


Additional info: Info direct from abrt:

------------[ cut here ]------------
WARNING: at kernel/softirq.c:143 _local_bh_enable_ip+0x3e/0xab()
Hardware name: Aspire 6530      
Modules linked in: aes_i586 aes_generic fuse sunrpc cpufreq_ondemand powernow_k8 ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 uinput snd_hda_codec_atihdmi microcode snd_hda_codec_realtek arc4 ecb uvcvideo videodev v4l1_compat snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device k10temp hwmon joydev snd_pcm serio_raw ath9k ath9k_common i2c_piix4 mac80211 ath9k_hw ath cfg80211 snd_timer rfkill snd soundcore atl1e snd_page_alloc wmi pata_acpi ata_generic usb_storage pata_atiixp video output radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
Pid: 1144, comm: wpa_supplicant Not tainted 2.6.33.2-57.fc13.i686 #1
Call Trace:
[<c043b55a>] warn_slowpath_common+0x6a/0x81
[<c0441149>] ? _local_bh_enable_ip+0x3e/0xab
[<f901696a>] ? ath_tx_node_cleanup+0xee/0x106 [ath9k]
[<c043b583>] warn_slowpath_null+0x12/0x15
[<c0441149>] _local_bh_enable_ip+0x3e/0xab
[<c04411c3>] local_bh_enable_ip+0xd/0xf
[<c07b41e8>] _raw_spin_unlock_bh+0x2a/0x2d
[<f901696a>] ath_tx_node_cleanup+0xee/0x106 [ath9k]
[<f9012339>] ath9k_sta_notify+0x79/0x7d [ath9k]
[<f8fa26a5>] __sta_info_unlink+0x11b/0x171 [mac80211]
[<f90122c0>] ? ath9k_sta_notify+0x0/0x7d [ath9k]
[<f8fa2723>] sta_info_unlink+0x28/0x36 [mac80211]
[<f8fa78f0>] ieee80211_set_disassoc+0x18a/0x19f [mac80211]
[<f8fa7db9>] ieee80211_mgd_deauth+0x42/0x104 [mac80211]
[<c04624c1>] ? mark_held_locks+0x43/0x5b
[<f8fad1d1>] ieee80211_deauth+0x19/0x1b [mac80211]
[<f8ecd98c>] __cfg80211_mlme_deauth+0xf0/0xf9 [cfg80211]
[<f8ecfc99>] __cfg80211_disconnect+0xee/0x154 [cfg80211]
[<f8ed27f4>] cfg80211_wext_siwmlme+0x64/0x86 [cfg80211]
[<c079992a>] ioctl_standard_call+0x1f5/0x29e
[<f8ed2790>] ? cfg80211_wext_siwmlme+0x0/0x86 [cfg80211]
[<c072516b>] ? dev_name_hash+0x1b/0x4d
[<c0799aca>] wext_handle_ioctl+0xf7/0x181
[<f8ed2790>] ? cfg80211_wext_siwmlme+0x0/0x86 [cfg80211]
[<c0729a26>] dev_ioctl+0x546/0x577
[<c0718f32>] sock_ioctl+0x1e9/0x1f5
[<c04eb565>] vfs_ioctl+0x2c/0x96
[<c0718d49>] ? sock_ioctl+0x0/0x1f5
[<c04ebb18>] do_vfs_ioctl+0x49b/0x4d9
[<c058ea59>] ? selinux_file_ioctl+0x43/0x46
[<c04ebb9c>] sys_ioctl+0x46/0x66
[<c07b4434>] syscall_call+0x7/0xb

Running fully updated Fedora 13 with all repos enabled, i686.

--- Additional comment from dmaxel@fedoraproject.org on 2010-04-24 21:43:32 EDT ---

Looking on the kerneloops.org site, there seem to be a lot of ath_tx_node_cleanup errors, just like the problem that I have.

--- Additional comment from nospam@thenerdshow.com on 2010-04-26 15:54:38 EDT ---

This happens to me sometimes when connecting under load. Sometimes with firefox running. VirtualBox would be a good candidate. Basically anything that uses CPU. 

I get a similar kernel oops when waking up from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=15839

In the latter case, Xorg is hogging CPU cycles. The common thread seems to be CPU usage.

--- Additional comment from linville@redhat.com on 2010-04-27 15:16:17 EDT ---

I suspect this relates to an earlier patch which fixed a lockdep warning.  I have reverted that patch in the test kernels here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2141465

Could you give those a try and see if the oops you are seeing disappears?

--- Additional comment from nospam@thenerdshow.com on 2010-04-27 16:32:44 EDT ---

The kernel oops stopped happening yesterday after reporting it and has not returned.

 tail yum.log

Apr 25 15:00:08 Updated: nautilus-2.30.0-3.fc13.x86_64
Apr 25 15:00:09 Updated: nautilus-extensions-2.30.0-3.fc13.x86_64
Apr 25 15:00:11 Updated: libchamplain-0.4.5-1.fc13.x86_64
Apr 25 15:00:12 Updated: libchamplain-gtk-0.4.5-1.fc13.x86_64
Apr 25 15:00:13 Updated: schroedinger-1.0.9-2.fc13.x86_64
Apr 25 15:00:26 Updated: gcalctool-5.30.0-2.fc13.x86_64
Apr 25 15:00:28 Updated: taglib-1.6.3-1.fc13.x86_64
Apr 25 15:00:29 Updated: prelink-0.4.3-3.fc13.x86_64
Apr 25 15:00:31 Updated: telepathy-butterfly-0.5.9-1.fc13.noarch
Apr 27 01:11:50 Installed: gpm-libs-1.20.6-9.fc13.x86_64
Apr 27 01:11:52 Installed: nss_compat_ossl-0.9.6-1.fc13.x86_64
Apr 27 01:11:53 Installed: 1:links-2.2-12.fc13.x86_64
Apr 27 08:36:26 Installed: lshw-B.02.14-3.fc12.x86_64

--- Additional comment from dmaxel@fedoraproject.org on 2010-04-27 18:55:28 EDT ---

Went ahead and installed kernel-2.6.33.2-68.bz585072.fc13.i686.rpm and kernel-headers-2.6.33.2-68.bz585072.fc13.i686.rpm...so far there are no more errors/oopses, but I only have it installed for about 20 minutes, so I'll need to use it a bit longer before I can say for sure.

--- Additional comment from dmaxel@fedoraproject.org on 2010-04-27 19:49:47 EDT ---

OK, suggestion that I tried out seems to work...no more kernel oops problems.

--- Additional comment from linville@redhat.com on 2010-04-28 09:45:50 EDT ---

Alright, that at least points at the problem -- unfortunately, that patch was also fixing a problem.  Hopefully we can find a solution for both issues...

--- Additional comment from linville@redhat.com on 2010-04-28 10:41:45 EDT ---

Scratch that last comment -- it looks like that patch was mistakenly backported to the stable kernel series for 2.6.33...

--- Additional comment from dmaxel@fedoraproject.org on 2010-04-28 12:05:52 EDT ---

So that means that the patch is no longer needed? So removing it would still have both problems solved?

--- Additional comment from linville@redhat.com on 2010-04-28 13:29:12 EDT ---

Yes -- that is to say that applying my patch to revert the other should resolve the issue you reported here while avoiding the problem that the problematic patch was intended to solve.

http://koji.fedoraproject.org/koji/buildinfo?buildID=169229

--- Additional comment from updates@fedoraproject.org on 2010-04-28 14:16:45 EDT ---

kernel-2.6.33.3-72.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/kernel-2.6.33.3-72.fc13
Comment 1 Fedora Update System 2010-04-30 18:32:27 EDT
kernel-2.6.32.12-115.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/kernel-2.6.32.12-115.fc12
Comment 2 Fedora Update System 2010-05-03 12:04:09 EDT
kernel-2.6.32.12-115.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kernel-2.6.32.12-115.fc12
Comment 3 Ronald Wells 2010-05-06 12:48:30 EDT
I think my problem is more accurately described by this bug:https://bugzilla.redhat.com/show_bug.cgi?id=544497
but that bug has been closed and I was referred to this bug.

I am using fedora 12 on an atom based system that uses an Atheros AR9285 wireless card (so ath9k driver) and trying to configure as an access point using hostapd 0.6.9-7 (also have tried 0.7.2).  I've also tried updating the ath9k driver using compat-wireless with no help.

I've tried this updated kernel (kernel-2.6.32.12-115.fc12.i686), the good news is that I don't get the kernel crash report in the messages log.  The bad news is that I still loose wireless connectivity (just no reports in the log) or the system just totally locks up and becomes unresponsive.  Here's what I get in the main-line (kernel 2.6.32.11-99.fc12.i686):

May  6 11:10:25 localhost hostapd: wlan0: STA 00:18:f3:49:f5:d2 IEEE 802.11: deauthenticated due to local deauth request
May  6 11:10:25 localhost kernel: ------------[ cut here ]------------
May  6 11:10:25 localhost kernel: WARNING: at kernel/softirq.c:143 _local_bh_enable_ip+0x3b/0x77()
May  6 11:10:25 localhost kernel: Hardware name: nT-330i
May  6 11:10:25 localhost kernel: Modules linked in: aes_i586 aes_generic ipt_MASQUERADE iptable_nat nf_nat ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 snd_hda_codec_nvhdmi snd_hda_codec_realtek arc4 snd_hda_intel ecb snd_hda_codec snd_hwdep ath9k snd_seq snd_seq_device mac80211 snd_pcm snd_timer snd ath soundcore cfg80211 wmi i2c_nforce2 serio_raw snd_page_alloc atl1c rfkill usb_storage nouveau ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
May  6 11:10:25 localhost kernel: Pid: 1281, comm: hostapd Not tainted 2.6.32.11-99.fc12.i686 #1
May  6 11:10:25 localhost kernel: Call Trace:
May  6 11:10:25 localhost kernel: [<c043a479>] warn_slowpath_common+0x6a/0x81
May  6 11:10:25 localhost kernel: [<c0440da3>] ? _local_bh_enable_ip+0x3b/0x77
May  6 11:10:25 localhost kernel: [<c043a4a2>] warn_slowpath_null+0x12/0x15
May  6 11:10:25 localhost kernel: [<c0440da3>] _local_bh_enable_ip+0x3b/0x77
May  6 11:10:25 localhost kernel: [<c0440dec>] local_bh_enable_ip+0xd/0xf
May  6 11:10:25 localhost kernel: [<c079383b>] _spin_unlock_bh+0x13/0x15
May  6 11:10:25 localhost kernel: [<fb10254e>] ath_tx_node_cleanup+0xf3/0x10b [ath9k]
May  6 11:10:25 localhost kernel: [<c041fe00>] ? native_irq_disable+0x8/0xb
May  6 11:10:25 localhost kernel: [<c058917b>] ? selinux_netlink_recv+0x58/0x73
May  6 11:10:25 localhost kernel: [<fb0fe9d2>] ath9k_sta_notify+0x79/0x7d [ath9k]
May  6 11:10:25 localhost kernel: [<fb07b345>] __sta_info_unlink+0x11e/0x16e [mac80211]
May  6 11:10:25 localhost kernel: [<fb0fe959>] ? ath9k_sta_notify+0x0/0x7d [ath9k]
May  6 11:10:25 localhost kernel: [<fb07b3bd>] sta_info_unlink+0x28/0x36 [mac80211]
May  6 11:10:25 localhost kernel: [<fb08636d>] ? ieee80211_del_station+0x0/0x52 [mac80211]
May  6 11:10:25 localhost kernel: [<fb0863a6>] ieee80211_del_station+0x39/0x52 [mac80211]
May  6 11:10:25 localhost kernel: [<fab877c8>] nl80211_del_station+0x70/0x92 [cfg80211]
May  6 11:10:25 localhost kernel: [<c0722978>] genl_rcv_msg+0x1a7/0x1c4
May  6 11:10:25 localhost kernel: [<c07227d1>] ? genl_rcv_msg+0x0/0x1c4
May  6 11:10:25 localhost kernel: [<c0721afe>] netlink_rcv_skb+0x35/0x7b
May  6 11:10:25 localhost kernel: [<c07227ca>] genl_rcv+0x20/0x27
May  6 11:10:25 localhost kernel: [<c0721920>] netlink_unicast+0xec/0x149
May  6 11:10:25 localhost kernel: [<c0721fd3>] netlink_sendmsg+0x21b/0x228
May  6 11:10:25 localhost kernel: [<c06fde28>] __sock_sendmsg+0x4a/0x53
May  6 11:10:25 localhost kernel: [<c06fe4a1>] sock_sendmsg+0xbb/0xd1
May  6 11:10:25 localhost kernel: [<c06fe4a1>] ? sock_sendmsg+0xbb/0xd1
May  6 11:10:25 localhost kernel: [<c0454371>] ? autoremove_wake_function+0x0/0x34
May  6 11:10:25 localhost kernel: [<c05be4bf>] ? might_fault+0x1e/0x20
May  6 11:10:25 localhost kernel: [<c05be4f3>] ? copy_from_user+0x32/0x119
May  6 11:10:25 localhost kernel: [<c0706052>] ? verify_iovec+0x43/0x71
May  6 11:10:25 localhost kernel: [<c06fe643>] sys_sendmsg+0x18c/0x1f0
May  6 11:10:25 localhost kernel: [<c04870c3>] ? call_rcu_sched+0x12/0x14
May  6 11:10:25 localhost kernel: [<c04870d2>] ? call_rcu+0xd/0xf
May  6 11:10:25 localhost kernel: [<c05bae57>] ? radix_tree_delete+0xe5/0x171
May  6 11:10:25 localhost kernel: [<c05020ef>] ? fsnotify_clear_marks_by_inode+0x21/0xa2
May  6 11:10:25 localhost kernel: [<c06fd79d>] ? sock_destroy_inode+0x15/0x17
May  6 11:10:25 localhost kernel: [<c04eae64>] ? destroy_inode+0x24/0x35
May  6 11:10:25 localhost kernel: [<c04e88d6>] ? __d_free+0x3d/0x40
May  6 11:10:25 localhost kernel: [<c04e8903>] ? d_free+0x2a/0x3c
May  6 11:10:25 localhost kernel: [<c04ee3f0>] ? mntput_no_expire+0x1e/0xba
May  6 11:10:25 localhost kernel: [<c06ff97b>] sys_socketcall+0x163/0x195
May  6 11:10:25 localhost kernel: [<c040abae>] ? syscall_trace_leave+0xaa/0xbd
May  6 11:10:25 localhost kernel: [<c040365c>] syscall_call+0x7/0xb
May  6 11:10:25 localhost kernel: ---[ end trace fb82fbc53375f354 ]---
May  6 11:10:31 localhost hostapd: wlan0: STA 00:18:f3:49:f5:d2 IEEE 802.11: authenticated
May  6 11:10:31 localhost hostapd: wlan0: STA 00:18:f3:49:f5:d2 IEEE 802.11: associated (aid 1)
May  6 11:10:31 localhost hostapd: wlan0: STA 00:18:f3:49:f5:d2 RADIUS: starting accounting session 4BE2E796-00000001
May  6 11:10:31 localhost hostapd: wlan0: STA 00:18:f3:49:f5:d2 WPA: pairwise key handshake completed (RSN)
May  6 11:20:22 localhost hostapd: wlan0: STA 00:18:f3:49:f5:d2 WPA: group key handshake completed (RSN)

Please let me know if there is any additional information I can provide to help figure out what is causing the problem.
Comment 4 Ronald Wells 2010-06-15 09:20:39 EDT
Ok, this is frustrating.. Now TWO bugs that have to do with the issues i'm having have been closed and it's still not working for me.  Am I not doing something correctly when I post to the bug since there was no response to my last post and the bug was just closed without any type of resolution that I can see???

Thanks,
Ron
Comment 5 John W. Linville 2010-06-15 13:55:03 EDT
Ron, you need to ensure that your comments are pertinent to the bug where you make them.  In the first case, you commented in bug 544497 about what seems to have been the same issue as the one that prompted this bug.  So, I asked you to test -115.fc12 and comment on this bug.  In comment 3, you seem to confirm that -115.fc12 resovle the issue for you ("the good news is that I don't get the kernel crash report in the messages log").

Unfortunately, you went on to comment about an issue that is not at all clearly related.  Rather than discussing the other issue here, you would be better off opening a new bug for that issue.
Comment 6 Ronald Wells 2010-06-15 14:08:04 EDT
John, Thanks for your response.  I think the issue is still releated, but that the system is crashing harder and therefore no logging happens, I think my post wasn't clear on that.  Basically the same thing happens that happened before but the system just locks up.  I'll do as you suggest and open a new bug, I'm just not sure what I'll post since the logs (as far as I can tell) aren't giving any useful information.
Comment 7 Henry Kroll 2010-06-15 21:46:49 EDT
2.6.33.5-112.fc13.x86_64 x86_64 is working great for me, Ron, aside from the usual Xorg slowness recovering from suspend. It reconnects to wireless and does not crash. I know it's a whale of a solution, but perhaps you could try upgrading to F13.

Note You need to log in before you can comment on or make changes to this bug.