Closed clang20 closed 8 years ago
IEA247I USING IEASYSDP FOR OS/390 02.10.00 HBB7703
IEA304W SYSTEM WAIT STATE CODE 80009064 DURING IEAVNP10 INITIALIZATION
A work-around for this problem is to issue the following command prior to the IPL:
archlvl disable STFL_EXTENDED
Thanks. Ill try and will revert back.
No, Same issue with STFL_EXTENDED disabled
IEA247I USING IEASYSDP FOR OS/390 02.10.00 HBB7703
IEA304W SYSTEM WAIT STATE CODE 80009064 DURING IEAVNP10 INITIALIZATION
Hi, The setting below makes no difference. Thanks, Chris
gauser317 wrote: A work-around for this problem is to issue the following command prior to the IPL: archlvl disable STFL_EXTENDED
Did you already fix this syntax error in your configuration file?
18:43:14 HHC00811I Processor CP00: architecture mode z/Arch
18:43:14 HHC02205E Invalid argument OS/390
18:43:14 HHC01441E Config file[22] conf/hercules.cfg: error processing statement: ARCHMODE OS/390
From hercules 4.00 help:
? archmode
Command Description
------- -------------------------------------------------------
archmode Alias for archlvl
? archlvl
Command Description
------- -------------------------------------------------------
archlvl *Set Architecture Level
Format: archlvl s/370|als0 | esa/390|als1 | esame|als2 | z/arch|als3
enable|disable <facility> [s/370|esa/390|z/arch]
query [<facility> | all]
command without any argument simply displays the current architecture
mode. Entering the command with an argument sets the architecture mode
to the specified value.
Hi Bert, I had changed it to that from another thread on same wait state for os390. I will change it back but expect the behavior will be the same.
Thanks
Hi Bert, I correct ARCHMODE and same behavior. BTW I am able to IPL using the 3.12 version of Hercules. So the fault is in the 4.x version of Hercules.
Thanks
Just to be sure: the archmode configuration statement is now accepted So it is no longer reported as error in your log?
Yes, It's corrected. The system IPLs fine using the 3.12 version of Hercules.
Please try this:
Change your OSTAILOR
statement to OSTAILOR NONE
and try again and then post your complete Hercules log file so we can see it.
It won't fix your problem of course, but it might provide us with a clue.
Hi Fish, logfile with OSTAILOR NONE attached.
Thanks logfile.txt
Hi Chris,
Would it be difficult for you to try the hercules (4.00) included in Juergen Winkelman's TK4-?
http://wotho.ethz.ch/tk4-/tk4-_v1.00_current.zip
Unzip and run something like:
C:\zos\tk4-\hercules\windows\64\hercules.exe -f conf\hercules.cnf
That hercules is a copy from 2012 if I remember that well with just a few updates.
Hi Bert, Looks like your build works.
@Fish, This version is from
08:10:00 HHC01413I Hercules version 4.00 08:10:00 HHC01414I (c) Copyright 1999-2012 by Roger Bowler, Jan Jaeger, and others 08:10:00 HHC01415I Built on Feb 6 2015 at 13:49:07 08:10:00 HHC01416I Build information: 08:10:00 HHC01417I Windows (MSVC) build for AMD64 08:10:00 HHC01417I Modes: S/370 ESA/390 z/Arch
I also thought I recall someone on the Yahoo thread having the same issue and that it worked using 4.0 back in October.
Thanks,
Chris
Hi Chris!
I would just like confirm the following:
Is that correct?
If so, please try the (2015-11-20) so we can know where things went wrong.
Thanks.
Hi Fish,
2016-08-10 fails 2016-04-23 Not sure perhaps per OP in yahoo thread it fails. He also mentioned a 4.0 version from October 2015 that he said Worked. Not sure about 2015-11-20 or whether these last two do work.
I'll check, but if you could give me the git command line to pull down 4.0 by date I'm happy to try starting from October 2015 (when it possibly last worked) to present to try to help narrow it down.
Did any of the CP exceptions in the log shed any insight on the failures?
Thanks,
Chris PS I also sent your 35 or so for a copy of CTCI.
Hi Fish, I've tried this
git clone https://github.com/hercules-390/hyperion.git .
git rev-list -1 --before="Oct 10 2016" master 05652fb9d7993d942138196c4e9bad6b1c7a63e1
git checkout 05652fb9d7993d942138196c4e9bad6b1c7a63e1
but still seem to have a set of working files from HEAD. What am I missing?
Hi Fish, I think I'm still pulling the latest branch. I would help if I corrected the date to 2015 lol. I'll try again.
15:44:03 HHC01413I Hercules version 4.0.0.8598-g05652fb-modified (4.0.0.8598) 15:44:03 HHC01414I (C) Copyright 1999-2016 by Roger Bowler, Jan Jaeger, and others 15:44:03 HHC01415I Build date: Aug 13 2016 at 15:39:23 15:44:03 HHC01417I Built with: Microsoft Visual C 190024213 1 15:44:03 HHC01417I Build type: Windows MSVC AMD64 host architecture build
Hi Fish, Looks like VS2015 support was not available yet in October 2015. Argh. I can update the makefile.bat though if there were some binaries I could test instead that would be helpful. Does the project maintain sets of prebuilt binaries?
Looks like hacking the build is not the way to go, I've worked around vs2015 support, issue with the VERSION define in version.h, a redefinition of timespec in fthreads.h and now NMAKE : fatal error U1073: don't know how to make 'msvc.AMD64.obj\SoftFloat-specialise.obj' I only see softfloat.c.
Hi Fish, I tried all the 4.0 pre-builts back to 2015-07-19 and none of them work.
Thanks
Hi Fish,
Final outcome of testing all the pre-guilts is that none of them work. Looks like the report about the October binaries working was wrong. The TK-4 build I tried from 2012 I believe, did work, and the version said 4.0 but I guess there is a question as to whether that was actually 4.0.
FAILS: Hercules-4.0.0.8597-g05652fb-x64.zip (2016-08-12) FAILS: Hercules-4.00.0.8473-gfe2c24f-x64.zip (2016-04-23) FAILS: Hercules-4.00.0-git-8396-g9b24d74-x64.zip (2015-11-20) FAILS: Hercules-4.00.0-git-8243-gf4bf8ff-x64.zip (2015-10-06) FAILS: Hercules-4.00.0.8213-gfce758d-x64.zip (2015-07-19)
Thanks,
Chris
Chris,
Your issue with OS/390 2.10:
IEA247I USING IEASYSDP FOR OS/390 02.10.00 HBB7703 IEA304W SYSTEM WAIT STATE CODE 80009064 DURING IEAVNP10 INITIALIZATION
is very similar to the issue Christian Birr had with OS/390 2.08, as documented in GitHub issue 13:
IEA247I USING IEASYSDB FOR OS/390 02.08.00 HBB6608 IEA304W SYSTEM WAIT STATE CODE 80009064 DURING IEAVNP10 INITIALIZATION
Christian's ultimate problem was a bad (damaged) CCKD DASD image file, but your problem is probably not that. I suspect your dasd image files are probably okay.
However...
I happened to notice that his configuration file starts with:
ARCHMODE ESA/390
ALRF ENABLE
whereas your configuration file does not.
Your configuration begins with:
ARCHMODE OS/390
which of course is wrong. You told Bert that you corrected it:
Hi Bert, I correct ARCHMODE and same behavior.
but you did not tell us what ARCHMODE
value you changed it to.
What ARCHMODE
value are you now using? Are you using ARCHMODE ESA/390
now?
I did some tests and due to Hyperion's different (more accurate) implementation of the STFL
and STFLE
instructions, the Facility List bytes returned by Hyperion when archmode ESAME
is used is very different from the Facility List bytes that it returns when archmode z/Arch
is used.
Have you tried adding a ARCHLVL ENABLE ASN_LX_REUSE
statement (same thing as ALRF ENABLE
) to your configuration file immediately following your ARCHMODE ESA/390
statement? (which, technically, for Hyperion, should actually be specified as ARCHLVL ESA/390
instead)
Enabling the ASN and LX Reuse Facility might be the solution to your problem?
Try removing your ARCHMODE OS/390
statement and replace it instead with:
ARCHLVL ESA/390
ARCHLVL ENABLE ASN_LX_REUSE
and then try your test again using one of the pre-built snapshots from my SoftDevLabs web site.
Please let us know if that helps you.
Thanks!
Hi Fish The setting is correct. Its esa/390. The same cfg works fine with 3.x. My dads is fine too.
Thanks
On Aug 14, 2016, at 20:29, Fish-Git notifications@github.com wrote:
Chris,
Your issue with OS/390 2.10:
IEA247I USING IEASYSDP FOR OS/390 02.10.00 HBB7703 IEA304W SYSTEM WAIT STATE CODE 80009064 DURING IEAVNP10 INITIALIZATION
is very similar to the issue Christian Birr had with OS/390 2.08, as documented in GitHub issue 13:
IEA247I USING IEASYSDB FOR OS/390 02.08.00 HBB6608 IEA304W SYSTEM WAIT STATE CODE 80009064 DURING IEAVNP10 INITIALIZATION
Christian's ultimate problem was a bad (damaged) CCKD DASD image file, but your problem is probably not that. I suspect your dasd image files are probably okay.
However...
I happened to notice that his configuration file starts with:
ARCHMODE ESA/390 ALRF ENABLE whereas your configuration file does not.
Your configuration begins with:
ARCHMODE OS/390 which of course is wrong. You told Bert that you corrected it:
Hi Bert, I correct ARCHMODE and same behavior.
but you did not tell us what ARCHMODE value you changed it to.
What ARCHMODE value are you now using? Are you using ARCHMODE ESA/390 now?
I did some tests and due to Hyperion's different (more accurate) implementation of the STFL and STFLE instructions, the Facility List bytes returned by Hyperion when archmode ESAME is used is very different from the Facility List bytes that it returns when archmode z/Arch is used.
Have you tried adding a ARCHLVL ENABLE ASN_LX_REUSE statement (same thing as ALRF ENABLE) to your configuration file immediately following your ARCHMODE ESA/390 statement? (which, technically, for Hyperion, should actually be specified as ARCHLVL ESA/390 instead)
Enabling the ASN and LX Reuse Facility might be the solution to your problem?
IN SUMMARY:
Try removing your ARCHMODE OS/390 statement and replace it instead with:
ARCHLVL ESA/390 ARCHLVL ENABLE ASN_LX_REUSE and then try your test again using one of the pre-built snapshots from my SoftDevLabs web site.
Please let us know if that helps you.
Thanks!
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Hi Fish The setting is correct. Its esa/390. The same cfg works fine with 3.x.
Okay. Good.
My dads is fine too.
Huh? What does that mean? I don't understand.
What does "My dads is fine" mean?
Hi Fish. The problem isn't my cfg file.
Thanks
Sorry stupid auto correct. I'm on my phone.
Thanks
Hi Fish, please pardon the autocorrect on my phone lol. Thanks
Chris
On 8/15/2016 6:01 AM, clang20 wrote:
On Aug 14, 2016, at 22:32, Fish-Git notifications@github.com wrote:
Hi Fish The setting is correct. Its esa/390. The same cfg works fine with 3.x.
I was wondering... Is it possible ASN and LX reuse is enable by default on hyperion and disabled by default on spinhawk ?
There is known bug in some versions on OS/390 2.10 where the control register explicitly requires use of the ASN and LX reuse feature, but is then issuing the wrong Set Address Space Control instruction leading to a program interrupt.
On hyperion try adding a "ARCHLVL ASN_LX_REUSE disabled" in your configuration file.
Ivan
Spelling correct changing dasd to dads perhaps?
Hi Ivan, Exactly lol.
Chris
Hi Dave rather :)
Hi Ivan. Will try as soon as I can tomorrow and will let you know.
Thanks
Chris
Spelling correct changing dasd to dads perhaps?
(Doh!) Of course. :)
On 8/15/2016 4:34 PM, Fish-Git wrote:
Spelling correct changing dasd to dads perhaps?
(Doh!) Of course. :)
Come on Fish.... didn't you auto back translated that one ?
But seriously ....
Don't you think the actual issue looks curiously close to the reason we had an option to disable ASN and LX reuse for OS/390 2.10 ?
Ivan
I was wondering... Is it possible ASN and LX reuse is enable by default on hyperion and disabled by default on spinhawk ?
Good guess, Ivan. I was thinking the same thing (but the opposite), which is why I ran the tests I did. ("stfle.txt
" test in the tests subdirectory) The results were, shall we say, quite illuminating. :)
I ran the test on both 3.12 and Hyperion first using archmode ESAME
by itself (the test's default) and then again using archmode ESA/390
+ ALRF ENABLE
(as well as just archmode z/Arch
by itself without any ALRF statement on Hyperion only), and this was the results:
(first 10 bytes of Facility List): (Note: the 'EE's you see is an artifact of the test; see "stfle.txt")
0 1 2 3 4 5 6 7 8 9
F1 F0 FF FB FC FC 80 00 04 1C (Spinhawk ESAME)
F1 F0 FF FB F0 70 08 00 EE EE (Hyperion ESAME)
81 00 CA 82 00 40 00 00 00 0C (Spinhawk 390+ALRF)
82 00 00 00 00 00 08 00 EE EE (Hyperion 390+ALRF)
F1 F4 FF FB F8 F5 08 00 20 1C (Hyperion z/Arch)
Quite interesting, isn't it?
Especially bit 69. ;-)
There is known bug in some versions on OS/390 2.10 where the control register explicitly requires use of the ASN and LX reuse feature, but is then issuing the wrong Set Address Space Control instruction leading to a program interrupt.
I'm thinking it has to be something along those lines too, simply because we're running out of possibilities. It seems 3.x is doing something incorrectly that just by coincidence happens to make OS/390 happy, whereas Hyperion is doing it correctly leading to the problem.
That may seem a tad arrogant but we do know for a fact Spinhawk is not setting its Facility List bits correctly whereas Hyperion sets them correctly. We also know other parts of Hyperion are more architecturally compliant as well (such as its LPARNUM
and CPUIDFMT
handling as well as its Channel Subsystem too) so the problem, as I theorize, is more likely IMO within 3.x than 4.x but it's presenting itself as the complete opposite! (at least in this particular specific case anyway)
On hyperion try adding a "ARCHLVL ASN_LX_REUSE disabled" in your configuration file.
I'm recommending the complete opposite! Enable ASN_LX_RESUSE
, just like GitHub issue 13 shows Christian has it in his configuration file for OS/390 2.08.
But trying both ways (with and without it) can't hurt either of course, seeing how we're still stumbling in the dark on this issue.
Hi Fish, I'll try the setting and will let you know.
Thanks,
Chris
Don't you think the actual issue looks curiously close to the reason we had an option to disable ASN and LX reuse for OS/390 2.10 ?
Absolutely!
But since the default on Hyperion is disabled (i.e. ALRF DISABLE
or ARCHLVL DISABLE ASN_LX_REUSE
is the default unless overridden), I'm suggesting that he try enabling it instead to see if that helps.
Further, since Christian Birr had/has it enabled in his configuration file for OS/390 2.08 (as documented in GitHub issue 13), I'm thinking Chris should try the same thing with his OS/390 2.10.
And since we're on the subject of ASN and LX REUSE, something we should probably discuss in the developers group is Hyperion's technically incorrect handling of the ALRF bit. According to the Principles of Operation the bit should always be on (enabled). That is to say, our default handling is technically wrong:
SA22-7832-10 z/Architecture Principles of Operation:
Facility Indications
(pg. 4-78)
A bit is set to one regardless of the current architec- tural mode if its meaning is true. A meaning applies to the current architectural mode unless it is said to apply to a specific architectural mode.
(pg. 4-76)
bit 6: The ASN-and-LX reuse facility is installed in the z/Architecture architectural mode.
Which would require users not wanting such behavior to specifically disable it (rather than specifically enable like today).
But as I said this is something we should probably discuss in the developers group (or at least in a separate GitHub issue), not here.
Come on Fish.... didn't you auto back translated that one ?
Believe it or not, no I didn't. It seems so obvious now of course, but at the time I honestly did not think of it. Go figure. :)
Lol pre-guilts, auto correct sucks lol
Cheers
Chris
Any luck yet, @clang20?
Have you had a chance to try the following yet?
ARCHLVL z/Arch
archlvl enable asn_lx_reuse
archlvl enable bit44
and:
LPARNUM 1
Does it help you any? Does it resolve your problem?
It looks like Wayne Bickerdike was able to successfully use my 2016-08-12 Hyperion pre-built snapshot using the above ARCHLVL
statements (see group message 79616), and as I explained in an earlier group post (message 79581) Hyperion uses the LPARNUM
value to determine which CPUID format to use, which also might be causing your problem.
Please report back to let us know whether your problem has been resolved yet or not!
Thanks!
Hi Fish, just got home from being out of town. I will try this afternoon and will let you know.
Thanks
Chris
Hi Fish,
Same wait state using the settings below.
ARCHLVL z/Arch archlvl enable asn_lx_reuse archlvl enable bit44
Thanks,
Chris
I also tried LPARNUM 1 with the same result.
Thanks,
Chris
Hi Fish,
Let me know if there is anything else you want me to try or if there are any additional diagnostics I can perform.
Thanks,
Chris
Let me know if there is anything else you want me to try or if there are any additional diagnostics I can perform.
Well, I don't know what your skill level is, but what I'd like to do (I'm not sure how to do it but nevertheless this is what I'd like to somehow do) is, do an instruction trace of IEAVNP10
.
You would need to somehow determine where in storage IEAVNP10
gets loaded, and then issue a t addr-addr
(or t addr.len
) Hercules command so we can see what it's doing. We need to determine what the heck it's complaining about.
Your OSTAILOR NONE
log didn't show anything unusual, so it's still a mystery why OS/390 is saying a program-check occurred when the evidence shows that's not true. I'm suspecting disabled wait 9064 is simply some type of catch-all "something bad happened" type of disabled waits.
But as I said, we need to see what IEAVNP10
is actually doing. Where it is taking its wrong turn. How it reached its "I give up! Let's throw a 9064 disabled wait!" decision.
At least that's what I would like to do unless someone else can come up with a better idea.
Can you do that Chris?
Hi Fish,
Would this involve traces on MVS or would it involve traces in Hercules or both? Well I am able to IPL the system using 3.10 if needed. Sounds like both information from Hercules and MVS will be needed. It seems like I would need to run a system trace though OS/390 specific documentation seems a bit scarce after a quick google search so I would have to dig deeper. I wonder if this module always loads at the same address. If someone could guide me in the right direction I can try to get what you need. In the meantime I’ll do some more research. Perhaps a standalone dump might help?
Thanks,
Chris
Chris,
Could you try SPECIFICALLY disabling ASN and LX reuse ? Again, I kind of remember that some of the (now deprecated) ASN_LX_REUSE statements, now replaced by ARCHLVL, were especially implemented in order to run the AD/CD version of OS/390 2.10 which had a bug in NIP that prevented an IPL. CR0 bit 44 was set to 1 and DID specify the OS wanted to use ASN LX Reuse but then used a Load Address Space Parameter (LASP) instruction which was incompatible with the facility, leading to a specification exception or a special operation exception.
Try looking at any program interrupt by setting OSTAILOR NONE, then looking at CR0 and the instruction parameters at the time at program interrupt.
If this is the case, then there is an issue with how we handle how ASN and LX Reuse is enabled/disabled.
Ivan
Hi All,
I used to be able to IPL this system using Hercules 3.10. I'm now using Hercules Hyperion (pulled down source yesterday) and am unable to IPL this system. OSTAILOR is set to OS/390, LPARNUM 10 and CPUVERID 47. Any ideas on what to try next?
Thanks,
Chris