1. 03 12月, 2013 9 次提交
    • R
      PCI / tg3: Give up chip reset and carrier loss handling if PCI device is not present · 8496e85c
      Rafael J. Wysocki 提交于
      Modify tg3_chip_reset() and tg3_close() to check if the PCI network
      adapter device is accessible at all in order to skip poking it or
      trying to handle a carrier loss in vain when that's not the case.
      Introduce a special PCI helper function pci_device_is_present()
      for this purpose.
      
      Of course, this uncovers the lack of the appropriate RTNL locking
      in tg3_suspend() and tg3_resume(), so add that locking in there
      too.
      
      These changes prevent tg3 from burning a CPU at 100% load level for
      solid several seconds after the Thunderbolt link is disconnected from
      a Matrox DS1 docking station.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8496e85c
    • D
      ipv6: judge the accept_ra_defrtr before calling rt6_route_rcv · 30e56918
      Duan Jiong 提交于
      when dealing with a RA message, if accept_ra_defrtr is false,
      the kernel will not add the default route, and then deal with
      the following route information options. Unfortunately, those
      options maybe contain default route, so let's judge the
      accept_ra_defrtr before calling rt6_route_rcv.
      Signed-off-by: NDuan Jiong <duanj.fnst@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      30e56918
    • L
      Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · a45299e7
      Linus Torvalds 提交于
      Pull irq fixes from Thomas Gleixner:
       - Correction of fuzzy and fragile IRQ_RETVAL macro
       - IRQ related resume fix affecting only XEN
       - ARM/GIC fix for chained GIC controllers
      
      * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        irqchip: Gic: fix boot for chained gics
        irq: Enable all irqs unconditionally in irq_resume
        genirq: Correct fuzzy and fragile IRQ_RETVAL() definition
      a45299e7
    • L
      Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · a0b57ca3
      Linus Torvalds 提交于
      Pull scheduler fixes from Ingo Molnar:
       "Various smaller fixlets, all over the place"
      
      * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        sched/doc: Fix generation of device-drivers
        sched: Expose preempt_schedule_irq()
        sched: Fix a trivial typo in comments
        sched: Remove unused variable in 'struct sched_domain'
        sched: Avoid NULL dereference on sd_busy
        sched: Check sched_domain before computing group power
        MAINTAINERS: Update file patterns in the lockdep and scheduler entries
      a0b57ca3
    • L
      Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · e321ae4c
      Linus Torvalds 提交于
      Pull perf fixes from Ingo Molnar:
       "Misc kernel and tooling fixes"
      
      * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        tools lib traceevent: Fix conversion of pointer to integer of different size
        perf/trace: Properly use u64 to hold event_id
        perf: Remove fragile swevent hlist optimization
        ftrace, perf: Avoid infinite event generation loop
        tools lib traceevent: Fix use of multiple options in processing field
        perf header: Fix possible memory leaks in process_group_desc()
        perf header: Fix bogus group name
        perf tools: Tag thread comm as overriden
      e321ae4c
    • L
      Merge tag 'stable/for-linus-3.13-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip · bcc2f9b7
      Linus Torvalds 提交于
      Pull Xen bug-fixes from Konrad Rzeszutek Wilk:
       "Fixes to patches that went in this merge window along with a latent
        bug:
         - Fix lazy flushing in case m2p override fails.
         - Fix module compile issues with ARM/Xen
         - Add missing call to DMA map page for Xen SWIOTLB for ARM"
      
      * tag 'stable/for-linus-3.13-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
        xen/gnttab: leave lazy MMU mode in the case of a m2p override failure
        xen/arm: p2m_init and p2m_lock should be static
        arm/xen: Export phys_to_mach to fix Xen module link errors
        swiotlb-xen: add missing xen_dma_map_page call
      bcc2f9b7
    • L
      Merge tag 'spi-v3.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi · aeac8103
      Linus Torvalds 提交于
      Pull spi fixes from Mark Brown:
       "A smattering of driver specific fixes here, including a bunch for a
        long standing common pattern in the error handling paths, and a fix
        for an embarrassing thinko in the new devm master registration code"
      
      * tag 'spi-v3.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
        spi/pxa2xx: Restore private register bits.
        spi/qspi: Fix qspi remove path.
        spi/qspi: cleanup pm_runtime error check.
        spi/qspi: set correct platform drvdata in ti_qspi_probe()
        spi/pxa2xx: add new ACPI IDs
        spi: core: invert success test in devm_spi_register_master
        spi: spi-mxs: fix reference leak to master in mxs_spi_remove()
        spi: bcm63xx: fix reference leak to master in bcm63xx_spi_remove()
        spi: txx9: fix reference leak to master in txx9spi_remove()
        spi: mpc512x: fix reference leak to master in mpc512x_psc_spi_do_remove()
        spi: rspi: use platform drvdata correctly in rspi_remove()
        spi: bcm2835: fix reference leak to master in bcm2835_spi_remove()
      aeac8103
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 5fc92de3
      Linus Torvalds 提交于
      Pull networking updates from David Miller:
       "Here is a pile of bug fixes that accumulated while I was in Europe"
      
       1) In fixing kernel leaks to userspace during copying of socket
          addresses, we broke a case that used to work, namely the user
          providing a buffer larger than the in-kernel generic socket address
          structure.  This broke Ruby amongst other things.  Fix from Dan
          Carpenter.
      
       2) Fix regression added by byte queue limit support in 8139cp driver,
          from Yang Yingliang.
      
       3) The addition of MSG_SENDPAGE_NOTLAST buggered up a few sendpage
          implementations, they should just treat it the same as MSG_MORE.
          Fix from Richard Weinberger and Shawn Landden.
      
       4) Handle icmpv4 errors received on ipv6 SIT tunnels correctly, from
          Oussama Ghorbel.  In particular we should send an ICMPv6 unreachable
          in such situations.
      
       5) Fix some regressions in the recent genetlink fixes, in particular
          get the pmcraid driver to use the new safer interfaces correctly.
          From Johannes Berg.
      
       6) macvtap was converted to use a per-cpu set of statistics, but some
          code was still bumping tx_dropped elsewhere.  From Jason Wang.
      
       7) Fix build failure of xen-netback due to missing include on some
          architectures, from Andy Whitecroft.
      
       8) macvtap double counts received packets in statistics, fix from Vlad
          Yasevich.
      
       9) Fix various cases of using *_STATS_BH() when *_STATS() is more
          appropriate.  From Eric Dumazet and Hannes Frederic Sowa.
      
      10) Pktgen ipsec mode doesn't update the ipv4 header length and checksum
          properly after encapsulation.  Fix from Fan Du.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (61 commits)
        net/mlx4_en: Remove selftest TX queues empty condition
        {pktgen, xfrm} Update IPv4 header total len and checksum after tranformation
        virtio_net: make all RX paths handle erors consistently
        virtio_net: fix error handling for mergeable buffers
        virtio_net: Fixed a trivial typo (fitler --> filter)
        netem: fix gemodel loss generator
        netem: fix loss 4 state model
        netem: missing break in ge loss generator
        net/hsr: Support iproute print_opt ('ip -details ...')
        net/hsr: Very small fix of comment style.
        MAINTAINERS: Added net/hsr/ maintainer
        ipv6: fix possible seqlock deadlock in ip6_finish_output2
        ixgbe: Make ixgbe_identify_qsfp_module_generic static
        ixgbe: turn NETIF_F_HW_L2FW_DOFFLOAD off by default
        ixgbe: ixgbe_fwd_ring_down needs to be static
        e1000: fix possible reset_task running after adapter down
        e1000: fix lockdep warning in e1000_reset_task
        e1000: prevent oops when adapter is being closed and reset simultaneously
        igb: Fixed Wake On LAN support
        inet: fix possible seqlock deadlocks
        ...
      5fc92de3
    • L
      vfs: fix subtle use-after-free of pipe_inode_info · b0d8d229
      Linus Torvalds 提交于
      The pipe code was trying (and failing) to be very careful about freeing
      the pipe info only after the last access, with a pattern like:
      
              spin_lock(&inode->i_lock);
              if (!--pipe->files) {
                      inode->i_pipe = NULL;
                      kill = 1;
              }
              spin_unlock(&inode->i_lock);
              __pipe_unlock(pipe);
              if (kill)
                      free_pipe_info(pipe);
      
      where the final freeing is done last.
      
      HOWEVER.  The above is actually broken, because while the freeing is
      done at the end, if we have two racing processes releasing the pipe
      inode info, the one that *doesn't* free it will decrement the ->files
      count, and unlock the inode i_lock, but then still use the
      "pipe_inode_info" afterwards when it does the "__pipe_unlock(pipe)".
      
      This is *very* hard to trigger in practice, since the race window is
      very small, and adding debug options seems to just hide it by slowing
      things down.
      
      Simon originally reported this way back in July as an Oops in
      kmem_cache_allocate due to a single bit corruption (due to the final
      "spin_unlock(pipe->mutex.wait_lock)" incrementing a field in a different
      allocation that had re-used the free'd pipe-info), it's taken this long
      to figure out.
      
      Since the 'pipe->files' accesses aren't even protected by the pipe lock
      (we very much use the inode lock for that), the simple solution is to
      just drop the pipe lock early.  And since there were two users of this
      pattern, create a helper function for it.
      
      Introduced commit ba5bb147 ("pipe: take allocation and freeing of
      pipe_inode_info out of ->i_mutex").
      Reported-by: NSimon Kirby <sim@hostway.ca>
      Reported-by: NIan Applegate <ia@cloudflare.com>
      Acked-by: NAl Viro <viro@zeniv.linux.org.uk>
      Cc: stable@kernel.org   # v3.10+
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b0d8d229
  2. 02 12月, 2013 6 次提交
  3. 01 12月, 2013 15 次提交
  4. 30 11月, 2013 10 次提交
    • R
      ARM: footbridge: fix VGA initialisation · 43659222
      Russell King 提交于
      It's no good setting vga_base after the VGA console has been
      initialised, because if we do that we get this:
      
      Unable to handle kernel paging request at virtual address 000b8000
      pgd = c0004000
      [000b8000] *pgd=07ffc831, *pte=00000000, *ppte=00000000
      0Internal error: Oops: 5017 [#1] ARM
      Modules linked in:
      CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0+ #49
      task: c03e2974 ti: c03d8000 task.ti: c03d8000
      PC is at vgacon_startup+0x258/0x39c
      LR is at request_resource+0x10/0x1c
      pc : [<c01725d0>]    lr : [<c0022b50>]    psr: 60000053
      sp : c03d9f68  ip : 000b8000  fp : c03d9f8c
      r10: 000055aa  r9 : 4401a103  r8 : ffffaa55
      r7 : c03e357c  r6 : c051b460  r5 : 000000ff  r4 : 000c0000
      r3 : 000b8000  r2 : c03e0514  r1 : 00000000  r0 : c0304971
      Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
      
      which is an access to the 0xb8000 without the PCI offset required to
      make it work.
      
      Fixes: cc22b4c1 ("ARM: set vga memory base at run-time")
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: <stable@vger.kernel.org>
      43659222
    • R
      ARM: fix booting low-vectors machines · d8aa712c
      Russell King 提交于
      Commit f6f91b0d (ARM: allow kuser helpers to be removed from the
      vector page) required two pages for the vectors code.  Although the
      code setting up the initial page tables was updated, the code which
      allocates page tables for new processes wasn't, neither was the code
      which tears down the mappings.  Fix this.
      
      Fixes: f6f91b0d ("ARM: allow kuser helpers to be removed from the vector page")
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: <stable@vger.kernel.org>
      d8aa712c
    • R
      ARM: dma-mapping: check DMA mask against available memory · 11a5aa32
      Russell King 提交于
      Some buses have negative offsets, which causes the DMA mask checks to
      falsely fail.  Fix this by using the actual amount of memory fitted in
      the system.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      11a5aa32
    • M
      ixgbe: Make ixgbe_identify_qsfp_module_generic static · 88217547
      Mark Rustad 提交于
      Correct a namespace complaint by making the function static
      and moving the prototype into the .c file.
      Signed-off-by: NMark Rustad <mark.d.rustad@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      88217547
    • J
      ixgbe: turn NETIF_F_HW_L2FW_DOFFLOAD off by default · 8bf1264d
      John Fastabend 提交于
      NETIF_F_HW_L2FW_DOFFLOAD allows upper layer net devices such
      as macvlan to use queues in the hardware to directly submit and
      receive skbs.
      
      This creates a subtle change in the datapath though. One change
      being the skb may no longer use the root devices qdisc.
      
      Because users may not expect this we can't enable the feature
      by default unless the hardware can offload all the software
      functionality above it. So for now disable it by default and
      let users opt in.
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      8bf1264d
    • J
      ixgbe: ixgbe_fwd_ring_down needs to be static · ae72c8d0
      John Fastabend 提交于
      When compiling with -Wstrict-prototypes gcc catches a static
      I missed.
      
      ./ixgbe_main.c:4254: warning: no previous prototype for 'ixgbe_fwd_ring_down'
      Reported-by: NPhillip Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      ae72c8d0
    • V
      e1000: fix possible reset_task running after adapter down · 74a1b1ea
      Vladimir Davydov 提交于
      On e1000_down(), we should ensure every asynchronous work is canceled
      before proceeding. Since the watchdog_task can schedule other works
      apart from itself, it should be stopped first, but currently it is
      stopped after the reset_task. This can result in the following race
      leading to the reset_task running after the module unload:
      
      e1000_down_and_stop():			e1000_watchdog():
      ----------------------			-----------------
      
      cancel_work_sync(reset_task)
      					schedule_work(reset_task)
      cancel_delayed_work_sync(watchdog_task)
      
      The patch moves cancel_delayed_work_sync(watchdog_task) at the beginning
      of e1000_down_and_stop() thus ensuring the race is impossible.
      
      Cc: Tushar Dave <tushar.n.dave@intel.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Signed-off-by: NVladimir Davydov <vdavydov@parallels.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      74a1b1ea
    • V
      e1000: fix lockdep warning in e1000_reset_task · b2f963bf
      Vladimir Davydov 提交于
      The patch fixes the following lockdep warning, which is 100%
      reproducible on network restart:
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.12.0+ #47 Tainted: GF
      -------------------------------------------------------
      kworker/1:1/27 is trying to acquire lock:
       ((&(&adapter->watchdog_task)->work)){+.+...}, at: [<ffffffff8108a5b0>] flush_work+0x0/0x70
      
      but task is already holding lock:
       (&adapter->mutex){+.+...}, at: [<ffffffffa0177c0a>] e1000_reset_task+0x4a/0xa0 [e1000]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&adapter->mutex){+.+...}:
             [<ffffffff810bdb5d>] lock_acquire+0x9d/0x120
             [<ffffffff816b8cbc>] mutex_lock_nested+0x4c/0x390
             [<ffffffffa017233d>] e1000_watchdog+0x7d/0x5b0 [e1000]
             [<ffffffff8108b972>] process_one_work+0x1d2/0x510
             [<ffffffff8108ca80>] worker_thread+0x120/0x3a0
             [<ffffffff81092c1e>] kthread+0xee/0x110
             [<ffffffff816c3d7c>] ret_from_fork+0x7c/0xb0
      
      -> #0 ((&(&adapter->watchdog_task)->work)){+.+...}:
             [<ffffffff810bd9c0>] __lock_acquire+0x1710/0x1810
             [<ffffffff810bdb5d>] lock_acquire+0x9d/0x120
             [<ffffffff8108a5eb>] flush_work+0x3b/0x70
             [<ffffffff8108b5d8>] __cancel_work_timer+0x98/0x140
             [<ffffffff8108b693>] cancel_delayed_work_sync+0x13/0x20
             [<ffffffffa0170cec>] e1000_down_and_stop+0x3c/0x60 [e1000]
             [<ffffffffa01775b1>] e1000_down+0x131/0x220 [e1000]
             [<ffffffffa0177c12>] e1000_reset_task+0x52/0xa0 [e1000]
             [<ffffffff8108b972>] process_one_work+0x1d2/0x510
             [<ffffffff8108ca80>] worker_thread+0x120/0x3a0
             [<ffffffff81092c1e>] kthread+0xee/0x110
             [<ffffffff816c3d7c>] ret_from_fork+0x7c/0xb0
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&adapter->mutex);
                                     lock((&(&adapter->watchdog_task)->work));
                                     lock(&adapter->mutex);
        lock((&(&adapter->watchdog_task)->work));
      
       *** DEADLOCK ***
      
      3 locks held by kworker/1:1/27:
       #0:  (events){.+.+.+}, at: [<ffffffff8108b906>] process_one_work+0x166/0x510
       #1:  ((&adapter->reset_task)){+.+...}, at: [<ffffffff8108b906>] process_one_work+0x166/0x510
       #2:  (&adapter->mutex){+.+...}, at: [<ffffffffa0177c0a>] e1000_reset_task+0x4a/0xa0 [e1000]
      
      stack backtrace:
      CPU: 1 PID: 27 Comm: kworker/1:1 Tainted: GF            3.12.0+ #47
      Hardware name: System manufacturer System Product Name/P5B-VM SE, BIOS 0501    05/31/2007
      Workqueue: events e1000_reset_task [e1000]
       ffffffff820f6000 ffff88007b9dba98 ffffffff816b54a2 0000000000000002
       ffffffff820f5e50 ffff88007b9dbae8 ffffffff810ba936 ffff88007b9dbac8
       ffff88007b9dbb48 ffff88007b9d8f00 ffff88007b9d8780 ffff88007b9d8f00
      Call Trace:
       [<ffffffff816b54a2>] dump_stack+0x49/0x5f
       [<ffffffff810ba936>] print_circular_bug+0x216/0x310
       [<ffffffff810bd9c0>] __lock_acquire+0x1710/0x1810
       [<ffffffff8108a5b0>] ? __flush_work+0x250/0x250
       [<ffffffff810bdb5d>] lock_acquire+0x9d/0x120
       [<ffffffff8108a5b0>] ? __flush_work+0x250/0x250
       [<ffffffff8108a5eb>] flush_work+0x3b/0x70
       [<ffffffff8108a5b0>] ? __flush_work+0x250/0x250
       [<ffffffff8108b5d8>] __cancel_work_timer+0x98/0x140
       [<ffffffff8108b693>] cancel_delayed_work_sync+0x13/0x20
       [<ffffffffa0170cec>] e1000_down_and_stop+0x3c/0x60 [e1000]
       [<ffffffffa01775b1>] e1000_down+0x131/0x220 [e1000]
       [<ffffffffa0177c12>] e1000_reset_task+0x52/0xa0 [e1000]
       [<ffffffff8108b972>] process_one_work+0x1d2/0x510
       [<ffffffff8108b906>] ? process_one_work+0x166/0x510
       [<ffffffff8108ca80>] worker_thread+0x120/0x3a0
       [<ffffffff8108c960>] ? manage_workers+0x2c0/0x2c0
       [<ffffffff81092c1e>] kthread+0xee/0x110
       [<ffffffff81092b30>] ? __init_kthread_worker+0x70/0x70
       [<ffffffff816c3d7c>] ret_from_fork+0x7c/0xb0
       [<ffffffff81092b30>] ? __init_kthread_worker+0x70/0x70
      
      == The issue background ==
      
      The problem occurs, because e1000_down(), which is called under
      adapter->mutex by e1000_reset_task(), tries to synchronously cancel
      e1000 auxiliary works (reset_task, watchdog_task, phy_info_task,
      fifo_stall_task), which take adapter->mutex in their handlers. So the
      question is what does adapter->mutex protect there?
      
      The adapter->mutex was introduced by commit 0ef4ee ("e1000: convert to
      private mutex from rtnl") as a replacement for rtnl_lock() taken in the
      asynchronous handlers. It targeted on fixing a similar lockdep warning
      issued when e1000_down() was called under rtnl_lock(), and it fixed it,
      but unfortunately it introduced the lockdep warning described above.
      Anyway, that said the source of this bug is that the asynchronous works
      were made to take rtnl_lock() some time ago, so let's look deeper and
      find why it was added there.
      
      The rtnl_lock() was added to asynchronous handlers by commit 338c15
      ("e1000: fix occasional panic on unload") in order to prevent
      asynchronous handlers from execution after the module is unloaded
      (e1000_down() is called) as it follows from the comment to the commit:
      
      > Net drivers in general have an issue where timers fired
      > by mod_timer or work threads with schedule_work are running
      > outside of the rtnl_lock.
      >
      > With no other lock protection these routines are vulnerable
      > to races with driver unload or reset paths.
      >
      > The longer term solution to this might be a redesign with
      > safer locks being taken in the driver to guarantee no
      > reentrance, but for now a safe and effective fix is
      > to take the rtnl_lock in these routines.
      
      I'm not sure if this locking scheme fixed the problem or just made it
      unlikely, although I incline to the latter. Anyway, this was long time
      ago when e1000 auxiliary works were implemented as timers scheduling
      real work handlers in their routines. The e1000_down() function only
      canceled the timers, but left the real handlers running if they were
      running, which could result in work execution after module unload.
      Today, the e1000 driver uses sane delayed works instead of the pair
      timer+work to implement its delayed asynchronous handlers, and the
      e1000_down() synchronously cancels all the works so that the problem
      that commit 338c15 tried to cope with disappeared, and we don't need any
      locks in the handlers any more. Moreover, any locking there can
      potentially result in a deadlock.
      
      So, this patch reverts commits 0ef4ee and 338c15.
      
      Fixes: 0ef4eedc ("e1000: convert to private mutex from rtnl")
      Fixes: 338c15e4 ("e1000: fix occasional panic on unload")
      Cc: Tushar Dave <tushar.n.dave@intel.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Signed-off-by: NVladimir Davydov <vdavydov@parallels.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      b2f963bf
    • Y
      e1000: prevent oops when adapter is being closed and reset simultaneously · 6a7d64e3
      yzhu1 提交于
      This change is based on a similar change made to e1000e support in
      commit bb9e44d0 ("e1000e: prevent oops when adapter is being closed
      and reset simultaneously").  The same issue has also been observed
      on the older e1000 cards.
      
      Here, we have increased the RESET_COUNT value to 50 because there are too
      many accesses to e1000 nic on stress tests to e1000 nic, it is not enough
      to set RESET_COUT 25. Experimentation has shown that it is enough to set
      RESET_COUNT 50.
      Signed-off-by: Nyzhu1 <yanjun.zhu@windriver.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      6a7d64e3
    • A
      igb: Fixed Wake On LAN support · 42ce4126
      Akeem G Abodunrin 提交于
      This patch fixes Wake on LAN being reported as supported on some Ethernet
      ports, in contrary to Hardware capability.
      Signed-off-by: NAkeem G Abodunrin <akeem.g.abodunrin@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      42ce4126