1. 24 2月, 2009 2 次提交
    • V
      ath9k: Fix panic upon attach failure · 40b130a9
      Vasanthakumar Thiagarajan 提交于
      [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: NVasanthakumar Thiagarajan <vasanth@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      40b130a9
    • A
      orinoco: do not resgister NULL pm_notifier function · 5c138dce
      Andrey Borzenkov 提交于
      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: NAndrey Borzenkov <arvidjaar@mail.ru>
      Acked-by: NDavid Kilroy <kilroyd@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5c138dce
  2. 22 2月, 2009 3 次提交
  3. 20 2月, 2009 7 次提交
  4. 19 2月, 2009 8 次提交
  5. 18 2月, 2009 1 次提交
    • D
      net: Kill skb_truesize_check(), it only catches false-positives. · 92a0acce
      David S. Miller 提交于
      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: NDavid S. Miller <davem@davemloft.net>
      92a0acce
  6. 16 2月, 2009 1 次提交
    • T
      net: forcedeth: Fix wake-on-lan regression · 34edaa88
      Tobias Diedrich 提交于
      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: NTobias Diedrich <ranma+kernel@tdiedrich.de>
      Tested-by: NPhilipp Matthias Hahn <pmhahn@titan.lahn.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      34edaa88
  7. 13 2月, 2009 18 次提交