On Wed, Mar 28, 2007 at 12:35:18AM +0100, Thiemo Seufer wrote:
> Right, a piggyback-style loader would likely fail in that case.
Which is exactly the interesting case for x86_64. So, since Paul's
verified that grub and lilo just put them far apart, maybe bumping up
the size is the right thing to
On Tuesday 27 March 2007 06:34:04 pm Kyle Hubert wrote:
> I've been looking online, but I can't say that I have found the answer
> to this yet.
>
> When using QEMU, I've noticed that if I switch away to a different
> virtual desktop on the host OS's WM, then QEMU stops what it is doing.
> It's real
On Wednesday 28 March 2007 01:22, andrzej zaborowski wrote:
> On 28/03/07, Kyle Hubert <[EMAIL PROTECTED]> wrote:
> > I've been looking online, but I can't say that I have found the answer
> > to this yet.
> >
> > When using QEMU, I've noticed that if I switch away to a different
> > virtual deskto
On 28/03/07, Kyle Hubert <[EMAIL PROTECTED]> wrote:
I've been looking online, but I can't say that I have found the answer
to this yet.
When using QEMU, I've noticed that if I switch away to a different
virtual desktop on the host OS's WM, then QEMU stops what it is doing.
It's really clear when
Paul Brook wrote:
> > > Note, that does not readily work - this is where we load the
> > > compressed kernel image and initrd, but what matters is the size it
> > > gets uncompressed to.
> >
> > I think what matters is the space taken by (uncompressed and loaded)
> > kernel ALLOC segments. Everythi
I've been looking online, but I can't say that I have found the answer
to this yet.
When using QEMU, I've noticed that if I switch away to a different
virtual desktop on the host OS's WM, then QEMU stops what it is doing.
It's really clear when it's in the middle of a boot, but it always
occurs.
> > Note, that does not readily work - this is where we load the
> > compressed kernel image and initrd, but what matters is the size it
> > gets uncompressed to.
>
> I think what matters is the space taken by (uncompressed and loaded)
> kernel ALLOC segments. Everything above that should be ok to
Daniel Jacobowitz wrote:
> On Tue, Mar 27, 2007 at 08:16:40PM +0100, Thiemo Seufer wrote:
> > Gwenole Beauchesne wrote:
> > > Hi,
> > >
> > > The following patch increases max kernel size to 8 MB when qemu is
> > > invoked
> > > with -kernel and -initrd. Otherwise, x86_64 kernel panics when load
On Tue, Mar 27, 2007 at 08:16:40PM +0100, Thiemo Seufer wrote:
> Gwenole Beauchesne wrote:
> > Hi,
> >
> > The following patch increases max kernel size to 8 MB when qemu is invoked
> > with -kernel and -initrd. Otherwise, x86_64 kernel panics when loading the
> > initrd (e.g. /x86_64/isolinux/a
Gwenole Beauchesne wrote:
> Hi,
>
> The following patch increases max kernel size to 8 MB when qemu is invoked
> with -kernel and -initrd. Otherwise, x86_64 kernel panics when loading the
> initrd (e.g. /x86_64/isolinux/alt0/{vmlinuz,all.rdz}).
I would like a patch which adjusts the initrd load
On Tue, Mar 27, 2007 at 06:14:22PM +0200, Gwenole Beauchesne wrote:
> Hi,
>
> The following patch increases max kernel size to 8 MB when qemu is invoked
> with -kernel and -initrd. Otherwise, x86_64 kernel panics when loading the
> initrd (e.g. /x86_64/isolinux/alt0/{vmlinuz,all.rdz}).
When I t
Hi,
The following patch increases max kernel size to 8 MB when qemu is invoked
with -kernel and -initrd. Otherwise, x86_64 kernel panics when loading the
initrd (e.g. /x86_64/isolinux/alt0/{vmlinuz,all.rdz}).
Thanks,
Gwenole.
2007-03-27 Gwenole Beauchesne <[EMAIL PROTECTED]>
* hw/pc
Hi qemu-devers,
this is my first post here, so please be kind :-)
i believe i found a bug in qemu's ne2000 code. i'm currently working on
a ne2000 driver for my little hobby-os and i'm having some troubles
getting it to receive any packets when running on qemu. but it works
fine on bochs and
Hi qemu-devers,
this is my first post here, so please be kind :-)
i believe i found a bug in qemu's ne2000 code. i'm currently working on
a ne2000 driver for my little hobby-os and i'm having some troubles
getting it to receive any packets when running on qemu. but it works
fine on bochs and
On Mon, Mar 26, 2007 at 12:30:13AM +0100, Thiemo Seufer wrote:
> > I renamed it to qemu_create_pidfile and moved it to osdep.h. I hope
> > that has all necessary includes. Please test.
>
> osdep.c, that is, only a tiny bit was for osdep.h. :-)
Tested on Windows Server 2003, thanks for the quick r
Qemu does not generate a double fault (DBF) on x86, if a general protection
fault could not be delivered. Instead it hangs in a loop.
The patch fix this bug by checking whether we are already in a GPF exception.
Bernhard Kauer
Index: helper.c
===
Hello,
I build my ppc-elf toolchain. But I'm not the target to check my soft.
I want use the Qemu simulator, but when I carry out the "qemu-ppc -L
/ /{toolchain}/bin/ls" instruction , I have the following error :
+ When I put the libm.so.6 library of eldk toolchain (from
{toolchain}/p
17 matches
Mail list logo
