[ath9k-devel] 3.9.0-rc8+ (hacked) splat.

[ath9k-devel] 3.9.0-rc8+ (hacked) splat.

[Ben Greear]

Was running around 200 stations against a VAP on this system, and
then changed the channel from 1 to 36 (by restarting hostapd with new
config).

Looks like null-pointer de-ref...  Anyone seen anything similar?

[17789.100382] ath: wiphy0: keyreset: keycache entry 228 out of range
[17789.107940] ath: wiphy0: keyreset: keycache entry 228 out of range
[17789.115530] ath: wiphy0: keyreset: keycache entry 228 out of range
[17789.122708] BUG: unable to handle kernel NULL pointer dereference at 000003c4
[17789.123477] IP: [<f8bbff21>] ath_tx_process_buffer+0x121/0xaa0 [ath9k]
[17789.123477] *pdpt = 000000002e017001 *pde = 0000000000000000
[17789.123477] Oops: 0000 [#1] PREEMPT SMP
[17789.123477] Modules linked in: iptable_raw xt_CT bridge nf_conntrack_ipv4 nf]
[17789.123477] Pid: 15, comm: ksoftirqd/1 Tainted: G        WC   3.9.0-rc8+ #18.
[17789.123477] EIP: 0060:[<f8bbff21>] EFLAGS: 00010206 CPU: 1
[17789.123477] EIP is at ath_tx_process_buffer+0x121/0xaa0 [ath9k]
[17789.123477] EAX: 00000000 EBX: f39bbd8c ECX: 00000000 EDX: 00000384
[17789.123477] ESI: f39b1680 EDI: 00000390 EBP: f5cebe44 ESP: f5cebd78
[17789.123477]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[17789.123477] CR0: 8005003b CR2: 000003c4 CR3: 30b46000 CR4: 000007e0
[17789.123477] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[17789.123477] DR6: ffff0ff0 DR7: 00000400
[17789.123477] Process ksoftirqd/1 (pid: 15, ti=f5cea000 task=f5cb4ce0 task.ti=)
[17789.123477] Stack:
[17789.123477]  f5c01480 f6750ac0 f5cebda4 c0549559 c08c0ddd c08c0ddd f6750ac0 0
[17789.123477]  f1756700 f1756700 0000033c f5cebdb0 c08c0ddd 00000001 f5cebdc0 0
[17789.123477]  00000000 00000000 00000384 00000003 f39bbd8c 00000390 0100be8c 0
[17789.123477] Call Trace:
[17789.123477]  [<c0549559>] ? kmem_cache_free+0xe9/0x120
[17789.123477]  [<c08c0ddd>] ? __kfree_skb+0x3d/0x90
[17789.123477]  [<c08c0ddd>] ? __kfree_skb+0x3d/0x90
[17789.123477]  [<c08c0ddd>] ? __kfree_skb+0x3d/0x90
[17789.123477]  [<f8bc0d2e>] ? ath_txq_unlock_complete+0x7e/0x90 [ath9k]
[17789.123477]  [<f8bc0ee1>] ath_tx_edma_tasklet+0x1a1/0x2a0 [ath9k]
[17789.123477]  [<f8bbb06f>] ath9k_tasklet+0x10f/0x170 [ath9k]
[17789.123477]  [<c04590d3>] tasklet_action+0xa3/0xb0
[17789.123477]  [<c045948a>] __do_softirq+0xaa/0x230
[17789.123477]  [<c09c0b33>] ? common_interrupt+0x33/0x38
[17789.123477]  [<c045963d>] run_ksoftirqd+0x2d/0x50
[17789.123477]  [<c0479f11>] smpboot_thread_fn+0x141/0x260
[17789.123477]  [<c04721a4>] kthread+0xa4/0xb0
[17789.123477]  [<c0479dd0>] ? smpboot_park_threads+0x70/0x70
[17789.123477]  [<c0470303>] ? parse_args+0x3/0x460
[17789.123477]  [<c09c05b7>] ret_from_kernel_thread+0x1b/0x28
[17789.123477]  [<c0472100>] ? kthread_freezable_should_stop+0x50/0x50
[17789.123477] Code: 66 81 e2 00 03 66 81 fa 00 03 0f 45 c7 0f b6 00 83 e0 0f 0f
[17789.123477] EIP: [<f8bbff21>] ath_tx_process_buffer+0x121/0xaa0 [ath9k] SS:E8
[17789.123477] CR2: 00000000000003c4
[17789.574609] ---[ end trace 7e9b62ed3d3df574 ]---


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

[ath9k-devel] 3.9.0-rc8+ (hacked) splat.

[Felix Fietkau]

On 2013-04-27 1:46 AM, Ben Greear wrote:
> Was running around 200 stations against a VAP on this system, and
> then changed the channel from 1 to 36 (by restarting hostapd with new
> config).
> 
> Looks like null-pointer de-ref...  Anyone seen anything similar?
I've never seen this one. Please use gdb to figure out the source code
line that the NULL pointer deref happens in.
As for the 'keycache entry 228 out of range' stuff, I'm going to send a
patch for that now.

- Felix

[ath9k-devel] 3.9.0-rc8+ (hacked) splat.

[Ben Greear]

On 04/27/2013 01:58 AM, Felix Fietkau wrote:
> On 2013-04-27 1:46 AM, Ben Greear wrote:
>> Was running around 200 stations against a VAP on this system, and
>> then changed the channel from 1 to 36 (by restarting hostapd with new
>> config).
>>
>> Looks like null-pointer de-ref...  Anyone seen anything similar?
> I've never seen this one. Please use gdb to figure out the source code
> line that the NULL pointer deref happens in.
> As for the 'keycache entry 228 out of range' stuff, I'm going to send a
> patch for that now.

Thanks.

I'm away from the office for a bit, but will build a debugging kernel
and crank on this early next week.

Thanks,
Ben

>
> - Felix
>


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

[ath9k-devel] 3.9.0-rc8+ (hacked) splat.

[Ben Greear]

On 04/28/2013 08:05 AM, Ben Greear wrote:
> On 04/27/2013 01:58 AM, Felix Fietkau wrote:
>> On 2013-04-27 1:46 AM, Ben Greear wrote:
>>> Was running around 200 stations against a VAP on this system, and
>>> then changed the channel from 1 to 36 (by restarting hostapd with new
>>> config).
>>>
>>> Looks like null-pointer de-ref...  Anyone seen anything similar?
>> I've never seen this one. Please use gdb to figure out the source code
>> line that the NULL pointer deref happens in.
>> As for the 'keycache entry 228 out of range' stuff, I'm going to send a
>> patch for that now.
>
> Thanks.
>
> I'm away from the office for a bit, but will build a debugging kernel
> and crank on this early next week.

Ok, this is against a modified 3.9.0 tree.  My patches are here:

http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.9.dev.y/.git;a=summary

I'm going to try reproducing against upstream 3.9.0 (using a smaller number of
stations since upstream doesn't have needed optimizations to make it work on
my hardware...)


