Re: [PATCH] 4.18-rc7 on alpha: bitsperlong issue
On Mon, Jan 21, 2019 at 1:42 PM Bob Tracy wrote: > > Apologies for what is essentially a repost with a proper subject header > in the sense of trying to get the attention of people who collect/approve > patches for submission upstream. See my posting from earlier today > (followup: [FTBFS] kernel 4.18-rc7 bitsperlong.h issue on alpha) for the > back story. As mentioned there, this patch applies cleanly to at least > all mainline kernel source trees >= version 4.18. > > Further apologies for including the patch as an attachment, but I don't > trust my mailer not to impose unintended formatting. Thanks Bob. I've vacuumed the patch up and will include it in a pull req soon.
Re: fdisk vs. BSD disklabels and slices
On Sun, Jan 6, 2019 at 2:31 PM Bob Tracy wrote: > > Has anyone reading this used a recent version of "fdisk" to create a BSD > disklabel and disk slices from scratch on an Alpha? If so, would you > please describe the procedure in enough detail that relevant Linux > installation documentation could be updated? It would seem to be anything > *but* intuitive :-(. fdisk's BSD disklabel support has been unusable raw disks, as far as I understand, since v2.23. See https://www.spinics.net/lists/util-linux-ng/msg11869.html > If "fdisk" is the wrong utility, I need a pointer to the correct one(s). > At this point, I'm seriously considering digging out my old Debian 4.0 > CDs and harvesting the essential pieces. > > As always, thanks in advance. Use 'parted' instead. It works well. Reminds me that I need to change the Gentoo handbook to reference parted instead of fdisk. > For what it's worth, the new Gentoo "install-alpha-minimal" image fixed > the "qla1280" firmware loading issue for the most part (a module reload > is required to get the firmware to load). Good to hear. I suspect the module is in the initramfs but the firmware is on the root file system. Hmm..
Re: [BUG] 4.13.0 kernel build error on Alpha
On Sun, Sep 10, 2017 at 3:34 PM, Bob Tracy wrote: > Here we go again :-(. Tool versions as follows: > > gcc version 7.2.0 (Debian 7.2.0-3) > GNU ld (GNU Binutils for Debian) 2.29 (binutils 2.29-9) > > Note evidence of the ".alphalib" section patch first tried with the 4.9 > kernel source. It has worked well up through 4.12. I didn't try > building any of the 4.13 release candidates because of all the compiler > updates that came through during that time. > > MODPOST vmlinux.o > WARNING: EXPORT symbol "callback_setenv" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "strrchr" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "__divl" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "__divqu" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "__memsetw" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "strchr" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "__reml" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "strcat" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "__copy_user" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "__remq" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "clear_page" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "strncpy" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "memmove" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "__remqu" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "memchr" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "__memset" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "copy_page" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "__divlu" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "strlen" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "strncat" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "callback_save_env" [vmlinux] version generation > failed, symbol will not be versioned. > WARNING: EXPORT symbol "memset" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: "saved_config" [vmlinux] is COMMON symbol > WARNING: EXPORT symbol "__clear_user" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "callback_getenv" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "__divq" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "strcpy" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "___memset" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "__remlu" [vmlinux] version generation failed, symbol > will not be versioned. > WARNING: EXPORT symbol "csum_ipv6_magic" [vmlinux] version generation failed, > symbol will not be versioned. > WARNING: EXPORT symbol "__constant_c_memset" [vmlinux] version generation > failed, symbol will not be versioned. > WARNING: modpost: Found 24 section mismatch(es). > To see full details build your kernel with: > 'make CONFIG_DEBUG_SECTION_MISMATCH=y' All of this is fixed by commit 873f9b5bcbf27f6e89e1879714abe4532cacf5d7 Author: Ben Hutchings Date: Wed Jul 19 01:01:16 2017 +0100 alpha: Restore symbol versions for symbols exported from assembly > arch/alpha/lib/memmove.o: In function `memmove': > (.alphalib+0x2c): relocation truncated to fit: BRSGP against symbol `memcpy' > defined in .text section in arch/alpha/lib/memcpy.o > Makefile:1000: recipe for target 'vmlinux' failed > make: *** [vmlinux] Error 1 I have not yet seen this. The kernel seemed to be in good shape after my two pull requests were merged. (commit dd689a68bc3 for 4.13 and commit 6caffe21dde for 4.13-rc1)
Re: [BUG] 4.9.0 build error on Alpha
FWIW, when I saw your first email I tried compiling with gcc-4.9.4, 5.4.0, and 6.2.0. All compiled my config fine. I'm guessing it's another symptom of the old "kernel too big" problem?
Re: Multia state of support
On Sat, Apr 2, 2016 at 12:52 PM, Michael Cree wrote: > On Sat, Apr 02, 2016 at 12:44:01PM -0700, Matt Turner wrote: >> On Sat, Apr 2, 2016 at 12:41 PM, Michael Cree wrote: >> > On Sat, Apr 02, 2016 at 07:33:34PM +0300, lausg...@gmail.com wrote: >> >> > What finally happened to dedicated xf86-video-tga driver? >> >> > The last trace for me is >> >> > https://lists.debian.org/debian-alpha/2009/09/msg00011.html >> >> > If it's alive, any plans to move its acceleration bits to EXA or >> >> > provide Xorg with XAA in Debian? >> >> >> >> from my initial post. Are you aware of what finally happened with your >> >> driver? >> > >> > All the old legacy video drivers, including tga, have been removed >> > from the xserver as no one was maintaining them anymore. >> >> This is incorrect. > > Well, they were removed from Debian, and the statement at the time > was that they no longer would be included unless someone stepped up > to maintain them. > >> > I think a recent xserver upload also removed user mode support, so >> > we are probably down to only the radeon KMS driver working on Alpha. >> >> And so is this. > > Then why did I get a message on upgrade, maybe six months ago, stating > this very thing? Maybe it's a Debian-specific change, like the previous case. (Maybe I misunderstood and you were talking specifically about Debian all along).
Re: Multia state of support
On Sat, Apr 2, 2016 at 12:41 PM, Michael Cree wrote: > On Sat, Apr 02, 2016 at 07:33:34PM +0300, lausg...@gmail.com wrote: >> > What finally happened to dedicated xf86-video-tga driver? >> > The last trace for me is >> > https://lists.debian.org/debian-alpha/2009/09/msg00011.html >> > If it's alive, any plans to move its acceleration bits to EXA or provide >> > Xorg with XAA in Debian? >> >> from my initial post. Are you aware of what finally happened with your >> driver? > > All the old legacy video drivers, including tga, have been removed > from the xserver as no one was maintaining them anymore. This is incorrect. > I think a recent xserver upload also removed user mode support, so > we are probably down to only the radeon KMS driver working on Alpha. And so is this. Unless you know something we don't?
Re: many packages held for alpha
On Fri, Sep 11, 2015 at 4:01 PM, Michael Cree wrote: > On Fri, Sep 11, 2015 at 03:18:46PM -0700, Matt Turner wrote: >> On Fri, Sep 11, 2015 at 12:33 AM, Michael Cree wrote: >> > On Thu, Sep 10, 2015 at 12:05:54AM -0500, Bob Tracy wrote: >> >> On Tue, Sep 08, 2015 at 07:56:29AM +1200, Michael Cree wrote: >> >> > The main problem is >> >> > that cmake FTBFS (Bug #789807) thus a growing proportion of the >> >> > archive is unbuildable on Alpha. >> >> >> >> See your private e-mail. I may have a handle on this beast. Won't >> >> burden the rest of the list with my speculation unless it pans out :-). >> > >> > Bob's speculation did pan out and we now have a working cmake! Thank >> > you Bob, you have enabled Alpha to survive another day. >> >> Some information would be nice... what was the problem? What was the >> solution? What versions are affected? > > Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789807 > > Upstream bug with patch: http://www.cmake.org/Bug/view.php?id=15736 > > Bug potentially affects all architectures but only by accident of > layout of binary executable showed up on Alpha. Excellent. Thanks Michael and Bob for the links and the explanation!
Re: many packages held for alpha
On Fri, Sep 11, 2015 at 12:33 AM, Michael Cree wrote: > On Thu, Sep 10, 2015 at 12:05:54AM -0500, Bob Tracy wrote: >> On Tue, Sep 08, 2015 at 07:56:29AM +1200, Michael Cree wrote: >> > The main problem is >> > that cmake FTBFS (Bug #789807) thus a growing proportion of the >> > archive is unbuildable on Alpha. >> >> See your private e-mail. I may have a handle on this beast. Won't >> burden the rest of the list with my speculation unless it pans out :-). > > Bob's speculation did pan out and we now have a working cmake! Thank > you Bob, you have enabled Alpha to survive another day. Some information would be nice... what was the problem? What was the solution? What versions are affected?
Re: Permedia 2 (Elsa Gloria Synergy) glint driver ?
On Sat, Apr 11, 2015 at 3:02 AM, Michael Cree wrote: > On Sat, Apr 11, 2015 at 09:29:17AM +, Markus wrote: >> Somewhere i still have an ATI Radeon 9250 PCI video card; >> do you think still will work ? > > Yes, that card will work. The only problem is that you may need to > compile the radeon driver into the kernel as the provided radeon > module is so large that it cannot be loaded by the kernel without > relocation errors. > > Cheers > Michael. It might be a nice project to add support for building only a single generation of hardware support into the module. It does support ~15 years worth of hardware by this point. :) -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAEdQ38FSDw2nCO4SBJ=lkyde7qsocewxdtjfwtbjofgmqzc...@mail.gmail.com
Re: iceweasel 10.0.1-1+alpha
On Mon, Feb 27, 2012 at 4:33 AM, Michael Cree wrote: > I've just got another > optimisation bug introduced in gcc-4.6 fixed. What's that? -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caedq38f6o-zx4tw4ua+o0cavjlh5o59g7czy07cwirr_phv...@mail.gmail.com
Re: Iceweasel [was Re: firefox-8.0.1]
On Sun, Nov 27, 2011 at 3:26 AM, Bob Tracy wrote: > Let's go with that last one. I was pretty sure I had more physical RAM > in my PWS 433au than I evidently do: /proc/meminfo implies I've got > somewhere in the vicinity of 576 MB, at least 512 MB of which is what I > purchased for the beast back in 2005 for US$96 (4x128MB). Swap is > approx. 1.5 GB, so you may safely assume the poor machine was thrashing > quite a bit. Just to get qt4-x11 to build required configuring an > additional GB of swap as a file within one of the filesystems that had > enough free space. Not exactly a good recipe for efficient performance. > The 433au supports up to 1.5 GB of PC66 RAM in six slots, so I'll try to > find 6x256 MB sticks if I can find them somewhere at a good price. Back > in 2005, my vendor of choice was http://www.kahlon.com, and they only > had the 512 MB kit (4x128MB). Hardly worth it. There's no upgrade for a PWS that's going to make it fast. I'd set up a distributed C/++ compiler if I wanted to reduce build times. -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caedq38gk55tasde_dippngt8qb++wievvodt+fcmoxsmtsp...@mail.gmail.com
Re: Alpha ES45 buildd
On Fri, Nov 11, 2011 at 5:16 AM, Tim Cutts wrote: > As I've said several times, the current ES45 buildd, goetz.debian.org, will > be available for someone to take as soon as the official Debian alpha ports > no longer need it for Lenny support. Once Wheezy is released, and official > Debian Alpha support therefore really does end, the two ES45's that I > currently host for Debian (and a third which we have kept so we have some > spare parts) will become available, and I'm sure the Sanger Institute will be > happy to donate them to the unofficial Alpha port, although someone else will > need to come and collect them from our data centre near Cambridge, UK, and > host them somewhere else. That's the thing. The hardware itself costs essentially nothing in comparison to having a place to keep them powered, cooled, and connected to the internet. If I understand correctly, you're saying once Debian ends support for Lenny, these systems will be turned off? Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caedq38h1usmot_kswcltsu0gk14ah3wud7+vwopv76kmaxo...@mail.gmail.com
Re: problem compiling kernel ld error relocation truncated to fit: GPREL16 against symbol
On Wed, Nov 2, 2011 at 10:54 PM, carl hansen wrote: > Problem compiling kernel 3.1, gcc 4.6.1 or .2, latest binutils > > I think it's ld error > google suggested -Wl,--no-relax, didn't make a difference, unless I > did it wrong > > > ld -static -N --build-id -o .tmp_vmlinux1 -T > arch/alpha/kernel/vmlinux.lds arch/alpha/kernel/head.o > init/built-in.o --start-group usr/built-in.o > arch/alpha/kernel/built-in.o arch/alpha/mm/built-in.o > arch/alpha/math-emu/built-in.o kernel/built-in.o mm/built-in.o > fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o > block/built-in.o lib/lib.a arch/alpha/lib/lib.a lib/built-in.o > arch/alpha/lib/built-in.o drivers/built-in.o sound/built-in.o > firmware/built-in.o net/built-in.o --end-group > init/built-in.o: In function `do_one_initcall': > /var/src.build/kernelbuild/latest/linux-3.1/init/main.c:682:(.text+0x8): > relocation truncated to fit: GPREL16 against symbol `initcall_debug' > defined in .sbss section in init/built-in.o > /var/src.build/kernelbuild/latest/linux-3.1/init/main.c:689:(.text+0xf8): > relocation truncated to fit: GPREL16 against symbol `initcall_debug' > defined in .sbss section in init/built-in.o > init/built-in.o: In function `set_reset_devices': > /var/src.build/kernelbuild/latest/linux-3.1/init/main.c:146:(.init.text+0x10): > relocation truncated to fit: GPREL16 against symbol `reset_devices' > defined in .sbss section in init/built-in.o > init/built-in.o: In function `init_setup': > /var/src.build/kernelbuild/latest/linux-3.1/init/main.c:293:(.init.text+0x5c): > relocation truncated to fit: GPREL16 against `.sbss' Yes, I hit this just two days ago. Using LDFLAGS="--relax" allows the compilation to finish, but it produced a kernel that panicked on boot. Not sure if it's related to binutils bug http://sources.redhat.com/bugzilla/show_bug.cgi?id=5276 or if its a gcc bug. Compiling with the same binutils and gcc-4.5.3 produced a working kernel though. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAEdQ38F-c5g=G2wQLToe3CbLTO2f=z+hx5_bpkvr6zi26i4...@mail.gmail.com
Re: iceweasel-6.0.2
On Thu, Sep 29, 2011 at 4:04 PM, Michael Cree wrote: >> Still have to specify "--disable-ipc" as well, which isn't >> necessary on supported architectures: that would need to be implemented >> and pushed upstream as well. > > I think that would be relatively straight-forward to implement. Some of the > kernel code probably can be used as a model. > > Matt: would you be interested in doing this? I suspect it is either you or > me who will have to do this and I am currently swamped with being an Alpha > buildd admin and fixing all the problems that result from the three month's > lost time building when we got demoted to Debian Ports. I'm interested, and I don't think it's a very hard problem. I just don't have time in the foreseeable future. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAEdQ38EhhrxCYzbm=nr3upiqscx_9z5iximfqmg6+_2edkn...@mail.gmail.com
Re: iceweasel-6.0.2
On Thu, Sep 29, 2011 at 12:18 PM, Bob Tracy wrote: > Woo-HOO! I'm pleased to announce a successful Alpha build of > iceweasel 6.0.2-1, xulrunner-6.0 6.0.2-1, and libmozjs6d 6.0.2-1. I > would *like* to make the ".deb" packages available for interested > parties to download and test, but I don't have the bandwidth locally. > > Assuming someone offers me an upload location so the packages can be > made available, please note the following disclaimers: > > (1) I'm not a Debian developer, therefore, the packages are *not* signed > and in no way should be considered official, i.e., if and when the > official packages are available via normal update channels, these > unofficial packages will be automatically replaced/updated. > > (2) The normal caveats about running software from the "experimental" > distribution should be heeded, i.e., these packages could grow hair on > your palms, curve your spine, crash your system, etc. That being said, > it all seems to work fine on my PWS 433au. > > (3) If you have currently-working versions of "iceweasel" and > "xulrunner" installed, you may want to have the corresponding packages > available to downgrade if there are problems. > > (4) Since you'll be doing a manual installation of the packages, check > them for dependencies *before* installing them: "dpkg --info file.deb" > is useful. > > --Bob I presume there are patches to make it all work? Posting those is a good place to start. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caedq38fu_a6plxg1vnkzouem9aify+jbuagrbgtucrs8ung...@mail.gmail.com
Re: Beware of new udev
On Mon, Sep 26, 2011 at 3:41 AM, Michael Cree wrote: > On 26/09/11 19:20, Michael Cree wrote: >> On 26/09/11 06:42, Uwe Schindler wrote: >>> Do you have linux-image-3.0-alpha-generic ? I am also upgrading, but want to >>> make sure I don't break my udev, but maybe it works with 3.0 already? >> >> Yes, I have linux-image-3.0-alpha-generic, nevertheless I was actually >> running a self-compiled kernel.org 3.0.4 kernel. >> >> I suspect it is either a libc6.1 issue or a kernel issue. Udev is >> calling the access4() function which is returning the 'Not implemented' >> error code. I note that the eglibc source has a test for kernel version >> 2.6.33-rc4 for the access4 kernel syscall. > > Oops. I meant to say the accept4 syscall. > > It is not implemented in the Alpha kernel! I don't know how we missed > that one. > > And glibc source has a comment in the file > ./sysdeps/unix/sysv/linux/alpha/kernel-features.h that the accept4 > syscall is in the Alpha kernel since version 2.6.33-rc1. The author of > that comment (who will know who he is) was sadly misinformed. Strange. I'm looking through git for some indication of why I'd have thought that, and I can't find anything. *shurg* Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caedq38hqouj3gmojpsmengmsqduf8wb0ma42ndc8oovcdz_...@mail.gmail.com
Re: Where to start hacking unstable on Alpha?
On Sun, Jul 3, 2011 at 9:05 AM, Gianluca Bonetti wrote: > I suggest a simple CMS based web site, say Drupal CMS with forum and > project handling modules to help developers in sharing their knowledge > and hacking efforts up to a positive result for everyone. > If such solution is already available somewhere, I apologize because I > haven't find by googling an hour. Did you try 'alpha linux' as keywords? http://alphalinux.org/wiki/index.php/Main_Page Please use this website. I spent a lot of time creating it. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caedq38em+cxv2lawlwygbsq+hyloom6gt4kn89auegad_ak...@mail.gmail.com
Re: firefox-4.0.1
On Fri, May 6, 2011 at 5:12 PM, Michael Cree wrote: > BTW, I don't think anyone has implemented the Alpha specific code for IPC. > I think firefox has to be compiled with --disable-ipc. IIRC, the > architecture specific code is a set of atomic operations, of which the > implementation probably could be based on the equivalent code in the Linux > kernel source. The is on my list of things to do but I doubt I will get > this far down my list for quite some time. Looking at the code, this should be pretty trivial. I started looking last night, and then wondered why in the world didn't they just use gcc's atomic __builtins? They Already separate other platforms files into x86_gcc, x86_macos, and x86_msvc. Seems like all gcc platforms with atomic __builtins could be replaced with a single file. Plus, I figure that gcc having some semantic knowledge of the algorithm should allow it to produce better code, and the __builtins should of course be less fragile and prone to errors than inline assembly. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=wna45og73nnsmp1yuamwszs6...@mail.gmail.com
Re: Compaq Fortran Compiler RPM Decryption Key
On Fri, Apr 22, 2011 at 10:25 PM, Peter Barfuss wrote: > Hi All, > > It seems that Compaq/HP seem to completely ignore the existence of the > Compaq Fortran Compiler for Alpha (their enthusiast/education > licensing page ultimately leads to a dead server... not just a 404, a > stone-dead server), and while I've managed to acquire > cfal-1.2.0-4.alpha.rpm.crypt, it's, well, encrypted. With a gpg key > that appears to be unobtanium. > > Does anyone have any idea where I may get this key? Or, for that > matter, email it to me? > > Thanks, > Peter You can get the decrypted rpm (and all the other Compaq tools and libraries) here: http://alphalinux.org/software/ccc/ Thanks, Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=omsaxdy-3zwtd7cxrpnusm7z...@mail.gmail.com
Re: alpha and hppa removal from unstable/experimental
On Sun, Apr 3, 2011 at 8:51 AM, Aurelien Jarno wrote: > On Sun, Apr 03, 2011 at 12:42:52PM +1200, Michael Cree wrote: >> At the time Alpha was removed from the testing distribution it did >> have serious issues and was criticised for a lack of upstream >> support. The upstream support has now largely been addressed. The >> kernel is now up to date with other architectures and is being >> supported. X windows is now working on the more modern Alphas (i.e. >> those with the BWX CPU extension), and the fixes to get KMS working >> on Alpha will soon make their way into the kernel. There is now >> upstream support addressing issues in the compiler toolchain and >> glibc. >> > > I would not say the same about glibc upstream support. When glibc 2.13 > has been released, it was not even compiling on alpha. After fixing the > build part, the testsuite results were very bad. You need a bunch of > patches to get it in a correct state, and I am the one who spent time > to write most of them. This is partly due to the fact that I hate trying to submit things to glibc. Also that I don't have any time right now. But mostly because I hate glibc development. I pushed a lot of patches we'd been carrying in Gentoo before 2.12, but I don't have the time or willpower to even follow all the "I made this change to the MIPS headers. Alpha will want to do the same"-type changes. I really appreciate you tracking down and fixing a lot of glibc problems recently. Thanks, Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktimjb3mu5ahcn8hepyzb1uddnq_...@mail.gmail.com
Re: alpha and hppa removal from unstable/experimental
On Fri, Apr 1, 2011 at 8:55 PM, Mark Hymers wrote: > Hi, > > As mentioned in the recent ftp-team meeting minutes, we're planning to > remove alpha and hppa from unstable. They were removed from testing > before the squeeze release and there's no sign that they will be release > architectures for wheezy. As such, we're planning to remove them from > unstable and experimental in the next few days. buildd support for > unstable and experimental will also be ended at that time, but will > obviously continue for lenny updates / security builds. > > Before we remove the architectures, archives will be taken for anyone > who wants to take a copy of the dump to use elsewhere. These dumps will > be made available on request. > > Thanks, > > Mark > > > -- > Mark Hymers > > Ganneff: I'm confident in your ability to create a flamewar. > Extremedura QA/i18n meeting 2008 > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQIcBAEBCAAGBQJNljvVAAoJEBG05f8VsP2CGKQP/1uNWPmrByhuR0QttS053LFV > EFS1pmo9uxjUSKrhjHVBVViJGWQkLXJ+33wQ70FKa7ZAFFwZSkx34nk7bHYDipMH > cpKHiTQ0uf8MD0LNpsbgq8qhZGku17MZIa481p22ahuTIgBAt0d08gxCWh1DG+Dt > fIn+9ePwyFSCJuvcGk4gwwUL5Gx/PkKsGSVMxrSPhObAKq7iPcCVfXdjQF74eBfR > mMVw2koqsLOpYG7OTyY9JFDF1+vhyx9LqcPrikoMFgJptwWRNzCQzT0Lhk7Vxtav > LGXZxlAUuqaUk7D8gm4zVJgnkXCynRVoU/du3Mu3zAIzcFtEVDnO56DEwc2emxI4 > 7kY80PzPUXoXTlb98kVpIG6LEuo1jkvRk20M+8aBgsc6nJNVVIbKqeSMyi295Q4a > AWkE15+Dok/PwYzLuPuBxusOKe2CBZg7y8w+Rc8a4WzDCi9jZyLx5WiqcGZ9yxD8 > jJLyGKYo8q9X3yY5CwBIshb6x5IL/cT7QLOr/AlqTK96+i2c2qaSBgJyzF2ULAW6 > pu4qGVgyItfGiB0HQTjMOYWNBAbV54LNzfJuDoiJd7IdE5Wpyf8/LINey7eLhUst > oe/zsaRk2AjjgT2pm5OngSSLXcHaeBDIlXo6WaUkXB3Rol+yqlb3W1CJa9UkeOVH > xu2VbT9h4KzTusvv6RHF > =Bd7T > -END PGP SIGNATURE- Might want to hold off on that for alpha. There's been a flurry of emails in the last week working to revive it. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikq59tqbwtmqxnwzeanbc7q3pxm+rpwxosyx...@mail.gmail.com
Re: current status of alpha in squeeze - Storage Question - we will need to store the code some where - Fwd: Disk drives
On Mon, Mar 28, 2011 at 4:43 PM, Robert Garron wrote: > Joel, > > Can your group do what Bill is asking below? > Similar to the change of 36 gig to 300 gig... > > Regards, > Robert > > -- Forwarded Message -- > > Subject: Disk drives > Date: Mon March 28 2011 > From: Bill Parke > To: Robert Garron , Ken Ballou > > > Ask Joel if SATA drives, with 4KB block size drives can be supported. > Anything > over 2.7TB disk drives are not addressable in 512 byte blocks. > > Also, I believe the general Grub 2 (We need to get to it) supports GPT drives > so > there may or may not need to be microcode changes needed. Or the Grub folks Microcode changes for what? This seems like much ado about nothing. Here's the thing to do: use an old IDE or SCSI disk for booting the Alpha. In many cases, an IDE->Compact Flash adapter will allow you to boot from Compact Flash. >From there, once Linux loads you're free to load the root filesystem from any disk the kernel has drivers for. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimvfj-wuw90gx7qdsnkjceabogliqz+olyzn...@mail.gmail.com
Re: current status of alpha in squeeze - Next Steps
On Tue, Mar 29, 2011 at 3:09 AM, Robert Garron wrote: > Stop creating a new thread every time you reply. It makes reading the email chains difficult. -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTikC7iaA56footYuTEjFz_-mdzqk5TJ--pkT=b...@mail.gmail.com
Re: current status of alpha in squeeze
On Mon, Mar 28, 2011 at 7:28 PM, A.B. wrote: > I did not find any distribution which could run on my alphas. I don't think you looked very hard. I wrote this page in Nov 2008 and it's barely changed since: http://alphalinux.org/wiki/index.php/Alpha_Linux_Wiki:Community_Portal#Distributions > Are my computers interesting and/or practical for your purposes or are the > realy out-dated? They're pretty outdated, especially things older than EV6. For, say, an 800 MHz UP1500, it's a usable, if a bit slow, system. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinx21dwpbgawgo5la_atj56arovdulvurd5q...@mail.gmail.com
Re: Debian on Alpha
On Mon, Mar 28, 2011 at 7:42 PM, Mark Wickens wrote: > Hi Guys, > > I'd like to add my offer of support to the issue of debian on alpha. > > Should we get a wiki together to help keep the effort going? I'd be happy to > get something together for us to focus the effort if it will help other than > using the alpha mailing list. http://alphalinux.org/wiki/index.php/Main_Page -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTimJC+dEMxVdQ9Hu=rm1r_hhq+e8xh7urvjv7...@mail.gmail.com
Re: current status of alpha in squeeze
On Mon, Mar 28, 2011 at 2:59 PM, Joel Nimar wrote: > Hi Robert: > Glad to hear from you and thank you for your kind words. Pyramid can help > you with firmware upgrades. We have microfiche and cd's that tell us the > minimal acceptable revision level for maintenance and a firmware library we > have kept over the years. We can also maintain and repair systems both here > and abroard (I actually have a great technician in AU). What kind of firmware/microcode are we talking about? I kept reading these emails and then wondering if my brain was short circuiting. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTikw7JU15rWqHAQbB4fwBTpEQN8TYe=thydri...@mail.gmail.com
Re: recent udev upgrade failure on alpha
On Thu, Feb 24, 2011 at 10:09 AM, Uwe Schindler wrote: > My bigger problem is that recent kernels (even the stable one no longer work > for me). On mounting my root xfs filesystem it produces a message about a > wrong relocation format / some other linking problem when loading the XFS > .ko (the exact message is not known, its somewhere in the screen buffer of > the already rebooted with older kernel machine, I can only remember what the > problem was - next time I try I will take a pen and write down the message > on console). This happens with the last stable kernel version, did not test > 2.7.37-1 until now. > The last kernel that works for me is 2.6.31-1-alpha-generic. Does anybody > knows what the problem loading the XFS module is? > > Unstable is else still running fine! This is the first I've heard of XFS not working (though, I've never used it myself). Have you reported this anywhere? Please mail linux-al...@vger.kernel.org and the appropriate XFS mailing list to try to get this fixed. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=3mY=dukhcrjfe_1-ipomv8ohsgwqc1of9z...@mail.gmail.com
Re: Netboot a 5305?
On Sun, Dec 19, 2010 at 4:02 PM, Mark Ter Morshuizen wrote: > Anyone know if it is possible to netboot a Alphaserver 5305 without mopd? > My CD-ROM seems flaky and I forgot the root password after not using the > machine for about 3 years. If it's like every other alpha, you should just do something like set ei*0_protocols bootp in SRM, where ei*0_protocols corresponds to the network device you want to boot from. Then just `boot -f `. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktiko1ptdpisy57lcbf2scfrqtyex8mkandj6y...@mail.gmail.com
Re: DSO linking changes for wheezy
On Mon, Nov 15, 2010 at 8:15 PM, Samuel Thibault wrote: > Matt Turner, le Mon 15 Nov 2010 19:51:10 -0500, a écrit : >> On Mon, Nov 15, 2010 at 7:24 PM, Roger Leigh wrote: >> > What's the actual problem --as-needed is trying to solve? >> > >> > The answer is mainly unwanted libraries being linked in as a result >> > of using pkg-config (and various other -config variants), though there >> > are other, lesser, culprits. The pkg-config .pc files for gtk, gnome >> > and other libraries add in many libraries, most of which aren't >> > typically needed. >> > >> > The solution: fix the .pc files! >> > >> > Using --as-needed is merely papering over the actual root problem. >> > It "fixes" the symptoms, but it's not addressing the actual cause. >> > The number of packages providing broken .pc files is not large, and >> > the number breaking due to relying on this brokenness is likely >> > just as small. >> >> I can't see why you think --as-needed is fundamentally wrong or unnecessary. >> >> Check out http://www.gentoo.org/proj/en/qa/asneeded.xml >> >> --as-needed has saved tons of time for upgrades like Cairo in Gentoo, >> where Cairo had been linked to glitz which is now useless and gone. > > Not a problem, if Cairo was properly exposing the dep. > >> So >> when people upgraded Cairo, all the software that linked against it >> (and also unnecessarily linked against glitz) > > Why did it get linked against glitz? That's where the problem is. I think because -lglitz was in cairo's .pc file. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=tex5afxojxthnva0wcvrha9b-njkem7dnc...@mail.gmail.com
Re: DSO linking changes for wheezy
On Mon, Nov 15, 2010 at 7:24 PM, Roger Leigh wrote: > What's the actual problem --as-needed is trying to solve? > > The answer is mainly unwanted libraries being linked in as a result > of using pkg-config (and various other -config variants), though there > are other, lesser, culprits. The pkg-config .pc files for gtk, gnome > and other libraries add in many libraries, most of which aren't > typically needed. > > The solution: fix the .pc files! > > Using --as-needed is merely papering over the actual root problem. > It "fixes" the symptoms, but it's not addressing the actual cause. > The number of packages providing broken .pc files is not large, and > the number breaking due to relying on this brokenness is likely > just as small. I can't see why you think --as-needed is fundamentally wrong or unnecessary. Check out http://www.gentoo.org/proj/en/qa/asneeded.xml --as-needed has saved tons of time for upgrades like Cairo in Gentoo, where Cairo had been linked to glitz which is now useless and gone. So when people upgraded Cairo, all the software that linked against it (and also unnecessarily linked against glitz) broke because glitz was missing. Maybe this isn't important for binary distributions. I don't know. I mean, I don't particularly care what Debian does. I just find the fervor with which you fight against --as-needed strange. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinsmth+krapikupgrww9niqqiy6ogmsuxdox...@mail.gmail.com
Re: DSO linking changes for wheezy
On Sun, Nov 14, 2010 at 8:40 PM, Adam Goode wrote: > On 11/14/2010 12:42 PM, Matt Turner wrote: >> Please ignore me if I've misunderstood the situation, firstly. >> >> Both Fedora and Gentoo are using --as-needed by default now. And from >> what I've read (google: site:blog.flameeyes.eu as-needed) --as-needed >> is certainly useful and prevents lots of unnecessary problems. >> > > I don't believe Fedora (as of 14) is using --as-needed. airlied_, does Fedora use --as-needed by default? Fedora 14 too? mattst88: yes -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikfcxtsqs4cz2of7ny7xyuev3bbgpdjko_sr...@mail.gmail.com
Re: DSO linking changes for wheezy
On Sun, Nov 14, 2010 at 10:06 AM, Roger Leigh wrote: > On Sun, Nov 14, 2010 at 01:51:49PM +0100, Kurt Roeckx wrote: >> On Sun, Nov 07, 2010 at 04:19:10PM +, Roger Leigh wrote: >> > On Fri, Oct 29, 2010 at 03:43:57PM +0200, Matthias Klose wrote: >> > > For wheezy I'm planning to change the linking behaviour for DSOs (turning >> > > on --as-needed and --no-copy-dt-needed-entries. The rationale is >> > > summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like >> > > to know about issues with these changes on some of the Debian ports, and >> > > if we need to disable one of these changes on some port. >> > >> > While I understand the rationale for --no-copy-dt-needed-entries for >> > preventing encapsulation violations via indirect linking, I don't agree >> > with the use of --as-needed *at all*. If a library has been explicitly >> > linked in, it shouldn't be removed. This is an issue for fixing in >> > individual packages, not in the toolchain. >> > >> > I can understand on using it on a per-package basis, but not in the >> > actual toolchain defaults. The compiler and linker *should not be >> > second-guessing the user*. This can break perfectly legitimate code >> > making use of ELF constructors and other features which won't be >> > picked out just by looking at symbol usage. >> >> People have been claiming that constructors or init section are a >> possible problem. I have yet to see an example where it breaks. > > It's not a very widely used feature. I'm sure it's trivial to make > such a test case. Portable software tends not to make use of ELF- > specific features like this, but that's not an excuse for breaking > perfectly legitimate code. > > But whether or not there are real life examples, --as-needed is > *fundamentally wrong*. It's deliberately *not doing what the user > requested*, and to make that misfeature the system-wide default > would be entirely inappropriate. If a package wishes to make use > of such a feature after understanding the implications, then they > are free to do so. But to make it the default--I don't think that's > a technically sound decision. Please ignore me if I've misunderstood the situation, firstly. Both Fedora and Gentoo are using --as-needed by default now. And from what I've read (google: site:blog.flameeyes.eu as-needed) --as-needed is certainly useful and prevents lots of unnecessary problems. "It's deliberately *not doing what the user requested*" -> In the case of Gentoo, the problem is that the user himself isn't specifically requesting all these libraries are linked in. They're specified by the build system or .la files. If the user wants lots of libraries linked in unnecessarily, then he can turn off --as-needed. So, I guess I'm not understanding what the problem with --as-needed is, exactly. Thanks, Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim6q3wvkh_crahhs_5rnkakq6rnfvfksmcpt...@mail.gmail.com
Re: Looking for two pairs of DS10L rails
On Sun, Sep 12, 2010 at 10:08 PM, Matt Turner wrote: > On Sun, Sep 12, 2010 at 10:02 PM, Tom Linden wrote: >> Try Puget Sound Data Systems > > Thanks for the email. I guess these are the same people selling Alpha > CPUs for $650 on eBay [1]? > > I'm more looking more for donations, rather than paying more for a set > of rails than I could get a whole other DS10L. Is it worth me emailing > them? > > Matt > > [1] http://cgi.ebay.com/UP2000-API-UP2000-667-MHz-/350245437728 $195 for a pair of rails. :( As I thought... -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=p5qymnxdstkm_mgcdzoy7+vqnhcx-8sd1p...@mail.gmail.com
Re: Looking for two pairs of DS10L rails
On Sun, Sep 12, 2010 at 11:38 PM, Carl Lowenstein wrote: > On Sun, Sep 12, 2010 at 5:39 PM, Matt Turner wrote: >> Hi, >> I've got two DS10Ls sitting at OSUOSL [1] idle because they won't rack >> them without rails. >> >> They're going to be set up to help with Alpha development things. I'd >> be great to get some rails if someone has any. > > Are DS10L rails distinctly different from generic rails for arbitrary > 1U computers? According to one DS10L owner I asked, yes. But I'd be thrilled to find out otherwise. Thanks, Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=vbamagprxzuwuc=tmtujodd0-l1u3mr8sc...@mail.gmail.com
Re: Looking for two pairs of DS10L rails
On Sun, Sep 12, 2010 at 10:02 PM, Tom Linden wrote: > Try Puget Sound Data Systems Thanks for the email. I guess these are the same people selling Alpha CPUs for $650 on eBay [1]? I'm more looking more for donations, rather than paying more for a set of rails than I could get a whole other DS10L. Is it worth me emailing them? Matt [1] http://cgi.ebay.com/UP2000-API-UP2000-667-MHz-/350245437728 -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinovm+zf4ryo5ew+2xjmo_s2chmec--0qhyr...@mail.gmail.com
Looking for two pairs of DS10L rails
Hi, I've got two DS10Ls sitting at OSUOSL [1] idle because they won't rack them without rails. They're going to be set up to help with Alpha development things. I'd be great to get some rails if someone has any. Let me know if you've got some. Thanks, Matt [1] http://osuosl.org/ -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimgjywvw0zresya2yvmcnpeocaicmwrn5tks...@mail.gmail.com
Re: kernel regression on 164UX
(You might want to turn off HTML mail for mailing list posts.) On Tue, Aug 3, 2010 at 5:56 PM, Ian Las wrote: > Completed initial tests. > Last working kernel for 164Ux is 2.6.22.19 > First broken kernel is 2.6.23 > Installed Git package. > Need some help how to continue: > As linux-2.6.23 is older than 2.6.22.19 would it be possible to specify > 2.6.22.19 as good and 2.6.23 as bad ? > It has a higher revision number but is actually older ! > Or is it necessary to start with a good older revision which would be > 2.6.22.9 ? > Do I need the git repository from " git clone > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git " ? > What would be the best starting point ? > > Ian Hi Ian, Yes, the first step is `git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git` If 2.6.22 is working, and 2.6.23 is not working, we can bisect this to find the breaking commit. (2.6.22.19 -> 2.6.23 is not a linear change, as they both came from 2.6.22, and not one from another.) So from your linux-2.6 git directory, you would do git bisect start git bisect good v2.6.22 git bisect bad v2.6.23 and then it'll guide you through the process. If you're able to boot an intermediate kernel, you'll run `git bisect good` and if you're not able to boot a particular revision, you'll run `git bisect bad` until you find the exact commit that caused the problem. Thanks for doing this. Let me know if there's anything I can do to help. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktindg9odfvx4asp2oo80jmyt+adwn7zvvazkw...@mail.gmail.com
Re: current state of sid (unstable)
On Tue, Aug 3, 2010 at 5:35 PM, Michael Cree wrote: >> Comments welcome. I've received one strong recommendation to give >> Gentoo a try, > > Matt, no doubt :-/ He's a great evangelist for Gentoo. Turn that :-/ upside.. well, not down. :-\ is pretty much the same. (Yes, it was me) >> presumably because the Alpha platform is still supported >> by Gentoo. > > Well, to note, the Alpha platform is not completely unsupported by Debian. > That Alpha is still in Debian Unstable attests to that fact. > > I tried installing Gentoo about a year ago on a PWS600au but had such a bad > experience that I have never looked at Gentoo again. It took a whole > weekend to just get the machine to boot to the point that I could actually > log in to the shell on the console. There were quite a number of boots into > a machine for which all of the keyboard, the serial port and networking > didn't work so I couldn't get access, rebooting with the rescue disk and > manually running every step of the boot process to get the gentoo system up > to a useable state and then recompiling the kernel. Bah, humbug, I like to > spend my weekends doing more useful things than that. > > Cheers > Michael. I don't want to make this a distro war, but your waste of time almost definitely could have been avoided by asking a question or two of the six or seven Gentoo/Alpha users on the #alpha IRC channel, to which you're already connected. I like Gentoo, I admit, but even if I weren't using Gentoo on my non-Alpha systems, I'd recommend it to Alpha users. It's less about $x feature than it is that Gentoo actively supports Alpha/Linux. We actively find, report, and fix bugs in the Kernel, gcc, glibc, and X.Org. But the name of the distribution isn't important. That one has active developers working on it while another does not, however, is important. I'd (We'd) love to consolidate Alpha/Linux users on one distribution. It simply makes things better and easier for everyone. I know that at this point I'm experienced with Gentoo installations, but I can have a system up and running in a few hours most of the time (and most of this time is compilation of software, which contrary to popular opinion is not necessary to watch). The process isn't as painful as many would have you believe. Thanks for understanding, Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimuepzfo7xfbm39h1phr3t+pyx4_bpn2ryq9...@mail.gmail.com
Re: Upgrading Sarge to Etch - failing to boot new kernel
On Fri, Jul 30, 2010 at 7:10 PM, Ian Las wrote: > > > --- Michael Cree schrieb am Fr, 30.7.2010: > > >> > >> Well, no, it looks to me like he has to use MILO, as he mentions a > >> 164LX with AlphaBIOS and a 164UX which only has ARCSBIOS. > > >Fair enough. Obviously a better description of the problem is required from > >the >initial reporter. > > >Cheers > >Michael. > > Sorry for my incomplete description. > > But my problem is as you have guessed correctly using a newer Linux kernel on > > a 164UX system. > > The last kernel which works for me on the 164UX is 2.6.22. > > Have tried newer versions (2.6.27 and 2.6.31) on a 164LX with Alphabios which > > work correctly. > > This means it is not mandatory to use SRM Console with newer Linux kernels. > > The 164UX has unfortunately ARCSBIOS only. > > All my trials ended with kernel panic. > > Below the end of the message log: > > Major devices are: ramdisk (0001) fd (0002) ide0 (0003) sd (0008) sd (0041) > sd ( > 0042) sd (0043) sd (0044) > [MS-DOS FS Rel. 12,FAT] > ...Image loaded into memory, entry @ 0xfc31 > Setting up Milo reboot parameter block at 0xfc000140 > Boot line is bootdevice=sdb2 bootfile=vmlinux.gz root=/dev/sdb6 > Bootstrap complete, kernel @ 0xfc31, sp @ 0xfc304000 > ...turning on virtual addressing and jumping to the Linux Kernel > > Kernel panic - not syncing: Attempted to kill init! > > Thanks,ian > > --To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > http://lists.debian.org/2b1ccde9-d861-447e-b652-47ffd13e3...@orcon.net.nz If you could git-bisect this, it would go a long way toward getting it fixed. I've got a 164UX, but it doesn't have Linux installed, nor am I going to have any time to tinker with it for a while. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik39mg7n1qcleg3m5ooq=vhszvcymysrkvky...@mail.gmail.com
Re: Upgrading Sarge to Etch - failing to boot new kernel
On Thu, Jul 29, 2010 at 8:02 PM, Michael Cree wrote: > On 30/07/2010, at 9:24 AM, Ian Las wrote: >> >> Built a custom 2.6.27 kernel on a 164LX system with Alphabios and it works >> withouit any problems but unfortunately it seems that a kernel >= 2.6.23 >> does not work for a 164UX system. >> >> What is the reason for the problem and any chance to fix it in the future >> ? >> > > Second guessing that the problem (which you notably don't report) is that > the kernel fails to even start booting properly when booting with aboot I > suggest that you haven't updated aboot on your boot disk to the newest > version. I think it is about 2.6.23 that the newer aboot is required. Note > that upgrading the aboot package is insufficient to rectify this. You must > also run the swriteboot program on your boot disk. The man file for > swriteboot gives suitable instruction on its use. > > Cheers > Michael. Well, no, it looks to me like he has to use MILO, as he mentions a 164LX with AlphaBIOS and a 164UX which only has ARCSBIOS. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin+bw_hecsnq11vb3yesicziikep515tjhzo...@mail.gmail.com
Re: Upgrading Sarge to Etch - failing to boot new kernel
On Thu, Jul 29, 2010 at 5:24 PM, Ian Las wrote: > > Built a custom 2.6.27 kernel on a 164LX system with Alphabios and it works > withouit any problems but unfortunately it seems that a kernel >= 2.6.23 does > not work for a 164UX system. > > What is the reason for the problem and any chance to fix it in the future ? > > Thanks,Ian Do you want us to guess about your problem? Do you have an error message? What are the symptoms? Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik2snjxt8gldk1nhrdm4bz6jjx56hd-ckhvj...@mail.gmail.com
Re: Upgrading Sarge to Etch - failing to boot new kernel
2010/6/17 Piotr Gliźniewicz : > Hi, > > I'm trying to install Debian on my 164LX with AlphaBIOS. Since the newest > DVD I can boot from MILO (I'm using the one provided on the Woody DVD) is > Sarge, I installed it and begun upgrading to Etch (as advised in the Lenny > readme). I've done a clean, default install of Sarge. Then I upgraded to the > 2.6.8-4 kernel from the Sarge DVD and it worked without problems. What I've > done to upgrade to Etch: > > commented out Sarge CD in /etc/apt/sources.list > apt-cdrom add (with the 1st Etch DVD) > aptitude update > aptitude upgrade > aptitude install initrd-tools > aptitude install linux-image-2.6-alpha-generic > shutdown -r now > > At this point I can't boot the system with MILO. I'm trying to do it with a > command similar to the one I used to boot the 2.6.8-4 kernel: > > boot sdb6:vmlinuz-2.6.18-6-alpha-generic > initrd=initrd.img-2.6.18-6-alpha-generic root=/deb/sdb7 > > Disk is partitioned to the Sarge default structure. > sdb5 is the space reserved for aboot (empty) > sdb6 is /boot (ext2 - MILO is not able to read ext3) > sdb7 is / (ext3) > sdb8 is swap > > It seems MILO loads the image, but then fails to boot (it displays > bootfile=. > > Any hints how to start it? > > Best, > -- > piotrek > > > -- > To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/4c1aa739.4070...@gmail.com Do you have a compelling reason to use AlphaBIOS/MILO? Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikiagq95gflufmfzdlod0968kuyp9j41iqhq...@mail.gmail.com
Re: m4 test suite segfaults on alpha
On Wed, Mar 24, 2010 at 8:33 PM, Santiago Vila wrote: > Hello. > > m4 fails to build from source > > https://buildd.debian.org/build.php?&pkg=m4&ver=1.4.14-1&arch=alpha&file=log > > The build logs says: > > /bin/bash: line 1: 23419 Segmentation fault EXEEXT='' srcdir='.' > LOCALE_FR='none' LOCALE_FR_UTF8='none' LIBSIGSEGV='' LOCALE_FR='none' > LOCALE_TR_UTF8='none' LOCALE_FR='none' LOCALE_FR_UTF8='none' LOCALE_JA='none' > LOCALE_ZH_CN='none' LOCALE_FR_UTF8='none' LOCALE_FR='none' > LOCALE_FR_UTF8='none' LOCALE_FR='none' LOCALE_FR_UTF8='none' > PATH='/build/buildd-m4_1.4.14-1-alpha-hjyniv/m4-1.4.14/build-aux':"$PATH" > PATH='/build/buildd-m4_1.4.14-1-alpha-hjyniv/m4-1.4.14/build-aux':"$PATH" > LOCALE_FR='none' LOCALE_FR_UTF8='none' LOCALE_JA='none' LOCALE_ZH_CN='none' > "$tst" > test-strstr.log-t 2>&1 > FAIL: test-strstr > > Is this a bug in bash? > > Any help will be appreciated. This failure apparently does not prevent > m4 from entering testing (the ones in mips and mipsel do), but anyway, > I'm not glad that m4 FTBFS on alpha. > > Thanks. > > > -- > To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > http://lists.debian.org/alpine.deb.1.10.1003250104110.9...@cantor.unex.es Hmm. I just tried in our Gentoo development box, and 1.4.14 succeeded. Using gcc-4.4.2. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/b4198de61003241746p7009f0e8h7e2f589deb92e...@mail.gmail.com
Re: Bug#558752: www.debian.org: Too many Alpha porters on intro/organization
On Tue, Dec 8, 2009 at 8:15 AM, Rafael Ruiz wrote: > So, Nowdays there are a Linux distribution for Alpha working? > Is NetBSD and OpenBSD our only choice? Gentoo is the only actively maintained distribution. > Linux kernel is good for Alpha, specially 2.4. You should try 2.6. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#556790: gcc-4.3: unrecognizable insn on alpha
On Tue, Dec 1, 2009 at 3:08 PM, Michael Cree wrote: > On 18/11/2009, at 9:31 AM, Kurt Roeckx wrote: > >> Package: gcc-4.3 >> Version: 4.3.4-5 >> >> Hi, >> >> I recently started seeing several cases of gcc giving an error >> message like this: >> packet-l2tp.c:1680: error: unrecognizable insn: >> (insn 419 86 84 9 packet-l2tp.c:1585 (set (reg:DI 200) >> (ne:SI (reg:DI 76 [ prephitmp.1208 ]) >> (const_int 0 [0x0]))) -1 (nil)) >> packet-l2tp.c:1680: internal compiler error: in extract_insn, at >> recog.c:2001 > > > Would this be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113 ?? Hmm. The patch that _uncovered_ (not caused) the regression was http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8603 It was included in >4.3.4 (that is, not in 4.3.4), 4.4.2, and the 4.5 branch, so I don't think it could be 42113, but it certainly couldn't hurt to test. I'd be nice to know what this code is that triggers the error. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [gentoo-alpha] Need X testers on Alpha. I think we've got it this time.
On Thu, Oct 8, 2009 at 9:59 AM, Jarod Wilson wrote: > On 10/8/09 9:56 AM, Matt Turner wrote: >> >> On Thu, Oct 8, 2009 at 8:49 AM, Geoff Martin >> wrote: >>> >>> I have a 164LX with a Matrox Millennium II and a "just installed" >>> Debian Lenny, all hardware is the same as 10 years ago : ). Can I help >>> you >>> with the test? what do I need to do? >> >> In general, you need to install the xserver's dependencies, then using >> git, clone my repository, and compile and install the code. >> >> I'm not a Debian user, so I'm not sure what's the best way to do this. >> Maybe someone else with Debian knowledge can help. > > Not a Debian user either, but I believe... > > apt-get build-dep > > ...should do the trick, more or less. Thanks. I just wonder if it'll pull in the needed versions? X from git will require newer versions of various packages than xserver-1.5 or whatever version is available in Debian. I guess an alternative is to use Peter Hutterer's X super module, but I'm not too familiar with that either. I should also say that anyone interested in testing is encouraged to join our #alpha IRC channel on irc.freenode.net. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [gentoo-alpha] Need X testers on Alpha. I think we've got it this time.
On Thu, Oct 8, 2009 at 8:49 AM, Geoff Martin wrote: > I have a 164LX with a Matrox Millennium II and a "just installed" > Debian Lenny, all hardware is the same as 10 years ago : ). Can I help you > with the test? what do I need to do? In general, you need to install the xserver's dependencies, then using git, clone my repository, and compile and install the code. I'm not a Debian user, so I'm not sure what's the best way to do this. Maybe someone else with Debian knowledge can help. If you can put up with more compiling, Gentoo has some nice overlays which automate much of this process. Thanks, Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [gentoo-alpha] Need X testers on Alpha. I think we've got it this time.
On Thu, Oct 8, 2009 at 9:35 AM, Brian Parkhurst wrote:
> How do you recommend I download your repo for compiling under gentoo?
The easiest/best way is to first install layman (emerge layman) and
with it add the 'x11' overlay.
See here for instructions wrt layman:
http://en.gentoo-wiki.com/wiki/Overlay#Layman
Unmask/keyword =x11-base/xorg-server- and its dependencies. (You
might want to use app-portage/autounmask to make this a more automated
task.)
Copy the xorg-server-.ebuild from your layman overlay to your
local overlay (/usr/local/portage/x11-base/xorg-server/). Edit the
file and change this line:
EGIT_REPO_URI="git://anongit.freedesktop.org/git/xorg/xserver"
to
EGIT_REPO_URI="git://anongit.freedesktop.org/~mattst88/xserver"
In the folder where this new ebuild exists, run `ebuild
xorg-server-.ebuild digest`
At this point you should run `emerge =x11-base/xorg-server-` and
sit back and wait. When this has finished, emerge whatever X11 drivers
you need (xf86-input-evdev, xf86-video-{ati,glint}) and do some
testing.
I don't know what your level of proficiency with Gentoo is, but if
it's not high then this process will sound hard--trust me, it's really
not. The alternative would be much more complicated.
Thanks,
Matt
--
To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [BUG] recent squeeze X11 updates causing SIGSEGV on startup
On Mon, Sep 14, 2009 at 11:34 AM, Julien Cristau wrote: > On Mon, Sep 14, 2009 at 11:27:28 -0400, Matt Turner wrote: > >> Hi, >> >> Thanks for the report. I was getting the exact same failure as you. >> >> The crash happens in xf86SlowBCopyFromBus, which seems to be totally >> useless. So I killed that code: >> http://cgit.freedesktop.org/xorg/xserver/commit/?id=5ef53a94ce4e48e11de26290cd677266308640c8 >> >> If anyone finds that it's needed on some systems, let me know and >> we'll figure out something. Otherwise, that code is gone from >> xserver-1.7 and shouldn't cause any more problems. >> >> I don't know if anyone is planning another 1.6.x release, but if they >> are, they might consider cherry-picking that commit. >> > It can probably be cherry-picked to our package in any case, if someone > confirms that it's enough to make things work. > > Cheers, > Julien > Unfortunately, it's not. It just gets you past that segfault. I might have further broken sparse mapping support with it as well. We just need to get to a point where _something_ works on Alpha, and then we'll go back and fix sparse. Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [BUG] recent squeeze X11 updates causing SIGSEGV on startup
Hi, Thanks for the report. I was getting the exact same failure as you. The crash happens in xf86SlowBCopyFromBus, which seems to be totally useless. So I killed that code: http://cgit.freedesktop.org/xorg/xserver/commit/?id=5ef53a94ce4e48e11de26290cd677266308640c8 If anyone finds that it's needed on some systems, let me know and we'll figure out something. Otherwise, that code is gone from xserver-1.7 and shouldn't cause any more problems. I don't know if anyone is planning another 1.6.x release, but if they are, they might consider cherry-picking that commit. Thanks, Matt Turner On Mon, Sep 14, 2009 at 11:11 AM, Bob Tracy wrote: > I'll file a proper bug report later, but thought I'd at least raise the > alarm that X11 on the Alpha became unusable over the weekend after I > applied recent squeeze updates. The X server dies with SIGSEGV (11) on > startup. Michael: I'm guessing you've seen this :-). Here's the log... > > X.Org X Server 1.6.3 > Release Date: 2009-7-31 > X Protocol Version 11, Revision 0 > Build Operating System: Linux 2.6.26-2-alpha-generic alpha Debian > Current Operating System: Linux smirkin 2.6.31 #1 Fri Sep 11 18:23:45 CDT > 2009 alpha > Build Date: 01 August 2009 07:42:05AM > xorg-server 2:1.6.3-1 (bui...@goedel.debian.org) > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (==) Log file: "/var/log/Xorg.0.log", Time: Mon Sep 14 08:55:21 2009 > (==) Using config file: "/etc/X11/xorg.conf" > (==) ServerLayout "Default Layout" > (**) |-->Screen "Default Screen" (0) > (**) | |-->Monitor "Hennessy Generic 15" > (**) | |-->Device "Radeon 7500 QW" > (**) |-->Input Device "Generic Keyboard" > (**) |-->Input Device "Configured Mouse" > (==) Automatically adding devices > (==) Automatically enabling devices > (**) FontPath set to: > unix/:7100, > /usr/share/fonts/X11/misc, > /usr/share/fonts/X11/cyrillic, > /usr/share/fonts/X11/100dpi/:unscaled, > /usr/share/fonts/X11/75dpi/:unscaled, > /usr/share/fonts/X11/Type1, > /usr/share/fonts/X11/100dpi, > /usr/share/fonts/X11/75dpi, > /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, > /usr/share/fonts/X11/misc, > /usr/share/fonts/X11/cyrillic, > /usr/share/fonts/X11/100dpi/:unscaled, > /usr/share/fonts/X11/75dpi/:unscaled, > /usr/share/fonts/X11/Type1, > /usr/share/fonts/X11/100dpi, > /usr/share/fonts/X11/75dpi, > /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, > built-ins > (==) ModulePath set to "/usr/lib/xorg/modules" > (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' > will be disabled. > (WW) Disabling Generic Keyboard > (WW) Disabling Configured Mouse > (II) Loader magic: 0x1f00 > (II) Module ABI versions: > X.Org ANSI C Emulation: 0.4 > X.Org Video Driver: 5.0 > X.Org XInput driver : 4.0 > X.Org Server Extension : 2.0 > (II) Loader running on linux > (++) using VT number 7 > > (--) PCI:*(0:0:12:0) 1002:5157:1002:013a ATI Technologies Inc Radeon RV200 QW > [Radeon 7500] rev 0, Mem @ 0x1000/268435456, 0x0926/65536, I/O @ > 0x9000/256, BIOS @ 0x/131072 > (II) No APM support in BIOS or kernel > (II) System resource ranges: > (II) "extmod" will be loaded. This was enabled by default and also specified > in the config file. > (II) "dbe" will be loaded. This was enabled by default and also specified in > the config file. > (II) "glx" will be loaded. This was enabled by default and also specified in > the config file. > (II) "record" will be loaded. This was enabled by default and also specified > in the config file. > (II) "dri" will be loaded. This was enabled by default and also specified in > the config file. > (II) "dri2" will be loaded by default. > (II) LoadModule: "dbe" > (II) Loading /usr/lib/xorg/modules/extensions//libdbe.so > (II) Module dbe: vendor="X.Org Foundation" > compiled for 1.6.3, module version = 1.0.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension DOUBLE-BUFFER > (II) LoadModule: "ddc" > (II) Module "ddc" already built-
Re: [RFC] Dropping Alpha sparse mapping support from X
Thanks for the responses, everyone. On Fri, Sep 4, 2009 at 6:04 PM, Maciej W. Rozycki wrote: > On Thu, 3 Sep 2009, Matt Turner wrote: > >> I'd like to drop support for non-BWX Alphas (EV4 and original EV5) >> from X. These machines can't load/store to single bytes and require >> special sparse memory mappings. >> >> The code required to select which functions (sparse, dense) is >> convoluted, adds an extra layer of indirection, probably gets close to >> zero usage, and even less testing. >> >> Does anyone use X on EV4 or EV5 (not EV56, EV56 has BWX)? > > What's the problem with making it a build-time option? You may inline > the indirection based on a macro or suchlike and keep the more complicated > code for a reference, even if you don't get any bug reports for a while > (perhaps the code is perfect? ;) ). Linux is probably going to support > pre-BWX machines as long as the Alpha port itself and you may have > troubles reaching all the interested users, especially as not everyone > makes frequent upgrades. After reading this and discussing it with a lot of people on IRC, I think you're right: a build time option probably is the best choice. Wrapping appropriate parts in #ifdef __alpha_bwx__ should do the trick, but would require binary distributions to provide two binaries. But since we might not have any binary distros with Debian exiting the alpha scene, this shouldn't be a problem. Thoughts? > Personally, I have planned to make the DEC 3000 AXP (that's the > TURBOchannel family maxing out at EV45) Linux port going for a while now > and will most likely get at it once I'm done with some VAX/Linux fiddling > I'm currently involved with. Linux already supports a number of > TURBOchannel framebuffers for the MIPS port (for the purpose of > DECstations), including but not limited to the SFB+ board which works with > the TGA driver, and the drivers will work as soon as platform support code > has been done -- there shouldn't be any platform-specific code left in the > TURBOchannel drivers these days anymore. On a different note, I've got a VAX 4000 model 60 I could use to help, when you get that far. Thanks, Matt Turner -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[RFC] Dropping Alpha sparse mapping support from X
Hi, I'd like to drop support for non-BWX Alphas (EV4 and original EV5) from X. These machines can't load/store to single bytes and require special sparse memory mappings. The code required to select which functions (sparse, dense) is convoluted, adds an extra layer of indirection, probably gets close to zero usage, and even less testing. Does anyone use X on EV4 or EV5 (not EV56, EV56 has BWX)? Thanks, Matt Turner -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 1.7 and 7.5 status: we're frozen
> I have ati cards -- an RV280 and an RV610. It may be the weekend before I > can complete the compilation of the Xserver and run it. Thus far I've gotten three testers with matrox cards, but only me with a radeon. So this is excellent. > Sorry, but your instructions for that (in your reply to someone else's > reply) are complete gobbledegook to me. How to get on IRC? Pick a client (xchat, for instance), connect to irc.freenode.net and then '/join #alpha'. It's simple. You should be able to figure out any snags you run into. Thanks, Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Fwd: 1.7 and 7.5 status: we're frozen
Hi Jon, On Mon, Aug 31, 2009 at 9:00 PM, Dialup Jon Norstog wrote: > > Matt, > > I care enough to join. Just point the way (link) Get an IRC client and join #alpha on Freenode. I'm mattst88. > BTW, IBM just announced details of the forthcoming Power 7 CPU. Four cores > each with quad multithreading, 4.0 Ghz. Novakovic notes in his article in > Inquirer that core-for-core the new chip just about matches the EV8 - ten > years later. How ridiculous. > later > > jn -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Fwd: 1.7 and 7.5 status: we're frozen
Hi Alpha users, I just received the attached email from the xorg-devel list. X.Org 7.5 (xserver-1.7) has been frozen for release. I've not been able to get it to work on Alpha. I just received xserver commit access today, and I want to make sure that X.Org 7.5 works on Alpha in time for its release - so I need your help. Gentoo users: please use the x11 overlay from layman and build xorg-server- with associated dependencies. Debian/Fedora/other: please build X.Org from git. I need testing of various video cards/drivers, namely o xf86-video-ati, with[0] and without KMS o xf86-video-glint [0] o xf86-video-mga I don't care if you don't like IRC, please join for a couple days to help us make sure that we can have a quality X.Org/Alpha release. #alpha on Freenode. Additionally, there is a lot of code in the xserver to support Alphas without BWX instructions (EV4 and EV5, EV56+ has BWX). We could really clean up a lot of cruft by dropping support for these systems. Also, removing this extra layer of indirection might provide a small speed-up for BWX-enabled Alphas. So, does anyone care about X on EV4 or EV5 Alphas? I've cross-posted, so make sure you hit Reply-All. Thanks, Matt Turner [0] http://bugs.freedesktop.org/show_bug.cgi?id=23227 [1] http://bugs.freedesktop.org/show_bug.cgi?id=21546 -- Forwarded message -- From: Daniel Stone Date: Mon, Aug 31, 2009 at 8:19 PM Subject: 1.7 and 7.5 status: we're frozen To: xorg-de...@lists.x.org Hi, Sorry for the paucity of updates (as well as progress). After a chat with Peter, we decided to postpone XKB2 (yet again) to 1.8, to give it more time to mature, as opposed to just dropping it in the tree, and also to allow us to make any updates to Xi that may be required after actually deploying it with 1.7. This means that we're not blocking on anything major for 1.7 bar stabilisation work and bug fixes, which means ... XSERVER IS FROZEN. PLEASE DON'T COMMIT ANYTHING MAJOR, OR ANY API BREAKS, WITHOUT CHECKING WITH ME AND/OR PETER FIRST. 1.6.99.900 will be rolled some time over the weekend, with .901 to follow fairly shortly after that. We'll branch the server when it makes sense -- probably pretty close to .901 or .902. Xi proto/libs need a final release at some stage, but most of the other modules are looking fairly good at the moment, and indeed already have releases. I'm hoping this means a final 1.7 and 7.5 release shortly before, or during, XDC. If you maintain a weird platform, please get building the stack and let us know of any problems so we can release a 7.5 that actually works everywhere. As always, please let me know if you have any questions. Cheers, Daniel ___ xorg-devel mailing list xorg-de...@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel pgpkcYNbzdnU4.pgp Description: PGP signature
Re: Iceweasel / Iceape on Alpha Lenny
Hi, Gentoo has xulrunner-1.9.0.11-r1 marked stable and version 1.9.1.1-r2 as testing. Both ebuilds have this code in them which adds -Wl,--no-relax to the LDFLAGS. It doesn't look like this is what you're hitting, but better safe than sorry. # It doesn't compile on alpha without this LDFLAGS use alpha && append-ldflags "-Wl,--no-relax" Also, mozilla-firefox-3.0.11 is marked stable, and mozilla-firefox-3.5.1-r2 is marked testing. Both have that same LDFLAG appended in the ebuild. I seem to remember Gentoo hitting some runtime errors (maybe around version 3.0.7), but searching bugzilla isn't turning anything up. I'm CC'ing al...@gentoo.org to see if they remember anything. Matt Turner -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help on memchr() EGLIBC assembly code
On Mon, Jul 13, 2009 at 6:17 PM, Aurelien Jarno wrote: > On Mon, Jul 13, 2009 at 02:24:00PM -0400, Carlos O'Donell wrote: >> On Mon, Jul 13, 2009 at 1:31 PM, Aurelien Jarno wrote: >> > With a lot of patches (E)GLIBC 2.10 builds on alpha, but it fails on the >> > testsuite for the memchr() function, which is an optimized assembly code >> > on alpha. Unfortunately I don't speak alpha assembly very well, so help >> > is needed. >> > >> > The problem is that the memchr() function on alpha uses prefetch, which >> > can cause a page boundary to be crossed, while the standards (POSIX and >> > C99) says it should stop when a match is found. >> > >> > I have built a small testcase (see file attached), which contains the >> > code to trigger the bug and the assembly code of the memchr() function, >> > copied from EGLIBC. >> > >> > It would be nice if someone can fix the assembly code so that the >> > prefetching does not create memory faults. Thanks in advance. >> >> If you remove: >> ./sysdeps/alpha/alphaev6/memchr.S >> ./sysdeps/alpha/memchr.S >> and allow the build to fallback on string/memchr.c do the tests pass? >> >> You can always add memchr.S routines back in a later release if you >> need an immediate workaround. > > Yeah, it works, and that's actually my plan if I get no answer. But I > would really like to see this fixed now, as otherwise, it will most > probably stay like that indefinitely. > > -- > Aurelien Jarno GPG: 1024D/F1BCDB73 > aurel...@aurel32.net http://www.aurel32.net > I'm copying Richard Henderson and Ivan Kokshayshy on this, as they are without a doubt the most knowledgeable people about this sort of thing. As an aside, please make sure these two bugs are fixed in eglibc (I don't know if they exist in eglibc, but I do realize that you filed them against glibc yourself -- so this is just a reminder). http://sources.redhat.com/bugzilla/show_bug.cgi?id=5350 http://sources.redhat.com/bugzilla/show_bug.cgi?id=5400 Matt -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: AlphaLinux Wiki: Patches page created
Hi, On Tue, Apr 21, 2009 at 4:21 AM, Michael Cree wrote: > Matt Turner wrote: >> >> I've finally created a patches page on the wiki, >> http://alphalinux.org/wiki/index.php/Patches >> > > Good idea. > > I've applied the futex patches against a 2.6.29.1 kernel and have it > running. Any particular thing I should be doing or observing to give these > patches a good test? The glibc test suite, which is no small undertaking. ;) I haven't done thorough testing myself, but Ivan seems to think the patch is good to go, as he submitted them to the lkml on April 24. http://marc.info/?l=linux-kernel&m=124058445411123&w=2 http://marc.info/?l=linux-kernel&m=124058429810795&w=2 Separate, but he also submitted a patch that fixes build issues for titan and marvel systems. http://marc.info/?l=linux-kernel&m=124058429810792&w=2 Thanks, Matt Turner > Cheers > Michael. > > ___ > axp-list mailing list > axp-l...@redhat.com > https://www.redhat.com/mailman/listinfo/axp-list > -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
AlphaLinux Wiki: Patches page created
Hi, I've finally created a patches page on the wiki, http://alphalinux.org/wiki/index.php/Patches The hope is that the distributions that are still supporting Alpha will use this page to collaborate by posting links to patches here. The format should be == What the Patch Does == * Author: * Status: * Patch: link to patch/mailing list message/bug report or some minor variation thereof. Patches should be kept listed until a version of the patched software is released. That is, don't remove the patch again GNU ed 1.2 until 1.3 is released with the appropriate fix. -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: network-manager_0.7.0.97 fails to build on alpha
Hi,
Since the patch fixes a bug and is otherwise harmless, why not push it upstream?
Thanks,
Matt Turner
On Sat, Feb 28, 2009 at 6:34 AM, Arthur Loiret wrote:
> Package: network-manager
> Version: 0.7.0.97-1
> Severity: serious
> User: debian-alpha@lists.debian.org
> Tags: patch
>
> Hi,
>
> network-manager_0.7.0.97 fails to build on alpha because of a false-positive
> warning from gcc-4.2 (should not happen with gcc-4.3), here is a quick patch
> to fix it, which can be removed once alpha will switch to gcc-4.3:
>
> --- test/nm-tool.c.1 2009-02-28 12:13:13.0 +0100
> +++ test/nm-tool.c 2009-02-28 12:13:19.0 +0100
> @@ -508,7 +508,7 @@
> GHashTable *table)
> {
> DBusGProxy *proxy;
> - NMConnection *connection;
> + NMConnection *connection = NULL;
> const char *service;
> GError *error = NULL;
> GHashTable *settings = NULL;
>
>
> --
> To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>
--
To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: squeeze and the future of the alpha port, redux
On Fri, Feb 20, 2009 at 7:52 AM, Oliver Falk wrote: > Steve Langasek wrote: >> >> [ ... ] not >> to mention the serious problems of the port's viability implied by things >> like the lack of Java support > > gcj and openjdk work fine in Fedora. AFAIK, Gentoo also has Java for Alpha. > So it shouldn't be to hard to get it running on Debian! In theory, Java should work on Gentoo, but we've never put any effort into it. I don't think it should be a priority over things like glibc and X.Org. >> and the general absence of a porter community. > > Well. Gentoo is still porting and Fedora (esp. Jay and /me) also. > > [ ... ] > > I'd like to mention; *I* often saw patches that helped me solve (Alpha) > problems on Fedora. So. If there's no Debian Alpha port, my (Fedora Alpha) > 'work' will get harder :-) Of course not if the Debian Alpha folks switch to > Fedora... :-P Looks like this is again a call for a central place for patches. Then again, there is a serious lack of actual developers for Alpha. I'll see what I can figure out. Matt Turner > > -of > > > -- > To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The State of Alpha Linux
Hi Oliver, On Thu, Jan 8, 2009 at 8:23 AM, Oliver Falk wrote: > Hi Matt! > > > Matt Turner wrote: >> >> The State of Alpha Linux >> >> We're all subscribed to this list because we use a dying platform. > > You think it's dying? :-P > >> We do what we can to keep it going, but in recent months the State of >> Alpha Linux has been deteriorating at an accelerated rate. >> >> Let me outline some issues facing us today: >> 1.We have no glibc/Alpha maintainer [1] > > What can we do here? Who can take over this job. What skills are required to > take over the job? How much time does one have to spend to do the job? If > someone would volunteer, whom does he or she have to contact? I mailed glibc's libc-ports mailing list recently about this. http://sources.redhat.com/ml/libc-ports/2009-01/msg2.html Gentoo's Mike Frysinger was the only one to respond. If you think there's a chance you might be able to take over the job, I encourage you to mail libc-ports, as I don't know the answers myself. > >> 2.Kernel development for Alpha is comatose > > I do see some commits from time to time... Well, not much enhancements of > course... But there would be a few things that should be ported from x86 to > alpha... > >> 3.We can't run modern X.Org [2] > > At the moment. I guess it's just a fair bit of work and then we would be > able to run modern xorg. It's actually just one non-trivial bug (we hope). Kernel bug 10839. Also, see http://alphalinux.org/wiki/index.php/Bugs_to_watch > >> To make things worse, for such a small group of users, we're much too >> segregated and disorganized. For instance, how many (of the only four) >> Gentoo/Alpha maintainers are subscribed to this list? Debian/Alpha? > > I don't know if any other Alpha distribution maintainer is subscribed here, > but I do include debian-alpha m/l now and klausman (I think he's one of the > Gentoo Alpha maintainers). Yes, klausmann subscribed to this list after I told him to recently. :) > >> How many realized we were without a glibc maintainer? That we can't >> use X.Org 7.4? > > I can say, I did. > >> If this trend continues, we will completely first lose X.Org support. > > AFAIK, Ivan works on this, isn't he? Well, he has in the past. According to marc.info, after a 6 month absence on LKML, he sent a message yesterday. This absence also coincides with the time he stopped responding to kernel bug 10893. > >> I even had an X.Org developer tell me he didn't care [about Alpha >> support] when I pinged him about an Alpha bug he had originally filed >> [3]! > > What is the problem for the developers? They don't have alphas they can > access? We can help in this case. No, I don't think this is the problem at all. jcristau, the developer who told me he didn't care, has at least one alpha. None of the top tier X.Org developers seem to care at all about alpha. David Airlie told me he thought some of the problems we'd experience on Alpha with kernel modesetting would be very similar to problems on the Itanium, which he has to support. So he would be willing to put a little bit of effort into supporting Alpha, since the heavy lifting would already be done for Itanium. > >> We'll later lose glibc support. As it stands now, Alpha isn't even in >> the main tree [4]. I'm not sure what version Debian ships, but Gentoo >> is 3 versions behind at 2.6.1. Newer than that and the test suite >> causes a hard lock [5]. How much longer is it going to be before 2.6 >> is incompatible with the latest version and we begin to lose the >> ability to use other modern software? > > 2.9 runs fine and I'm trying to keep up 2 date with trunk to find bugs as > early as possible and patch it so it works. Also I'm using Gentoo and Debian > patches and post bugs in glibc bugzilla. > > So from my perspective glibc is not a problem. > gcc (as of 4.3.x) isn't a problem as well. From time to time there are build > problems, but normally easy to fix and I 'zilla them... The real problem is that nothing is going to get better in regards to glibc, it's only going to get worse as long as we have no upstream support. Unfortunately, some of the tests either fail or hang the system completely. This makes me think there are probably some corner cases where glibc would fail in normal applications. > >> While we may never lose kernel support, it will certainly begin to lag >> behind other platforms more and more. > > We do already lag behind; Eg. uptrace/ptrace, Execshield (only as dummy > functions at the moment). I don't know the cu
