Out of curiosity, wouldn't it be better to specifically request that
feature of gcc, with one of its myriad options, rather than forcing a
rather large optimization sweep? I'm sure that -O2 is good generally,
but using it as a kludge to get at one of the many things that it
enables seems li
Ed Swierk wrote:
On 3/28/06, Jens Axboe <[EMAIL PROTECTED]> wrote:
monitor/mwait feature present.
using mwait in idle threads.
[snip]
invalid operand: [#1]
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.14-1.1656_FC4)
EIP is at mwait_idle+0x2f/
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Paul Brook <[EMAIL PROTECTED]> 06/03/28 20:20:38
Modified files:
. : vl.c
Log message:
Use 3-argument open call when creating file.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/
On 3/28/06, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > monitor/mwait feature present.
> > using mwait in idle threads.
>
> [snip]
>
> > invalid operand: [#1]
> > Modules linked in:
> > CPU:0
> > EIP:0060:[]Not tainted VLI
> > EFLAGS: 00010246 (2.6.14-1.1656_FC4)
> > EIP is at mwai
On Tue, Mar 28 2006, Ed Swierk wrote:
> I'm still getting a kernel panic running a Linux guest kernel with
> -kernel-qemu. I'm using kqemu-1.3.0pre5 and
> qemu-snapshot-2006-03-27_23.
>
> The guest kernel is a precompiled Fedora Core 4 kernel, version
> 2.6.14-1.1656_FC4. It works fine with kqemu
Ed Swierk wrote:
I'm still getting a kernel panic running a Linux guest kernel with
-kernel-qemu. I'm using kqemu-1.3.0pre5 and
qemu-snapshot-2006-03-27_23.
The guest kernel is a precompiled Fedora Core 4 kernel, version
2.6.14-1.1656_FC4. It works fine with kqemu in non-kernel-kqemu mode.
Any
I'm still getting a kernel panic running a Linux guest kernel with
-kernel-qemu. I'm using kqemu-1.3.0pre5 and
qemu-snapshot-2006-03-27_23.
The guest kernel is a precompiled Fedora Core 4 kernel, version
2.6.14-1.1656_FC4. It works fine with kqemu in non-kernel-kqemu mode.
Any hints for how to tr
On Tue, 28 Mar 2006 12:26:37 +0400, Brad Campbell <[EMAIL PROTECTED]> wrote:
> Fabrice Bellard wrote:
>> Hi,
>>
>> I just released a new version of kqemu which fixes some recently
>> discovered issues. The fixes are the following:
>>
>> - Support for guest Linux kernels compiled with gcc >= 3.3
>
Sent: Tuesday, March 28, 2006 8:50 PM Brad Campbell wrote:
> Kazu wrote:
>
>> I tested Linux guest/WinXP host but the host OS crashed.
>
> I believe -kernel-kqemu is still somewhat experimental on Windows host.
>
>> Redhat 7.2 guest/Fedora Core 4 host with normal kqemu is slower
>> than -no-kqemu
On Wed, Feb 15, 2006 at 12:25:01PM +, Thiemo Seufer wrote:
> Hello all,
>
> the appended patch
>
> - Adds detection of gcc commandline flag support, based on the theory
> "If it exists, we want to use it".
> - Uses this to add enough gcc4 flag magic to OP_FLAGS, and remove the
> specialca
On Tuesday, March 28, 2006, 14:27:48, andrzej zaborowski wrote:
> Normal Operating Systems don't crash no matter what program they are running.
That only applies to user-mode programs that don't make calls to device
drivers. Kqemu is basically a device driver which runs in kernel space, and
a cra
On Tue, Mar 28, 2006 at 08:57:15AM +0200, Dirk Behme wrote:
> Hi,
>
> ELF loader feature for MIPS in patch
>
> http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00033.html
>
> was rejected because it breaks loading of raw kernel images:
>
> http://lists.gnu.org/archive/html/qemu-devel/200
Paul Brook wrote:
Normal Operating Systems don't crash no matter what program they are
running.
Except that kqemu is a kernel module (or windows equivalent). As such it is
effectively part of the OS, and can easily crash the whole machine.
Yes indeed.
I'm actually quite impressed. I've cras
Works fine on my computer too!
OS: Ubuntu 5.10 (Breezy Badger)
CPU: Athlon XP 2000+ (with kernel 2.6.12-10-k7)
Using latest CVS version of QEMU with some USB patches from http://gnome.dnsalias.net/patches/On 3/28/06,
Paul Brook <[EMAIL PROTECTED]> wrote:
> Normal Operating Systems don't crash no
> Normal Operating Systems don't crash no matter what program they are
> running.
Except that kqemu is a kernel module (or windows equivalent). As such it is
effectively part of the OS, and can easily crash the whole machine.
Paul
___
Qemu-devel mail
On 28/03/06, Marco Matthies <[EMAIL PROTECTED]> wrote:
> Brad Campbell wrote:
> > none 768M 137M 632M 18% /tmp <-- not sure why it
> > says none.. it's tmpfs
>
> change the none to tmpfs in /etc/fstab. normally the mount point goes
> there, but tmpfs (and proc, for example) don
Brad Campbell wrote:
none 768M 137M 632M 18% /tmp <-- not sure why it
says none.. it's tmpfs
change the none to tmpfs in /etc/fstab. normally the mount point goes
there, but tmpfs (and proc, for example) don't have a mount point so you
can put anything there.
marco
__
Kazu wrote:
I tested Linux guest/WinXP host but the host OS crashed.
I believe -kernel-kqemu is still somewhat experimental on Windows host.
Redhat 7.2 guest/Fedora Core 4 host with normal kqemu is slower
than -no-kqemu. Why ?
Have you got your tmpfs set up correctly so qemu can place its
Sent: Tuesday, March 28, 2006 6:30 AM Fabrice Bellard wrote:
> Hi,
>
> I just released a new version of kqemu which fixes some recently
> discovered issues. The fixes are the following:
>
> - Support for guest Linux kernels compiled with gcc >= 3.3
>
> - x86_64 host support is working again (only
Fabrice Bellard wrote:
Hi,
I just released a new version of kqemu which fixes some recently
discovered issues. The fixes are the following:
- Support for guest Linux kernels compiled with gcc >= 3.3
Tested with 2.4.26 & 2.6.16 - gcc-3.2, gcc-3.3, gcc-3.4 & gcc-4.0.2
Win2k-SP3, Win2k-SP4, W
Andrew Barr wrote:
I'm running a Windows 2000 SP4 guest on a Linux 2.6.16 host with Qemu CVS and
kqemu 1.3.0pre3. I am trying to use -kernel-kqemu. I have been allocating 256
MB of RAM to my guest (out of 768 MB total) and I have found that using that
amount of memory with -kernel-kqemu causes
21 matches
Mail list logo
