Re: [Qemu-devel] [PATCH] Reducing X communication bandwidth, take 2

[Julian Seward]

On Wednesday 14 March 2007 04:57, Mark Williamson wrote:
> > > Here is a somewhat revised version of a patch I first made nearly
> > > three years ago.  The original thread is
> >
> > The idea here is quite similar to what the VNC server does now.
> >
> > If this is desirable for SDL too, then perhaps we should find a way to
> > fold this into common code?
> >
> > Although, is there a compelling reason to use SDL over X instead of VNC?
>
> I sometimes do this sort of thing because it Just Works with no manual
> configuring of port forwarding etc.  I don't necessarily like to do it for
> extended usage but it is very convenient.

Yes.  VNC is all very nice (I use it a lot) but is hassle to set up,
what with making holes in firewalls and/or port forwarding etc.  This
patch has the "it just works" property.

In fact I obtained (by far) the best remote X performance by using both
this patch and making the remote X connection with 
"ssh -XC -o CompressionLevel=1".  The patch knocks out the majority of
the data, and the ssh compression squashed what remained by more than a
factor of 10.  Doing this it was hard to tell that QEMU was not running
locally.

J


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] Reducing X communication bandwidth, take 2

[Johannes Schindelin]

Hi,

On Wed, 14 Mar 2007, Julian Seward wrote:

> In fact I obtained (by far) the best remote X performance by using both 
> this patch and making the remote X connection with "ssh -XC -o 
> CompressionLevel=1".  The patch knocks out the majority of the data, and 
> the ssh compression squashed what remained by more than a factor of 10.  
> Doing this it was hard to tell that QEMU was not running locally.

This should be helped by the VNC encodings Tight, ZRLE, and for multimedia 
content (movies) the upcoming ZYWRLE encoding.

But I agree that your idea to reduce X communication makes tons of sense, 
since not everybody wants to use VNC.

Ciao,
Dscho



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Regarding VNC (was:Re: [Qemu-devel] [PATCH] Reducing X)

[Hetz Ben Hamo]

Hi,


This should be helped by the VNC encodings Tight, ZRLE, and for multimedia
content (movies) the upcoming ZYWRLE encoding.


Is someone planning to integrate Hitachi's VNC ZYWRLE extension to
QEMU's VNC implementation?

Code is at: http://mobile.hitachi-system.co.jp/publications/ZYWRLE/

Thanks,
Hetz
--
Skepticism is the lazy person's default position.
Visit my blog (hebrew) for things that (sometimes) matter:
http://wp.dad-answers.com


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: Regarding VNC (was:Re: [Qemu-devel] [PATCH] Reducing X)

[Johannes Schindelin]

Hi,

On Wed, 14 Mar 2007, Hetz Ben Hamo wrote:

> > This should be helped by the VNC encodings Tight, ZRLE, and for 
> > multimedia content (movies) the upcoming ZYWRLE encoding.
> 
> Is someone planning to integrate Hitachi's VNC ZYWRLE extension to 
> QEMU's VNC implementation?
> 
> Code is at: http://mobile.hitachi-system.co.jp/publications/ZYWRLE/

For a few weeks now I tried to find the time to integrate it in 
LibVNCServer, so I am very unlikely to integrate it into QEmu.

Ciao,
Dscho



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] problems using sockets inside qemu code

[Marius Monton]

Hi again,

I'm using sockets inside qemu code for my work on SystemC + qemu simulation.
I've implemented a TCP client inside qemu code to connect to an
application (TCP server) outside QEMU (all SystemC stuff).
Almost all is working fine, but sometimes receiving data fails with an
"Interrupted system call" on perror (errno = EINTR).
When testing socket code with no QEMU works fine...

Any idea? I don't knot what to do

Thanks
-- 
Màrius Montón i Macián   [EMAIL PROTECTED]
  http://cephis.uab.es

Hardware Engineer
CEPHIS
Centre de Prototips i Solucions Hardware-Software
Dep. Microelectrònica i Sistemes Electrònics
ETSE - Universitat Autònoma de Barcelona (UAB)  Phone: +34 935 813 534
Fax: +34 935 813 033
QC-2090D. ETSE. Campus UAB.
080193 Bellaterra


begin:vcard
fn;quoted-printable:M=C3=A0rius Mont=C3=B3n
n;quoted-printable;quoted-printable:Mont=C3=B3n;M=C3=A0rius
org:CEPHIS-UAB
adr:Campus de la Autonoma;;QC-2090D. ETSE;Bellaterra;Barcelona;08193;Spain
email;internet:[EMAIL PROTECTED]
title:System Engineer
tel;work:+34935813534
url:http://cephis.uab.cat
version:2.1
end:vcard


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] problems using sockets inside qemu code

[Paul Brook]

On Wednesday 14 March 2007 14:23, Marius Monton wrote:
> Hi again,
>
> I'm using sockets inside qemu code for my work on SystemC + qemu
> simulation. I've implemented a TCP client inside qemu code to connect to an
> application (TCP server) outside QEMU (all SystemC stuff).
> Almost all is working fine, but sometimes receiving data fails with an
> "Interrupted system call" on perror (errno = EINTR).
> When testing socket code with no QEMU works fine...

I suggest you read the recv(1) manpage. Retry the command.

Paul


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] scsi patch

[王成業]

--- ../../tmp/qemu-0.9.0/hw/lsi53c895a.c2007-02-06 07:01:
54.0 +0800
+++ lsi53c895a.c2007-03-08 20:50:03.094098835 +0800
@@ -251,7 +251,7 @@
uint32_t ia;
uint32_t sbc;
uint32_t csbc;
-uint32_t scratch[13]; /* SCRATCHA-SCRATCHR */
+uint32_t scratch[18]; /* SCRATCHA-SCRATCHR */

/* Script ram is stored as 32-bit words in host byteorder.  */
uint32_t script_ram[2048];
@@ -1038,7 +1038,7 @@
op0 |= op1;
break;
case 3: /* XOR */
-op0 |= op1;
+op0 ^= op1;
break;
case 4: /* AND */
op0 &= op1;
@@ -1765,7 +1765,7 @@
lsi_reg_writeb(s, addr, val & 0xff);
lsi_reg_writeb(s, addr + 1, (val >> 8) & 0xff);
lsi_reg_writeb(s, addr + 2, (val >> 16) & 0xff);
-lsi_reg_writeb(s, addr + 2, (val >> 24) & 0xff);
+lsi_reg_writeb(s, addr + 3, (val >> 24) & 0xff);
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] QCOW(2) image corruption under QEMU 0 .9.0 reproducible

[herbie hancock]

Hello, i had also a reproducible disk crash:
info of the last good image, size is about 3,5GB

image: debian4_0.dsk file format: qcow2 virtual size: 16G (16777216000 bytes) 
disk size: 3.3G cluster_size: 4096

as soon as the image increase to a size of about 7,9 GB the emulator locks up, 
and after a restart the the image is not readable any more.
the start of the image is filled with zeros, the signature of the file  at the 
start (QFI )  is overwritten.

I tried it two times, started with a intact image with the size above and in 
both times the image was corrupted.

Host: WIN2K
Guest: Debian 4.0 Etch.
qemu: 0.90 (build date 2007-02-19, the version that comes with 
http://www.davereyn.co.uk/qem/setupqemuk40.exe)

I tested the image above with virtualbox (installed backup of the qemu disk 
with acronis trueimage and bart pe boot cd) , 
started with the above image, and the problems are gone, image is now filled 
with more than 9GB, no problem so far.

I never experienced such a bad problem with qemu before, maybe it is a problem 
with qcow2 format ?

Bye
HR
_
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=0066



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] [SPARC] SlavIO interrupt controller fix

[Aurelien Jarno]

Hi all,

I have finally been able to fix the Linux kernel crash that occurs on
the Sparc target (sun4m) when doing intensive disk I/O (see the dmesg 
log below).

slavio_pic_set_irq() in slavio_intctl.c calls slavio_check_interrupts()
when an interrupt is activated, but also when interrupt is deactivated.
This can cause in very rare conditions a spurious interrupt that 
perturbates the ESP driver that leads to a kernel crash. 

>From what I have been able to trace, it occurs when an interrupt is 
being serviced, and an interrupt with a lower level is being cleared 
before the interrupt routine in the target disables the first interrupt.
To have a bad effect on the ESP driver, it should also occur when a 
DMA transfer is scheduled. That explains why this bug is not so easy 
to reproduce (it usually occurs between half an hour and two hours under
intensive disk I/O, and up to 24 hours with very few disk I/O), though
it is very annoying.

Note that all other functions from this file that activate and 
deactivate interrupts only call slavio_check_interrupts() in  interrupt
activation cases, so they are already correct.

The patch below fixes the problem. With this patch I am currently running
a Sparc target with intensive I/O disk for 24 hours without crash.

Cheers,
Aurelien


