Red Hat Bugzilla – Bug 112785
Extraordinarily large number of unaligned accesses with NFS and -6.EL kernel
Last modified: 2007-11-30 17:06:59 EST
Description of problem: I can understand the general lack of concern
for seeing "unaligned access" messages that find their way to
/dev/console on an IA64 (or Sparc64, or Alpha/64, etc.) system. But
there's a concerning number of them coming from /bin/ls when looking
at directories mounted over NFS. I see this on the Pinnacles systems;
I'm able to re-create this at will on our Eiger (rx7620).
So many that, when compared to -4.EL (RHEL3), they're alarmingly high.
Something ought to be done about it.
Version-Release number of selected component (if applicable):
# rpm -q kernel
How reproducible: 100% (always)
[root@either-p0 root]# mount
/dev/sdb2 on / type ext3 (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
none on /dev/shm type tmpfs (rw)
test.lsy:/pbfd on /store type nfs (rw,nolock,addr=10.100.0.102)
[root@either-p0 root]# ls /store
kernel unaligned access to 0xe0000003fd7eb5fa, ip=0xa000000000248a01
kernel unaligned access to 0xe0000003fd7eb61a, ip=0xa000000000248a40
kernel unaligned access to 0xe0000003fd7eb5e6, ip=0xa000000000248a41
kernel unaligned access to 0xe0000003fd7eb62a, ip=0xa000000000248a80
cert dist ftp FW ISO ks lost+found misc scratch store test
[root@either-p0 root]# ls /store/te<TAB>kernel unaligned access to
kernel unaligned access to 0xe0000003fd7e881a, ip=0xa000000000248a40
kernel unaligned access to 0xe0000003fd7e87e6, ip=0xa000000000248a41
kernel unaligned access to 0xe0000003fd7e882a, ip=0xa000000000248a80
3 cert hazard.old ia64 RCS src team.bak
bin hazard ia32 lib sbin team
Expected results: far, far fewer unaligned access errors when running
Additional info: In the text above, the second "ls" call uses the TAB
key (filename expansion) capability of bash. This is very easy to
reproduce on my Eiger (Olympia should show the same over NFS). I can
get an unaligned access for EVERY unique directory when it's traversed
for the first time.
It seems we missed removing this printk....
A fix for this got put into what it hoped to be the final U1 rebuild
Verified in the re0108 ISO
This was fixed in RHEL3 U1.