On Fri, 20 May 2005, Julian Chesterfield wrote:
Is there a way to redirect monitor IO to a local socket, e.g. a unix
filehandle socket, under linux? When I try to redirect to a pty using
'-monitor pty' the graphical qemu window doesn't boot. Am I starting
it incorrectly?
ARGS:
qemu -hda -m 256
On Wed, 18 May 2005, Ben Taylor wrote:
Are the other brctl commands I had in there not required?
Not strictly required, but speeds things up. The default for the bridgeing
is to use Spanning Tree to prevent loops in your network, but as this
bridge is to a virtual network there can't be loop
The attached patch is an initial implementation of a hand-written code
generation backend for qemu. Salient features are:
The basic principle is that (as before) guest code is broken down into simple
operations ("qOPs"). These qops use a simple three-argument model, with the
goal of being very
Is there a way to redirect monitor IO to a local socket, e.g. a unix
filehandle socket, under linux? When I try to redirect to a pty using
'-monitor pty' the graphical qemu window doesn't boot. Am I starting
it incorrectly?
ARGS:
qemu -hda -m 256 -boot c -nics 1 -n -full-screen
-monitor pty
Hello
I have tried to debug the nasty problem, that I loose the keyboard
input in QEMU, when using FreeDOS with HIMEM, EMM386 and FDAPM. I
found a "raise_exception 0xd" in the debug log. I think this is a GPF.
If I use HIMEM and FDAPM, it works fine.
Because HIMEM, EMM386 and FDAPM is working on
Hi!
I tried to build qemu-system-sparc on a windows host using mingw and all steps
described in the qemu documentation. First of all, this doesn't work since
qemu requires zlib. After compiling and installing zlib in the mingw
environment qemu builds fine. But when trying to test qemu using the
On Thursday 19 May 2005 23:25, John Hogerhuis wrote:
> But once you are past that point gcc for a given arch, gcc isn't
> really going to help you any more. So bring on the hand
> coding/optimizations. There's no doubt the hand coded stuff would be
> at least as good as gcc output. And that's becau
Hello,
I've sucessfully tested NetBSD 2.0 and OpenBSD 3.7 as target OS (i386).
The only little problems I got :
- OpenBSD:
Problem:
After installing, on first boot (a kernel message), I got a lot of :
apm0: APM set CPU idle: unknow error code? (83)
Temporary solution:
boot with boot -c,
On 5/20/05, John Hogerhuis <[EMAIL PROTECTED]> wrote:
> But once you are past that point gcc for a given arch, gcc isn't
> really going to help you any more. So bring on the hand
> coding/optimizations.
And for popular combinations of architectures, such as x86 or PPC on
each other, I absolute a
Just a quick thank-you for the x86_64 support; I'm currently working on the
initrd on the install cd for slamd64 (a amd64 port of Slackware), and your
work has saved me both countless hours and money (in the cost of useless
CDRs).
Regards,
--
Fred Emmott
(http://www.fredemmott.co.uk)
__
Rudi Lippert wrote:
well, nothing really means nothing. the guest window does not come up, and
the console window does not show anything, even with -monitor stdio. the
thread just goes to sleep.
strace may be interesting, and 5kb are not too much, i think, so here it
comes.
thanks for now,
Rudi
[.
11 matches
Mail list logo