1. 13 10月, 2005 6 次提交
  2. 12 10月, 2005 14 次提交
  3. 11 10月, 2005 17 次提交
  4. 10 10月, 2005 3 次提交
    • M
      [PATCH] i386: fix stack alignment for signal handlers · d347f372
      Markus F.X.J. Oberhumer 提交于
      This fixes the setup of the alignment of the signal frame, so that all
      signal handlers are run with a properly aligned stack frame.
      
      The current code "over-aligns" the stack pointer so that the stack frame
      is effectively always mis-aligned by 4 bytes.  But what we really want
      is that on function entry ((sp + 4) & 15) == 0, which matches what would
      happen if the stack were aligned before a "call" instruction.
      Signed-off-by: NMarkus F.X.J. Oberhumer <markus@oberhumer.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d347f372
    • B
      [PATCH] ide: Workaround PM problem · 867f8b4e
      Benjamin Herrenschmidt 提交于
      The logic in ide_do_request() doesn't guarantee that both drives will be
      serviced after a call.  It may "forget" to service one in some
      circumstances, including when one of the drive is suspended (it will
      eventually fail to service the slave when the master is suspended for
      example).  This prevents the wakeup requests that gets queued on wakeup
      from sleep from beeing serviced in some cases when 2 drives are sharing
      an IDE bus.
      
      The problem is deep enough in the way this code works (and there are
      probably a few other problematic but rare corner cases) and fixing it
      would require some major rethinking of the way IDE decides which channel
      to service.  This is not 2.6.14 material.  However, in the meantime,
      Bart has accepted this simple workaround that will fix the crash on
      wakeup from sleep since this specific corner case is actually hitting
      users to get into 2.6.14.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      867f8b4e
    • T
      [PATCH] relayfs: fix bogus param value in call to vmap · 1cc956e1
      Tom Zanussi 提交于
      The third param in this call to vmap shouldn't be GFP_KERNEL, which
      makes no sense, but rather VM_MAP.  Thanks to Al Viro for spotting
      this.
      Signed-off-by: NTom Zanussi <zanussi@us.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1cc956e1