Description of problem:
/usr/bin/amtu hangs while running in the domU or on a dom0. It runs fine on all
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install RHEL5 GA with xen. Run the /usr/bin/amtu application.
System starts the test but just hangs.
If for some reason the application can't support xen then it should detect that
and exit. It should not hang.
This is causing RHTS failures.
This would be indicating that the Xen kernel has a problem. Whoever maintains
that kernel should be cc'ed or this bz transferred to them.
The test logs show this:
4gb seg fixup, process prelink (pid 19553), cs:ip 73:080a288c
printk: 338 messages suppressed.
4gb seg fixup, process prelink (pid 19553), cs:ip 73:08084338
printk: 20 messages suppressed.
Is prelink not working? Are there AVC's that denied prelink from running?
Do you have any idea where its hanging? Is this prelink failure related in any way?
I don't know if it is related. I think it would be best/fastest to bring up
a test system and duplicate the issue. It happenes every time. You can use RHTS
and run the reserve workflow to get a test box if you don't have one available.
I installed the xen kernel and set it to be default kernel on boot
[root@ibm-taroko ~]# /usr/bin/amtu
Executing Memory Test...
Memory Test SUCCESS!
Executing Memory Separation Test...
Memory Separation Test SUCCESS!
Executing Network I/O Tests...
Network I/O Controller Test SUCCESS!
Executing I/O Controller - Disk Test...
I/O Controller - Disk Test SUCCESS!
Executing Supervisor Mode Instructions Test...
Privileged Instruction Test SUCCESS!
[root@ibm-taroko ~]# uname -r
[root@ibm-taroko amtu]# make run
No Build required using version packaged in distro
***** Starting the runtest.sh script *****
***** Current Running Kernel Package = kernel-xen-2.6.18-34.el5.x86_64 *****
***** Current Running AMTU Package = amtu-1.0.4-4.x86_64 *****
***** Current Running Distro = Red Hat Enterprise Linux Server release 5 *****
***** End of runtest.sh *****
I haven't tried a guest OS. Maybe the kernel got horked up from other tests and
that caused amtu to appear to fail?
Created attachment 160032 [details]
tries to cause a segfault
This problem only exists on 32-bit xen kernels (dom0 and domU). I have narrowed
the problem to the kernel itself by running a simple testcase (stolen from the
amtu source code).
The testcase just calls 'asm("HLT\n\t")' and expects a segfault but instead hangs.
The backtrace looks like this for process 'don':
don T 00000640 2840 28197 27623 (NOTLB)
ea11dec0 00000282 5c6834fd 00000640 00000001 00000001 eab0d000 c0c33550
6080c5bc 00000640 041890bf eab0d10c c10092c0 00000005 00101734 00000014
c05fcf2f ea11dfbc 00030001 00000001 c042a916 00000000 ecb023c0 00000000
Re-assigning this bz to the xen-kernel team.
This request was previously evaluated by Red Hat Product Management
for inclusion in the current Red Hat Enterprise Linux release, but
Red Hat was unable to resolve it in time. This request will be
reviewed for a future Red Hat Enterprise Linux release.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
An execshield patch for 32 bit Xen went into the RHEL tree recently. Can you verify whether this bug still happens with RHEL 5.3?
It looks like it has been working OK for a while now. Actually it is good with RHEL5.2. I think the issue is resolved.
In case you are interested. Here is a link to all the test passes in the last year on the machine that showed the issue.
I believe we can close this as resolved.