2002-04-09 21:26:43

by Jurgen Philippaerts

[permalink] [raw]
Subject: arch/sparc64/kernel/traps.c


i recently wanted to check something in my `dmesg` output.
but i saw something i didn't expect :)

i do not know how long it's been there, since i don't check it that
often, but... do i need to worry about something ?

FWIW; this was 2.4.19-pre5 on a sunblade100


this is what i got:

data_access_exception: SFSR[0000000000801009] SFAR[fffffd0000000028],
going.
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
find(4631): Dax
TSTATE: 0000009911009601 TPC: 00000000005a39c0 TNPC: 00000000005a39c4
Y: 00000000 Not tainted
g0: 0000000000000000 g1: 0000000000000084 g2: 0000000000000001 g3:
fffff800002131c0
g4: fffff80000000000 g5: 0000000000000001 g6: fffff80001ec4000 g7:
0000000000000001
o0: 0000000000000001 o1: 00fcfd0000000028 o2: 0000000000008027 o3:
0000000000000009
o4: fffff8002075b78a o5: 0000000019999997 sp: fffff80001ec7211
ret_pc: 0000000000486cac
l0: 0000000000000027 l1: fffff800263f7740 l2: 00fcfd0000000000 l3:
fffff80027ed5f50
l4: 000000000001aa6c l5: 0000000000000000 l6: fffff80024ac6000 l7:
0000000000000000
i0: fffff80007782620 i1: fffff8002075b6e0 i2: 00000000005d5158 i3:
0000000000486bc0
i4: 000000007015f0ec i5: 000000007015f0ec i6: fffff80001ec72d1 i7:
00000000004730a8
Caller[00000000004730a8]
Caller[0000000000473a24]
Caller[0000000000473d2c]
Caller[0000000000474268]
Caller[00000000004703ec]
Caller[00000000004112f4]
Caller[00000000700fc9cc]
Instruction DUMP: 00000000 00000000 00000000 <ca024000> 8e014008
cfe25005 80a14007 1247fffc 8143e00a


Jurgen.


2002-04-09 21:30:31

by David Miller

[permalink] [raw]
Subject: Re: arch/sparc64/kernel/traps.c

From: Jurgen Philippaerts <[email protected]>
Date: Tue, 9 Apr 2002 23:20:00 +0200

TSTATE: 0000009911009601 TPC: 00000000005a39c0 TNPC: 00000000005a39c4
Y: 00000000 Not tainted

Please send this through ksymoops so that we get the kernel
symbols that match up to all these magic numbers in your OOPS.

2002-04-09 21:54:16

by Jurgen Philippaerts

[permalink] [raw]
Subject: Re: arch/sparc64/kernel/traps.c

On Tue, Apr 09, 2002 at 11:40:08PM +0200, David S. Miller wrote:
> From: Jurgen Philippaerts <[email protected]>
> Date: Tue, 9 Apr 2002 23:20:00 +0200
>
> TSTATE: 0000009911009601 TPC: 00000000005a39c0 TNPC: 00000000005a39c4
> Y: 00000000 Not tainted
>
> Please send this through ksymoops so that we get the kernel
> symbols that match up to all these magic numbers in your OOPS.

i would, if i could :)
so, i downloaded ksymoops-2.4.5 (i assume this is the version i need)

but it won't compile. sorry, my c knowledge is very basic.
but i assume there's something wrong with my /usr/lib/libbfd.a ?