esp0: !BSERV after data, probably to msgout
esp0: Aborting command
esp0: dumping state
esp0: dma -- cond_reg addr
esp0: SW [sreg<00> sstep<04> ireg<18>]
esp0: HW reread [sreg<83> sstep<00> ireg<10>]
esp0: current command [tgt<00> lun<00> pphase cphase]
esp0: disconnected
esp0: Aborting command
esp0: dumping state
esp0: dma -- cond_reg addr
esp0: SW [sreg<00> sstep<04> ireg<18>]
esp0: HW reread [sreg<03> sstep<00> ireg<10>]
esp0: current command [tgt<00> lun<00> pphase cphase]
esp0: disconnected
esp0: Resetting scsi bus
esp0: SCSI bus reset interrupt
Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = 000d
tsk->{mm,active_mm}->pgd = fc048800
  \|/  \|/
  "@'/ ,. \`@"
  /_| \__/ |_\
 \__U_/
apt-get(4250): Oops [#1]
PSR: 04400fc6 PC: fe61f128 NPC: fe61f12c Y: Not tainted
PC: 
%G: f2cb4000   0014 fd0da000   0020  f2cb4000 0001
%O: fe620800 f79d8800  0010 0008  f00d8eac f0234000  f2cb5b18 fe61edd0
RPC: 
%L: f79f3600    f7956500   ea7afb00  f3004000 00989680
%I: f021529c       fff0  f2cb5b80 fe61de10
Caller[fe61de10]: esp_work_bus+0x64/0x6c [esp]
Caller[fe61f7e8]: esp_intr+0x1e0/0x310 [esp]
Caller[f0013160]: handler_irq+0x94/0xd4
Caller[f0010bd8]: patch_handler_irq+0x8/0x24
Caller[f019b744]: here+0x18/0x90
Caller[f019c538]: do_nanosleep+0x44/0x88
Caller[f0046af8]: hrtimer_nanosleep+0x30/0x130
Caller[f0046c74]: sys_nanosleep+0x7c/0x94
Caller[f0011634]: syscall_is_too_hard+0x3c/0x40
Caller[5035a36c]: 0x5035a374
Instruction DUMP: c22420ec  8400a014  c42420e8  c22420e4  c200a00c  
c22420e0  c20e203a  82086007
Kernel panic - not syncing: Aiee, killing interrupt handler!
 <0>Press Stop-A (L1-A) to return to the boot prom



--- hw/slavio_intctl.c  2007-02-06 00:01:54.0 +0100
+++ hw/slavio_intctl.c  2007-03-14 13:50:18.0 +0100
@@ -293,6 +293,7 @@
if (level) {
s->intregm_pending |= mask;
s->intreg_pending[s->target_cpu] |= 1 << pil;
+   slavio_check_interrupts(s);
}
else {
s->intregm_pending &= ~mask;
@@ -300,7 +301,6 @@
}
}
 }
-slavio_check_interrupts(s);
 }
 
 void slavio_pic_set_irq_cpu(void *opaque, int irq, int level, unsigned int cpu)

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] -kernel-kqemu option causes kernel-panic

[Halim Sahin]

Hello list,

I experienced several problems with qemu under linux using kernel 
2.6.18.
The guest system is a debian testing, the host a debian unstable.
kqemu is the newest version from www.qemu.org.
The guest can not start if I give -kernel-kqemu.
The last message is kernel panic.

Another problem is the performance of the guest harddisk.
There is no ide dma aktivated and hdparm fails to aktivate it.

If I try to shutdown the guest, I am only getting system halted but the 
qemu did not shutdown.

What can I do to solve this?
Thanks
a  lot.
Halim




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] -kernel-kqemu option causes kernel-panic

[Brad Campbell]

Halim Sahin wrote:

Hello list,

I experienced several problems with qemu under linux using kernel 
2.6.18.

The guest system is a debian testing, the host a debian unstable.
kqemu is the newest version from www.qemu.org.
The guest can not start if I give -kernel-kqemu.
The last message is kernel panic.

Another problem is the performance of the guest harddisk.
There is no ide dma aktivated and hdparm fails to aktivate it.

If I try to shutdown the guest, I am only getting system halted but the 
qemu did not shutdown.


What version of qemu are you using ?

Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] -kernel-kqemu option causes kernel-panic

[Halim Sahin]

On Do, Mär 15, 2007 at 11:12:41 +0400, Brad Campbell wrote:
> Halim Sahin wrote:
> >Hello list,
> >
> >I experienced several problems with qemu under linux using kernel 
> >2.6.18.
> >The guest system is a debian testing, the host a debian unstable.
> >kqemu is the newest version from www.qemu.org.
> >The guest can not start if I give -kernel-kqemu.
> >The last message is kernel panic.
> >
> >Another problem is the performance of the guest harddisk.
> >There is no ide dma aktivated and hdparm fails to aktivate it.
> >
> >If I try to shutdown the guest, I am only getting system halted but the 
> >qemu did not shutdown.
> 
> What version of qemu are you using ?
I am using qemu 0.9.0 but this problem happends with 0.8.2 too.

Halim




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel