From: Patrick Smith <patsmith@pobox.com>
To: reiserfs-list@namesys.com
Subject: reiserfsck on PPC: checkmem fails
Date: Tue, 04 Feb 2003 00:44:43 -0500 [thread overview]
Message-ID: <3E3F534B.2050000@pobox.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]
I'm using ReiserFS on a PowerPC. The filesystem works fine in normal
use, but I'm having a bit of trouble with reiserfsck.
Versions: reiserfsprogs 3.6.4, Linux kernel 2.4.20.
In order to get reiserfsprogs to compile, I applied the attached patch.
When I run reiserfsprogs, it reports one or two problems, and then fails
in checkmem. For now, I'm ignoring the problems, as I don't know
whether they're caused by the same thing as checkmem or are real problems.
I've tracked down the cause of the checkmem failure to this bit of code
in reiserfs_fetch_ondisk_bitmap in bitmap.c:
last_byte_unused_bits = bm->bm_byte_size * 8 - bm->bm_bit_size;
for (i = 0; i < last_byte_unused_bits; i ++)
clear_bit (bm->bm_bit_size + i, bm->bm_map);
Thing is, the set_bit/clear_bit functions on PowerPC handle bits in
groups of 32, with the low-order bits getting the lower numbers. And,
when this code runs, bm->bm_byte_size is 506733, congruent to 1 modulo
4. So the last byte of data bits is aligned on a word (4 byte)
boundary, followed by the "mem_end" sentinel inserted by getmem:
Bmem _end
(where B is the last byte of data).
When the code above calls clear_bit to clear the last few bits, this
clears low-order bits in the Bmem word. But those are in the 'm' byte,
not the data byte. Oops!
Does anyone have any ideas as to whether there's an easy fix? And
whether there could be similar problems elsewhere? Any help would be
much appreciated.
Also, would there be any serious drawbacks to using 3.6.3 or 3.6.2
instead? And would they have the same problem?
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1139 bytes --]
--- ./include/misc.h.orig 2002-09-13 06:09:28.000000000 -0400
+++ ./include/misc.h 2002-12-24 22:31:08.000000000 -0500
@@ -49,7 +49,10 @@
int uuid_is_correct (unsigned char * uuid);
int set_uuid (const unsigned char * text, unsigned char * UUID);
+#include <asm/byteorder.h>
+#define __KERNEL__
#include <asm/bitops.h>
+#undef __KERNEL__
#if __BYTE_ORDER == __LITTLE_ENDIAN
int le_set_bit (int nr, void * addr);
int le_clear_bit (int nr, void * addr);
--- ./include/io.h.orig 2002-09-01 11:32:07.000000000 -0400
+++ ./include/io.h 2002-12-24 22:31:08.000000000 -0500
@@ -2,6 +2,7 @@
* Copyright 1996-2002 Hans Reiser
*/
+#include "misc.h"
struct buffer_head {
unsigned long b_blocknr;
--- ./include/swab.h.orig 2002-08-07 05:12:07.000000000 -0400
+++ ./include/swab.h 2002-12-24 22:32:09.000000000 -0500
@@ -4,5 +4,15 @@
#ifndef _REISERFS_SWAB_H_
#define _REISERFS_SWAB_H_
+#include <asm/byteorder.h>
+#define __KERNEL__
+#include <asm/bitops.h>
+#undef __KERNEL__
+
#include <linux/byteorder/swab.h>
+
+#define swab16 __swab16
+#define swab32 __swab32
+#define swab64 __swab64
+
#endif /* _REISERFS_SWAB_H_ */
next reply other threads:[~2003-02-04 5:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-04 5:44 Patrick Smith [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-02-05 6:17 reiserfsck on PPC: checkmem fails Patrick Smith
2003-02-06 3:58 Patrick Smith
2003-02-08 12:59 ` Vitaly Fertman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E3F534B.2050000@pobox.com \
--to=patsmith@pobox.com \
--cc=reiserfs-list@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.