Hi,
Cygwin compiler doesn't seem to like variables/structure members which are
named "interface".
This patch renames them to "type".
Hervé
cygwin_fix.diff
Description: Binary data
linux-user setsockopt() doesn't return the correct errno for certain
cases. This fixes errno for unsupported levels. It's similar to the
bug in getsockopt().
Index: qemu/linux-user/syscall.c
===
--- qemu.orig/linux-user/syscall.c 200
nanosleep() doesn't write remaining time if there's an error - but it's
when return value == -1 and errno == EINTR when the remaining time must
be written.
Index: qemu/linux-user/syscall.c
===
--- qemu.orig/linux-user/syscall.c 2007-12
linux-user getsockopt() doesn't return the correct errnos for certain
cases. This fixes errnos for unsupported levels and unsupported SOL_IP
option names.
Index: qemu/linux-user/syscall.c
===
--- qemu.orig/linux-user/syscall.c 2007-12
Here is the Mainstone keypad martix
-Armin
Index: qemu/hw/mainstone.c
===
--- qemu.orig/hw/mainstone.c
+++ qemu/hw/mainstone.c
@@ -18,6 +18,45 @@
#include "sysemu.h"
#include "flash.h"
+static struct keymap map[0xE0] = {
+[0
Hello,
Here is a new series of keypad support patches for the PXA27x.
I believe I have addressed all the concerns from my first set of patch.
Feedback and comment welcome.
-Armin
Index: qemu/hw/pxa.h
===
--- qemu.orig/hw/pxa.h
+++ qe
andrzej zaborowski wrote:
Hi,
On 12/12/2007, Armin <[EMAIL PROTECTED]> wrote:
Here is an attempt to add PXA27x keypad support. It currently only
supports the matrix type interface. It still needs direct and
mulitswitch support added.
Just wanted to get something out there for folks to pound
On Thu, 2007-12-13 at 01:21 +, Paul Brook wrote:
> > - It would be good to limit the changes in the CPU emulation code to
> > handle the TLS. For example, on MIPS, the TLS register must not be
> > stored in the CPU state. Same for ARM.
>
> I disagree. The TLS register is part of the CPU state
> - It would be good to limit the changes in the CPU emulation code to
> handle the TLS. For example, on MIPS, the TLS register must not be
> stored in the CPU state. Same for ARM.
I disagree. The TLS register is part of the CPU state. On many machines
(including ARMv6 CPUs) it's an actual CPU re
Stefan Weil wrote:
basetyps.h is included by windows.h / rpc.h. QEMU does not need it, so
you can avoid it like this:
#define WIN32_LEAN_AND_MEAN
#include
WIN32_LEAN_AND_MEAN reduces the number of includes in windows.h
and increases compilation speed. And you don't have to rename
variables lik
Thayne Harbaugh wrote:
> I believe Paul Brook did the original patch for arm eabi TLS. The patch
> has bounced around for a bit but hasn't been applied. We've been using
> this patch for a while and have tweaked it to be a bit more correct as
> far as code organization.
>
> Please let me know wh
Filip Navara wrote:
> Hi Ryan & others,
>
> now I have been holding a SMBIOS patch on my hard disk for way to long it
> seems. I used a different approach from yours, so I decided to publish it
> for review or further ideas. What I did was to modify the bochs bios to
> produce the SMBIOS tables an
Hi all,
I'm trying to find out a virtualization solution to fit our project.
Do you think QEUM is the right choice for me?
Host OS: Windows, Max OS X (Intel), Linux (x86 or x86_64), Solaris
(Optional)
Guest OS: Scientific Linux 3 or 4 (x86, the option to support 64bit
and SMP in the fu
Robert Nestor <[EMAIL PROTECTED]> wrote:
> It seems qemu-forum.ipi.fi is down. Is there an alternate place one
> can obtain source snapshots or browse the user forums?
I mentioned something to Pablo, and he said he could see it
from where he was, but he suspected there's some DNS problem
basetyps.h is included by windows.h / rpc.h. QEMU does not need it, so
you can avoid it like this:
#define WIN32_LEAN_AND_MEAN
#include
WIN32_LEAN_AND_MEAN reduces the number of includes in windows.h
and increases compilation speed. And you don't have to rename
variables like interface :-)
Rega
2007/12/12, C.W. Betts <[EMAIL PROTECTED]>:
>
> Could you perhaps give a patch? I don't feel like going through and
> changing every instance of BlockInterfaceType to something else.
>
Having a closer look I think the underlying problem is a name conflict with
a #define in Mingw's header file ba
Qemu doesn't exit with the proper code when dieing from an uncaught
signal. Exit codes for uncaught signals are -. Unfortunately
the kernel filters values from exit() and _exit().
A solution is to actually die from an uncaught signal. This patch
detects an uncaught signal, installs the default
sorry my english poor.
lock cmpxchg %edx,%ecx is Invalid instruction but qemu-0.9.0 can execute
It seems qemu-forum.ipi.fi is down. Is there an alternate place one
can obtain source snapshots or browse the user forums?
There are some places where target signals and host signals aren't
correctly differentiated. This patch addresses proper signal
translation between target and host.
* Changes variable names to be more explicit about target and host
signals.
* Calls target_to_host_signal() and host_to_target_sign
andrzej zaborowski schrieb:
> On 30/11/2007, Stefan Weil <[EMAIL PROTECTED]> wrote:
>
>> What about my bug report? Up to now I got no replies.
>>
>> Please include the patch in CVS HEAD - or tell me why you won't do so.
>>
>
> Please check that you can still reproduce the error. pbrook expl
This patch adds the missing get_sp_from_cpustate() for m68k.
Index: qemu/linux-user/m68k/target_signal.h
===
--- qemu.orig/linux-user/m68k/target_signal.h 2007-12-11 10:33:23.0 -0700
+++ qemu/linux-user/m68k/target_signal.h 200
Actually somebody has already described the problem on the mailing list and
Paul Brook replied to that message. Hopefully you can find it in the
archives.
F.
On Dec 12, 2007 5:25 PM, 武田 俊也 <[EMAIL PROTECTED]> wrote:
> Hi all.
>
> I encountered the crash problem with windows build on Core-Duo ho
Hi all.
I encountered the crash problem with windows build on Core-Duo host.
Qemu crashes in cpu_interrupt() called from host_alarm_handler() in vl.c
because CPUState *env = next_cpu is null.
I tried the patch to check env is not null in host_alarm_handler()
and now qemu does not crash.
Could you perhaps give a patch? I don't feel like going through and changing
every instance of BlockInterfaceType to something else.
- Original Message -
From: Eduardo Felipe
To: qemu-devel@nongnu.org
Sent: Wednesday, December 12, 2007 3:41 AM
Subject: Re: [Qemu-devel] Window
tmr_overflow_time is updated only once on guest Windows, so ACPI timer
interrupt is raised only twice. My solution is that tmr_overflow_time is
updated every time after setting expired_time. I tested it on Windows XP,
not sure on other guest OS .
acpi.patch:
--- qemu.orig/hw/acpi.c Wed Dec 12 2
Hi,
by mere accident I fixed the gcc4 Linux x86_64 support. Originally I
was tracking down a bug in the Mac OS version and wanted to compare
the outputs of the Linux version with the Mac one when I realized that
a gcc4 compiled qemu does not work on x86_64 Linux.
The symptoms were very simi
On Dec 12, 2007, at 12:39 PM, Andreas Färber wrote:
Am 11.11.2007 um 13:40 schrieb Andreas Färber:
Building CVS HEAD on OS X (here sparc-softmmu) currently results in
unresolved symbols:
gcc-3.3 -g-o qemu-img qemu-img.o qemu-img-block.o qemu-img-
block-raw.o cutils.o block-cow.o bloc
andrzej zaborowski writes ("Re: [Qemu-devel] [PATCH] ioemu/qemu vga: save and
restore vram buffer"):
> On 10/12/2007, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > I have reinterpreted the `is_vbe' byte, which is related to
> > CONFIG_BOCHS_VBE, as a general flags word. This enables my code to
> > a
Am 11.11.2007 um 13:40 schrieb Andreas Färber:
Building CVS HEAD on OS X (here sparc-softmmu) currently results in
unresolved symbols:
gcc-3.3 -g-o qemu-img qemu-img.o qemu-img-block.o qemu-img-block-
raw.o cutils.o block-cow.o block-qcow.o aes.o block-vmdk.o block-
cloop.o block-dmg.o
2007/12/12, C.W. Betts <[EMAIL PROTECTED]>:
>
> Same problem with cygwin. I think it's a problem with BlockInterfaceType
> not being correctly parsed on mingw-gcc for some odd reason.
Hi,
I don't think it is related with BlockInterfaceType itself. The problem is
to use "interface" as a variabl
Same problem with cygwin. I think it's a problem with BlockInterfaceType not
being correctly parsed on mingw-gcc for some odd reason.
- Original Message -
From: "Balazs Attila-Mihaly (Cd-MaN)" <[EMAIL PROTECTED]>
To: "Qemu Devel"
Sent: Tuesday, December 11, 2007 8:05 PM
Subject: [Qemu-d
32 matches
Mail list logo
