documented Oops running big-endian reiserfs on parisc architecture
Well, I watched the number of files in /lost+found grow every time I had to pull the plug from my HP C200, so I added a 'sync' option in /etc/fstab and tried to get reiserfs working.
I patched my 2.4.9-pa13 kernel with
endian-safe-reiserfs-for-2.4.8.patch
which went without warnings or errors. A patched reiserfs-progs-3.x.0k-pre9 also built well (despite what the configure scripts says, you _need_ automake).
Creating a reiserfs-partition went without a hitch.
running bonnie -s 128 on it did this:
Adding Swap: 1041400k swap-space (priority -1)
eth0: Setting half-duplex based on MII#1 link partner capability of 0021.
reiserfs: checking transaction log (device 08:03) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
bonnie[163]: Unaligned data reference 28
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001110
r0-3 00000000 102ec550 10197d0c 26f24838 r4-7 26f24848 27054e40 00000011 00000020 r8-11 0000000a 26f06580 00000020 26f247a0 r12-15 27088d1c ffffffff 26f24838 00000001 r16-19 26f24708 faf02c68 0006a248 26f24852 r20-23 0000000f 00000003 03000000 00000002 r24-27 0000000a 0000000a 26f24848 102d4010 r28-31 26f24848 01000000 26f24b40 10196fc8 sr0-3 00000000 00000004 00000000 00000004 sr4-7 00000000 00000000 00000000 00000000
IASQ: 00000000 00000000 IAOQ: 10197d10 10197d14
IIR: 0c7c1093 ISR: 00000000 IOR: 26f24846
ORIG_R28: 00000000
pa8200:/var/log#
After reading in the archives about ksymoops, I looked up this part of my System.map:
101979e0 T reiserfs_lookup101979e0 t .L143210197ad4 t reiserfs_add_entry10197e50 t .L151210197f28 t .L1510
10198068 T reiserfs_create
objdump -d /boot/linux-2.4.9-pa13 revealed:
10197cbc: d6 d6 0b 18 depw,z r22,7,8,r22 10197cc0: d6 b5 0a 10 depw,z r21,15,16,r21 10197cc4: 41 33 01 fe ldb ff(sr0,r9),r19 10197cc8: 0a d5 02 75 or r21,r22,r21 10197ccc: d6 94 09 08 depw,z r20,23,24,r20 10197cd0: 0a b4 02 74 or r20,r21,r20 10197cd4: 0a 93 02 73 or r19,r20,r19 10197cd8: d2 75 18 f8 extrw,u r19,7,8,r21 10197cdc: d2 74 19 f8 extrw,u r19,15,8,r20 10197ce0: 0c 73 12 16 stb r19,b(sr0,r3) 10197ce4: d2 73 1a f8 extrw,u r19,23,8,r19 10197ce8: 0c 75 12 10 stb r21,8(sr0,r3) 10197cec: 0c 74 12 12 stb r20,9(sr0,r3) 10197cf0: e8 86 a9 e4 b,l 102a51e8 <memcpy>,%r2 10197cf4: 0c 73 12 14 stb r19,a(sr0,r3) 10197cf8: 08 06 02 59 copy r6,r25 10197cfc: 08 04 02 5a copy r4,r26 10197d00: d7 20 1c 1d depwi 0,31,3,r25 10197d04: e8 0d a5 d8 call 101b1ff8 <padd_item> 10197d08: 08 08 02 58 copy r8,r24 10197d0c: 00 01 0e 74 rsm 1,r20 10197d10: 0c 7c 10 93 ldw e(sr0,r3),r19 10197d14: d6 60 1f 1f depwi 0,7,1,r19 10197d18: 0c 73 12 9c stw r19,e(sr0,r3) 10197d1c: 00 14 18 60 mtsm r20 10197d20: 85 e0 26 32 cmpib,=,n 0,r15,10198040 <.L1510+0x118> 10197d24: 00 01 0e 74 rsm 1,r20 10197d28: 0c 7c 10 93 ldw e(sr0,r3),r19 10197d2c: d6 7f 1f 5f depwi -1,5,1,r19 10197d30: 0c 73 12 9c stw r19,e(sr0,r3) 10197d34: 00 14 18 60 mtsm r20 10197d38: 08 00 02 54 copy r0,r20 10197d3c: 08 00 02 55 copy r0,r21 10197d40: 37 c6 3e 51 ldo -d8(sp),r6 10197d44: 37 cd 3d c1 ldo -120(sp),r13 10197d48: 6b d4 3e 51 stw r20,-d8(sr0,sp) 10197d4c: 6b d5 3e 59 stw r21,-d4(sr0,sp) 10197d50: 6b d4 3e 61 stw r20,-d0(sr0,sp) 10197d54: 6b d5 3e 69 stw r21,-cc(sr0,sp) 10197d58: 08 0c 02 59 copy r12,r25 10197d5c: 6b c6 3e 01 stw r6,-100(sr0,sp) 10197d60: 6b cd 3f 99 stw r13,-34(sr0,sp) 10197d64: 08 08 02 58 copy r8,r24 10197d68: 08 05 02 5a copy r5,r26 10197d6c: eb ff b4 4d b,l 10197798 <reiserfs_find_entry>,%r2
which makes the error somewhere around here in fs/reiserfs/namei.c, function reiserfs_add_entry, after call to padd_item, before call to reiserfs_find_entry:
/* copy name */
memcpy ((char *)(deh + 1), name, namelen);
/* padd by 0s to the 4 byte boundary */
padd_item ((char *)(deh + 1), ROUND_UP (namelen), namelen);
/* entry is ready to be pasted into tree, set 'visibility' and 'stat data in entry' attributes */
mark_de_without_sd (deh);
visible ? mark_de_visible (deh) : mark_de_hidden (deh);
/* find the proper place for the new entry */
memset (bit_string, 0, sizeof (bit_string));
de.de_gen_number_bit_string = (char *)bit_string;
retval = reiserfs_find_entry (dir, name, namelen, &path, &de);And there I'm stuck. I'm sending this to the parisc-list to document the failure, and to linux-kernel to reach some reiserfs-experts, perhaps.
I'm willing to test anything!
Good luck,
Jurriaan
Signature · 4 lines
"I have seen her. That is enough, perhaps." Pug smiled. "You are a rare man." Raymond E Feist - The King's Buccaneer GNU/Linux 2.4.9-ac5 SMP/ReiserFS 2x1402 bogomips load av: 0.04 0.01 0.06
Quoted 2 lines · On Sun, Sep 02, 2001 at 10:55:38AM +0200, [email protected] wrote:
ReiserFS version 3.6.25
bonnie[163]: Unaligned data reference 28
As it says, an unaligned data reference.
Quoted 3 lines
r0-3 00000000
102ec55010197d0c26f24838IASQ: 00000000 00000000 IAOQ:
10197d1010197d14
In kernel mode.
Quoted 1 line
10197d10: 0c 7c 10 93 ldw e(sr0,r3),r19
r3 is 26f24838, and offset `e' from that is unaligned.
Quoted 4 lines
which makes the error somewhere around here in
fs/reiserfs/namei.c, functionreiserfs_add_entry, after call topadd_item, before call toreiserfs_find_entry:
Quoted 13 lines
/* copy name */
memcpy ((char *)(deh + 1), name, namelen);
/* padd by 0s to the 4 byte boundary */
padd_item ((char *)(deh + 1), ROUND_UP (namelen), namelen);
/* entry is ready to be pasted into tree, set 'visibility' and 'stat data in entry' attributes */
mark_de_without_sd (deh);
visible ? mark_de_visible (deh) : mark_de_hidden (deh);
/* find the proper place for the new entry */
memset (bit_string, 0, sizeof (bit_string));
de.de_gen_number_bit_string = (char *)bit_string;
retval = reiserfs_find_entry (dir, name, namelen, &path, &de);I suspect mark_de_without_sd is an inlined function/macro and this will be where the unaligned data reference is happening.
Signature · 1 line
Revolutions do not require corporate support.
From: Matthew Wilcox <[email protected]>
Date: Sun, 2 Sep 2001 15:00:23 +0100
Quoted 2 lines · On Sun, Sep 02, 2001 at 10:55:38AM +0200, [email protected] wrote:
ReiserFS version 3.6.25
bonnie[163]: Unaligned data reference 28
As it says, an unaligned data reference.
BTW, you should not be OOPSing on this as unaligned references are defined as completely normal, especially in the networking.
Is it impossible to handle unaligned access traps properly on parisc? If so, well you have some problems...
Later,
David S. Miller
[email protected]
PATCH 1/1 : documented Oops running big-endian reiserfs on parisc architecture
In reply to [email protected]Quoted 14 lines · Matthew Wilcox
Quoted 13 lines · On Sun, Sep 02, 2001 at 10:55:38AM +0200, [email protected] wrote:
ReiserFS version 3.6.25
bonnie[163]: Unaligned data reference 28which makes the error somewhere around here in
fs/reiserfs/namei.c, functionreiserfs_add_entry, after call topadd_item, before call toreiserfs_find_entry:padd_item ((char *)(deh + 1), ROUND_UP (namelen), namelen); /* entry is ready to be pasted into tree, set 'visibility' and 'stat data in entry' attributes */ mark_de_without_sd (deh); visible ? mark_de_visible (deh) : mark_de_hidden (deh);
Quoted 8 lines
Quoted 4 lines
/* find the proper place for the new entry */ memset (bit_string, 0, sizeof (bit_string)); de.de_gen_number_bit_string = (char *)bit_string; retval = reiserfs_find_entry (dir, name, namelen, &path, &de);I suspect
mark_de_without_sdis an inlined function/macro and this will be where the unaligned data reference is happening.
Correct. And the comments just above there about alignment are very enlightening; it seems that the IBM/S390 architecture has some special needs, and I just tested that my PA-RISC kernel has the same needs. Thus I am able to present a real bugfix.
This patch allows me to run bonnie on a reiserfs partition with pa-risc linux.
include/linux/reiserfs_fs.h Sun Sep 2 20:47:27 2001 renamed from include/linux/reiserfs_fs.h Sun Sep 2 21:54:25 2001 +1 -1
@@ -924,7 +924,7 @@ #define DEH_Visible 2 /* 64 bit systems (and the S/390) need to be aligned explicitly -jdm */ -#if BITS_PER_LONG == 64 || defined(__s390__) +#if BITS_PER_LONG == 64 || defined(__s390__) || defined(__hppa__) # define ADDR_UNALIGNED_BITS (3) #endif
This applies to linux-2.4.9-pa13 with endian-safe-reiserfs-for-2.4.8.patch and to 2.4.9-ac5.
Please apply,
Jurriaan
Signature · 4 lines
It is well to remember, my son, that the entire population of the
universe, with one trifling exception, is composed of others.
John Andrew Holmes
GNU/Linux 2.4.9-ac5 SMP/ReiserFS 2x1402 bogomips load av: 0.98 0.83 0.37Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture
In reply to [email protected]include/linux/reiserfs_fs.h Sun Sep 2 20:47:27 2001 line 929
Quoted 11 lines · On Sun, Sep 02, 2001 at 07:57:17PM +0200, [email protected] wrote:
include/linux/reiserfs_fs.h Sun Sep 2 20:47:27 2001 renamed from include/linux/reiserfs_fs.h Sun Sep 2 21:54:25 2001 +1
-1@@ -924,7 +924,7 @@ #define DEH_Visible 2 /* 64 bit systems (and the S/390) need to be aligned explicitly -jdm */ -#if BITS_PER_LONG == 64 || defined(__s390__) +#if BITS_PER_LONG == 64 || defined(__s390__) || defined(__hppa__) # define ADDR_UNALIGNED_BITS (3) #endif
couldn't reiserfs use asm/unaligned.h like anyone else? Seems at least sparc and mips may need the same treatment.
Bye
Richard
Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture
From: Richard Zidlicky <[email protected]>
Date: Mon, 3 Sep 2001 00:34:37 +0200
Review
Quoted 5 lines · On Sun, Sep 02, 2001 at 07:57:17PM +0200, [email protected] wrote:
/* 64 bit systems (and the S/390) need to be aligned explicitly -jdm */
(quoted diff) +1
-1-#if BITS_PER_LONG == 64 || defined(__s390__) +#if BITS_PER_LONG == 64 || defined(__s390__) || defined(__hppa__) # define ADDR_UNALIGNED_BITS (3) #endif
couldn't reiserfs use asm/unaligned.h like anyone else? Seems at least sparc and mips may need the same treatment.
Sparc will act correctly for unaliagned accesses.
It will trap and run very slowly, but it wont' OOPS and it will give correct results.
This is actually required behavior, I don't know why parisc is acting differently.
Later,
David S. Miller
[email protected]
Re: [parisc-linux] Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs
Quoted 5 lines
It will trap and run very slowly, but it wont' OOPS and it will give correct results.
This is actually required behavior, I don't know why parisc is acting differently.
Several of the platforms only have trap fixups for a small subset of operations that can legitimately occur on things like networking headers. It makes the recovery code a lot smaller and cleaner.
Alan
Quoted 7 lines · David S. Miller
From: Matthew Wilcox <[email protected]>
Date: Sun, 2 Sep 2001 15:00:23 +0100Quoted 2 lines · On Sun, Sep 02, 2001 at 10:55:38AM +0200, [email protected] wrote:
ReiserFS version 3.6.25
bonnie[163]: Unaligned data reference 28
Quoted 7 lines
As it says, an unaligned data reference.
BTW, you should not be OOPSing on this as unaligned references are defined as completely normal, especially in the networking.
Is it impossible to handle unaligned access traps properly on parisc? If so, well you have some problems...
No, we just haven't bothered to implement it yet. Not many people use IPX these days.
Signature · 1 line
Revolutions do not require corporate support.
From: Matthew Wilcox <[email protected]>
Date: Mon, 3 Sep 2001 00:25:14 +0100
No, we just haven't bothered to implement it yet. Not many people use IPX these days.
IPX is not the only way this can happen. Normal IPv4 can get it with some ethernet cards on receive.
Later,
David S. Miller
[email protected]
Quoted 5 lines
Quoted 2 lines
Is it impossible to handle unaligned access traps properly on parisc? If so, well you have some problems...
No, we just haven't bothered to implement it yet. Not many people use IPX these days.
You also need unaligned trap fixups for
AX.25, NetROM, LAPB, X.25, Appletalk, PPP, Anything over 802.2LLC, Linus NFS code for some NFS mount options (although not the -ac NFS code)
Alan
Quoted 5 lines
Quoted 2 lines
Is it impossible to handle unaligned access traps properly on parisc? If so, well you have some problems...
No, we just haven't bothered to implement it yet. Not many people use IPX these days.
It should be easy to handle kernel unalignment traps in parisc/kernel/unaligned.c like we currently do for userspace (in fact there already is some code to do this). I thought we didn't want to do this though?
randolph
Signature · 4 lines
@..@ http://www.TauSq.org/ (----) ( >__< ) ^^ ~~ ^^
Well, I should have read the next email before saying these patches seemed to be stable.
Jeff?
Hans
Quoted 135 lines · [email protected] wrote:
Well, I watched the number of files in /lost+found grow every time I had to pull the plug from my HP C200, so I added a 'sync' option in
/etc/fstaband tried to get reiserfs working.I patched my 2.4.9-pa13 kernel with
endian-safe-reiserfs-for-2.4.8.patch
which went without warnings or errors. A patched reiserfs-progs-3.x.0k-pre9 also built well (despite what the configure scripts says, you _need_ automake).
Creating a reiserfs-partition went without a hitch.
running bonnie -s 128 on it did this:
Adding Swap: 1041400k swap-space (priority -1)
eth0: Setting half-duplex based on MII#1 link partner capability of 0021.
reiserfs: checking transaction log (device 08:03) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
bonnie[163]: Unaligned data reference 28YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001110r0-3 00000000 102ec550 10197d0c 26f24838 r4-7 26f24848 27054e40 00000011 00000020 r8-11 0000000a 26f06580 00000020 26f247a0 r12-15 27088d1c ffffffff 26f24838 00000001 r16-19 26f24708 faf02c68 0006a248 26f24852 r20-23 0000000f 00000003 03000000 00000002 r24-27 0000000a 0000000a 26f24848 102d4010 r28-31 26f24848 01000000 26f24b40 10196fc8 sr0-3 00000000 00000004 00000000 00000004 sr4-7 00000000 00000000 00000000 00000000IASQ: 00000000 00000000 IAOQ:
10197d1010197d14
IIR:0c7c1093ISR: 00000000 IOR:26f24846
ORIG_R28: 00000000
pa8200:/var/log#After reading in the archives about ksymoops, I looked up this part of my System.map:
101979e0Treiserfs_lookup101979e0t .L143210197ad4treiserfs_add_entry10197e50t .L151210197f28t .L1510
10198068 Treiserfs_createobjdump -d
/boot/linux-2.4.9-pa13revealed:10197cbc: d6 d6 0b 18 depw,z r22,7,8,r22 10197cc0: d6 b5 0a 10 depw,z r21,15,16,r21 10197cc4: 41 33 01 fe ldb ff(sr0,r9),r19 10197cc8: 0a d5 02 75 or r21,r22,r21 10197ccc: d6 94 09 08 depw,z r20,23,24,r20 10197cd0: 0a b4 02 74 or r20,r21,r20 10197cd4: 0a 93 02 73 or r19,r20,r19 10197cd8: d2 75 18 f8 extrw,u r19,7,8,r21 10197cdc: d2 74 19 f8 extrw,u r19,15,8,r20 10197ce0: 0c 73 12 16 stb r19,b(sr0,r3) 10197ce4: d2 73 1a f8 extrw,u r19,23,8,r19 10197ce8: 0c 75 12 10 stb r21,8(sr0,r3) 10197cec: 0c 74 12 12 stb r20,9(sr0,r3) 10197cf0: e8 86 a9 e4 b,l 102a51e8 <memcpy>,%r2 10197cf4: 0c 73 12 14 stb r19,a(sr0,r3) 10197cf8: 08 06 02 59 copy r6,r25 10197cfc: 08 04 02 5a copy r4,r26 10197d00: d7 20 1c 1d depwi 0,31,3,r25 10197d04: e8 0d a5 d8 call 101b1ff8 <padd_item> 10197d08: 08 08 02 58 copy r8,r24 10197d0c: 00 01 0e 74 rsm 1,r20 10197d10: 0c 7c 10 93 ldw e(sr0,r3),r19 10197d14: d6 60 1f 1f depwi 0,7,1,r19 10197d18: 0c 73 12 9c stw r19,e(sr0,r3) 10197d1c: 00 14 18 60 mtsm r20 10197d20: 85 e0 26 32 cmpib,=,n 0,r15,10198040 <.L1510+0x118> 10197d24: 00 01 0e 74 rsm 1,r20 10197d28: 0c 7c 10 93 ldw e(sr0,r3),r19 10197d2c: d6 7f 1f 5f depwi -1,5,1,r19 10197d30: 0c 73 12 9c stw r19,e(sr0,r3) 10197d34: 00 14 18 60 mtsm r20 10197d38: 08 00 02 54 copy r0,r20 10197d3c: 08 00 02 55 copy r0,r21 10197d40: 37 c6 3e 51 ldo -d8(sp),r6 10197d44: 37 cd 3d c1 ldo -120(sp),r13 10197d48: 6b d4 3e 51 stw r20,-d8(sr0,sp) 10197d4c: 6b d5 3e 59 stw r21,-d4(sr0,sp) 10197d50: 6b d4 3e 61 stw r20,-d0(sr0,sp) 10197d54: 6b d5 3e 69 stw r21,-cc(sr0,sp) 10197d58: 08 0c 02 59 copy r12,r25 10197d5c: 6b c6 3e 01 stw r6,-100(sr0,sp) 10197d60: 6b cd 3f 99 stw r13,-34(sr0,sp) 10197d64: 08 08 02 58 copy r8,r24 10197d68: 08 05 02 5a copy r5,r26 10197d6c: eb ff b4 4d b,l 10197798 <reiserfs_find_entry>,%r2which makes the error somewhere around here in
fs/reiserfs/namei.c, functionreiserfs_add_entry, after call topadd_item, before call toreiserfs_find_entry:/* copy name */ memcpy ((char *)(deh + 1), name, namelen); /* padd by 0s to the 4 byte boundary */ padd_item ((char *)(deh + 1), ROUND_UP (namelen), namelen); /* entry is ready to be pasted into tree, set 'visibility' and 'stat data in entry' attributes */ mark_de_without_sd (deh); visible ? mark_de_visible (deh) : mark_de_hidden (deh); /* find the proper place for the new entry */ memset (bit_string, 0, sizeof (bit_string)); de.de_gen_number_bit_string = (char *)bit_string; retval = reiserfs_find_entry (dir, name, namelen, &path, &de);And there I'm stuck. I'm sending this to the parisc-list to document the failure, and to linux-kernel to reach some reiserfs-experts, perhaps.
I'm willing to test anything!
Good luck,
Jurriaan
--
"I have seen her. That is enough, perhaps."
Pug smiled. "You are a rare man."
Raymond E Feist - The King's Buccaneer
GNU/Linux 2.4.9-ac5 SMP/ReiserFS 2x1402 bogomips load av: 0.04 0.01 0.06 -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 10 lines · Matthew Wilcox
Quoted 9 lines · David S. Miller
From: Matthew Wilcox <[email protected]>
Date: Sun, 2 Sep 2001 15:00:23 +0100Quoted 2 lines · On Sun, Sep 02, 2001 at 10:55:38AM +0200, [email protected] wrote:
ReiserFS version 3.6.25
bonnie[163]: Unaligned data reference 28As it says, an unaligned data reference.
Quoted 9 lines
Quoted 5 lines
BTW, you should not be OOPSing on this as unaligned references are defined as completely normal, especially in the networking.
Is it impossible to handle unaligned access traps properly on parisc? If so, well you have some problems...
No, we just haven't bothered to implement it yet. Not many people use IPX these days.
OK, well this seems to have opened quite a can of worms. Programming the handling of unaligned access traps on parisc is quite above my possibilities.
I did notice that mark_de_without_sd() in reiserfs_fs.h just calls the ext2_{set|clear|test}_bit routines. If the host architecture should handle that with unaligned addresses, obviously the exception for s390 should also go. The current source would make reiserfs slow on sparc as well, if I understand correctly.
To solve this for parisc, I see two possibilities:
- rewrite asm/parisc/bitops.h to have the ext2_* routines handle unaligned addresses. This would possibly be slowing down all aligned access. Not so nice.
- rewrite reiserfs_fs.h to use it's own test/set/clear bit routines. This would lose all the optimizations all specific architectures have in their asm/*/bitops.h. Also not nice.
Keeping in mind that I don't know any parisc assembly, is there any way I can help resolve this in an elegant manner?
Greetings,
Jurriaan
Signature · 3 lines
If all else fails, immortality can always be assured by spectacular error.
John Kenneth Galbraith
GNU/Linux 2.4.9-ac5 SMP/ReiserFS 2x1402 bogomips load av: 0.45 0.12 0.04Quoted 7 lines · Hans Reiser
Well, I should have read the next email before saying these patches seemed to be stable.
Jeff?
you misread the archive, Hans. This is the original bugreport; once the alignment was fixed it worked fine.
Signature · 1 line
Revolutions do not require corporate support.
Re: [SOLVED + PATCH]: documented Oops running big-endian reiserfs on parisc architecture
In reply to [email protected]Quoted 7 lines · Richard Zidlicky
Quoted 6 lines · On Sun, Sep 02, 2001 at 07:57:17PM +0200, [email protected] wrote:
include/linux/reiserfs_fs.h Sun Sep 2 20:47:27 2001 renamed from include/linux/reiserfs_fs.h Sun Sep 2 21:54:25 2001 +0
-0@@ -924,7 +924,7 @@ #define DEH_Visible 2
Quoted 8 lines
include/linux/reiserfs_fs.h Sun Sep 2 20:47:27 2001 line 929
Quoted 5 lines
include/linux/reiserfs_fs.h Sun Sep 2 20:47:27 2001 renamed from include/linux/reiserfs_fs.h Sun Sep 2 21:54:25 2001 +1
-1/* 64 bit systems (and the S/390) need to be aligned explicitly -jdm */ -#if BITS_PER_LONG == 64 || defined(__s390__) +#if BITS_PER_LONG == 64 || defined(__s390__) || defined(__hppa__) # define ADDR_UNALIGNED_BITS (3) #endifcouldn't reiserfs use
asm/unaligned.hlike anyone else? Seems at least sparc and mips may need the same treatment.
I'll be the first to admit that having the #if followed by arch defines really sucks, and that asm/unaligned.h would be much cleaner if for no other reason than avoiding an unnecessary gotcha for someone porting a new arch.
Unfortunately, this doesn't appear to work in all cases. I know from testing that the S/390 case will fail using the {get,put)_unaligned macros, since they are identical to a normal, unassisted assignment.
I did kick around the idea of making those macros the default accessors for the deh_state member (which is the only place they're used), but it unfairly penalizes arches that don't need them.
I'm open to suggestions.
-Jeff
Signature · 3 lines
Jeff Mahoney | "Bill Gates is a monocle and a Persian cat away [email protected] | from being the villain in a James Bond movie." [email protected] | -- Dennis Miller