1. 01 7月, 2010 2 次提交
  2. 30 6月, 2010 3 次提交
  3. 29 6月, 2010 3 次提交
  4. 27 6月, 2010 3 次提交
  5. 26 6月, 2010 10 次提交
  6. 25 6月, 2010 2 次提交
  7. 24 6月, 2010 5 次提交
  8. 23 6月, 2010 2 次提交
  9. 22 6月, 2010 3 次提交
  10. 19 6月, 2010 1 次提交
    • B
      ath5k: initialize ah->ah_current_channel · b6855772
      Bob Copeland 提交于
      ath5k assumes ah_current_channel is always a valid pointer in
      several places, but a newly created interface may not have a
      channel.  To avoid null pointer dereferences, set it up to point
      to the first available channel until later reconfigured.
      
      This fixes the following oops:
      $ rmmod ath5k
      $ insmod ath5k
      $ iw phy0 set distance 11000
      
      BUG: unable to handle kernel NULL pointer dereference at 00000006
      IP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
      *pde = 00000000
      Oops: 0000 [#1]
      last sysfs file: /sys/devices/pci0000:00/0000:00:0e.0/ieee80211/phy0/index
      Modules linked in: usbhid option usb_storage usbserial usblp evdev lm90
      scx200_acb i2c_algo_bit i2c_dev i2c_core via_rhine ohci_hcd ne2k_pci
      8390 leds_alix2 xt_IMQ imq nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_cc
      
      Pid: 1597, comm: iw Not tainted (2.6.32.14 #8)
      EIP: 0060:[<d0a1ff24>] EFLAGS: 00010296 CPU: 0
      EIP is at ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
      EAX: 000000c2 EBX: 00000000 ECX: ffffffff EDX: c12d2080
      ESI: 00000019 EDI: cf8c0000 EBP: d0a30edc ESP: cfa09bf4
        DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
      Process iw (pid: 1597, ti=cfa09000 task=cf88a000 task.ti=cfa09000)
      Stack:
        d0a34f35 d0a353f8 d0a30edc 000000fe cf8c0000 00000000 1900063d cfa8c9e0
      <0> cfa8c9e8 cfa8c0c0 cfa8c000 d0a27f0c 199d84b4 cfa8c200 00000010 d09bfdc7
      <0> 00000000 00000000 ffffffff d08e0d28 cf9263c0 00000001 cfa09cc4 00000000
      Call Trace:
        [<d0a27f0c>] ? ath5k_hw_attach+0xc8c/0x3c10 [ath5k]
        [<d09bfdc7>] ? __ieee80211_request_smps+0x1347/0x1580 [mac80211]
        [<d08e0d28>] ? nl80211_send_scan_start+0x7b8/0x4520 [cfg80211]
        [<c10f5db9>] ? nla_parse+0x59/0xc0
        [<c11ca8d9>] ? genl_rcv_msg+0x169/0x1a0
        [<c11ca770>] ? genl_rcv_msg+0x0/0x1a0
        [<c11c7e68>] ? netlink_rcv_skb+0x38/0x90
        [<c11c9649>] ? genl_rcv+0x19/0x30
        [<c11c7c03>] ? netlink_unicast+0x1b3/0x220
        [<c11c893e>] ? netlink_sendmsg+0x26e/0x290
        [<c11a409e>] ? sock_sendmsg+0xbe/0xf0
        [<c1032780>] ? autoremove_wake_function+0x0/0x50
        [<c104d846>] ? __alloc_pages_nodemask+0x106/0x530
        [<c1074933>] ? do_lookup+0x53/0x1b0
        [<c10766f9>] ? __link_path_walk+0x9b9/0x9e0
        [<c11acab0>] ? verify_iovec+0x50/0x90
        [<c11a42b1>] ? sys_sendmsg+0x1e1/0x270
        [<c1048e50>] ? find_get_page+0x10/0x50
        [<c104a96f>] ? filemap_fault+0x5f/0x370
        [<c1059159>] ? __do_fault+0x319/0x370
        [<c11a55b4>] ? sys_socketcall+0x244/0x290
        [<c101962c>] ? do_page_fault+0x1ec/0x270
        [<c1019440>] ? do_page_fault+0x0/0x270
        [<c1002ae5>] ? syscall_call+0x7/0xb
      Code: 00 b8 fe 00 00 00 b9 f8 53 a3 d0 89 5c 24 14 89 7c 24 10 89 44 24
      0c 89 6c 24 08 89 4c 24 04 c7 04 24 35 4f a3 d0 e8 7c 30 60 f0 <0f> b7
      43 06 ba 06 00 00 00 a8 10 75 0e 83 e0 20 83 f8 01 19 d2
      EIP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] SS:ESP
      0068:cfa09bf4
      CR2: 0000000000000006
      ---[ end trace 54f73d6b10ceb87b ]---
      
      Cc: stable@kernel.org
      Reported-by: NSteve Brown <sbrown@cortland.com>
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b6855772
  11. 18 6月, 2010 1 次提交
  12. 17 6月, 2010 5 次提交
    • F
      bnx2: fix dma_get_ops compilation breakage · aabef8b2
      FUJITA Tomonori 提交于
      This removes dma_get_ops() prefetch optimization in bnx2.
      
      bnx2 uses dma_get_ops() to see if dma_sync_single_for_cpu() is
      noop. bnx2 does prefetch if it's noop.
      
      But dma_get_ops() isn't available on all the architectures (only the
      architectures that uses dma_map_ops struct have it). Using
      dma_get_ops() in drivers leads to compilation breakage on many
      architectures.
      
      This patch removes dma_get_ops() and changes bnx2 to do prefetch on
      all the architectures. This adds useless prefetch on non-coherent
      architectures but this is harmless. It is also unlikely to cause the
      performance drop.
      
      [ Remove now unused local variable 'pdev' -DaveM ]
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Acked-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aabef8b2
    • S
      ucc_geth: fix for RX skb buffers recycling · db176edc
      Sergey Matyukevich 提交于
      This patch implements a proper modification of RX skb buffers before
      recycling. Adjusting only skb->data is not enough because after that
      skb->tail and skb->len become incorrect.
      Signed-off-by: NSergey Matyukevich <geomatsi@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      db176edc
    • K
      pcnet_cs: add new id (TOSHIBA Modem/LAN Card) · 8b1d920f
      Ken Kawasaki 提交于
      pcnet_cs:
      serial_cs:
          add new id (TOSHIBA Modem/LAN Card)
      Signed-off-by: NKen Kawasaki <ken_kawasaki@spring.nifty.jp>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b1d920f
    • A
      gianfar: Fix oversized packets handling · 63b88b90
      Anton Vorontsov 提交于
      Issuing the following command on host:
      
      $ ifconfig eth2 mtu 1600 ; ping 10.0.0.27 -s 1485 -c 1
      
      Makes some boards (tested with MPC8315 rev 1.1 and MPC8313 rev 1.0)
      oops like this:
      
        skb_over_panic: text:c0195914 len:1537 put:1537 head:c79e4800 data:c79e4880 tail:0xc79e4e81 end:0xc79e4e80 dev:eth1
        ------------[ cut here ]------------
        kernel BUG at net/core/skbuff.c:127!
        Oops: Exception in kernel mode, sig: 5 [#1]
        MPC831x RDB
        last sysfs file: /sys/kernel/uevent_seqnum
        Modules linked in:
        NIP: c01c1840 LR: c01c1840 CTR: c016d918
        [...]
        NIP [c01c1840] skb_over_panic+0x48/0x5c
        LR [c01c1840] skb_over_panic+0x48/0x5c
        Call Trace:
        [c0339d50] [c01c1840] skb_over_panic+0x48/0x5c (unreliable)
        [c0339d60] [c01c3020] skb_put+0x5c/0x60
        [c0339d70] [c0195914] gfar_clean_rx_ring+0x25c/0x3d0
        [c0339dc0] [c01976e8] gfar_poll+0x170/0x1bc
      
      Dumped buffer descriptors showed that eTSEC's length/truncation
      logic sometimes passes oversized packets, i.e. for the above ICMP
      packet the following two buffer descriptors may become ready:
      
        status=1400 length=1536
        status=1800 length=1541
      
      So, it seems that gianfar actually receives the whole big frame,
      and it tries to place the packet into two BDs. This situation
      confuses the driver, and so the skb_put() sanity check fails.
      
      This patch fixes the issue by adding an appropriate check, i.e.
      the driver should not try to process frames with buffer
      descriptor's length over rx_buffer_size (i.e. maxfrm and mrblr).
      
      Note that sometimes eTSEC works correctly, i.e. in the second
      (last) buffer descriptor bits 'truncated' and 'crcerr' are set,
      and so there's no oops. Though I couldn't find any logic when
      it works correctly and when not.
      Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      63b88b90
    • J
      ehea: Fix kernel deadlock in DLPAR-mem processing · 099473c1
      Jan-Bernd Themann 提交于
      Port reset operations and memory add/remove operations need to
      be serialized to avoid a kernel deadlock. The deadlock is caused
      by calling the napi_disable() function twice.
      Therefore we have to employ the dlpar_mem_lock in the ehea_reset_port
      function as well
      Signed-off-by: NJan-Bernd Themann <themann@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      099473c1