zfs 0.6.4.1 could not work on sparc64

[wangdbang]

zfs 0.6.4.1 could not work on sparc64, it reported "Bus error" when i used "zpool list" command. but 0.6.3 worked well. I tried to debug it with gdb, the output was:

[root@HAslave zfs-0.6.4.1]# gdb /usr/local/sbin/zpool
GNU gdb (GDB) Fedora (7.0-4.ft.ky3)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc64-redhat-linux-gnu".
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/local/sbin/zpool...done.
(gdb) b main
Breakpoint 1 at 0x10af6c: file ../../cmd/zpool/zpool_main.c, line 5880.
(gdb) r
Starting program: /usr/local/sbin/zpool
[Thread debugging using libthread_db enabled]

Program received signal SIGBUS, Bus error.
uu_init () at ../../lib/libuutil/uu_misc.c:251
251 (void) pthread_atfork(uu_lockup, uu_release, uu_release_child);
Missing separate debuginfos, use: debuginfo-install glibc-2.11.1-5.ft.ky3.sparc64 libuuid-2.16-10.2.ft.ky3.sparc64 zlib-1.2.3-24.ft.ky3.sparc64
(gdb) bt
#0 uu_init () at ../../lib/libuutil/uu_misc.c:251
#1 0xfffff80100255834 in __do_global_ctors_aux () from /usr/local/lib/libuutil.so.1
#2 0xfffff801002428f4 in _init () from /usr/local/lib/libuutil.so.1
#3 0xfffff80100011c68 in call_init () from /lib64/ld-linux.so.2
#4 0xfffff80100011e20 in _dl_init_internal () from /lib64/ld-linux.so.2
#5 0xfffff80100002d30 in _dl_start_user () from /lib64/ld-linux.so.2
#6 0xfffff80100002d30 in _dl_start_user () from /lib64/ld-linux.so.2

Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

[behlendorf]

@wangdbang we've almost certainly accidentally introduced a memory alignment error since we aren't regularly testing on sparc. Here's a nice link to the basic issue. You could use git bisert to determine where the issue was introduced.

http://cmynhier.blogspot.com/2008/10/memory-alignment-on-sparc-or-300x.html

[wangdbang]

@behlendorf I saw the contents in the link you gave, but i still have no idea how to change the code or add the option to gcc compiler to let zfs work on sparc64, would you like to give more suggestion? I just use ZFS a few days, i'm not familiar with the zfs codes, thank you very much.

[wangdbang]

@behlendorf I did not find any diffrence in lib/libuutil/* between 0.6.3 and 0.6.4.1, is there any new truct added in? Should i focus on the new struct?

[behlendorf]

@wangdbang it's going to be something subtle where we've accidentally misaligned a 32-bit variable. My suggestion would be to use git bisect to just test all the commits between 0.6.3 and 0.6.4 automatically. That should greatly narrow down where the alignment issue was introduced. See http://git-scm.com/docs/git-bisect for documentation on how to use git to accomplish this. This is definitely something we'll want to fix.

[wangdbang]

@behlendorf I will try it again with your suggestion, thanks again.

Best Regards,
Daobang Wang.

在 2015-06-02 05:19:57，"Brian Behlendorf" notifications@github.com 写道：

@wangdbang it's going to be something subtle where we've accidentally misaligned a 32-bit variable. My suggestion would be to use git bisect to just test all the commits between 0.6.3 and 0.6.4 automatically. That should greatly narrow down where the alignment issue was introduced. See http://git-scm.com/docs/git-bisect for documentation on how to use git to accomplish this. This is definitely something we'll want to fix.

—
Reply to this email directly or view it on GitHub.

[wangdbang]

@behlendorf, we could use it now, did not change any code, it had supported already, should not use the default configuration to config it before compile.this could be marked close.

[behlendorf]

@wangdbang thanks for the followup. Then I'll close this out, although we'd still like to setup an automated builder for sparc.