[snip]
The other interesting thing is that it's using pread - which means
it's a too old kernel to use preadv and thus a not very well tested
codepath with current qemu.
Too old?, I am confused: both host and guest kernels are 2.6.33!
I built KVM against the 2.6.30 headers though.
You need to build qemu against the 2.6.33 headers ('make
headers-install'). But after we fix this, please.
OK.
I'm signing off for today, but I will test whatever patches/suggestions
you send my way.
It may also be that glibc is emulating preadv, incorrectly.
Not sure how to do that.
Antoine, can you check this? ltrace may help,
This the only part that looked slightly relevant:
[pid 26883] __xstat64(1, "./vm/media_fs", 0x7fff92e40500) = 0
[pid 26883] malloc(48) = 0x2a38d60
[pid 26883] memset(0x2a38d60, '\000', 48) = 0x2a38d60
[pid 26883] open64("./vm/media_fs", 540674, 00) = 12
[pid 26883] posix_memalign(0x7fff92e40560, 512, 16384, -1, 48) = 0
[pid 26883] lseek64(12, 0, 2, 0x7f404f2f3e60, 4) = 0x133c4820600
Where's pread/preadv? Did you use -f?
Yes I did.
ltrace -f bash ./vm/start.sh >& trace.log
or run 'strings libc.so | grep pread'.
strings /lib/libc.so.6 | grep pread
preadv
preadv64
pread
__pread64_chk
__pread64
__pread_chk
So it does seem glibc emulates preadv.
Perhaps https://bugzilla.redhat.com/show_bug.cgi?id=563103 ?
This a gentoo box... but yes, this does look similar doesn't it?
Antoine
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
