This can be helpful in diagnosing network-related issues.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The basic statistics are already collected via ifconfig. But that tool
is deprecated, and provides no way of collecting the extended stats.
So also gather data from 'ip link'.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This patch adds ethtool commands for network interfaces.
Especially the offload settings are important.
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This patch adds the base lspci command to list pci devices
and the smc_dbg command from the smc-tools package to show
SMC socket related information.
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Function get_payload_records() reading from disk, blindly adds payload
record (junks) to a list in a 2-stage hierarchical hash keyed with
request ID and PAY area.
On adapter offline/online, zfcp resets the request ID to re-start with 1.
Hence it's not a unique foreign key in the lifetime of the PAY area.
The last payload record (junks) read for the same request ID and PAY area
is the one printed as named PAY field in the tool output.
This is not necessarily the chronologically last record due to PAY area
wrapping.
With this workaround, we:
* warn on reading PAY records if ambiguous entries occurred,
* print additional PAY timestamps which the user can compare
with the actual trace record timestamps to determine if they are close
enough to indicate a match.
We only found this by accident because we kept "short" "payload" being a
built-in part of some actual trace record types in areas HBA, SAN, SCSI.
For above cases, the full PAYload did not match the
built-in "short" "payload".
While at it, also add a comment that PAY output can also be wrong
in another case when junks of multi-part PAY records are missing due
to PAY area wrapping.
Below is an abbreviated example output with this workaround:
Loading trace records ...(this might take a while)
Warning: Ambiguous PAYload records. reqid:0000000000000037 area:san_res
...
Timestamp : 2017-07-07-18:01:34:574827
Area : SAN
...
Tag : fssct_1
Request ID : 0x0000000000000037
Destination ID : 0x00fffffc
SAN req short : 01000000 fc020000 01720ffc 00000000
00000008
SAN req length : 20
Timestamp : 2017-07-07-18:01:34:619310 ------------------+
Area : SAN |
... |
Tag : fsscth2 |
Request ID : 0x0000000000000037 |
Destination ID : 0x00fffffc |
SAN resp short : 01000000 fc020000 80020000 00000000 |
00671a07 00000000 c05076ff d6801850 |
00671a7e 00000000 c05076ff d6801968 |
SAN resp length: 16384 |
Payload time : 2017-07-07-18:16:17:165708 <== does not match
San resp info : 01000000 fc020000 80020000 00000000 <== wrong
4a49424d 20202020 20323936 34202020 <== wrong
20202020 20202020 20303230 30303030 <== wrong
30303745 43383720 20504348 49443a20 <== wrong
30313938 204e5049 5620556c 7049643a <== wrong
20303536 30303330 30202020 00000000 <== wrong
00000000 00000000 00000000 00000000 <== wrong
... <== wrong
...
Timestamp : 2017-07-07-18:16:17:165713
Area : SAN
...
Tag : fsscth2
Request ID : 0x0000000000000037 <== same reqid & pay "area"
Destination ID : 0x00fffffc
SAN resp short : 01000000 fc020000 80020000 00000000
4a49424d 20202020 20323936 34202020
20202020 20202020 20303230 30303030
SAN resp length: 273
Payload time : 2017-07-07-18:16:17:165708 <== 2nd & last, match
close to Timestamp
San resp info : 01000000 fc020000 80020000 00000000
4a49424d 20202020 20323936 34202020
20202020 20202020 20303230 30303030
30303745 43383720 20504348 49443a20
30313938 204e5049 5620556c 7049643a
20303536 30303330 30202020 00000000
00000000 00000000 00000000 00000000
...
Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
GCC8 shows the following compile warning:
cmsfs-fuse.c: In function ‘convert_text’:
cmsfs-fuse.c:2558:19: warning: passing argument 2 to restrict-qualified
parameter aliases with argument 4 [-Wrestrict]
rc = iconv(conv, &data_ptr, &in_count, &data_ptr, &out_count);
^~~~~~~~~ ~~~~~~~~~
Fix this by using a separate buffer for iconv. The buffer size depends on
the record format: variable-length records have a maximum length of
MAX_RECORD_LEN (plus 1 byte for linefeed), while fixed-length records
could be larger in theory. This patch takes that into account for the iconv
buffer, but the rest of the code currently cannot handle fixed-length records
larger than MAX_RECORD_LEN.
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Reviewed-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add the missing identifiers to report the card name and link speed.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The IPAPPEND option in the pxelinux config file can be used
to pass information about the boot interface to the booted
Linux kernel.
The support for this option was missing and could lead to
installation failures, e.g. using kickstart.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Client architecture aware DHCP configurations may send a
bootfile for the wrong architecture, if the DHCP request
doesn't include the client architecture identifier 0x001f.
Further, the DHCP reply may include the pxepathprefix option,
which points to the base directory to use for TFT requests.
If the value is not honored by the client, the wrong
configuration file, kernel, etc. could be loaded.
Both issues are fixed by this commit.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Compressed kernel modules (filename *.ko.xz) would not be included
since the script was looking for files with .ko suffix only.
This can result in a pxelinux.0 image that can't access the
network, which is not good for a network boot loader...
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The output of /proc/<pid>/stat will show the process name in parentheses.
The parsing code in read_stat() tries to filter out the parentheses, which
will go wrong when the process name itself also contains parentheses, e.g.
in an output like this: "2421 ((sd-pam)) S 2420 2420 2420 ..."
In this case, the first closing parentheses will be taken as end marker,
and the sscanf() on the remaining string will silently fail, leaving its
values in uninitialized state and producing wrong data.
Fix this by using strrchr() instead of strchr() to find the last closing
parentheses. Also add return value checking for sscanf() and initialize the
values to 0.
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
lsluns lists nothing and returns with return code 0 if no adapter (FCP
device) or target port exists in sysfs. This can be confusing for the user.
Print a message if no adapter exists. Print a message if no port exists on
any adapter.
Reported-by: Thorsten Diehl <thorsten.diehl@de.ibm.com>
Suggested-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
hmcdrvfs will ignore files with a link count >= 1000, due to an inconsistency
in the input data. The parsing code relies on having spaces between the
different fields in its input data. When a file has a link count >= 1000,
there will be no space, and the "link count" field will be placed directly
after the previous "mode" field. This will confuse the parser, and all such
files will not be accesible.
The "mode" field will never contain digits, so in order to fix this issue,
the parser can recognize the "link count" field by the presence of a digit.
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When calculating partition start offset during multi-volume dump processing,
the result of multiplication is truncated to 32-bits thus resulting in
invalid behavior in case the real offset is beyond 4Gig boundary.
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.vnet.ibm.com>
Reviewed-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Jan Höppner