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.
> > http://article.gmane.org/gmane.comp.emulat
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
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 Contr
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 ide_set_sec
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
> > t
> > 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,
- Original Message -
From: "Ralf Baerwaldt" <[EMAIL PROTECTED]>
To:
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 Opteron.
Is this v
The macros isupper, isspace, tolower, and so forth (from )
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 chars by
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 functi
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, the
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 tha
> 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 pro
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...)
Ye
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 08/02/20 18:01:24
Modified files:
tcg: tcg-op.h
Log message:
Fix andi, optimize addi and subi zero cases
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-op.h?cvsroot=qemu&r
> 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 u
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
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 err
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
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 "experiment
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? Al
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 ty
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 in
27 matches
Mail list logo
