ath5k and ath9k bugs still in 2.6.39-rc7

ath5k and ath9k bugs still in 2.6.39-rc7

[Ben Greear]

As far as I can tell, ath5k is critically broken due to un-initilized
spinlock (fixed in the patch I posted a few days ago), and ath9k stations
won't work due to PS bugs that Felix posted fixes for yesterday.

It looks like -rc7 is the last RC before the final .39, so I'm hoping
these patches can be pushed quickly to Linus!

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath5k and ath9k bugs still in 2.6.39-rc7

[Felix Fietkau]

On 2011-05-10 6:34 PM, Ben Greear wrote:
> As far as I can tell, ath5k is critically broken due to un-initilized
> spinlock (fixed in the patch I posted a few days ago), and ath9k stations
> won't work due to PS bugs that Felix posted fixes for yesterday.
Did you test my patch for that? I couldn't reproduce the issue, so I 
couldn't test whether my patch fully fixes it.

- Felix

Re: ath5k and ath9k bugs still in 2.6.39-rc7

[Ben Greear]

On 05/10/2011 10:10 AM, Felix Fietkau wrote:
> On 2011-05-10 6:34 PM, Ben Greear wrote:
>> As far as I can tell, ath5k is critically broken due to un-initilized
>> spinlock (fixed in the patch I posted a few days ago), and ath9k stations
>> won't work due to PS bugs that Felix posted fixes for yesterday.
> Did you test my patch for that? I couldn't reproduce the issue, so I
> couldn't test whether my patch fully fixes it.

Trying now..I get crashes..but not sure yet who is to blame.

I did test your previous two patches..one of which was NAK'd..those
worked fine.

Ben

>
> - Felix


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath5k and ath9k bugs still in 2.6.39-rc7

[Ben Greear]

On 05/10/2011 10:10 AM, Felix Fietkau wrote:
> On 2011-05-10 6:34 PM, Ben Greear wrote:
>> As far as I can tell, ath5k is critically broken due to un-initilized
>> spinlock (fixed in the patch I posted a few days ago), and ath9k stations
>> won't work due to PS bugs that Felix posted fixes for yesterday.
> Did you test my patch for that? I couldn't reproduce the issue, so I
> couldn't test whether my patch fully fixes it.

Better hold off on that patch..looks like the culprit.  Maybe vif is not NULL but
still bogus?


> (gdb) l *(ath_tx_start+0x640)
0xa123 is in ath_tx_start (/home/greearb/git/linux.wireless-testing/drivers/net/wireless/ath/ath9k/xmit.c:1833).
1828							   bf->bf_state.bfs_paprd);
1829	
1830			if (txctl->paprd)
1831				bf->bf_state.bfs_paprd_timestamp = jiffies;
1832	
1833			if ((vif && vif->type != NL80211_IFTYPE_AP &&
1834			            vif->type != NL80211_IFTYPE_AP_VLAN) ||
1835			    !ieee80211_is_data(hdr->frame_control) ||
1836			    (tx_info->flags & IEEE80211_TX_CTL_CLEAR_PS_FILT))
1837				ath9k_hw_set_clrdmask(sc->sc_ah, bf->bf_desc, true);


> - Felix


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath5k and ath9k bugs still in 2.6.39-rc7

[Felix Fietkau]

On 2011-05-10 7:48 PM, Ben Greear wrote:
> On 05/10/2011 10:10 AM, Felix Fietkau wrote:
>>  On 2011-05-10 6:34 PM, Ben Greear wrote:
>>>  As far as I can tell, ath5k is critically broken due to un-initilized
>>>  spinlock (fixed in the patch I posted a few days ago), and ath9k stations
>>>  won't work due to PS bugs that Felix posted fixes for yesterday.
>>  Did you test my patch for that? I couldn't reproduce the issue, so I
>>  couldn't test whether my patch fully fixes it.
>
> Better hold off on that patch..looks like the culprit.  Maybe vif is not NULL but
> still bogus?
I think I know where the bug is, I'll send a v2 soon.

- Felix

Re: ath5k and ath9k bugs still in 2.6.39-rc7

[Ben Greear]

On 05/10/2011 10:48 AM, Ben Greear wrote:
> On 05/10/2011 10:10 AM, Felix Fietkau wrote:
>> On 2011-05-10 6:34 PM, Ben Greear wrote:
>>> As far as I can tell, ath5k is critically broken due to un-initilized
>>> spinlock (fixed in the patch I posted a few days ago), and ath9k
>>> stations
>>> won't work due to PS bugs that Felix posted fixes for yesterday.
>> Did you test my patch for that? I couldn't reproduce the issue, so I
>> couldn't test whether my patch fully fixes it.
>
> Better hold off on that patch..looks like the culprit. Maybe vif is not
> NULL but
> still bogus?
>
>
>> (gdb) l *(ath_tx_start+0x640)
> 0xa123 is in ath_tx_start
> (/home/greearb/git/linux.wireless-testing/drivers/net/wireless/ath/ath9k/xmit.c:1833).
>
> 1828 bf->bf_state.bfs_paprd);
> 1829
> 1830 if (txctl->paprd)
> 1831 bf->bf_state.bfs_paprd_timestamp = jiffies;
> 1832
> 1833 if ((vif && vif->type != NL80211_IFTYPE_AP &&
> 1834 vif->type != NL80211_IFTYPE_AP_VLAN) ||
> 1835 !ieee80211_is_data(hdr->frame_control) ||
> 1836 (tx_info->flags & IEEE80211_TX_CTL_CLEAR_PS_FILT))
> 1837 ath9k_hw_set_clrdmask(sc->sc_ah, bf->bf_desc, true);

Well, it seems vif is always, or at least mostly always, wrong in my testing.

I added code like this, and get the printout below:

		printk("vif: %p tx_info: %p control: %p\n",
		       vif, tx_info, &(tx_info->control));
		if ((((unsigned long)(vif) & ~0xff) && vif->type != NL80211_IFTYPE_AP &&
		            vif->type != NL80211_IFTYPE_AP_VLAN) ||

vif: 00000025 tx_info: f2749a98 control: f2749aa0
vif: 00000025 tx_info: f2749b58 control: f2749b60
vif: 00000025 tx_info: f26c8318 control: f26c8320
vif: 000000a1 tx_info: f26c8a98 control: f26c8aa0
vif: 000000a1 tx_info: f26c8c18 control: f26c8c20
vif: 000000a1 tx_info: f0491b58 control: f0491b60
vif: 00000099 tx_info: f0491198 control: f04911a0
vif: 00000025 tx_info: f2749498 control: f27494a0
vif: 000000a1 tx_info: f0491558 control: f0491560
vif: 000000a1 tx_info: f0491b58 control: f0491b60


>
>
>> - Felix
>
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: ath5k and ath9k bugs still in 2.6.39-rc7

[Dan Williams]

On Tue, 2011-05-10 at 09:34 -0700, Ben Greear wrote:
> As far as I can tell, ath5k is critically broken due to un-initilized
> spinlock (fixed in the patch I posted a few days ago), and ath9k stations
> won't work due to PS bugs that Felix posted fixes for yesterday.
> 
> It looks like -rc7 is the last RC before the final .39, so I'm hoping
> these patches can be pushed quickly to Linus!

Johannes and I found out yesterday that ath5k doesn't implement the
tx_last_beacon hook either, which breaks IBSS mode.  Anyone know how to
fix that one?  It's been broken since at least 2.6.38 so it's not
technically a regression in current linux-2.6, but it's still broken.

Dan