1. 11 12月, 2008 5 次提交
  2. 10 12月, 2008 3 次提交
    • S
      firewire: fw-ohci: fix IOMMU resource exhaustion · 1d1dc5e8
      Stefan Richter 提交于
      There is a DMA map/ unmap imbalance whenever a block write request
      packet is sent and then dequeued with ohci_cancel_packet.  The latter
      may happen frequently if the AR resp tasklet is executed before the AT
      req tasklet for the same transaction.
      
      Add the missing dma_unmap_single.  This fixes
      https://bugzilla.redhat.com/show_bug.cgi?id=475156
      
      Reported-by: Emmanuel Kowalski
      Tested-by: Emmanuel Kowalski
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      1d1dc5e8
    • N
      ieee1394: node manager causes up to ~3.25s delay in freezing tasks · ec9a13cd
      Nigel Cunningham 提交于
      The firewire nodemanager function "nodemgr_host_thread" contains a loop
      that calls try_to_freeze near the top of the loop, but then delays for
      up to 3.25 seconds (plus time to do work) before getting back to the top
      of the loop. When starting a cycle post-boot, this doesn't seem to bite,
      but it is causing a noticeable delay at boot time, when freezing
      processes prior to starting to read the image.
      
      The following patch adds invocation of try_to_freeze to the subloops
      that are used in the body of this function. With these additions, the
      time to freeze when starting to resume at boot time is virtually zero.
      I'm no expert on firewire, and so don't know that we shouldn't check
      the return value and jump back to the top of the loop or such like after
      being frozen, but I submit it for your consideration.
      Signed-off-by: NNigel Cunningham <nigel@tuxonice.net>
      
      The delay until nodemgr freezes was up to 0.25s (plus time for node
      probes) in Linux 2.6.27 and older and up to 3.25s (plus ~) since Linux
      2.6.28-rc1, hence much more noticeable.
      
      try_to_freeze() without any jump is correct.  The surrounding code in
      the respective loops will catch whether another bus reset happens during
      the freeze and handle it.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      ec9a13cd
    • B
      radeonfb: Disable new color expand acceleration unless explicitely enabled · f3179748
      Benjamin Herrenschmidt 提交于
      This new color expansion acceleration for radeonfb appears to trigger
      problems with X on VT switch and suspend/resume on some machines. It
      might be a problem in the VT layer or in X, but I haven't quite found
      it yet, so in the meantime, this disables the acceleration by default,
      reverting to 2.6.27 state. It can be enabled using the "accel_cexp"
      module parameter or fbdev argument.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f3179748
  3. 09 12月, 2008 10 次提交
  4. 06 12月, 2008 4 次提交
  5. 05 12月, 2008 4 次提交
  6. 04 12月, 2008 14 次提交