Re: Help with slicer FTBFS on alpha - #548500

[Falk Hueffner]

On Tue, Sep 29, 2009 at 01:32:35AM -0300, Nelson A. de Oliveira wrote:

> I couldn't get anything useful from Google on this one. Can somebody
> give some light about the "got subsegment exceeds 64K" problem from
> #548500, please?

It basically means that there are too many symbols in this file. Try
dividing it into two smaller files.

  Falk


-- 
To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Architecture usertags

[Falk Hueffner]

On Tue, Mar 03, 2009 at 08:52:03PM +0100, Wouter Verhelst wrote:
> After a short discussion on IRC, we came up with another option: a set
> of publically documented usertags, the definition of which would be
> announced on debian-devel-announce and linked to from the BTS homepage,
> so that maintainers could apply them to architecture-specific bugs when
> necessary. The format, suggested by Steve Langasek, was to use the
> porters mailinglist as the user, and the architecture name as the
> usertag (e.g., 'debian-m...@lists.debian.org' as user, and 'm68k' as
> tag).

For Alpha, there is already something like this, although with several
tags documented here: http://wiki.debian.org/AlphaBugs

  Falk


-- 
To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [BUGS] Test suite fails on alpha architecture

[Falk Hueffner]

Tom Lane <[EMAIL PROTECTED]> writes:

> All the other diffs that Martin showed are divide-by-zero failures,
> and I do not see any of them on Gentoo's machine.  I think that this
> must be a compiler bug.  The first example in his diffs is just
> "select 1/0", which executes this code:
>
> int32arg1 = PG_GETARG_INT32(0);
> int32arg2 = PG_GETARG_INT32(1);
> int32result;
>
> if (arg2 == 0)
> ereport(ERROR,
> (errcode(ERRCODE_DIVISION_BY_ZERO),
>  errmsg("division by zero")));
>
> result = arg1 / arg2;
>
> It looks to me like Debian's compiler must be allowing the division
> instruction to be speculatively executed before the if-test branch
> is taken.  Perhaps it is supposing that this is OK because control
> will return from ereport(), when in fact it will not (the routine
> throws a longjmp).  Since we've not seen such behavior on any other
> platform, however, I suspect this is just a bug and not intentional.

Can you create a stand-alone testcase for this?

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: __divq et.al

[Falk Hueffner]

Camm Maguire <[EMAIL PROTECTED]> writes:

> Greetings!  Is there any way I can instruct gcc not to put these
> hidden library calls into the .o output? 

No. The Alpha CPU does not have an integer division instruction, so a
libcall is needed. (Incidentally, I have a patch that makes gcc emit
code that uses the FPU instead (at least for 32 bit ops), but that's
not part of mainstream gcc.)

> GCL needs a permanent address for them, which is problematic as they
> are in a shared lib, yet I cannot redirect the call through a
> pointer at the C level (there is no call at the C level), nor is it
> clear how to provide a stationary wrapper/trampoline, as the (C)
> call semantics are opaque (to me).

I don't think I really understand the issue. Is it that the code must
not use use any symbol from a shared library whatsoever? Then why is
that and can't it be fixed? And if so, how would a wrapper work
anyway?

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: gclcvs build failure on alpha

[Falk Hueffner]

Camm Maguire <[EMAIL PROTECTED]> writes:

> Greetings!  As we are short of alpha machines, could someone please
> help me understand this alpha specific problem?  Does the library have
> a different name on alpha?
>
> ;; Loading boot.lisp
> ;; Compiling ../lsp/gcl_listlib.lsp.
> Warning: NTH-VALUE is being redefined.
> ;; End of Pass 1.  
>
> Error: ERROR "dlopen faiure on \"libc.so.6\""
> Signalled by DLOPEN.
> ERROR "dlopen faiure on \"libc.so.6\""

Yes, it's called libc.so.6.1 on Alpha, and also on ia64 AFAIK.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Page coloring

[Falk Hueffner]

"Rafael Ruiz" <[EMAIL PROTECTED]> writes:

> Does anybody knows if linux kernel has implemented page coloring
> optimization?

This is the wrong mailing list for your question.

Anyway, no, it doesn't. It probably will never have, since the
increasing associativity of caches makes it less profitable. There
were some patches in the past, though.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: errors on kernel compile?

[Falk Hueffner]

Harmon Seaver <[EMAIL PROTECTED]> writes:

>Not just on this same driver. If I restart make, it then compiles
> that part okay and moves on.

This indicates a hardware problem.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: floor() broken on EV4?

[Falk Hueffner]

[EMAIL PROTECTED] writes:

> In tracking down issues with ganglia/rrdtool, I found that floor()
> is not working properly in testing on my Avanti - it always seems to
> return zero:
>
> [EMAIL PROTECTED]:~$ cat junk.c
> #include 
> #include 
>
> int main()
> {
>   double x = 1.1;
>
>   printf("floor(%f) = %f\n", x, floor(x));
>
>   return(0);
> }
> [EMAIL PROTECTED]:~$ gcc junk.c -o junk -lm
> [EMAIL PROTECTED]:~$ ./junk
> floor(1.10) = 0.00
>
> The same code on EV56 produces the expected result.  
>
> Anyone have any ideas or recommendations?

The EV4 FPU cannot round to minus infinity, as glibc's floor wants to
do, so the kernel emulates this. So it's almost certainly a kernel
bug. Can you show the output of this program:

#include 

int main() {
union { double x; unsigned long i; } u;
asm ("cvttq/svm %1,%0" : "=f"(u.x) : "f"(1.1));
printf("%016lx\n", u.i);

u.i = 1;
asm ("cvtqt/m %0,%0" : "=f"(u.x) : "f"(u.x));
printf("%e\n", u.x);

return 0;
}

?

BTW, are you really still working with these machines? I was planning
on suggesting to drop EV4 support for lenny, because I couldn't really
imagine anybody still using them with a current Debian system...

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: build failure of CppUnit

[Falk Hueffner]

Steve Robbins <[EMAIL PROTECTED]> writes:

> Quoting Falk Hueffner <[EMAIL PROTECTED]>:
>
>> "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
>>
>>> A new upload of CppUnit with a tiny bugfix is failing in a
>>> completely different region of the code.  Thus I expect it is a
>>> toolchain problem. Could one of you have a look?
>>
>> From my experience, it might as well be bug in the program.
>
> You could be right.  I already explained why I think this is not the case.
>
> It should be trivial for someone with an alpha machine to
> pull down the older version and try to build it.

You seem to think that a source working with one version of the
toolchain, but not another, indicates a toolchain bug. This is not the
case. If the code exhibits undefined behavior, the problem might show
up or not based on minor changes in either the toolchain or the
source. So the experiment you suggest does not help to learn the
source of the problem.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: build failure of CppUnit

[Falk Hueffner]

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:

> A new upload of CppUnit with a tiny bugfix is failing in a
> completely different region of the code.  Thus I expect it is a
> toolchain problem. Could one of you have a look?

>From my experience, it might as well be bug in the program. It would
be much more likely for you to get help if you could provide a
stand-alone testcase that clearly demonstrates it's a toolchain bug.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#397139: ftbfs alpha + ia64

[Falk Hueffner]

Steve Langasek <[EMAIL PROTECTED]> writes:

> 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. :)

It should work, the code is guarded to be only executed on ev56+. See
also the thread

http://gcc.gnu.org/ml/gcc/2005-07/msg00371.html

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: gclcvs

[Falk Hueffner]

Camm Maguire <[EMAIL PROTECTED]> writes:

> Greetings!  The package builds fine, it appears.
>
> 1) could you please install fakeroot

done

> 2) I can make and upload by-hand builds if someone tells me they will
>be installed.  acl2/hppa and maxima/ppc uploads have thus far been
>ignored.

I don't think that's a good idea, it could lead to trouble with
security updates.

> 3) Is my success a sign that this machine is trailing sid in some
>critical installed packages?

It was up-to-date as of about 3 days ago... I've now updated it to the
latest ftp.de.debian.org state.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#397139: ftbfs alpha + ia64

[Falk Hueffner]

Steve Langasek <[EMAIL PROTECTED]> 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
> source by an #if !defined(__alpha_bwx__).  It looks like the difference is
> in the assembler between gcc-4.0 and gcc-4.1; specifically, gcc-4.1 emits a
> '.arch ev5' directive, where gcc-4.0 does not.

I made a patch against gcc to suppress gcc outputting .arch directives
that don't do anything useful except triggering this error, and it
went in in 4.1.1ds2-17. Unfortunately, I thought an .ev4 directive
would be the problem, while it seems to be .ev5. This updated patch
instead of alpha-no-ev4-directive.patch should help:

--- gcc/config/alpha/alpha.c.orig   2006-11-06 09:59:12.0 +0100
+++ gcc/config/alpha/alpha.c2006-11-06 09:59:06.0 +0100
@@ -9353,7 +9353,7 @@
 fputs ("\t.set nomacro\n", asm_out_file);
   if (TARGET_SUPPORT_ARCH | TARGET_BWX | TARGET_MAX | TARGET_FIX | TARGET_CIX)
 {
-  const char *arch;
+  const char *arch = NULL;
 
   if (alpha_cpu == PROCESSOR_EV6 || TARGET_FIX || TARGET_CIX)
arch = "ev6";
@@ -9361,12 +9361,9 @@
arch = "pca56";
   else if (TARGET_BWX)
arch = "ev56";
-  else if (alpha_cpu == PROCESSOR_EV5)
-   arch = "ev5";
-  else
-   arch = "ev4";
 
-  fprintf (asm_out_file, "\t.arch %s\n", arch);
+  if (arch)
+fprintf (asm_out_file, "\t.arch %s\n", arch);
 }
 }
 #endif


> 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...

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: GCL/maxima/axiom/acl2, denormalized floats, and alpha

[Falk Hueffner]

Camm Maguire <[EMAIL PROTECTED]> writes:

> Casting the smallest denormalized shortfloat to a double in a function
> argument is destroying the number in the callee.  Do you know of a
> workaround? 

What kind of machine is this on? Might also be a kernel bug. Do you
have a stand-alone testcase?

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: gnucash on alpha

