All of lore.kernel.org
 help / color / mirror / Atom feed
* sudo oops on mips64 linux_2_4
@ 2003-07-16 11:07 Florian Lohoff
  2003-07-16 13:05 ` Maciej W. Rozycki
  0 siblings, 1 reply; 10+ messages in thread
From: Florian Lohoff @ 2003-07-16 11:07 UTC (permalink / raw)
  To: linux-mips

[-- Attachment #1: Type: text/plain, Size: 3591 bytes --]

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                  flo@rfc822.org             +49-171-2280134
                        Heisenberg may have been here.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: sudo oops on mips64 linux_2_4
  2003-07-16 11:07 sudo oops on mips64 linux_2_4 Florian Lohoff
@ 2003-07-16 13:05 ` Maciej W. Rozycki
  2003-07-16 14:21   ` Florian Lohoff
  0 siblings, 1 reply; 10+ messages in thread
From: Maciej W. Rozycki @ 2003-07-16 13:05 UTC (permalink / raw)
  To: Florian Lohoff; +Cc: linux-mips

On Wed, 16 Jul 2003, Florian Lohoff wrote:

> 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

 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: macro@ds2.pg.gda.pl, PGP key available        +

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: sudo oops on mips64 linux_2_4
  2003-07-16 13:05 ` Maciej W. Rozycki
@ 2003-07-16 14:21   ` Florian Lohoff
  2003-07-16 15:21     ` Maciej W. Rozycki
  0 siblings, 1 reply; 10+ messages in thread
From: Florian Lohoff @ 2003-07-16 14:21 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: linux-mips

[-- Attachment #1: Type: text/plain, Size: 3795 bytes --]

On Wed, Jul 16, 2003 at 03:05:05PM +0200, Maciej W. Rozycki wrote:
>  Please pass it through ksymoops for more details.  Version 2.4.9 should
> 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
Cpu 0 Unable to handle kernel paging request at address 0000000000000000, epc == ffffffff88171104, ra == ffffffff880159f0
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
epc     : ffffffff88171104    Not tainted
Using defaults from ksymoops -t elf32-tradbigmips -a mips:3000
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


>>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
-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
                        Heisenberg may have been here.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: sudo oops on mips64 linux_2_4
  2003-07-16 14:21   ` Florian Lohoff
@ 2003-07-16 15:21     ` Maciej W. Rozycki
  2003-07-16 18:45       ` Ladislav Michl
  0 siblings, 1 reply; 10+ messages in thread
From: Maciej W. Rozycki @ 2003-07-16 15:21 UTC (permalink / raw)
  To: Florian Lohoff; +Cc: linux-mips

On Wed, 16 Jul 2003, Florian Lohoff wrote:

> >  Please pass it through ksymoops for more details.  Version 2.4.9 should
> > 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)

 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. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: sudo oops on mips64 linux_2_4
  2003-07-16 15:21     ` Maciej W. Rozycki
@ 2003-07-16 18:45       ` Ladislav Michl
  2003-07-16 19:01         ` Maciej W. Rozycki
  0 siblings, 1 reply; 10+ messages in thread
From: Ladislav Michl @ 2003-07-16 18:45 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: Florian Lohoff, linux-mips

On Wed, Jul 16, 2003 at 05:21:20PM +0200, Maciej W. Rozycki wrote:
> On Wed, 16 Jul 2003, Florian Lohoff wrote:
> 
> > >  Please pass it through ksymoops for more details.  Version 2.4.9 should
> > > 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)
> 
>  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() 

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
> some addresses decoded.

	ladis

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: sudo oops on mips64 linux_2_4
  2003-07-16 18:45       ` Ladislav Michl
@ 2003-07-16 19:01         ` Maciej W. Rozycki
  2003-07-16 19:05           ` Geert Uytterhoeven
  0 siblings, 1 reply; 10+ messages in thread
From: Maciej W. Rozycki @ 2003-07-16 19:01 UTC (permalink / raw)
  To: Ladislav Michl; +Cc: Florian Lohoff, linux-mips

On Wed, 16 Jul 2003, Ladislav Michl wrote:

> >  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?

 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.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: sudo oops on mips64 linux_2_4
  2003-07-16 19:01         ` Maciej W. Rozycki
@ 2003-07-16 19:05           ` Geert Uytterhoeven
  2003-07-16 19:54             ` Maciej W. Rozycki
  0 siblings, 1 reply; 10+ messages in thread
From: Geert Uytterhoeven @ 2003-07-16 19:05 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: Ladislav Michl, Florian Lohoff, Linux/MIPS Development

On Wed, 16 Jul 2003, Maciej W. Rozycki wrote:
> On Wed, 16 Jul 2003, Ladislav Michl wrote:
> > >  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?
> 
>  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.

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 -- geert@linux-m68k.org

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: sudo oops on mips64 linux_2_4
  2003-07-16 19:05           ` Geert Uytterhoeven
@ 2003-07-16 19:54             ` Maciej W. Rozycki
  2003-07-16 19:57               ` Geert Uytterhoeven
  0 siblings, 1 reply; 10+ messages in thread
From: Maciej W. Rozycki @ 2003-07-16 19:54 UTC (permalink / raw)
  To: Geert Uytterhoeven; +Cc: Ladislav Michl, Florian Lohoff, Linux/MIPS Development

On Wed, 16 Jul 2003, Geert Uytterhoeven wrote:

> >  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.
> 
> You do not want to set CONFIG_FB_VIRTUAL=y, since the virtual frame buffer
> device is meant for testing only.

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

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: sudo oops on mips64 linux_2_4
  2003-07-16 19:54             ` Maciej W. Rozycki
@ 2003-07-16 19:57               ` Geert Uytterhoeven
  0 siblings, 0 replies; 10+ messages in thread
From: Geert Uytterhoeven @ 2003-07-16 19:57 UTC (permalink / raw)
  To: Maciej W. Rozycki; +Cc: Ladislav Michl, Florian Lohoff, Linux/MIPS Development

On Wed, 16 Jul 2003, Maciej W. Rozycki wrote:
> On Wed, 16 Jul 2003, Geert Uytterhoeven wrote:
> > >  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.
> > 
> > You do not want to set CONFIG_FB_VIRTUAL=y, since the virtual frame buffer
> > device is meant for testing only.
> 
>  Sure -- and I should expect random crashes if I happen to enable it,
> right? 

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

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: sudo oops on mips64 linux_2_4
@ 2003-07-16 15:05 Chris Fouts
  0 siblings, 0 replies; 10+ messages in thread
From: Chris Fouts @ 2003-07-16 15:05 UTC (permalink / raw)
  To: 'Maciej W. Rozycki'; +Cc: linux-mips

I'm just getting started with MIPS in Linux so please bear with me.

What options do I use for the compiler to recoginze the C0 specific
op-codes, e.g., mfc0, mtc0, etc? I tried -mips1, -mips2, -mips3 and 
arch=RM7000 to no avail.

-chris

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2003-07-16 19:57 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-16 11:07 sudo oops on mips64 linux_2_4 Florian Lohoff
2003-07-16 13:05 ` Maciej W. Rozycki
2003-07-16 14:21   ` Florian Lohoff
2003-07-16 15:21     ` Maciej W. Rozycki
2003-07-16 18:45       ` Ladislav Michl
2003-07-16 19:01         ` Maciej W. Rozycki
2003-07-16 19:05           ` Geert Uytterhoeven
2003-07-16 19:54             ` Maciej W. Rozycki
2003-07-16 19:57               ` Geert Uytterhoeven
2003-07-16 15:05 Chris Fouts

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.