[PATCH] ath5k : ath5k_config_interface deadlock fix

[PATCH] ath5k : ath5k_config_interface deadlock fix

[Dave Young]

In the drivers/net/wireless/ath5k/base.c, there's recursive locking of sc->lock
This casue the kernel stuck

Bug report please see:
http://lkml.org/lkml/2008/7/29/32

Fixed it by remove the lock in sub routine "ath5k_beacon_update",
The ath5k_config_interface is the only caller to it.

[  171.430207] =============================================
[  171.432140] [ INFO: possible recursive locking detected ]
[  171.433113] 2.6.27-rc1-smp #4
[  171.434079] ---------------------------------------------
[  171.435039] ath5k_pci/2447 is trying to acquire lock:
[  171.435990]  (&sc->lock){--..}, at: [<f89ee9b5>] ath5k_config_interface+0xd5/0x340 [ath5k]
[  171.437046] 
[  171.437048] but task is already holding lock:
[  171.438903]  (&sc->lock){--..}, at: [<f89ee91d>] ath5k_config_interface+0x3d/0x340 [ath5k]
[  171.439953] 
[  171.439954] other info that might help us debug this:
[  171.441795] 3 locks held by ath5k_pci/2447:
[  171.442729]  #0:  ((name)){--..}, at: [<c013a122>] run_workqueue+0x102/0x1d0
[  171.443800]  #1:  (&(&local->scan_work)->work){--..}, at: [<c013a122>] run_workqueue+0x102/0x1d0
[  171.444859]  #2:  (&sc->lock){--..}, at: [<f89ee91d>] ath5k_config_interface+0x3d/0x340 [ath5k]
[  171.445941] 
[  171.445942] stack backtrace:
[  171.447791] Pid: 2447, comm: ath5k_pci Not tainted 2.6.27-rc1-smp #4
[  171.448732]  [<c014d69f>] __lock_acquire+0xa8f/0x11b0
[  171.449698]  [<c014de41>] lock_acquire+0x81/0xa0
[  171.450655]  [<f89ee9b5>] ? ath5k_config_interface+0xd5/0x340 [ath5k]
[  171.451651]  [<c046073b>] mutex_lock_nested+0x9b/0x280
[  171.452609]  [<f89ee9b5>] ? ath5k_config_interface+0xd5/0x340 [ath5k]
[  171.453588]  [<f89ee9b5>] ? ath5k_config_interface+0xd5/0x340 [ath5k]
[  171.454555]  [<f89ee9b5>] ath5k_config_interface+0xd5/0x340 [ath5k]
[  171.455485]  [<c0184082>] ? check_object+0xe2/0x1e0
[  171.456428]  [<c014c7cb>] ? trace_hardirqs_on+0xb/0x10
[  171.457377]  [<c014c73d>] ? trace_hardirqs_on_caller+0xbd/0x140
[  171.458334]  [<c014c7cb>] ? trace_hardirqs_on+0xb/0x10
[  171.459304]  [<c03eb31c>] ? dev_alloc_skb+0x1c/0x30
[  171.460276]  [<f89a3747>] ieee80211_if_config+0x97/0x160 [mac80211]
[  171.461237]  [<f89a95bc>] ieee80211_sta_join_ibss+0x25c/0x3e0 [mac80211]
[  171.462196]  [<c012f070>] ? local_bh_enable_ip+0x80/0xc0
[  171.463171]  [<f89ab325>] ieee80211_sta_find_ibss+0x365/0x4b0 [mac80211]
[  171.464134]  [<f89ab8ab>] ieee80211_scan_completed+0x2cb/0x320 [mac80211]
[  171.465097]  [<f89ab7de>] ? ieee80211_scan_completed+0x1fe/0x320 [mac80211]
[  171.466084]  [<f89af3b3>] ieee80211_sta_scan_work+0xa3/0x1f0 [mac80211]
[  171.467054]  [<c013a122>] ? run_workqueue+0x102/0x1d0
[  171.468026]  [<c013a175>] run_workqueue+0x155/0x1d0
[  171.468978]  [<c013a122>] ? run_workqueue+0x102/0x1d0
[  171.469947]  [<c014c7cb>] ? trace_hardirqs_on+0xb/0x10
[  171.470925]  [<f89af310>] ? ieee80211_sta_scan_work+0x0/0x1f0 [mac80211]
[  171.471924]  [<c013ac68>] worker_thread+0x88/0xe0
[  171.472880]  [<c013da70>] ? autoremove_wake_function+0x0/0x40
[  171.473862]  [<c013abe0>] ? worker_thread+0x0/0xe0
[  171.474835]  [<c013d782>] kthread+0x42/0x70
[  171.475789]  [<c013d740>] ? kthread+0x0/0x70
[  171.476765]  [<c01048e7>] kernel_thread_helper+0x7/0x10