[Falk Hueffner]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> The Gnome-2 version of gnucash seems to have a grave bug on alpha
> which did not exist in the old gnome-1 version.  I would much
> appreciate it if the alpha porting team (that is, you guys) could
> work on it.  I do not subscribe to debian-alpha, so please keep me
> on any relevant CCs.
>
> At the very least, I would appreciate it if you could verify whether
> the bug is reproducible or not.
>
> See bug #378346 for the bug report.

I can reproduce it. I don't have time at the moment to debug it, but I
can give you an account if you're interested.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: xorg 7.0 and Radeon 7500

[Falk Hueffner]

[EMAIL PROTECTED] (Bob Tracy) writes:

> As an aside, a definitive opinion that Xorg 7.0.X is badly broken would
> be disappointing, but useful.  In that case, what's the recommended
> procedure to downgrade to something that's known to work, and what is
> the latest something that works?

You can use an older snapshot:

deb http://snapshot.debian.net/archive/2006/04/11/debian sid main
deb-src http://snapshot.debian.net/archive/2006/04/11/debian sid main

Then remove all traces of the X server and install it again... There's
probably no smoother way.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Helix Player

[Falk Hueffner]

[EMAIL PROTECTED] (Bob Tracy) writes:

> Anyone working on this?  Version 1.0.4 might be doable if the
> dependencies on the Tru64 native compiler (ccc) could be eliminated.
> Specifically, it looks like common/include/atomicbase.h needs to have
> a "#elif defined (__alpha) && defined (__GNUC__)" section written to
> be used instead of the existing  "#elif defined (__alpha)" code.

