Re: test8-pre6 file corruption and oops

2000-09-08 Thread Keith Owens

On Fri, 08 Sep 2000 23:09:14 +0200, 
Kenneth Johansson <[EMAIL PROTECTED]> wrote:
>I have now put "-k /boot/System.map-$(uname -r)" as argument to klogd
>so it can't possibly choose the wrong file but is there some
>reason to turn off the lookup in klogd and use ksymoops ??

klogd only handles some architectures.  klogd only knows about some
messages for the architectures it does handle.  klogd does not verify
that it was passed the correct System.map.  klogd does not always know
about loaded modules.  Even when klogd knows about loaded modules, it
does not use the __insmod symbols to correctly map the modules.  I
could go on but you get the idea.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: test8-pre6 file corruption and oops

2000-09-08 Thread Kenneth Johansson

"Juan J. Quintela" wrote:

> > "kenneth" == Kenneth Johansson <[EMAIL PROTECTED]> writes:
>
> kenneth> Is there some way I can fix the old report I don't have a unprocessed 
>version of the oops as klogd "fixed" it automatically.
>
> I don't think so.  It is a good idea to run klogd with the -x option,
> to prevent him from doind the translation.

I checked into this some more and debian have a patched version that actually gets it 
right and it did not take the symbols from the
System.map link. It was easy to check as that mapfile don't even have the "__mon_yday" 
symbol so it must have got the symbols from
another file and unless it's seriously broken it should have picked the right one.

So it lookes like the call trace was wrong and not the map file.

I have now put "-k /boot/System.map-$(uname -r)" as argument to klogd so it can't 
possibly choose the wrong file but is there some
reason to turn off the lookup in klogd and use ksymoops ??







-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: test8-pre6 file corruption and oops

2000-09-08 Thread Juan J. Quintela

> "kenneth" == Kenneth Johansson <[EMAIL PROTECTED]> writes:


kenneth> Is there some way I can fix the old report I don't have a unprocessed version 
of the oops as klogd "fixed" it automatically.

I don't think so.  It is a good idea to run klogd with the -x option,
to prevent him from doind the translation.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: test8-pre6 file corruption and oops

2000-09-08 Thread Keith Owens

On Fri, 08 Sep 2000 10:33:35 +0200, 
Kenneth Johansson <[EMAIL PROTECTED]> wrote:
>Is there some way I can fix the old report I don't have a unprocessed
>version of the oops as klogd "fixed" it automatically.

The raw data has been lost.  Do you feel like grubbing through
whichever System.map klogd used and converting label+offset back to
hex ;)  If not then the oops is probably useless.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: test8-pre6 file corruption and oops

2000-09-08 Thread Kenneth Johansson

"Juan J. Quintela" wrote:

> > "kenneth" == Kenneth Johansson <[EMAIL PROTECTED]> writes:
>
> hi
>
> I only can guess that you are using a wrong System.map for
> doing the ksymoops.  __mon_yday is an array, not a function,
> the backtrace don't make sense.
>
> Later, Juan "waiting for a nice backtrace" :)))

You are right for some reason my last 5 upgrades have copied the correct 
System.map(with version numer in the name) into /boot but not updated the link. I have 
to investigate why this happens. I guess most tools use the right
version anyway otherwise I would have seen this error before.

Is there some way I can fix the old report I don't have a unprocessed version of the 
oops as klogd "fixed" it automatically.


Sorry for the bogus report.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: test8-pre6 file corruption and oops

2000-09-08 Thread Kenneth Johansson

"Juan J. Quintela" wrote:

  "kenneth" == Kenneth Johansson [EMAIL PROTECTED] writes:

 hi

 I only can guess that you are using a wrong System.map for
 doing the ksymoops.  __mon_yday is an array, not a function,
 the backtrace don't make sense.

 Later, Juan "waiting for a nice backtrace" :)))

You are right for some reason my last 5 upgrades have copied the correct 
System.map(with version numer in the name) into /boot but not updated the link. I have 
to investigate why this happens. I guess most tools use the right
version anyway otherwise I would have seen this error before.

Is there some way I can fix the old report I don't have a unprocessed version of the 
oops as klogd "fixed" it automatically.


Sorry for the bogus report.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: test8-pre6 file corruption and oops

2000-09-08 Thread Keith Owens

On Fri, 08 Sep 2000 10:33:35 +0200, 
Kenneth Johansson [EMAIL PROTECTED] wrote:
Is there some way I can fix the old report I don't have a unprocessed
version of the oops as klogd "fixed" it automatically.

The raw data has been lost.  Do you feel like grubbing through
whichever System.map klogd used and converting label+offset back to
hex ;)  If not then the oops is probably useless.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: test8-pre6 file corruption and oops

2000-09-08 Thread Juan J. Quintela

 "kenneth" == Kenneth Johansson [EMAIL PROTECTED] writes:


kenneth Is there some way I can fix the old report I don't have a unprocessed version 
of the oops as klogd "fixed" it automatically.

I don't think so.  It is a good idea to run klogd with the -x option,
to prevent him from doind the translation.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: test8-pre6 file corruption and oops

2000-09-08 Thread Keith Owens

On Fri, 08 Sep 2000 23:09:14 +0200, 
Kenneth Johansson [EMAIL PROTECTED] wrote:
I have now put "-k /boot/System.map-$(uname -r)" as argument to klogd
so it can't possibly choose the wrong file but is there some
reason to turn off the lookup in klogd and use ksymoops ??

klogd only handles some architectures.  klogd only knows about some
messages for the architectures it does handle.  klogd does not verify
that it was passed the correct System.map.  klogd does not always know
about loaded modules.  Even when klogd knows about loaded modules, it
does not use the __insmod symbols to correctly map the modules.  I
could go on but you get the idea.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: test8-pre6 file corruption and oops

2000-09-07 Thread Keith Owens

On 08 Sep 2000 01:40:55 +0200, 
"Juan J. Quintela" <[EMAIL PROTECTED]> wrote:
>> "kenneth" == Kenneth Johansson <[EMAIL PROTECTED]> writes:
>
>hi
>
>I only can guess that you are using a wrong System.map for
>doing the ksymoops.  __mon_yday is an array, not a function,
>the backtrace don't make sense.
>
>Later, Juan "waiting for a nice backtrace" :)))
>
>kenneth> Sep  7 17:39:50 ken1 kernel: Call Trace: [__mon_yday+6234/22368] 
>[__mon_yday+6978/22368] [blk_get_queue+50/64] [generic_make_request+257/272] 
>[ll_rw_block+337/448] [flush_dirty_buffers+130/180] [tvecs+15418/54628] 

That is caused by klogd assuming it knows where the System.map is and
blindly using the wrong one.  Sorry folks but klogd as distributed is
broken.  Either start klogd with "-x" or apply
ftp://ftp.ocs.com.au/pub/ksymoops/v2.3/patch-sysklogd-1-3-31-ksymoops-1.gz
and use ksymoops to get a real back trace.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: test8-pre6 file corruption and oops

2000-09-07 Thread Juan J. Quintela

> "kenneth" == Kenneth Johansson <[EMAIL PROTECTED]> writes:

hi

I only can guess that you are using a wrong System.map for
doing the ksymoops.  __mon_yday is an array, not a function,
the backtrace don't make sense.

Later, Juan "waiting for a nice backtrace" :)))

kenneth> Sep  7 17:39:50 ken1 kernel: invalid operand: 
kenneth> Sep  7 17:39:50 ken1 kernel: CPU:0
kenneth> Sep  7 17:39:50 ken1 kernel: EIP:0010:[__make_request+161/1444]
kenneth> Sep  7 17:39:50 ken1 kernel: EFLAGS: 00010286
kenneth> Sep  7 17:39:50 ken1 kernel: eax: 001f   ebx: c22ab380   ecx:    
edx: 
kenneth> Sep  7 17:39:50 ken1 kernel: esi: c22ab380   edi: c0268380   ebp: 0001   
esp: c1171f34
kenneth> Sep  7 17:39:50 ken1 kernel: ds: 0018   es: 0018   ss: 0018
kenneth> Sep  7 17:39:50 ken1 kernel: Process kupdate (pid: 4, stackpage=c1171000)
kenneth> Sep  7 17:39:50 ken1 kernel: Stack: c01e19da c01e1cc2 02c7 c22ab380 
0001 000c  0001 
kenneth> Sep  7 17:39:50 ken1 kernel:c0268398 c0268390  0002 
  c015f592 00fe 
kenneth> Sep  7 17:39:50 ken1 kernel:c0160151 c0268380 0001 c22ab380 
c22ab380  0001 c1171fd0 
kenneth> Sep  7 17:39:50 ken1 kernel: Call Trace: [__mon_yday+6234/22368] 
[__mon_yday+6978/22368] [blk_get_queue+50/64] [generic_make_request+257/272] 
[ll_rw_block+337/448] [flush_dirty_buffers+130/180] [tvecs+15418/54628] 
kenneth> Sep  7 17:39:50 ken1 kernel: Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7 4e 14 8b 
14 85 00 ca 25 c0 


That occurrences of __man_yday look quite bogus.
-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



test8-pre6 file corruption and oops

2000-09-07 Thread Kenneth Johansson

I get this on only one of my machines but it's probably not that stange
as they really don't have much in common other than being i386
compatible.

Could old errors on the filesystem produce this error?? I have only run
fsck under t8p6.

The last one is incomplete but the kernel had inserted part of another
file in the log so that was all I could get out.  I have not noticed
when this happens, If I find a pattern I post it later but It only
functions as a nfs server and NAT box(ppp/netfiler/squid/...) so I don't
think I could find much.




Sep  7 17:39:50 ken1 kernel: invalid operand: 
Sep  7 17:39:50 ken1 kernel: CPU:0
Sep  7 17:39:50 ken1 kernel: EIP:0010:[__make_request+161/1444]
Sep  7 17:39:50 ken1 kernel: EFLAGS: 00010286
Sep  7 17:39:50 ken1 kernel: eax: 001f   ebx: c22ab380   ecx:    edx: 

Sep  7 17:39:50 ken1 kernel: esi: c22ab380   edi: c0268380   ebp: 0001   esp: 
c1171f34
Sep  7 17:39:50 ken1 kernel: ds: 0018   es: 0018   ss: 0018
Sep  7 17:39:50 ken1 kernel: Process kupdate (pid: 4, stackpage=c1171000)
Sep  7 17:39:50 ken1 kernel: Stack: c01e19da c01e1cc2 02c7 c22ab380 0001 
000c  0001 
Sep  7 17:39:50 ken1 kernel:c0268398 c0268390  0002  
 c015f592 00fe 
Sep  7 17:39:50 ken1 kernel:c0160151 c0268380 0001 c22ab380 c22ab380 
 0001 c1171fd0 
Sep  7 17:39:50 ken1 kernel: Call Trace: [__mon_yday+6234/22368] 
[__mon_yday+6978/22368] [blk_get_queue+50/64] [generic_make_request+257/272] 
[ll_rw_block+337/448] [flush_dirty_buffers+130/180] [tvecs+15418/54628] 
Sep  7 17:39:50 ken1 kernel: Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7 4e 14 8b 14 85 00 
ca 25 c0 
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   0f 0b ud2a   
Code;  0002 Before first symbol
   2:   83 c4 0c  add$0xc,%esp
Code;  0005 Before first symbol
   5:   0f b6 46 15   movzbl 0x15(%esi),%eax
Code;  0009 Before first symbol
   9:   0f b7 4e 14   movzwl 0x14(%esi),%ecx
Code;  000d Before first symbol
   d:   8b 14 85 00 ca 25 c0  mov0xc025ca00(,%eax,4),%edx

Sep  7 22:19:47 ken1 kernel: invalid operand: 
Sep  7 22:19:47 ken1 kernel: CPU:0
Sep  7 22:19:47 ken1 kernel: EIP:0010:[__make_request+161/1444]
Sep  7 22:19:47 ken1 kernel: EFLAGS: 00010286
Sep  7 22:19:47 ken1 kernel: eax: 001f   ebx: c1b15b00   ecx:    edx: 

Sep  7 22:19:47 ken1 kernel: esi: c1b15b00   edi: c0268380   ebp: 0001   esp: 
c1171f34
Sep  7 22:19:47 ken1 kernel: ds: 0018   es: 0018   ss: 0018
Sep  7 22:19:47 ken1 kernel: Process kupdate (pid: 4, stackpage=c1171000)
Sep  7 22:19:47 ken1 kernel: Stack: c01e1e7a c01e2162 02c7 c1b15b00 0001 
000c  001e8480 
Sep  7 22:19:47 ken1 kernel:c0268398 c0268390  0002  
 c015f592 00fe 
Sep  7 22:19:47 ken1 kernel:c0160151 c0268380 0001 c1b15b00 c1b15b00 
 0001 c1171fd0 
Sep  7 22:19:47 ken1 kernel: Call Trace: [__mon_yday+6234/22368] 
[__mon_yday+6978/22368] [blk_get_queue+50/64] [generic_make_request+257/272] 
[ll_rw_block+337/448] [flush_dirty_buffers+130/180] [tvecs+15418/54628] 
Sep  7 22:19:47 ken1 kernel: Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7 4e 14 8b 14 85 00 
ca 25 c0 

Code;   Before first symbol
 <_EIP>:
Code;   Before first symbol
   0:   0f 0b ud2a   
Code;  0002 Before first symbol
   2:   83 c4 0c  add$0xc,%esp
Code;  0005 Before first symbol
   5:   0f b6 46 15   movzbl 0x15(%esi),%eax
Code;  0009 Before first symbol
   9:   0f b7 4e 14   movzwl 0x14(%esi),%ecx
Code;  000d Before first symbol
   d:   8b 14 85 00 ca 25 c0  mov0xc025ca00(,%eax,4),%edx

Sep  7 22:26:06 ken1 kernel: invalid operand: 
Sep  7 22:26:06 ken1 kernel: CPU:0
Sep  7 22:26:06 ken1 kernel: EIP:0010:[__make_request+161/1444]
Sep  7 22:26:06 ken1 kernel: EFLAGS: 00010282
Sep  7 22:26:06 ken1 kernel: eax: 001f   ebx: c21f49c0   ecx:    edx: 

Sep  7 22:26:06 ken1 kernel: esi: c21f49c0   edi: c0268380   ebp: 0001   esp: 
c1173f3c
Sep  7 22:26:06 ken1 kernel: ds: 0018   es: 0018   ss: 0018
Sep  7 22:26:06 ken1 kernel: Process kflushd (pid: 3, stackpage=c1173000)
Sep  7 22:26:06 ken1 kernel: Stack: c01e1e7a c01e2162 02c7 c21f49c0 0001 
[EMAIL PROTECTED]>
Status: RO

1 warning issued.  Results may not be reliable.



test8-pre6 file corruption and oops

2000-09-07 Thread Kenneth Johansson

I get this on only one of my machines but it's probably not that stange
as they really don't have much in common other than being i386
compatible.

Could old errors on the filesystem produce this error?? I have only run
fsck under t8p6.

The last one is incomplete but the kernel had inserted part of another
file in the log so that was all I could get out.  I have not noticed
when this happens, If I find a pattern I post it later but It only
functions as a nfs server and NAT box(ppp/netfiler/squid/...) so I don't
think I could find much.




Sep  7 17:39:50 ken1 kernel: invalid operand: 
Sep  7 17:39:50 ken1 kernel: CPU:0
Sep  7 17:39:50 ken1 kernel: EIP:0010:[__make_request+161/1444]
Sep  7 17:39:50 ken1 kernel: EFLAGS: 00010286
Sep  7 17:39:50 ken1 kernel: eax: 001f   ebx: c22ab380   ecx:    edx: 

Sep  7 17:39:50 ken1 kernel: esi: c22ab380   edi: c0268380   ebp: 0001   esp: 
c1171f34
Sep  7 17:39:50 ken1 kernel: ds: 0018   es: 0018   ss: 0018
Sep  7 17:39:50 ken1 kernel: Process kupdate (pid: 4, stackpage=c1171000)
Sep  7 17:39:50 ken1 kernel: Stack: c01e19da c01e1cc2 02c7 c22ab380 0001 
000c  0001 
Sep  7 17:39:50 ken1 kernel:c0268398 c0268390  0002  
 c015f592 00fe 
Sep  7 17:39:50 ken1 kernel:c0160151 c0268380 0001 c22ab380 c22ab380 
 0001 c1171fd0 
Sep  7 17:39:50 ken1 kernel: Call Trace: [__mon_yday+6234/22368] 
[__mon_yday+6978/22368] [blk_get_queue+50/64] [generic_make_request+257/272] 
[ll_rw_block+337/448] [flush_dirty_buffers+130/180] [tvecs+15418/54628] 
Sep  7 17:39:50 ken1 kernel: Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7 4e 14 8b 14 85 00 
ca 25 c0 
Using defaults from ksymoops -t elf32-i386 -a i386

Code;   Before first symbol
 _EIP:
Code;   Before first symbol
   0:   0f 0b ud2a   
Code;  0002 Before first symbol
   2:   83 c4 0c  add$0xc,%esp
Code;  0005 Before first symbol
   5:   0f b6 46 15   movzbl 0x15(%esi),%eax
Code;  0009 Before first symbol
   9:   0f b7 4e 14   movzwl 0x14(%esi),%ecx
Code;  000d Before first symbol
   d:   8b 14 85 00 ca 25 c0  mov0xc025ca00(,%eax,4),%edx

