Hi Edgar,
On Feb 16, 2008 11:07 PM, Edgar E. Iglesias [EMAIL PROTECTED] wrote:
On Tue, Feb 12, 2008 at 09:42:15PM +0200, Felipe Contreras wrote:
Hi,
I don't know what I'm doing but this seems to fix the weird issue I was
having.
On Wed, Feb 20, 2008 at 03:03:39PM +0200, Felipe Contreras wrote:
Hi Edgar,
On Feb 16, 2008 11:07 PM, Edgar E. Iglesias [EMAIL PROTECTED] wrote:
On Tue, Feb 12, 2008 at 09:42:15PM +0200, Felipe Contreras wrote:
Hi,
I don't know what I'm doing but this seems to fix the weird issue
On Feb 20, 2008 3:13 PM, Edgar E. Iglesias [EMAIL PROTECTED] wrote:
On Wed, Feb 20, 2008 at 03:03:39PM +0200, Felipe Contreras wrote:
Hi Edgar,
On Feb 16, 2008 11:07 PM, Edgar E. Iglesias [EMAIL PROTECTED] wrote:
On Tue, Feb 12, 2008 at 09:42:15PM +0200, Felipe Contreras wrote:
Hello,
I want to produce a file system that could be written.
The environment is arm (qemu-system-arm) with linux.
The file system type I prefer is ext2.
But I have some questions .
Is QEMU could produce a file system image that could be written?
If yes, what should I do ???
Thanks a lot
--
Open
The attached patch makes the ide emulation actually take notice of
error returns from bdrv_write and bdrv_aio_{read,write}.
Ian.
diff --git a/block.c b/block.c
diff --git a/hw/ide.c b/hw/ide.c
index 25f5b9f..370a412 100644
--- a/hw/ide.c
+++ b/hw/ide.c
@@ -792,6 +792,11 @@ static void
On Wed, Feb 20, 2008 at 03:53:46PM +, Ian Jackson wrote:
Content-Description: message body text
bdrv_flush is declared to return void, but this is wrong because it
means that the implementations have nowhere to report their errors.
Indeed, the implementations generally ignore errors.
Daniel P. Berrange writes (Re: [Qemu-devel] [PATCH] bdrv_flush error
handling):
On Wed, Feb 20, 2008 at 03:53:46PM +, Ian Jackson wrote:
Finally, it would perhaps be best if the block device emulators wrote
to the qemu console to complain if they give write errors. Otherwise
the errno
Finally, it would perhaps be best if the block device emulators wrote
to the qemu console to complain if they give write errors. Otherwise
the errno value and other important information will be lost, which
makes debugging hard.
If by 'qemu console' you mean stderr, then fine, but
- Original Message -
From: Ralf Baerwaldt [EMAIL PROTECTED]
To: qemu-devel@nongnu.org
Sent: 19.02.2008 18:09
Subject: [Qemu-devel] precompiled qemu-system-x86_64 is 32 bit instead of
64bit
I downloaded http://fabrice.bellard.free.fr/qemu/qemu-0.9.1-i386.tar.gz
and I'm using an AMD
The macros isupper, isspace, tolower, and so forth (from ctype.h)
are defined to take an int containing the value of an unsigned char,
or EOF.
This means that you mustn't write:
char *p;
...
if (isspace(*p)) { ...
If *p is a top-bit-set character, and your host architecture has
signed
bdrv_flush is declared to return void, but this is wrong because it
means that the implementations have nowhere to report their errors.
Indeed, the implementations generally ignore errors.
This patch corrects this by making it return int (implicitly, either 0
or -errno, as for other similar
Paul Brook wrote:
Finally, it would perhaps be best if the block device emulators wrote
to the qemu console to complain if they give write errors. Otherwise
the errno value and other important information will be lost, which
makes debugging hard.
If by 'qemu console' you mean stderr,
Avi Kivity writes (Re: [Qemu-devel] [PATCH] bdrv_flush error handling):
For non-raw formats, you can pass through errors on data, but it is
impossible to recover on metadata errors, so dying on I/O error should
be fine.
You mean metadata write errors I assume. I don't see why a metadata
Paul Brook writes (Re: [Qemu-devel] [PATCH] bdrv_flush error handling):
Disk full is a fundamentally unfriendly situation to be in. There is no good
answer. Reporting errors back to the host has its own set of problems. Many
guest OS effectively just lock up when this occurs.
I think that's
Write errors for non-raw formats can easily be caused by a disk full
situation on the host. Killing the guest hard is unfriendly for that
situation.
Disk full is a fundamentally unfriendly situation to be in. There is no good
answer. Reporting errors back to the host has its own set of
Robi Yagel wrote:
Hello,
Thanks for the patch,
Nice to hear that there is interest in this. :)
if you can, please advice on the proper place to add
periodic generation of SMI/NMIs in order to simulate, e.g., a watchdog (and
the
needed parameters - except for CPU_INTERRUPT_NMI...)
Yeah, I
Is savevm-upon-disk-full a realistic prospect?
Not particularly useful. If you're run out of disk space, chances are that
savevm will also fail.
Paul
Ian Jackson wrote:
Paul Brook writes (Re: [Qemu-devel] [PATCH] bdrv_flush error handling):
Disk full is a fundamentally unfriendly situation to be in. There is no
good
answer. Reporting errors back to the host has its own set of problems. Many
guest OS effectively just lock up when
Paul Brook wrote:
Is savevm-upon-disk-full a realistic prospect?
Not particularly useful. If you're run out of disk space, chances are that
savevm will also fail.
I'm imagining (a) that the savevm space is preallocated, or (b) is on
a different disk.
-- Jamie
On Wed, Feb 20, 2008 at 04:31:56PM +, Jamie Lokier wrote:
Ian Jackson wrote:
Paul Brook writes (Re: [Qemu-devel] [PATCH] bdrv_flush error handling):
Disk full is a fundamentally unfriendly situation to be in. There is no
good
answer. Reporting errors back to the host has its own
Daniel P. Berrange wrote:
On Wed, Feb 20, 2008 at 04:31:56PM +, Jamie Lokier wrote:
Ian Jackson wrote:
Paul Brook writes (Re: [Qemu-devel] [PATCH] bdrv_flush error handling):
Disk full is a fundamentally unfriendly situation to be in. There is no good
answer. Reporting
On Wednesday 20 February 2008 01:01:33 pm Anthony Liguori wrote:
Daniel P. Berrange wrote:
On Wed, Feb 20, 2008 at 04:31:56PM +, Jamie Lokier wrote:
Ian Jackson wrote:
Paul Brook writes (Re: [Qemu-devel] [PATCH] bdrv_flush error
handling):
Disk full is a fundamentally unfriendly
Jan Kiszka wrote:
However, find some experimental watchdog-enabler patch below. It allows
to use nmi_watchdog=1 (i.e. the IO-APIC variant) with Linux, without any
visible regression of normal IRQ delivery (but I only lightly tested it
on top of the kvm-userspace qemu, that's why experimental).
Hi All,
I am having my host OS as Fedora 7 and my guest OS is Windows Server
2003. I want to setup Network for Windows Server. I tried creating Network
bridge and tap0 device. Also i tried with VDE method for network setup. Can
someone please let me know what steps should i follow?
Hi...
On Wed, Feb 20, 2008 at 9:13 PM, b93049 [EMAIL PROTECTED] wrote:
Is QEMU could produce a file system image that could be written?
If yes, what should I do ???
Qemu doesn't deal directly with filesystem. Via qemu-img, the only
thing you can do is create empty disk image (be it raw type,
Sometimes the guest intentionally seeks the error. Example?
TrueCrypt 5.0 supports encryption of the full system disk. To get the real
size of the disk, the truecrypt driver queries the number of blocks of the
disk, but then tries to read after the last block, until it gets an error.
Qemu hangs
26 matches
Mail list logo
