Re: problems with mips builds on ball (potential mass give-back)
On 2012-07-14 23:56:02 (+0100), Simon McVittie <smcv@debian.org> wrote:
> (Re-sending to a wider audience than mips@b.d.o, with more information and
> a somewhat complete list of give-backs.)
>
> ball.debian.org seems to be rather unhappy. My recent dbus upload failed
> with this in the log:
>
> ../../dbus/dbus-transport.c: In function
> '_dbus_transport_get_is_authenticated':
> ../../dbus/dbus-transport.c:788:1: internal compiler error: Segmentation
> fault
> [... log noise from a parallel compilation omitted ...]
> The bug is not reproducible, so it is likely a hardware or OS problem.
>
> I assume that last line means that recent gcc automatically retries
> compilations that failed with a segfault, to see whether they work the
> second time?
>
> It's not the only package in a similar situation: when I picked some examples
> at random, nipy's tests segfaulted, and nmap and gamera
> suffered an unreproducible compiler segfault similar to dbus. Each of
> those packages built successfully on the other architectures.
>
> Ben Hutchings reported a similar problem on kernel backport builds
> <https://lists.debian.org/debian-kernel/2012/07/msg00105.html>.
>
> I've attempted to provide a list of affected packages in sid (by looking at
> buildd.debian.org, I know nothing about most of these packages). See below
> for that; it's a list of gb commands which can be given when ball has been
> repaired or removed from service. I haven't done this for any other suites
> so far, but ball appears to build at least squeeze-backports too.
>
> The list does not include builds on ball which failed for similar reasons
> on other architectures, on the assumption that those are more likely to be
> package bugs.
>
> This could be rather unfortunate for packages' testing migration, which
> is why I've cc'd the release team.
>
I have been looking at the kernel logs, but I haven't noticed any messages
hinting to a kernel problem. It doesn't help that the log is filled with:
[4749162.188000] lvremove: sending ioctl 20001261 to a partition!
and
[4749178.956000] lvcreate: sending ioctl 20001261 to a partition!
Ofcourse a broken RAM chip can't be ruled out. I don't think we have ECC memory
on ball.
Cheers,
Peter.
Reply to: