CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl blueswir107/04/08 06:29:06
Modified files:
linux-user : main.c
Log message:
Sparc32/64 CPU selection for user emulator
CVSWeb URLs:
On Sun, 2007-04-08 at 01:04 +0100, Thiemo Seufer wrote:
J. Mayer wrote:
[snip]
To give you an real example why arbitrary limits are not acceptable AT
ALL: I know an embedded Mips device (widely used !) with 2 CPU, 8 PIC
and about 500 IRQ sources.
Care to tell which one this is?
I'm
On Sun, 2007-04-08 at 09:49 +0200, J. Mayer wrote:
I'm sorry, I'm no sure I can (NDA rules).
Let's say it's a chips used in some consumer electronics products.
I gave this example to show that we cannot pre-determine any limit to
the number of PINs we have to manage, even if it's a poor
The main problem here is that the less one can do when collaborating to
a project is to respect others work.
Then nobody should ever commit anything that touch the code he's not in
charge without previously formally do a proposal, wait for reactions and
discuss, taking care of others remarks,
BTW, I have a small PREP test image that I can publish.
I am planning since some time to add to the QEMU web site an automatic
regression testing system which will automatically launch many OSes with
the current CVS version. I had no time to do it recently, but if no one
does it before I'll try
Wang Cheng Yeh wrote:
BTW, I have a small PREP test image that I can publish.
I am planning since some time to add to the QEMU web site an automatic
regression testing system which will automatically launch many OSes with
the current CVS version. I had no time to do it recently, but if no
Hi Atif,
In target-i386/translate.c, there are many variants of mov i.e.
case 0x89: /* mov Gv, Ev */
case 0xc7: /* mov Ev, Iv */
case 0x8b: /* mov Ev, Gv */
case 0x8e: /* mov seg, Gv */
That's true. I forgot the fact that mov %eax,%eax can be both:
0x89 0xC0
0x8B 0xC0
It's up to the
J. Mayer wrote:
[snip]
Mr Paul Brook did break the PREP and heathrow machines while doing
changes in the PCI code. There were some posts on this list reporting
this and he never even tried to fix what he broke. And now he's
complaining I cannot test as it does not work. Looks like a bad joke,
J. Mayer wrote:
On Sun, 2007-04-08 at 01:04 +0100, Thiemo Seufer wrote:
J. Mayer wrote:
[snip]
To give you an real example why arbitrary limits are not acceptable AT
ALL: I know an embedded Mips device (widely used !) with 2 CPU, 8 PIC
and about 500 IRQ sources.
Care to tell
On Sun, 2007-04-08 at 15:11 +0100, Thiemo Seufer wrote:
J. Mayer wrote:
[snip]
Mr Paul Brook did break the PREP and heathrow machines while doing
changes in the PCI code. There were some posts on this list reporting
this and he never even tried to fix what he broke. And now he's
On Sun, 2007-04-08 at 15:41 +0100, Thiemo Seufer wrote:
J. Mayer wrote:
On Sun, 2007-04-08 at 01:04 +0100, Thiemo Seufer wrote:
J. Mayer wrote:
[snip]
To give you an real example why arbitrary limits are not acceptable AT
ALL: I know an embedded Mips device (widely used !) with 2
Hi all,
I have a huge list of operating systems (both closed and open source, that
works and that doesn't work under QEMU) that can be used to check that QEMU
doesn't broke (or even, that it corrects a non-working state).
I've already discussed that with Fabrice.
And I think it is better to
The crashs are caused by transmit descriptors with packet sizes
larger than the buffer which is defined in the driver. Using netperf
or rsync will always result in a buffer overflow and crash QEMU
with the current eepro100 driver.
Up to now I could not find the reason for these large packet
I'm experimenting a bit with QEMU and am in need of a way to save and
restore X86 CPU state including the pc so that the processor state can
be rolled back to re execute from the previous point. I've found the
functions cpu_x86_fsave and cpu_restore_state but do not understand
them well enough
Hi Eduardo,
Thanks a lot for your help. I really appreciate it. I have added the
functionality that I wanted.
By the way, Is there any documentation that can help me better understand
the QEMU source code?
Regards,
Atif
On 4/8/07, Eduardo Felipe [EMAIL PROTECTED] wrote:
Hi Atif,
In
2) I don't like hiding pointers in types, so I would use for example
'QEMUSignal *' instead of 'qemu_irq'.
FWIW I did it this way so that devices are agnostic about whether it was
implemented as a pointer or an integer index.
Paul
Mr Paul Brook did break the PREP and heathrow machines while doing
changes in the PCI code. There were some posts on this list reporting
this and he never even tried to fix what he broke. And now he's
complaining I cannot test as it does not work. Looks like a bad joke,
no ?
AFAIK PPC
It doesn't fullfil the requirements for an automated testing,
however, it is a good idea, but not inside the plannings I proposed.
El 08/04/2007, a las 23:07, Eduardo Felipe escribió:
But that required some macro interface click at x,y, wait some
seconds,
press 'k' key, that is not
On Sunday 08 April 2007, Paul Brook wrote:
I stand by my original statement.
A machine that requires building a custom kernel, maybe hacking a
bootloader, and creating a bootable filesystem from scratch is untestable.
seems reasonable to me
-mike
pgpDRIrvITBvj.pgp
Description: PGP signature
On April 08 at 21:04 EDT, Anthony Liguori hastily scribbled:
Thomas Tuttle wrote:
+if (x_position vs-ds-width) x_position = vs-ds-width;
+if (y_position vs-ds-height) y_position = vs-ds-height;
+if (x_position + w = vs-ds-width) w = vs-ds-width - x_position;
+if
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 07/04/09 02:01:58
Modified files:
hw : pl190.c
Log message:
ARM IRQ fix.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pl190.c?cvsroot=qemur1=1.2r2=1.3
21 matches
Mail list logo
