Could you please re-test with this patch applied?
It turned out that this patch did not make much difference. the step-simple is
still failing with the patch applied. It could be reproduced a few times after
a fresh reboot. The test exited with 1 here,
/* Known bug in 2.6.28-rc7 +
On 12/22, caiq...@redhat.com wrote:
The following are testing results on s390x kernels build from the source,
http://kojipkgs.fedoraproject.org/packages/kernel/2.6.32.2/14.fc13/src/kernel-2.6.32.2-14.fc13.src.rpm
without and with CONFIG_UTRACE using the latest ptrace-utrace git tree.
On 12/22, Oleg Nesterov wrote:
On 12/22, caiq...@redhat.com wrote:
and a different syscall number when syscall-from-clone failed.
This is not clear to me, will take a look.
Should I say I know nothing about s390 and can't read its asm?
First of all, I think syscall-from-clone is wrong on
On 12/22, Oleg Nesterov wrote:
On 12/22, Oleg Nesterov wrote:
and I don't know whether it is OK or not that syscall-from-clone
sees different -orig_gpr2 after return from fork() on s390
-unexpected syscall 0x5ee9 without utrace
+unexpected syscall 0
Damn, my fault. I forgot to cc you when I sent the fix for s390 (attached
below), and I forgot to remind you about this fix when we discussed the
testing on s390.
That change is upstream for 2.6.33 now. I'll cherry-picked it into
the 2.6.32/tracehook branch so it will be in the backport
Oh. I am still trying to parse arch/s390/kernel/entry.S to understand
how can we fix these test-cases. I think I need the help, will continue
tomorrow.
Martin Schwidefsky schwidef...@de.ibm.com is the s390 arch maintainer.
He is friendly and helpful. You can ask him for help both with
