1. 11 7月, 2009 1 次提交
  2. 17 3月, 2009 1 次提交
  3. 14 2月, 2009 6 次提交
  4. 12 2月, 2009 8 次提交
  5. 10 2月, 2009 1 次提交
  6. 30 1月, 2009 4 次提交
  7. 23 1月, 2009 2 次提交
    • P
      orinoco: use KERN_DEBUG for link status messages · 11eaea41
      Pavel Roskin 提交于
      KERN_INFO is too "loud" for messages that are generated by the ordinary
      events, such as accociation.  Use of KERN_DEBUG is consistent with
      mac80211.
      
      Suggested by Michael Gilbert <michael.s.gilbert@gmail.com>
      Signed-off-by: NPavel Roskin <proski@gnu.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      11eaea41
    • A
      orinoco: move kmalloc(..., GFP_KERNEL) outside spinlock in orinoco_ioctl_set_genie · 7fe99c4e
      Andrey Borzenkov 提交于
      [   56.923623] BUG: sleeping function called from invalid context at /home/bor/src/linux-git/mm/slub.c:1599
      [   56.923644] in_atomic(): 0, irqs_disabled(): 1, pid: 3031, name: wpa_supplicant
      [   56.923656] 2 locks held by wpa_supplicant/3031:
      [   56.923662]  #0:  (rtnl_mutex){--..}, at: [<c02abd1f>] rtnl_lock+0xf/0x20
      [   56.923703]  #1:  (&priv->lock){++..}, at: [<dfc840c2>] orinoco_ioctl_set_genie+0x52/0x130 [orinoco]
      [   56.923782] irq event stamp: 910
      [   56.923788] hardirqs last  enabled at (909): [<c01957db>] __kmalloc+0x7b/0x140
      [   56.923820] hardirqs last disabled at (910): [<c0309419>] _spin_lock_irqsave+0x19/0x80
      [   56.923847] softirqs last  enabled at (880): [<c0124f54>] __do_softirq+0xc4/0x110
      [   56.923865] softirqs last disabled at (871): [<c01049ae>] do_softirq+0x8e/0xe0
      [   56.923895] Pid: 3031, comm: wpa_supplicant Not tainted 2.6.29-rc2-1avb #1
      [   56.923905] Call Trace:
      [   56.923919]  [<c01049ae>] ? do_softirq+0x8e/0xe0
      [   56.923941]  [<c011ad12>] __might_sleep+0xd2/0x100
      [   56.923952]  [<c0195837>] __kmalloc+0xd7/0x140
      [   56.923963]  [<c030946a>] ? _spin_lock_irqsave+0x6a/0x80
      [   56.923981]  [<dfc840e9>] ? orinoco_ioctl_set_genie+0x79/0x130 [orinoco]
      [   56.923999]  [<dfc840c2>] ? orinoco_ioctl_set_genie+0x52/0x130 [orinoco]
      [   56.924017]  [<dfc840e9>] orinoco_ioctl_set_genie+0x79/0x130 [orinoco]
      [   56.924036]  [<c0209325>] ? copy_from_user+0x35/0x130
      [   56.924061]  [<c02ffd96>] ioctl_standard_call+0x196/0x380
      [   56.924085]  [<c029f945>] ? __dev_get_by_name+0x85/0xb0
      [   56.924096]  [<c02ff88f>] wext_handle_ioctl+0x14f/0x230
      [   56.924113]  [<dfc84070>] ? orinoco_ioctl_set_genie+0x0/0x130 [orinoco]
      [   56.924132]  [<c02a3da5>] dev_ioctl+0x495/0x570
      [   56.924155]  [<c0293e05>] ? sys_sendto+0xa5/0xd0
      [   56.924171]  [<c0142fe8>] ? mark_held_locks+0x48/0x90
      [   56.924183]  [<c0292880>] ? sock_ioctl+0x0/0x280
      [   56.924193]  [<c029297d>] sock_ioctl+0xfd/0x280
      [   56.924203]  [<c0292880>] ? sock_ioctl+0x0/0x280
      [   56.924235]  [<c01a51d0>] vfs_ioctl+0x20/0x80
      [   56.924246]  [<c01a53e2>] do_vfs_ioctl+0x72/0x570
      [   56.924257]  [<c0293e62>] ? sys_send+0x32/0x40
      [   56.924268]  [<c02947c0>] ? sys_socketcall+0x1d0/0x2a0
      [   56.924280]  [<c010339f>] ? sysenter_exit+0xf/0x16
      [   56.924292]  [<c01a5919>] sys_ioctl+0x39/0x70
      [   56.924302]  [<c0103371>] sysenter_do_call+0x12/0x31
      Signed-off-by: NAndrey Borzenkov <arvidjaar@mail.ru>
      Cc: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7fe99c4e
  8. 13 1月, 2009 1 次提交
    • D
      orinoco: take the driver lock in the rx tasklet · 20953ad6
      David Kilroy 提交于
      Fix the warning reproduced below.
      
      We add to rx_list in interrupt context and remove elements in tasklet
      context. While removing elements we need to prevent the interrupt
      modifying the list.
      
      Note that "orinoco: Process bulk of receive interrupt in a tasklet" did not
      preserve locking semantics on what is now orinoco_rx.
      
      This patch reinstates the locking semantics and ensures it covers
      rx_list as well. This leads to additional cleanup required in
      free_orinocodev.
      
      [89479.105038] WARNING: at lib/list_debug.c:30 __list_add+0x8f/0xa0()
      [89479.105058] list_add corruption. prev->next should be next (dddb3568), but was cbc28978. (prev=dddb3568).
      [89479.106002] Pid: 15746, comm: X Not tainted 2.6.28-1avb #26
      [89479.106020] Call Trace:
      [89479.106062]  [<c011d3b0>] warn_slowpath+0x60/0x80
      [89479.106104]  [<c01073d0>] ? native_sched_clock+0x20/0x70
      [89479.106194]  [<c013d825>] ? lock_release_holdtime+0x35/0x200
      [89479.106218]  [<c018d9f0>] ? __slab_alloc+0x550/0x560
      [89479.106254]  [<c02f9c9d>] ? _spin_unlock+0x1d/0x20
      [89479.106270]  [<c018d9f0>] ? __slab_alloc+0x550/0x560
      [89479.106302]  [<c01ff2a7>] ? delay_tsc+0x17/0x24
      [89479.106319]  [<c01ff221>] ? __const_udelay+0x21/0x30
      [89479.106376]  [<dfa8b1e2>] ? hermes_bap_seek+0x112/0x1e0 [hermes]
      [89479.106396]  [<c013d7eb>] ? trace_hardirqs_off+0xb/0x10
      [89479.106418]  [<c018e307>] ? __kmalloc_track_caller+0xb7/0x110
      [89479.106448]  [<c028eefc>] ? dev_alloc_skb+0x1c/0x30
      [89479.106465]  [<c028eefc>] ? dev_alloc_skb+0x1c/0x30
      [89479.106482]  [<c020e13f>] __list_add+0x8f/0xa0
      [89479.106551]  [<dfd0fcae>] orinoco_interrupt+0xcae/0x16c0 [orinoco]
      [89479.106574]  [<c013b0e3>] ? tick_dev_program_event+0x33/0xb0
      [89479.106594]  [<c01073d0>] ? native_sched_clock+0x20/0x70
      [89479.106613]  [<c013d825>] ? lock_release_holdtime+0x35/0x200
      [89479.106662]  [<c013d7eb>] ? trace_hardirqs_off+0xb/0x10
      [89479.106892]  [<dfe7faa7>] ? usb_hcd_irq+0x97/0xa0 [usbcore]
      [89479.106926]  [<c015ba79>] handle_IRQ_event+0x29/0x60
      [89479.106947]  [<c015cf89>] handle_level_irq+0x69/0xe0
      [89479.106963]  [<c015cf20>] ? handle_level_irq+0x0/0xe0
      [89479.106977]  <IRQ>  [<c02ca933>] ? tcp_v4_rcv+0x633/0x6e0
      [89479.107025]  [<c0103f0c>] ? common_interrupt+0x28/0x30
      [89479.107057]  [<c02a0000>] ? sk_run_filter+0x320/0x7a0
      [89479.107078]  [<c020e041>] ? list_del+0x21/0x90
      [89479.107106]  [<dfd0d24e>] ? orinoco_rx_isr_tasklet+0x2ce/0x480 [orinoco]
      [89479.107131]  [<c01402e0>] ? __lock_acquire+0x160/0x1650
      [89479.107151]  [<c01073d0>] ? native_sched_clock+0x20/0x70
      [89479.107169]  [<c013d825>] ? lock_release_holdtime+0x35/0x200
      [89479.107200]  [<c012249a>] ? irq_enter+0xa/0x60
      [89479.107217]  [<c0104e52>] ? do_IRQ+0xd2/0x130
      [89479.107518]  [<c010342c>] ? restore_nocheck_notrace+0x0/0xe
      [89479.107542]  [<c0122830>] ? __do_softirq+0x0/0x110
      [89479.107561]  [<c013f7b4>] ? trace_hardirqs_on_caller+0x74/0x140
      [89479.107583]  [<c01ff678>] ? trace_hardirqs_on_thunk+0xc/0x10
      [89479.107602]  [<c0122087>] ? tasklet_action+0x27/0x90
      [89479.107620]  [<c013f7b4>] ? trace_hardirqs_on_caller+0x74/0x140
      [89479.107638]  [<c01220a3>] ? tasklet_action+0x43/0x90
      [89479.107655]  [<c012289f>] ? __do_softirq+0x6f/0x110
      [89479.107674]  [<c0122830>] ? __do_softirq+0x0/0x110
      [89479.107685]  <IRQ>  [<c015cf20>] ? handle_level_irq+0x0/0xe0
      [89479.107715]  [<c012246d>] ? irq_exit+0x5d/0x80
      [89479.107732]  [<c0104e52>] ? do_IRQ+0xd2/0x130
      [89479.107747]  [<c0103337>] ? sysenter_exit+0xf/0x16
      [89479.107765]  [<c013f83d>] ? trace_hardirqs_on_caller+0xfd/0x140
      [89479.107782]  [<c0103f0c>] ? common_interrupt+0x28/0x30
      [89479.107797] ---[ end trace a1fc0a52df4a729d ]---
      Reported-by: NAndrey Borzenkov <arvidjaar@mail.ru>
      Signed-off-by: NDavid Kilroy <kilroyd@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      20953ad6
  9. 13 12月, 2008 1 次提交
  10. 26 11月, 2008 4 次提交
  11. 22 11月, 2008 1 次提交
  12. 11 11月, 2008 3 次提交
  13. 04 11月, 2008 1 次提交
  14. 01 11月, 2008 2 次提交
  15. 28 10月, 2008 1 次提交
  16. 23 10月, 2008 1 次提交
  17. 25 9月, 2008 1 次提交
    • D
      wireless: Read scan flags correctly on x86-64 · 9930ccee
      David Kilroy 提交于
      The SIOCSIWSCAN handler is passed data in an iw_point structure. Some
      drivers erronously use an iw_param instead.
      
      On 32 bit architectures the difference isn't noticed as the flags
      parameter tends to be the only one used by scan handlers and is at the
      same offset.
      
      On 64 bit architectures the pointer in the iw_point structure means the
      flag parameter is at different offsets in these structures.
      
      Thanks to Jean Tourrilhes for tracking this down for orinoco, and Pavel
      Roskin for confirming the fix and identifying other suspect handlers.
      Signed-off-by: NDavid Kilroy <kilroyd@googlemail.com>
      Acked-by: NPavel Roskin <proski@gnu.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9930ccee
  18. 16 9月, 2008 1 次提交