1. 08 6月, 2010 5 次提交
  2. 06 6月, 2010 4 次提交
    • E
      iwlwifi: move sysfs_create_group to post request firmware · 7d47618a
      Emmanuel Grumbach 提交于
      Move the sysfs_create_group to iwl_ucode_callback after we
      have safely got the firmware.
      
      The motivation to do this comes from a warning from lockdep which detected
      that we request priv->mutex while holding s_active during a sysfs request
      (show_statistics in the example copy pasted). The reverse order exists upon
      request_firmware: request_firmware which is a sysfs operation
      that requires s_active is run under priv->mutex.
      
      This ensures that we don't get sysfs request before we finish to request
      the firmware, avoiding this deadlock.
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      -------------------------------------------------------
      cat/2595 is trying to acquire lock:
       (&priv->mutex){+.+.+.}, at: [<facfa598>] show_statistics+0x48/0x100 [iwlagn]
      
      but task is already holding lock:
       (s_active){++++.+}, at: [<c0580ebd>] sysfs_get_active_two+0x1d/0x50
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (s_active){++++.+}:
             [<c0489b74>] __lock_acquire+0xc44/0x1230
             [<c048a1ed>] lock_acquire+0x8d/0x110
             [<c0581499>] sysfs_addrm_finish+0xe9/0x180
             [<c057f64a>] sysfs_hash_and_remove+0x4a/0x80
             [<c05829d4>] sysfs_remove_group+0x44/0xd0
             [<c0714b75>] dpm_sysfs_remove+0x15/0x20
             [<c070dac8>] device_del+0x38/0x170
             [<c070dc1e>] device_unregister+0x1e/0x60
             [<c071838d>] _request_firmware+0x29d/0x550
             [<c07186c7>] request_firmware+0x17/0x20
             [<fad01bf1>] iwl_mac_start+0xb1/0x1230 [iwlagn]
             [<fa46ba06>] ieee80211_open+0x436/0x6f0 [mac80211]
             [<c0808cd2>] dev_open+0x92/0xf0
             [<c0808b2b>] dev_change_flags+0x7b/0x190
             [<c08148e8>] do_setlink+0x178/0x3b0
             [<c0815169>] rtnl_setlink+0xf9/0x130
             [<c081453b>] rtnetlink_rcv_msg+0x1bb/0x1f0
             [<c0827ce6>] netlink_rcv_skb+0x86/0xa0
             [<c081436c>] rtnetlink_rcv+0x1c/0x30
             [<c08279c3>] netlink_unicast+0x263/0x290
             [<c0828768>] netlink_sendmsg+0x1c8/0x2a0
             [<c07f85fd>] sock_sendmsg+0xcd/0x100
             [<c07f964d>] sys_sendmsg+0x15d/0x290
             [<c07f9e6b>] sys_socketcall+0xeb/0x2a0
             [<c040ad9f>] sysenter_do_call+0x12/0x38
      
      -> #0 (&priv->mutex){+.+.+.}:
             [<c0489f84>] __lock_acquire+0x1054/0x1230
             [<c048a1ed>] lock_acquire+0x8d/0x110
             [<c08bb358>] __mutex_lock_common+0x58/0x470
             [<c08bb84a>] mutex_lock_nested+0x3a/0x50
             [<facfa598>] show_statistics+0x48/0x100 [iwlagn]
             [<c070d219>] dev_attr_show+0x29/0x50
             [<c057fecd>] sysfs_read_file+0xdd/0x190
             [<c052880f>] vfs_read+0x9f/0x190
             [<c0528d22>] sys_read+0x42/0x70
             [<c040ad9f>] sysenter_do_call+0x12/0x38
      
      other info that might help us debug this:
      
      3 locks held by cat/2595:
       #0:  (&buffer->mutex){+.+.+.}, at: [<c057fe25>] sysfs_read_file+0x35/0x190
       #1:  (s_active){++++.+}, at: [<c0580ecd>] sysfs_get_active_two+0x2d/0x50
       #2:  (s_active){++++.+}, at: [<c0580ebd>] sysfs_get_active_two+0x1d/0x50
      
      stack backtrace:
      Pid: 2595, comm: cat Not tainted 2.6.33-tp-rc4 #2
      Call Trace:
       [<c08b99ab>] ? printk+0x1d/0x22
       [<c0487752>] print_circular_bug+0xc2/0xd0
       [<c0489f84>] __lock_acquire+0x1054/0x1230
       [<c0478d81>] ? sched_clock_cpu+0x121/0x180
       [<c048a1ed>] lock_acquire+0x8d/0x110
       [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
       [<c08bb358>] __mutex_lock_common+0x58/0x470
       [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
       [<c08bb84a>] mutex_lock_nested+0x3a/0x50
       [<facfa598>] ? show_statistics+0x48/0x100 [iwlagn]
       [<facfa598>] show_statistics+0x48/0x100 [iwlagn]
       [<c0580cf9>] ? sysfs_get_active+0x69/0xb0
       [<facfa550>] ? show_statistics+0x0/0x100 [iwlagn]
       [<c070d219>] dev_attr_show+0x29/0x50
       [<c057fecd>] sysfs_read_file+0xdd/0x190
       [<c05ff314>] ? security_file_permission+0x14/0x20
       [<c0528242>] ? rw_verify_area+0x62/0xd0
       [<c052880f>] vfs_read+0x9f/0x190
       [<c047745b>] ? up_read+0x1b/0x30
       [<c057fdf0>] ? sysfs_read_file+0x0/0x190
       [<c04af3b4>] ? audit_syscall_entry+0x1f4/0x220
       [<c0528d22>] sys_read+0x42/0x70
       [<c040ad9f>] sysenter_do_call+0x12/0x38
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      7d47618a
    • W
      iwlwifi: add name to Maintainers list · 9edc71b7
      Wey-Yi Guy 提交于
      Add "Wey-Yi Guy" to maintainers list for iwlwifi.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      9edc71b7
    • A
      iwl3945: fix internal scan · 14023641
      Abhijeet Kolekar 提交于
      Port of internal scan to iwl3945 missed introduction
      of iwl3945_get_single_channel_for_scan.
      
      Fix the following bug by introducing the iwl3945_get_single_channel_for_scan
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2208Signed-off-by: NAbhijeet Kolekar <abhijeet.kolekar@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      14023641
    • R
      iwl3945: enable stuck queue detection on 3945 · a6866ac9
      Reinette Chatre 提交于
      We learn from
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1834 and
      https://bugzilla.redhat.com/show_bug.cgi?id=589777
      that 3945 can also suffer from a stuck command queue. Enable stuck queue
      detection for iwl3945 to enable recovery in this case.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      a6866ac9
  3. 05 6月, 2010 4 次提交
  4. 02 6月, 2010 3 次提交
  5. 29 5月, 2010 5 次提交
  6. 27 5月, 2010 2 次提交
    • C
      ar9170usb: fix read from freed driver context · 50019600
      Christian Lamparter 提交于
      Commit "ar9170: wait for asynchronous firmware loading"
      introduced a bug, which is triggered by fatal errors
      while the driver is initializing the device.
      
      BUG: unable to handle kernel paging request at 6b6b6bf7
      IP: [<c117b567>] kobject_put+0x7/0x70
      *pde = 00000000
      Oops: 0000 [#1] PREEMPT
      last sysfs file: /sys/devices/platform/hdaps/position
      Modules linked in: ar9170usb [...]
      
      Pid: 6246, comm: firmware/ar9170 Not tainted 2.6.34-wl #54
      EIP: 0060:[<c117b567>] EFLAGS: 00010206 CPU: 0
      EIP is at kobject_put+0x7/0x70
      EAX: 6b6b6bd7 EBX: f4d3d0e0 ECX: f5ba9124 EDX: f6af2a7c
      ESI: 00000000 EDI: f4d3d0e0 EBP: 00000000 ESP: f5e98f9c
       DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
      Process firmware/ar9170 (pid: 6246)
      Stack:
       c12532ed 00000246 f5bfaa70 f8487353 f4d3d0e0
      Call Trace:
       [<c12532ed>] ? device_release_driver+0x1d/0x30
       [<f8487353>] ? ar9170_usb_firmware_failed+0x43/0x70 [ar9170usb]
       [<c125983c>] ? request_firmware_work_func+0x2c/0x70
       [<c1259810>] ? request_firmware_work_func+0x0/0x70
       [<c10413f4>] ? kthread+0x74/0x80
       [<c1041380>] ? kthread+0x0/0x80
       [<c1003136>] ? kernel_thread_helper+0x6/0x10
      Code: 40 d3 f2 ff 85 c0 89 c3 74 0a ba 44 86 4c c1 e8 [...]
      EIP: [<c117b567>] kobject_put+0x7/0x70 SS:ESP 0068:f5e98f9c
      CR2: 000000006b6b6bf7
      ---[ end trace e81abb992434b410 ]---
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      50019600
    • J
      Revert "rt2x00: Fix rt2800usb TX descriptor writing." · b578bb49
      John W. Linville 提交于
      This reverts commit 663cb47c.
      
      This patch was merged out of the proper order, so instead of fixing a
      problem with a prior (unmerged) patch, it creates one.  Ooops!
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b578bb49
  7. 25 5月, 2010 14 次提交
  8. 22 5月, 2010 3 次提交