halfmeg
2010-11-29 15:34:34 UTC
Occasionally someone comes along and tries to utilize S/370 mode using more than 1 processor defined in the Hercules configuration. There is some discussion but never seems to be a resolution to SPIN problem or what seems to be excessive overhead when NUMCPU 2 is defined.
http://tech.groups.yahoo.com/group/hercules-390/message/49171
http://tech.groups.yahoo.com/group/hercules-390/message/49269
3.8j only does a couple of things differently when MP is genned, as I think TK3 is. It sets aside some Global Save Area for the 2nd processor and includes 2 modules, IGFPXMFA & IFGPTAIM in the gen.
Thinking that the above seems pretty innocuous I tinker with Hercules a bit this morning.
Checked out current SVN (7143) version ( dyn76.c causes failure in compile so removed it from make ).
Changed hercules.cnf to:
CPUMODEL 3033
ARCHLVL s/370
NUMCPU 2
Started Hercules no need for OS to see what looks like a problem to me. Log segment reporduced below:
09:58:22 HHC00013I Herc command: 'sysclear'
09:58:22 HHC02311I sysclear completed
09:58:27 HHC00013I Herc command: 'r 50-50'
09:58:27 HHC02290I R:00000050:K:00=FFF99851
09:58:32 HHC00013I Herc command: 'r 50-50'
09:58:32 HHC02290I R:00000050:K:00=FFF3CBD4
09:58:38 HHC00013I Herc command: 'r 50-50'
09:58:38 HHC02290I R:00000050:K:00=FFECCB65 <<---<<<<
09:58:42 HHC00013I Herc command: 'cpu 1'
09:58:50 HHC00013I Herc command: 'r 50-50'
09:58:50 HHC02290I R:00000050:K:00=FFECCB65 <<---<<<<
09:58:52 HHC00013I Herc command: 'r 50-50'
09:58:52 HHC02290I R:00000050:K:00=FFE9E3A6
09:58:53 HHC00013I Herc command: 'r 50-50'
09:58:53 HHC02290I R:00000050:K:00=FFE8C626 <<---<<<<
09:58:57 HHC00013I Herc command: 'cpu 0'
09:59:07 HHC00013I Herc command: 'r 50-50'
09:59:07 HHC02290I R:00000050:K:00=FFE8C626 <<---<<<<
09:59:10 HHC00013I Herc command: 'r 50-50'
09:59:10 HHC02290I R:00000050:K:00=FFE5C4F0
09:59:11 HHC00013I Herc command: 'r 50-50'
09:59:11 HHC02290I R:00000050:K:00=FFE47A95 <<---<<<<
09:59:15 HHC00013I Herc command: 'cpu 1 '
09:59:23 HHC00013I Herc command: 'r 50-50'
09:59:23 HHC02290I R:00000050:K:00=FFE47A95 <<---<<<<
09:59:24 HHC00013I Herc command: 'r 50-50'
09:59:24 HHC02290I R:00000050:K:00=FFE2F573
SYSCLEAR starts the CPUTIMER in s/370 mode located at x'50'. When 2 CPUs are defined there are supposed to be a separate PSA for each. That may be alright, but the timer should be getting updated in each as well. As the log above shows the timer doesn't increment after switching the display from CPU 0 to 1 or back to 0 even though several seconds have passed. Once the 'bogus' timer display is displayed then the timer display changes as it should again until a CPU switch is performed then it doesn't update until the 2nd display request.
This doesn't look right and if a CPU is expecting the timer to always increment but doesn't, isn't there a possibility the SPIN is coming from what looks to me like a bug?
Phil
http://tech.groups.yahoo.com/group/hercules-390/message/49171
http://tech.groups.yahoo.com/group/hercules-390/message/49269
3.8j only does a couple of things differently when MP is genned, as I think TK3 is. It sets aside some Global Save Area for the 2nd processor and includes 2 modules, IGFPXMFA & IFGPTAIM in the gen.
Thinking that the above seems pretty innocuous I tinker with Hercules a bit this morning.
Checked out current SVN (7143) version ( dyn76.c causes failure in compile so removed it from make ).
Changed hercules.cnf to:
CPUMODEL 3033
ARCHLVL s/370
NUMCPU 2
Started Hercules no need for OS to see what looks like a problem to me. Log segment reporduced below:
09:58:22 HHC00013I Herc command: 'sysclear'
09:58:22 HHC02311I sysclear completed
09:58:27 HHC00013I Herc command: 'r 50-50'
09:58:27 HHC02290I R:00000050:K:00=FFF99851
09:58:32 HHC00013I Herc command: 'r 50-50'
09:58:32 HHC02290I R:00000050:K:00=FFF3CBD4
09:58:38 HHC00013I Herc command: 'r 50-50'
09:58:38 HHC02290I R:00000050:K:00=FFECCB65 <<---<<<<
09:58:42 HHC00013I Herc command: 'cpu 1'
09:58:50 HHC00013I Herc command: 'r 50-50'
09:58:50 HHC02290I R:00000050:K:00=FFECCB65 <<---<<<<
09:58:52 HHC00013I Herc command: 'r 50-50'
09:58:52 HHC02290I R:00000050:K:00=FFE9E3A6
09:58:53 HHC00013I Herc command: 'r 50-50'
09:58:53 HHC02290I R:00000050:K:00=FFE8C626 <<---<<<<
09:58:57 HHC00013I Herc command: 'cpu 0'
09:59:07 HHC00013I Herc command: 'r 50-50'
09:59:07 HHC02290I R:00000050:K:00=FFE8C626 <<---<<<<
09:59:10 HHC00013I Herc command: 'r 50-50'
09:59:10 HHC02290I R:00000050:K:00=FFE5C4F0
09:59:11 HHC00013I Herc command: 'r 50-50'
09:59:11 HHC02290I R:00000050:K:00=FFE47A95 <<---<<<<
09:59:15 HHC00013I Herc command: 'cpu 1 '
09:59:23 HHC00013I Herc command: 'r 50-50'
09:59:23 HHC02290I R:00000050:K:00=FFE47A95 <<---<<<<
09:59:24 HHC00013I Herc command: 'r 50-50'
09:59:24 HHC02290I R:00000050:K:00=FFE2F573
SYSCLEAR starts the CPUTIMER in s/370 mode located at x'50'. When 2 CPUs are defined there are supposed to be a separate PSA for each. That may be alright, but the timer should be getting updated in each as well. As the log above shows the timer doesn't increment after switching the display from CPU 0 to 1 or back to 0 even though several seconds have passed. Once the 'bogus' timer display is displayed then the timer display changes as it should again until a CPU switch is performed then it doesn't update until the 2nd display request.
This doesn't look right and if a CPU is expecting the timer to always increment but doesn't, isn't there a possibility the SPIN is coming from what looks to me like a bug?
Phil