Subject: Kernel vs. glibc problems

From: Karsten Merker <[email-masked]>
Date: Sun, 4 Apr 2004 13:52:12 +0200

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
<[email-masked]>
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.

---

From: Guido Guenther <[email-masked]>
Date: Sun, 4 Apr 2004 17:50:10 +0200

> causes (at least) ls, sleep and tar to die with "illegal instruction".
What is the illegal instruction? Gdb should tell.
Cheers,
 -- Guido

---

From: Karsten Merker <[email-masked]>
Date: Sun, 4 Apr 2004 19:35:12 +0200

> What is the illegal instruction? Gdb should tell.

It is an "ll" instruction in libpthread (checked in the cases of
ls, sleep and tar). ll/sc should be emulated by the kernel on R3k,
so it looks like there is a problem with the emulation code.

Regards,
Karsten

---

From: Karsten Merker <[email-masked]>
Date: Sun, 4 Apr 2004 20:55:51 +0200

> so it looks like there is a problem with the emulation code.

The reason seems to be in arch/mips/kernel/cpu-probe.c. In function
cpu_probe_legacy the following flags are set for R2k/R3k:

                c->options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX |
                             MIPS_CPU_LLSC;

i.e. R2k and R3k are assumed to have ll/sc implemented, so the
ll/sc emulation does not get called. The following micro-patch
should fix that.

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.
--- linux-mips-cvs-20040326/arch/mips/kernel/cpu-probe.c	Thu Feb  5 20:54:41 2004
+++ linux-mips-cvs-20040326.patched/arch/mips/kernel/cpu-probe.c	Sun Apr  4 20:23:21 2004
@@ -170,8 +170,7 @@
 	case PRID_IMP_R2000:
 		c->cputype = CPU_R2000;
 		c->isa_level = MIPS_CPU_ISA_I;
-		c->options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX |
-		             MIPS_CPU_LLSC;
+		c->options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX;
 		if (__cpu_has_fpu())
 			c->options |= MIPS_CPU_FPU;
 		c->tlbsize = 64;
@@ -185,8 +184,7 @@
 		else
 			c->cputype = CPU_R3000;
 		c->isa_level = MIPS_CPU_ISA_I;
-		c->options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX |
-		             MIPS_CPU_LLSC;
+		c->options = MIPS_CPU_TLB | MIPS_CPU_NOFPUEX; 
 		if (__cpu_has_fpu())
 			c->options |= MIPS_CPU_FPU;
 		c->tlbsize = 64;

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 5 Apr 2004 15:29:55 +0200 (CEST)

> ll/sc emulation does not get called. The following micro-patch

 I've checked in the patch as obviously correct, both to the mainline and
to the 2.4 branch.  Thanks for working on the issue.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +