If the tape device isn't manually assigned via the /proc
interface, the driver only assigns the tape device to the system
while the device is in use (open). So while the device isn't in use
it might be used by any other system that shares the tape
device.
The 3480/90 tape driver is unable to detect manual operations
on the tape device, in particular manual tape unloads, and these
operations will lead to errors in reading and writing. The driver
provides ioctl functions to control the device and these must be
used, either through the API or by using the Linux mt
utility.
The sequence of the
parameters as well as the separator used in the module- and kernel
parameter line has changed. Please refer to the "Device Drivers and
Installation Commands" manual in the Documentation section.
Detachment in VM of a device still open or mounted in Linux may
trigger a limitation in the Linux kernel 2.4 common code and cause
the system to hang or crash.
After detaching the DASD device, you must disable the device
using:
echo -n "set <devno> off" >> /proc/dasd/devices
before attaching the device again, to avoid crashing the device
driver.
zIPL does not work with diag access to VM minidisks.
fdasd expects more than one entry in the config file of the -c
option.
Note that running DASDFMT occupies 1 channel path which may
affect your IO performance.
Note that the dasdfmt utility can only format volumes
containing a standard record zero on all tracks. If your disk does
not fulfill this requirement (for example if you re-use an old
volume, or access a brand new disk or one having an unknown
history), you should additionally use a device support facility
such as ICKDSF (in z/OS, OS/390, z/VM, VSE/ESA or stand-alone)
before doing the dasdfmt for the low-level format.
The DASD device driver does not support Parallel Access Volumes
(PAV), neither static nor dynamic.
31-bit Linux, only: The size of any swap device or file may not
exceed 2GB. Similarly, the limit for the main memory that can be
defined is slightly less than 2GB.
There are some limitations to the current
implementation and some precautions you should take in using it.
These are:
You can only partition ECKD disks formatted with the new disk
layout (dasdfmt option -d cdl ).
No more than three partitions can be created on any one
physical volume. This restriction is a result of the scheme of
allocating Linux major and minor numbers to the partitions.
(Increasing the number of partitions per DASD would drastically
reduce the number of DASD that could be mounted in a system).
You are advised to use fdasd to create or alter
partitions as it checks for errors. If you use another partition
editor it is your responsibility to ensure that partitions do not
overlap. If they do, data corruption will occur.
To avoid wasting disk space you should leave no gaps between
adjacent partitions. Gaps are not reported as errors, but a gap can
only be reclaimed by deleting and recreating one or other of the
surrounding partitions and rebuilding the file system on it.
A disk need not be partitioned completely. You may begin by
creating only one or two partitions at the start of your disk and
convert the remaining space to a partition later (perhaps when
performance measurements have given you a better value for the
blocksize).
There is no facility for moving, enlarging or reducing
partitions as fdasd has no control over the file system on
the partition. You only can delete and recreate them. If you change
your partition table you will lose the data in all altered
partitions. It is up to you to preserve the data by copying it to
another medium.
The following is
technically not a restriction of dasdfmt , since formatting
interruptions are detected and the device is reset to the "active,
not formatted" state. Nevertheless, it could happen that a disk
goes into the "accepted" state, and the following procedure can be
used to remedy this situation.
During the formatting process the DASD is placed in a temporary
'accepted' state. If it is left in this state (for example if
DASDFMT is interrupted) the DASD cannot be accessed. You can check
the state of a DASD by entering:
#cat /proc/dasd/devices
If you see "accepted" in the output the corresponding DASD is
disabled and not available for use. You can re-enable the DASD with
the command:
#echo 'set <devno> on '>/proc/dasd/devices
where <devno> is the device number of the DASD you want to
enable. Example:
#cat /proc/dasd/devices
0700(ECKD)at (94:0)is dasda:active at blocksize:4096,601020 blocks,2347MB
0800(ECKD)at (94:4)is dasdb:active at blocksize:4096,601020 blocks,2347MB
0900(ECKD)at (94:8)is dasdc:accepted
Disk 900 is in the accepted state and cannot be formatted with the
dasdfmt command.
#echo 'set 900 on'>/proc/dasd/devices
enables the disk and changes its state to "active, not formatted".
#cat /proc/dasd/devices
0700(ECKD)at (94:0)is dasda:active at blocksize:4096,601020 blocks,2347MB
0800(ECKD)at (94:4)is dasdb:active at blocksize:4096,601020 blocks,2347MB
0900(ECKD)at (94:8)is dasdc:active n/f
#
The zfcp driver provides some technical data about the fabric,
the connections, the target devices, etc., and their capabilities
and configurations. Due to the vast number of possible
combinations, it is not possible to provide all relevant
information. It is the obligation of the fabric maintainer to
gather all additional important information by other means, such as
manufacturers' data and network management tools. This also
encompasses high-integrity fabrics.
If access to a device is lost although it is currently mounted,
a limitation of the Linux 2.6 code may be triggered which causes the
kernel to hang or to crash. It is recommended to use a multi-pathing
setup.
Address mappings issued to zfcp currently cannot be removed "on
the fly". The recommended way to change existing address mappings
is to reload the zfcp module. This implies disruption and restart
of SCSI operation of a particular Linux instance.
Error recovery by the Linux SCSI stack on a (virtual) FCP
adapter may impact ongoing SCSI traffic to other devices attached
to the same adapter. Therefore, it is recommended to use a unique
(virtual) FCP adapter (unique zSeries device number, see
/proc/subchannels ) to isolate a device from other SAN traffic. In
particular, this applies to tape devices.
In case of non-recoverable errors (e.g., temporary adapter
failure, low-level data loss on the fiber), zfcp uses the host
return codes ("host_byte") provided by the Linux SCSI stack (see
drivers/scsi/scsi.h ) to indicate these error conditions to upper
layer drivers. In particular, low-level errors can be disruptive to
the SCSI traffic of devices which do not allow retries (e.g., tape
read/write commands). It is recommended to the upper layer driver
to try to recover these conditions, or just to return I/O error to
the application. In case of a high frequency of host return codes,
please check your SAN equipment (firmware etc.).
To be able to send the SCSI command REPORT LUNS, an internal
representation is needed for FC LUN X'0' for the target port. If an
FC LUN X'0' is not configured within zfcp for a target port for
which the HBA API function HBA_SendReportLUNs() is called, an
internal representation for FC LUN X'0' for this target port is
created within zfcp. After that no mapping with FC LUN X'0' can be
added for the same target port to module zfcp.
The zfcp HBA API support is only available on IBM eServer
zSeries 990 and 890 mainframes with a microcode level (MCL) that includes
the enhancements of October 31, 2003. Please ensure to use the
latest available microcode level.
Emulated 3172-001 lcs
devices on MP3000 do not autodetect correctly, it is advised that
you force these devices using
lcs0,<read_devno>,<write_devno>,0,<port_no>
using the channel device layer.
Real 3172-001's may need a delay
between detection and starting up the device. Otherwise, the device
will not start up properly owing to a possible microcode problem.
Best workaround:
Load the lcs module a few seconds before the interface will be
configured up, for example: remove the entry for the lcs module in
/etc/modules.conf
append "insmod lcs" to the end of /etc/rc.sysinit
Alternate workaround:
Perform an ifconfig tr0 down and ifconfig tr0 up a few seconds
after the lcs module was loaded.
To use OSA devices when running
Linux for zSeries on a basic mode machine (no LPARs) you may need
to specify an ipldelay=xyz boot parameter. We recommend a value
between 2m and 5m for xyz for the OSA card to initialize fully
after IPL.
With current microcode the following restrictions apply:
When running Linux on zSeries in LPAR mode, re-booting from a
SCSI device does not work.
The following restrictions do no longer apply with MCL J12221.003
(zSeries 990 and 890) and MCL J12811.003 (zSeries 800, 900):
When running a 64-bit Linux on zSeries in LPAR mode with more
than 2GB LPAR memory, a SCSI dump may contain an invalid
PSW.
ESA/390 mode dumps may be invalid because of wrong prefix
register values. To read such a dump with the dump analysis tool
lcrash the '-f ' option can be used.
HiperSockets Network Concentrator simplifies network addressing
between HiperSockets and OSA-Express allowing seamless integration
of HiperSockets-connected operating systems into external
networks.
The kernel can be configured
both with and without the channel device layer. However, the qeth
module only works in kernels built with the channel device layer
switched on. CTC and LCS also work in kernels built without the
channel device layer. For details on the configuration, please see
the "Device Drivers and Installation" manual in the Documentation section.
ucd-snmp 4.2.x does not run properly on Linux for
zSeries(64-bit). An additional patch is needed to enable snmpd on
Linux for zSeries(64-bit). You will find the required patch at
"http://sourceforge.net/projects/net-snmp" in the patch section.
Check for title summary "enable ucd-snmp 4.2.x for 64-bit (s390x)".
Apply the patch against the ucd-snmp source tarball (e.g.
ucd-snmp-4.2.5.tar.gz). You can download the ucd-snmp source
tarball from the download section at
"http://net-snmp.sourceforge.net/" . Then compile and install the
package as usual.
at least OSA-E microcode level 3.0A is required.
Only OSD CHPIDs are supported.
Current MIBs do not contain any writable objects.
SNMP traps are not yet supported.
To use OSA-Express Direct SNMP on all z990 OSA-levels, as well
as z800/z900 OSA-levels starting with 3.33 (Driver 3G, EC stream
J11204, MCL032; see also
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/FLASH10250),
both the linux-2.4.21-s390-06-june2003.tar.gz kernel patch and
s390-tools version 1.2.2 are needed.
If you have a PCICC only, or are attempting to use a CRT key on
a system with PCIXCC only, you need to ensure that your data is
PKCS-1.2 padded. If you have a PCICA, or are only using Mod-Expo
keys with a PCIXCC card you do not need to ensure PKCS-1.2 padding.
See z90crypt.h for a more thorough discussion of the
requirements.
PCICC is not supported on the IBM eServer zSeries 990 (z990)
hardware.
VM hides PCICCs and PCIXCCs from its guests if a PCICA is also
available.
PCIXCC is detected, but ignored when running under z90crypt
versions earlier than 1.2.1.
PCIXCC is only available for z990 as "PCIX Cryptographic
Coprocessor (PCIXCC) feature (#0868)".
PCIXCC cards are currently not supported for VM guests.
s390-tools 1.2.x are only tested with the kernels of
"May 2002 stream" and "June 2003 stream".
Because of missing kernel-interfaces the following s390-tools from
1.2.x will definitely not work with the "August 2001 stream":
start_hsnc/ip-watcher, osasnmpd, qetharp and qethconf.
Note that bug-fixes and enhancements for s390-tools 1.2.x
are provided in s390-tools 1.2.(x+1) and will not be provided
as patches against 1.2.x.
Do not use the ext3
filesystem with an external journal (on another partition or
volume) having another size than the default size. This
configuration is currently failing on S/390 and zSeries as well as
on xSeries (Intel) due to a problem in the open source journaling
file system code.
As of linux-2.4.21-s390-06-june2003.tar.gz, using broadcast in
VM Guest LAN requires APAR VM63397.
Multicasting has to be switched on in the kernel
configuration.
The OSA Express Driver needs QDIO base support.
On OSA-Express querying the ARP cache (qetharp -q) only returns
a maximum of 62 entries, even though more entries might exist in a
device's ARP cache.
HiperSockets do not provide broadcast functionality except on
z990.
Not all levels of OSA-Express microcode support broadcast
functionality; broadcast is available starting with level 3.0A.
OSA-2 supports broadcasts.
The MTU range is 576 - 61440. However, depending on the medium
and networking hardware settings, it may be restricted to 1492,
1500, 8992 or 9000. For HiperSockets the MTU range extends to
57344. This may be restricted by the framesize announced by the
microcode.
The maximum MTU size is limited by the value of the
memory_usage_in_k parameter, which, together with the maximum frame
(buffer) size, determines the number of buffers. The frame size for
OSA-Express is fixed at 64 KB. For HiperSockets, the maximum frame
size is defined during HiperSockets CHPID definition in the IOCDS.
If the hardware configuration specifies the maximum frame size as
40 KB, the MTU can be configured up to 32 KB (frame size minus 8
KB) using ifconfig. Possible frame sizes are 16, 24, 40, and 64 KB.
The total memory usage is
(number of buffers) * (Linux memory usage per buffer)
The Linux memory usage per buffer is 16 KB for frame size 16 KB, 32
KB for frame size 24 KB, and 64 KB for frame sizes 40 and 64 KB.
Linux will calculate the number of buffers from the total memory
usage given in the chandev statement (where the number of buffers
is <=128 and >=16. If a parameter is too high, Linux will
allocate 128 buffers of 64 KB each.
There is a restriction in Linux that the packet size of a
multicast packet cannot be greater than the MTU size of the
interface used.
There may be circumstances that prevent ifconfig (or
other commands) from setting an IP address on an OSA-Express
network feature. The most common one is that another system in the
network has set that IP address already. As a result, the IP
address will be indicated by ifconfig as being set on the
interface, but the address is not actually set on the feature.
Since the design of the network stack in Linux does not allow
feedback about IP address changes, there is no means of notifying
the user of the problem other than to log a message. This message
(usually containing text such as "could not set IP address" or
"duplicate IP address") will appear in the kernel messages
(displayable using "dmesg"). For most distribution settings, this
will also trigger a message in /var/log/messages. If you are not
sure whether the IP address was set properly or experience a
networking problem, you should always check these logs to see if an
error was encountered when setting the address.
This requirement applies to both IPv4 and IPv6 addresses, and to IP
takeover, VIPA, HiperSockets, and Proxy ARP.
MAC addresses of VM Guest LAN devices will not be displayed
correctly, until PTF UM30652 (only applies to z/VM 4.3.0) is
installed.
When
using MTU sizes >8K on a network interface, the Linux TCP/IP
stack may run into problems on heavily loaded systems because
allocating memory for packets may fail due to memory fragmentation.
As a symptom of this problem you will see messages of the form
"order-N allocation failed" in the system log; in addition, network
connections will drop packets, in extreme cases to the extent that
the network is no longer usable.
As a workaround, use MTU sizes at
most of 8K (minus header size), even if the network hardware allows
larger sizes (e.g. HiperSockets, gigabit ethernet).
