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 kernel-2.4.21-6.EL How reproducible: 100% (always) Actual results: [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 0xe0000003fd7e87fa, ip=0xa000000000248a01 kernel unaligned access to 0xe0000003fd7e881a, ip=0xa000000000248a40 kernel unaligned access to 0xe0000003fd7e87e6, ip=0xa000000000248a41 kernel unaligned access to 0xe0000003fd7e882a, ip=0xa000000000248a80 st/ 3 cert hazard.old ia64 RCS src team.bak bin hazard ia32 lib sbin team [root@either-p0 root]# Expected results: far, far fewer unaligned access errors when running /bin/ls 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 tonight.
Verified in the re0108 ISO
This was fixed in RHEL3 U1.