1. 23 Feb, 2009 3 commits
    • Larry Finger's avatar
      rtl8187: New USB ID's for RTL8187L · 046ee5d2
      Larry Finger authored
      Add new USB ID codes. These come from two postings on forums and
      mailing lists, and four are derived from the .inf that accompanies
      the latest Realtek Windows driver for the RTL8187L.
      
      Thanks to Viktor Ilijašić <viktor.ilijasic@gmail.com> and Xose Vazquez
      Perez <xose.vazquez@gmail.com> for reporting these new ID's.
      Signed-off-by: default avatarLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      046ee5d2
    • Vasanthakumar Thiagarajan's avatar
      ath9k: Fix panic upon attach failure · 40b130a9
      Vasanthakumar Thiagarajan authored
      [246916.338046]
      [246916.338048] Pid: 29265, comm: insmod Not tainted (2.6.29-rc4-wl #64) 9461DUU
      [246916.338051] EIP: 0060:[<c02ca274>] EFLAGS: 00010202 CPU: 0
      [246916.338055] EIP is at rollback_registered+0x24/0x220
      [246916.338057] EAX: 00000001 EBX: 00000000 ECX: 00000000 EDX: f122e8fc
      [246916.338059] ESI: 00000000 EDI: 00000000 EBP: f6595d30 ESP: f6595d1c
      [246916.338062]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      [246916.338064] Process insmod (pid: 29265, ti=f6594000 task=f7343fe0 task.ti=f6594000)
      [246916.338067] Stack:
      [246916.338068]  c04a2920 22222222 f6595d48 00000000 f122f080 f6595d48 c02ca489 f122e8fc
      [246916.338076]  f122e220 f122f080 f122e220 f6595d5c f8a03156 f122e220 f122f080 f122e220
      [246916.338085]  f6595d80 f87359af f122f080 00002000 f874e129 f122f150 f122f080 f6290000
      [246916.338094] Call Trace:
      [246916.338096]  [<c02ca489>] ? unregister_netdevice+0x19/0x70
      [246916.338100]  [<f8a03156>] ? ieee80211_unregister_hw+0x36/0xd0 [mac80211]
      [246916.338112]  [<f87359af>] ? ath_detach+0xcf/0x250 [ath9k]
      [246916.338127]  [<f8735d9c>] ? ath_attach+0x26c/0x740 [ath9k]
      [246916.338139]  [<f873c33a>] ? ath_pci_probe+0x13a/0x310 [ath9k]
      [246916.338151]  [<c0233e28>] ? _raw_spin_unlock+0x68/0x80
      [246916.338158]  [<c023ab8e>] ? local_pci_probe+0xe/0x10
      [246916.338162]  [<c023b8e0>] ? pci_device_probe+0x60/0x80
      [246916.338169]  [<c029e042>] ? driver_probe_device+0x82/0x1b0
      [246916.338174]  [<c029e1f9>] ? __driver_attach+0x89/0x90
      [246916.338180]  [<c029d97b>] ? bus_for_each_dev+0x4b/0x70
      [246916.338184]  [<c023b820>] ? pci_device_remove+0x0/0x40
      [246916.338190]  [<c029ded9>] ? driver_attach+0x19/0x20
      [246916.338193]  [<c029e170>] ? __driver_attach+0x0/0x90
      [246916.338197]  [<c029d317>] ? bus_add_driver+0x1b7/0x230
      [246916.338203]  [<c023b820>] ? pci_device_remove+0x0/0x40
      [246916.338206]  [<c029e399>] ? driver_register+0x69/0x140
      [246916.338212]  [<f859d000>] ? ath9k_init+0x0/0x54 [ath9k]
      [246916.338221]  [<c023bb4e>] ? __pci_register_driver+0x4e/0x90
      [246916.338225]  [<f859d000>] ? ath9k_init+0x0/0x54 [ath9k]
      [246916.338232]  [<f859d06b>] ? ath_pci_init+0x17/0x19 [ath9k]
      [246916.338238]  [<f859d017>] ? ath9k_init+0x17/0x54 [ath9k]
      [246916.338245]  [<c017148e>] ? tracepoint_update_probe_range+0x7e/0xb0
      [246916.338249]  [<c010111a>] ? do_one_initcall+0x2a/0x170
      [246916.338252]  [<c0149f26>] ? up_read+0x16/0x30
      [246916.338256]  [<c014aa9d>] ? __blocking_notifier_call_chain+0x4d/0x60
      [246916.338265]  [<c0162b1a>] ? sys_init_module+0x8a/0x1c0
      [246916.338269]  [<c022f888>] ? trace_hardirqs_on_thunk+0xc/0x10
      [246916.338272]  [<c0103ebf>] ? sysenter_do_call+0x12/0x43
      [246916.338276] Code: 8d bc 27 00 00 00 00 55 89 e5 56 89 c6 53 83 ec 0c a1 74 27 4a c0 85 c0 0f 85 4b 01 00 00 e8 04 7d 00 00 85 c0 0f 84 c9 01 00 00 <8b> 86 18 03 00 00 85 c0 0f 84 86 01 00 00 83 e8 01 0f 85 71 01
      [246916.338328] EIP: [<c02ca274>] rollback_registered+0x24/0x220 SS:ESP 0068:f6595d1c
      [246916.338335] ---[ end trace 76357c56a75ea34e ]---
      Signed-off-by: default avatarVasanthakumar Thiagarajan <vasanth@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      40b130a9
    • Andrey Borzenkov's avatar
      orinoco: do not resgister NULL pm_notifier function · 5c138dce
      Andrey Borzenkov authored
      With DEBUG_NOTIFIERS it results in
      
      [11330.890966] WARNING: at /home/bor/src/linux-git/kernel/notifier.c:88
      notifier_call_chain+0x91/0xa0()
      [11330.890977] Hardware name: PORTEGE 4000
      [11330.890983] Invalid notifier called! ...
      
      Without DEBUG_NOTIFIERS it most likely crashes on NULL pointer.
      Signed-off-by: default avatarAndrey Borzenkov <arvidjaar@mail.ru>
      Acked-by: default avatarDavid Kilroy <kilroyd@googlemail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5c138dce
  2. 22 Feb, 2009 3 commits
  3. 20 Feb, 2009 7 commits
  4. 19 Feb, 2009 8 commits
  5. 18 Feb, 2009 1 commit
    • David S. Miller's avatar
      net: Kill skb_truesize_check(), it only catches false-positives. · 92a0acce
      David S. Miller authored
      A long time ago we had bugs, primarily in TCP, where we would modify
      skb->truesize (for TSO queue collapsing) in ways which would corrupt
      the socket memory accounting.
      
      skb_truesize_check() was added in order to try and catch this error
      more systematically.
      
      However this debugging check has morphed into a Frankenstein of sorts
      and these days it does nothing other than catch false-positives.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      92a0acce
  6. 16 Feb, 2009 1 commit
    • Tobias Diedrich's avatar
      net: forcedeth: Fix wake-on-lan regression · 34edaa88
      Tobias Diedrich authored
      Commit f55c21fd ("forcedeth: call
      restore mac addr in nv_shutdown path"), which was introduced to fix
      the regression tracked at
      http://bugzilla.kernel.org/show_bug.cgi?id=11358 causes the
      wake-on-lan mac to be reversed in the shutdown path.  Apparently the
      forcedeth situation is rather messy in that the mac we need to
      writeback for a subsequent modprobe to work is exactly the reverse of
      what is needed for proper wake-on-lan.
      
      The following patch explains the situation in the comments and
      makes the call to nv_restore_mac_addr() conditional (only called if
      we are not really going for poweroff).
      
      Tobias Diedrich wrote:
      > Hmm, I had not tried WOL for some time.
      > With 2.6.29-rc3 is see the following behaviour:
      > 
      > State            WOL Behaviour
      > ------------------------------
      > shutdown         reversed MAC
      > disk/shutdown    reversed MAC
      > disk/platform    OK
      > 
      > Apparently nv_restore_mac_addr() restores the MAC in the wrong order
      > for WOL (at least for my PCI_DEVICE_ID_NVIDIA_NVENET_15).  platform
      > works, because the MAC is not touched in the nv_suspend() path.
      > 
      > A possible fix might be to only call nv_restore_mac_addr() if
      > system_state != SYSTEM_POWER_OFF.
      
      With the following patch:
      shutdown         OK
      disk/shutdown    OK
      disk/platform    OK
      kexec            OK
      Signed-off-by: default avatarTobias Diedrich <ranma+kernel@tdiedrich.de>
      Tested-by: default avatarPhilipp Matthias Hahn <pmhahn@titan.lahn.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      34edaa88
  7. 13 Feb, 2009 17 commits