I wrote a patch that does just that (see bug #337867). However, I
never really tested it and I think there were some other problems...
Is there anything that Helix Player can play that mplayer cannot? I
thought not, which is why I didn't follow this anymore...

By the way, the correct way to fix this would be to rip out all of the
architecture-specific cruft in atomicbase.h and use gcc atomic
builtins, which are present from 4.1 on.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: obexftp_0.19-3 fails to compile

[Falk Hueffner]

Hendrik Sattler <[EMAIL PROTECTED]> writes:

> gp-relative relocation against dynamic symbol cobex_handleinput
> /usr/bin/ld: final link failed: Nonrepresentable section on output
>
> Any ideas? Note that libobexftp, libmulticobex and libbfb are compiled as 
> static libs only.

You cannot create a shared library from objects that weren't build
with -fPIC.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: EV67 optimized libc6.1

[Falk Hueffner]

Aurelien Jarno <[EMAIL PROTECTED]> writes:

> - For people having an EV67 compatible CPU, please install 
>   libc6.1-alphaev67 and verify it is used. You can see that using ldd, 
>   for example: 
>   'ldd /bin/ls'. It should uses libraries from /lib/ev67/

It's not being used:

[EMAIL PROTECTED]:/# dpkg -l libc6.1\* | grep ii
ii  libc6.1   2.3.6-6+ev67   GNU C Library: Shared libraries
ii  libc6.1-alphaev67 2.3.6-6+ev67   GNU C Library: Shared libraries (EV67 optim

[EMAIL PROTECTED]:/# ldd /bin/ls
librt.so.1 => /lib/librt.so.1 (0x0202c000)
libacl.so.1 => /lib/libacl.so.1 (0x02056000)
libselinux.so.1 => /lib/libselinux.so.1 (0x0207)
libc.so.6.1 => /lib/libc.so.6.1 (0x0209a000)
libpthread.so.0 => /lib/libpthread.so.0 (0x02214000)
/lib/ld-linux.so.2 (0x0200)
libattr.so.1 => /lib/libattr.so.1 (0x022be000)
libdl.so.2.1 => /lib/libdl.so.2.1 (0x022d4000)
libsepol.so.1 => /lib/libsepol.so.1 (0x022ea000)

I'm not sure why... The library as such works, though:

[EMAIL PROTECTED]:/# LD_LIBRARY_PATH=/lib/ev67 ldd /bin/ls
librt.so.1 => /lib/ev67/librt.so.1 (0x0202c000)
libacl.so.1 => /lib/libacl.so.1 (0x02056000)
libselinux.so.1 => /lib/libselinux.so.1 (0x0207)
libc.so.6.1 => /lib/ev67/libc.so.6.1 (0x0209a000)
libpthread.so.0 => /lib/ev67/libpthread.so.0 (0x02226000)
/lib/ld-linux.so.2 (0x0200)
libattr.so.1 => /lib/libattr.so.1 (0x022d)
libdl.so.2.1 => /lib/ev67/libdl.so.2.1 (0x022e6000)
libsepol.so.1 => /lib/libsepol.so.1 (0x022fc000)
[EMAIL PROTECTED]:/# LD_LIBRARY_PATH=/lib/ev67 ls
bin   dev  homelibmnt  proc  sbin  srv  tmp  var
boot  etc  initrd  media  opt  root  src   sys  usr


-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: EV67 optimized libc6.1

[Falk Hueffner]

Aurelien Jarno <[EMAIL PROTECTED]> writes:

> As requested a long time ago in the BTS (bug #229251), I have built 
> an EV67 optimized version of the glibc.

It depends on "tzdata", which doesn't seem to be available anywhere
(http://people.debian.org/~aurel32/tzdata/ is 404).

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: em86

[Falk Hueffner]

Nipper <[EMAIL PROTECTED]> writes:

> Out of curiousity, does qemu run on Alpha? This would also provide
> an x86 emulation environment.

It used to almost work a while ago, but nontrivial programs would
frequently crash and nobody debugged it. By now, it has probably also
bitrot somewhat.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: NSF and compiling kernel

[Falk Hueffner]

Harmon Seaver <[EMAIL PROTECTED]> writes:

>Since I don't have enough drive space on my multia, I nfs mounted the
> space from my debian intel box, downloaded the kernel source, and tried
> to run make menuconfig. I've got the nsf mount "rw" both on the intel
> end and on the multia end, but it still won't let me delete files or
> make links. Here's my /etc/exports file:
> # /etc/exports: the access control list for filesystems which may be
> exported
> #   to NFS clients.  See exports(5).
> /xtra/scuz/src  192.168.2.100 (rw,no_root_squash)

That exports /xtra/scuz/src to two machines: one called 192.168.2.100,
and one called (rw,no_root_squash). So, there must be no space.

This is a very, very frequent mistake. It would be nice if you could
take the time to file a bug report and ask for clearly pointing this
out in the /etc/exports file comments, the exports(5) man page, and
also that it produces something useful in the log files.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: BTS usertags for Alpha specific bugs

[Falk Hueffner]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Since in 2.6 the kernels are all built from the linux-2.6 package,
> might it not be a good idea to tag these as well?

Probably yes, I have a partial list somewhere, so I might do this.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: BTS usertags for Alpha specific bugs

[Falk Hueffner]

Steve Langasek <[EMAIL PROTECTED]> writes:

>> I scanned the BTS for Alpha specific bugs (by looking for those
>> reported on an Alpha machine, or with "alpha" in the subject). I'm
>> planning to use usertags with user debian-alpha@lists.debian.org to
>> record this. I would use the following tags:
>
> You didn't mention what "user" you'll be using for these usertags.
> It was probably the obvious choice, but just in case, may I suggest
> using [EMAIL PROTECTED]

Yes, that's just what I thought of :-)

> I would like to see some tagging mechanism for bugs that are general
> 64-bit bugs as well, so we could theoretically spread the load on
> these between porters for all three archs.

Seems like a good idea. Maybe somebody[tm] can post a proposal to the
appropriate lists...

> BTW, given that most of the cases of "broken" packages *should* be
> turned into FTBFS bugs by the maintainer in the absence of any other
> action by the porters, I would suggest this is the appropriate
> category for FTBFS bugs even if we aren't planning to proactively
> usertag them.

Thinking of it, it might be clearest to just have a "ftbfs" tag. I've
set up a Wiki page at http://wiki.debian.org/AlphaBugs and tagged the
list I sent. Everybody, feel free to change/add...

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

BTS usertags for Alpha specific bugs

[Falk Hueffner]

Hi,

I scanned the BTS for Alpha specific bugs (by looking for those
reported on an Alpha machine, or with "alpha" in the subject). I'm
planning to use usertags with user debian-alpha@lists.debian.org to
record this. I would use the following tags:

brokenunusable on Alpha
buggy buggy on Alpha
maybe might be Alpha specific, but this has not been verified
  (might be just a generic 64-bit bug). Somebody with an AMD64
  should check these
hardware  This requires particular hardware to be reproduced.

I'm not tagging FTBFS, because they can be better tracked at
http://buildd.debian.org/~jeroen/status/architecture.php?a=alpha, and
also not bugs for Alpha-specific packages like aboot.

I'd be interested in feedback... here's the list:

broken

 68213 jvim on Alpha/AXP responds only once per 4 key strokes
103606 Flightgear gives floating point exception on Alpha
135925 jfbterm: broken on Alpha
145542 gtkpool: Floating point exception on Alpha
222770 prelink: Causes apt-build (perl) to segfault
269840 koules: FPE signal raised intermittently
330284 qt3-designer: crashes the X server on opening a file
335684 rrdtool graph FPE on alpha


buggy

106741 Column spacing wrong in register window on Alpha
161432 [PR target/8603] Alpha: s?addl pattern doesn't work
185865 procps: cannot parse System.map file on linux-2.2.25 on alpha
11 dhcp-client: dhclient produces unaligned traps on Alpha
212233 Member named "__align" causes conflict with Compaq C builtin
220920 Bogus information on Alpha core files
229251 libc6.1: request ev67 specific build
231862 libvorbis0a: oggenc still dies somtimes with floating point exception
263178 install deos not modify boot_dev and boot_osflags
265831 Debian kernels are unusable on TITAN-based systems because of 
LEGACY_START_ADDRESS
267465 syslog-ng: Get rid of unaligned trap on alpha
213571 modutils: unaligned trap on alpha
286262 xdebconfigurator: Some problems on Alpha
289187 clamav-daemon: Unaligned Trap on alpha
313106 openvpn has lots of unaligned traps
325600 libc6.1: Threads remain  on Alpha with libc6. 2.3.5-4
325638 please re-enable optimization for mozilla on alpha
329573 dovecot-imapd: Unaligned traps on alpha plattform
329578 xserver-xorg: Xorg causes unaligned traps (Alpha arch.)
334766 binutils: ld infinite loops on alpha
335578 ocamlopt.opt segfaults on Alpha


maybe

106656 Cannot get index with amrecover
109089 cdparanoia refuses to work on an alpha
128943 chipmunk-log: chpmnk-diglog segfaults after opening its two windows
130007 vsound: sample rate is always 44100 on alpha
140474 xmovie does not build on alpha
146305 celestia: Arithmetic exception on alpha
152128 vcg: xvcg dies with segfault when opening a vcg file
153428 tac-plus: encryption key mismatch under alpha architecture
153815 acidlab: duplicate key error
155819 gnome-pilot: gpilotd crashes when gpilot-applet starts
155857 id3v2: Segfault on alpha when adding track number ( -T option)
186882 freecraft: Crashes immediately on Alpha
193494 freeciv-server: Crashes on first client connect on alpha
194869 knocker: crash on alpha when parsing conf file.
203981 openbabel doesn't build on alpha
207056 openafs-modules-source: [alpha 2.4.19+xfs] afsd fails to start on Alpha 
with XFS-patched 2.4.19
208304 pcre doesnt work sometimes
216836 gltron: Game -> Start Game crashes gltron on alpha
264130 bind9 crashed with strange error
264806 libapache2-mod-php4: Segfault on alpha
267122 brec: does not clean up its semaphores
268298 After upgrading from a previous version on debian/alpha the user auth 
with psql doesn't work anymore 
271157 cupsys: Cannot set printer to parallel port
271330 cyrmaster does not register with snmpd on Alpha
273521 gs-esp: Fails with every document from Konqueror
278455 abiword: AbiWord 2.0.10 does not start on Alpha.
291154 acct: dates in lastcomm's output are random in alpha
299194 amarok: Crashes on Alpha
313144 mldonkey-gui: GUI crashes on startup on Alpha
314840 Watching directories broken on Alpha
325936 lam4-dev: simple example fails on Alpha


hardware

152336 xserver-xfree86: [mga] console locks up on MGA 2064W rev 1
262183 xserver-xfree86: [core server] BusID argument mandatory for PCI display 
adapters on Alpha boxen [regression from 4.2.1]
271910 xserver-xfree86: [mga] freezes, unaligned traps, and other problems on 
Alpha PWS433AU with MGA 2164W rev 0
286013 xserver-xfree86: [mga] driver locks up when XAA enabled on alpha with 
MGA G400 AGP rev 4
301344 [tga] All KDE windows are completely unreadable
320814 xserver-comm 4.3.0.dfsg: fails to run the x-windows system on alpha 
machine
334431 xserver-common-v3: Error activating XKB configuration, in an old Alpha 
workstation

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian 3.1 kde problem

[Falk Hueffner]

Hartwig Atrops <[EMAIL PROTECTED]> writes:

> Hi all.
>
> I have a weired problem on my Alphastation 500au (TGA2 graphics). I
> installed Sarge on it (twice), X11 is ok. Gnome desktop works
> fine. As well as gnome applications. But kde does not, neither kdm
> nor kde applications: the application starts, but you cannot read
> the output. Some kind of black printing on black background inside
> the kde window, only some dimly icons.  Gnome background arround the
> application is still ok.
>
> When I use the applications over the network (ssh -X), e.g. k3b, it works 
> fine !?!
>
> Could not find any hint on the net. Is this a known problem?

Sounds like http://bugs.debian.org/301344

> What to do?

You might try asking the reporter of 301344 whether he could resolve
it...


-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dcc seems unusable in sarge on alpha

[Falk Hueffner]

Adrian Zaugg <[EMAIL PROTECTED]> writes:

> Falk Hueffner wrote:
>> I get the same log message, however DCC works fine. I think it's just
>> the log message that's bogus. Why do you think it isn't working? Is
>> nothing flagged as spam?
>
> I use dcc along with pyzor, razor in spamassassin. When I look through
> the tests reported in the mail headers (e.g. grep through my spam
> folder), I never saw dcc appearing.

Maybe you're using 3.1? DCC has been disabled there by default, see
/usr/share/doc/spamassassin/NEWS.Debian.gz.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dcc seems unusable in sarge on alpha

[Falk Hueffner]

Adrian Zaugg <[EMAIL PROTECTED]> writes:

> dcc seems to be unusable on alpha: Since about 6 month dcc reports
> always: dccifd: 1.2.74 rejected messages to 0 targets and discarded
> messages to 0 targets among 0 total since 11/14/05

I get the same log message, however DCC works fine. I think it's just
the log message that's bogus. Why do you think it isn't working? Is
nothing flagged as spam?

> Every time a message is presented to dcc it produces an unaligned
> trap.  I think this is related to bug #301983. Has this something to
> do with the above described behavior?

No, that can't have any adverse effect on dcc's result.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: seti & boinc for alpha

[Falk Hueffner]

Adrian Zaugg <[EMAIL PROTECTED]> writes:

> I just got aware I compiled the package with -mcpu=ev56 which may
> mean those binaries do not run on an alpha < 21164? If this is the
> case I wonder how to use the debian package system to let it provide
> packages for different cpu subarchs. Could somebody please explain
> this to me?

The Debian packaging system has no support for this. It'd be probably
easiest to write a wrapper script that calls the correct binary.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Compilation problem

[Falk Hueffner]

emmanuel poizot <[EMAIL PROTECTED]> writes:

> relocalisation inconnue: !lituse_jsrdirect

This is a bug in the gcc package, it was missing a dependency on a
recent binutils package (http://bugs.debian.org/333954). You need at
least binutils 2.16.1cvs20050902-1.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 325600 ( threads on Alpha).

[Falk Hueffner]

Tom Evans <[EMAIL PROTECTED]> writes:

> If I simply change (in
> linuxthreads/sysdep/unix/sysv/linux/not-cancel.h) from:
>
> # define waitpid_not_cancel(pid, stat_loc, options) \
>   INLINE_SYSCALL (osf_wait4, 4, pid, stat_loc, options, NULL)
>
> to:
>
> # define waitpid_not_cancel(pid, stat_loc, options) \
>   wait4( pid, stat_loc, options, NULL )
>
> all is well

That's weird. What happens with -O0? What with gcc 3.3? Can you
perhaps attach the assembly that is generated for the "broken" case?

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Failed autobuild of geneweb. Clue?

[Falk Hueffner]

Christian Perrier <[EMAIL PROTECTED]> writes:

> (please CC me to answers)
>
> Folks,
>
> As the maintainer of the geneweb package, I'm wondering why it failed
> to autobuild
> (http://buildd.debian.org/fetch.php?&pkg=geneweb&ver=4.10-11&arch=alpha&stamp=1128979544&file=log&as=raw)

ocamlopt.opt is totally broken on Alpha, it segfaults on
everything. I'll file a bug report about that. ocamlc.opt and ocamlopt
work.

> Could some of you help me to track this down and have the package
> enter testing (maybe just re-trying would be successful?)

No, it won't. As a workaround, you could compile with ocamlopt instead
of ocamlopt.opt.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt-cache search broken?

[Falk Hueffner]

Joey Hess <[EMAIL PROTECTED]> writes:

> On my alpha I'm seeing apt-cache search segfault every time using apt
> 0.6.42 from unstable. Anyone else see this?

Yes.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Requalification of Alpha for etch

[Falk Hueffner]

John Goerzen <[EMAIL PROTECTED]> writes:

> On Sat, Oct 08, 2005 at 07:40:15PM +0200, Falk Hueffner wrote:
> I saw on the wiki page a mention that HP sells new systems at insane
> prices.  But the link didn't give pricing.  Do you know what new
> systems sell for?

I don't really recall, but it was way beyond being an actual option.

> If anybody has an Alpha, I would volunteer to install Debian on it
> and get it in working condition, and then ship it off to wherever it
> would be hosted.
>
> Do you know what the holdup is?

I guess the right combination of a good machine and (like Thimo
mentioned) hosting with a competent local admin nearby.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Requalification of Alpha for etch

[Falk Hueffner]

Hi,

following hppa and ia64, I've started a wiki page to start collecting
info for the Alpha requalification for etch:
http://wiki.debian.org/alphaEtchReleaseRecertification

AFAICS, all criteria but two are given:

* More developers need to certify in that they're activly developing
  on this architecture.

* There needs to be another buildd. There have been numerous offers in
  the past. I have no idea what to do to actually make it happen.

Please feel free to add to the wiki page, especially on these two
points.

It would also be nice if more people could install popularity-contest,
so that we get a clearer picture on the number of users.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: X.Org 6.9 Needs Your Build Logs!

[Falk Hueffner]

Julien Cristau <[EMAIL PROTECTED]> writes:

> I just tried to build xorg-x11 from current svn on alpha.
> It failed in xc/lib/GL/mesa/drivers/dri/r128/r128_ioctl.c, with what
> looks like a missing #include somewhere. I don't have the time to
> investigate right now, but will look into it next week if noone does it
> first.
> Build log is available at
> .

Where can this be obtained? I can only find 6.8.2.dfsg.1-8+SVN.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: SIGFPE

[Falk Hueffner]

Tyson Whitehead <[EMAIL PROTECTED]> writes:

> I just did an upgrade yesterday and Konqueror is SIGFPEing.  Scanned the 
> libraries for floating point use without trap statements, and there are bunch 
> of them again.  Specifically (for Konqueror):
>
> kdelibs4c2:  /usr/lib/libkutils.so.1
> kdelibs4c2:  /usr/lib/libkio.so.4
> kdelibs4c2:  /usr/lib/libkdesu.so.4
> kdelibs4c2:  /usr/lib/libkdecore.so.4
> kdelibs4c2:  /usr/lib/libkdefx.so.4
> libqt3-mt:  /usr/lib/libqt-mt.so.3
> libx11-6:  /usr/X11R6/lib/libX11.so.6
> libaudio2:  /usr/lib/libaudio.so.2
>
> I checked GCC4 (the current 4.0.2-2 release in unstable) and the '-mieee' is 
> default unless '-ffinte-math-only' (turned on by '-ffast-math') stuff is 
> still all there and working.  I scanned the source packages and couldn't find 
> any use of '-ffast-math' (other than for x86).
>
> Anyone know what is going on here?

The patch was disabled for a few weeks because it misapplied and made
bootstrap fail. It's been restored now. See also
http://bugs.debian.org/330826

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bzip2 unaligned trap

[Falk Hueffner]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Thu, Aug 25, 2005 at 09:04:06AM +0200, Uwe Schindler wrote:
>> At 08:00 25.08.2005, you wrote:
>> >With this kernel I get permanent unaligned trap errors from bzip2:
>> >bzip2(10013): unaligned trap at 020c3074: 00020c5100020c3d 28 1
>
>> >Does anyone know wether this is a hardware or software problem?
>
>> [...] But do not exspect that they fix this because alpha is not
>> the main platform and most developers do not have such a processor.
>
> Rather, do not expect this to be fixed unless you can convert the
> kernel-level trap into a userspace backtrace that the developers can
> act on.

I'd say that's the maintainer's job, not the bug reporter's. So please
report it :-)

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian 31r0a install

[Falk Hueffner]

"Ted Letofsky" <[EMAIL PROTECTED]> writes:

> Good afternoon everyone,
>
> I'm STILL playing around with Multia/UDB machines, and finally decided to
> try a fresh new install from scratch using 31r0a.
>
> I've converted to SRM and followed the instructions using both CD1 and the
> NetINST cd.
>
> In both cases, the machine simply "stops".
>
> I don't want to say "hangs" because caps lock and num lock LEDs continue to
> work.
>
> I start the machine.
> The machine has an internal ide disk (UNUSED, IGNORE IT).

Is the "console" SRM variable set correctly? It needs to be set to
"graphics" unless you use a serial console.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Request for help: unaligned trap

[Falk Hueffner]

Helge Kreutzmann <[EMAIL PROTECTED]> schrieb am 12.04.05 09:24:31:
> 
> Hello,
> On Mon, Apr 11, 2005 at 09:45:43PM -0700, Steve Langasek wrote:
> > Usually not; usually such bugs are reproducible on sparc and ia64 as well,
> > and IIRC both of those architectures are easier to debug because the trap
> > is exposed to userspace (i.e., SIGBUS), making it much simpler to get a
> > backtrace.
> 
> You can achieve this on alpha as well, several years ago people posted
> wrappers for doing this. 

Just add this code to main:

#if defined(__alpha__) && defined(__linux__)
// Deliver SIGBUS on unaligned traps instead of fixing them up.
#include 
#include 
#include 
syscall(__NR_osf_setsysinfo, SSI_NVPAIRS,
(unsigned int[]) { SSIN_UACPROC, UAC_SIGBUS | UAC_NOPRINT },
1, 0, 0, 0);
#endif



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: No more Debian/Alpha?

[Falk Hueffner]

Martin Zobel-Helas <[EMAIL PROTECTED]> writes:

> Hi Dan,
>
> On Monday, 14 Mar 2005, you wrote:
>> http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html
>
> Alpha will become SCC and will be availible via scc.d.o.

In fact, there isn't even a reason why it couldn't become a fully
supported architecture, except that there is only one buildd
currently. Unfortunately, it is not clear what would need to happen to
change that.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FTBFS gnugk 2:2.2.1-4 on alpha

[Falk Hueffner]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Attached is the final patch resulting from my investigations.  -Os
> is the culprit here, as originally suspected. :)

Can you nail it down to a particular source file? I would like to know
whether this is a gcc bug... a test case would be great.

-- 
Falk


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packages needing buildd on alpha

[Falk Hueffner]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Okay, I've found time to take a closer look at this problem, and you're
> right that it's related to configure.  Specifically, it's related to a
> buggy and unusable octave:
>
> $ octave --version
> Illegal instruction
> $ octave -q -f <> printf(octave_config_info("localfcnfilepath"));
>> EOF
> Illegal instruction
> $

I can't reproduce this with octave2.1 2.1.57-4 on an ev67. What kind
of Alpha do you have? What does gdb show on disas?

-- 
Falk

Re: Help: Perl crashes, probably pthread-problem?

[Falk Hueffner]

Helge Kreutzmann <[EMAIL PROTECTED]> writes:

> (this was reported as a bug to the BTS, but no response received). It
> is probably glibc/pthreads related.
>
> I have a small perl program
> http://bugs.debian.org/cgi-bin/bugreport.cgi/smallTest.pl?bug=243311&msg=3&att=2
>
> using a small module:
> http://bugs.debian.org/cgi-bin/bugreport.cgi/iohelp.pm?bug=243311&msg=3&att=1
>
> This perl script crashes perl. To reproduce, type/tab complete e.g.:
> [EMAIL PROTECTED]:~/prog/db/eingabe$ ./smallTest.pl
> y, Protokoll:: http
> Publisher:
> y, Protokoll:: http
> Publisher:
> y, Protokoll:: http
> Publisher:
> Speicherzugriffsfehler (core dumped)
>
> (Speicherzugriffsfehler == segmentation fault)

I can't reproduce this with perl 5.8.4-2 and libc6.1 2.3.2.ds1-13 from
sid. Can you perhaps try upgrading either?

-- 
Falk

Re: "Unaligned access" on Alpha

[Falk Hueffner]

Kelledin <[EMAIL PROTECTED]> writes:

> Hmmm...I take it that an unaligned access in kernel-land causes a
> crash/oops?

No, it gets fixed up, too.

-- 
Falk

Re: "Unaligned access" on Alpha

[Falk Hueffner]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Sun, Feb 29, 2004 at 07:38:16PM +0100, Falk Hueffner wrote:
> > Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > > As of Linux 2.6, unaligned memory access is no longer handled for you by
> > > the kernel on alpha.  These will instead generate SIGBUS errors, just as
> > > they have forever on Linux sparc.
> 
> > Are you sure? This was not the case with 2.6.0-test3, and the code
> > still seems to be there in 2.6.3 (traps.c/do_entUnaUser).
> 
> I'm not sure, as I've yet to run 2.6 on my alphas, but I have seen
> reports of SIGBUS on alpha under 2.6, which has definitely never
> happened before.  (Maybe this behavior is now optional?)

It has always been optional, you can choose to get SIGBUS with
setsysinfo. However, a default of enabling emulation seems very
sensible to me...

-- 
Falk

Re: "Unaligned access" on Alpha

[Falk Hueffner]

Kelledin <[EMAIL PROTECTED]> writes:

> Lately I've been looking closely at the compile logs on my EV56 
> box, and I've noticed a particular gcc warning occurring 
> frequently:
> 
> cast increases required alignment of target type.
> 
> This worries me almost as much as casts between integers and 
> pointers of different size, but...even with all the warnings, I 
> don't get too many crashes.

Well, not surprising, since this will only lead to a problem if a) the
pointer is actually dereferenced and b) the alignment is actually
wrong. Often this cannot occur and the warning is bogus.

> Still, I'm compelled to wonder about the effect of unaligned
> accesses, i.e. how severe is an unaligned access in user-space?  How
> about in kernel-space?  How does the system handle them?

A trap to PALcode occurs and the firmware hands over to the operating
system. The OS emulates the access and resumes the program. Takes
probably about 100-200 cycles.

> I have a pretty clear idea what it would take to fix that warning
> condition, but it occurs so frequently that I'm not sure it would be
> worth the time. :/

I don't think so, unless you actually see unaligned accesses in the
syslog.

-- 
Falk

Re: "Unaligned access" on Alpha

[Falk Hueffner]

Steve Langasek <[EMAIL PROTECTED]> writes:

> As of Linux 2.6, unaligned memory access is no longer handled for you by
> the kernel on alpha.  These will instead generate SIGBUS errors, just as
> they have forever on Linux sparc.

Are you sure? This was not the case with 2.6.0-test3, and the code
still seems to be there in 2.6.3 (traps.c/do_entUnaUser).

-- 
Falk

Re: acrobat reader

[Falk Hueffner]

Joakim Roubert <[EMAIL PROTECTED]> writes:

> Has anyone gotten some recent versions of Acrobat Reader for True64
> work with shared libraries? I run an AlphaStation 200 4/166 (EV4),
> and the latest one I've been able to run was Acrobat Reader 3.  Or
> do people recommend using xpdf or similar? (They don't seem to work
> that well here; they do work better than not at all, though. ;-)

I would recommend using xpdf. It's free, and the newest version from
unstable supports document table of contents, so I don't see any need
for Acrobat Reader any more. The author also usually fixes bugs very
quickly, so if something doesn't work be sure to file a bug report.

-- 
Falk

Re: Bug#232727: ghc6: ghci doesn't start on Alpha

[Falk Hueffner]

Ian Lynagh <[EMAIL PROTECTED]> writes:

> Of course, if anyone is familiar with these things and is willing to
> spend some time on it then that would be great! The latest version of
> the file in question is at
> http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/rts/Linker.c?rev=1.145&content-type=text/x-cvsweb-markup
> (search for R_SPARC_WDISP30 to find the relevant bit) - if you get in
> touch I can give you some more details.

You should be able to steal the appropriate bits from xfree86
programs/Xserver/hw/xfree86/loader/elfloader.c.

-- 
Falk

Re: How to handle the -mieee SIGFPE problem in normal Debian packages

[Falk Hueffner]

Dominique Devriese <[EMAIL PROTECTED]> writes:

> I'm currently looking at the following bug report
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203722 about a
> frequent SIGFPE on an alpha machine.  I guess we all know the cause
> of this bug, namely the non-standard alpha FPU semantics.
> 
> 2 make all KDE programs install a SIG_IGN SIGFPE handler.  This can be
>   done in kdelibs, and would be little work.

That ain't working, since ev4/ev5 FP exceptions are unresumable, which
is the root of all problems.

> 4 wait for the gcc alpha patch to be included into gcc, which was
>   posted on this list recently.

It has been added to the newest gcc (but not upstream), so the problem
should magically go away all by itself.

-- 
Falk

Re: Dbian Linux (woody) for AXP can't boot on DS15

[Falk Hueffner]

Alexander Strop <[EMAIL PROTECTED]> writes:

> mel kravitz wrote:
> 
> >aboot is 0.9b latest available from:
> >https://sourceforge.net/projects/aboot/
> >-mel
> >
> 
> Is aboot also used if you boot from CD?

Yes.

> I can not find aboot on Cd1 at /boot

It does not exist as a file, but raser is weaved into the image at the
hardcoded offset the SRM console expects.


-- 
Falk

Re: TLB reload code

[Falk Hueffner]

Nawab Ali <[EMAIL PROTECTED]> writes:

> I need to modify the TLB miss handler code. Basically everytime
> there is a TLB miss, I'm trying to log the new PTE that is brought
> into the TLB.
> 
> Now I know that Alpha handles TLB misses in software.  What I don't
> know is whether TLB misses are handled by the PALcode or by the OS.

PALcode.

> If TLB misses are handles by the PALcode, how do I go about
> modifying it??

I'm not sure. I suppose the architecture reference manual will tell.

-- 
Falk

Re: SYM53c8xx Panic on Boot: 2.6.1rc1 (Alpha)

[Falk Hueffner]

John Goerzen <[EMAIL PROTECTED]> writes:

> It was always my understanding that once booted, the console in use
> wouldn't matter.  Is that understanding correct?

Close. The memory wastage may be different, and you cannot use
oprofile with AlphaBios (no perfmon PALcode).

> Also, I also thought that I would have to repartition my disks to
> switch consoles; is that correct as well?

Yes, unfortunately the hardcoded place where SRM expects the boot
loader is in the middle of a DOS partition block.

-- 
Falk

Re: UML Port

[Falk Hueffner]

Joerg Hoh <[EMAIL PROTECTED]> writes:

> I want to run some virtual machines on my alpha to play around with with
> different distributions, kernel and such stuff. But noone of the popular
> emulators does imho work on linux/alpha (no emulation of the i386
> instruction set like booch does).

qemu mostly works, except it tends to crash on larger programs. Maybe
it is easy to fix.  Or maybe not; the pages being larger is a major
obstacle. Adding Alpha emulation should be pretty straight-forward...
at least for emulating userspace.

> So I asked on the uml-devel-list (user mode linux) how hard it is to
> port the uml patch to other plattforms than i386, because this
> approach seems to me to be the fastest (in terms of execution speed)
> and most generic one.  The answers were spare, and I've extracted
> from the answers, that the most problems are the plattform specific
> ones :-|

It should be easier than for other platforms, since all interaction
with the MMU and similar things (timers etc) is done via firmware
calls. So all you need to do is implement the firmware interface,
which is pretty high-level and well documented. See
ftp://ftp.compaq.com/pub/products/alphaCPUdocs/alpha_arch_ref.pdf.gz

-- 
Falk

Re: CCC/CXX installation

[Falk Hueffner]

Phil Carmody <[EMAIL PROTECTED]> writes:

> --- John Goerzen <[EMAIL PROTECTED]> wrote:
> > I noticed the same problem recently.  Go into the create-comp-config.sh
> > file and move the -v so it comes after the -V {GCC_PATH} thing.
> 
> Yup, I tried that hack myself! It kinda-sorta seemed to work.
>  
> > Also, I hacked it to call gcc instead of gcc-2.95.  You may need to make
> > a few other minor adjustments to GCC_PATH.
> 
> OK, I've not noticed anything that I can be sure is caused by that yet, but I
> am unable to build what I was trying to build :-(
> 
> ccc is complaining that 
> <<<
> ./compile speed.c
> cc: Error: /usr/include/bits/pthreadtypes.h, line 71: Invalid declarator.
> (declarator)
>   __pthread_cond_align_t __align;
> -^
> >>>
> 
> Which is being pulled in via .

See bug #212233. As a workaround, rename __align to __align_ or
whatever.

-- 
Falk

Re: MILO packages?

[Falk Hueffner]

John Goerzen <[EMAIL PROTECTED]> writes:

> I decided it was about time for me to check for updates for my
> MILO...  only to find that there are no milo packages in Debian.
> Why is this,

Nobody has produced them.

> and where might I obtain a current copy of MILO?

http://www.suse.de/~stepan/

If you're interested in building it, you should probably check out the
patches gentoo applies, there are some tunings needed to build it with
a non-SUSE kernel and modern gcc.

-- 
Falk

Re: SIGFPE resolution?

[Falk Hueffner]

Thomas Evans <[EMAIL PROTECTED]> writes:

> On Wed, 2003-11-05 at 04:12, Falk Hueffner wrote:
> > There was one suggestion to disable -mieee by -ffast-math. -ffast-math
> > also enables a *lot* of other optimizations, so if you don't want IEEE
> > compliance, you might want it anyway. Would that be acceptable to you?
> 
> I'm okay with this sugesstion, as long as Debian on Alpha enables
> fast math by exception and not as the rule.

That was the idea.

> My concern is also dependencies - people will insist on building
> glibc, etc with fast math enabled (because by default they'll work
> fine) and then some other application with throw down IEEE values to
> them an they'll crash.

AFAIK, libm from glibc is currently built IEEE compliant, and I don't
think that should change unless we introduce some mechanism to choose
a libm based on compiler flags (which would be nice, though).

-- 
Falk

Re: SIGFPE resolution?

[Falk Hueffner]

Phil Carmody <[EMAIL PROTECTED]> writes:

> --- Thomas Evans <[EMAIL PROTECTED]> wrote:
> > I really hope that no one is doing severely high
> > performance, mission critical, FP code on pre-EV6
> > alphas these days, so I really feel that defaulting
> > all Debian built Alpha images to IEEE shouldn't be
> > a big deal.
> 
> I do all of my presieving and some of my testing for 
> my PIES project on a pre-EV6 alpha. No, it's not 
> exactly mission critical, but it _is_ high performance, 
> and it is FP code. (And it doesn't depend on IEEE 
> nappy-changing as it doesn't shit itself.)

There was one suggestion to disable -mieee by -ffast-math. -ffast-math
also enables a *lot* of other optimizations, so if you don't want IEEE
compliance, you might want it anyway. Would that be acceptable to you?

-- 
Falk

Re: sound on UP1500

[Falk Hueffner]

"Peter Watkinson" <[EMAIL PROTECTED]> writes:

> I have a up1500 with stock woody 2.2 kernel, when booting it detects
> the sound as SB however no sound emits from my speakers. While
> trawling google I see that someone possibly mentioned a sound
> problem with these type of motherboards(nautilus up1100 etc) pre 2.4
> kernels. Is this so? Or do I have a hardware problem.

I don't remember about 2.2, but I'm pretty sure it worked fine for me
with 2.4, and I'm currently using 2.6.0-test3 sucesfully... Not sure
whether this helps you :)

-- 
Falk

Re: Bug#212912: gcc-3.3: [alpha] Linux linker/loader does not support -mieee-conformant

[Falk Hueffner]

Matthias Klose <[EMAIL PROTECTED]> writes:

> As Chris (currently listed as package maintainer for gcc alpha)
> seems to be away, I'll ask on debian-alpha (Falk?), if this patch
> should be included.

I'd vote for not including it like it is now.

> > Richard Henderson (the Alpha fellow from Red Hat) said he wouldn't
> > accept it into the general GCC unless all users of GCC (i.e. BSD,
> > etc) came forward and said they wanted it.
> > 
> > He also gave three reasons why he personally didn't like it:
> > 1- The default under DEC C is to not IEEE compliance
> > 2- IEEE compliance leads to 'severe' performance penalties
> > 3- The vast majority of SIGFPEs are due to unitialized data reads
> > 
> > While one and three might be true (timing tests show that two is
> > just plain wrong),

Well, 20% looks pretty severe to me.

> > they miss the point of the patch.
> > 
> > The patch is intended to help achieve the goal of having as many
> > packages as possible run on the Debian Alpha distribution as
> > possible (without needing to specify Alpha specific flags).

Then we should also compile with -O0 to avoid triggering bugs?  There
has to be some trade-off.

> > This means matching the GNU defaults on the other Debian
> > architectures, and that just happens to be IEEE compliant
> > libraries and code.

It has also been a GNU policy to not be standards compliant just for
the sake of it. Very little code actually needs IEEE complicance.

Like rth, I'd say as a minimum -ffast-math should turn off IEEE
complicance. When that's the case, the patch would be OK with me,
since actually also very little code needs high floating point
performance.

-- 
Falk

Re: dog bytes in his tail

[Falk Hueffner]

Adrian Zaugg <[EMAIL PROTECTED]> writes:

> Does anybody know what's going on with Bug #202762
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=202762)? The
> problem seems to still exist and prevents me from compiling a new
> 2.4.2x kernel with gcc-3.3

Are you sure you're using gcc 3.3.2ds3-0pre5? Apparently, it's not
even in the archive for Alpha yet.

-- 
Falk

Re: mysterious xmms buildd failure on alpha buildd

[Falk Hueffner]

Thimo Neubauer <[EMAIL PROTECTED]> writes:

> mpg123.c:837: error: unrecognizable insn:
> (insn 555 554 2298 32 0x2f87918 (set (reg/f:DI 366)
> (symbol_ref:DI ("@Lmpg123_ip"))) -1 (nil)
> (expr_list:REG_EQUAL (symbol_ref:DI ("@Lmpg123_ip"))
> (nil)))
> mpg123.c:837: internal compiler error: in extract_insn, at
> recog.c:2175

This is a well known gcc bug (http://gcc.gnu.org/PR11717), fixed in
GCC 3.3.2 which is to be released Real Soon Now[tm].

-- 
Falk

Re: libc6 vs. libc6.1/testing rather strange (broken ?)

[Falk Hueffner]

Helge Kreutzmann <[EMAIL PROTECTED]> writes:

> Yesterday I came around an example which might explain part of the
> problem:  dcraw
> 
> I got the source, compiled it and tried to install it, however:
> 
> Depends: libc6 (>= 2.3.2-1)
> 
> Does this dependency have to read:
> Depends: libc6 (>= 2.3.2-1) | libc6.1 (>= 2.3.2-1)
> 
> Should I fill bugs against such packages?

Yes. They should usually just use

Depends: ${shlibs:Depends}

or your version if they really need a specific libc version.

> Is the version numbering for libc6 and libc6.1 the same, i.e. do I have to 
> wait
> for libc6.1 2.3.2-1 before I can use dcraw?

Yes, it's really the same package, only for weird historical reason
the package is called libc6.1 on Alpha and IA64 and libc6 everywhere else.

The explicit dependency in dcraw is probably just a mistake, though,
there is basically no reason why a source would not work with older
glibcs.

> (I removed the versioned dependency in this case but have not yet
> tried dcraw).

BTW, are you trying to hook up a digital camera to your Alpha? I'd be
interested in experiences :)

-- 
Falk

Re: Kernels for sarge d-i: confirmation that jensen, nautilus variants aren't needed?

[Falk Hueffner]

Steve Langasek <[EMAIL PROTECTED]> writes:

> I'm trying to see what I can do to get working test images put together
> for sarge based on debian-installer.  I notice that there are no 2.4
> kernel-image packages for the jensen or nautilus subarchitectures; and
> I found a single thread discussing this from back in May:
> 
> Can anyone confirm that the new 2.4 generic kernels do in fact work on
> nautilus and jensen machines?

They work on Nautilus with SRM. Don't know about Jensen.

> Also, I found some comments from back in January 2002 indicating that
> SRM is now available for nautilus machines, and therefore APB support is
> no longer needed in the installer.  Is this correct?

Yes.

-- 
Falk

Re: Agistudio build crashes GCC - help needed

[Falk Hueffner]

On Sat, 23 Aug 2003, Jarno Elonen wrote:

> From buildd logs it looks like the build of a package I maintain,
> Agistudio crashes GCC on Alpha. Could someone on the list try it again
> with a new GCC and if it still fails, generate data for a bug report
> as recommended at http://gcc.gnu.org/bugs.html#need?

I am pretty sure it is not fixed yet. However, as a workaround, you could
change the build to build with -O2 (as the policy mandates), or change
the source to not pass 300k structures by value (as common sense mandates ;)

Falk

Re: alpha cds bootable?

[Falk Hueffner]

Alastair McKinstry <[EMAIL PROTECTED]> writes:

> I don't know whether alphas can boot ISOLINUX format. If not, we
> will need to juggle packages to make everything fit in 2.8 MB on
> alpha.

CD booting on Alpha is completely different than for PCs. The firmware
(SRM) reads a bootloader from a fixed offset of the medium (which
fortunately is not used otherwise on ISO images). The bootloader
(aboot) understands file systems like ext2 or iso9660. So there's no
limit on the size of a kernel or initrd at all.

(There's also another firmware (ARC), but I've never understood how CD
booting works there...)

-- 
Falk

Re: Raid-5 Problem

[Falk Hueffner]

Adrian Zaugg <[EMAIL PROTECTED]> writes:

> The same happens with RAID1 and maybe RAID0 Software RAIDs (unable to
> handle kernel paging request) when using or syncing them.

Apparently, this is triggered by a gcc bug (see
http://gcc.gnu.org/PR11087). It will be fixed in the
soon-to-be-released gcc 3.3.1, I'm not sure whether it is fixed in 3.3
already.

> Use gcc-3.2 to compile kernel 2.4.21 instead, which works. It tells
> something of a multi literal string (or something like that) in
> xor.h, which is deprecated in gcc-3.2 (thus a warning) and no more
> supported in gcc-3.3 (leads to stop compiling). (Is this a bug of
> the kernel-source to be reported?)

Yes.

-- 
Falk

Re: swriteboot error and sound on XP1000

[Falk Hueffner]

Jonathan Riddell <[EMAIL PROTECTED]> writes:

> Can anybody help with this error message from swriteboot:
> 
> # swriteboot -v /dev/sda bootlx
> open bootfile: No such file or directory

You need to give the complete path to the bootlx file. Make sure you
have the "aboot" package installed. It's in /boot/bootlx then.

-- 
Falk

Re: compiler errors: md needed for hardware raid?

[Falk Hueffner]

Lars Oeschey <[EMAIL PROTECTED]> writes:

> Am Dienstag, 15. Juli 2003 15:19 schrieb Falk Hueffner:
> mh, ok... But I found that I need some kind of software raid, I have 
> several partitions on external cabinets (that old mylex controllers 
> support partitions only up to 32Gb) and I want to combine those to one 
> big drive.
> I took a look ant md and LVM now, but what I didn't find is, does LVM 
> need md? or is it more of a replacement for it?
> Cause then I could just use LVM...

I think LVM2 can do at least raid0 on its own. I don't know whether it
is well-tested on Alpha, though, I've never used it :)

-- 
Falk

Re: compiler errors: md needed for hardware raid?

[Falk Hueffner]

Lars Oeschey <[EMAIL PROTECTED]> writes:

> when trying to compile the 2.4.21 kernel I get compiler errors within 
> /drivers/md:
> 
> In file included from xor.c:23:
> /usr/src/kernel-source-2.4.21/include/asm/xor.h:35:5: missing 
> terminating " character

Eek. That file uses multiline string literals, which is no longer
accepted by gcc.

You could just start each line within the asm argument with " and
finish with \n\t".

> I couldn't find anything on this error at google, so my question is: is 
> the md driver needed for hardware raids or is it just for software 
> raids?

Software.

-- 
Falk

Re: compiling 2.4.20

[Falk Hueffner]

Lars Oeschey <[EMAIL PROTECTED]> writes:

> Am Mittwoch, 9. Juli 2003 14:55 schrieb Falk Hueffner:
> 
> > 2.4.20 has serious bugs on Alpha, you should rather use 2.4.19 or
> > 2.4.21.
> 
> I upgraded now to 3.3 since I found a similar answer somewhere on the 
> net. The compile failed again somewhere else though, but I'll try 
> 2.4.21 then first (the odd numbers were the stable ones?).

They're all supposed to be stable, only for 2.4.20 an Alpha specific
bug was introduced close to release... (it was fixed shortly after in
the -pre21 sub-releases, though).

> Do I only need the kernel-source package? I saw some kernel-header
> packages too...

You don't need them for compiling kernels (I think).

-- 
Falk

Re: compiling 2.4.20

[Falk Hueffner]

Lars Oeschey <[EMAIL PROTECTED]> writes:

> since I checked the 2.4.18 kernel-image and found out that there's no 
> DAC960 support (only as module) I decided to compile a new 2.4.20 
> kernel. 

2.4.20 has serious bugs on Alpha, you should rather use 2.4.19 or
2.4.21.

> DAC960.c:1054: internal error--unrecognizable insn:
> (insn 1050 1046 482 (set (reg:DI 16 $16)
> (plus:DI (reg:DI 30 $30)
> (const_int 4398046511104 [0x400]))) -1 (nil)
> (nil))
> cpp0: output pipe has been closed
> make[4]: *** [DAC960.o] Error 1
> 
> Anyone has an idea wht the problem is?

A bug in gcc. Which version are you using? If you're not using gcc
3.3, try upgrading.

-- 
Falk

Re: SIGFPE and -mieee

[Falk Hueffner]

Kelledin <[EMAIL PROTECTED]> writes:

> Also, one other detail I forgot: what about EV6 and higher?  My 
> understanding is that on Alpha processors >=EV6, -mieee is 
> either unnecessary, or the extra code it introduces comes at 
> negligible cost.

The latter. The trap barriers introduced by -mieee are discarded as
nops very early in the pipeline, since the ev6 has precise traps.
Also, it can do some more denormal arithmetic in hardware. Example:

double x = 1.0;
for (int i = 0; i < 10; ++i)
x *= 2;

no -mieee   SIGFPE
-mieee on ev5   165.81 seconds (inf arithmetic emulated by kernel)
-mieee on ev6 1.03 seconds

If you use -mcpu=ev6, -mieee should be totally free since gcc doesn't
insert any trap barriers then.

-- 
Falk

Re: SIGFPE and -mieee

[Falk Hueffner]

Tyson Whitehead <[EMAIL PROTECTED]> writes:

> I've prepared and tested a patch for gcc to address the -mieee
> issue.
> 
> The patch makes -mieee the default and adds a -mieee-disable option
> to make it possible to reverse the default (maybe this should be
> called -mno-ieee).

I'd prefer -mno-ieee.

> I'll submit it to either the gcc mailing list, or as a bug rebort
> against gcc, shortly.  Comments?  Suggestions?

I'm somewhat indetermined about this. Let's see what the gcc list says
about it :)

I'd also suggest -ffast-math turns on -mno-ieee.

> PS: Incidentally, I checked both LAPACK and BLAS (on which ATLAS is
> based).  They are currently both being compiled with -mieee.

They probably have the important routines written in assembly anyway,
so it doesn't matter much.

-- 
Falk

Re: Konqueror and Javascript

[Falk Hueffner]

Rob Thyssen <[EMAIL PROTECTED]> writes:

> I haven't been able to get Mozilla working and understand from Jens
> response to my question about this that I probably won't get it
> working any time soon.

You could use an older version from sid. E. g:

deb http://snapshot.debian.net/archive/2003/03/01/debian unstable main

> Konqueror runs very nicely in KDE3 but on some sites with javascript
> it crashes instantly. For example if I point it at ebay.co.uk it
> only gets as far as the html title before it crashes and
> disappears. Other sites with simple javascript display and work
> fine. Is there something that I can do about this?

File a bug report :)

-- 
Falk

Re: no atop for alpha?

[Falk Hueffner]

Chris Hecker <[EMAIL PROTECTED]> writes:

> http://http.us.debian.org/debian/pool/main/a/atop/
> 
> Why is there no atop for alpha (neither testing nor unstable)? 

Because it doesn't build.

> Was there someplace I should have gone to ask this beside this list?

atop's bug page
(http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=atop).

-- 
Falk

Re: error when compiling xdrawchem

[Falk Hueffner]

Jan Lentfer <[EMAIL PROTECTED]> writes:

> I am trying to build a new package for xdrawchem (1.7.2). I got it
> build fine on x86, but it fails to build on Alpha.
> 
> It fails with:
> 
> arrow.cpp: In method `class QPoint Arrow::Midpoint()':
> arrow.cpp:165: implicit declaration of function `int lround(...)'

Looks like your math.h is broken. It works in sid, though.

-- 
Falk

Re: cpml/cxml libs

[Falk Hueffner]

Timothy Timmons <[EMAIL PROTECTED]> writes:

> Sadly, it looks like there is no longer any place to download version 5.2
> of the cpml libraries. HP's website has nothing but broken links for it.
> ftp.compaq.com does have cpml libs.. but only older 5.0 and 5.1 versions.
> The debian installer expects version 5.2 (cpml_ev5-5.2.0-1.alpha.rpm).
> 
> I know this probably isn't the right list to ask such questions, but
> anyone have any idea how I'm supposed to get these libraries now?

Try

ftp://ftp.compaq.com/pub/products/math/cpml/5.2.0/linux/cpml_ev5-5.2.0-1.alpha.rpm

-- 
Falk

Re: unable to boot with floppies or CD on PC164LX (SRM console)

[Falk Hueffner]

Timothy Timmons <[EMAIL PROTECTED]> writes:

> I assembled a Sarge/alpha CD1 with jigdo today. No luck booting off
> of the CD like the Install manual says should work fine. I am using
> the right device.  I have tried booting it with both IDE and SCSI
> cd-rom drives.
> 
> I keep getting the same error:
> 
> "Block 0 of devxxx is not a valid boot block"

I don't know where you got those images, probably they're actually not
bootable. You can try make them bootable with isomarkboot.

> Same thing happens when I try to use a Woody/alpha rescue.bin floppy.

Hmm, that should work. Do any other floppies work?

> I notice in the alpha dir on all of the ftp sites/mirrors that there
> is a file named "bootlx", but is not labeled in any way in any of
> the docs or the readme.txt in the dir.

It's the aboot boot loader.

> I also seem to remember checking the ftp sites a week ago when I
> decided to put Debian on this machine and seeing a special 164LX
> floppy image dir along with the special Jensen floppy image dir.

164LX doesn't need a special kernel image... maybe you were looking at
an ancient kernel 2.0 distribution.

-- 
Falk

Re: need tester for tk8.3 bug

[Falk Hueffner]

Chris Waters <[EMAIL PROTECTED]> writes:

> I need to confirm whether tk8.3 bugs #151435 and #156702 are still
> present in testing/unstable.  These are alpha-specific bugs, and I
> don't have an alpha.
> 
> Upstream was unable to reproduce on their alphas (running RH), so I
> think there's a strong possibility these bugs are fixed.  But I'd like
> to confirm before closing the reports.
> 
> I've attached a small script which can be used to test both bugs.  The
> script should produce a red quarter-circle inside of a square.  Can
> someone please try this and let me know if it works?  (Note: I'm not
> subscribed to this list, so please cc me.)

Works for me with tk8.3 8.3.5-2.

-- 
Falk

Re: Debian 3.0 on AS1000A 5/333 won't shutdown/reboot

[Falk Hueffner]

Jens Kruse <[EMAIL PROTECTED]> writes:

> While 'make' this error message appeared:
> 
> DAC960.c: In function `DAC960_V2_EnableMemoryMailboxInterface':
> DAC960.c:1054: internal error--unrecognizable insn:
> (insn 1050 1046 482 (set (reg:DI 16 $16)
>  (plus:DI (reg:DI 30 $30)
>  (const_int 4398046511104 [0x400]))) -1 (nil)
>  (nil))
> cpp0: output pipe has been closed
> make[3]: *** [DAC960.o] Error 1
> 
> This appears also with other modules, i.e. atm.
> 
> Googling around I found out that it might have something to do with
> gcc, I'm using
> 
> fehmarn:/usr/src/linux# dpkg -l gcc

(heh. my alpha is called juist :)

> ii gcc 2.95.4-14 The GNU C compiler.

Well, gcc 2.95 is no longer maintained... you should try updating to
3.2.3 or 3.3.

-- 
Falk

Re: Debian 3.0 on AS1000A 5/333 won't shutdown/reboot

[Falk Hueffner]

Jens Kruse <[EMAIL PROTECTED]> writes:

> David Duminy wrote:
> > The device /dev/srm allows you to set the srm's variables from
> > linux. I think you that
> 
> > 'echo 0 > /dev/srm/boot_osflags ' under linux is equivalent to the
> > 'set boot_osflags 0' under SRM.
> >
> > the /dev/srm device should be enabled in the kernel. Maybe you have
> > to compile a new kernel to enable it.
> 
> I'd like to compile a kernel, but I couldn't find any statement
> regarding '/dev/srm' - does anyone have a hint for me where to find
> the parameter to enable 'dev/srm'?

It's actually /proc/srm_environment. It's activated with
CONFIG_SRM_ENV in "System setup".

-- 
Falk

Re: acrobat reader

[Falk Hueffner]

Joakim Roubert <[EMAIL PROTECTED]> writes:

> Earlier I've been using the Acrobat Reader 3 on my AlphaStation 200
> (21064), and that's working fine.
> 
> Now I installed Acrobat Reader 4.05, and get this:
> 
> octavia:packages/Acrobat4/bin$ ./acroread
> zsh: illegal hardware instruction  ./acroread
> octavia:packages/Acrobat4/bin$
> 
> Is this something that can be configured to work, or am I as a user
> of a 21064 system stuck to older versions?

I suppose it was simply compiled for ev56+. You could verify that with
gdb and disas. There used to be a kernel patch that emulated the
missing instructions, it would probably be relatively easy to get that
to work again. However, I'd just use xpdf :)

-- 
Falk

Re: AlphaStation 500 MILO problems + Voodoo questions

[Falk Hueffner]

Jay Estabrook <[EMAIL PROTECTED]> writes:

> On Tue, Apr 29, 2003 at 12:26:39AM +0200, Falk Hueffner wrote:
> > I briefly tried the digital output on an AGP Radeon 7500 in an
> > UP1500, but X 4.2.1 said:
> > 
> > (II) RADEON(0): No legacy BIOS found -- trying PCI
> 
> Well, for whatever reason, not being able to read the BIOS will cause
> a LOT of problems. I assume these error messages don't appear when the
> card is configured for CRT output?

Yes they do:

(II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x
(II) RADEON(0): PCI bus 1 card 5 func 0
(**) RADEON(0): Depth 24, (--) framebuffer bpp 32
(II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
(==) RADEON(0): Default visual is TrueColor
(**) RADEON(0): Option "CrtScreen"
(==) RADEON(0): RGB weight 888
(II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
(II) RADEON(0): initializing int10
(II) RADEON(0): No legacy BIOS found -- trying PCI
(EE) RADEON(0): Cannot read V_BIOS (5)
(WW) RADEON(0): Restoring MEM_CNTL (), setting to 2e002e01
(WW) RADEON(0): Restoring CONFIG_MEMSIZE (0800), setting to 0800
(--) RADEON(0): Chipset: "ATI Radeon 7500 QW (AGP)" (ChipID = 0x5157)
(--) RADEON(0): Linear framebuffer at 0xe000
(--) RADEON(0): MMIO registers at 0xd800
(--) RADEON(0): BIOS at 0xf000
(--) RADEON(0): VideoRAM: 131072 kByte (64-bit DDR SDRAM)
(WW) RADEON(0): Video BIOS not detected in PCI space!
(WW) RADEON(0): Attempting to read Video BIOS from legacy ISA space!
(WW) RADEON(0): Video BIOS not found!
(II) RADEON(0): initializing int10
(II) RADEON(0): No legacy BIOS found -- trying PCI
(EE) RADEON(0): Cannot read V_BIOS (5)
(WW) RADEON(0): Video BIOS not detected, using default PLL parameters!
(II) RADEON(0): PLL parameters: rf=2700 rd=67 min=12500 max=35000; xclk=16615
(==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0)
(II) RADEON(0): Sampo: Using hsync range of 30.00-65.00 kHz
(II) RADEON(0): Sampo: Using vrefresh range of 56.00-75.00 Hz
(II) RADEON(0): Clock range:  12.50 to 350.00 MHz
(II) RADEON(0): Not using default mode "640x350" (vrefresh out of range)
[...]
(II) RADEON(0): Not using default mode "1024x768" (hsync out of range)
(--) RADEON(0): Virtual size is 1280x1024 (pitch 1280)
(**) RADEON(0): Default mode "1280x1024": 108.0 MHz, 64.0 kHz, 60.0 Hz

> I'd love to look further into this, as we have seen such problems on
> our AGP boxes, but the best I can do is UP1100, and its BIOS emulator
> cannot handle any Radeons, AFAICT... :-(
> 
> > Analog works fine if I add Option "CrtScreen"...
> 
> I haven't used 4.2.1 or 4.3.0 much at all yet; do they force one to
> add that option by defaulting to the DVI connector?

It looks like it, at least it won't work without that option.

-- 
Falk

Re: AlphaStation 500 MILO problems + Voodoo questions

[Falk Hueffner]

Jay Estabrook <[EMAIL PROTECTED]> writes:

> Finally, I had the following success running X from the XLT MILO:
> 
> 3. ATI Radeon 7500

Did you try that one with the digital output? I briefly tried the
digital output on an AGP Radeon 7500 in an UP1500, but X 4.2.1 said:

(II) RADEON(0): No legacy BIOS found -- trying PCI
(EE) RADEON(0): Cannot read V_BIOS (5)
(WW) RADEON(0): Restoring MEM_CNTL (), setting to 2e002e01
(WW) RADEON(0): Restoring CONFIG_MEMSIZE (0800), setting to 0800
(--) RADEON(0): Chipset: "ATI Radeon 7500 QW (AGP)" (ChipID = 0x5157)
(--) RADEON(0): Linear framebuffer at 0xe000
(--) RADEON(0): MMIO registers at 0xd800
(--) RADEON(0): BIOS at 0xf000
(--) RADEON(0): VideoRAM: 131072 kByte (64-bit DDR SDRAM)
(WW) RADEON(0): Video BIOS not detected in PCI space!
(WW) RADEON(0): Attempting to read Video BIOS from legacy ISA space!
(WW) RADEON(0): Video BIOS not found!
(II) RADEON(0): initializing int10
(II) RADEON(0): No legacy BIOS found -- trying PCI
(EE) RADEON(0): Cannot read V_BIOS (5)
(WW) RADEON(0): Video BIOS not detected, using default PLL parameters!
(II) RADEON(0): PLL parameters: rf=2700 rd=67 min=12500 max=35000; xclk=16615
(==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0)
(WW) RADEON(0): Mode 1280x1024 is out of range.
Valid mode should be between 640x480-0x0
(WW) RADEON(0): Mode 640x480 is out of range.
Valid mode should be between 640x480-0x0
(EE) RADEON(0): No valid mode found for this DFP/LCD

Analog works fine if I add Option "CrtScreen"...

-- 
Falk

Re: kdegames, lyx and xserver-xfree86

[Falk Hueffner]

Linus Gasser <[EMAIL PROTECTED]> writes:

> OK, thanks for the info. I mis-wrote my thoughts: is it due to the
> fact of the gzip-error (see earlier on this list) that a new, fixed
> XFree86 is not compiled and put into place, yet?

No, it's now because of another problem, the gzip bug has been kludged
around... see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=189339

-- 
Falk

Re: kdegames, lyx and xserver-xfree86

[Falk Hueffner]

Linus Gasser <[EMAIL PROTECTED]> writes:

> yesterday I had a pleasant surprise: kdegames is in unstable, again!
> What is the magic behind it?

Upstream binutils now contain a fix for the jump table relocation
problem.

>  Now I only have xserver-xfree86/unstable who gives me errors on start-up, 
> with something like
>   ELF - relocation error
> has somebody a working unstable-version of xfree86?

Hmm. This should have been fixed. Try installing xserver-xfree86-dbg
as a workaround.

-- 
Falk

Re: boot problems

[Falk Hueffner]

"Donald D. Daniel" <[EMAIL PROTECTED]> writes:

> My /etc/aboot.conf is as follows:
> 
> 0:1/vmlinuz ro root=/dev/hda1
> 1:1/xl ro root=/dev/hda1
> 
> In /boot and /boot2 I have identical files including
> vmlinuz-2.2.22.
> 
> At / I have vmlinuz and xl, symbolic links to the two
> identical copies of the kernel.
> 
> If I "boot dqa0 -fl i" to get into aboot,
> I can type "0" and one copy of the kernel will boot.
> If I type "1", the other copy does not boot

Maybe /boot2 is a mount point? aboot does not parse /etc/fstab and
therefore doesn't know which partitions will be mounted where.

-- 
Falk

Re: Ethernet strangeness on kernel 2.4.20... and more

[Falk Hueffner]

"Wm. Josiah Erikson" <[EMAIL PROTECTED]> writes:

> One is that since I upgraded to kernel 2.4.20 from 2.4.19, I get
> this in the dmesg:

2.4.20 has a bug in the string handling code, which for example breaks
iso9660. Maybe that's also the reason for this oops. Try a -pre kernel.


> Another, probably silly question is - how do I make it boot up with
> aboot automatically, without having to choose a kernel image?  Right
> now it boots into interactive mode, and I'd much rather have it just
> boot kernel image 0 automatically.

set boot_osflags 0

-- 
Falk

Re: Galeon segfaulting

[Falk Hueffner]

Kerstin Hoef-Emden <[EMAIL PROTECTED]> writes:

> The window frames in mozilla, however, are still absent.

Here's a patch for fvwm. I've also filed a bug report, so hopefully
this will be fixed in sarge soon.

-- 
Falk

--- fvwm/decorations.c~	2003-02-08 14:09:43.0 +0100
+++ fvwm/decorations.c	2003-04-09 14:07:49.0 +0200
@@ -73,10 +73,10 @@
 /* Motif  window hints */
 typedef struct
 {
-  CARD32  flags;
-  CARD32  functions;
-  CARD32  decorations;
-  INT32   inputMode;
+  ulong  flags;
+  ulong  functions;
+  ulong  decorations;
+  long   inputMode;
 } PropMotifWmHints;
 
 typedef PropMotifWmHintsPropMwmHints;

Re: non PIC library on alpha

[Falk Hueffner]

Bill Allombert <[EMAIL PROTECTED]> writes:

> Woody allowed non PIC code in dynamic libraries on alpha, but this
> does not work anymore.
> 
> This is a problem if you have assembly code linked in your shared
> library that is not PIC aware, since you will need to rewrite it.

"Rewrite" seems a bit strong, most code shouldn't even be affected;
the only difference is in getting the address of global symbols.

Non-PIC code in libraries is not a good idea anyway, so I'd just fix
the assembly.

-- 
Falk

Re: Relocation errors with g++-3.2

[Falk Hueffner]

Adam C Powell IV <[EMAIL PROTECTED]> writes:

> Just curious, gcc bugs aside, what's wrong with inlining functions
> with switch statements?  (I've done it a couple of times...)  Does
> switch take so much time that it's not worth saving the function
> call?

Yes, at least when the switch has enough cases that gcc generates a
jump table. That will lead to a data-dependend indirect jump, which
usually stalls the pipeline (unless always the same case is taken).

I usually only inline really small functions that compile to 1-4
instructions, or after I've done some measurements. That helps
relieving the icache.

By the way, the relocation bug indeed doesn't depend on inlining, but
rather on functions with switch-statements being emitted in several .o
files, which can also happen with static functions in headers, or
templates. Unfortunately, I cannot think of a reasonable workaround...

-- 
Falk

Re: Galeon segfaulting

[Falk Hueffner]

Kerstin Hoef-Emden <[EMAIL PROTECTED]> writes:

> Galeon crashes with a segfault-message on my system, almost every
> time, I want to print a page (successful printouts are rare).
> 
> The error message is as follows:
> 
> Application /usr/bin/galeon-bin has crashed due to a fatal error.
> (Segmentation fault)
> 
> My LX164 runs under woody (Galeon 1.2.5) and fvwm2 as a WM. I did
> some experiments with the settings, but couldn't find any
> differences between dis- or enabled Java or Javascript, between
> printing all or only single pages, no differences also between pages
> with or without pictures.

I can't reproduce this with the galeon in sid (1.2.7-6), at least not
when printing to a file (I have no printer). So I guess it has been
fixed meanwhile. You could try rebuilding galeon for woody, or upgrade
to sid if you're adventurous :)

-- 
Falk

Re: Relocation errors with g++-3.2

[Falk Hueffner]

Kelledin <[EMAIL PROTECTED]> writes:

> On Saturday 05 April 2003 08:54 pm, Falk Hueffner wrote:
> > As a workaround, try to find out which switch statement causes
> > it and don't inline the function (a function complex enough to
> > contain a switch statement probably shouldn't be inline,
> > anyway).
> 
> Well...I poked around in the case where this applies to me
> (kdegames-3.1.1, specifically kmines).  Apparently this scenario
> never occurs; the only explicitly inlined functions I see are in
> grid2.h, and not one contains a switch statement.  Have I possibly
> missed something?
> 
> I tried building with -fno-default-inline (to counteract class 
> methods getting automatically inlined).  No joy...

It's in grid2.h:
static Coord neighbour(const Coord &c, Neighbour n) {
switch (n) {
case Left:  return c + Coord(-1,  0);
case Right: return c + Coord( 1,  0);
case Up:return c + Coord( 0, -1);
case Down:  return c + Coord( 0,  1);
case LeftUp:return c + Coord(-1, -1);
case LeftDown:  return c + Coord(-1,  1);
case RightUp:   return c + Coord( 1, -1);
case RightDown: return c + Coord( 1,  1);
}
return c;
}

As a fix, either uninline this, or use a non-moronic design that will
not lead to code bloat and unpredictable indirect branches in critical
paths.

-- 
Falk

Re: Relocation errors with g++-3.2

[Falk Hueffner]

Kelledin <[EMAIL PROTECTED]> writes:

> On Saturday 05 April 2003 08:54 pm, Falk Hueffner wrote:
> > As a workaround, try to find out which switch statement causes
> > it and don't inline the function (a function complex enough to
> > contain a switch statement probably shouldn't be inline,
> > anyway).
> 
> Well...I poked around in the case where this applies to me 
> (kdegames-3.1.1, specifically kmines).  Apparently this scenario 
> never occurs; the only explicitly inlined functions I see are in 
> grid2.h, and not one contains a switch statement.  Have I 
> possibly missed something?
> 
> I tried building with -fno-default-inline (to counteract class 
> methods getting automatically inlined).  No joy...

Hmm, weird. I'll check it out.

-- 
Falk

Re: Relocation errors with g++-3.2

[Falk Hueffner]

Mats Rynge <[EMAIL PROTECTED]> writes:

> main.o(.rodata+0x8b4):itimerspec/format.h:380: relocation truncated to fit: 
> GPREL32 *UND*
> 
> This is only happening on Alpha and only with g++-3.2 (2.95 works
> fine). Does anyone have some insight in what is causing this?

Jump tables relocated against symbols emitted mutiple times, where the
corresponding copy was dropped. See
http://gcc.gnu.org/ml/gcc/2003-04/msg00191.html

As a workaround, try to find out which switch statement causes it and
don't inline the function (a function complex enough to contain a
switch statement probably shouldn't be inline, anyway).

-- 
Falk

Re: Xfree

[Falk Hueffner]

"Peter Watkinson" <[EMAIL PROTECTED]> writes:

> Aha wait a minute if I remember correctly isn't there a way to re go
> through the install process which means you can re do the X
> configure.

dpkg-reconfigure xserver-xfree86

-- 
Falk

Re: xfree86 4.2.1-6 build on alpha

[Falk Hueffner]

Daniel Stone <[EMAIL PROTECTED]> writes:

> On Thu, Apr 03, 2003 at 05:01:50PM +1000, Anthony Towns scrawled:
> > xfree86 4.2.1-6 fails to build on alpha due to:
> > 
> > ...
> > LD_LIBRARY_PATH=../../../exports/lib  ../../../exports/bin/bdftopcf -t 
> > lutBS08.
> > bdf | gzip > lutBS08.pcf.gz
> > make[6]: *** [lutBS08.pcf.gz] Error 139
> > 
> > See http://buildd.debian.org/build.php?arch=alpha&pkg=xfree86&ver=4.2.1-6
> > 
> > Can this be looked into, please?
> 
> Ah, the gzip killer bug. Works with -3, fails with -4 - where the
> --rsyncable patch was introduced. However, StevenK claimed he couldn't
> reproduce it, so I didn't file a bug about it.
> 
> Bug needs to be filed on gzip about the 'gzip killer' .bdf.

Already reported 3 weeks ago as #184057.

-- 
Falk

Re: newbie

[Falk Hueffner]

"Bob Schmidt" <[EMAIL PROTECTED]> writes:

> Hi,
> 
> Just got my 433au today in the mail.  I am trying to install debian
> 3.0r1 on it.  Now I have used linux before, but this is all new to
> me here.  It tells me that I have to have an (I think) an osf/bsd
> boot label, then it sends me to the disk partioning program.  I type
> the letter b like it tells me to, then type r to go to the regular
> disk setup.

What made you think you need to do that? Stay in the disklabel menu,
and everything should work.

-- 
Falk