Re: Help with slicer FTBFS on alpha - #548500
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
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
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
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
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
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?
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?
[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 stdio.h
#include math.h
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 stdio.h
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
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
[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
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: gclcvs
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
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: GCL/maxima/axiom/acl2, denormalized floats, and alpha
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: xorg 7.0 and Radeon 7500
[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
[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
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
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
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
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
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
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]
Re: BTS usertags for Alpha specific bugs
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]
BTS usertags for Alpha specific bugs
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 defunct 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
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
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: dcc seems unusable in sarge on alpha
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: seti boinc for alpha
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: 325600 (defunct threads on Alpha).
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: apt-cache search broken?
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]
Requalification of Alpha for etch
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: Requalification of Alpha for etch
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]
Re: SIGFPE
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: X.Org 6.9 Needs Your Build Logs!
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 http://perso.ens-lyon.fr/julien.cristau/xorg-x11_6.8.99.900_alpha.log. 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: bzip2 unaligned trap
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
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
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 unistd.h
#include asm/sysinfo.h
#include asm/unistd.h
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?
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
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
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 EOF 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?
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=243311msg=3att=2 using a small module: http://bugs.debian.org/cgi-bin/bugreport.cgi/iohelp.pm?bug=243311msg=3att=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
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: Unaligned access on Alpha
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
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: acrobat reader
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
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.145content-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
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
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
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: UML Port
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
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 sys/types.h.
See bug #212233. As a workaround, rename __align to __align_ or
whatever.
--
Falk
Re: MILO packages?
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?
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: SIGFPE resolution?
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: sound on UP1500
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: dog bytes in his tail
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: Bug#212912: gcc-3.3: [alpha] Linux linker/loader does not support -mieee-conformant
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: mysterious xmms buildd failure on alpha buildd
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 ?)
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?
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: http://lists.debian.org/debian-alpha/2003/debian-alpha-200305/msg00057.html 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
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?
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
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
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?
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: compiler errors: md needed for hardware raid?
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: compiling 2.4.20
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: compiling 2.4.20
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: SIGFPE and -mieee
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: SIGFPE and -mieee
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: Konqueror and Javascript
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?
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
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
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: need tester for tk8.3 bug
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
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
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
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
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
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
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: boot problems
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
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
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
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
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: Relocation errors with g++-3.2
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
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: Galeon segfaulting
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
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
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
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=alphapkg=xfree86ver=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
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
Re: video card
Richard Fillion [EMAIL PROTECTED] writes: It seems i've partially fixed my problems with slow video output. I built XF4.3 and installed it. Now it takes forever to get into X, but if it makes it better, i'm all for it. I can play mpegs rather well, only dropping a few frames here and there. I have 'mplayer' aliased to 'mplayer -framedrop -vo sdl -cache 65536 '. Yes, 64megs of cache, hey i have 512megs of RAM, may aswell put it to use. Divx at original size is decent, almost watchable, but fullscreen it starts dropping frames like crazy. That indicates you're not using the Xv extension. Xv moves YUV-conversion and scaling to the hardware, which saves a lot of CPU time. Try xvinfo to see whether your card and driver support it, or mplayer -vo xv. -- Falk
Re: compiling mplayer
Richard Fillion [EMAIL PROTECTED] writes: Hi, im trying to compile mplayer, the tarball that someone gave me about a year about that made divx work on my old alpha. And i'm getting this: make -C libmpeg2 make[1]: Entering directory `/seagate/src/mplayer/libmpeg2' gcc -c -O4 -mcpu=ev56 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I../libvo -I.. -DMPG12PLAY -finline-limit=10 -fforce-addr -o header.o header.c cc1: Invalid option `-finline-limit=10' make[1]: *** [header.o] Error 1 make[1]: Leaving directory `/seagate/src/mplayer/libmpeg2' make: *** [libmpeg2/libmpeg2.a] Error 2 -finline-limit is a new option in gcc 3. Try upgrading your gcc, or remove this option from the Makefile. -- Falk
Re: compiling mplayer
Richard Fillion [EMAIL PROTECTED] writes: I removed the finline option from the makefile, and it got further, but now it stops again. I didnt have any problems last time compiling, it worked oh so nicely eheh. So this is the last bit of output that i got: gcc -O4 -mcpu=ev56 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Ilibmpdemux -Iloader -Ilibvo -o mplayer mplayer.o mp_msg.o xacodec.o cpudetect.o codec-cfg.o cfgparser.o my_profile.o spudec.o playtree.o playtreeparser.o asxparser.o vobsub.o subreader.o find_sub.o lirc_mp.o mixer.o mp-opt-reg.o -Llibvo -lvo -Llibmpcodecs -lmpcodecs -Lmp3lib -lMP3 -Lliba52 -la52 -Llibmpeg2 -lmpeg2 -Llibavcodec -lavcodec -Llibmpdemux -lmpdemux -Linput -linput -Llibmpdvdkit -lmpdvdkit -lpthread -ldl -Lpostproc -lpostproc -Llinux -losdep -ltermcap -lnsl -lm -Llibao2 -lao2 -lnsl libmpeg2/libmpeg2.a(idct_alpha.o): In function `idct_block_copy_alpha': idct_alpha.o(.text+0xa48): undefined reference to `__builtin_alpha_zap' Hmm, that piece relies on other newish gcc features. Probably you should just try the newest mplayer from CVS with ffmpeg CVS, that should work. Just check both out and copy ffmpeg/libavcodec into the mplayer directory. -- Falk
Re: questions
Bob Schmidt [EMAIL PROTECTED] writes: Are there any issues I should be aware of before I start (I get my 433au on Monday). Also, (dumb question) what kind of modems will work in these machines? The only pci modems I have are winmodems, I got them to work in linux on my pc, but will they work in a 433au. No idea, never used one of those. I also have a 56k ISA modem, I'm assuming that won't work because it is not pci. That's not certain, some Alphas have ISA slots, and Linux can use them, for example I'm using an ISA sound card in my SX164. I also got ahold of a Digital AS 4000 with dual 400mhz processors and 512mb of ram. I put WniNT on that, but have been thinking of perhaps putting linux on that as well. It is a little overkill for my home server, but I'm having fun. I got it for a steal (under $100) and it works perfectly, and is in good shape. Will debian work on that? It should. The default kernel will use only one processor, though, you need to install the appropriate kernel package, or compile your own kernel. Falk
Re: ccc
Adam C Powell IV [EMAIL PROTECTED] writes:
Aha, I had an identical file minus the -std strict_ansi. But with
those, it gives me compiler errors:
zither:/# cxx /tmp/bye.C -o /tmp/bye
cxx: Error: /tmp/bye.C, line 4: identifier cout is undefined
cout Hello world endl;
--^
cxx: Error: /tmp/bye.C, line 4: identifier endl is undefined
cout Hello world endl;
---^
cxx: Info: 2 errors detected in the compilation of /tmp/bye.C.
zither:/# more /tmp/bye.C
#include iostream
int main()
{
cout Hello world endl;
return 0; }
Well, that's a correct message, g++ will tell you the same :)
You need std::cout and std::endl. And I think you really need -std
strict_ansi in comp.config to get it to work.
--
Falk
Re: ccc
Adam C Powell IV [EMAIL PROTECTED] writes: Hmm, just compiled with std::cout and std::endl, and got even more undefined symbols... Can you tell me the steps you went through to get this installed? I know you didn't (merely) use the .deb, because that would have put paths to 2.95.4 in your comp.config. Hm, I don't really remember, I guess I used alien and then kicked it till it worked :) Maybe your binutils is too old? I have 2.13.90.0.18-1.2. -- Falk
Re: strange when updating
Joakim Roubert [EMAIL PROTECTED] writes: I'm running Woody, with some unstable packages. So today I did the usual apt-get update, but see what I get: Hit ftp://ftp.se.debian.org unstable/non-US/non-free Sources Hit ftp://ftp.se.debian.org unstable/non-US/non-free Release Reading Package Lists... Error! E: Dynamic MMap ran out of room E: Error occured while processing gnuvd (NewVersion1) E: Problem with MergeList /var/lib/apt/lists/ftp.se.debian.org_debian_dists_unstable_contrib_binary-alpha_Packages E: The package lists or status file could not be parsed or opened. octavia:lib/apt/lists# What is this, and how could it be solved? Does anyone know? http://www.google.com/search?q=%22Dynamic+MMap+ran+out+of+room%22 -- Falk
