kernel panic with PAP-8252

kernel panic with PAP-8252

[K.Morikawa]

TurboLinux 6.5 Server (kernel-2.2.18 , reiserfs-3.5.29)

At July 13
I encountered kernel panic problem with PAP-8252, and our machine is HANG-UP.
PAP-8252 appear on console. but not logged to messages.
This problem was occurred during data backup job on reiserfs.
There are reiserfs filesystems on hardware RAID5 disks.(160GB x4DISKs)
I rebooted machine, then restart data backup job. but kernel panic re-occurred.
tried to delete the directories by "rm -rf", however can't delete with error.
I could delete the directories after deleting the files first.

After that the machine was operating without any problem.
I'm watching...


At July 27
kernel panic happened with same error.
I tried reiserfsck with --check option. however completed with no error.
so I did not run reiserfsck with --rebuild-tree option.
machine is operating after reboot.

This problem is very concern.
Please investigate and advice me.


/var/log/messages as follows... 
----------------------------------------------------------------------------------------------------
Jul 15 15:27:15 backup syslogd 1.4-0: restart.
Jul 15 15:27:15 backup kernel: klogd 1.4-0, log source = /proc/kmsg started.
Jul 15 15:27:15 backup kernel: Inspecting /boot/System.map-2.2.18-2
Jul 15 15:27:15 backup kernel: Loaded 8711 symbols from /boot/System.map-2.2.18-2.
Jul 15 15:27:15 backup kernel: Symbols match kernel version 2.2.18.
Jul 15 15:27:15 backup kernel: Loaded 32 symbols from 2 modules.
Jul 15 15:27:15 backup kernel: 15 is less than newest_mount_id 16
Jul 15 15:27:15 backup kernel: clm-2018: transaction is valid returning because mount_id 15 is less
than newest_mount_id 16
Jul 15 15:27:16 backup last message repeated 16 times
Jul 15 15:27:16 backup kernel: clm-2035: Starting replay from offset 4659, trans_id 8320
Jul 15 15:27:16 backup kernel: clm-2021: journal_read_transaction, offset 4659, len 9 mount_id 16
Jul 15 15:27:16 backup kernel: clm-2029: setting journal start to offset 4670
Jul 15 15:27:16 backup kernel: clm-2021: journal_read_transaction, offset 4670, len 4294967295 mount
_id 4294967295
Jul 15 15:27:16 backup kernel: clm-2023: journal_read_trans skipping because 4294967295 is != newest
_mount_id 16
Jul 15 15:27:16 backup kernel: clm-2038: Replayed 1 transactions in 3 seconds, mount_id now 17
Jul 15 15:27:16 backup kernel: Using r5 hash to sort names
Jul 15 15:27:16 backup kernel: ReiserFS version 3.5.29
Jul 15 15:27:16 backup kernel: clm-2030: reading through journal entries
Jul 15 15:27:16 backup kernel: clm-2031: found in header: first_unflushed_offset 1943, last_flushed_
trans_id 9208
Jul 15 15:27:16 backup kernel: clm-2020: found valid transaction start offset 1943, len 23 id 9209
Jul 15 15:27:16 backup kernel: clm-2020: found valid transaction start offset 35, len 57 id 9174
Jul 15 15:27:16 backup kernel: clm-2032: Setting oldest_start to offset 35, trans_id 9174
Jul 15 15:27:16 backup kernel: clm-2020: found valid transaction start offset 94, len 67 id 9175
Jul 15 15:27:16 backup kernel: clm-2020: found valid transaction start offset 163, len 33 id 9176
Jul 15 15:27:16 backup kernel: clm-2020: found valid transaction start offset 198, len 65 id 9177
Jul 15 15:27:16 backup kernel: clm-2020: found valid transaction start offset 265, len 65 id 9178
Jul 15 15:27:16 backup kernel: clm-2020: found valid transaction start offset 332, len 40 id 9179
Jul 15 15:27:16 backup kernel: clm-2020: found valid transaction start offset 374, len 30 id 9180
Jul 15 15:27:16 backup kernel: clm-2020: found valid transaction start offset 406, len 65 id 9181
Jul 15 15:27:16 backup kernel: clm-2020: found valid transaction start offset 473, len 55 id 9182
----------------------------------------------------------------------------------------------------
Jul 29 14:05:47 backup syslogd 1.4-0: restart.
Jul 29 14:05:47 backup kernel: klogd 1.4-0, log source = /proc/kmsg started.
Jul 29 14:05:48 backup kernel: Inspecting /boot/System.map-2.2.18-2
Jul 29 14:05:48 backup kernel: Loaded 8711 symbols from /boot/System.map-2.2.18-2.
Jul 29 14:05:48 backup kernel: Symbols match kernel version 2.2.18.
Jul 29 14:05:48 backup kernel: Loaded 32 symbols from 2 modules.
Jul 29 14:05:48 backup kernel: rning because mount_id 18 is less than newest_mount_id 20
Jul 29 14:05:48 backup kernel: clm-2018: transaction is valid returning because mount_id 18 is less
than newest_mount_id 20
Jul 29 14:05:48 backup last message repeated 32 times
Jul 29 14:05:48 backup kernel: clm-2035: Starting replay from offset 2061, trans_id 8598
Jul 29 14:05:48 backup kernel: clm-2021: journal_read_transaction, offset 2061, len 8 mount_id 20
Jul 29 14:05:48 backup kernel: clm-2029: setting journal start to offset 2071
Jul 29 14:05:48 backup kernel: clm-2021: journal_read_transaction, offset 2071, len 65536 mount_id 1
340
Jul 29 14:05:48 backup kernel: clm-2023: journal_read_trans skipping because 1340 is != newest_mount
_id 20
Jul 29 14:05:48 backup kernel: clm-2038: Replayed 1 transactions in 3 seconds, mount_id now 21
Jul 29 14:05:48 backup kernel: Using r5 hash to sort names
Jul 29 14:05:48 backup kernel: ReiserFS version 3.5.29
Jul 29 14:05:48 backup kernel: clm-2030: reading through journal entries
Jul 29 14:05:48 backup kernel: clm-2031: found in header: first_unflushed_offset 1996, last_flushed_
trans_id 9844
Jul 29 14:05:48 backup kernel: clm-2020: found valid transaction start offset 1996, len 65 id 9845
Jul 29 14:05:48 backup kernel: clm-2020: found valid transaction start offset 30, len 27 id 9808
Jul 29 14:05:48 backup kernel: clm-2032: Setting oldest_start to offset 30, trans_id 9808
Jul 29 14:05:49 backup kernel: clm-2020: found valid transaction start offset 59, len 66 id 9809
Jul 29 14:05:49 backup kernel: clm-2020: found valid transaction start offset 127, len 61 id 9810
Jul 29 14:05:49 backup kernel: clm-2020: found valid transaction start offset 190, len 63 id 9811
Jul 29 14:05:49 backup kernel: clm-2020: found valid transaction start offset 255, len 61 id 9812
Jul 29 14:05:49 backup kernel: clm-2020: found valid transaction start offset 318, len 28 id 9813
Jul 29 14:05:49 backup kernel: clm-2020: found valid transaction start offset 348, len 61 id 9814
Jul 29 14:05:49 backup kernel: clm-2020: found valid transaction start offset 411, len 51 id 9815
Jul 29 14:05:49 backup kernel: clm-2020: found valid transaction start offset 464, len 67 id 9816
----------------------------------------------------------------------------------------------------