Sep  7 22:19:47 ken1 kernel: invalid operand: 
Sep  7 22:19:47 ken1 kernel: CPU:0
Sep  7 22:19:47 ken1 kernel: EIP:0010:[__make_request+161/1444]
Sep  7 22:19:47 ken1 kernel: EFLAGS: 00010286
Sep  7 22:19:47 ken1 kernel: eax: 001f   ebx: c1b15b00   ecx:    edx: 

Sep  7 22:19:47 ken1 kernel: esi: c1b15b00   edi: c0268380   ebp: 0001   esp: 
c1171f34
Sep  7 22:19:47 ken1 kernel: ds: 0018   es: 0018   ss: 0018
Sep  7 22:19:47 ken1 kernel: Process kupdate (pid: 4, stackpage=c1171000)
Sep  7 22:19:47 ken1 kernel: Stack: c01e1e7a c01e2162 02c7 c1b15b00 0001 
000c  001e8480 
Sep  7 22:19:47 ken1 kernel:c0268398 c0268390  0002  
 c015f592 00fe 
Sep  7 22:19:47 ken1 kernel:c0160151 c0268380 0001 c1b15b00 c1b15b00 
 0001 c1171fd0 
Sep  7 22:19:47 ken1 kernel: Call Trace: [__mon_yday+6234/22368] 
[__mon_yday+6978/22368] [blk_get_queue+50/64] [generic_make_request+257/272] 
[ll_rw_block+337/448] [flush_dirty_buffers+130/180] [tvecs+15418/54628] 
Sep  7 22:19:47 ken1 kernel: Code: 0f 0b 83 c4 0c 0f b6 46 15 0f b7 4e 14 8b 14 85 00 
ca 25 c0 

Code;   Before first symbol
 _EIP:
Code;   Before first symbol
   0:   0f 0b ud2a   
Code;  0002 Before first symbol
   2:   83 c4 0c  add$0xc,%esp
Code;  0005 Before first symbol
   5:   0f b6 46 15   movzbl 0x15(%esi),%eax
Code;  0009 Before first symbol
   9:   0f b7 4e 14   movzwl 0x14(%esi),%ecx
Code;  000d Before first symbol
   d:   8b 14 85 00 ca 25 c0  mov0xc025ca00(,%eax,4),%edx

Sep  7 22:26:06 ken1 kernel: invalid operand: 
Sep  7 22:26:06 ken1 kernel: CPU:0
Sep  7 22:26:06 ken1 kernel: EIP:0010:[__make_request+161/1444]
Sep  7 22:26:06 ken1 kernel: EFLAGS: 00010282
Sep  7 22:26:06 ken1 kernel: eax: 001f   ebx: c21f49c0   ecx:    edx: 

Sep  7 22:26:06 ken1 kernel: esi: c21f49c0   edi: c0268380   ebp: 0001   esp: 
c1173f3c
Sep  7 22:26:06 ken1 kernel: ds: 0018   es: 0018   ss: 0018
Sep  7 22:26:06 ken1 kernel: Process kflushd (pid: 3, stackpage=c1173000)
Sep  7 22:26:06 ken1 kernel: Stack: c01e1e7a c01e2162 02c7 c21f49c0 0001 
[EMAIL PROTECTED]
Status: RO

1 warning issued.  Results may not be reliable.



Re: test8-pre6 file corruption and oops

2000-09-07 Thread Keith Owens

On 08 Sep 2000 01:40:55 +0200, 
"Juan J. Quintela" [EMAIL PROTECTED] wrote:
 "kenneth" == Kenneth Johansson [EMAIL PROTECTED] writes:

hi

I only can guess that you are using a wrong System.map for
doing the ksymoops.  __mon_yday is an array, not a function,
the backtrace don't make sense.

Later, Juan "waiting for a nice backtrace" :)))

kenneth Sep  7 17:39:50 ken1 kernel: Call Trace: [__mon_yday+6234/22368] 
[__mon_yday+6978/22368] [blk_get_queue+50/64] [generic_make_request+257/272] 
[ll_rw_block+337/448] [flush_dirty_buffers+130/180] [tvecs+15418/54628] 

That is caused by klogd assuming it knows where the System.map is and
blindly using the wrong one.  Sorry folks but klogd as distributed is
broken.  Either start klogd with "-x" or apply
ftp://ftp.ocs.com.au/pub/ksymoops/v2.3/patch-sysklogd-1-3-31-ksymoops-1.gz
and use ksymoops to get a real back trace.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/