gcc io.o ksyms.o ksymoops.o map.o misc.o object.o oops.o re.o
symbol.o -Dlinux -Wall -Wno-conversion -Waggregate-return
-Wstrict-prototypes -Wmissing-prototypes -DDEF_KSYMS=\"/proc/ksyms\"
-DDEF_LSMOD=\"/proc/modules\" -DDEF_OBJECTS=\"/lib/modules/*r/\"
-DDEF_MAP=\"/usr/src/linux/System.map\" -Wl,-Bstatic -lbfd -liberty
-Wl,-Bdynamic -o ksymoops
/usr/lib/libbfd.a(merge.o): In function `merge_strings':
merge.o(.text+0xc04): undefined reference to `htab_create'
merge.o(.text+0xc2c): undefined reference to `htab_create'
merge.o(.text+0xce4): undefined reference to
`htab_find_slot_with_hash'
merge.o(.text+0xd60): undefined reference to
`htab_find_slot_with_hash'
merge.o(.text+0xdd8): undefined reference to `htab_delete'
merge.o(.text+0xdec): undefined reference to `htab_delete'
collect2: ld returned 1 exit status
make: *** [ksymoops] Error 1


Jurgen.
--
http://www.tuxedo.org/~esr/faqs/smart-questions.html

Linux sparkie 2.4.19-pre5 #1 Thu Apr 4 19:14:41 CEST 2002 sparc64 unknown
11:40pm up 5 days, 3:53, 14 users, load average: 0.07, 0.07, 0.04

2002-04-09 23:04:59

by David Miller

[permalink] [raw]
Subject: Re: arch/sparc64/kernel/traps.c


ksymoops should be already installed on your system
at /usr/bin/ksymoops, if it isn't find the package
to install or complain to your distribution maintainer :-)

If you still want to compile ksymoops from source you need to update
and install a new binutils to get the latest BFD library.

2002-04-10 06:50:35

by Denis Vlasenko

[permalink] [raw]
Subject: Re: arch/sparc64/kernel/traps.c

On 9 April 2002 19:47, Jurgen Philippaerts wrote:
> On Tue, Apr 09, 2002 at 11:40:08PM +0200, David S. Miller wrote:
> > From: Jurgen Philippaerts <[email protected]>
> > Date: Tue, 9 Apr 2002 23:20:00 +0200
> >
> > TSTATE: 0000009911009601 TPC: 00000000005a39c0 TNPC: 00000000005a39c4
> > Y: 00000000 Not tainted
> >
> > Please send this through ksymoops so that we get the kernel
> > symbols that match up to all these magic numbers in your OOPS.
>
> i would, if i could :)
> so, i downloaded ksymoops-2.4.5 (i assume this is the version i need)
>
> but it won't compile. sorry, my c knowledge is very basic.
> but i assume there's something wrong with my /usr/lib/libbfd.a ?

Hi, I had similar problem, took me months to figure it out.
I suggest:
* getting latest binutils, compiling and installing them
* thorougly checking that *old* binutils aren't interfering
(in my case ksymoops got linked with old libbfd.a despite
newer one was also installed! 8-[ )
* compiling ksymoops

--
vda

2002-04-10 08:31:24

by Luigi Genoni

[permalink] [raw]
Subject: Re: arch/sparc64/kernel/traps.c

what version of binutils are you using?
please upgrade them (sources from ftp.kernel.org).


On Tue, 9 Apr 2002, Jurgen Philippaerts wrote:

> On Tue, Apr 09, 2002 at 11:40:08PM +0200, David S. Miller wrote:
> > From: Jurgen Philippaerts <[email protected]>
> > Date: Tue, 9 Apr 2002 23:20:00 +0200
> >
> > TSTATE: 0000009911009601 TPC: 00000000005a39c0 TNPC: 00000000005a39c4
> > Y: 00000000 Not tainted
> >
> > Please send this through ksymoops so that we get the kernel
> > symbols that match up to all these magic numbers in your OOPS.
>
> i would, if i could :)
> so, i downloaded ksymoops-2.4.5 (i assume this is the version i need)
>
> but it won't compile. sorry, my c knowledge is very basic.
> but i assume there's something wrong with my /usr/lib/libbfd.a ?
>
> gcc io.o ksyms.o ksymoops.o map.o misc.o object.o oops.o re.o
> symbol.o -Dlinux -Wall -Wno-conversion -Waggregate-return
> -Wstrict-prototypes -Wmissing-prototypes -DDEF_KSYMS=\"/proc/ksyms\"
> -DDEF_LSMOD=\"/proc/modules\" -DDEF_OBJECTS=\"/lib/modules/*r/\"
> -DDEF_MAP=\"/usr/src/linux/System.map\" -Wl,-Bstatic -lbfd -liberty
> -Wl,-Bdynamic -o ksymoops
> /usr/lib/libbfd.a(merge.o): In function `merge_strings':
> merge.o(.text+0xc04): undefined reference to `htab_create'
> merge.o(.text+0xc2c): undefined reference to `htab_create'
> merge.o(.text+0xce4): undefined reference to
> `htab_find_slot_with_hash'
> merge.o(.text+0xd60): undefined reference to
> `htab_find_slot_with_hash'
> merge.o(.text+0xdd8): undefined reference to `htab_delete'
> merge.o(.text+0xdec): undefined reference to `htab_delete'
> collect2: ld returned 1 exit status
> make: *** [ksymoops] Error 1
>
>
> Jurgen.
> --
> http://www.tuxedo.org/~esr/faqs/smart-questions.html
>
> Linux sparkie 2.4.19-pre5 #1 Thu Apr 4 19:14:41 CEST 2002 sparc64 unknown
> 11:40pm up 5 days, 3:53, 14 users, load average: 0.07, 0.07, 0.04
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

2002-04-10 10:27:27

by Keith Owens

[permalink] [raw]
Subject: Re: arch/sparc64/kernel/traps.c

On Tue, 9 Apr 2002 23:47:34 +0200,
Jurgen Philippaerts <[email protected]> wrote:
>gcc io.o ksyms.o ksymoops.o map.o misc.o object.o oops.o re.o
>symbol.o -Dlinux -Wall -Wno-conversion -Waggregate-return
>-Wstrict-prototypes -Wmissing-prototypes -DDEF_KSYMS=\"/proc/ksyms\"
>-DDEF_LSMOD=\"/proc/modules\" -DDEF_OBJECTS=\"/lib/modules/*r/\"
>-DDEF_MAP=\"/usr/src/linux/System.map\" -Wl,-Bstatic -lbfd -liberty
>-Wl,-Bdynamic -o ksymoops
>/usr/lib/libbfd.a(merge.o): In function `merge_strings':
>merge.o(.text+0xc04): undefined reference to `htab_create'
>merge.o(.text+0xc2c): undefined reference to `htab_create'

http://marc.theaimsgroup.com/?l=linux-kernel&m=101773461204829&w=2

2002-04-10 13:46:11

by Jurgen Philippaerts

[permalink] [raw]
Subject: Re: arch/sparc64/kernel/traps.c

On Wed, Apr 10, 2002 at 01:10:10AM +0200, David S. Miller wrote:
>
> ksymoops should be already installed on your system
> at /usr/bin/ksymoops, if it isn't find the package
> to install or complain to your distribution maintainer :-)
>
> If you still want to compile ksymoops from source you need to update
> and install a new binutils to get the latest BFD library.

allright, ksymoops doesn't come with my distribution (Splack)
so i got the source, and went from there.

now it compiled nicely.

here's the output that i get (i'm not quite sure what to expect, so i
hope this is what you need:)


# ksymoops -m /boot/System.map-2.4.19-pre5 -v
/usr/src/linux2419pre5/vmlinux < oops.txt
ksymoops 2.4.5 on sparc64 2.4.19-pre5. Options used
-v /usr/src/linux2419pre5/vmlinux (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.19-pre5/ (default)
-m /boot/System.map-2.4.19-pre5 (specified)

\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
TSTATE: 0000009911009601 TPC: 00000000005a39c0 TNPC: 00000000005a39c4
Y: 00000000 Not tainted
Using defaults from ksymoops -t elf32-sparc -a sparc
g0: 0000000000000000 g1: 0000000000000084 g2: 0000000000000001 g3:
fffff800002131c0
g4: fffff80000000000 g5: 0000000000000001 g6: fffff80001ec4000 g7:
0000000000000001
o0: 0000000000000001 o1: 00fcfd0000000028 o2: 0000000000008027 o3:
0000000000000009
o4: fffff8002075b78a o5: 0000000019999997 sp: fffff80001ec7211
ret_pc: 0000000000486cac
l0: 0000000000000027 l1: fffff800263f7740 l2: 00fcfd0000000000 l3:
fffff80027ed5f50
l4: 000000000001aa6c l5: 0000000000000000 l6: fffff80024ac6000 l7:
0000000000000000
i0: fffff80007782620 i1: fffff8002075b6e0 i2: 00000000005d5158 i3:
0000000000486bc0
i4: 000000007015f0ec i5: 000000007015f0ec i6: fffff80001ec72d1 i7:
00000000004730a8
Caller[00000000004730a8]
Caller[0000000000473a24]
Caller[0000000000473d2c]
Caller[0000000000474268]
Caller[00000000004703ec]
Caller[00000000004112f4]
Caller[00000000700fc9cc]
Instruction DUMP: 00000000 00000000 00000000 <ca024000> 8e014008
cfe25005 80a14007 1247fffc 8143e00a
Error (Oops_bfd_perror): set_section_contents Bad value


>>PC; 005a39c0 <__atomic_add+0/0> <=====

>>g3; fffff800002131c0 <END_OF_CODE+fffff7fffe1f0329/????>
>>g4; fffff80000000000 <END_OF_CODE+fffff7fffdfdd169/????>
>>g6; fffff80001ec4000 <END_OF_CODE+fffff7ffffea1169/????>
>>o1; fcfd0000000028 <END_OF_CODE+fcfcfffdfdd191/????>
>>o2; 00008027 Before first symbol
>>o4; fffff8002075b78a <END_OF_CODE+fffff8001e7388f3/????>
>>o5; 19999997 <END_OF_CODE+17976b00/????>
>>sp; fffff80001ec7211 <END_OF_CODE+fffff7ffffea437a/????>
>>ret_pc; 00486cac <proc_lookupfd+ec/1a0>
>>l1; fffff800263f7740 <END_OF_CODE+fffff800243d48a9/????>
>>l2; fcfd0000000000 <END_OF_CODE+fcfcfffdfdd169/????>
>>l3; fffff80027ed5f50 <END_OF_CODE+fffff80025eb30b9/????>
>>l4; 0001aa6c Before first symbol
>>l6; fffff80024ac6000 <END_OF_CODE+fffff80022aa3169/????>
>>i0; fffff80007782620 <END_OF_CODE+fffff8000575f789/????>
>>i1; fffff8002075b6e0 <END_OF_CODE+fffff8001e738849/????>
>>i2; 005d5158 <proc_fd_inode_operations+0/80>
>>i3; 00486bc0 <proc_lookupfd+0/1a0>
>>i4; 7015f0ec <END_OF_CODE+6e13c255/????>
>>i5; 7015f0ec <END_OF_CODE+6e13c255/????>
>>i6; fffff80001ec72d1 <END_OF_CODE+fffff7ffffea443a/????>
>>i7; 004730a8 <real_lookup+68/140>

Trace; 004730a8 <real_lookup+68/140>
Trace; 00473a24 <link_path_walk+764/a60>
Trace; 00473d2c <path_walk+c/20>
Trace; 00474268 <__user_walk+48/80>
Trace; 004703ec <sys_lstat64+c/80>
Trace; 004112f4 <linux_sparc_syscall32+34/40>
Trace; 700fc9cc <END_OF_CODE+6e0d9b35/????>


1 error issued. Results may not be reliable.

2002-04-11 05:51:18

by Denis Vlasenko

[permalink] [raw]
Subject: Re: arch/sparc64/kernel/traps.c

On 10 April 2002 11:39, Jurgen Philippaerts wrote:
> On Wed, Apr 10, 2002 at 01:10:10AM +0200, David S. Miller wrote:
> > ksymoops should be already installed on your system
> > at /usr/bin/ksymoops, if it isn't find the package
> > to install or complain to your distribution maintainer :-)
> >
> > If you still want to compile ksymoops from source you need to update
> > and install a new binutils to get the latest BFD library.
>
> allright, ksymoops doesn't come with my distribution (Splack)
> so i got the source, and went from there.
>
> now it compiled nicely.
>
> here's the output that i get (i'm not quite sure what to expect, so i
> hope this is what you need:)

[snip]

> Error (Oops_bfd_perror): set_section_contents Bad value

[snip]

I've seen the same when ksymoops was linked against old libbfd.
It builds without errors but could not disassemble oopsed code.
Check for old libbfd lying around.
--
vda

2002-04-11 10:42:22

by Jurgen Philippaerts

[permalink] [raw]
Subject: Re: arch/sparc64/kernel/traps.c

On Thu, Apr 11, 2002 at 08:00:08AM +0200, Denis Vlasenko wrote:

> > > ksymoops should be already installed on your system
> > > at /usr/bin/ksymoops, if it isn't find the package
> > > to install or complain to your distribution maintainer :-)
> > >
> > > If you still want to compile ksymoops from source you need to update
> > > and install a new binutils to get the latest BFD library.
> >
> > allright, ksymoops doesn't come with my distribution (Splack)
> > so i got the source, and went from there.
> >
> > now it compiled nicely.
> >
> > here's the output that i get (i'm not quite sure what to expect, so i
> > hope this is what you need:)
>
> [snip]
>
> > Error (Oops_bfd_perror): set_section_contents Bad value
>
> [snip]
>
> I've seen the same when ksymoops was linked against old libbfd.
> It builds without errors but could not disassemble oopsed code.
> Check for old libbfd lying around.

sorry for the long lines, but it would't be very readable otherwise
:)

$ locate libbfd | xargs ls -ld
-rwxr-xr-x 1 root root 632951 Apr 10 15:18 /usr/lib/libbfd-2.12.so
-rw-r--r-- 1 root root 737648 Apr 10 15:18 /usr/lib/libbfd.a
-rwxr-xr-x 1 root root 771 Apr 10 15:18 /usr/lib/libbfd.la
lrwxrwxrwx 1 root root 14 Apr 10 15:24 /usr/lib/libbfd.so -> libbfd-2.12.so

$ locate bfd.h | xargs ls -ld
-rw-r--r-- 1 root root 134077 Apr 10 15:18 /usr/include/bfd.h

it all looks like the new version to me


ps: it's the first time i actually use ksymoops, so excuse my
newbie-like behaviour :)

Jurgen.

2002-04-11 12:52:11

by Denis Vlasenko

[permalink] [raw]
Subject: Re: arch/sparc64/kernel/traps.c

On 11 April 2002 08:34, Jurgen Philippaerts wrote:
> > > here's the output that i get (i'm not quite sure what to expect, so i
> > > hope this is what you need:)
> >
> > [snip]
> >
> > > Error (Oops_bfd_perror): set_section_contents Bad value
> >
> > [snip]
> >
> > I've seen the same when ksymoops was linked against old libbfd.
> > It builds without errors but could not disassemble oopsed code.
> > Check for old libbfd lying around.
>
>sorry for the long lines, but it would't be very readable otherwise
>:)

>$ locate libbfd | xargs ls -ld
>-rwxr-xr-x 1 root root 632951 Apr 10 15:18 /usr/lib/libbfd-2.12.so
>-rw-r--r-- 1 root root 737648 Apr 10 15:18 /usr/lib/libbfd.a
>-rwxr-xr-x 1 root root 771 Apr 10 15:18 /usr/lib/libbfd.la
>lrwxrwxrwx 1 root root 14 Apr 10 15:24 /usr/lib/libbfd.so -> libbfd-2.12.so

>$ locate bfd.h | xargs ls -ld
>-rw-r--r-- 1 root root 134077 Apr 10 15:18 /usr/include/bfd.h

>it all looks like the new version to me

Double check that you built ksymoops against these libs, not older ones.
Even if you deleted them, you may still be using old ksymoops binary!
--
vda

2002-04-11 14:16:16

by Jurgen Philippaerts

[permalink] [raw]
Subject: Re: arch/sparc64/kernel/traps.c

On Thu, Apr 11, 2002 at 03:00:14PM +0200, Denis Vlasenko wrote:
>
> >it all looks like the new version to me
>
> Double check that you built ksymoops against these libs, not older ones.
> Even if you deleted them, you may still be using old ksymoops binary!

i don't have an old ksymoops binary :) it just did not want to
compile until i removed the old binutils, and installed the new
version.

just to be sure, i removed the source dir for ksymoops, unpacked it
again, recompiled, and ran it from thre. same result.


i think i'll just let it rest, and give it another go next time i get
an oops :) so far my box seems to be running as i expect it to run,
so i won't worry too much about it.
unless one of the developers really needs it :)

best regards,
Jurgen.