The S/390 locks up?  Or the PC locks up?

ftp://hursley.linux.ibm.com/ doesn't exist when I try to connect to it BTW

Posted question to LTC1391

I will try to get answer to what exactly locks up. Also, the site that the
originator noted above is an internal site and that is why you cannot access it.
If there is something about the image you need to know can you ask it here so
that the  submitter can answer it for you. Thanks very much.

It is not clear at all to me from the initial bug report what system
is what above, and what problem is happening where.  I need a much
much greater amount of detail about both systems, and what exactly
is occuring, including what role each system is playing in the problem.

This bug is reported against Red Hat Linux 7.1/s390, and it sounds to
me like you're saying the z900 is locking up when resizing a window.
Since s390 does not contain video hardware, I would have to conclude
that this is not an XFree86 bug, but some kind of kernel bug or a
hardware problem.  Does the s390 have any proprietary OCO modules
loaded?

Adding comment from our developer,Kosuke Yoshida
 I was on leave yesterday, sorry for my late response..

Recently, the ftp site which was specified in initial bug report was move to a 
restricted site. 
https://ftp3.linux.ibm.com/rh_terms.html The downloadable site is prepared for
IBM TestUser. OtherUser cannot access it.

Unfortunately, we cannot verify this problem on z64 environment any longer, 
because the lease term of our z64 environment has already expired . 
Anyway, you should create a Redhat 7.1 for s/390(64bit) environment, and try to 
reproduce this problem.

So, I' d like to describe a initial bugs report again.
- zSeries 64-bit system:
IBM M/T 2064 zSeries 900 with Redhat 7.1 for s/390(64bit)  

Steps to Reproduce:
0. Install Redhat 7.1 for S/390(64bit) include Japanese package.
   Our Redhat Linux's image files are on 
https://ftp3.linux.ibm.com/rh_terms.html/....
1. Connect to the RH7.1 for S/390(64bit)from pc client through XDM.
   $X -query (390x linux) from PC client
2. Logon to the Redhat with GNOME/Sawfish
3. Open an terminal application like "kterm"or"Gnome Emulation Terminal".
4. Resize the application frame(window).
   Then, X client hangs up solidly. <== This is a problem

Additional Information:
This problem occurs without Japanese packages.
this problem does not occur on SLES7 for s/390 31-bit and SLES7 for s/390 64bit.
This does not occurs on Redhat 7.1 for s/390 31-bit.
We confirmed that accessed RH7.1 z64 from some PC clients, and this problem 
occurred solidly.

==> It means this is a Redhat 7.1 for s/390(64bit) unique problem.

In the initial bug report, you stated:

4. Resize the application frame.
   Then, System hangs up solidly.

Actual Results:  System hungs up solidly


But in your last comment, you state:
4. Resize the application frame(window).
   Then, X client hangs up solidly. <== This is a problem

These two pieces of information conflict with each other.  What is hanging,
the X client, or the entire system, and if the entire system, which system
is hanging, the s390, or the one running the X server?
I'm still confused.

Here is a clarification of the above
------- Additional Comment #19 From kosuke.com  2003-01-20 20:46 -------
I'm sorry to confusing you. As far as I remember, "X-client hangs up" is 
correct. 
Unfortunately, we cannot verify this on z64 environment any longer, 
because our lease term of z64 environment has already expired . 
So, if someone can re-test on Japanese z64 environnent instead of us,
I will agree with closing this problem.  Thank you. 

Ok, closing bug as WONTFIX, as it isn't yet entirely clear what the
problem is exactly and reporter has indicated the hardware is no
longer available for further troubleshooting.

If the hardware is available again at some point, and the problem recurs,
please reopen the report and we can try to continue troubleshooting.

Thanks.

Reopening 

     ------- Additional Comments From chinen.com  2003-03-03 07:07 -------
Thanks to David, I was able to reproduce this bug.

The answer against RedHat's question in Comment #17 is `sawfish'.

