Shouldn't the cachepolicy switch take care of that? But yes, there are various problems with I/O on vmap regions with virtually indexed caches, see: http://www.spinics.net/lists/linux-arch/msg04301.h
Setting cachepolicy=uncached should make aliasing issues disappear. If you're still seeing issues with cachepolicy=uncached, it's likely some other issue.
At one point there were other patches floating around to "fix" arm which were not correct. Are these problems seen on a pristine 2.6.27-rc4 kernel, or with other special arm patches applied? -Eric
You could try undoing this: /* ARM old ABI has some weird alignment/padding */ and just define __arch_pack to nothing unconditionally, to see if that's what broke... Or if someone can provide an xfs.
Ok, actually: first - sorry for the scattershot replies. I thought userspace was updated earlier, but: xfsprogs-2.10.1 (5 September 2008)... - Add packed on-disk shortform directory for ARM's old ABI
Hi Eric, I tried to reproduce this problem on my ARM machine and it's really easy to trigger. See the transcript below. I tried with 2.6.26.6 (without the ARM old ABI fix) and 2.6.27 (with the fix),
Thanks; a quick look at the disk structure sizes & offsets shows no differences (as I'd hope/expect for ARM EABI). So is this a regression? did it used to work? If so, when? :) (just for the record;
* Eric Sandeen <sandeen@xxxxxxxxxxx> [2008-10-16 17:13]: The original report was with 2.6.18 but that was with the old ABI: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423562 I just installed a
As far as I can remember (I only used old ABI arm) this is not a regression. XFS never worked on arm for me. If you need tests on old ABI just tell me. -- Ever tried. Ever failed. No matter. Try agai
Ok; I think there are probably a few problems, so trying to keep them straight. I at least had xfs working properly in a qemu arm emulator a few weeks ago... :) ok, thanks! -Eric
Ok, that's a little odd. (correlates with the "bad" magic that was seen, because block 0 is the superblock, but doesn't make sense because we were trying to read a directory leaf block, in theory) If
* Eric Sandeen <sandeen@xxxxxxxxxxx> [2008-10-17 09:15]: I cannot even mount it: debian:~# mkfs.xfs -f /dev/sda5 meta-data=/dev/sda5 isize=256 agcount=4, agsize=94380 blks = sectsz=512 attr=2 data =
Oh, wow. This sounds like a new problem then; not a cache problem, and not an alignment problem... hrm. I'll try to think of something else to try. Thanks, -Eric
Author: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
Date: Sat, 18 Oct 2008 22:48:53 +0300
You are wrong. Our team have experience with XFS on ARM OABI on NAS. It worked fine on 2.6.12, but got broken on 2.6.17. http://oss.sgi.com/bugzilla/show_bug.cgi?id=712 -- Regards, Kirill A. Shutemov
Author: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
Date: Sat, 18 Oct 2008 23:17:50 +0300
I'll try to do it. -- Regards, Kirill A. Shutemov + Belarus, Minsk + ALT Linux Team, http://www.altlinux.com/ Attachment: signature.asc Description: Digital signature
That's the log replay indicating that there's a bad transaction header in the log. Very strange - it shoul dbe a clean log. What does xfs_logprint -t /dev/sda5 tell you about the transactions in the