1. 14 Mar, 2007 22 commits
  2. 13 Mar, 2007 14 commits
  3. 12 Mar, 2007 4 commits
    • Zachary Amsden's avatar
      [PATCH] Fix vmi time header bug · 2cb8a57b
      Zachary Amsden authored
      Some gcc put this function in .init.text because the header didn't
      match.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2cb8a57b
    • Zachary Amsden's avatar
      [PATCH] Fix VMI and COMPAT_VDSO for 2.6.21 · b6bc5d71
      Zachary Amsden authored
      VMI is broken under COMPAT_VDSO, as Xen and other non hardware assisted
      hypervisors will be.  I have been working on a fix for this which works
      for older glibcs that panic when the new relocatable VDSO is used.
      
      However, I believe at this time that the fix is going to be too radical
      to consider at this stage in the release of 2.6.21.  We don't expect
      this config option to be turned on by vendors for new distributions, so
      at this point we are willing to drop support for it when VMI is compiled
      in, and work on a patch for 2.6.22 which more fully addresses the
      problem.
      Signed-off-by: default avatarZachary Amsden <zach@vmware.com>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b6bc5d71
    • Eric W. Biederman's avatar
      [PATCH] pci: Repair pci_save/restore_state so we can restore one save many times. · 9f35575d
      Eric W. Biederman authored
      Because we do not reserve space for the pci-x and pci-e state in struct
      pci dev we need to dynamically allocate it.  However because we need
      to support restore being called multiple times after a single save
      it is never safe to free the buffers we have allocated to hold the
      state.
      
      So this patch modifies the save routines to first check to see
      if we have already allocated a state buffer before allocating
      a new one.  Then the restore routines are modified to not free
      the state after restoring it.  Simple and it fixes some subtle
      error path handling bugs, that are hard to test for.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: default avatarAuke Kok <auke-jan.h.kok@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9f35575d
    • Eric W. Biederman's avatar
      [PATCH] msi: Safer state caching. · 392ee1e6
      Eric W. Biederman authored
      There are two ways pci_save_state and pci_restore_state are used.  As
      helper functions during suspend/resume, and as helper functions around
      a hardware reset event.  When used as helper functions around a hardware
      reset event there is no reason to believe the calls will be paired, nor
      is there a good reason to believe that if we restore the msi state from
      before the reset that it will match the current msi state.  Since arch
      code may change the msi message without going through the driver, drivers
      currently do not have enough information to even know when to call
      pci_save_state to ensure they will have msi state in sync with the other
      kernel irq reception data structures.
      
      It turns out the solution is straight forward, cache the state in the
      existing msi data structures (not the magic pci saved things) and
      have the msi code update the cached state each time we write to the hardware.
      This means we never need to read the hardware to figure out what the hardware
      state should be.
      
      By modifying the caching in this manner we get to remove our save_state
      routines and only need to provide restore_state routines.
      
      The only fields that were at all tricky to regenerate were the msi and msi-x
      control registers and the way we regenerate them currently is a bit dependent
      upon assumptions on how we use the allow msi registers to be configured and used
      making the code a little bit brittle.  If we ever change what cases we allow
      or how we configure the msi bits we can address the fragility then.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: default avatarAuke Kok <auke-jan.h.kok@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      392ee1e6