1. 04 10月, 2011 5 次提交
    • T
      pch_gbe: Fixed the issue on which a network freezes · 805e969f
      Toshiharu Okada 提交于
      The pch_gbe driver has an issue which a network stops,
      when receiving traffic is high.
      In the case, The link down and up are necessary to return a network.
      
      This patch fixed this issue.
      Signed-off-by: NToshiharu Okada <toshiharu-linux@dsn.okisemi.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      805e969f
    • T
      pch_gbe: Fixed the issue on which PC was frozen when link was downed. · 5f3a1141
      Toshiharu Okada 提交于
      When a link was downed during network use,
      there is an issue on which PC freezes.
      
      This patch fixed this issue.
      Signed-off-by: NToshiharu Okada <toshiharu-linux@dsn.okisemi.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f3a1141
    • W
      make PACKET_STATISTICS getsockopt report consistently between ring and non-ring · 7091fbd8
      Willem de Bruijn 提交于
      This is a minor change.
      
      Up until kernel 2.6.32, getsockopt(fd, SOL_PACKET, PACKET_STATISTICS,
      ...) would return total and dropped packets since its last invocation. The
      introduction of socket queue overflow reporting [1] changed drop
      rate calculation in the normal packet socket path, but not when using a
      packet ring. As a result, the getsockopt now returns different statistics
      depending on the reception method used. With a ring, it still returns the
      count since the last call, as counts are incremented in tpacket_rcv and
      reset in getsockopt. Without a ring, it returns 0 if no drops occurred
      since the last getsockopt and the total drops over the lifespan of
      the socket otherwise. The culprit is this line in packet_rcv, executed
      on a drop:
      
      drop_n_acct:
              po->stats.tp_drops = atomic_inc_return(&sk->sk_drops);
      
      As it shows, the new drop number it taken from the socket drop counter,
      which is not reset at getsockopt. I put together a small example
      that demonstrates the issue [2]. It runs for 10 seconds and overflows
      the queue/ring on every odd second. The reported drop rates are:
      ring: 16, 0, 16, 0, 16, ...
      non-ring: 0, 15, 0, 30, 0, 46, 0, 60, 0 , 74.
      
      Note how the even ring counts monotonically increase. Because the
      getsockopt adds tp_drops to tp_packets, total counts are similarly
      reported cumulatively. Long story short, reinstating the original code, as
      the below patch does, fixes the issue at the cost of additional per-packet
      cycles. Another solution that does not introduce per-packet overhead
      is be to keep the current data path, record the value of sk_drops at
      getsockopt() at call N in a new field in struct packetsock and subtract
      that when reporting at call N+1. I'll be happy to code that, instead,
      it's just more messy.
      
      [1] http://patchwork.ozlabs.org/patch/35665/
      [2] http://kernel.googlecode.com/files/test-packetsock-getstatistics.cSigned-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7091fbd8
    • D
      net: xen-netback: correctly restart Tx after a VM restore/migrate · d0e5d832
      David Vrabel 提交于
      If a VM is saved and restored (or migrated) the netback driver will no
      longer process any Tx packets from the frontend.  xenvif_up() does not
      schedule the processing of any pending Tx requests from the front end
      because the carrier is off.  Without this initial kick the frontend
      just adds Tx requests to the ring without raising an event (until the
      ring is full).
      
      This was caused by 47103041 (net:
      xen-netback: convert to hw_features) which reordered the calls to
      xenvif_up() and netif_carrier_on() in xenvif_connect().
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Acked-by: NIan Campbell <ian.campbell@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0e5d832
    • A
      bonding: properly stop queuing work when requested · a0db2dad
      Andy Gospodarek 提交于
      During a test where a pair of bonding interfaces using ARP monitoring
      were both brought up and torn down (with an rmmod) repeatedly, a panic
      in the timer code was noticed.  I tracked this down and determined that
      any of the bonding functions that ran as workqueue handlers and requeued
      more work might not properly exit when the module was removed.
      
      There was a flag protected by the bond lock called kill_timers that is
      set when the interface goes down or the module is removed, but many of
      the functions that monitor link status now unlock the bond lock to take
      rtnl first.  There is a chance that another CPU running the rmmod could
      get the lock and set kill_timers after the first check has passed.
      
      This patch does not allow any function to queue work that will make
      itself run unless kill_timers is not set.  I also noticed while doing
      this work that bond_resend_igmp_join_requests did not have a check for
      kill_timers, so I added the needed call there as well.
      Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
      Reported-by: NLiang Zheng <lzheng@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0db2dad
  2. 30 9月, 2011 3 次提交
  3. 29 9月, 2011 8 次提交
  4. 28 9月, 2011 20 次提交
  5. 27 9月, 2011 4 次提交
    • L
      vfs: remove LOOKUP_NO_AUTOMOUNT flag · b6c8069d
      Linus Torvalds 提交于
      That flag no longer makes sense, since we don't look up automount points
      as eagerly any more.  Additionally, it turns out that the NO_AUTOMOUNT
      handling was buggy to begin with: it would avoid automounting even for
      cases where we really *needed* to do the automount handling, and could
      return ENOENT for autofs entries that hadn't been instantiated yet.
      
      With our new non-eager automount semantics, one discussion has been
      about adding a AT_AUTOMOUNT flag to vfs_fstatat (and thus the
      newfstatat() and fstatat64() system calls), but it's probably not worth
      it: you can always force at least directory automounting by simply
      adding the final '/' to the filename, which works for *all* of the stat
      family system calls, old and new.
      
      So AT_NO_AUTOMOUNT (and thus LOOKUP_NO_AUTOMOUNT) really were just a
      result of our bad default behavior.
      Acked-by: NIan Kent <raven@themaw.net>
      Acked-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b6c8069d
    • L
      ASoC: ssm2602: Re-enable oscillator after suspend · 9058020c
      Lars-Peter Clausen 提交于
      Currently the the internal oscillator is powered down when entering BIAS_OFF
      state, but not re-enabled when going back to BIAS_STANDBY. As a result the
      CODEC will stop working after suspend if the internal oscillator is used to
      generate the sysclock signal. This patch fixes it by clearing the appropriate
      bit in the power down register when the CODEC is re-enabled.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Cc: stable@kernel.org
      9058020c
    • T
      VFS: Fix the remaining automounter semantics regressions · 815d405c
      Trond Myklebust 提交于
      The concensus seems to be that system calls such as stat() etc should
      not trigger an automount.  Neither should the l* versions.
      
      This patch therefore adds a LOOKUP_AUTOMOUNT flag to tag those lookups
      that _should_ trigger an automount on the last path element.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      [ Edited to leave out the cases that are already covered by LOOKUP_OPEN,
        LOOKUP_DIRECTORY and LOOKUP_CREATE - all of which also fundamentally
        force automounting for their own reasons   - Linus ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      815d405c
    • L
      vfs pathname lookup: Add LOOKUP_AUTOMOUNT flag · d94c177b
      Linus Torvalds 提交于
      Since we've now turned around and made LOOKUP_FOLLOW *not* force an
      automount, we want to add the ability to force an automount event on
      lookup even if we don't happen to have one of the other flags that force
      it implicitly (LOOKUP_OPEN, LOOKUP_DIRECTORY, LOOKUP_PARENT..)
      
      Most cases will never want to use this, since you'd normally want to
      delay automounting as long as possible, which usually implies
      LOOKUP_OPEN (when we open a file or directory, we really cannot avoid
      the automount any more).
      
      But Trond argued sufficiently forcefully that at a minimum bind mounting
      a file and quotactl will want to force the automount lookup.  Some other
      cases (like nfs_follow_remote_path()) could use it too, although
      LOOKUP_DIRECTORY would work there as well.
      
      This commit just adds the flag and logic, no users yet, though.  It also
      doesn't actually touch the LOOKUP_NO_AUTOMOUNT flag that is related, and
      was made irrelevant by the same change that made us not follow on
      LOOKUP_FOLLOW.
      
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      Cc: Ian Kent <raven@themaw.net>
      Cc: Jeff Layton <jlayton@redhat.com>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Greg KH <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d94c177b
新手
引导
客服 返回
顶部