1. 17 Jul, 2008 1 commit
  2. 14 Jul, 2008 5 commits
  3. 16 Apr, 2008 2 commits
  4. 05 Feb, 2008 1 commit
  5. 26 Jan, 2008 4 commits
  6. 27 Jul, 2007 2 commits
  7. 27 Apr, 2007 8 commits
  8. 05 Feb, 2007 5 commits
  9. 08 Dec, 2006 1 commit
  10. 04 Dec, 2006 3 commits
    • Cornelia Huck's avatar
      [S390] cio: Retry internal operations after vary off. · d23861ff
      Cornelia Huck authored
      If I/O was running on a just varied off chpid, it will be terminated.
      If this was a common I/O layer internal I/O, it needs to be retried.
      Signed-off-by: default avatarCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
    • Cornelia Huck's avatar
      [S390] cio: Use path verification for last path gone after vary off. · 24cb5b48
      Cornelia Huck authored
      If the last path to a device is gone after a chpid has been varied
      off, putting it on the slow queue doesn't prevent a device driver
      from still attempting to use it (it may stay on the slow queue for a
      long time). Instead, trigger a verify event which will prevent I/O
      attempts from the device driver immediately.
      Signed-off-by: default avatarCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
    • Heiko Carstens's avatar
      [S390] Reset infrastructure for re-IPL. · 15e9b586
      Heiko Carstens authored
      In case of re-IPL and diag308 doesn't work we have to reset all devices
      manually and wait synchronously that each reset finished.
      This patch adds the necessary infrastucture and the first exploiter of it.
      Subsystems that need to add a function that needs to be called at re-IPL
      may register/unregister this function via
      struct reset_call {
      	struct reset_call *next;
      	void (*fn)(void);
      void register_reset_call(struct reset_call *reset);
      void unregister_reset_call(struct reset_call *reset);
      When the registered function get called the context is:
      - all cpus beside the current one are stopped
      - all machine checks and interrupts are disabled
      - prefixing is disabled
      - a default machine check handler is available for use
      The registered functions may not take any locks are sleep.
      For the common I/O layer part of this patch:
      Introduce a reset_call css_reset that does the following:
      - clear all subchannels
      - perform a rchp on all channel paths and wait for the resulting
        machine checks
      This replaces the calls to clear_all_subchannels() and
      cio_reset_channel_paths() for kexec and ccw reipl. reipl_ccw_dev() now
      uses reipl_find_schid() to determine the subchannel id for a given
      device id.
      Also remove cio_reset_channel_paths() and friends since they are not
      needed anymore.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
  11. 11 Oct, 2006 2 commits
  12. 06 Oct, 2006 1 commit
  13. 20 Sep, 2006 2 commits
  14. 30 Aug, 2006 2 commits
  15. 12 Jul, 2006 1 commit
    • Cornelia Huck's avatar
      [S390] path grouping and path verifications fixes. · 7e560814
      Cornelia Huck authored
      1. Multipath devices for which SetPGID is not supported are not handled well.
         Use NOP ccws for path verification (sans path grouping) when SetPGID is not
      2. Check for PGIDs already set with SensePGID on _all_ paths (not just the
         first one) and try to find a common one. Moan if no common PGID can be
         found (and use NOP verification). If no PGIDs have been set, use the css
         global PGID (as before). (Rationale: SetPGID will get a command reject if
         the PGID it tries to set does not match the already set PGID.)
      3. Immediately before reboot, issue RESET CHANNEL PATH (rcp) on all chpids. This
         will remove the old PGIDs. rcp will generate solicited CRWs which can be
         savely ignored by the machine check handler (all other actions create
         unsolicited CRWs).
      Signed-off-by: default avatarCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>