(RedHat's Question)
| What is hanging,
| the X client, or the entire system, and if the entire system, which system
| is hanging, the s390, or the one running the X server?

Properly speaking, sawfish is not hanging but it is killed and dumps a core file.
I'll be writing the way of reproducing in the next comment.

------- Additional Comment #24 From Mitsuru Chinen  2003-03-03 09:02 -------

Synopsis:
Sawfish is killed and dumps core with resizing a window on s/390x


Environment:
[s/390x machine]
 OS: Red Hat Linux release 7.1 (Seawolf) for S390x (Under VM)
 kernel : 2.4.9-37 #1 SMP Sat Apr 13 05:45:12 EDT 2002
 Concerned Packages :
   XFree86-xdm-4.0.3-22.71.1sx.s390x.rpm
   gnome-core-1.2.4-16.s390x.rpm
   sawfish-0.36-7.s390x.rpm
   (and dependencies)
 Terminal Emulatorers :
   xterm : XFree86-4.0.3-22.71.1sx.s390x.rpm
   kterm : kterm-6.2.0-20.s390x.rpm
   gnome-terminal : gnome-core-1.2.4-16.s390x.rpm

[i686 machine]
 OS: Red Hat Linux release 8.0 (Psyche) for i686
 kernel : 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002
 Concerned Packages:
   XFree86-4.0.3-22.71.1sx.s390x.rpm
   (and dependencies)


Constitution:
o s/390x machine is a application server. gnome, sawfish and all X clients
 are executed on this machine.
o i686 machine is a X Terminal. Users operate each X client on this machine.
o Users login RedHat 7.1 for s390x from i686 machine via xdm.


Steps to Reproduce:
0. On the s/390x machine, edit the setting file of xdm to accept XDMCP session.

# diff -u Xaccess.orig Xaccess
40c40
< # *                                    #any host can get a login window
---
> *                                      #any host can get a login window

# diff -u xdm-config.orig xdm-config
28c28
< DisplayManager.requestPort:    0
---
>! DisplayManager.requestPort:  0


1. On the s/390x machine, change the desktop environments into Gnome.
 $ switchdesk GNOME

2. On the s/390x machine, boot xdm up.
 $ su -
 # xdm

3. On the i686 machine, connect s/390x machine via XDMCP session.
 $ X -query (s/390x hostname)

4. On the i686 machine, login to the RedHat s/390x through xdm.

5. After sawfish boots, open an terminal emulator like "xterm",
  "kterm" or "gnome-terminal".

6. Resize the application frame of the terminal emulator.
  Then the terminal emulator hangs up and sawfish is killed with
  dumping a core file.                  <-- Problem!!!


Actual Results:
Sawfish is killed.
Although X clients are alive, they don't answer the user's
operation because window manager is dead.


Expected Results:
Sawfish should be alive even if a terminal emulator is resized.

So this isn't really an X server bug, or XFree86 bug, but rather a
sawfish bug.

Reassigning to sawfish...

s390 developers here have suggested that you give the output of lsmod, 
and that if it includes a binary-only module, you try to reproduce the 
problem without that module.

Adding comments from LTC bug
------- Additional Comment #29 From Mitsuru Chinen  2003-03-03 23:02 -------

Hello Ken,
Could you please submit the following comments?

---8<------8<---

Excuse me, but I can't understand what `binary-only module' means.
I would appreciate it if you could give me more details.

The outputs of lsmod is:
  Module                  Size  Used by    Tainted: P
  autofs                 15556   1  (autoclean)
  qeth                  174456   1  (autoclean)
  qdio                   50232   1  (autoclean) [qeth]
  ipchains               53344   0

Thank you,


------- Additional Comment #30 From Mitsuru Chinen 2003-03-04 07:08 -------

Hi Ken,
Could you please also submit the following comments to RedHat?

---8<------8<---
The root cause lurks in GNU MP library which is used by sawfish.
The latest GNU MP library (gmp-4.1.2.tar.gz) doesn't have this problem.

  GMP Download Page > http://www.swox.com/gmp/#DOWNLOAD

The reason why sawfish was killed is on copying array.
Reading the gmp-3.1.1 source code, you can find a macro named `MPN_COPY' at
the mpn_divrem function (gmp-3.1.1/mpn/divrem.c line 56).

  MPN_COPY (qp, q2p, qn);

This macro copies `qn' elements from a array `q2p' to another array `qp'.

I checked the value of the `qp' when a window was resized and found the `qp'
value was NULL. When a value is put into NULL pointer, SIGILL is generated.
As you know, the program is killed when it catchs SIGILL.

To fix this bug, I would appreciate it if you could make a new GNU MP library
packages.
Thank you,

Hi Ken,
Could you please also submit the following comments to RedHat?

---8<------8<---
The root cause lurks in GNU MP library which is used by sawfish.
The latest GNU MP library (gmp-4.1.2.tar.gz) doesn't have this problem.

  GMP Download Page > http://www.swox.com/gmp/#DOWNLOAD

The reason why sawfish was killed is on copying array.
Reading the gmp-3.1.1 source code, you can find a macro named `MPN_COPY' at
the mpn_divrem function (gmp-3.1.1/mpn/divrem.c line 56).

  MPN_COPY (qp, q2p, qn);

This macro copies `qn' elements from a array `q2p' to another array `qp'.

I checked the value of the `qp' when a window was resized and found the `qp'
value was NULL. When a value is put into NULL pointer, SIGILL is generated.
As you know, the program is killed when it catchs SIGILL.

To fix this bug, I would appreciate it if you could make a new GNU MP library
packages.
Thank you,

gmp is updated for our next release for mainframe, so I am closing this
report.

Thanks a lot for your bug report,

Florian La Roche