Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
First Last Prev Next    This bug is not in your last search results.
Bug 669373 - ath9k: inconsistent lock state
ath9k: inconsistent lock state
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
6.1
Unspecified Unspecified
low Severity medium
: rc
: ---
Assigned To: Stanislaw Gruszka
desktop-bugs@redhat.com
:
Depends On:
Blocks:
  Show dependency tree / graph
 
Reported: 2011-01-13 09:17 EST by Stanislaw Gruszka
Modified: 2011-05-23 16:37 EDT (History)
3 users (show)

See Also:
Fixed In Version: kernel-2.6.32-112.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-05-23 16:37:34 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)
Add an attachment (proposed patch, testcase, etc.)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0542 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 6.1 kernel security, bug fix and enhancement update 2011-05-19 07:58:07 EDT

  None (edit)
Description Stanislaw Gruszka 2011-01-13 09:17:29 EST 
Description of problem:

> =================================
> [ INFO: inconsistent lock state ]
> 2.6.32-94.el6.bz621103.x86_64.debug #1
> ---------------------------------
> inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
> wpa_supplicant/8534 [HC0[0]:SC0[0]:HE1:SE1] takes:
>  (&txq->axq_lock){+.?...}, at: [<ffffffffa02fb449>] ath_tx_node_cleanup+0x79/0x190 [ath9k]
> {IN-SOFTIRQ-W} state was registered at:
>   [<ffffffff810a747a>] __lock_acquire+0x5da/0x1590
>   [<ffffffff810a84d4>] lock_acquire+0xa4/0x120
>   [<ffffffff814f6edb>] _spin_lock_bh+0x3b/0x70
>   [<ffffffffa02fcfbc>] ath_tx_tasklet+0x18c/0x4b0 [ath9k]
>   [<ffffffffa02f65d0>] ath9k_tasklet+0xc0/0x110 [ath9k]
>   [<ffffffff8106ea06>] tasklet_action+0xe6/0xf0
>   [<ffffffff8106f715>] __do_softirq+0xd5/0x220
>   [<ffffffff8100c3cc>] call_softirq+0x1c/0x30
>   [<ffffffff8100e0cd>] do_softirq+0xad/0xe0
>   [<ffffffff8106f305>] irq_exit+0x95/0xa0
>   [<ffffffff814fc4f5>] do_IRQ+0x75/0xf0
>   [<ffffffff8100bb53>] ret_from_intr+0x0/0x16
>   [<ffffffff81009e9b>] cpu_idle+0xbb/0x110
>   [<ffffffff814eca03>] start_secondary+0x20b/0x24e
> irq event stamp: 29523
> hardirqs last  enabled at (29523): [<ffffffff814f6c30>] _spin_unlock_irqrestore+0x40/0x80
> hardirqs last disabled at (29522): [<ffffffff814f6fc2>] _spin_lock_irqsave+0x32/0xa0
> softirqs last  enabled at (29518): [<ffffffffa02b1f84>] __ieee80211_key_todo+0x244/0x320 [mac80211]
> softirqs last disabled at (29516): [<ffffffff814f6ebc>] _spin_lock_bh+0x1c/0x70
> 
> other info that might help us debug this:
> 4 locks held by wpa_supplicant/8534:
>  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81443937>] rtnl_lock+0x17/0x20
>  #1:  (&wdev->mtx){+.+.+.}, at: [<ffffffffa0277839>] cfg80211_wext_siwmlme+0x69/0xb0 [cfg80211]
>  #2:  (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa02a4d40>] ieee80211_mgd_deauth+0x30/0x120 [mac80211]
>  #3:  (&local->sta_mtx){+.+.+.}, at: [<ffffffffa029cb07>] sta_info_destroy_addr+0x27/0x60 [mac80211]
> 
> stack backtrace:
> Pid: 8534, comm: wpa_supplicant Not tainted 2.6.32-94.el6.bz621103.x86_64.debug #1
> Call Trace:
>  [<ffffffff810a5127>] print_usage_bug+0x177/0x180
>  [<ffffffff810a60dd>] mark_lock+0x35d/0x430
>  [<ffffffff810a74dc>] __lock_acquire+0x63c/0x1590
>  [<ffffffff810a2e0b>] ? add_lock_to_list+0x5b/0xf0
>  [<ffffffff810a791e>] ? __lock_acquire+0xa7e/0x1590
>  [<ffffffffa029c67f>] ? __sta_info_destroy+0xff/0x360 [mac80211]
>  [<ffffffffa029c67f>] ? __sta_info_destroy+0xff/0x360 [mac80211]
>  [<ffffffff810a84d4>] lock_acquire+0xa4/0x120
>  [<ffffffffa02fb449>] ? ath_tx_node_cleanup+0x79/0x190 [ath9k]
>  [<ffffffff810957a5>] ? sched_clock_local+0x25/0x90
>  [<ffffffff81013263>] ? native_sched_clock+0x13/0x60
>  [<ffffffff814f6e66>] _spin_lock+0x36/0x70
>  [<ffffffffa02fb449>] ? ath_tx_node_cleanup+0x79/0x190 [ath9k]
>  [<ffffffffa02fb449>] ath_tx_node_cleanup+0x79/0x190 [ath9k]
Comment 2 RHEL Product and Program Management 2011-01-14 05:52:28 EST 
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.
Comment 4 Stanislaw Gruszka 2011-01-28 10:35:28 EST 
100% on debug kernel, you have to stop interface (i.e. click "disconnect" on NetworkManager window). You can set this OtherQA, since I'm able to reproduce with minimal effort.
Comment 6 Aristeu Rozanski 2011-02-03 11:18:33 EST 
Patch(es) available on kernel-2.6.32-112.el6
Comment 9 Vladimir Benes 2011-04-29 11:35:37 EDT 
cannot see any error on -130 kernel when disconnecting fast speed download either via disconnect in nm-applet, ifconfig wlanX down or or modprobe -r ath9k
-> VERIFIED
Comment 10 errata-xmlrpc 2011-05-23 16:37:34 EDT 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0542.html
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.