Kohji Morikawa <k-morikawa@stage.gr.jp>
----------------------------------------------------------------------->

Re: kernel panic with PAP-8252

[Oleg Drokin]

Hello!

On Tue, Jul 30, 2002 at 03:11:33PM +0900, K. Morikawa wrote:

> TurboLinux 6.5 Server (kernel-2.2.18 , reiserfs-3.5.29)

You should consider upgrading if not whole kernel than at least the reiserfs
part to version 3.5.35.
Patch can be obtained from ouf ftp site ftp.namesys.com.

Bye,
    Oleg

Re: kernel panic with PAP-8252

[K.Morikawa]

Hello.
Thank you for your reply.

I understand that kernel-2.2.18 and reiserfs-3.5.29 is old.
Also reiserfs-3.5.35(latest) is fixed many bugs too.
However, it is unable to up the version immediately.
because cause of this problem is indistinct and
It's necessary the inspection of the middleware and application related.

Please investigate and advice me.
Regards

Kohji Morikawa <k-morikawa@stage.gr.jp>
----------------------------------------------------------------------->
On Tue, 30 Jul 2002 15:03:40 +0400
Oleg Drokin <green@namesys.com> wrote:

> Hello!
> 
> On Tue, Jul 30, 2002 at 03:11:33PM +0900, K. Morikawa wrote:
> 
> > TurboLinux 6.5 Server (kernel-2.2.18 , reiserfs-3.5.29)
> 
> You should consider upgrading if not whole kernel than at least the reiserfs
> part to version 3.5.35.
> Patch can be obtained from ouf ftp site ftp.namesys.com.
> 
> Bye,
>     Oleg

Re: kernel panic with PAP-8252

[Oleg Drokin]

Hello!

   There is no PAP-8252 assertion in our code (And there was no such
   assertion in 3.5.29 version either (just checked)).
   Can you please verify what assertion you are getting?

Bye,
    Oleg
On Tue, Jul 30, 2002 at 09:20:33PM +0900, K. Morikawa wrote:
> Hello.
> Thank you for your reply.
> 
> I understand that kernel-2.2.18 and reiserfs-3.5.29 is old.
> Also reiserfs-3.5.35(latest) is fixed many bugs too.
> However, it is unable to up the version immediately.
> because cause of this problem is indistinct and
> It's necessary the inspection of the middleware and application related.
> 
> Please investigate and advice me.
> Regards
> 
> Kohji Morikawa <k-morikawa@stage.gr.jp>
> ----------------------------------------------------------------------->
> On Tue, 30 Jul 2002 15:03:40 +0400
> Oleg Drokin <green@namesys.com> wrote:
> 
> > Hello!
> > 
> > On Tue, Jul 30, 2002 at 03:11:33PM +0900, K. Morikawa wrote:
> > 
> > > TurboLinux 6.5 Server (kernel-2.2.18 , reiserfs-3.5.29)
> > 
> > You should consider upgrading if not whole kernel than at least the reiserfs
> > part to version 3.5.35.
> > Patch can be obtained from ouf ftp site ftp.namesys.com.
> > 
> > Bye,
> >     Oleg
> 

Re: kernel panic with PAP-8252

[K.Morikawa]

Hello!!
Sorry, I was mistaking a code.
The correct code is as follows.

PAP-8285: get_neighbors : invalid rdkey<0> kernel panic:
REISERFS: panic (device 08:31): PAP-8285: get_neighbors

Please support.
Regards.

Kohji Morikawa <k-morikawa@stage.gr.jp>
----------------------------------------------------------------------->
On Tue, 30 Jul 2002 16:26:33 +0400
Oleg Drokin <green@namesys.com> wrote:

> Hello!
> 
>    There is no PAP-8252 assertion in our code (And there was no such
>    assertion in 3.5.29 version either (just checked)).
>    Can you please verify what assertion you are getting?
> 
> Bye,
>     Oleg
> On Tue, Jul 30, 2002 at 09:20:33PM +0900, K. Morikawa wrote:
> > Hello.
> > Thank you for your reply.
> > 
> > I understand that kernel-2.2.18 and reiserfs-3.5.29 is old.
> > Also reiserfs-3.5.35(latest) is fixed many bugs too.
> > However, it is unable to up the version immediately.
> > because cause of this problem is indistinct and
> > It's necessary the inspection of the middleware and application related.
> > 
> > Please investigate and advice me.
> > Regards
> > 
> > Kohji Morikawa <k-morikawa@stage.gr.jp>
> > ----------------------------------------------------------------------->
> > On Tue, 30 Jul 2002 15:03:40 +0400
> > Oleg Drokin <green@namesys.com> wrote:
> > 
> > > Hello!
> > > 
> > > On Tue, Jul 30, 2002 at 03:11:33PM +0900, K. Morikawa wrote:
> > > 
> > > > TurboLinux 6.5 Server (kernel-2.2.18 , reiserfs-3.5.29)
> > > 
> > > You should consider upgrading if not whole kernel than at least the reiserfs
> > > part to version 3.5.35.
> > > Patch can be obtained from ouf ftp site ftp.namesys.com.
> > > 
> > > Bye,
> > >     Oleg
> > 

森川 <k-morikawa@stage.gr.jp>
----------------------------------------------------------------------->

Re: kernel panic with PAP-8252

[Oleg Drokin]

Hello!

   This check is invalid and newer reiserfs patches are no longer checking
   this stuff, since it is unneeded. You should upgrade your kernel,
   or alternatively you can rebuild your kernel with CONFIG_REISERFS_CHECK
   config option turned off, it will disable these kind of checks, but other
   bugs won't go away, though.

Bye,
    Oleg   
On Tue, Jul 30, 2002 at 09:52:40PM +0900, K. Morikawa wrote:
> Hello!!
> Sorry, I was mistaking a code.
> The correct code is as follows.
> 
> PAP-8285: get_neighbors : invalid rdkey<0> kernel panic:
> REISERFS: panic (device 08:31): PAP-8285: get_neighbors
> 
> Please support.
> Regards.
> 
> Kohji Morikawa <k-morikawa@stage.gr.jp>
> ----------------------------------------------------------------------->
> On Tue, 30 Jul 2002 16:26:33 +0400
> Oleg Drokin <green@namesys.com> wrote:
> 
> > Hello!
> > 
> >    There is no PAP-8252 assertion in our code (And there was no such
> >    assertion in 3.5.29 version either (just checked)).
> >    Can you please verify what assertion you are getting?
> > 
> > Bye,
> >     Oleg
> > On Tue, Jul 30, 2002 at 09:20:33PM +0900, K. Morikawa wrote:
> > > Hello.
> > > Thank you for your reply.
> > > 
> > > I understand that kernel-2.2.18 and reiserfs-3.5.29 is old.
> > > Also reiserfs-3.5.35(latest) is fixed many bugs too.
> > > However, it is unable to up the version immediately.
> > > because cause of this problem is indistinct and
> > > It's necessary the inspection of the middleware and application related.
> > > 
> > > Please investigate and advice me.
> > > Regards
> > > 
> > > Kohji Morikawa <k-morikawa@stage.gr.jp>
> > > ----------------------------------------------------------------------->
> > > On Tue, 30 Jul 2002 15:03:40 +0400
> > > Oleg Drokin <green@namesys.com> wrote:
> > > 
> > > > Hello!
> > > > 
> > > > On Tue, Jul 30, 2002 at 03:11:33PM +0900, K. Morikawa wrote:
> > > > 
> > > > > TurboLinux 6.5 Server (kernel-2.2.18 , reiserfs-3.5.29)
> > > > 
> > > > You should consider upgrading if not whole kernel than at least the reiserfs
> > > > part to version 3.5.35.
> > > > Patch can be obtained from ouf ftp site ftp.namesys.com.
> > > > 
> > > > Bye,
> > > >     Oleg
> > > 
> 
> ?$B?9@n <k-morikawa@stage.gr.jp>
> ----------------------------------------------------------------------->
> 

Re: kernel panic with PAP-8252

[Kuba Ober]

On wtorek 30 lipiec 2002 08:20 am, K.Morikawa wrote:
> Hello.
> Thank you for your reply.
>
> I understand that kernel-2.2.18 and reiserfs-3.5.29 is old.
> Also reiserfs-3.5.35(latest) is fixed many bugs too.
> However, it is unable to up the version immediately.
> because cause of this problem is indistinct and
> It's necessary the inspection of the middleware and application related.

By definition, user-level, unprivileged application errors shouldn't crash the 
kernel. So you should really forget about your application stuff and update 
the kernel to the latest 2.2, as well as latest reiserfs for 2.2. Or else 
you're asking for trouble.

Again: application stuff should not crash the kernel if the kernel is fine. So 
even if your apps were completely broken, the kernel should be running fine. 
If you're getting kernel crashes, it's the kernel at fault. *Do* update ASAP. 
*Really*. You know, updating the kernel is not such a big job after all.

Cheers, Kuba Ober

Re: kernel panic with PAP-8252

[Kuba Ober]

> I tried reiserfsck with --check option. however completed with no error.
> so I did not run reiserfsck with --rebuild-tree option.
> machine is operating after reboot.

Another note: please make sure that you use latest reiserfs-tools (version 
3.6.2). You really should not be using anything older than this version, 
especially the 3.x. versions.

Make sure you verify that, since it seems your system hasn't been updated in a 
long time, so I'm nearly sure that you *are* using outdated reiserfstools.

Cheers, Kuba Ober