[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

ARM710 problems



Hello,

I've been trying to get Debian fully up and running on my ARM710
RiscPC in the last weeks. I have had no end of trouble with it, but at
last I have made some progress.

This mail is a bit long, but please read it, because I think there's a
fundamental problem somewhere! (e.g. autobuilders producing buggy
executables?)

Here's a list of binaries that segfault/behave oddly:
 - grep         (Error message "regexp too big", IIRC)
 - gzip         (Segfaults immediately)
 - apt-get      (Segfaults sooner or later, see below)
 - apt-cache    (Segfaults most of the time)
 - update-menus (Segfaults always after reading some files)
 - lynx         (Segfaults e.g. when trying to download to disk)
 - X            (Segfaults after displaying the checked background)

I was able to fix some of these, but not all. :-(
 - grep, gzip and update-menus work OK after a recompile.
 - lynx and X I haven't tried recompiling. (Anyway, those are the
   potato r0 versions, I should try upgrading first.)
 - apt-cache and apt-get are the cause of a bite-sized hole in my
   desk. Got them to work by pointing a loaded rocket thrower at my
   RiscPC while they executed. ;-/

I used Wookey's base system to successfully complete the first
installation stage (until the reboot). When booting from HD for the
second stage, the boot process failed because of grep/gzip not
working, but I was able to get to a shell.

Next, I built an ARM cross-compiler on my x86 machine and cross-built
the grep and gzip packages (against glibc-2.1.2). They have been
working fine, I've never had any more problems with them. (Should I
binary-NMU the packages? I can also upload them to my homepage for you
to have a look.)

I already posted a list of what I used for my cross-compiler to
armlinux-toolchain a while ago: unpatched binutils-2.10.1,
gcc-2.95.3.test3 (with inhibit-libc hack, but without fold-const
patch; left that out when I rebuilt the cross-compiler).

/Somehow/ I then got apt to work for long enough to install a useful
set of packages from a potato CD ROM I made for 2.2r0. Its behaviour
was really odd: Exactly one invocation of "apt-get update" would work
- to make it work again, I had to reinstall the package. (BTW,
contrary to Peter's guide, "apt-get update" crashes for me regardless
of whether it's called from the shell or by deselect.)

To cut a (very) long story short, I have found out that there is only
one particular combination of things that makes apt work reliably for
me so far: apt-0.3.19 recompiled by my cross-compiler
_against_glibc_2.2_, glibc-2.2.1-1 from testing and a 2.4 kernel. 
*None* of the following works:

- apt-0.5.0 and glibc-2.2.1-1 from testing on 2.4 - segfaults
- apt-0.3.19 (recompiled by me) and glibc-2.1.3 - segfaults
- apt-0.3.19 (recompiled by me), glibc-2.2.1-1 from testing,
  and a 2.2 kernel - crashes the kernel!!!

I haven't tried recompiling apt-0.5.0 so far. I don't think I'll touch
anything anymore, now that it appears to work at last. The 2.2 kernel
is 2.2.16, the 2.4 kernel is 2.4.1 built by Phil for me when I first
reported my problems. BTW, all those segfaults almost invariably
happen in string handling functions - both with C and C++. IIRC, I
have been using libstdc++2.10_1:2.95.2-13 all the time.

All this leaves the question: What is it that makes things break for
me, but nobody else? Does the regular, native GCC for ARM contain
additional patches? Could apt or glibc contain some really weird bugs? 
Is the NSA behind all this? Do little green men really live inside my
computer?

All the best,

  Richard

PS: Congratulations for the Aleph ARMLinux coverage in LWN! :-)
-- 
  __   _
  |_) /|  Richard Atterer     |  CS student at the Technische  |  GPG key:
  | \/¯|  http://atterer.net  |  Universität München, Germany  |  888354F7
  ¯ ´` ¯

Attachment: pgpYnJCC5bZyV.pgp
Description: PGP signature


Reply to: