Il 26/05/2013 19:08, Andreas Färber ha scritto:
> Have you actually tried that out with a patch such as the following?
>
> diff --git a/hw/ide/core.c b/hw/ide/core.c
> index c7a8041..bf1ff18 100644
> --- a/hw/ide/core.c
> +++ b/hw/ide/core.c
> @@ -795,6 +795,8 @@ static void ide_flush_cb(void *opa
On Sun, May 26, 2013 at 07:08:02PM +0200, Andreas Färber wrote:
> Am 21.05.2013 09:12, schrieb Gonglei (Arei):
> > Through analysis, I found that because the system call the fdatasync
> > command in the Qemu over 30s,
> > after the Guest's kernel thread detects the io transferation is timeout,
>
Am 21.05.2013 09:12, schrieb Gonglei (Arei):
> Through analysis, I found that because the system call the fdatasync command
> in the Qemu over 30s,
> after the Guest's kernel thread detects the io transferation is timeout, went
> to check IDE disk state.
> But the IDE disk status is 0x50, rathe
[Qemu-devel] IDE disk FLUSH take more than 30 secs, the SUSE
> guest reports "lost interrupt and the file system becomes read-only"
>
> Hi,
>
> Am 21.05.2013 09:12, schrieb Gonglei (Arei):
> > In the case of physical hard disk's speed which processing IO (when grou
Hi,
Am 21.05.2013 09:12, schrieb Gonglei (Arei):
> In the case of physical hard disk's speed which processing IO (when grouping
> RAID) is very slow, I encountered a problem.
> I dd big file in SUSE virtual machine, the command is
> linux:/ # dd if=/dev/zero of=./info bs=1M count=5000;sync
>
> b
In the case of physical hard disk's speed which processing IO (when grouping
RAID) is very slow, I encountered a problem.
I dd big file in SUSE virtual machine, the command is
linux:/ # dd if=/dev/zero of=./info bs=1M count=5000;sync
but finally I get those message:
linux:~ # dmesg
[ 174.804114]