1. 20 7月, 2009 2 次提交
  2. 18 7月, 2009 1 次提交
  3. 17 7月, 2009 8 次提交
  4. 15 7月, 2009 3 次提交
  5. 14 7月, 2009 2 次提交
  6. 13 7月, 2009 3 次提交
    • R
      NET: Fix locking issues in PPP, 6pack, mkiss and strip line disciplines. · adeab1af
      Ralf Baechle 提交于
      Guido Trentalancia reports:
      
      I am trying to use the kiss driver in the Linux kernel that is being
      shipped with Fedora 10 but unfortunately I get the following oops:
      
      mkiss: AX.25 Multikiss, Hans Albas PE1AYX
      mkiss: ax0: crc mode is auto.
      ADDRCONF(NETDEV_CHANGE): ax0: link becomes ready
      ------------[ cut here ]------------
      WARNING: at kernel/softirq.c:77 __local_bh_disable+0x2f/0x83() (Not
      tainted)
      [...]
      unloaded: microcode]
      Pid: 0, comm: swapper Not tainted 2.6.27.25-170.2.72.fc10.i686 #1
       [<c042ddfb>] warn_on_slowpath+0x65/0x8b
       [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38
       [<c04228b4>] ? __enqueue_entity+0xe3/0xeb
       [<c042431e>] ? enqueue_entity+0x203/0x20b
       [<c0424361>] ? enqueue_task_fair+0x3b/0x3f
       [<c041f88c>] ? resched_task+0x3a/0x6e
       [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38
       [<c06ab4e2>] ? _spin_lock_bh+0xb/0x16
       [<c043255b>] __local_bh_disable+0x2f/0x83
       [<c04325ba>] local_bh_disable+0xb/0xd
       [<c06ab4e2>] _spin_lock_bh+0xb/0x16
       [<f8b6f600>] mkiss_receive_buf+0x2fb/0x3a6 [mkiss]
       [<c0572a30>] flush_to_ldisc+0xf7/0x198
       [<c0572b12>] tty_flip_buffer_push+0x41/0x51
       [<f89477f2>] ftdi_process_read+0x375/0x4ad [ftdi_sio]
       [<f8947a5a>] ftdi_read_bulk_callback+0x130/0x138 [ftdi_sio]
       [<c05d4bec>] usb_hcd_giveback_urb+0x63/0x93
       [<c05ea290>] uhci_giveback_urb+0xe5/0x15f
       [<c05eaabf>] uhci_scan_schedule+0x52e/0x767
       [<c05f6288>] ? psmouse_handle_byte+0xc/0xe5
       [<c054df78>] ? acpi_ev_gpe_detect+0xd6/0xe1
       [<c05ec5b0>] uhci_irq+0x110/0x125
       [<c05d4834>] usb_hcd_irq+0x40/0xa3
       [<c0465313>] handle_IRQ_event+0x2f/0x64
       [<c046642b>] handle_level_irq+0x74/0xbe
       [<c04663b7>] ? handle_level_irq+0x0/0xbe
       [<c0406e6e>] do_IRQ+0xc7/0xfe
       [<c0405668>] common_interrupt+0x28/0x30
       [<c056821a>] ? acpi_idle_enter_simple+0x162/0x19d
       [<c0617f52>] cpuidle_idle_call+0x60/0x92
       [<c0403c61>] cpu_idle+0x101/0x134
       [<c069b1ba>] rest_init+0x4e/0x50
       =======================
      ---[ end trace b7cc8076093467ad ]---
      ------------[ cut here ]------------
      WARNING: at kernel/softirq.c:136 _local_bh_enable_ip+0x3d/0xc4()
      [...]
      Pid: 0, comm: swapper Tainted: G        W 2.6.27.25-170.2.72.fc10.i686
       [<c042ddfb>] warn_on_slowpath+0x65/0x8b
       [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38
       [<c04228b4>] ? __enqueue_entity+0xe3/0xeb
       [<c042431e>] ? enqueue_entity+0x203/0x20b
       [<c0424361>] ? enqueue_task_fair+0x3b/0x3f
       [<c041f88c>] ? resched_task+0x3a/0x6e
       [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38
       [<c06ab4e2>] ? _spin_lock_bh+0xb/0x16
       [<f8b6f642>] ? mkiss_receive_buf+0x33d/0x3a6 [mkiss]
       [<c04325f9>] _local_bh_enable_ip+0x3d/0xc4
       [<c0432688>] local_bh_enable_ip+0x8/0xa
       [<c06ab54d>] _spin_unlock_bh+0x11/0x13
       [<f8b6f642>] mkiss_receive_buf+0x33d/0x3a6 [mkiss]
       [<c0572a30>] flush_to_ldisc+0xf7/0x198
       [<c0572b12>] tty_flip_buffer_push+0x41/0x51
       [<f89477f2>] ftdi_process_read+0x375/0x4ad [ftdi_sio]
       [<f8947a5a>] ftdi_read_bulk_callback+0x130/0x138 [ftdi_sio]
       [<c05d4bec>] usb_hcd_giveback_urb+0x63/0x93
       [<c05ea290>] uhci_giveback_urb+0xe5/0x15f
       [<c05eaabf>] uhci_scan_schedule+0x52e/0x767
       [<c05f6288>] ? psmouse_handle_byte+0xc/0xe5
       [<c054df78>] ? acpi_ev_gpe_detect+0xd6/0xe1
       [<c05ec5b0>] uhci_irq+0x110/0x125
       [<c05d4834>] usb_hcd_irq+0x40/0xa3
       [<c0465313>] handle_IRQ_event+0x2f/0x64
       [<c046642b>] handle_level_irq+0x74/0xbe
       [<c04663b7>] ? handle_level_irq+0x0/0xbe
       [<c0406e6e>] do_IRQ+0xc7/0xfe
       [<c0405668>] common_interrupt+0x28/0x30
       [<c056821a>] ? acpi_idle_enter_simple+0x162/0x19d
       [<c0617f52>] cpuidle_idle_call+0x60/0x92
       [<c0403c61>] cpu_idle+0x101/0x134
       [<c069b1ba>] rest_init+0x4e/0x50
       =======================
      ---[ end trace b7cc8076093467ad ]---
      mkiss: ax0: Trying crc-smack
      mkiss: ax0: Trying crc-flexnet
      
      The issue was, that the locking code in mkiss was assuming it was only
      ever being called in process or bh context.  Fixed by converting the
      involved locking code to use irq-safe locks.
      
      Review of other networking line disciplines shows that 6pack, both sync
      and async PPP and STRIP have similar issues.  The ppp_async one is the
      most interesting one as it sorts out half of the issue as far back as
      2004 in commit http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=2996d8deaeddd01820691a872550dc0cfba0c37dSigned-off-by: NRalf Baechle <ralf@linux-mips.org>
      Reported-by: NGuido Trentalancia <guido@trentalancia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      adeab1af
    • B
      netdev: restore MTU change operation · 635ecaa7
      Ben Hutchings 提交于
      alloc_etherdev() used to install a default implementation of this
      operation, but it must now be explicitly installed in struct
      net_device_ops.
      Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      635ecaa7
    • B
      netdev: restore MAC address set and validate operations · 240c102d
      Ben Hutchings 提交于
      alloc_etherdev() used to install default implementations of these
      operations, but they must now be explicitly installed in struct
      net_device_ops.
      Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      240c102d
  7. 10 7月, 2009 2 次提交
    • R
      cxgb3: Fix crash caused by stashing wrong netdev_queue · e594e96e
      Roland Dreier 提交于
      Commit c3a8c5b6 ("cxgb3: move away from LLTX") exposed a bug in how
      cxgb3 looks up the netdev_queue it stashes away in a qset during
      initialization.  For multiport devices, the TX queue index it uses is
      offset by the first_qset index of each port.  This leads to a crash
      once LLTX is removed, since hard_start_xmit is called with one TX
      queue lock held, while the TX reclaim timer task grabs a different
      (wrong) TX queue lock when it frees skbs.
      
      Fix this by removing the first_qset offset used to look up the TX
      queue passed into t3_sge_alloc_qset() from setup_sge_qsets().
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      Acked-by: NDivy Le Ray <divy@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e594e96e
    • Y
      ixgbe: Fix coexistence of FCoE and Flow Director in 82599 · 8faa2a78
      Yi Zou 提交于
      Fix coexistence of Fiber Channel over Ethernet (FCoE) and Flow Director (FDIR)
      in 82599 and remove the disabling of FDIR when FCoE is enabled.
      
      Currently, FDIR is turned off when FCoE is enabled under the assumption that
      FCoE is always enabled with DCB being turned on. However, FDIR does not have
      to be turned off all the time when FCoE is enabled since FCoE can be enabled
      without DCB being turned on, e.g., use link pause only. This patch makes sure
      that when DCB is turned on or off, FDIR is turned on or off correspondingly;
      and when FCoE is enabled, it does not disable FDIR, rather, it will have FDIR
      set up properly so FCoE and FDIR can coexist regardless of DCB being on or off.
      Signed-off-by: NYi Zou <yi.zou@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8faa2a78
  8. 09 7月, 2009 10 次提交
  9. 08 7月, 2009 3 次提交
    • S
      iwmc3200wifi: add Kconfig help · a7a4e41e
      Samuel Ortiz 提交于
      We're missing a Kconfig help for the iwmc3200wifi driver.
      Signed-off-by: NSamuel Ortiz <samuel.ortiz@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a7a4e41e
    • V
      ath9k: Fix leak in tx descriptor · cbfe89c6
      Vasanthakumar Thiagarajan 提交于
      When we reclaim the tx desc, we always assume that the
      last desc is a holding desc, which is not true, and skip it.
      If the tx queue is drained during channel change, internal
      reset and etc, the last descriptor may not be the holding
      descriptor and we fail to reclaim them. This results in the
      following two issues.
      
      1. Tx stuck - We drop all the frames coming from upper layer
      due to shortage in tx desc.
      
      2. Crash - If we fail to reclaim a tx descriptor, we miss to
      update the tx BA window with the seq number of the frame
      associated to that desc, which, at some point, result in
      the following crash due to an assert failure in ath_tx_addto_baw().
      
      This patch fixes these two issues.
      
       kernel BUG at ../drivers/net/wireless/ath/ath9k/xmit.c:180!
      [155064.304164] invalid opcode: 0000 [#1] SMP
       Call Trace:
        [<fbc6d83b>] ? ath9k_tx+0xeb/0x160 [ath9k]
        [<fbbc9591>]  ipv6? __ieee80211_tx+0x41/0x120 [mac80211]
        [<fbbcb5ae>] ?  aes_i586ieee80211_master_start_xmit+0x28e/0x560 [mac80211]
        [<c037e501>]  aes_generic? _spin_lock_irqsave+0x31/0x40
        [<c02f347b>] ? dev_hard_start_xmit+0x16b/0x1c0
        [<c03058b5>] ? __qdisc_run+0x1b5/0x200
        [<fbbcda5a>] ?  af_packetieee80211_select_queue+0xa/0x100 [mac80211]
        [<c02f53b7>] ?  i915dev_queue_xmit+0x2e7/0x3f0
        [<fbbc9b49>] ? ieee80211_subif_start_xmit+0x369/0x7a0 [mac80211]
        [<c031bc35>] ? ip_output+0x55/0xb0
        [<c02e0188>] ? show_memcpy_count+0x18/0x60
        [<c02eb186>] ? __kfree_skb+0x36/0x90
        [<c02f2202>] ?  binfmt_miscdev_queue_xmit_nit+0xd2/0x110
        [<c02f347b>] ? dev_hard_start_xmit+0x16b/0x1c0
        [<c03058b5>] ? __qdisc_run+0x1b5/0x200
        [<c033bca7>] ?  scoarp_create+0x57/0x2a0
        [<c02f53b7>] ?  bridgedev_queue_xmit+0x2e7/0x3f0
        [<c03034a0>] ? eth_header+0x0/0xc0
        [<c033b95f>]  stp? arp_xmit+0x5f/0x70
        [<c033bf4f>] ? arp_send+0x5f/0x70
        [<c033c8f5>]  bnep? arp_solicit+0x105/0x210
        [<c02fa5aa>] ? neigh_timer_handler+0x19a/0x390
        [<c013bf88>] ? run_timer_softirq+0x138/0x210
        [<c02fa410>] ?  ppdevneigh_timer_handler+0x0/0x390
        [<c02fa410>] ? neigh_timer_handler+0x0/0x390
      Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cbfe89c6
    • L
      b43/b43legacy: fix radio LED initialization · fd4973c5
      Larry Finger 提交于
      Fix condition in which radio LED did not initialize correctly, and remove
      4 compilation warnings.
      
      After the recent changes in rfkill, the radio LED used by b43/b43legacy
      did not always initialize correctly.
      
      Both b43 and b43legacy used the deprecated variable radio_enabled in
      struct ieee80211_conf.
      Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fd4973c5
  10. 07 7月, 2009 4 次提交
  11. 06 7月, 2009 2 次提交
    • E
      forcedeth: Fix NAPI race. · 78c29bd9
      Eric Dumazet 提交于
      Eric Dumazet a écrit :
      > Ingo Molnar a écrit :
      >>> The following changes since commit 52989765:
      >>>   Linus Torvalds (1):
      >>>         Merge git://git.kernel.org/.../davem/net-2.6
      
      > >>> are available in the git repository at:
      
      >>>   master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
      >> Hm, something in this lot quickly wrecked networking here - see the
      >> tx timeout dump below. It starts with:
      >>
      >> [  351.004596] WARNING: at net/sched/sch_generic.c:246 dev_watchdog+0x10b/0x19c()
      >> [  351.011815] Hardware name: System Product Name
      >> [  351.016220] NETDEV WATCHDOG: eth0 (forcedeth): transmit queue 0 timed out
      >>
      >> Config attached. Unfortunately i've got no time to do bisection
      >> today.
      >
      >
      >
      > forcedeth might have a problem, in its netif_wake_queue() logic, but
      > I could not see why a recent patch could make this problem visible now.
      >
      > CPU0/1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
      > is not a new cpu either :)
      >
      > forcedeth uses an internal tx_stop without appropriate barrier.
      >
      > Could you try following patch ?
      >
      > (random guess as I dont have much time right now)
      
      We might have a race in napi_schedule(), leaving interrupts disabled forever.
      I cannot test this patch, I dont have the hardware...
      Tested-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      78c29bd9
    • J
      drivers/net/smsc911x.c: Fix resource size off by 1 error · 39424539
      Julia Lawall 提交于
      The call resource_size(res) returns res->end - res->start + 1 and thus the
      second change is semantics-preserving.  res_size is then used as the second
      argument of a call to request_mem_region, and the memory allocated by this
      call appears to be the same as what is released in the two calls to
      release_mem_region.  So the size argument for those calls should be
      resource_size(size) as well.  Alternatively, in the second call to
      release_mem_region, the second argument could be res_size, as that variable
      has already been initialized at the point of this call.
      
      The problem was found using the following semantic patch:
      (http://www.emn.fr/x-info/coccinelle/)
      
      // <smpl>
      @@
      struct resource *res;
      @@
      
      - (res->end - res->start) + 1
      + resource_size(res)
      
      @@
      struct resource *res;
      @@
      
      - res->end - res->start
      + BAD(resource_size(res))
      // </smpl>
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      39424539