Bug#569594: git t7400.24 is failing again

[Stephen Powell]

# I have to admit I’m mystified, since nothing has changed recently
# in this area of the git source code.
# Porters, has anything possibly relevant (configuration changes?)
# happened recently?
#
# Please send follow-ups to the bug address.
# ok ia64 (zx6000) 1.6.5-1~bpo50+1 2010-01-19
# ok ia64 (mundy) 1.6.6.1 2010-01-28
# FAIL ia64 (alkman) 1.6.6.2 2010-02-12
# ok ia64 (alkman) 1.7.0 2010-02-16
# ok ia64 (alkman) 1.7.0 2010-02-16
# ok ia64 (alkman) 1.7.0.2 2010-03-18
# ok ia64 (caballero) 1.7.0.3 2010-03-22
# ok hppa (penalosa) 1.6.6.1 2010-01-28
# FAIL hppa (peri) 1.6.6.2 2010-02-13
# ok hppa (peri) 1.7.0 2010-02-16
# ok hppa (peri) 1.7.0 2010-02-16
# ok hppa (penalosa) 1.7.0.2 2010-03-18
# ok hppa (peri) 1.7.0.3 2010-03-22
# ok s390 (lxdebian) 1.6.6.1 2010-01-28
# ok s390 (zandonai) 1.6.5-1~bpo50+1 2010-02-01
# FAIL s390 (zandonai) 1.7.0~rc2 2010-02-13
# ok s390 (debian-31) 1.7.0 2010-02-16
# FAIL s390 (lxdebian) 1.7.0.2 2010-03-18
# FAIL s390 (lxdebian) 1.7.0.3 2010-03-22
# Other platforms are fine.
reopen 569594
found 569594 git-core/1:1.7.0.2-1
found 569594 git-core/1:1.7.0.3-1
thanks
I am trying to reproduce on S/390 with hercules, but it is very slow.

The only thing I know of that changed recently is the switch
to a 64-bit kernel by the build server for s390. (I am just a regular
Joe Schmoe user. I'm not a Debian package maintainer, Debian Developer,
or any other kind of official Debian person. So consider the source.)

See bug number 573887 for a build problem that surfaced with the mozart
package that resulted from this kernel change. Whether that's your
problem or not, I have no idea. As for the other architectures, I
have no idea about them either.
--
.''`. Stephen Powell <***@wowway.com>
: :' :
`. `'`
`-

[Bastian Blank]

Post by Stephen Powell
The only thing I know of that changed recently is the switch
to a 64-bit kernel by the build server for s390. (I am just a regular
Joe Schmoe user. I'm not a Debian package maintainer, Debian Developer,
or any other kind of official Debian person. So consider the source.)

That change was done several years ago. The last buildd with a 32bit
kernel was debian01, which was discontinued over 3 years ago.

Bastian
--
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
stardate unknown.

[Stephen Powell]

Post by Bastian Blank
That change was done several years ago. The last buildd with a 32bit
kernel was debian01, which was discontinued over 3 years ago.

Hmm. Interesting. I wonder why, then, that mozart had a problem
related to this only a couple of weeks ago? (See BR 573887.)

I just realized that bug report #569594 is archived and has therefore
been silently rejecting all posts to it. I'll stick to the list
from now on unless and until Jonathan opens a new bug report.
Jonathan, I'll CC you for now, but if you are subscribed to the
debian-s390 list or otherwise read all mail to that list, let me
know and I'll drop the CC in future posts. Thanks.
--
.''`. Stephen Powell <***@wowway.com>
: :' :
`. `'`
`-

[Jonathan Nieder]

If you're using Hercules, you have to define the the machine in Hercules
as a 64-bit machine, such as a z800, z900, etc. A 64-bit kernel won't
run on an ESA/390 processor.

Probably I misconfigured it. With hercules 3.06-1.3, I tried
"ARCHMODE z/Arch" in the configuration file; the lenny installer
(which uses a 32-bit kernel) succeeded but the squeeze installer
(which uses 64-bit) failed. From

http://www.hercules-390.org/hercconf.html#ARCHMODE

I see that the IPL always uses ESA/390 mode, so I can’t tell from the
log whether this setting had the right effect.

I’ll try spending more time to track it down with Hercules 3.07
this weekend. This time I can just install the new kernel on a
working system to rule out other variables.

I just realized that bug report #569594 is archived and has therefore
been silently rejecting all posts to it.

Hmph. Appears to be confused [1]. I’ve been receiving your messages
through the Debian git packaging list, but the log as retrieved through
http://bugs.debian.org and ***@bugs.debian.org doesn’t include them.

Jonathan

[1] http://thread.gmane.org/gmane.linux.debian.devel.bugs.rc/261981

[Stephen Powell]

Post by Jonathan Nieder

If you're using Hercules, you have to define the the machine in Hercules
as a 64-bit machine, such as a z800, z900, etc. A 64-bit kernel won't
run on an ESA/390 processor.

Probably I misconfigured it. With hercules 3.06-1.3, I tried
"ARCHMODE z/Arch" in the configuration file;

I don't use hercules, but that sounds right. Perhaps there are
other relevant settings too. I don't know. Someone who knows
Hercules please help out here.

Post by Jonathan Nieder
the lenny installer
(which uses a 32-bit kernel) succeeded but the squeeze installer
(which uses 64-bit) failed.

Hmm. Well, I used a "daily-build" Squeeze/Sid installer for the s390
architecture a couple of months ago, which used a 2.6.30-2-s390x
kernel in the installer itself, if I'm not mistaken, and it worked
fine. But then again, I ran it in a virtual machine under z/VM
running in an LPAR on a real mainframe, not under Hercules.

Post by Jonathan Nieder
From http://www.hercules-390.org/hercconf.html#ARCHMODE
I see that the IPL always uses ESA/390 mode, so I can’t tell from the
log whether this setting had the right effect.

An IPL includes an initial CPU reset, which does put the processor
into an ESA/390 compatibility mode at boot time. But if you boot
a 64-bit kernel, the kernel will switch the processor to z/Architecture
mode very early on in the boot process via a SIGP order. If this
order is issued on a z/Architecture-capable processor, the SIGP
order will work. If this order is issued on a non-z/Architecture-
capable processor, the SIGP order fails, the kernel detects the
failure, and promptly commits suicide. A 31-bit kernel never
attempts to issue that SIGP order and continues running happily
in ESA/390 compatibility mode.

Post by Jonathan Nieder
I’ll try spending more time to track it down with Hercules 3.07
this weekend. This time I can just install the new kernel on a
working system to rule out other variables.

If your "working system" is on an ESA/390 processor, the 64-bit
kernel will die a spectacular death! The processor must be
64-bit capable, even though it starts out in ESA/390 compatibility
mode at boot time, in order for that SIGP order to work.

Post by Jonathan Nieder

I just realized that bug report #569594 is archived and has therefore
been silently rejecting all posts to it.

Hmph. Appears to be confused [1]. I’ve been receiving your messages
through the Debian git packaging list, but the log as retrieved through
[1] http://thread.gmane.org/gmane.linux.debian.devel.bugs.rc/261981

That makes sense. The bug tracking system continues to act as the
mail forwarding agent, but actual posts to the bug log are rejected.
--
.''`. Stephen Powell <***@wowway.com>
: :' :
`. `'`
`-

[Jonathan Nieder]

ok ia64 (zx6000) 1.6.5-1~bpo50+1 2010-01-19
ok ia64 (mundy) 1.6.6.1 2010-01-28
FAIL ia64 (alkman) 1.6.6.2 2010-02-12
ok ia64 (alkman) 1.7.0 2010-02-16
ok ia64 (alkman) 1.7.0 2010-02-16
ok ia64 (alkman) 1.7.0.2 2010-03-18
ok ia64 (caballero) 1.7.0.3 2010-03-22
ok hppa (penalosa) 1.6.6.1 2010-01-28
FAIL hppa (peri) 1.6.6.2 2010-02-13
ok hppa (peri) 1.7.0 2010-02-16
ok hppa (peri) 1.7.0 2010-02-16
ok hppa (penalosa) 1.7.0.2 2010-03-18
ok hppa (peri) 1.7.0.3 2010-03-22
ok s390 (lxdebian) 1.6.6.1 2010-01-28
ok s390 (zandonai) 1.6.5-1~bpo50+1 2010-02-01
FAIL s390 (zandonai) 1.7.0~rc2 2010-02-13
ok s390 (debian-31) 1.7.0 2010-02-16
FAIL s390 (lxdebian) 1.7.0.2 2010-03-18
FAIL s390 (lxdebian) 1.7.0.3 2010-03-22

ok s390 (hercules.local) 1.7.0.3 2010-03-26

I am trying to reproduce on S/390 with hercules, but it is very slow.

Can’t reproduce here, unfortunately. Probably something in the buildd
setup (available memory? threads?) triggers it.

Therefore if anyone has a system that can reproduce this failure, I
would be very happy. Simple recipes to try out:

setup:

curl http://kernel.org/pub/software/scm/git/git-1.7.0.3.tar.bz2 |
tar -xf - &&
cd git* &&
echo NO_CURL=1 >config.mak &&
echo NO_EXPAT=1 >>config.mak &&
make; # or make -j20, or whatever is most convenient

run the failing test:

(cd t && sh -x t7400-submodule-basic.sh -v -i)

run all tests:

make test

I would be happy if some DD could find time to try this out on zelenka [1].
Similarly, results (positive or negative) from any z/Arch user with time to
try it out on a private machine would be welcome.

Regards,
Jonathan

[1] http://db.debian.org/machines.cgi?host=zelenka