On 7/26/06, ZIGLIO, Frediano, VF-IT <[EMAIL PROTECTED]> wrote:
Hi, as expected 0.8.2 make windows 64 works. There is however a smallproblem with network card. Windows 64 do not support old ne card so Iused rtl8139. It seems that 8139plus card make windows enter in an
infinite loop at shutdown. Cha
I'm working on some custom emulated hardware to integrate with qemu's full pc emulation ( i guess you could call it a new target, but really just some mods of the x86 )..
I am curious if there's a way I could simulate counting scanlines. Basically a small piece of the chipset I'm implementing has
Thanks for your help!! That goes for all the people who responded on the thread! :)
Turns out, I just didn't understand what the vmlinux part meant. Being totally new to linux, I just thought that was the required syntax for using gdb with qemu. I didn't realize it was supposed to be the name of t
I failed to compile qemu-0.8.2 under Solaris on SPARC Sun-Blade-100 box.
Does this patch help?
It looks like Solaris gcc by default compiles in V8plus (or V8plusa?) mode,
not V8 or V9 as I assumed. V8 would be wrong.
_
Express y
I failed to compile qemu-0.8.2 under Solaris on SPARC Sun-Blade-100 box.
[EMAIL PROTECTED]: qemu-0.8.2 $ uname -a
SunOS cps222 5.10 Generic_118833-03 sun4u sparc SUNW,Sun-Blade-100
[EMAIL PROTECTED]: qemu-0.8.2 $ gcc -v
Reading specs from /opt/sfw/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.4/sp
On Wed, Jul 26 2006, Sven Köhler wrote:
> > Sounds good, so at least it's on its way :-)
> > It's on of those big items left on the TODO, so will be good to see go
> > in. Then one should implement an ahci host controller for queued
> > command support next...
> Or use the scsi
On Tue, 25 Jul 2006 15:15:49 -0500, Anthony Liguori wrote:
> @@ -448,15 +472,10 @@ sdl_too_old=no
>
> if test -z "$sdl" ; then
>
> -sdl_config="sdl-config"
> +sdl_config="${cross-prefix}sdl-config"
That should obviously be cross_prefix :-) Cross compiling SDL seems to be
pretty darn nasty a
> Sounds good, so at least it's on its way :-)
> It's on of those big items left on the TODO, so will be good to see go
> in. Then one should implement an ahci host controller for queued
> command support next...
Or use the scsi emulation :-)
>>> Ah, did not know that queueing
On Fri, Jul 21, 2006 at 02:21:21PM -0500, Anthony Liguori wrote:
> As far as I know, the big hurdle for QEMU and libvirt right now is not any
> GUI aspects (VNC would work just fine). It's interacting with QEMU. Xen
> provides an XML-RPC interface to managing instances whereas QEMU only
> really
On Wed, Jul 26 2006, Paul Brook wrote:
> On Wednesday 26 July 2006 13:23, Jens Axboe wrote:
> > On Wed, Jul 26 2006, Paul Brook wrote:
> > > > Sounds good, so at least it's on its way :-)
> > > > It's on of those big items left on the TODO, so will be good to see go
> > > > in. Then one should impl
> Sounds good, so at least it's on its way :-)
> It's on of those big items left on the TODO, so will be good to see go
> in. Then one should implement an ahci host controller for queued command
> support next...
Or use the scsi emulation :-)
Paul
___
On Wednesday 26 July 2006 13:23, Jens Axboe wrote:
> On Wed, Jul 26 2006, Paul Brook wrote:
> > > Sounds good, so at least it's on its way :-)
> > > It's on of those big items left on the TODO, so will be good to see go
> > > in. Then one should implement an ahci host controller for queued
> > > co
On Wed, Jul 26 2006, Paul Brook wrote:
> > Sounds good, so at least it's on its way :-)
> > It's on of those big items left on the TODO, so will be good to see go
> > in. Then one should implement an ahci host controller for queued command
> > support next...
>
> Or use the scsi emulation :-)
Ah,
Hello,
I'm using Qemu 0.8.2 on Microsoft Windows XP and the AltGr key doesn't seem
to work at all using windib (using directx support it works but the keyboard
mappig isn't correct, even forcing a keymap via -k option). I tried to press
AltGr+ but no output is produced. This is a real matter be
Hi,
On Wed, 26 Jul 2006, Johannes Schindelin wrote:
> On Wed, 26 Jul 2006, ZIGLIO, Frediano, VF-IT wrote:
>
> > -s = &d->rtl8139;
> > -
> > /* I/O handler for memory-mapped I/O */
> > s->rtl8139_mmio_io_addr =
> > cpu_register_io_memory(0, rtl8139_mmio_read, rtl8139_mmio_write
Hi,
On Wed, 26 Jul 2006, ZIGLIO, Frediano, VF-IT wrote:
> Just to make it happy I wrote this patch that add a rtl8139too card. It
> simply change pci revision id but use rtl8139 code.
Nice.
> -s = &d->rtl8139;
> -
> /* I/O handler for memory-mapped I/O */
> s->rtl8139_mmio_io_add
Hi,
as expected 0.8.2 make windows 64 works. There is however a small
problem with network card. Windows 64 do not support old ne card so I
used rtl8139. It seems that 8139plus card make windows enter in an
infinite loop at shutdown. Changing pci id from 0x20 to 0x10 (that is
use old 8139, not pl
ZIGLIO, Frediano, VF-IT wrote:
I use the patch to reduce image size. I use a RIP (repair is possible)
ISO image to boot a small Linux system where I can issue ntfswipe (or
any other wipe command). Than I can recompress image with qemu-img.
Yes, I do similar at the moment.
I just boot the win
>
> Avi Kivity wrote:
>
> >> This _looks_ like it would severely impact cpu load during a write.
> >> Have you done any testing to determine if this is likely
> to impact a
> >> normal usage scenario?
> >
> > Why would it? In most cases, the zero test would terminate quickly,
> > without acce
Avi Kivity wrote:
This _looks_ like it would severely impact cpu load during a write.
Have you done any testing to determine if this is likely to impact a
normal usage scenario?
Why would it? In most cases, the zero test would terminate quickly,
without accessing the entire cluster.
Good
Brad Campbell wrote:
ZIGLIO, Frediano, VF-IT wrote:
Hi,
well, this is not a definitive patch but it works. The aim is to be
able to wipe the disk without allocating entire space. When you wipe a
disk the program fill disk with zero bytes so disk image increase to
allocate all space. This just
>
> ZIGLIO, Frediano, VF-IT wrote:
> > Hi,
> > well, this is not a definitive patch but it works. The
> aim is to be
> > able to wipe the disk without allocating entire space. When
> you wipe a
> > disk the program fill disk with zero bytes so disk image increase to
> > allocate all space. Thi
ZIGLIO, Frediano, VF-IT wrote:
Hi,
well, this is not a definitive patch but it works. The aim is to be
able to wipe the disk without allocating entire space. When you wipe a
disk the program fill disk with zero bytes so disk image increase to
allocate all space. This just patch detect null byte
Hi,
well, this is not a definitive patch but it works. The aim is to be
able to wipe the disk without allocating entire space. When you wipe a
disk the program fill disk with zero bytes so disk image increase to
allocate all space. This just patch detect null byte writes and do not
write all zero
On Tue, Jul 25 2006, Fabrice Bellard wrote:
> Jens Axboe wrote:
> >On Tue, Jul 25 2006, Sven Köhler wrote:
> >
> >So the current thread-based async dma patch is really just the
> >wrong long term solution. A more long term solution is likely in
> >the works. It requires quite a bit of
25 matches
Mail list logo
