1. 05 Aug, 2005 10 commits
    • Petr Vandrovec's avatar
      [PATCH] rtc: msleep() cannot be used from interrupt · 403fe5ae
      Petr Vandrovec authored
      Since the beginning of July my Opteron box was randomly crashing and
      being rebooted by hardware watchdog.  Today it finally did it in front
      of me, and this patch will hopefully fix it.
      
      The problem is that at the end of June (the 28th, to be exact: commit
      47f176fd, "[PATCH] Using msleep()
      instead of HZ") rtc_get_rtc_time was converted to use msleep() instead
      of busy waiting.  But rtc_get_rtc_time is used by hpet_rtc_interrupt,
      and scheduling is not allowed during interrupt.  So I'm reverting this
      part of original change, replacing msleep() back with busy loop.
      
      The original code was busy waiting for up to 20ms, but on my hardware in
      the worst case update-in-progress bit was asserted for at most 363
      passes through loop (on 2GHz dual Opteron), much less than even one
      jiffie, not even talking about 20ms.  So I changed code to just wait
      only as long as necessary.  Otherwise when RTC was set to generate
      8192Hz timer, it stopped doing anything for 20ms (160 pulses were
      skipped!) from time to time, and this is rather suboptimal as far as I
      can tell.
      Signed-off-by: default avatarPetr Vandrovec <vandrove@vc.cvut.cz>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      403fe5ae
    • Simon Derr's avatar
      [PATCH] __vm_enough_memory() signedness fix · 2f60f8d3
      Simon Derr authored
      We have found what seems to be a small bug in __vm_enough_memory() when
      sysctl_overcommit_memory is set to OVERCOMMIT_NEVER.
      
      When this bug occurs the systems fails to boot, with /sbin/init whining
      about fork() returning ENOMEM.
      
      We hunted down the problem to this:
      
      The deferred update mecanism used in vm_acct_memory(), on a SMP system,
      allows the vm_committed_space counter to have a negative value.
      
      This should not be a problem since this counter is known to be inaccurate.
      
      But in __vm_enough_memory() this counter is compared to the `allowed'
      variable, which is an unsigned long.  This comparison is broken since it
      will consider the negative values of vm_committed_space to be huge positive
      values, resulting in a memory allocation failure.
      
      Signed-off-by: <Jean-Marc.Saffroy@ext.bull.net>
      Signed-off-by: <Simon.Derr@bull.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      2f60f8d3
    • Herbert Xu's avatar
      [PATCH] tcp: fix TSO cwnd caching bug · b68e9f85
      Herbert Xu authored
      tcp_write_xmit caches the cwnd value indirectly in cwnd_quota.  When
      tcp_transmit_skb reduces the cwnd because of tcp_enter_cwr, the cached
      value becomes invalid.
      
      This patch ensures that the cwnd value is always reread after each
      tcp_transmit_skb call.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b68e9f85
    • David S. Miller's avatar
      [PATCH] tcp: fix TSO sizing bugs · 846998ae
      David S. Miller authored
      MSS changes can be lost since we preemptively initialize the tso_segs count
      for an SKB before we %100 commit to sending it out.
      
      So, by the time we send it out, the tso_size information can be stale due
      to PMTU events.  This mucks up all of the logic in our send engine, and can
      even result in the BUG() triggering in tcp_tso_should_defer().
      
      Another problem we have is that we're storing the tp->mss_cache, not the
      SACK block normalized MSS, as the tso_size.  That's wrong too.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      846998ae
    • John McCutchan's avatar
      [PATCH] Clean up inotify delete race fix · 0c3dba15
      John McCutchan authored
      This avoids the whole #ifdef mess by just getting a copy of
      dentry->d_inode before d_delete is called - that makes the codepaths the
      same for the INOTIFY/DNOTIFY cases as for the regular no-notify case.
      I've been running this under a Gnome session for the last 10 minutes.
      Inotify is being used extensively.
      Signed-off-by: default avatarJohn McCutchan <ttb@tentacle.dhs.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      0c3dba15
    • Olav Kongas's avatar
      [PATCH] USB: Fix setup packet initialization in isp116x-hcd · f10eff26
      Olav Kongas authored
      When recently addressing remarks by Alexey Dobriyan about
      the isp116x-hcd, I introduced a bug in the driver. Please
      apply the attached patch to fix it.
      Signed-off-by: default avatarOlav Kongas <ok@artecdesign.ee>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f10eff26
    • David Brownell's avatar
      [PATCH] USB: ehci: microframe handling fix · 7dedacf4
      David Brownell authored
      This patch has a one line oops fix, plus related cleanups.
      
       - The bugfix uses microframe scheduling data given to the hardware to
         test "is this a periodic QH", rather than testing for nonzero period.
         (Prevents an oops by providing the correct answer.)
      
       - The cleanup going along with the patch should make it clearer what's
         going on whenever those bitfields are accessed.
      
      The bug came about when, around January, two new kinds of EHCI interrupt
      scheduling operation were added, involving both the high speed (24 KBytes
      per millisec) and low/full speed (1-64 bytes per millisec) microframe
      scheduling.  A driver for the Edirol UA-1000 Audio Capture Unit ran into
      the oops; it used one of the newly supported high speed modes.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      7dedacf4
    • Pete Zaitcev's avatar
      [PATCH] USB: ub documentation update · 003ba515
      Pete Zaitcev authored
      The patch which went in was correct, but not quite what I had in mind.
      Here is a patch to update that a little bit. Original patch is at:
       http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4749f32da939d4e4160541b2cadc22492bb507ecSigned-off-by: default avatarPete Zaitcev <zaitcev@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      003ba515
    • Dominik Brodowski's avatar
      [PATCH] pci and yenta: pcibios_bus_to_resource · 43c34735
      Dominik Brodowski authored
      In yenta_socket, we default to using the resource setting of the CardBus
      bridge.  However, this is a PCI-bus-centric view of resources and thus needs
      to be converted to generic resources first.  Therefore, add a call to
      pcibios_bus_to_resource() call in between.  This function is a mere wrapper on
      x86 and friends, however on some others it already exists, is added in this
      patch (alpha, arm, ppc, ppc64) or still needs to be provided (parisc -- where
      is its pcibios_resource_to_bus() ?).
      Signed-off-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      43c34735
    • John W. Linville's avatar
      [PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it · fec59a71
      John W. Linville authored
      Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration
      (including BARs) when transitioning from D3hot->D0.  This leaves such
      a device in an inaccessible state.  The patch below causes the BARs
      to be restored when enabling such a device, so that its driver will
      be able to access it.
      
      The patch also adds pci_restore_bars as a new global symbol, and adds a
      correpsonding EXPORT_SYMBOL_GPL for that.
      
      Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a
      (re)boot.  Most drivers call pci_enable_device very early, so devices
      left in D3hot that lose configuration during the D3hot->D0 transition
      will be inaccessible to their drivers.
      
      Drivers could be modified to account for this, but it would
      be difficult to know which drivers need modification.  This is
      especially true since often many devices are covered by the same
      driver.  It likely would be necessary to replicate code across dozens
      of drivers.
      
      The patch below should trigger only when transitioning from D3hot->D0
      (or at boot), and only for devices that have the "no soft reset" bit
      cleared in the PM control register.  I believe it is safe to include
      this patch as part of the PCI infrastructure.
      
      The cleanest implementation of pci_restore_bars was to call
      pci_update_resource.  Unfortunately, that does not currently exist
      for the sparc64 architecture.  The patch below includes a null
      implemenation of pci_update_resource for sparc64.
      
      Some have expressed interest in making general use of the the
      pci_restore_bars function, so that has been exported to GPL licensed
      modules.
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      fec59a71
  2. 04 Aug, 2005 30 commits