Hercules Bus Error

[David Clements]

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.

My host environment is debian stable using an updated kernel
linux-3.12.1-amd64

Hercules is version 4.0 from the github/hyperion repository and I used

configure --enable-debug --prefix= ...... to generate hercules

My guest is debian-390 testing, the only addition is the s390-tools from
the IBM
DeveloperWorks website, because the debian version is incomplete for
some reason!!!

My comms devices are:

#0440.2 CTCI tun2

0440.2 CTCI 192.168.200.1 192.168.200.2


#0F40.3 QETH ipaddr 192.168.10.100 debug

0F40.3 QETH iface tun2 debug

I initially installed the guest with the vCTC, installed the
correct s390-tools, then used znetconf -a 0f40 -o layer2=0 to set
up the layer3 qeth device. at which point hercules stops with a Bus Error.

I set the tun2 device up on the host side with the ip command
as follows:

ip tuntap add dev tun2 mode tun
ip link set tun2 up
ip addr add 192.168.100.100 peer 192.168.100.50 dev tun2

The ip addr list then shows

23: tun2: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc
pfifo_fast
state DOWN qlen 500
link/none
inet 192.168.100.100 peer 192.168.100.50/32 scope global tun2
valid_lft forever preferred_lft forever

To validate the tun2 devices I tried to use it for the vCTC connection,
and it is recognized as a valid device

Tun2 before hercules starts:

23: tun2: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1500 qdisc
pfifo_fast state DOWN qlen 500
link/none
inet 192.168.100.100 peer 192.168.100.50/32 scope global tun2
valid_lft forever preferred_lft forever

Hercules displays as it starts up:

HHC02198I Device 0440 type 3088 subchannel 0:0004 attached

HHC00901I 0:0440 CTCI: interface tun2, type TUN opened

HHC02198I Device 0441 type 3088 subchannel 0:0005 attached

Tun2 after hercules acquires it:

23: tun2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UP qlen 500
link/none
inet 192.168.100.100 peer 192.168.100.50/32 scope global tun2
valid_lft forever preferred_lft forever

I'm not a c programmer but as far as I can see the same code
is used to open tun2 for both qeth and vCTC.

I have both the run log and a screen print of the last screen
displayed by hercules before it stops.

Let me know what else you need from me.

Dave Clements.

[Stephen Powell]

Post by David Clements
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
: :' :
`. `'`
`-

[David Clements]

Post by Stephen Powell

Post by David Clements
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
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
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
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.
# 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
# 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
`. `'`
`-
--
with a subject of "unsubscribe". Trouble? Contact

My initial response to your response was short, sharp and yes, crude,
but....

I sent this problem report to the wrong group.

There is no correct way to use debian. As I said in a post on my original
issues with hercules and debian-390 testing, I use debian because it gives
me what I need from a distro.
I do not use the debian supplied version of hercules, it does not provide
the functionality I need, so I use later versions from the github repo. I
use bash as my default shell, for all non-root work, I do not use dash nor
am I interested in why debian uses dash. I use later kernels to fix stall
problems on my AMD cpus, I could go on and on. I use debian the way I want
to, if I wanted to be dictated to about how I use my systems I would use
OSX or Windows.

My goal is to test new functionality in hercules, if this means I misuse or
abuse debian and or it's tools then so be it.

I worked with real mainframe boxes both as an engineer and a systems
programmer for more than 40 years, during that time I always had the
belief, philosophy if you like, that there was always some who knew more
than I on any given subject.

To summarize, please don't presume to lecture me, particularly as you said
in your first sentence "I admit that I don't understand all that you have
written", without first trying to ascertain the questioners level of
expertise. If you feel you can help in the spirit the question was posed
in, then great, otherwise.......

[Stephen Powell]

Post by David Clements
My initial response to your response was short, sharp and yes, crude,
but....
I sent this problem report to the wrong group.

OK, so you sent the problem report to the wrong group. We all make mistakes,
myself included. But how was I to know that you had sent the problem
report to the wrong group? I can't read minds. There's no need to get
mad about it. I responded based on the assumption that you posted to
debian-s390 on purpose. What else could I do?

Post by David Clements
There is no correct way to use debian. As I said in a post on my original
issues with hercules and debian-390 testing, I use debian because it gives
me what I need from a distro.

Whatever floats your boat, man. But when you use Debian in ways that its
architects did not design it to work, you severely limit the number of
people that will be able to help you should you have problems. I was
just trying to explain how its architects designed it to work.

Post by David Clements
I do not use the debian supplied version of hercules, it does not provide
the functionality I need, so I use later versions from the github repo.

Again, whatever floats your boat, man.

Post by David Clements
I use bash as my default shell, for all non-root work, I do not use dash nor
am I interested in why debian uses dash.

bash is the default shell for the login shell on Debian. But a shell script
which specifically points to "#!/bin/sh" will run under dash by default on
a Debian system, unless you have made alterations to it. Debian switched
to dash for improved speed, especially during the boot-up process.
If you want to make bash your default shell for shell scripts, again, whatever
floats your boat. I just wanted to make you aware of this issue.

Post by David Clements
I use later kernels to fix stall
problems on my AMD cpus, I could go on and on.

Fine. Again, whatever floats your boat.

Post by David Clements
I use debian the way I want
to, if I wanted to be dictated to about how I use my systems I would use
OSX or Windows.

I did not dictate to you.

Post by David Clements
My goal is to test new functionality in hercules, if this means I misuse or
abuse debian and or it's tools then so be it.

OK.

Post by David Clements
I worked with real mainframe boxes both as an engineer and a systems
programmer for more than 40 years, during that time I always had the
belief, philosophy if you like, that there was always some who knew more
than I on any given subject.

I am a systems programmer for IBM mainframes myself, still actively employed.
And I share that belief.

Post by David Clements
To summarize, please don't presume to lecture me, particularly as you said
in your first sentence "I admit that I don't understand all that you have
written", without first trying to ascertain the questioners level of
expertise. If you feel you can help in the spirit the question was posed
in, then great, otherwise.......

I did not lecture to you. That is your interpretation. I was just trying
to be helpful. Let me know how your strategy of insulting those from whom
you are trying to obtain free help works out for you.
--
.''`. Stephen Powell
: :' :
`. `'`
`-

[Philipp Kern]

Post by Stephen Powell
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. [...]

I think that your post should end up somewhere accessible and google'able in
documentation, as it is probably something a bunch of people will struggle
with when getting started with Debian on the mainframe. Except that I don't
know where. Some of it might belong into the installation manual, but most
of it is just how Debian network configuration works on the mainframe
and I'm not sure if we have good enduser docs where this would fit…

(Thanks for writing it up!)

Kind regards
Philipp Kern

[Stephen Powell]

Post by Philipp Kern
I think that your post should end up somewhere accessible and google'able in
documentation, as it is probably something a bunch of people will struggle
with when getting started with Debian on the mainframe. Except that I don't
know where. Some of it might belong into the installation manual, but most
of it is just how Debian network configuration works on the mainframe
and I'm not sure if we have good enduser docs where this would fit…
(Thanks for writing it up!)

Well, it obviously wasn't what the OP wanted to hear, but maybe it will benefit
someone. But I know what you mean. There's no well-defined place for it.
Network configuration in Debian for s390x is part sysconfig-hardware
(which is poorly documented), part udev (such as
/etc/udev/rules.d/70-persistent-net.rules), and part ifupdown. There doesn't
seem to be a single, well-defined place to document it.
--
.''`. Stephen Powell
: :' :
`. `'`
`-