1. 27 9月, 2007 1 次提交
  2. 26 9月, 2007 9 次提交
  3. 25 9月, 2007 8 次提交
  4. 24 9月, 2007 1 次提交
    • J
      IB/mlx4: Fix data corruption triggered by wrong headroom marking order · 6e694ea3
      Jack Morgenstein 提交于
      This is an addendum to commit 0e6e7416 ("IB/mlx4: Handle new FW
      requirement for send request prefetching").  We also need to handle
      prefetch marking properly for S/G segments, or else the HCA may end up
      processing S/G segments that are not fully written and end up sending
      the wrong data.  This can actually cause data corruption in practice,
      especially on systems with relatively slow CPUs (where the HCA is more
      likely to prefetch while the CPU is in the middle of writing a work
      request into memory).
      
      We write S/G segments in reverse order into the WQE, in order to
      guarantee that the first dword of all cachelines containing S/G
      segments is written last (overwriting the headroom invalidation
      pattern).  The entire cacheline will thus contain valid data when the
      invalidation pattern is overwritten.
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      6e694ea3
  5. 23 9月, 2007 2 次提交
    • T
      ACPI: disable lower idle C-states across suspend/resume · b04e7bdb
      Thomas Gleixner 提交于
      device_suspend() calls ACPI suspend functions, which seems to have undesired
      side effects on lower idle C-states. It took me some time to realize that
      especially the VAIO BIOSes (both Andrews jinxed UP and my elfstruck SMP one)
      show this effect. I'm quite sure that other bug reports against suspend/resume
      about turning the system into a brick have the same root cause.
      
      After fishing in the dark for quite some time, I realized that removing the ACPI
      processor module before suspend (this removes the lower C-state functionality)
      made the problem disappear. Interestingly enough the propability of having a
      bricked box is influenced by various factors (interrupts, size of the ram image,
      ...). Even adding a bunch of printks in the wrong places made the problem go
      away. The previous periodic tick implementation simply pampered over the
      problem, which explains why the dyntick / clockevents changes made this more
      prominent.
      
      We avoid complex functionality during the boot process and we have to do the
      same during suspend/resume. It is a similar scenario and equaly fragile.
      
      Add suspend / resume functions to the ACPI processor code and disable the lower
      idle C-states across suspend/resume. Fall back to the default idle
      implementation (halt) instead.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NAndrew Morton <akpm@linux-foundation.org>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b04e7bdb
    • A
      KVM: Fix virtualization menu help text · 36a74097
      Avi Kivity 提交于
      What guest drivers?
      
      Cc: Jan Engelhardt <jengelh@computergmbh.de>
      Signed-off-by: NAvi Kivity <avi@qumranet.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      36a74097
  6. 22 9月, 2007 2 次提交
  7. 21 9月, 2007 17 次提交