On Thursday 15 March 2007 21:55, Laurent Desnogues wrote:
> Paul Brook a écrit :
> > I suggest you check again. I'm fairly sure the arm926 implements the Base
> > Restored abort model.
>
> Yes, but arm7 is Based Updated IIRC. What particular implementation
> does Qemu target?
Qemu currently emula
Paul Brook a écrit :
I suggest you check again. I'm fairly sure the arm926 implements the Base
Restored abort model.
Yes, but arm7 is Based Updated IIRC. What particular implementation
does Qemu target?
There are so many IMPLEMENTATION DEFINED and UNPREDICTABLE in the
architecture (that are
On 3/15/07, Paul Brook <[EMAIL PROTECTED]> wrote:
> > This is still wrong.
>
> So, is this a known bug?
Still wrong implies it's a bug, and your patch does not fix it properly.
I know that...
I was not clear.. sorry...
what I mean is: do you agree that there was a bug in these instructions?
> > This is still wrong.
>
> So, is this a known bug?
Still wrong implies it's a bug, and your patch does not fix it properly.
> > The writeback must happen after the load.
>
> We code like this because
> - we didn't find this restriction in arm reference manual
It's the Abort model section you
Hi Paul,
On 3/15/07, Paul Brook <[EMAIL PROTECTED]> wrote:
On Thursday 15 March 2007 19:35, Lauro Ramos Venancio wrote:
> Qemu-arm is wrongly executing post-indexed loads when Rm and Rd are
> the same register. For example:
>
> ldr r0, [r1], +r0
>
> Current behavior:
> r0 <- [r1]
> r1 <- r1 + r0
On Thursday 15 March 2007 19:35, Lauro Ramos Venancio wrote:
> Qemu-arm is wrongly executing post-indexed loads when Rm and Rd are
> the same register. For example:
>
> ldr r0, [r1], +r0
>
> Current behavior:
> r0 <- [r1]
> r1 <- r1 + r0
>
> Expected behavior:
> addr <- r1
> r1 <- r1 + r0
> r0 <- [
Now sending the attachment. :)
Lauro
On Thu, 2007-03-15 at 16:35 -0300, Lauro Ramos Venancio wrote:
> Qemu-arm is wrongly executing post-indexed loads when Rm and Rd are
> the same register. For example:
>
> ldr r0, [r1], +r0
>
> Current behavior:
> r0 <- [r1]
> r1 <- r1 + r0
>
> Expected beh
Qemu-arm is wrongly executing post-indexed loads when Rm and Rd are
the same register. For example:
ldr r0, [r1], +r0
Current behavior:
r0 <- [r1]
r1 <- r1 + r0
Expected behavior:
addr <- r1
r1 <- r1 + r0
r0 <- [addr]
The attached patch fixes this bug. Patched by me and Rodrigo Vivi.
This patch
Rob Landley <[EMAIL PROTECTED]> wrote:
> On Tuesday 13 March 2007 10:25 am, Ben Taylor wrote:
> > However, it's very wax-on, wax-off kind of thing. Without the patch,
> > arm-test and mips-test crash. With the patch, I can run both tests.
>
> Could we get a reproduction sequence for the c
Hello list
"Sorry if you receive double post, I don't be sure you reveived the
intial post. "
We would use qemu and a target Linux platform with CDC Ethernet
equipment.
The host is Linux or Windows with libusb.
When The device is plugged to the target system, the usb0 network
interface is
On Tuesday 13 March 2007 10:25 am, Ben Taylor wrote:
> However, it's very wax-on, wax-off kind of thing. Without the patch,
> arm-test and mips-test crash. With the patch, I can run both tests.
Could we get a reproduction sequence for the crashes please?
Rob
--
Vista: Windows Millenium Second
Paul Brook wrote:
Whereas I think the single easiest way to increase the user base would be to
merge the kvm patches.
This is good to hear. I should really have submitted patches to
qemu-devel long ago, but have run out of cycles. In addition, I am a
little concerned about the kvm user
Hello,
I came to the same solution after testing qemu on several machines.
The debian packages seem to have this Problem too.
Thanks
On Do, Mär 15, 2007 at 03:58:52 +0400, Brad Campbell wrote:
> Halim Sahin wrote:
> >Hello,
> >Is the cvs-repo of qemu down?
> >cvs -z3 -d:pserver:[EMAIL PROTECTED
> Subsequent releases of the branch would contain no functionality
> enhancements, but just bug fixes, with the eventual aim of achieving
> 'it just works' status for any x86/x86_64 guest I try to install/run.
> I know that's a tall order, and that 0.9.0 may not be able to supply
> that for all gue
On Thursday 15 March 2007 13:48, Anthony Liguori wrote:
> I'm not necessarily sure I agree that a stable branch is the best thing
> to have (verses aiming for never introducing regressions).
Aiming for no regressions is a worthy aim, but I believe unachieveable
in a project of any size. For sure
Julian Seward wrote:
>
> Something similar happened to me. At first I thought it was a hardware
> (host) problem and so do not have good details - this is from memory.
I had trouble (disk access errors when installing Debian/mipsel) with a
5 GB qcow2 image with only some hundred MB of payload. I
I'm not necessarily sure I agree that a stable branch is the best thing
to have (verses aiming for never introducing regressions).
I do agree that a bug tracker would be terribly useful for tracking
regressions. Bug trackers quickly get out of hand though unless someone
spends a lot of time k
Halim Sahin wrote:
Hello,
Is the cvs-repo of qemu down?
cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/qemu co
qemu
gives me a timeout after a few minutes.
The qemu release 0.9.0 does not work for me.
1. DMA not activable in guest
2. kernel-kqemu causes kernel panic (not the debian package)
3.
I am a great fan of QEMU, and have used it more or less continuously
for the past 2+ years. Over that time I've installed and operated
various Linux and Windows guests with varying degrees of success.
The recently released 0.9.0 seems a big step forward in the
stability/usability department, whi
Hello,
Is the cvs-repo of qemu down?
cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/qemu co
qemu
gives me a timeout after a few minutes.
The qemu release 0.9.0 does not work for me.
1. DMA not activable in guest
2. kernel-kqemu causes kernel panic (not the debian package)
3. The shutdown does not
Something similar happened to me. At first I thought it was a hardware
(host) problem and so do not have good details - this is from memory.
- 0.9.0, binary build from qemu.org
- i386 openSUSE 10.2 host
- RedHat 8 guest
- .qcow2 image, max size 8GB
- using the Accelerator but not -kernel-kqemu
Hi,
Small addition to my previous mail:
The shutdown doesn't work too.
Last message is system halted but qemu does not shut down.
Best regards
Halim
--
Halim Sahin
E-Mail:
halim.sahin (at) t-online.de
___
Qemu-devel mailing
Hello,
On Do, Mär 15, 2007 at 10:21:14 +0100, Aurelien Jarno wrote:
> Halim Sahin a écrit :
> > 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.
> >>> T
Halim Sahin a écrit :
> 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 new
Hello,
Now i tried the newest kqemu module under sarge with kernel 2.6.15 as
host and all works fine.
The big question is now why does the same vm not work under the
qemu host with kernel 2.6.18 under debian testing?
Now I.ll try qemu 0.9.0 under my stable sarge system.
Any Ideas what to d
On 3/15/07, Halim Sahin <[EMAIL PROTECTED]> wrote:
Hello,
On Thu, Mar 15, 2007 at 09:14:46AM +0100, Christian MICHON wrote:
> is it on a freshly created qemu image, or one created with qemu
> <= 0.8.2 ?
0.8.2 was used to create the image
>
> what is the format of the qemu image ? raw, qcow, qcow
Hello,
On Thu, Mar 15, 2007 at 09:14:46AM +0100, Christian MICHON wrote:
> is it on a freshly created qemu image, or one created with qemu
> <= 0.8.2 ?
0.8.2 was used to create the image
>
> what is the format of the qemu image ? raw, qcow, qcow2 ?
Raw
>
> right now (and I'm on windows hosts),
is it on a freshly created qemu image, or one created with qemu
<= 0.8.2 ?
what is the format of the qemu image ? raw, qcow, qcow2 ?
right now (and I'm on windows hosts), latest qemu and 0.9.0
work well. Most of the pb I see with kernel-kqemu are
time out on hdc (cdrom) if I boot on hda with lin
28 matches
Mail list logo