Kernel vs. glibc problems
Hallo everybody,
I am experiencing problems with current kernels depending on which glibc
version I have installed and on which machine I run my tests.
On a DECstation 5000/150, having an R4000SC, everything works fine,
regardless which combination of kernel and glibc I use. Tested
combinations:
- Debian 2.4.19 plus Debian/Woody glibc (2.2.5)
- Debian 2.4.19 plus Debian/Sarge glibc (2.3.2)
- CVS 2.4.25 from 2004/03/25 plus Debian/Sarge glibc (2.3.2)
On a DECstation 5000/20, having an R3000, the following combinations work:
- Debian 2.4.19 plus Debian/Woody glibc (2.2.5)
- Debian 2.4.19 plus Debian/Sarge glibc (2.3.2)
- CVS 2.4.25 from 2004/03/25 plus Debian/Woody glibc (2.2.5)
But running the same CVS 2.4.25 with the Debian/Sarge glibc (2.3.2)
causes (at least) ls, sleep and tar to die with "illegal instruction".
Similar behavior regarding 2.4.25 plus Debian/Sid glibc (2.3.2) has
been reported for a DECstation 5000/133 (also R3k).
Besides, there has been a report on debian-mips in
<599FD8BDB7FBD511A4D10008C7CFB6DC06FB93DA@dfwex02.allegiancetelecom.com>
that similar behaviour also happened on a Cobalt box, which
has an R5k-compatible core. Quotation from that email:
"Last time I tried it, it broke tar, ls -l, gcc, and just about everything
else that called the gettimeofday() system call.", which fits
to my experiences on the R3k DECstations.
All this seems to point to some kernel-vs-glibc mismatch. The only
thing I could dig out in this regard was the change in struct msqid_ds
(see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=200215), but
that does not explain why this happens on an R3k DECstation but
not on an R4k DECstation while it happens on an R5k Cobalt,
and the change done there should not affect ls and sleep.
Strangely the CVS kernel works fine with the _old_ glibc on the
R3k DECstations, but not with the new one, even though it should
be the other way round as the CVS kernel AFAICS has the fixes
listes in the aforementioned bugreport.
Some problem with instruction emulation (ll/sc) on R3k came to
my mind, but that does not explain the problems on the Cobalt.
Any ideas what could cause this behaviour?
Regards,
Karsten
--
#include <standard_disclaimer>
Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung
oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder
Meinungsforschung.
Reply to: