Subject: sudo oops on mips64 linux_2_4

From: Florian Lohoff <[email-masked]>
Date: Wed, 16 Jul 2003 13:07:35 +0200

Hi,
i am getting this oops running anything with "sudo" on a mips64 sgi indy.
This is -r linux_2_4 of yesterday. Module support is not compiled in

strace output up to the oops is this:

[...]
old_mmap(NULL, 321040, PROT_READ|PROT_EXEC, MAP_PRIVATE, 0, 0) = 0x2adc8000
mprotect(0x2add7000, 259600, PROT_NONE) = 0
old_mmap(0x2ae16000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0x2ae16000
close(3)                                = 0
open("/lib/libnsl.so.1", O_RDONLY)      = 3
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0644, st_size=100028, ...}) = 0
old_mmap(NULL, 363472, PROT_READ|PROT_EXEC, MAP_PRIVATE, 0, 0) = 0x2ae18000
mprotect(0x2ae2f000, 269264, PROT_NONE) = 0
old_mmap(0x2ae6e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x16000) = 0x2ae6e000
old_mmap(0x2ae6f000, 7120, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, 3, 0x16000) = 0x2ae6f000
close(3)                                = 0
munmap(0x2aac4000, 9572)                = 0
uname({sys="Linux", node="debian", ...}) = 0
open("/etc/passwd", O_RDONLY)           = 3
fcntl64(3, F_GETFD)                     = 0
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
ioctl(4, 0x8912Oops in fault.c::do_page_fault, line 231:
Cpu 0

debian:~# sudo ls
Cpu 0 Unable to handle kernel paging request at address 0000000000000000, epc == ffffffff88171104, ra == ffffffff880159f0

These are by the System.map
	ffffffff88171104 l_exc
	ffffffff880159f0 dev_ifconf

Oops in fault.c::do_page_fault, line 231:
Cpu 0
$0      : 0000000000000000 ffffffff881e0000 0000000000000020 0000000000000000
$4      : 0000000000000000 ffffffff881dffff ffffffff881e0000 0000000000000020
$8      : 0000000000000000 0000000000000000 0000000000000000 0000000000000000
$12     : 0000000000000000 0000000000000001 0000000000000028 0000000000000003
$16     : ffffffffffffffff 000000007fff7a20 0000000000000000 000000007fff7a28
$20     : 0000000000000004 000000007fff7aa0 000000007fff7b60 000000007fff7bf0
$24     : 0000000000000000 000000002ad0d6f0
$28     : ffffffff8a188000 ffffffff8a18be30 000000007fff7c80 ffffffff880159f0
Hi      : 0000000000000040
Lo      : 0000000000000010
epc     : ffffffff88171104    Not tainted
badvaddr: 0000000000000000
Status  : b000cce3  [ KX SX UX KERNEL EXL IE ]
Cause   : 0000000c
Process sudo (pid: 225, stackpage=ffffffff8a188000)
Stack: 0000004000000000 000000050000013a 000000505d00f61c 0000000000000000
       ffffffff881cdd08 0000000000008912 ffffffff8a231a80 000000007fff7a20
       ffffffff880157dc 0000000000000002 000000007fff7e34 0000000000000004
       0000000000000004 000000007fff7a64 000000007fff7a60 ffffffff8801aeec
       0000000000000000 00000000100006c0 0000000000000fd6 0000000000000000
       0000000000000004 0000000000008912 000000007fff7a20 0000000000000000
       0000000000000000 0000000000000000 0000000010003ec0 0000000000000010
       000000002adc3f44 000000002adc3f44 0000000020666f72 0000000020256820
       000000007fff7e34 0000000000000001 0000000000000001 0000000000000002
       0000000000000000 000000007fff7aa0 000000007fff7b60 000000007fff7bf0
       0000000000000006 ...
Call Trace: [<ffffffff880157dc>] [<ffffffff8801aeec>]

Code: 0085202f  10c0fff2  64c5ffff <a0800000> 64840001  14a0fffd  64a5ffff  03e00008  00000000
Segmentation fault

-- 
Florian Lohoff                  [email-masked]             +49-171-2280134
                        Heisenberg may have been here.

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 16 Jul 2003 15:05:05 +0200 (MET DST)

> $4      : 0000000000000000 ffffffff881dffff ffffffff881e0000 0000000000000020

 Please pass it through ksymoops for more details.  Version 2.4.9 should
work just fine for mips64.

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

---

From: Florian Lohoff <[email-masked]>
Date: Wed, 16 Jul 2003 16:21:36 +0200

> work just fine for mips64.

This looks still broken - Giving the vmlinux file to ksymoops makes it
even worse - tons or errors.

ksymoops 2.4.8 on mips 2.4.19-r5k-ip22.  Options used
     -v /dev/null (specified)
     -k /dev/null (specified)
     -l /dev/null (specified)
     -o /dev/null (specified)
     -m /home/flo/System.map (specified)

Error (regular_file): read_nm_symbols /dev/null is not a regular file, ignored
Warning (read_vmlinux): no kernel symbols in vmlinux, is /dev/null a valid vmlinux file?
Error (regular_file): read_ksyms /dev/null is not a regular file, ignored
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000

>>PC;  ffffffff88171104 <END_OF_CODE+fffffffeffe868fc/????>   <=====

Trace; ffffffff880157dc <END_OF_CODE+fffffffeffd2afd4/????>
Trace; ffffffff8801aeec <END_OF_CODE+fffffffeffd306e4/????>

Code;  881710f8 <fbmem_read_proc+d8/100>
00000000 <_PC>:
Code;  881710f8 <fbmem_read_proc+d8/100>
   0:   0085202f  0x85202f
Code;  881710fc <fbmem_read_proc+dc/100>
   4:   10c0fff2  beqz    a2,ffffffd0 <_PC+0xffffffd0>
Code;  88171100 <fbmem_read_proc+e0/100>
   8:   64c5ffff  0x64c5ffff
Code;  88171104 <fbmem_read_proc+e4/100>
   c:   a0800000  sb      zero,0(a0)
Code;  88171108 <fbmem_read_proc+e8/100>
  10:   64840001  0x64840001
Code;  8817110c <fbmem_read_proc+ec/100>
  14:   14a0fffd  bnez    a1,c <_PC+0xc>
Code;  88171110 <fbmem_read_proc+f0/100>
  18:   64a5ffff  0x64a5ffff
Code;  88171114 <fbmem_read_proc+f4/100>
  1c:   03e00008  jr      ra
Code;  88171118 <fbmem_read_proc+f8/100>
  20:   00000000  nop

1 warning and 2 errors issued.  Results may not be reliable.

Flo

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 16 Jul 2003 17:21:20 +0200 (MET DST)

>      -m /home/flo/System.map (specified)

 Hmm, I would use "-V -K -L -O -m /home/flo/System.map" instead. ;-)  And
also "-t elf64-tradbigmips -a mips:5000" as you really want 64-bit
addresses and opcodes beyond R3k (and your ksymoops isn't configured to
use a 64-bit target by default).  Using vmlinux might give additional
information beyond what System.map can provide and it should work just
fine once right options are passed to ksymoops -- I used to get correct
output with no warnings at all. 

 At least we know the error is in drivers/video/fbmem.c:fbmem_read_proc() 
because of buf being null.  But please retry with the above options to get
some addresses decoded.

---

From: Ladislav Michl <[email-masked]>
Date: Wed, 16 Jul 2003 20:45:15 +0200

>  At least we know the error is in drivers/video/fbmem.c:fbmem_read_proc() 

and at least we know there is something wrong. why is fbmem compiled in
at all?

> because of buf being null.  But please retry with the above options to get

	ladis

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 16 Jul 2003 21:01:37 +0200 (MET DST)

> and at least we know there is something wrong. why is fbmem compiled in

 Well, that's not wrong per se and is actually valid at least for
CONFIG_FB_VIRTUAL.  And the code should fail gracefully if there nothing
useful to do.

---

From: Geert Uytterhoeven <[email-masked]>
Date: Wed, 16 Jul 2003 21:05:19 +0200 (MEST)

> CONFIG_FB_VIRTUAL.  And the code should fail gracefully if there nothing

You do not want to set CONFIG_FB_VIRTUAL=y, since the virtual frame buffer
device is meant for testing only.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email-masked]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Wed, 16 Jul 2003 21:54:30 +0200 (MET DST)

> device is meant for testing only.

 Sure -- and I should expect random crashes if I happen to enable it,
right?

---

From: Geert Uytterhoeven <[email-masked]>
Date: Wed, 16 Jul 2003 21:57:36 +0200 (MEST)

>  Sure -- and I should expect random crashes if I happen to enable it,

I don't think so. Even if you set CONFIG_FB_VIRTUAL=y, you have to explicitly
enable it by passing `video=vfb' on the kernel command line. And it shouldn't
cause random crashes (but you never know ;-)

Gr{oetje,eeting}s,

						Geert