(gdb) l *(ath_tx_process_buffer+0x175)
0xc8b5 is in ath_tx_process_buffer (/home/greearb/git/linux-3.9.dev.y/drivers/net/wireless/ath/ath9k/xmit.c:439).
434		}
435	
436		an = (struct ath_node *)sta->drv_priv;
437		tidno = ieee80211_get_qos_ctl(hdr)[0] & IEEE80211_QOS_CTL_TID_MASK;
438		tid = ATH_AN_2_TID(an, tidno);
439		seq_first = tid->seq_start;
440		isba = ts->ts_flags & ATH9K_TX_BA;
441	
442		/*
443		 * The hardware occasionally sends a tx status for the wrong TID.
(gdb)


[  444.210612] BUG: unable to handle kernel NULL pointer dereference at 00000540
[  444.211060] IP: [<f864f8b5>] ath_tx_process_buffer+0x175/0xb90 [ath9k]
[  444.211060] *pdpt = 000000003013f001 *pde = 0000000000000000
[  444.211060] Oops: 0000 [#1] PREEMPT SMP
[  444.211060] Modules linked in: iptable_raw xt_CT nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack bridge ip_gre gre 8021q mrp garp stp llc 
fuse macvlan pktgen nfsv3 nfs_acl nfsv4 auth_rpcgss nfs fscache lockd sunrpc binfmt_misc uinput arc4 ath9k mac80211 snd_hda_codec_realtek snd_hda_intel 
ath9k_common snd_hda_codec ath9k_hw snd_hwdep snd_seq iTCO_wdt ath snd_seq_device coretemp snd_pcm gpio_ich iTCO_vendor_support cfg80211 snd_timer snd cdc_acm 
lpc_ich microcode i2c_i801 rfkill pcspkr soundcore serio_raw snd_page_alloc r8169 mii i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: 
iptable_nat]
[  444.211060] Pid: 3601, comm: ip Tainted: G         C O 3.9.0+ #2 To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M.
[  444.211060] EIP: 0060:[<f864f8b5>] EFLAGS: 00010206 CPU: 1
[  444.211060] EIP is at ath_tx_process_buffer+0x175/0xb90 [ath9k]
[  444.211060] EAX: 00000000 EBX: f27a804c ECX: 00000000 EDX: 000004e4
[  444.211060] ESI: f4f99e20 EDI: 000004f0 EBP: f1527788 ESP: f152769c
[  444.211060]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[  444.211060] CR0: 8005003b CR2: 00000540 CR3: 30301000 CR4: 000007e0
[  444.211060] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[  444.211060] DR6: ffff0ff0 DR7: 00000400
[  444.211060] Process ip (pid: 3601, ti=f1526000 task=f090b600 task.ti=f1526000)
[  444.211060] Stack:
[  444.211060]  00000002 00000001 00000000 f864f821 c048eb7b 6c97aee2 00000067 6c97aee2
[  444.211060]  00000067 00000001 0000049c f79d57c0 f1527700 00000000 f584b8a0 00000040
[  444.211060]  00000000 f0900100 000004e4 00000001 f27a804c 000004f0 00000005 f152776c
[  444.211060] Call Trace:
[  444.211060]  [<f864f821>] ? ath_tx_process_buffer+0xe1/0xb90 [ath9k]
[  444.211060]  [<c048eb7b>] ? find_busiest_group+0x2b/0x440
[  444.211060]  [<c045a8b1>] ? local_bh_enable_ip+0x71/0xf0
[  444.211060]  [<c04b1891>] ? trace_hardirqs_on_caller+0xa1/0x180
[  444.211060]  [<f865037b>] ath_drain_txq_list+0xab/0xd0 [ath9k]
[  444.211060]  [<f86503f3>] ath_draintxq+0x53/0xf0 [ath9k]
[  444.211060]  [<f864571d>] ? ath9k_ioread32+0x2d/0x80 [ath9k]
[  444.211060]  [<f8650586>] ath_drain_all_txq+0xf6/0x150 [ath9k]
[  444.211060]  [<f85aa6af>] ? ath9k_hw_kill_interrupts+0x9f/0xd0 [ath9k_hw]
[  444.211060]  [<f8646f6a>] ath_prepare_reset+0x4a/0x70 [ath9k]
[  444.211060]  [<f8647a34>] ath_reset_internal+0x84/0x1e0 [ath9k]
[  444.211060]  [<f8649d03>] ath9k_config+0x1c3/0x550 [ath9k]
[  444.211060]  [<f936eae6>] ieee80211_hw_config+0x46/0x2b0 [mac80211]
[  444.211060]  [<f936eb8e>] ? ieee80211_hw_config+0xee/0x2b0 [mac80211]
[  444.211060]  [<f93997e3>] ieee80211_free_chanctx+0x183/0x1b0 [mac80211]
[  444.211060]  [<f9399f83>] __ieee80211_vif_release_channel+0x1b3/0x2a0 [mac80211]
[  444.211060]  [<f939a0b4>] ieee80211_vif_release_channel+0x44/0x60 [mac80211]
[  444.211060]  [<f938621f>] ieee80211_stop_ap+0x19f/0x290 [mac80211]
[  444.211060]  [<f853e8bc>] cfg80211_stop_ap+0xcc/0x190 [cfg80211]
[  444.211060]  [<f851b761>] cfg80211_netdev_notifier_call+0x591/0x740 [cfg80211]
[  444.211060]  [<c09c6c70>] ? packet_seq_start+0x70/0x70
[  444.211060]  [<c09c6d28>] ? packet_notifier+0xb8/0x1b0
[  444.211060]  [<c09c6d41>] ? packet_notifier+0xd1/0x1b0
[  444.211060]  [<c09c6c70>] ? packet_seq_start+0x70/0x70
[  444.211060]  [<c09ebac3>] notifier_call_chain+0x43/0x60
[  444.211060]  [<c047ac7f>] raw_notifier_call_chain+0x1f/0x30
[  444.211060]  [<c08e9f0c>] call_netdevice_notifiers+0x2c/0x60
[  444.211060]  [<c090419c>] ? netpoll_rx_disable+0x5c/0x90
[  444.211060]  [<c08e9f74>] __dev_close_many+0x34/0xb0
[  444.211060]  [<c0904140>] ? find_skb+0x90/0x90
[  444.211060]  [<c08ea033>] __dev_close+0x43/0x80
[  444.211060]  [<c08e9492>] __dev_change_flags+0x82/0x150
[  444.211060]  [<c04842d0>] ? cpuacct_charge+0x90/0xc0
[  444.211060]  [<c08ea9e3>] dev_change_flags+0x23/0x60
[  444.211060]  [<c08f92dc>] do_setlink+0x21c/0x7a0
[  444.211060]  [<c04842d0>] ? cpuacct_charge+0x90/0xc0
[  444.211060]  [<c04842e9>] ? cpuacct_charge+0xa9/0xc0
[  444.211060]  [<c06ca842>] ? nla_parse+0x22/0xd0
[  444.211060]  [<c08fc059>] rtnl_newlink+0x539/0x5c0
[  444.211060]  [<c04b15c4>] ? mark_held_locks+0x64/0xf0
[  444.211060]  [<c09e537b>] ? __mutex_lock_common+0x34b/0x430
[  444.992227]  [<c064f10c>] ? security_capable+0x1c/0x30
[  444.992227]  [<c045e35a>] ? ns_capable+0x2a/0x60
[  444.992227]  [<c08fbb20>] ? rtnl_configure_link+0xb0/0xb0
[  444.992227]  [<c08f8d9b>] rtnetlink_rcv_msg+0x27b/0x2f0
[  444.992227]  [<c08f8b20>] ? rtnetlink_rcv+0x30/0x30
[  444.992227]  [<c0912716>] netlink_rcv_skb+0x86/0xb0
[  444.992227]  [<c08f8b0c>] rtnetlink_rcv+0x1c/0x30
[  444.992227]  [<c091245d>] netlink_unicast+0x17d/0x1f0
[  444.992227]  [<c09130f4>] netlink_sendmsg+0x204/0x310
[  444.992227]  [<c08d7eda>] sock_sendmsg+0xba/0xf0
[  444.992227]  [<c0537d3d>] ? might_fault+0x7d/0x90
[  444.992227]  [<c06b3c1d>] ? _copy_from_user+0x3d/0x130
[  444.992227]  [<c08e2a8b>] ? verify_iovec+0x5b/0xb0
[  444.992227]  [<c08d8e15>] __sys_sendmsg+0x2c5/0x2e0
[  444.992227]  [<c09e7b7a>] ? _raw_spin_lock+0x4a/0x50
[  444.992227]  [<c04b3209>] ? lock_release_non_nested+0x59/0x2e0
[  444.992227]  [<c0537cf3>] ? might_fault+0x33/0x90
[  444.992227]  [<c08d8fbb>] sys_sendmsg+0x3b/0x60
[  444.992227]  [<c08d92df>] sys_socketcall+0x10f/0x2d0
[  444.992227]  [<c09e9531>] ? do_device_not_available+0x21/0x40
[  444.992227]  [<c09e88e4>] ? restore_all+0xf/0xf
[  444.992227]  [<c09eed8d>] sysenter_do_call+0x12/0x38
[  444.992227] Code: 00 03 66 81 fa 00 03 0f 45 c7 0f b6 00 83 e0 0f 0f b6 c8 6b d1 70 03 95 5c ff ff ff 89 8d 54 ff ff ff 8d 7a 0c 89 bd 68 ff ff ff <0f> b7 52 
5c 66 89 95 2c ff ff ff 8b 55 84 f6 42 0c 01 0f 85 e3
[  444.992227] EIP: [<f864f8b5>] ath_tx_process_buffer+0x175/0xb90 [ath9k] SS:ESP 0068:f152769c
[  444.992227] CR2: 0000000000000540
[  445.246540] ---[ end trace 7315411fcce19c5d ]---


Thanks,
Ben


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

[ath9k-devel] 3.9.0-rc8+ (hacked) splat.

[Ben Greear]

On 04/30/2013 11:05 AM, Ben Greear wrote:
> On 04/28/2013 08:05 AM, Ben Greear wrote:
>> On 04/27/2013 01:58 AM, Felix Fietkau wrote:
>>> On 2013-04-27 1:46 AM, Ben Greear wrote:
>>>> Was running around 200 stations against a VAP on this system, and
>>>> then changed the channel from 1 to 36 (by restarting hostapd with new
>>>> config).
>>>>
>>>> Looks like null-pointer de-ref...  Anyone seen anything similar?
>>> I've never seen this one. Please use gdb to figure out the source code
>>> line that the NULL pointer deref happens in.
>>> As for the 'keycache entry 228 out of range' stuff, I'm going to send a
>>> patch for that now.
>>
>> Thanks.
>>
>> I'm away from the office for a bit, but will build a debugging kernel
>> and crank on this early next week.
>
> Ok, this is against a modified 3.9.0 tree.  My patches are here:
>
> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.9.dev.y/.git;a=summary
>
> I'm going to try reproducing against upstream 3.9.0 (using a smaller number of
> stations since upstream doesn't have needed optimizations to make it work on
> my hardware...)

With the wpa_supplicant optimizations I posted yesterday, I can
reproduce the crash on a standard 3.9.0 kernel with the regdomain
patch AND the "mac80211: Add per-sdata station hash, and sdata hash."

https://patchwork.kernel.org/patch/2482351/

I was not able to reproduce this without the hash optimization patch,
so either it's buggy, or it just makes things a lot faster and that
triggers bugs in ath9k more easily.....

Thanks,
Ben

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

[ath9k-devel] 3.9.0-rc8+ (hacked) splat.

[Felix Fietkau]

On 2013-05-01 6:01 PM, Ben Greear wrote:
> On 04/30/2013 11:05 AM, Ben Greear wrote:
>> On 04/28/2013 08:05 AM, Ben Greear wrote:
>>> On 04/27/2013 01:58 AM, Felix Fietkau wrote:
>>>> On 2013-04-27 1:46 AM, Ben Greear wrote:
>>>>> Was running around 200 stations against a VAP on this system, and
>>>>> then changed the channel from 1 to 36 (by restarting hostapd with new
>>>>> config).
>>>>>
>>>>> Looks like null-pointer de-ref...  Anyone seen anything similar?
>>>> I've never seen this one. Please use gdb to figure out the source code
>>>> line that the NULL pointer deref happens in.
>>>> As for the 'keycache entry 228 out of range' stuff, I'm going to send a
>>>> patch for that now.
>>>
>>> Thanks.
>>>
>>> I'm away from the office for a bit, but will build a debugging kernel
>>> and crank on this early next week.
>>
>> Ok, this is against a modified 3.9.0 tree.  My patches are here:
>>
>> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.9.dev.y/.git;a=summary
>>
>> I'm going to try reproducing against upstream 3.9.0 (using a smaller number of
>> stations since upstream doesn't have needed optimizations to make it work on
>> my hardware...)
> 
> With the wpa_supplicant optimizations I posted yesterday, I can
> reproduce the crash on a standard 3.9.0 kernel with the regdomain
> patch AND the "mac80211: Add per-sdata station hash, and sdata hash."
> 
> https://patchwork.kernel.org/patch/2482351/
> 
> I was not able to reproduce this without the hash optimization patch,
> so either it's buggy, or it just makes things a lot faster and that
> triggers bugs in ath9k more easily.....
It's buggy. Take a look at this part:

> diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
> index 238a0cc..6b0fe74 100644
> --- a/net/mac80211/sta_info.c
> +++ b/net/mac80211/sta_info.c
> @@ -965,6 +1018,13 @@ struct ieee80211_sta *ieee80211_find_sta_by_ifaddr(struct ieee80211_hw *hw,
>  {
>  	struct sta_info *sta, *nxt;
>  
> +	if (localaddr) {
> +		sta = sta_info_get_by_vif(hw_to_local(hw), localaddr, addr);
> +		if (sta && !sta->uploaded)
> +			return NULL;
> +		return &sta->sta;
> +	}
If sta is NULL, it'll return &sta->sta, which is non-NULL. It matches
the null-pointer crash on dereferencing the driver's tid struct inside
sta->drv_priv.

- Felix

[ath9k-devel] 3.9.0-rc8+ (hacked) splat.

[Ben Greear]

On 05/01/2013 09:08 AM, Felix Fietkau wrote:
> On 2013-05-01 6:01 PM, Ben Greear wrote:
>> On 04/30/2013 11:05 AM, Ben Greear wrote:
>>> On 04/28/2013 08:05 AM, Ben Greear wrote:
>>>> On 04/27/2013 01:58 AM, Felix Fietkau wrote:
>>>>> On 2013-04-27 1:46 AM, Ben Greear wrote:
>>>>>> Was running around 200 stations against a VAP on this system, and
>>>>>> then changed the channel from 1 to 36 (by restarting hostapd with new
>>>>>> config).
>>>>>>
>>>>>> Looks like null-pointer de-ref...  Anyone seen anything similar?
>>>>> I've never seen this one. Please use gdb to figure out the source code
>>>>> line that the NULL pointer deref happens in.
>>>>> As for the 'keycache entry 228 out of range' stuff, I'm going to send a
>>>>> patch for that now.
>>>>
>>>> Thanks.
>>>>
>>>> I'm away from the office for a bit, but will build a debugging kernel
>>>> and crank on this early next week.
>>>
>>> Ok, this is against a modified 3.9.0 tree.  My patches are here:
>>>
>>> http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-3.9.dev.y/.git;a=summary
>>>
>>> I'm going to try reproducing against upstream 3.9.0 (using a smaller number of
>>> stations since upstream doesn't have needed optimizations to make it work on
>>> my hardware...)
>>
>> With the wpa_supplicant optimizations I posted yesterday, I can
>> reproduce the crash on a standard 3.9.0 kernel with the regdomain
>> patch AND the "mac80211: Add per-sdata station hash, and sdata hash."
>>
>> https://patchwork.kernel.org/patch/2482351/
>>
>> I was not able to reproduce this without the hash optimization patch,
>> so either it's buggy, or it just makes things a lot faster and that
>> triggers bugs in ath9k more easily.....
> It's buggy. Take a look at this part:
>
>> diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
>> index 238a0cc..6b0fe74 100644
>> --- a/net/mac80211/sta_info.c
>> +++ b/net/mac80211/sta_info.c
>> @@ -965,6 +1018,13 @@ struct ieee80211_sta *ieee80211_find_sta_by_ifaddr(struct ieee80211_hw *hw,
>>   {
>>   	struct sta_info *sta, *nxt;
>>
>> +	if (localaddr) {
>> +		sta = sta_info_get_by_vif(hw_to_local(hw), localaddr, addr);
>> +		if (sta && !sta->uploaded)
>> +			return NULL;
>> +		return &sta->sta;
>> +	}
> If sta is NULL, it'll return &sta->sta, which is non-NULL. It matches
> the null-pointer crash on dereferencing the driver's tid struct inside
> sta->drv_priv.

Ahh, thanks so much!

That does appear to be the cause...

Thanks,
Ben

>
> - Felix
>


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