Re: Hercules Bus Error
On Tue, 18 Feb 2014 21:14:53 -0500 (EST), David Clements wrote:
>
> I have been doing a lot of qeth testing both layer2 and layer3 and
> have run into a problem when using the iface parameter on the qeth
> definition.
> ...
I admit that I don't understand all that you have written. For one thing,
I'm using the version of Hercules that is packaged for Debian, which
is release 3.07, and have no familiarity with the QETH driver in
newer versions of Hercules at all. Consequently, I have no idea whether
you have configured things properly on the Hercules side or not.
It sounds to me like you are asking Debian s390x porters to debug
Hercules for you. If you suspect a bug in Hercules, you should
report this problem to the Hercules developers.
As for Debian, I don't know enough about the tools you are using to
be able to tell if there is a bug in Debian or not, but I can tell
you that you are not using Debian the way it is designed to work.
But before I get into that, let me say one thing. The default shell
in Debian is no longer bash, but dash. /bin/sh is a symbolic link
to /bin/dash on newer Debian systems. Consequently, any shell script
which starts out with "#!/bin/sh" will be executed by dash, not bash.
Consequently, any coding in the shell script which uses constructs
supported only by bash is likely to fail. As of s390-tools 1.17.1,
there are a couple of shell scripts which come with s390-tools that
start out with "#!/bin/sh" but which contain "bashisms": code that
only works with bash. The Debianized package contains patches to
change this to "#!/bin/bash", but the upstream version that you are
using may not have these changes. Check lstape and chiucvallow, and,
if they start with "#!/bin/sh", change these to "#!/bin/bash", as
these scripts contain bashisms. (At least at the 1.17.1 level they
do.) Interestingly enough, chiucvallow is another command, which,
like znetconf, is present in the Debian source package for s390-tools,
but didn't make it to the binary version of the package for some reason.
Now back to my main subject.
For network devices in Debian for s390x, hardware configuration is
designed to be done by sysconfig-hardware, and software configuration
is designed to be done by ifupdown. These two packages "front-end"
the lower level commands. If you use the network device during
installation, the Debian installer will create the appropriate
configuration file for you in /etc/sysconfig/hardware for
sysconfig-hardware, and will also configure the device for you in
/etc/network/interfaces for ifupdown. If you create a new network
device after installation, or if the network device existed prior
to installation but you did not use it during installation, then
you will have to create these configurations manually. Here is an
example from my system described on my "Debian Under Hercules" web
page: http://users.wowway.com/~zlinuxman/hercules.htm. The file
is called /etc/sysconfig/hardware/config-ccw-0.0.1000, and its
contents are as follows:
CCWGROUP_CHANS=(0.0.1000 0.0.1001)
CTC_PROTOCOL=0
This is for a channel-to-channel adapter with device number 1000
as the read device, device number 1001 as the write device, and
protocol 0 (s390).
Here is another example for an Open Systems Adapter Express in
QDIO layer 3 mode from another system. The file name is
/etc/sysconfig/hardware/config-ccw-0.0.0300, and its contents are
as follows:
CCWGROUP_CHANS=(0.0.0300 0.0.0301 0.0.0302)
Documentation for the contents of these files is, unfortunately,
poor. The best way to find out is to use one of these devices
for a Debian install. I don't know what the above file would
look like if the device were a layer 2 device, but based on reading
the source code, I'm guessing that it would be something like this:
CCWGROUP_CHANS=(0.0.0300 0.0.0301 0.0.0302)
QETH_OPTIONS=layer2
So, anyway, the first step is to create one of these configuration
files with an appropriate name in /etc/sysconfig/hardware.
sysconfig-hardware will then configure the device and bring it
online during boot.
By the way, while we're on the subject of sysconfig-hardware, I
strongly recommend that you apply the patch for Debian bug number
620095 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620095)
to sysconfig-hardware. Otherwise, you will never be able to get
a device offline that was configured by sysconfig-hardware.
The patch basically consists of changing
SUBSYSTEM=="ccw", RUN+="/sbin/hwup -A -D $devpath $env{SUBSYSTEM} $kernel"
to
SUBSYSTEM=="ccw", ACTION=="add", RUN+="/sbin/hwup -A -D $devpath $env{SUBSYSTEM} $kernel"
in /lib/udev/rules.d/85-sysconfig-hardware.rules.
On the software side, all interfaces are configured in /etc/network/interfaces.
for example, here is what the definition for my layer3 QETH device looks like:
# The primary network interface
auto eth0
iface eth0 inet static
address 10.14.80.48
netmask 255.255.255.0
network 10.14.80.0
broadcast 10.14.80.255
gateway 10.14.80.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 10.14.80.5 10.14.80.9 10.14.6.24
dns-search my.employers.network.us
(Well, OK, I lied about the dns-search option. That's not the real domain name.
The name was changed to protect my employer's identity.)
Here is what my CTCA device in protocol 0 mode looks like on one of my home Debian
system under Hercules:
# The primary network interface
auto ctc0
iface ctc0 inet static
address 192.168.1.9
netmask 255.255.255.252
network 192.168.1.8
broadcast 192.168.1.11
gateway 192.168.1.10
pointopoint 192.168.1.10
mtu 1500
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 192.168.0.1
dns-search my.home.network.us
(Again, I lied about the domain name for anonymity's sake.)
As you can see, the options are about the same. I had to add "pointopoint"
as an option for this device, since it is a point-to-point connection.
And I added "mtu" for technical reasons. "mtu" could have been specified
for the eth0 interface too, but I chose to leave it off. Some of the above
options are not used or are ignored for this device, such as broadcast,
but it doesn't hurt to specify them for documentation purposes.
If you have two QETH devices defined at the same time, one layer 3 and
one layer 2, for example, then one of them will be called eth0 and the
other will be called eth1. The trick is to figure out which is which.
This is controlled by a file called /etc/udev/rules.d/70-persistent-net.rules.
On the i386 or amd64 platform, devices are generally identified by MAC
address. But on the s390x platform, they are generally identified by
device number. If this file is missing, you can determine the correspondence
from sysfs. For example,
cat /sys/bus/ccwgroup/devices/0.0.0300/ifname
might produce
eth0
Once you know the correspondence between device numbers and interface
names, you will know how to configure the interface names in
/etc/network/interfaces.
If you want the interface to come up automatically during boot,
you can add an "auto" statement to the file, such as
auto eth0
If not, you can manually bring the interface up by means of
ifup eth0
You can manually take an interface down with
ifdown eth0
In short, I recommend that you configure these network devices the
way Debian was designed to work. If Hercules is working properly,
and you have configured your interfaces properly in both Hercules
and Debian, it should "just work". If not, asking for help on this
list with your devices configured the "Debian way" will likely
cause better recognition of the problem by Debian users.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: