On 03/07/2010 08:01 PM, Antoine Martin wrote:
On 03/08/2010 12:30 AM, Avi Kivity wrote:
On 03/07/2010 07:21 PM, Christoph Hellwig wrote:
On Sun, Mar 07, 2010 at 07:18:40PM +0200, Avi Kivity wrote:
The only things that stands out is this before the "read failed"
message:
[pid 9098] lseek(12, 0, SEEK_END) = 1321851815424
[pid 9121] pread(12, 0x7fa50a0e47d0, 2048, 0) = -1 EINVAL (Invalid
argument)
The buffer is unaligned here, yet the file was opened with O_DIRECT
(cache=none). This is strange, since alignment is not related to disk
size.
Yes cache=none: "-drive file=./vm/var_fs,if=virtio,cache=none"
Side question: this is the right thing to do for raw partitions, right?
The rightest.
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.
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?
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 ?
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
