Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 27 4月, 2007 7 次提交
  3. 06 2月, 2007 5 次提交
  5. 08 12月, 2006 1 次提交
  7. 04 12月, 2006 3 次提交
    • C
      [S390] cio: Retry internal operations after vary off. · d23861ff
      由 Cornelia Huck 提交于 
      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: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      d23861ff
    • C
      [S390] cio: Use path verification for last path gone after vary off. · 24cb5b48
      由 Cornelia Huck 提交于 
      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: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      24cb5b48
    • H
      [S390] Reset infrastructure for re-IPL. · 15e9b586
      由 Heiko Carstens 提交于 
      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: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      15e9b586
  9. 11 10月, 2006 2 次提交
  11. 06 10月, 2006 1 次提交
  13. 20 9月, 2006 2 次提交
  15. 30 8月, 2006 2 次提交
  17. 12 7月, 2006 1 次提交
    • C
      [S390] path grouping and path verifications fixes. · 7e560814
      由 Cornelia Huck 提交于 
      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
   supported.
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: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      7e560814
  19. 01 7月, 2006 1 次提交
  21. 29 6月, 2006 2 次提交
  23. 28 4月, 2006 2 次提交
  25. 24 3月, 2006 2 次提交
  27. 07 3月, 2006 1 次提交
  29. 12 2月, 2006 1 次提交
  31. 02 2月, 2006 1 次提交
  33. 15 1月, 2006 1 次提交
  35. 07 1月, 2006 4 次提交
  37. 28 7月, 2005 1 次提交