1. 05 1月, 2012 2 次提交
  2. 10 12月, 2011 1 次提交
  3. 06 12月, 2011 4 次提交
    • B
      pasemi_mac: Fix building as module · 65e9d805
      Ben Hutchings 提交于
      Commit ded19add ('pasemic_mac*: Move
      the PA Semi driver') inadvertently split pasemi_mac into two separate
      modules with unresolved symbols.  Change it back into a single module.
      Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      65e9d805
    • W
      netback: Fix alert message. · 6b84bd16
      Wei Liu 提交于
      The original message in netback_init was 'kthread_run() fails', which should be
      'kthread_create() fails'.
      Signed-off-by: NWei Liu <wei.liu2@citrix.com>
      Acked-by: NIan Campbell <ian.campbell@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6b84bd16
    • F
      r8169: fix Rx index race between FIFO overflow recovery and NAPI handler. · c7c2c39b
      françois romieu 提交于
      Since 92fc43b4, rtl8169_tx_timeout ends up
      resetting Rx and Tx indexes and thus racing with the NAPI handler via
      -> rtl8169_hw_reset
         -> rtl_hw_reset
            -> rtl8169_init_ring_indexes
      
      What about returning to the original state ?
      
      rtl_hw_reset is only used by rtl8169_hw_reset and rtl8169_init_one.
      
      The latter does not need rtl8169_init_ring_indexes because the indexes
      still contain their original values from the newly allocated network
      device private data area (i.e. 0).
      
      rtl8169_hw_reset is used by:
      1. rtl8169_down
         Helper for rtl8169_close. rtl8169_open explicitely inits the indexes
         anyway.
      2. rtl8169_pcierr_interrupt
         Indexes are set by rtl8169_reinit_task.
      3. rtl8169_interrupt
         rtl8169_hw_reset is needed when the device goes down. See 1.
      4. rtl_shutdown
         System shutdown handler. Indexes are irrelevant.
      5. rtl8169_reset_task
         Indexes must be set before rtl_hw_start is called.
      6. rtl8169_tx_timeout
         Indexes should not be set. This is the job of rtl8169_reset_task anyway.
      
      The removal of rtl8169_hw_reset in rtl8169_tx_timeout and its move in
      rtl8169_reset_task do not change the analysis.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: hayeswang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c7c2c39b
    • F
      r8169: Rx FIFO overflow fixes. · 811fd301
      françois romieu 提交于
      Realtek has specified that the post 8168c gigabit chips and the post
      8105e fast ethernet chips recover automatically from a Rx FIFO overflow.
      The driver does not need to clear the RxFIFOOver bit of IntrStatus and
      it should rather avoid messing it.
      
      The implementation deserves some explanation:
      1. events outside of the intr_event bit mask are now ignored. It enforces
         a no-processing policy for the events that either should not be there
         or should be ignored.
      
      2. RxFIFOOver was already ignored in rtl_cfg_infos[RTL_CFG_1] for the
         whole 8168 line of chips with two exceptions:
         - RTL_GIGA_MAC_VER_22 since b5ba6d12
           ("use RxFIFO overflow workaround for 8168c chipset.").
           This one should now be correctly handled.
         - RTL_GIGA_MAC_VER_11 (8168b) which requires a different Rx FIFO
           overflow processing.
      
         Though it does not conform to Realtek suggestion above, the updated
         driver includes no change for RTL_GIGA_MAC_VER_12 and RTL_GIGA_MAC_VER_17.
         Both are 8168b. RTL_GIGA_MAC_VER_12 is common and a bit old so I'd rather
         wait for experimental evidence that the change suggested by Realtek really
         helps or does not hurt in unexpected ways.
      
         Removed case statements in rtl8169_interrupt are only 8168 relevant.
      
      3. RxFIFOOver is masked for post 8105e 810x chips, namely the sole 8105e
         (RTL_GIGA_MAC_VER_30) itself.
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Cc: hayeswang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      811fd301
  4. 04 12月, 2011 2 次提交
  5. 03 12月, 2011 3 次提交
    • W
      iwlwifi: change the default behavior of watchdog timer · 9995ffe5
      Wey-Yi Guy 提交于
      The current default watchdog timer is enabled, but we are seeing issues on
      legacy devices. So change the default setting of watchdog timer to per
      device based. But user still can use the "wd_disable" module parameter
      to overwrite the system setting
      
      Cc: stable@vger.kernel.org #3.0+
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9995ffe5
    • W
      iwlwifi: do not re-configure HT40 after associated · 34a5b4b6
      Wey-Yi Guy 提交于
      The ht40 setting should not change after association unless channel switch
      
      This fix a problem we are seeing which cause uCode assert because driver
      sending invalid information and make uCode confuse
      
      Here is the firmware assert message:
      kernel: iwlagn 0000:03:00.0: Microcode SW error detected.  Restarting 0x82000000.
      kernel: iwlagn 0000:03:00.0: Loaded firmware version: 17.168.5.3 build 42301
      kernel: iwlagn 0000:03:00.0: Start IWL Error Log Dump:
      kernel: iwlagn 0000:03:00.0: Status: 0x000512E4, count: 6
      kernel: iwlagn 0000:03:00.0: 0x00002078 | ADVANCED_SYSASSERT
      kernel: iwlagn 0000:03:00.0: 0x00009514 | uPc
      kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink1
      kernel: iwlagn 0000:03:00.0: 0x00009496 | branchlink2
      kernel: iwlagn 0000:03:00.0: 0x0000D1F2 | interruptlink1
      kernel: iwlagn 0000:03:00.0: 0x00000000 | interruptlink2
      kernel: iwlagn 0000:03:00.0: 0x01008035 | data1
      kernel: iwlagn 0000:03:00.0: 0x0000C90F | data2
      kernel: iwlagn 0000:03:00.0: 0x000005A7 | line
      kernel: iwlagn 0000:03:00.0: 0x5080B520 | beacon time
      kernel: iwlagn 0000:03:00.0: 0xCC515AE0 | tsf low
      kernel: iwlagn 0000:03:00.0: 0x00000003 | tsf hi
      kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp1
      kernel: iwlagn 0000:03:00.0: 0x29703BF0 | time gp2
      kernel: iwlagn 0000:03:00.0: 0x00000000 | time gp3
      kernel: iwlagn 0000:03:00.0: 0x000111A8 | uCode version
      kernel: iwlagn 0000:03:00.0: 0x000000B0 | hw version
      kernel: iwlagn 0000:03:00.0: 0x00480303 | board version
      kernel: iwlagn 0000:03:00.0: 0x09E8004E | hcmd
      kernel: iwlagn 0000:03:00.0: CSR values:
      kernel: iwlagn 0000:03:00.0: (2nd byte of CSR_INT_COALESCING is CSR_INT_PERIODIC_REG)
      kernel: iwlagn 0000:03:00.0:        CSR_HW_IF_CONFIG_REG: 0X00480303
      kernel: iwlagn 0000:03:00.0:          CSR_INT_COALESCING: 0X0000ff40
      kernel: iwlagn 0000:03:00.0:                     CSR_INT: 0X00000000
      kernel: iwlagn 0000:03:00.0:                CSR_INT_MASK: 0X00000000
      kernel: iwlagn 0000:03:00.0:           CSR_FH_INT_STATUS: 0X00000000
      kernel: iwlagn 0000:03:00.0:                 CSR_GPIO_IN: 0X00000030
      kernel: iwlagn 0000:03:00.0:                   CSR_RESET: 0X00000000
      kernel: iwlagn 0000:03:00.0:                CSR_GP_CNTRL: 0X080403c5
      kernel: iwlagn 0000:03:00.0:                  CSR_HW_REV: 0X000000b0
      kernel: iwlagn 0000:03:00.0:              CSR_EEPROM_REG: 0X07d60ffd
      kernel: iwlagn 0000:03:00.0:               CSR_EEPROM_GP: 0X90000001
      kernel: iwlagn 0000:03:00.0:              CSR_OTP_GP_REG: 0X00030001
      kernel: iwlagn 0000:03:00.0:                 CSR_GIO_REG: 0X00080044
      kernel: iwlagn 0000:03:00.0:            CSR_GP_UCODE_REG: 0X000093bb
      kernel: iwlagn 0000:03:00.0:           CSR_GP_DRIVER_REG: 0X00000000
      kernel: iwlagn 0000:03:00.0:           CSR_UCODE_DRV_GP1: 0X00000000
      kernel: iwlagn 0000:03:00.0:           CSR_UCODE_DRV_GP2: 0X00000000
      kernel: iwlagn 0000:03:00.0:                 CSR_LED_REG: 0X00000078
      kernel: iwlagn 0000:03:00.0:        CSR_DRAM_INT_TBL_REG: 0X88214dd2
      kernel: iwlagn 0000:03:00.0:        CSR_GIO_CHICKEN_BITS: 0X27800200
      kernel: iwlagn 0000:03:00.0:             CSR_ANA_PLL_CFG: 0X00000000
      kernel: iwlagn 0000:03:00.0:           CSR_HW_REV_WA_REG: 0X0001001a
      kernel: iwlagn 0000:03:00.0:        CSR_DBG_HPET_MEM_REG: 0Xffff0010
      kernel: iwlagn 0000:03:00.0: FH register values:
      kernel: iwlagn 0000:03:00.0:         FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X21316d00
      kernel: iwlagn 0000:03:00.0:        FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X021479c0
      kernel: iwlagn 0000:03:00.0:                  FH_RSCSR_CHNL0_WPTR: 0X00000060
      kernel: iwlagn 0000:03:00.0:         FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X80819104
      kernel: iwlagn 0000:03:00.0:          FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
      kernel: iwlagn 0000:03:00.0:            FH_MEM_RSSR_RX_STATUS_REG: 0X07030000
      kernel: iwlagn 0000:03:00.0:    FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
      kernel: iwlagn 0000:03:00.0:                FH_TSSR_TX_STATUS_REG: 0X07ff0001
      kernel: iwlagn 0000:03:00.0:                 FH_TSSR_TX_ERROR_REG: 0X00000000
      kernel: iwlagn 0000:03:00.0: Start IWL Event Log Dump: display last 20 entries
      kernel: ------------[ cut here ]------------
      WARNING: at net/mac80211/util.c:1208 ieee80211_reconfig+0x1f1/0x407()
      kernel: Hardware name: 4290W4H
      kernel: Pid: 1896, comm: kworker/0:0 Not tainted 3.1.0 #2
      kernel: Call Trace:
      kernel:  [<ffffffff81036558>] ? warn_slowpath_common+0x73/0x87
      kernel:  [<ffffffff813b8966>] ? ieee80211_reconfig+0x1f1/0x407
      kernel:  [<ffffffff8139e8dc>] ? ieee80211_recalc_smps_work+0x32/0x32
      kernel:  [<ffffffff8139e95a>] ? ieee80211_restart_work+0x7e/0x87
      kernel:  [<ffffffff810472fa>] ? process_one_work+0x1c8/0x2e3
      kernel:  [<ffffffff810480c9>] ? worker_thread+0x17a/0x23a
      kernel:  [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
      kernel:  [<ffffffff81047f4f>] ? manage_workers.clone.18+0x15b/0x15b
      kernel:  [<ffffffff8104ba97>] ? kthread+0x7a/0x82
      kernel:  [<ffffffff813d21b4>] ? kernel_thread_helper+0x4/0x10
      kernel:  [<ffffffff8104ba1d>] ? kthread_flush_work_fn+0x11/0x11
      kernel:  [<ffffffff813d21b0>] ? gs_change+0xb/0xb
      
      Cc: <stable@kernel.org> 3.1+
      Reported-by: NUdo Steinberg <udo@hypervisor.org>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      34a5b4b6
    • J
      iwlagn: fix HW crypto for TX-only keys · 274b89ca
      Johannes Berg 提交于
      Group keys in IBSS or AP mode are not programmed
      into the device since we give the key to it with
      every TX packet. However, we do need mac80211 to
      create the MMIC & PN in all cases. Move the code
      around to set the key flags all the time. We set
      them even when the key is removed again but that
      is obviously harmless.
      
      Cc: stable@vger.kernel.org
      Reported-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      274b89ca
  6. 02 12月, 2011 2 次提交
  7. 01 12月, 2011 2 次提交
  8. 29 11月, 2011 3 次提交
    • H
      staging: hv: move hv_netvsc out of staging area · 95fa0405
      Haiyang Zhang 提交于
      hv_netvsc has been reviewed on netdev mailing list on 6/09/2011.
      All recommended changes have been made. We are requesting to move
      it out of staging area.
      Signed-off-by: NHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NKY Srinivasan <kys@microsoft.com>
      Signed-off-by: NMike Sterling <Mike.Sterling@microsoft.com>
      Acked-by: NStephen Hemminger <shemminger@vyatta.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      95fa0405
    • R
      ath9k: Revert change that broke AR928X on Acer Ferrari One · a7322812
      Rafael J. Wysocki 提交于
      Revert a hunk in drivers/net/wireless/ath/ath9k/hw.c introduced by
      commit 2577c6e8 (ath9k_hw: Add
      support for AR946/8x chipsets) that caused a nasty regression to
      appear on my Acer Ferrari One (the box locks up entirely at random
      times after the wireless has been started without any way to get
      debug information out of it).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a7322812
    • S
      rtlwifi: fix lps_lock deadlock · e55b32c1
      Stanislaw Gruszka 提交于
      rtl_lps_leave can be called from interrupt context, so we have to
      disable interrupts when taking lps_lock.
      
      Below is full lockdep info about deadlock:
      
      [   93.815269] =================================
      [   93.815390] [ INFO: inconsistent lock state ]
      [   93.815472] 2.6.41.1-3.offch.fc15.x86_64.debug #1
      [   93.815556] ---------------------------------
      [   93.815635] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      [   93.815743] swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
      [   93.815832]  (&(&rtlpriv->locks.lps_lock)->rlock){+.?...}, at: [<ffffffffa025dad6>] rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.815947] {SOFTIRQ-ON-W} state was registered at:
      [   93.815947]   [<ffffffff8108e10d>] __lock_acquire+0x369/0xd0c
      [   93.815947]   [<ffffffff8108efb3>] lock_acquire+0xf3/0x13e
      [   93.815947]   [<ffffffff814e981d>] _raw_spin_lock+0x45/0x79
      [   93.815947]   [<ffffffffa025de34>] rtl_swlps_rf_awake+0x5a/0x76 [rtlwifi]
      [   93.815947]   [<ffffffffa025aec0>] rtl_op_config+0x12a/0x32a [rtlwifi]
      [   93.815947]   [<ffffffffa01d614b>] ieee80211_hw_config+0x124/0x129 [mac80211]
      [   93.815947]   [<ffffffffa01e0af3>] ieee80211_dynamic_ps_disable_work+0x32/0x47 [mac80211]
      [   93.815947]   [<ffffffff81075aa5>] process_one_work+0x205/0x3e7
      [   93.815947]   [<ffffffff81076753>] worker_thread+0xda/0x15d
      [   93.815947]   [<ffffffff8107a119>] kthread+0xa8/0xb0
      [   93.815947]   [<ffffffff814f3184>] kernel_thread_helper+0x4/0x10
      [   93.815947] irq event stamp: 547822
      [   93.815947] hardirqs last  enabled at (547822): [<ffffffff814ea1a7>] _raw_spin_unlock_irqrestore+0x45/0x61
      [   93.815947] hardirqs last disabled at (547821): [<ffffffff814e9987>] _raw_spin_lock_irqsave+0x22/0x8e
      [   93.815947] softirqs last  enabled at (547790): [<ffffffff810623ed>] _local_bh_enable+0x13/0x15
      [   93.815947] softirqs last disabled at (547791): [<ffffffff814f327c>] call_softirq+0x1c/0x30
      [   93.815947]
      [   93.815947] other info that might help us debug this:
      [   93.815947]  Possible unsafe locking scenario:
      [   93.815947]
      [   93.815947]        CPU0
      [   93.815947]        ----
      [   93.815947]   lock(&(&rtlpriv->locks.lps_lock)->rlock);
      [   93.815947]   <Interrupt>
      [   93.815947]     lock(&(&rtlpriv->locks.lps_lock)->rlock);
      [   93.815947]
      [   93.815947]  *** DEADLOCK ***
      [   93.815947]
      [   93.815947] no locks held by swapper/0.
      [   93.815947]
      [   93.815947] stack backtrace:
      [   93.815947] Pid: 0, comm: swapper Not tainted 2.6.41.1-3.offch.fc15.x86_64.debug #1
      [   93.815947] Call Trace:
      [   93.815947]  <IRQ>  [<ffffffff814dfd00>] print_usage_bug+0x1e7/0x1f8
      [   93.815947]  [<ffffffff8101a849>] ? save_stack_trace+0x2c/0x49
      [   93.815947]  [<ffffffff8108d55c>] ? print_irq_inversion_bug.part.18+0x1a0/0x1a0
      [   93.815947]  [<ffffffff8108dc8a>] mark_lock+0x106/0x220
      [   93.815947]  [<ffffffff8108e099>] __lock_acquire+0x2f5/0xd0c
      [   93.815947]  [<ffffffff810152af>] ? native_sched_clock+0x34/0x36
      [   93.830125]  [<ffffffff810152ba>] ? sched_clock+0x9/0xd
      [   93.830125]  [<ffffffff81080181>] ? sched_clock_local+0x12/0x75
      [   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.830125]  [<ffffffff8108efb3>] lock_acquire+0xf3/0x13e
      [   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.830125]  [<ffffffff814e981d>] _raw_spin_lock+0x45/0x79
      [   93.830125]  [<ffffffffa025dad6>] ? rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.830125]  [<ffffffff81422467>] ? skb_dequeue+0x62/0x6d
      [   93.830125]  [<ffffffffa025dad6>] rtl_lps_leave+0x26/0x103 [rtlwifi]
      [   93.830125]  [<ffffffffa025f677>] _rtl_pci_ips_leave_tasklet+0xe/0x10 [rtlwifi]
      [   93.830125]  [<ffffffff8106281f>] tasklet_action+0x8d/0xee
      [   93.830125]  [<ffffffff810629ce>] __do_softirq+0x112/0x25a
      [   93.830125]  [<ffffffff814f327c>] call_softirq+0x1c/0x30
      [   93.830125]  [<ffffffff81010bf6>] do_softirq+0x4b/0xa1
      [   93.830125]  [<ffffffff81062d7d>] irq_exit+0x5d/0xcf
      [   93.830125]  [<ffffffff814f3b7e>] do_IRQ+0x8e/0xa5
      [   93.830125]  [<ffffffff814ea533>] common_interrupt+0x73/0x73
      [   93.830125]  <EOI>  [<ffffffff8108b825>] ? trace_hardirqs_off+0xd/0xf
      [   93.830125]  [<ffffffff812bb6d5>] ? intel_idle+0xe5/0x10c
      [   93.830125]  [<ffffffff812bb6d1>] ? intel_idle+0xe1/0x10c
      [   93.830125]  [<ffffffff813f8d5e>] cpuidle_idle_call+0x11c/0x1fe
      [   93.830125]  [<ffffffff8100e2ef>] cpu_idle+0xab/0x101
      [   93.830125]  [<ffffffff814c6373>] rest_init+0xd7/0xde
      [   93.830125]  [<ffffffff814c629c>] ? csum_partial_copy_generic+0x16c/0x16c
      [   93.830125]  [<ffffffff81d4bbb0>] start_kernel+0x3dd/0x3ea
      [   93.830125]  [<ffffffff81d4b2c4>] x86_64_start_reservations+0xaf/0xb3
      [   93.830125]  [<ffffffff81d4b140>] ? early_idt_handlers+0x140/0x140
      [   93.830125]  [<ffffffff81d4b3ca>] x86_64_start_kernel+0x102/0x111
      
      Resolves:
      https://bugzilla.redhat.com/show_bug.cgi?id=755154
      
      Reported-by: vjain02@students.poly.edu
      Reported-and-tested-by: NOliver Paukstadt <pstadt@sourcentral.org>
      Cc: stable@vger.kernel.org
      Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e55b32c1
  9. 28 11月, 2011 2 次提交
  10. 27 11月, 2011 2 次提交
  11. 24 11月, 2011 5 次提交
    • A
      ehea: Use round_jiffies_relative to align workqueue · 67c170a2
      Anton Blanchard 提交于
      Use round_jiffies_relative to align the ehea workqueue and avoid
      extra wakeups.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      67c170a2
    • A
      ehea: Reduce memory usage in buffer pools · aa9084a0
      Anton Blanchard 提交于
      Now that we enable multiqueue by default the ehea driver is using
      quite a lot of memory for its buffer pools. With 4 queues we
      consume 64MB in the jumbo packet ring, 16MB in the medium packet
      ring and 16MB in the tiny packet ring.
      
      We should only fill the jumbo ring once the MTU is increased but
      for now halve it's size so it consumes 32MB. Also reduce the tiny
      packet ring, with 4 queues we had 16k entries which is overkill.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aa9084a0
    • T
      qlge: fix size of external list for TX address descriptors · 78242853
      Thadeu Lima de Souza Cascardo 提交于
      When transmiting a fragmented skb, qlge fills a descriptor with the
      fragment addresses, after DMA-mapping them. If there are more than eight
      fragments, it will use the eighth descriptor as a pointer to an external
      list. After mapping this external list, called OAL to a structure
      containing more descriptors, it fills it with the extra fragments.
      
      However, considering that systems with pages larger than 8KiB would have
      less than 8 fragments, which was true before commit a715dea3, it
      defined a macro for the OAL size as 0 in those cases.
      
      Now, if a skb with more than 8 fragments (counting skb->data as one
      fragment), this would start overwriting the list of addresses already
      mapped and would make the driver fail to properly unmap the right
      addresses on architectures with pages larger than 8KiB.
      
      Besides that, the list of mappings was one size too small, since it must
      have a mapping for the maxinum number of skb fragments plus one for
      skb->data and another for the OAL. So, even on architectures with page
      sizes 4KiB and 8KiB, a skb with the maximum number of fragments would
      make the driver overwrite its counter for the number of mappings, which,
      again, would make it fail to unmap the mapped DMA addresses.
      Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      78242853
    • Y
      bnx2x: Fix 5461x LED · 1d125bd5
      Yaniv Rosner 提交于
      Fix port identify test on 5461x PHY by driving LEDs through MDIO.
      Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
      Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1d125bd5
    • X
      b44: Use dev_kfree_skb_irq() in b44_tx() · 15ac2b08
      Xander Hover 提交于
      Reported issues when using dev_kfree_skb() on UP systems and
      systems with low numbers of cores.  dev_kfree_skb_irq() will
      properly save IRQ state before freeing the skb.
      
      Tested on 3.1.1 and 3.2_rc2
      
      Example of reproducible trace of kernel 3.1.1
      ------------[ cut here ]------------
         WARNING: at kernel/softirq.c:159 local_bh_enable+0x32/0x79()
         ...
         Pid: 0, comm: swapper Not tainted 3.1.1-gentoo #1
         Call Trace:
          [<c1022970>] warn_slowpath_common+0x65/0x7a
          [<c102699e>] ? local_bh_enable+0x32/0x79
          [<c1022994>] warn_slowpath_null+0xf/0x13
          [<c102699e>] local_bh_enable+0x32/0x79
          [<c134bfd8>] destroy_conntrack+0x7c/0x9b
          [<c134890b>] nf_conntrack_destroy+0x1f/0x26
          [<c132e3a6>] skb_release_head_state+0x74/0x83
          [<c132e286>] __kfree_skb+0xb/0x6b
          [<c132e30a>] consume_skb+0x24/0x26
          [<c127c925>] b44_poll+0xaa/0x449
          [<c1333ca1>] net_rx_action+0x3f/0xea
          [<c1026a44>] __do_softirq+0x5f/0xd5
          [<c10269e5>] ? local_bh_enable+0x79/0x79
          <IRQ>  [<c1026c32>] ? irq_exit+0x34/0x8d
          [<c1003628>] ? do_IRQ+0x74/0x87
          [<c13f5329>] ? common_interrupt+0x29/0x30
          [<c1006e18>] ? default_idle+0x29/0x3e
          [<c10015a7>] ? cpu_idle+0x2f/0x5d
          [<c13e91c5>] ? rest_init+0x79/0x7b
          [<c15c66a9>] ? start_kernel+0x297/0x29c
          [<c15c60b0>] ? i386_start_kernel+0xb0/0xb7
         ---[ end trace 583f33bb1aa207a9 ]---
      Signed-off-by: NXander Hover <LKML@hover.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      15ac2b08
  12. 23 11月, 2011 2 次提交
  13. 22 11月, 2011 5 次提交
  14. 18 11月, 2011 5 次提交