Re: Bug#397139: ftbfs alpha + ia64

[Steve Langasek <vorlon@debian.org>]

Hi Ivan,

On Mon, Nov 06, 2006 at 02:51:01PM -0500, Ivan Jager wrote:
> On Mon, 6 Nov 2006, Falk Hueffner wrote:
> >Steve Langasek <vorlon@debian.org> writes:
> >>On Sun, Nov 05, 2006 at 01:56:28PM +0100, maximilian attems wrote:
> >>>{standard input}:372: Error: macro requires $at register while noat in 
> >>>effect
> >>>make[5]: *** [arch/alpha/kernel/core_cia.o] Error 1
> >>>make[4]: *** [arch/alpha/kernel] Error 2

> >>Taking a look at the assembler output for core_cia, this is due to use of
> >>the ldbu, ldwu, stb, and stw instructions in asm-alpha/compiler.h, which 
> >>are
> >>instructions specific to ev56 and above.  They are also guarded in the
> [...]
> >>Since the errors from the assembler really indicate that these 
> >>instructions
> >>are not supported by the ev5 (gcc-4.0 has the same problem assembling the
> >>gcc-4.1 output as gcc-4.1 itself does, due to the .arch ev5 declaration),
> >>and this kernel code hasn't changed recently that I see, it seems to be 
> >>the
> >>case that ev5 processors are already unsupported by the current kernel in
> >>etch.  Given that no one has complained about this to date (at least that
> >>I'm aware of), is it time to explicitly bump the baseline on alpha to ev56
> >>for etch?

> >I'm not opposed to this, in fact I was planning to suggest this for
> >etch+1. However, this particular problem should be reasonably easy to
> >fix, so if anybody speaks up for ev5, we should give it a try...

> I'm running a DNS server on an EV5. (AlphaStation 500/333) It's running 
> unstable, but on an old, self-compiled kernel, so I haven't had trouble 
> yet.

> I don't know of anyone else running Debian on an EV5, and I don't really 
> have a strong reason for continuing to use this box over an EV56 or even a 
> different arch.

> I'll gladly test debian kernels, and keep it more up to date, if that 
> would be useful.

Yes, if you could test the etch or sid kernel (linux 2.6.17 or 2.6.18) on
your ev5 system to indicate whether these illegal instructions are a problem
in practice[1], that would be appreciated.

Given that you mention you're not running a Debian kernel at all right now,
and that this code is in place upstream and nobody else seems to have
complained loudly enough to get it fixed, I'm not sure how much effort we'll
want to put into it if it turns out to not work on ev5, but it will still be
good to know -- and if the kernel *does* work for you, that's a good reason
to find a solution other than switching the kernel to build ev56 code. :)

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/