22 Feb, 2011

3 commits

  • I previously managed to reproduce a hang while scanning wireless
    channels (reproducible with airodump-ng hopping channels); subsequent
    lockdep instrumentation revealed a lock ordering issue.

    Without knowing the design intent, it looks like the locks should be
    taken in reverse order; please comment.

    =======================================================
    [ INFO: possible circular locking dependency detected ]
    2.6.38-rc5-341cd #4
    -------------------------------------------------------
    airodump-ng/15445 is trying to acquire lock:
    (&rdev->devlist_mtx){+.+.+.}, at: []
    cfg80211_wext_siwfreq+0xc6/0x100

    but task is already holding lock:
    (&wdev->mtx){+.+.+.}, at: [] cfg80211_wext_siwfreq+0xbc/0x100

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #1 (&wdev->mtx){+.+.+.}:
    [] lock_acquire+0xc6/0x280
    [] mutex_lock_nested+0x6e/0x4b0
    [] cfg80211_netdev_notifier_call+0x430/0x5f0
    [] notifier_call_chain+0x8b/0x100
    [] raw_notifier_call_chain+0x11/0x20
    [] call_netdevice_notifiers+0x32/0x60
    [] __dev_notify_flags+0x34/0x80
    [] dev_change_flags+0x40/0x70
    [] do_setlink+0x1fc/0x8d0
    [] rtnl_setlink+0xf2/0x140
    [] rtnetlink_rcv_msg+0x163/0x270
    [] netlink_rcv_skb+0xa1/0xd0
    [] rtnetlink_rcv+0x20/0x30
    [] netlink_unicast+0x2ba/0x300
    [] netlink_sendmsg+0x267/0x3e0
    [] sock_sendmsg+0xe4/0x110
    [] sys_sendmsg+0x253/0x3b0
    [] system_call_fastpath+0x16/0x1b

    -> #0 (&rdev->devlist_mtx){+.+.+.}:
    [] __lock_acquire+0x1622/0x1d10
    [] lock_acquire+0xc6/0x280
    [] mutex_lock_nested+0x6e/0x4b0
    [] cfg80211_wext_siwfreq+0xc6/0x100
    [] ioctl_standard_call+0x5d/0xd0
    [] T.808+0x163/0x170
    [] wext_handle_ioctl+0x3a/0x90
    [] dev_ioctl+0x6f2/0x830
    [] sock_ioctl+0xfd/0x290
    [] do_vfs_ioctl+0x9d/0x590
    [] sys_ioctl+0x4a/0x80
    [] system_call_fastpath+0x16/0x1b

    other info that might help us debug this:

    2 locks held by airodump-ng/15445:
    #0: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x20
    #1: (&wdev->mtx){+.+.+.}, at: []
    cfg80211_wext_siwfreq+0xbc/0x100

    stack backtrace:
    Pid: 15445, comm: airodump-ng Not tainted 2.6.38-rc5-341cd #4
    Call Trace:
    [] ? print_circular_bug+0xfa/0x100
    [] ? __lock_acquire+0x1622/0x1d10
    [] ? trace_hardirqs_off_caller+0x29/0xc0
    [] ? lock_acquire+0xc6/0x280
    [] ? cfg80211_wext_siwfreq+0xc6/0x100
    [] ? mark_held_locks+0x67/0x90
    [] ? mutex_lock_nested+0x6e/0x4b0
    [] ? cfg80211_wext_siwfreq+0xc6/0x100
    [] ? mark_held_locks+0x67/0x90
    [] ? cfg80211_wext_siwfreq+0xc6/0x100
    [] ? cfg80211_wext_siwfreq+0xc6/0x100
    [] ? ioctl_standard_call+0x5d/0xd0
    [] ? __dev_get_by_name+0x9b/0xc0
    [] ? ioctl_standard_call+0x0/0xd0
    [] ? T.808+0x163/0x170
    [] ? might_fault+0x72/0xd0
    [] ? wext_handle_ioctl+0x3a/0x90
    [] ? might_fault+0xbb/0xd0
    [] ? dev_ioctl+0x6f2/0x830
    [] ? put_lock_stats+0xe/0x40
    [] ? lock_release_holdtime+0xac/0x150
    [] ? sock_ioctl+0xfd/0x290
    [] ? do_vfs_ioctl+0x9d/0x590
    [] ? fget_light+0x1df/0x3c0
    [] ? sys_ioctl+0x4a/0x80
    [] ? system_call_fastpath+0x16/0x1b

    Signed-off-by: Daniel J Blueman
    Acked-by: Johannes Berg
    Signed-off-by: John W. Linville

    Daniel J Blueman
     
  • As reported and found by Johannes Stezenbach:
    rt2800{pci,usb} do not report the Michael MIC in RXed frames, but do check
    the Michael MIC in hardware. Therefore we have to report to mac80211 that the
    received frame does not include the Michael MIC.

    https://bugzilla.kernel.org/show_bug.cgi?id=16608

    Signed-off-by: Gertjan van Wingerde
    Signed-off-by: Ivo van Doorn
    Signed-off-by: John W. Linville

    Gertjan van Wingerde
     
  • Fast channel change fixes:

    a) Always set OFDM timings
    b) Don't re-activate PHY
    c) Enable only NF calibration, not AGC

    https://bugzilla.kernel.org/show_bug.cgi?id=27382

    Signed-off-by: Nick Kossifidis
    Signed-off-by: John W. Linville

    Nick Kossifidis
     

19 Feb, 2011

4 commits

  • Correct channel setting function must be used for AR2317.
    When I tested ahb patch on bullet2 all seemed to work fine,
    but it couldn't connect another host (using ibss for example).
    During an analysis I observed that it's transmitting on another
    channel. I looked into madwifi code and understood that
    the problem is in channel setting function. So atheros RF2317 not
    fully handled in the current ath5k version and must be patched.

    Signed-off-by: Nikolay Ledovskikh
    Acked-by: Bob Copeland
    Signed-off-by: John W. Linville

    Nikolay Ledovskikh
     
  • taken two RT35XX EDIMAX from DPO_RT3562_3592_3062_LinuxSTA_V2.4.1.1_20101217

    Signed-off-by: Xose Vazquez Perez
    Acked-by: Ivo van Doorn
    Signed-off-by: John W. Linville

    Xose Vazquez Perez
     
  • Low level driver could pass rx frames to us after disassociate, what
    can lead to run conn_mon_timer by ieee80211_sta_rx_notify(). That
    is obviously wrong, but nothing happens until we unload modules and
    resources are used after free. If kernel debugging is enabled following
    warning could be observed:

    WARNING: at lib/debugobjects.c:259 debug_print_object+0x65/0x70()
    Hardware name: HP xw8600 Workstation
    ODEBUG: free active (active state 0) object type: timer_list
    Modules linked in: iwlagn(-) iwlcore mac80211 cfg80211 aes_x86_64 aes_generic fuse cpufreq_ondemand acpi_cpufreq freq_table mperf xt_physdev ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ext3 jbd dm_mirror dm_region_hash dm_log dm_mod uinput hp_wmi sparse_keymap sg wmi arc4 microcode serio_raw ecb tg3 shpchp rfkill ext4 mbcache jbd2 sr_mod cdrom sd_mod crc_t10dif firewire_ohci firewire_core crc_itu_t mptsas mptscsih mptbase scsi_transport_sas ahci libahci pata_acpi ata_generic ata_piix floppy nouveau ttm drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: cfg80211]
    Pid: 13827, comm: rmmod Tainted: G W 2.6.38-rc4-wl+ #22
    Call Trace:
    [] ? warn_slowpath_common+0x7f/0xc0
    [] ? warn_slowpath_fmt+0x46/0x50
    [] ? debug_print_object+0x65/0x70
    [] ? debug_check_no_obj_freed+0x125/0x210
    [] ? debug_check_no_locks_freed+0xf7/0x170
    [] ? kfree+0xc2/0x2f0
    [] ? netdev_release+0x45/0x60
    [] ? device_release+0x27/0xa0
    [] ? kobject_release+0x8d/0x1a0
    [] ? kobject_release+0x0/0x1a0
    [] ? kref_put+0x37/0x70
    [] ? kobject_put+0x27/0x60
    [] ? netdev_run_todo+0x1ab/0x270
    [] ? rtnl_unlock+0xe/0x10
    [] ? ieee80211_unregister_hw+0x58/0x120 [mac80211]
    [] ? iwl_pci_remove+0xdb/0x22a [iwlagn]
    [] ? pci_device_remove+0x52/0x120
    [] ? __device_release_driver+0x75/0xe0
    [] ? driver_detach+0xd8/0xe0
    [] ? bus_remove_driver+0x91/0x100
    [] ? driver_unregister+0x62/0xa0
    [] ? pci_unregister_driver+0x44/0xa0
    [] ? iwl_exit+0x15/0x1c [iwlagn]
    [] ? sys_delete_module+0x1a2/0x270
    [] ? trace_hardirqs_on_thunk+0x3a/0x3f
    [] ? system_call_fastpath+0x16/0x1b

    Acked-by: Johannes Berg
    Signed-off-by: Stanislaw Gruszka
    Signed-off-by: John W. Linville

    Stanislaw Gruszka
     
  • John W. Linville
     

17 Feb, 2011

3 commits


16 Feb, 2011

1 commit

  • The DMA latency issue is observed only in Intel pinetrail platforms
    but in the driver we had a default PM-QOS value of 55. This caused
    unnecessary power consumption and battery drain in other platforms.

    Remove the pm-qos thing in the driver code and address the throughput
    issue in Intel pinetrail platfroms in user space using any one of
    the scripts in below links:

    http://www.kernel.org/pub/linux/kernel/people/mcgrof/scripts/cpudmalatency.c
    http://johannes.sipsolutions.net/files/netlatency.c.txt

    More details can be found in the following bugzilla link:

    https://bugzilla.kernel.org/show_bug.cgi?id=27532

    This reverts the following commits:

    98c316e348bedffa730e6f1e4baeb8a3c3e0f28b
    4dc3530df7c0428b41c00399a7ee8c929406d181
    10598c124ecabbbfd7522f74de19b8f7d52a1bee

    Signed-off-by: Mohammed Shafi Shajakhan
    Signed-off-by: John W. Linville

    Mohammed Shafi Shajakhan
     

10 Feb, 2011

3 commits

  • When suspending an associated system, and then resuming,
    the station vif is being reconfigured without taking the
    sdata->u.mgd.mtx lock, which results in the following warning:

    WARNING: at net/mac80211/mlme.c:101 ieee80211_ap_probereq_get+0x58/0xb8 [mac80211]()
    Modules linked in: wl12xx_sdio wl12xx firmware_class crc7 mac80211 cfg80211 [last unloaded: crc7]
    Backtrace:
    [] (dump_backtrace+0x0/0x118) from [] (dump_stack+0x20/0x24)
    r7:00000000 r6:bf12d6ec r5:bf154aac r4:00000065
    [] (dump_stack+0x0/0x24) from [] (warn_slowpath_common+0x5c/0x74)
    [] (warn_slowpath_common+0x0/0x74) from [] (warn_slowpath_null+0x2c/0x34)
    r9:000024ff r8:cd006460 r7:00000001 r6:00000000 r5:00000000
    r4:cf1394a0
    [] (warn_slowpath_null+0x0/0x34) from [] (ieee80211_ap_probereq_get+0x58/0xb8 [mac80211])
    [] (ieee80211_ap_probereq_get+0x0/0xb8 [mac80211]) from [] (wl1271_cmd_build_ap_probe_req+0x30/0xf8 [wl12xx])
    r4:cd007440
    [] (wl1271_cmd_build_ap_probe_req+0x0/0xf8 [wl12xx]) from [] (wl1271_op_bss_info_changed+0x4c4/0x808 [wl12xx])
    r5:cd007440 r4:000003b4
    [] (wl1271_op_bss_info_changed+0x0/0x808 [wl12xx]) from [] (ieee80211_bss_info_change_notify+0x1a4/0x1f8 [mac80211])
    [] (ieee80211_bss_info_change_notify+0x0/0x1f8 [mac80211]) from [] (ieee80211_reconfig+0x4d0/0x668 [mac80211])
    r8:cf0eeea4 r7:cd00671c r6:00000000 r5:cd006460 r4:cf1394a0
    [] (ieee80211_reconfig+0x0/0x668 [mac80211]) from [] (ieee80211_resume+0x60/0x70 [mac80211])
    [] (ieee80211_resume+0x0/0x70 [mac80211]) from [] (wiphy_resume+0x6c/0x7c [cfg80211])
    r5:cd006248 r4:cd006110
    [] (wiphy_resume+0x0/0x7c [cfg80211]) from [] (legacy_resume+0x38/0x70)
    r7:00000000 r6:00000000 r5:cd006248 r4:cd0062fc
    [] (legacy_resume+0x0/0x70) from [] (device_resume+0x168/0x1a0)
    r8:c04ca8d8 r7:cd00627c r6:00000010 r5:cd006248 r4:cd0062fc
    [] (device_resume+0x0/0x1a0) from [] (dpm_resume_end+0xf8/0x3bc)
    r7:00000000 r6:00000005 r5:cd006248 r4:cd0062fc
    [] (dpm_resume_end+0x0/0x3bc) from [] (suspend_devices_and_enter+0x1b0/0x204)
    [] (suspend_devices_and_enter+0x0/0x204) from [] (enter_state+0xf0/0x148)
    r7:c037e978 r6:00000003 r5:c043d807 r4:00000000
    [] (enter_state+0x0/0x148) from [] (state_store+0xa4/0xcc)
    r7:c037e978 r6:00000003 r5:00000003 r4:c043d807
    [] (state_store+0x0/0xcc) from [] (kobj_attr_store+0x20/0x24)
    [] (kobj_attr_store+0x0/0x24) from [] (sysfs_write_file+0x11c/0x150)
    [] (sysfs_write_file+0x0/0x150) from [] (vfs_write+0xc0/0x14c)
    [] (vfs_write+0x0/0x14c) from [] (sys_write+0x4c/0x78)
    r8:40126000 r7:00000004 r6:cf1a7c80 r5:00000000 r4:00000000
    [] (sys_write+0x0/0x78) from [] (ret_fast_syscall+0x0/0x30)
    r8:c00502c8 r7:00000004 r6:403525e8 r5:40126000 r4:00000004

    Signed-off-by: Eliad Peller
    Signed-off-by: John W. Linville

    Eliad Peller
     
  • Patch fixes:
    https://bugzilla.redhat.com/show_bug.cgi?id=654599

    Many users report very low speed problem on 3945 devices,
    this patch fixes problem, but only for some of them.

    For unknown reason, sometimes after hw scanning, device is not able
    to receive frames at high rate. Since plcp health check may request
    hw scan to "reset radio", performance problem start to be observable
    after update kernel to .35, where plcp check was introduced.

    Bug reporter confirmed that removing plcp check fixed problem for him.

    Reported-and-tested-by: SilvioTO
    Cc: stable@kernel.org # 2.6.35+
    Signed-off-by: Stanislaw Gruszka
    Acked-by: Wey-Yi Guy
    Signed-off-by: John W. Linville

    Stanislaw Gruszka
     
  • John W. Linville
     

08 Feb, 2011

3 commits

  • Using skb_header_cloned to check if it's safe to write to the skb is not
    enough - mac80211 also touches the tailroom of the skb.
    Initially this check was only used to increase a counter, however this
    commit changed the code to also skip skb data reallocation if no extra
    head/tailroom was needed:

    commit 4cd06a344db752f513437138953af191cbe9a691
    mac80211: skip unnecessary pskb_expand_head calls

    It added a regression at least with iwl3945, which is fixed by this patch.

    Reported-by: Dmitry Torokhov
    Signed-off-by: Felix Fietkau
    Tested-by: Dmitry Torokhov
    Signed-off-by: John W. Linville

    Felix Fietkau
     
  • With commit 554d1d027b19265c4aa3f718b3126d2b86e09a08 only one RF_KILL
    interrupt will be seen by the driver when the interface is down.

    Re-enable the interrupt when it occurs to see all transitions.

    Signed-off-by: Don Fry
    Signed-off-by: Wey-Yi Guy
    Cc: stable@kernel.org
    Signed-off-by: John W. Linville

    Don Fry
     
  • This fixes parsing of the device invariants (MAC address)
    for PCMCIA SSB devices.

    ssb_pcmcia_do_get_invariants expects an iv pointer as data
    argument.

    Tested-by: dylan cristiani
    Signed-off-by: Michael Buesch
    Cc: stable@kernel.org
    Signed-off-by: John W. Linville

    Michael Büsch
     

05 Feb, 2011

2 commits

  • This patch reverts the following commit
    ath9k: remove bfs_paprd_timestamp from struct ath_buf_state

    Under high interference/noisy environment conditions where PAPRD frames
    fails heavily introduces a possibility of double freeing skb's and causes
    kernel panic after some time.This patch reverts back to the original approach
    of using paprd_timestamp before freeing the PAPRD frame skb's

    [ 194.193705] Pid: 0, comm: swapper Tainted: G D WC
    2.6.35-22-generic #33-Ubuntu
    [ 194.193712] Call Trace:
    [ 194.193722] [] ? printk+0x2d/0x35
    [ 194.193732] [] panic+0x5a/0xd2
    [ 194.193741] [] oops_end+0xcd/0xd0
    [ 194.193750] [] die+0x54/0x80
    [ 194.193758] [] do_trap+0x96/0xc0
    [ 194.193837] [] ? do_invalid_op+0x0/0xa0
    [ 194.193846] [] do_invalid_op+0x8b/0xa0
    [ 194.193856] [] ? kfree+0xec/0xf0
    [ 194.193866] [] ? default_spin_lock_flags+0x8/0x10
    [ 194.193877] [] ? free_one_page+0x12a/0x2d0
    [ 194.193888] [] ? __free_pages+0x1c/0x40
    [ 194.193897] [] error_code+0x73/0x78
    [ 194.193906] [] ? kfree+0xec/0xf0
    [ 194.193915] [] ? skb_release_data+0x70/0xa0
    [ 194.193924] [] skb_release_data+0x70/0xa0
    [ 194.193933] [] __kfree_skb+0x17/0x90
    [ 194.193941] [] consume_skb+0x21/0x40
    [ 194.193964] [] ieee80211_tx_status+0x760/0x860 [mac80211]
    [ 194.193979] [] ath_tx_complete_buf+0x1bf/0x2c0 [ath9k]
    [ 194.193988] [] ? _raw_spin_lock_irqsave+0x2f/0x50
    [ 194.193997] [] ? skb_queue_tail+0x3e/0x50
    [ 194.194010] [] ath_tx_complete_aggr+0x823/0x940 [ath9k]
    [ 194.194021] [] ? sched_clock+0x8/0x10
    [ 194.194030] [] ? sched_clock_local+0xa4/0x180
    [ 194.194040] [] ? enqueue_sleeper+0x1e7/0x2b0
    [ 194.194051] [] ? enqueue_entity+0x174/0x200
    [ 194.194064] [] ath_tx_edma_tasklet+0x2bd/0x3b0 [ath9k]
    [ 194.194074] [] ? _raw_spin_lock_irqsave+0x2f/0x50
    [ 194.194088] [] ath9k_tasklet+0x9f/0x190 [ath9k]
    [ 194.194097] [] tasklet_action+0xa7/0xb0
    [ 194.194107] [] __do_softirq+0x9c/0x1b0
    [ 194.194117] [] ? irq_to_desc+0x14/0x20
    [ 194.194126] [] ? ack_apic_level+0x64/0x1f0
    [ 194.194136] [] do_softirq+0x45/0x50
    [ 194.194145] [] irq_exit+0x65/0x70
    [ 194.194153] [] do_IRQ+0x55/0xc0
    [ 194.194162] [] ? hrtimer_start+0x27/0x30
    [ 194.194171] [] common_interrupt+0x30/0x38
    [ 194.194181] [] ? native_safe_halt+0xa/0x10
    [ 194.194268] [] default_idle+0x49/0xb0
    [ 194.194277] [] cpu_idle+0x8c/0xd0
    [ 194.194286] [] rest_init+0x71/0x80
    [ 194.194295] [] start_kernel+0x36e/0x374
    [ 194.194305] [] ? pass_all_bootoptions+0x0/0xa
    [ 194.194314] [] i386_start_kernel+0xd7/0xdf
    [ 194.194364] panic occurred, switching back to text console

    Signed-off-by: Mohammed Shafi Shajakhan
    Signed-off-by: John W. Linville

    Mohammed Shafi Shajakhan
     
  • This patch fixes a off-by-one bug which bugged
    the driver's PS-POLL capability.

    Cc:
    Signed-off-by: Christian Lamparter
    Signed-off-by: John W. Linville

    Christian Lamparter
     

04 Feb, 2011

1 commit


03 Feb, 2011

2 commits

  • When the off-channel TX is done with remain-on-channel
    offloaded to hardware, the reported cookie is wrong as
    in that case we shouldn't use the SKB as the cookie but
    need to instead use the corresponding r-o-c cookie
    (XOR'ed with 2 to prevent API mismatches).

    Fix this by keeping track of the hw_roc_skb pointer
    just for the status processing and use the correct
    cookie to report in this case. We can't use the
    hw_roc_skb pointer itself because it is NULL'ed when
    the frame is transmitted to prevent it being used
    twice.

    This fixes a bug where the P2P state machine in the
    supplicant gets stuck because it never gets a correct
    result for its transmitted frame.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     
  • 6250 2x2 devices have 2 tx chain and 2 rx chain. For some reason,
    the EEPROM contain incorrect information and indicate it only has single
    tx chain. overwrite it with .cfg parameter to make sure both chain 'A' and
    chain 'B' can be used for transmit and receive

    Signed-off-by: Wey-Yi Guy
    Signed-off-by: John W. Linville

    Wey-Yi Guy
     

02 Feb, 2011

2 commits

  • This patch fixes a minor issue that two connection responses will be sent
    for one L2CAP connection request. If the L2CAP connection request is first
    blocked due to security reason and responded with reason "security block",
    the state of the connection remains BT_CONNECT2. If a pairing procedure
    completes successfully before the ACL connection is down, local host will
    send another connection complete response. See the following packets
    captured by hcidump.

    2010-12-07 22:21:24.928096 < ACL data: handle 12 flags 0x00 dlen 16
    0000: 0c 00 01 00 03 19 08 00 41 00 53 00 03 00 00 00 ........A.S.....
    ... ...

    2010-12-07 22:21:35.791747 > HCI Event: Auth Complete (0x06) plen 3
    status 0x00 handle 12
    ... ...

    2010-12-07 22:21:35.872372 > ACL data: handle 12 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0054 scid 0x0040 result 0 status 0
    Connection successful

    Signed-off-by: Liang Bao
    Acked-by: Ville Tervo
    Signed-off-by: Gustavo F. Padovan

    Bao Liang
     
  • free the skb's when the Tx of PAPRD frames fails and also add a debug
    message indicating that.

    Signed-off-by: Mohammed Shafi Shajakhan
    Signed-off-by: John W. Linville

    Mohammed Shafi Shajakhan
     

01 Feb, 2011

1 commit

  • When DEBUG_SPI is included in the debug log level wl1271_spi_reset()
    will dump the already freed memory instead of the SPI buffer.

    This bug was spotted by the semantic patch tool coccinelle using the
    script found at scripts/coccinelle/free/kfree.cocci.

    More information about semantic patching is available at
    http://coccinelle.lip6.fr/

    Signed-off-by: Mathias Krause
    Signed-off-by: John W. Linville

    Mathias Krause
     

29 Jan, 2011

2 commits

  • While unloading the driver, the ps_usecount is incremented
    before configuring gpio registers in deinit_device.
    But it is failed to restore the ps_usecount after that.
    The problem is that the chip is forcibly moved to FULL SLEEP
    by radio_disable when mac80211 is reporting as idle
    though ps_usecount is not zero.

    This patch retores ps_usecount properly and ensures that
    the chip is always moved to full sleep only if ps usage
    count is zero which also helps in debugging deadbeef on
    multivif case. And also fixes the following warning.

    ath: DMA failed to stop in 10 ms AR_CR=0xdeadbeef AR_DIAG_SW=0xdeadbeef
    ath: Could not stop RX, we could be confusing the DMA engine when we
    start RX up
    ------------[ cut here ]------------
    WARNING: at drivers/net/wireless/ath/ath9k/recv.c:536
    ath_stoprecv+0xf4/0x100 [ath9k]()

    Cc: stable@kernel.org
    Cc: Paul Stewart
    Signed-off-by: Rajkumar Manoharan
    Signed-off-by: John W. Linville

    Rajkumar Manoharan
     
  • The bit 6 & 7 of AR_WA (0x4004) should be enabled only
    for the chips that are supporting L0s functionality
    while resuming back from S3/S4.

    Enabling these bits for AR9280 is causing system hang
    within a few S3/S4-resume cycles.

    Cc: stable@kernel.org
    Cc: Jack Lee
    Signed-off-by: Rajkumar Manoharan
    Signed-off-by: John W. Linville

    Rajkumar Manoharan
     

28 Jan, 2011

6 commits

  • Update maintainer's email address, webpage and align with renaming of
    files.

    Signed-off-by: Luciano Coelho
    Signed-off-by: John W. Linville

    Luciano Coelho
     
  • We do not kill any scheduled tasklets when stopping device, that may
    cause usage of resources after free. Disable interrupts, kill tasklets
    and then works in correct order.

    Cc: stable@kernel.org
    Tested-by: Sujith
    Signed-off-by: Stanislaw Gruszka
    Signed-off-by: John W. Linville

    Stanislaw Gruszka
     
  • We do not kill any scheduled tasklets when stopping device, that may
    cause usage of resources after free. Moreover we enable interrupts
    in tasklet function, so we could potentially end with interrupts
    enabled when driver is not ready to receive them.

    I think patch should fix Ben's kernel crash from:
    http://marc.info/?l=linux-wireless&m=129438358921501&w=2

    Cc: stable@kernel.org
    Signed-off-by: Stanislaw Gruszka
    Signed-off-by: John W. Linville

    Stanislaw Gruszka
     
  • The ath5k version of ieee80211_generic_frame_duration() returns
    an __le16 for standard modes but a cpu-endian int for turbo/half/
    quarter rates. Make it always return cpu-endian values.

    Signed-off-by: Bob Copeland
    Acked-by: Bruno Randolf
    Acked-by: Nick Kossifidis
    Signed-off-by: John W. Linville

    Bob Copeland
     
  • Review spotted a problem with the error handling in ath5k_hw_dma_stop:
    a successful return from ath5k_hw_stop_tx_dma will be treated as
    an error, so we always bail out of the loop after processing a single
    active queue. As a result, we may not actually stop some queues during
    reset.

    Signed-off-by: Bob Copeland
    Acked-by: Bruno Randolf
    Acked-by: Nick Kossifidis
    Reviewed-by: Stanislaw Gruszka
    Signed-off-by: John W. Linville

    Bob Copeland
     
  • When the source code from Realtek was prepared for kernel inclusion,
    some routines were refactored to reduce the level of indentation. This
    patch repairs errors introduced in that process.

    Signed-off-by: Chaoming Li
    Signed-off-by: Larry Finger
    Signed-off-by: John W. Linville

    Chaoming Li
     

27 Jan, 2011

1 commit


26 Jan, 2011

3 commits


22 Jan, 2011

3 commits

  • In drivers/net/wireless/rtlwifi/pci.c::_rtl_pci_rx_interrupt() we call
    dev_alloc_skb(), which may fail and return NULL, but we do not check the
    returned value against NULL before dereferencing the returned pointer.
    This may lead to a NULL pointer dereference which means we'll crash - not
    good.

    In a separate call to dev_alloc_skb(), the debug level is changed so that
    the failure message will always be logged.

    Signed-off-by: Jesper Juhl
    Signed-off-by: Larry Finger
    Signed-off-by: John W. Linville

    Jesper Juhl
     
  • There are several places where ath_reset() was called without proper
    calls to ath9k_ps_wakeup/ath9k_ps_restore. To fix this, add those calls
    directly to ath_reset and drop them from callers where it makes sense.

    Also add them to the config callback around ath_update_txpow to fix a
    crash that happens when the tx power changed before any vif is brought up.

    Signed-off-by: Felix Fietkau
    Cc: stable@kernel.org
    Signed-off-by: John W. Linville

    Felix Fietkau
     
  • AR9003's PAPRD was enabled prematurely, and is causing some
    large discrepancies on throughput and network connectivity.
    For example downlink (RX) throughput against an AR9280 AP
    can vary widlely from 43-73 Mbit/s while disabling this
    gets AR9382 (2x2) up to around 93 Mbit/s in a 2.4 GHz HT20 setup.

    Cc: stable@kernel.org
    Cc: Paul Shaw
    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez