Oopses of the day...

Dominique Quatravaux (quatrava@clipper.ens.fr)
Mon, 9 Dec 1996 23:06:20 +0100 (MET)


Hello all,

I've had lots of oopses, panics and machine checks today on my Noname,
running the latest glibc snapshot. Basically I've been unable to compile
the kernel release 2.0.27 while running under any of the following
kernels : 2.1.14 (homebuilt), 2.1.1 and 2.0.21 (grabbed from azstarnet).
The problem is that the -pipe option in gcc does not seem to work. After
fiddling the Makefile to make gcc use -v, one gets the following :

make[2]: Entering directory `/usr/src/linux-2.0.27/kernel'
gcc -v -D__KERNEL__ -I/usr/src/linux-2.0.27/include -Wall
-Wstrict-prototypes -g -O2 -pipe -mno-fp-regs -DMODVERSIONS
-DEXPORT_SYMTAB -c ksyms.c
Reading specs from /usr/lib/gcc-lib/alpha-linux/2.7.2/specs
gcc version 2.7.2
/usr/lib/gcc-lib/alpha-linux/2.7.2/cpp -lang-c -v [many other options]
ksyms.c |
/usr/lib/gcc-lib/alpha-linux/2.7.2/cc1 /tmp/cca00661.i -quiet -dumpbase
ksyms.c -mno-fp-regs -g -O2 -Wall -Wstrict-prototypes -version -o
/tmp/cca00661.s |
/usr/alpha-linux/bin/as -nocpp -o ksyms.o
[more verbosity]
init/version.ccc1: /tmp/cca00477.i: No such file or directory

cc1 is obviously passed the wrong command line by gcc. But the strangest
of the story is that this bug 1) is environment-dependent (using "env -i
PATH=/usr/bin" in front of gcc in the Makefile solves the problem) and 2)
can crash the kernels listed with various error messages such as :
* VFS: Wrong blocksize on device 08:02
VFS: grow_buffers: size = 262144 (this one repeated hundreds of times)
(this one with kernel 2.1.14)
* Two oopses (listed below) for kernel 2.1.1, and LOTS of further
oopses during the shutdown sequence;
* A bunch of machine checks I couldn't decode since they scrolled
too fast and weren't written to the logs with kernel 2.0.21.

I'm really screwed up with that new glibc, does anyone experience the
same problems ? It seems incredible to me that nobody noticed these
oddities except me...

Sorry, I couldn't figure out how ksymoops works. So here's the full
stuff...

Unable to handle kernel paging request at virtual address fffc00004468b90f
update(144): Oops 0
pc = [<fffffc0000312ff8>] ps = 0000

(from /proc/ksyms, that's all I have since this kernel is not
homebuilt)
fffffc0000311cd0 sys_call_table_R79fa4011
fffffc0000313750 hard_reset_now_R93031761

rp = [<fffffc0000312f38>] sp = fffffc00007e1d40
r0=42 r1=0 r2=14 r3=fffffc00007e1d68
r8=19
r16=fffffc00004405f0 r17=fffffc01c0007aa0 r18=50 r

r20=0 r21=2 r22=0 r23=fffffc000041c308
r24=1 r25=a r26=fffffc0000312f38 r27=fffffc000031d

r28=0 r29=fffffc000045ff08 r30=fffffc00007e1d40
Code: 47ff041f 415e0643 40641403 <2c290000> 2c49
0401 b4230000

kernel: unaligned trap at fffffc000033a020: fffffc

kernel: unaligned trap at fffffc000033a028: fffc00

Unable to handle kernel paging request at virtual address fffc00004468b90f
init(1): Oops 0
pc = [<fffffc0000312ff8>] ps = 0000
rp = [<fffffc0000312f38>] sp = fffffc00004d1d20
r0=42 r1=0 r2=14 r3=fffffc00004d1d48
r8=19
r16=fffffc00004405f0 r17=fffffc01c0007aa0 r18=50 r

r20=0 r21=2 r22=0 r23=fffffc000041c308
r24=1 r25=a r26=fffffc0000312f38 r27=fffffc000031d

r28=0 r29=fffffc000045ff08 r30=fffffc00004d1d20
Code: 47ff041f 415e0643 40641403 <2c290000> 2c49
0007 482906c1 48490f42 44220401 b4230000

-- 
<< Tout n'y est pas parfait, mais on y honore certainement les jardiniers >>
				Dominique QUATRAVAUX
				(Dominique.Quatravaux@ens.fr)