Discussion:
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
(too old to reply)
Stephen Powell
2014-08-15 01:50:01 UTC
Permalink
Hrm. Odd. It shouldn't be because the brokeness relates to the C
library, not to the C compiler itself and zipl does not use the C
library.
Again, we must distinguish between zipl, the Linux command which
runs at a Linux shell prompt, and zIPL, the boot loader proper,
a customized version of which is written out by zipl when zipl gets
run. zipl, the command which runs at a Linux shell prompt, most
certainly does use the C library. It is written in C, it is compiled
by the C compiler, and, at execution time, it uses the C run-time
library, just like any other C program. zIPL, which is written
out by zipl, does not use the C library. Or does it? Well, not
the regular C library, no. But it does use a minimalist run-time
library. In the source package, look at zipl/boot/libc.c. Yes, even
zIPL, the boot loader proper, does use a C library of sorts.
That being said, I had to recompile s390-tools on sid,
Therein lies the problem.
and I do not run sid due to the C breakage.
You should. You may not be able to directly install jessie or
sid, but you can install wheezy and then do an upgrade to jessie
or sid. Of course, you will likely experience problems during
the upgrade, as I did, most likely with the upgrade of package
perl-base. But there are posts to debian-s390 by me that explain
how I worked around it. If you had a sid system to test with,
you would have realized that this package is unusable and you
never would have uploaded it.
It worked before the recompilation, hence there might be
a change in sid vs. wheezy that caused this.
Oh, absolutely. I downloaded the new source package, built
it on a wheezy system, transferred the binary package to
my jessie system, installed the binary package on my jessie
system, ran zipl, shutdown my system, and IPLed. It IPLed
just fine. I then took the exact same source package, compiled
it on a jessie system, installed the binary package, ran zipl,
shutdown, and IPLed. Kaboom! disabled wait state code X'32EE'.
The C compiler and run-time library used is the only difference.
I think I've proven pretty conclusively that this is C breakage
causing this problem.
You are talking about Hercules, right?
It doesn't matter. I get the exact same results on Hercules
as I do on a real mainframe, and vice versa. I have found
Hercules to be a deadly accurate emulation of real mainframe
hardware, when properly configured.

In my opinion, everyone who maintains a package which is
mainframe-specific, such as s390-tools, and anyone responsible,
in whole or in part, for the s390x port needs their own mainframe
system that they can play around with in a totally unrestricted
manner, without fear of messing someone else up. And if you
don't have access to a real mainframe, a Hercules emulation of
one is the next best thing. It's slower than a real mainframe;
but architecturally, it is virtually indistinguishable from a
real mainframe to the software. And that's what an emulator is
all about, right?

You need a jessie/sid system to play around with.

I must say that the C breakage on s390x is the biggest mess that
I have ever seen, and in the case of this package, has produced
the worst error yet: a totally unbootable system.

By the way, when version 1.17.1 of the package is compiled on
a jessie system, it runs fine. To me, the most significant
difference between the two packages is that the zIPL portion of
the 1.17.1 package, the boot loader proper, is all written in
assembly language (zipl/boot/sclp.S, zipl/boot/menu.S, etc.),
whereas the zIPL portion of the 1.24.1 package has been rewritten
in C (zipl/boot/sclp.c, zipl/boot/menu.c, etc.). Since it's
written in C, it needs that minimalist C run-time library
(zipl/boot/libc.c), which the 1.17.1 version doesn't need.

Yes, this bug has C breakage written all over it.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Philipp Kern
2014-08-15 21:30:03 UTC
Permalink
On Thu, 14 Aug 2014 21:45:53 -0400 (EDT)
Post by Stephen Powell
Hrm. Odd. It shouldn't be because the brokeness relates to the C
library, not to the C compiler itself and zipl does not use the C
library.
Again, we must distinguish between zipl, the Linux command which
runs at a Linux shell prompt, and zIPL, the boot loader proper,
a customized version of which is written out by zipl when zipl gets
run. zipl, the command which runs at a Linux shell prompt, most
certainly does use the C library. It is written in C, it is compiled
by the C compiler, and, at execution time, it uses the C run-time
library, just like any other C program.
zIPL, which is written
out by zipl, does not use the C library. Or does it? Well, not
the regular C library, no. But it does use a minimalist run-time
library. In the source package, look at zipl/boot/libc.c. Yes, even
zIPL, the boot loader proper, does use a C library of sorts.
Stephen is right. The zipl tool is a "normal" C program that uses
the glibc. The zipl boot loader code under the "boot" source directory
does not use the glibc or any other external library.
Before s390-tools-1.24.0 it was written 100% in assembler. With
s390-tools-1.24.0 we have rewritten the code in C and have added our
own minimal libc.
I should've written (e)glibc instead of "C library". It's what I meant. I tried
to simplify things and failed.

The question of "is this Hercules" was also more related to "where is the value
coming from", as CP might do things differently.

So Hercules should log the whole PSW. I can also only see it logging that and
the CPU address/ID, not a wait state code. Do you happen to have the PSW
handy?

Kind regards
Philipp Kern
Stephen Powell
2014-08-15 23:20:01 UTC
Permalink
...
Do you happen to have the PSW handy?
The full PSW is as follows:

00020000 80000000 00000000000032EE

It looks like the "wait" bit is set, "31-bit addressing mode" is set,
I/O, External, and Machine check interruptions are all disabled,
and the instruction address (i.e. disabled wait state code) is set
to X'32EE'.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Stephen Powell
2014-08-16 15:40:01 UTC
Permalink
Post by Stephen Powell
00020000 80000000 00000000000032EE
By the way, Hercules has an instruction tracing facility, similar to
the CP TRACE command on z/VM. The "T" command, along with the "T+"
and "T-" commands, are documented in the Hercules User Reference Guide,
available as a pdf file from

http://hercdoc.glanzmann.org

Scroll down to the section for the manuals for version 3.07, which is
the version which is currently packaged for Debian.

And, by the way, the current main Hercules web site is

http://www.hercules-390.eu

The 3.07 documentation which ships with the current hercules package
in Debian points to the old web site, which is no longer valid.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Loading...