reiserfs problem of sorts..
I notice that one of my systems suddenly starts to "oops" when I use "find". It seems like a reiser problem, but how do I get rid of it? Should I do a reiserfsck --rebuild-tree or should I run some other tool? The volumes are using acl, xattr and usrquota. This is found in /var/log/messages: Apr 25 08:06:45 beata kernel: Unable to handle kernel NULL pointer dereference at 000000000000000b RIP: Apr 25 08:06:45 beata kernel: <ffffffff880ed239>{:reiserfs:sprintf_le_key+25} Apr 25 08:06:45 beata kernel: PGD e5d50067 PUD 7f308067 PMD 0 Apr 25 08:06:45 beata kernel: Oops: 0000 [1] SMP Apr 25 08:06:45 beata kernel: CPU 1 Apr 25 08:06:45 beata kernel: Modules linked in: iptable_filter ip_tables vmnet parport_pc vmmon nls_utf8 hfsplus vfat fat subfs freq_table edd nfsd exportfs button battery ac ipv6 ide_cd cdrom floppy tg3 shpchp pci_hotplug generic i2c_amd756 hw_random i2c_amd8111 i2c_core quota_v2 lp parport dm_mod reiserfs fan thermal processor aacraid sg megaraid_mbox megaraid_mm amd74xx sd_mod scsi_mod ide_disk ide_core Apr 25 08:06:45 beata kernel: Pid: 12198, comm: find Tainted: PF M U 2.6.13-15.8-smp Apr 25 08:06:45 beata kernel: RIP: 0010:[<ffffffff880ed239>] <ffffffff880ed239>{:reiserfs:sprintf_le_key+25} Apr 25 08:06:45 beata kernel: RSP: 0018:ffff810008c4fb58 EFLAGS: 00010206 Apr 25 08:06:45 beata kernel: RAX: 0000000000000028 RBX: 0000000000000001 RCX: 0000000000000000 Apr 25 08:06:45 beata kernel: RDX: ffff810008c4fc88 RSI: 0000000000000003 RDI: ffffffff8811cbc1 Apr 25 08:06:45 beata kernel: RBP: 0000000000000003 R08: ffffffff8811c799 R09: 00000000ffffffff Apr 25 08:06:45 beata kernel: R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff8811c780 Apr 25 08:06:45 beata kernel: R13: ffffffff8811cbc1 R14: ffffffff8811cb80 R15: ffff810008c4fc48 Apr 25 08:06:45 beata kernel: FS: 00002aaaaaeffe00(0000) GS:ffffffff8050f880(0000) knlGS:000000005587efe0 Apr 25 08:06:45 beata kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Apr 25 08:06:45 beata kernel: CR2: 000000000000000b CR3: 000000001bea3000 CR4: 00000000000006e0 Apr 25 08:06:45 beata kernel: Process find (pid: 12198, threadinfo ffff810008c4e000, task ffff81006f3418c0) Apr 25 08:06:45 beata kernel: Stack: ffffffff8811c7ac 0000000000000001 ffffffff8811c7ac ffffffff8811c780 Apr 25 08:06:45 beata kernel: 000000000000006b ffffffff880ed669 ffff810025406e60 ffffffff8023cd14 Apr 25 08:06:45 beata kernel: 0000003000000028 ffff8100e4141c38 Apr 25 08:06:45 beata kernel: Call Trace:<ffffffff880ed669>{:reiserfs:prepare_error_buf+153} Apr 25 08:06:45 beata kernel: <ffffffff8023cd14>{snprintf+68} <ffffffff8018dd11>{alloc_buffer_head+49} Apr 25 08:06:45 beata kernel: <ffffffff880edea0>{:reiserfs:reiserfs_warning+80} <ffffffff80167400>{read_cache_page+240} Apr 25 08:06:45 beata kernel: <ffffffff881001c9>{:reiserfs:reiserfs_xattr_get+553} Apr 25 08:06:45 beata kernel: <ffffffff88100e21>{:reiserfs:reiserfs_get_acl+241} <ffffffff880ff086>{:reiserfs:__reiserfs_permission+294} Apr 25 08:06:45 beata kernel: <ffffffff8019ad66>{permission+150} <ffffffff8019ae5d>{may_open+109} Apr 25 08:06:45 beata kernel: <ffffffff8019e68e>{open_namei+750} <ffffffff8018ba1d>{filp_open+45} Apr 25 08:06:45 beata kernel: <ffffffff8018acb3>{get_unused_fd+227} <ffffffff8018bb12>{sys_open+82} Apr 25 08:06:45 beata kernel: <ffffffff8010ed7e>{system_call+126} Apr 25 08:06:45 beata kernel: Apr 25 08:06:45 beata kernel: Code: 48 8b 76 08 ba 0f 00 00 00 48 89 f0 48 c1 e8 3c 89 c1 83 e1 Apr 25 08:06:45 beata kernel: RIP <ffffffff880ed239>{:reiserfs:sprintf_le_key+25} RSP <ffff810008c4fb58> Apr 25 08:06:45 beata kernel: CR2: 000000000000000b
On Tuesday 25 April 2006 02:26, Anders Norrbring wrote:
I notice that one of my systems suddenly starts to "oops" when I use "find". It seems like a reiser problem, but how do I get rid of it? Should I do a reiserfsck --rebuild-tree or should I run some other tool? The volumes are using acl, xattr and usrquota.
Hi Anders, Boot into rescue mode and make a backup/image of the errant filesystem, first. Umount the filesystem and run 'reiserfsck /dev/xxx' (same as running 'reiserfsck --check /dev/xxx') to perform a non-destructive examination. It will report back what corruptions it finds and whether or not it believes they can be fixed without rebuilding the tree. Note: If you invoke 'reiserfsck' without any parameters, a list of the options will be displayed. Good night & good luck! Carl
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-04-25 at 08:26 +0200, Anders Norrbring wrote:
I notice that one of my systems suddenly starts to "oops" when I use "find". It seems like a reiser problem, but how do I get rid of it? Should I do a reiserfsck --rebuild-tree or should I run some other tool? The volumes are using acl, xattr and usrquota.
You haven't mentioned what version you are using. It seems a bug to me that should be reported to SuSE. But try first "fsck" (it calls reiserfsck). If it is the root filesystem, do it from the rescue dvd. Don't do a --rebuild-tree unless it tells you to do so.
Apr 25 08:06:45 beata kernel: Pid: 12198, comm: find Tainted: PF M U 2.6.13-15.8-smp
Tainted... - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFETfd5tTMYHG2NR9URAnvfAJ9LWUpW5+HWuJ9J6mvRTr+RpI08FgCgjK8i w6yuQdkU26DnfiUx6HKWspA= =sQr7 -----END PGP SIGNATURE-----
Carlos E. R. skrev:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Tuesday 2006-04-25 at 08:26 +0200, Anders Norrbring wrote:
I notice that one of my systems suddenly starts to "oops" when I use "find". It seems like a reiser problem, but how do I get rid of it? Should I do a reiserfsck --rebuild-tree or should I run some other tool? The volumes are using acl, xattr and usrquota.
You haven't mentioned what version you are using. It seems a bug to me that should be reported to SuSE. But try first "fsck" (it calls reiserfsck). If it is the root filesystem, do it from the rescue dvd. Don't do a --rebuild-tree unless it tells you to do so.
Apr 25 08:06:45 beata kernel: Pid: 12198, comm: find Tainted: PF M U 2.6.13-15.8-smp
Tainted...
Yep, noticed that too... Directly from the SuSE 10.0 DVD.. Kinda weird, huh? Anders.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-04-25 at 12:21 +0200, Anders Norrbring wrote:
Apr 25 08:06:45 beata kernel: Pid: 12198, comm: find Tainted: PF M U 2.6.13-15.8-smp
Tainted...
Yep, noticed that too... Directly from the SuSE 10.0 DVD.. Kinda weird, huh?
You could learn, perhaps, why is tainted looking at the boot log or the messages log: at some point it loads some unsuported or not free module that "taints" the kernel, and it logs the fact. Kernel people will then not look at the problem (no source code). - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEThHvtTMYHG2NR9URAhgTAJ9IuOkUiQj3t+nwzHll85VKAj+QDgCfXdgb +h2c1obGc0VYAAlXSQHnxf8= =s1qz -----END PGP SIGNATURE-----
participants (4)
-
Anders Johansson
-
Anders Norrbring
-
Carl Hartung
-
Carlos E. R.