Skip to contentSkip to conversation

kernel BUG with 2.4.1-pre7 reiserfs

DISCUSSION Jakob Borg 3 participants 5 messages Jan 16, 2001

lore
Share & tools
lore

Jakob Borg

author
#0 lore raw

Hi,

I recently got this in my logs after moving /home to reiserfs. It is a plain 2.4.1-pre7 SMP system (.config attached).

Jan 16 19:15:02 narayan kernel: journal_begin called without kernel lock held
Jan 16 19:15:02 narayan kernel: kernel BUG at journal.c:423!
Jan 16 19:15:02 narayan kernel: CPU:   0

I seem to remember more possibly useful information scrolling by my screen, but it seems to not have made it to the logs, and I will shut down and fsck the filesystem now...

Regards,

Signature · 8 lines
Jakob Borg            mailto:[email protected]       (personal)
UNIX/network admin    mailto:[email protected]    (development)
systems programmer    mailto:[email protected]       (work)
                      http://jakob.borg.pp.se/
-
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/
#1 lore raw

In article <[email protected]>,

Quoted 5 lines · Jakob Borg

Hi,

I recently got this in my logs after moving /home to reiserfs. It is a plain 2.4.1-pre7 SMP system (.config attached).

Quoted 7 lines
Jan 16 19:15:02 narayan kernel: journal_begin called without kernel lock held
Jan 16 19:15:02 narayan kernel: kernel BUG at journal.c:423!
Jan 16 19:15:02 narayan kernel: CPU:   0

I seem to remember more possibly useful information scrolling by my screen, but it seems to not have made it to the logs, and I will shut down and fsck the filesystem now...

It really needs the stack-trace to debug this sanely (along with translations of what the hex numbers are - see the bugreporting documentation in the kernel source tree).

Linus
-
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/

author
#2 lore raw
In reply to Jakob Borg
Quoted 7 lines · Linus Torvalds
Quoted 3 lines

I seem to remember more possibly useful information scrolling by my screen, but it seems to not have made it to the logs, and I will shut down and fsck the filesystem now...

It really needs the stack-trace to debug this sanely (along with translations of what the hex numbers are - see the bugreporting documentation in the kernel source tree).

Got that in the other mail subjected "More information ... ". In the meantime it seems the filesystem is unhurt because of this, but reiserfsck says

uread_super_block: bad block is found at a new superblock location
uread_super_block: bad block is found at an old superblock location

which seems bogus. This is reiserfsck from the same suite that mkreiserfs came from ("reiserfsprogs 3.x") so they should be talking about the same sort of filesystem.

Regards,

Signature · 8 lines
Jakob Borg            mailto:[email protected]       (personal)
UNIX/network admin    mailto:[email protected]    (development)
systems programmer    mailto:[email protected]       (work)
                      http://jakob.borg.pp.se/
-
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/
#3 lore raw
Quoted 13 lines · On Tuesday, January 16, 2001 07:58:37 PM +0100 Jakob Borg <[email protected]>…
Quoted 7 lines · Linus Torvalds
Quoted 3 lines

I seem to remember more possibly useful information scrolling by my screen, but it seems to not have made it to the logs, and I will shut down and fsck the filesystem now...

It really needs the stack-trace to debug this sanely (along with translations of what the hex numbers are - see the bugreporting documentation in the kernel source tree).

Got that in the other mail subjected "More information ... ". In the meantime it seems the filesystem is unhurt because of this, but reiserfsck says

Quoted 7 lines

uread_super_block: bad block is found at a new superblock location
uread_super_block: bad block is found at an old superblock location

which seems bogus. This is reiserfsck from the same suite that mkreiserfs came from ("reiserfsprogs 3.x") so they should be talking about the same sort of filesystem.

The BUG you hit should not corrupt anything, that debugging code is actually there to prevent silent corruption due to lack of locking.

It is likely you are using an fsck version that can't read the 3.6.x format. They are still packaging the beta fsck tool for the new format, I'm not sure the exact download URL yet.

When you mount the FS it tells you which version it is, please include that info as well.

-chris

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

author
#4 lore raw
In reply to Jakob Borg
Quoted 2 lines · Chris Mason

When you mount the FS it tells you which version it is, please include that info as well.

I am rebooting with the patch from you (Chris) in about 30 seconds. This is the output from reiserfs when booting:

reiserfs: checking transaction log (device 16:41) ...
reiserfs: replayed 5 transactions in 4 seconds Using tea hash to sort names
reiserfs: using 3.5.x disk format
ReiserFS version 3.6.25

Signature · 8 lines
Jakob Borg            mailto:[email protected]       (personal)
UNIX/network admin    mailto:[email protected]    (development)
systems programmer    mailto:[email protected]       (work)
                      http://jakob.borg.pp.se/
-
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/