Signed-off-by: Dave Young <hidave.darkstar@gmail.com>

drivers/net/wireless/ath5k/base.c |    6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

Index: linux-2.6.26/drivers/net/wireless/ath5k/base.c
===================================================================
--- linux-2.6.26.orig/drivers/net/wireless/ath5k/base.c	2008-08-01 12:55:16.000000000 +0800
+++ linux-2.6.26/drivers/net/wireless/ath5k/base.c	2008-08-01 14:01:15.000000000 +0800
@@ -3024,6 +3024,9 @@
 		ath5k_hw_reset_tsf(sc->ah);
 }
 
+/*
+ * caller need lock the hw->sc->lock for us.
+ */
 static int
 ath5k_beacon_update(struct ieee80211_hw *hw, struct sk_buff *skb)
 {
@@ -3032,8 +3035,6 @@
 
 	ath5k_debug_dump_skb(sc, skb, "BC  ", 1);
 
-	mutex_lock(&sc->lock);
-
 	if (sc->opmode != IEEE80211_IF_TYPE_IBSS) {
 		ret = -EIO;
 		goto end;
@@ -3048,7 +3049,6 @@
 		ath5k_beacon_config(sc);
 
 end:
-	mutex_unlock(&sc->lock);
 	return ret;
 }
 

Re: [PATCH] ath5k : ath5k_config_interface deadlock fix

[Jiri Slaby]

Dave Young napsal(a):
> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of sc->lock
> This casue the kernel stuck
> 
> Bug report please see:
> http://lkml.org/lkml/2008/7/29/32
> 
> Fixed it by remove the lock in sub routine "ath5k_beacon_update",
> The ath5k_config_interface is the only caller to it.
> 
> [  171.430207] =============================================
> [  171.432140] [ INFO: possible recursive locking detected ]
> [  171.433113] 2.6.27-rc1-smp #4
> [  171.434079] ---------------------------------------------
> [  171.435039] ath5k_pci/2447 is trying to acquire lock:
> [  171.435990]  (&sc->lock){--..}, at: [<f89ee9b5>] ath5k_config_interface+0xd5/0x340 [ath5k]
> [  171.437046] 
> [  171.437048] but task is already holding lock:
> [  171.438903]  (&sc->lock){--..}, at: [<f89ee91d>] ath5k_config_interface+0x3d/0x340 [ath5k]
> [  171.439953] 
> [  171.439954] other info that might help us debug this:
> [  171.441795] 3 locks held by ath5k_pci/2447:
> [  171.442729]  #0:  ((name)){--..}, at: [<c013a122>] run_workqueue+0x102/0x1d0
> [  171.443800]  #1:  (&(&local->scan_work)->work){--..}, at: [<c013a122>] run_workqueue+0x102/0x1d0
> [  171.444859]  #2:  (&sc->lock){--..}, at: [<f89ee91d>] ath5k_config_interface+0x3d/0x340 [ath5k]

Should be fixed already:
http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97

Re: [PATCH] ath5k : ath5k_config_interface deadlock fix

[Pekka Enberg]

Jiri Slaby wrote:
> Dave Young napsal(a):
>> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of 
>> sc->lock
>> This casue the kernel stuck
>>
>> Bug report please see:
>> http://lkml.org/lkml/2008/7/29/32
>>
>> Fixed it by remove the lock in sub routine "ath5k_beacon_update",
>> The ath5k_config_interface is the only caller to it.
>>
>> [  171.430207] =============================================
>> [  171.432140] [ INFO: possible recursive locking detected ]
>> [  171.433113] 2.6.27-rc1-smp #4
>> [  171.434079] ---------------------------------------------
>> [  171.435039] ath5k_pci/2447 is trying to acquire lock:
>> [  171.435990]  (&sc->lock){--..}, at: [<f89ee9b5>] 
>> ath5k_config_interface+0xd5/0x340 [ath5k]
>> [  171.437046] [  171.437048] but task is already holding lock:
>> [  171.438903]  (&sc->lock){--..}, at: [<f89ee91d>] 
>> ath5k_config_interface+0x3d/0x340 [ath5k]
>> [  171.439953] [  171.439954] other info that might help us debug this:
>> [  171.441795] 3 locks held by ath5k_pci/2447:
>> [  171.442729]  #0:  ((name)){--..}, at: [<c013a122>] 
>> run_workqueue+0x102/0x1d0
>> [  171.443800]  #1:  (&(&local->scan_work)->work){--..}, at: 
>> [<c013a122>] run_workqueue+0x102/0x1d0
>> [  171.444859]  #2:  (&sc->lock){--..}, at: [<f89ee91d>] 
>> ath5k_config_interface+0x3d/0x340 [ath5k]
> 
> Should be fixed already:
> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97 

I guess that didn't make it to -stable?

Re: [PATCH] ath5k : ath5k_config_interface deadlock fix

[Andrew Morton]

On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg <penberg@cs.helsinki.fi> wrote:

> Jiri Slaby wrote:
> > Dave Young napsal(a):
> >> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of 
> >> sc->lock
> >> This casue the kernel stuck
> >>
> >> Bug report please see:
> >> http://lkml.org/lkml/2008/7/29/32
> >>
> >> Fixed it by remove the lock in sub routine "ath5k_beacon_update",
> >> The ath5k_config_interface is the only caller to it.
> >>
> >> [  171.430207] =============================================
> >> [  171.432140] [ INFO: possible recursive locking detected ]
> >> [  171.433113] 2.6.27-rc1-smp #4
> >> [  171.434079] ---------------------------------------------
> >> [  171.435039] ath5k_pci/2447 is trying to acquire lock:
> >> [  171.435990]  (&sc->lock){--..}, at: [<f89ee9b5>] 
> >> ath5k_config_interface+0xd5/0x340 [ath5k]
> >> [  171.437046] [  171.437048] but task is already holding lock:
> >> [  171.438903]  (&sc->lock){--..}, at: [<f89ee91d>] 
> >> ath5k_config_interface+0x3d/0x340 [ath5k]
> >> [  171.439953] [  171.439954] other info that might help us debug this:
> >> [  171.441795] 3 locks held by ath5k_pci/2447:
> >> [  171.442729]  #0:  ((name)){--..}, at: [<c013a122>] 
> >> run_workqueue+0x102/0x1d0
> >> [  171.443800]  #1:  (&(&local->scan_work)->work){--..}, at: 
> >> [<c013a122>] run_workqueue+0x102/0x1d0
> >> [  171.444859]  #2:  (&sc->lock){--..}, at: [<f89ee91d>] 
> >> ath5k_config_interface+0x3d/0x340 [ath5k]
> > 
> > Should be fixed already:
> > http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97 
> 
> I guess that didn't make it to -stable?

(cc stable!)

Re: [PATCH] ath5k : ath5k_config_interface deadlock fix

[Bob Copeland]

On Fri, Aug 1, 2008 at 4:14 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>
>> Jiri Slaby wrote:
>> > Dave Young napsal(a):
>> >> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of
>> >> sc->lock
>> >
>> > Should be fixed already:
>> > http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
>>
>> I guess that didn't make it to -stable?
>
> (cc stable!)

Not to worry, the commit that introduced it was
9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
came in after 2.6.26.

-- 
Bob Copeland %% www.bobcopeland.com

Re: [PATCH] ath5k : ath5k_config_interface deadlock fix

[Jiri Slaby]

Bob Copeland napsal(a):
> On Fri, Aug 1, 2008 at 4:14 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
>> On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>>
>>> Jiri Slaby wrote:
>>>> Dave Young napsal(a):
>>>>> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of
>>>>> sc->lock
>>>> Should be fixed already:
>>>> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
>>> I guess that didn't make it to -stable?
>> (cc stable!)
> 
> Not to worry, the commit that introduced it was
> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
> came in after 2.6.26.

git-describe 9d139c810a2aa17365cc548d0cd2a189d8433c65
v2.6.26-rc8-1219-g9d139c8

Re: [PATCH] ath5k : ath5k_config_interface deadlock fix

[Jiri Slaby]

Jiri Slaby napsal(a):
> Bob Copeland napsal(a):
>> On Fri, Aug 1, 2008 at 4:14 AM, Andrew Morton 
>> <akpm@linux-foundation.org> wrote:
>>> On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg 
>>> <penberg@cs.helsinki.fi> wrote:
>>>
>>>> Jiri Slaby wrote:
>>>>> Dave Young napsal(a):
>>>>>> In the drivers/net/wireless/ath5k/base.c, there's recursive 
>>>>>> locking of
>>>>>> sc->lock
>>>>> Should be fixed already:
>>>>> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97 
>>>>>
>>>> I guess that didn't make it to -stable?
>>> (cc stable!)
>>
>> Not to worry, the commit that introduced it was
>> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
>> came in after 2.6.26.
> 
> git-describe 9d139c810a2aa17365cc548d0cd2a189d8433c65
> v2.6.26-rc8-1219-g9d139c8

Fingers faster than brain. Why such a change went into -rc8? How long has 
this been in linux-next? It appeared in mmotm between 2008-07-15-15-39 and 
2008-07-23-02-07 which I think correspond to -next appearance -- isn't it 
way too fast?

Re: [ath5k-devel] [PATCH] ath5k : ath5k_config_interface deadlock fix

[Alan Jenkins]

Jiri Slaby wrote:
> Bob Copeland napsal(a):
>   
>> On Fri, Aug 1, 2008 at 4:14 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
>>     
>>> On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>>>
>>>       
>>>> Jiri Slaby wrote:
>>>>         
>>>>> Dave Young napsal(a):
>>>>>           
>>>>>> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of
>>>>>> sc->lock
>>>>>>             
>>>>> Should be fixed already:
>>>>> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
>>>>>           
>>>> I guess that didn't make it to -stable?
>>>>         
>>> (cc stable!)
>>>       
>> Not to worry, the commit that introduced it was
>> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
>> came in after 2.6.26.
>>     
>
> git-describe 9d139c810a2aa17365cc548d0cd2a189d8433c65
> v2.6.26-rc8-1219-g9d139c8
>
>   
Jiri Slaby wrote:
> Bob Copeland napsal(a):
>   
>> On Fri, Aug 1, 2008 at 4:14 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
>>     
>>> On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>>>
>>>       
>>>> Jiri Slaby wrote:
>>>>         
>>>>> Dave Young napsal(a):
>>>>>           
>>>>>> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of
>>>>>> sc->lock
>>>>>>             
>>>>> Should be fixed already:
>>>>> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
>>>>>           
>>>> I guess that didn't make it to -stable?
>>>>         
>>> (cc stable!)
>>>       
>> Not to worry, the commit that introduced it was
>> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
>> came in after 2.6.26.
>>     
>
> git-describe 9d139c810a2aa17365cc548d0cd2a189d8433c65
> v2.6.26-rc8-1219-g9d139c8
>   
Unfortunately git-describe can be misleading.

All this tells you is that the commit in question was based on (a
descendant of) v2.6.26-rc8.  It doesn't tell you whether the patch is
present in v2.6.26.

There must be a better way (for efficient merges, right?).  But all I
can think of is comparing the files in question against the diff.  I
checked myself and the changes don't appear to have been included in
v2.6.26.

Alan

Re: [PATCH] ath5k : ath5k_config_interface deadlock fix

[Bob Copeland]

On Fri, Aug 1, 2008 at 11:02 AM, Jiri Slaby <jirislaby@gmail.com> wrote:
>>
>> Not to worry, the commit that introduced it was
>> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
>> came in after 2.6.26.
>
> git-describe 9d139c810a2aa17365cc548d0cd2a189d8433c65
> v2.6.26-rc8-1219-g9d139c8

I'm not that expert in git, what does that mean?  Some other commits
for 2.6.27 also show a 2.6.26-rc from git-describe (e.g. my
3a078876caee).

For my own investigation, I did a 'git-checkout v2.6.26' and looked at
the code to see the patch had not been applied yet.  Is there an
easier way to definitively say commit X is/is not in tagged release Y?

-- 
Bob Copeland %% www.bobcopeland.com

git-describe [Was: ath5k_config_interface deadlock fix]

[Jiri Slaby]

Alan Jenkins napsal(a):
> There must be a better way (for efficient merges, right?).  But all I
> can think of is comparing the files in question against the diff.  I
> checked myself and the changes don't appear to have been included in
> v2.6.26.

Ah, I see. Is this a git-describe bug or my misunderstanding of the tool?

Sorry for the noise, it's not in 2.6.26.

Re: git-describe [Was: ath5k_config_interface deadlock fix]

[Alan Jenkins]

Jiri Slaby wrote:
> Alan Jenkins napsal(a):
>> There must be a better way (for efficient merges, right?).  But all I
>> can think of is comparing the files in question against the diff.  I
>> checked myself and the changes don't appear to have been included in
>> v2.6.26.
>
> Ah, I see. Is this a git-describe bug or my misunderstanding of the tool?

It's not an implementation bug.  It's just very easy to misunderstand.

git-describe only looks _back_ in time to what the current commit is
based on.  In this case the commit was based on v2.6.26-rc8 - but it
_wasn't_ merged into 2.6.26.  It was presumably merged in for
v2.6.27-rc1.  This is a perfectly legal history in GIT.

It's probably most often encountered during git-bisect.  If you bisect
e.g. between v2.6.26 and v.2.6.27-rc1, you're likely to see commits
which were based on v2.6.26-rc8.

If that doesn't help, try finding an introduction to GIT with some good
pictures.  I think it's easier to understand it visually.

Alan

Re: [ath5k-devel] [PATCH] ath5k : ath5k_config_interface deadlock fix

[Alan Jenkins]

Bob Copeland wrote:
> On Fri, Aug 1, 2008 at 11:02 AM, Jiri Slaby <jirislaby@gmail.com> wrote:
>   
>>> Not to worry, the commit that introduced it was
>>> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
>>> came in after 2.6.26.
>>>       
>> git-describe 9d139c810a2aa17365cc548d0cd2a189d8433c65
>> v2.6.26-rc8-1219-g9d139c8
>>     
>
> I'm not that expert in git, what does that mean?  Some other commits
> for 2.6.27 also show a 2.6.26-rc from git-describe (e.g. my
> 3a078876caee).
>
> For my own investigation, I did a 'git-checkout v2.6.26' and looked at
> the code to see the patch had not been applied yet.  Is there an
> easier way to definitively say commit X is/is not in tagged release Y?
>
>   

Aha!  I think we want git-describe --contains.

$ git-describe --contains 2b142900784c6e38c8d39fa57d5f95ef08e735d8
v2.6.27-rc1~55^2~1

Alan

Re: [PATCH] ath5k : ath5k_config_interface deadlock fix

[Dave Young]

On Fri, Aug 1, 2008 at 9:43 PM, Bob Copeland <me@bobcopeland.com> wrote:
> On Fri, Aug 1, 2008 at 4:14 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
>> On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>>
>>> Jiri Slaby wrote:
>>> > Dave Young napsal(a):
>>> >> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of
>>> >> sc->lock
>>> >
>>> > Should be fixed already:
>>> > http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
>>>
>>> I guess that didn't make it to -stable?
>>
>> (cc stable!)
>
> Not to worry, the commit that introduced it was
> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
> came in after 2.6.26.

Strange, I get system stuck in 2.6.26 as well, so there might be other bugs.


>
> --
> Bob Copeland %% www.bobcopeland.com
>



-- 
Regards
dave

Re: [PATCH] ath5k : ath5k_config_interface deadlock fix

[Jiri Slaby]

Dave Young napsal(a):
> On Fri, Aug 1, 2008 at 9:43 PM, Bob Copeland <me@bobcopeland.com> wrote:
>> On Fri, Aug 1, 2008 at 4:14 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
>>> On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>>>
>>>> Jiri Slaby wrote:
>>>>> Dave Young napsal(a):
>>>>>> In the drivers/net/wireless/ath5k/base.c, there's recursive locking of
>>>>>> sc->lock
>>>>> Should be fixed already:
>>>>> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
>>>> I guess that didn't make it to -stable?
>>> (cc stable!)
>> Not to worry, the commit that introduced it was
>> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
>> came in after 2.6.26.
> 
> Strange, I get system stuck in 2.6.26 as well, so there might be other bugs.

Could you provide any logs regarding this, please?

Re: [PATCH] ath5k : ath5k_config_interface deadlock fix

[Dave Young]

On Mon, Aug 4, 2008 at 4:06 PM, Jiri Slaby <jirislaby@gmail.com> wrote:
> Dave Young napsal(a):
>>
>> On Fri, Aug 1, 2008 at 9:43 PM, Bob Copeland <me@bobcopeland.com> wrote:
>>>
>>> On Fri, Aug 1, 2008 at 4:14 AM, Andrew Morton <akpm@linux-foundation.org>
>>> wrote:
>>>>
>>>> On Fri, 01 Aug 2008 11:03:37 +0300 Pekka Enberg <penberg@cs.helsinki.fi>
>>>> wrote:
>>>>
>>>>> Jiri Slaby wrote:
>>>>>>
>>>>>> Dave Young napsal(a):
>>>>>>>
>>>>>>> In the drivers/net/wireless/ath5k/base.c, there's recursive locking
>>>>>>> of
>>>>>>> sc->lock
>>>>>>
>>>>>> Should be fixed already:
>>>>>>
>>>>>> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=commitdiff_plain;h=bc05116ab33d30342e2b4b1bcc6d6e1184e9df97
>>>>>
>>>>> I guess that didn't make it to -stable?
>>>>
>>>> (cc stable!)
>>>
>>> Not to worry, the commit that introduced it was
>>> 9d139c810a2aa17365cc548d0cd2a189d8433c65, which as far as I can tell
>>> came in after 2.6.26.
>>
>> Strange, I get system stuck in 2.6.26 as well, so there might be other
>> bugs.
>
> Could you provide any logs regarding this, please?
>

I will generate some new logs tomorrow.

There's some info in:
http://lkml.org/lkml/2008/7/29/32

-- 
Regards
dave