Hi Seth,
On 12/10/18 4:39 AM, Seth K wrote:
> Thank you all for help with my last patch. I found one more entry in my
> notes that could be a bug, or could be a misunderstanding on my part.
>
> The memory map in DocID15818 (Rev 15) datasheet says:
> ADC1 - ADC2 - ADC3: 0x40012000-0x400123FF
Thank you all for help with my last patch. I found one more entry in my
notes that could be a bug, or could be a misunderstanding on my part.
The memory map in DocID15818 (Rev 15) datasheet says:
ADC1 - ADC2 - ADC3: 0x40012000-0x400123FF
That suggests a size of 0x400 (they share that
On 8 October 2018 at 23:17, Stefano Stabellini wrote:
> I double-checked all the addresses and they are correct. For some reason
> after starting the guest, ATS12NSOPW starts to fail for
> ffc006f91628, which is the same virtual address corresponding to the
> same runstate region allocated in
Hi Peter,
I am chasing an address translation error, and it looks like it might be
a QEMU bug, because I cannot reproduce the problem on a physical board.
The issue is that a requested ATS12NSOPW translation in Xen is reported
as failing by QEMU, but actually the address is correct. The workflow
On 06/04/2016 16:59, Zir Blazer wrote:
>> On Tue, Apr 05, 2016 at 07:49:47PM -0300, Zir Blazer wrote:
>> > The bare minimum script that produces the warning, should be this:
>> > #!/bin/bash
>> > qemu-system-x86_64 \-m 1024M \-enable-kvm \-object
> iothread,id=iothread0 \-device
Recently I hear that the experimental x-data-plane feature from virtio-blk was
production-ready and that virtio-scsi also got support for it, so, after
finding what the new syntax is:
http://comments.gmane.org/gmane.comp.emulators.qemu/279118
...I decided to test it. After all, it was supposed
On 11/16/2015 08:44 PM, Toni Nedialkov wrote:
> There is some evidence to suggest that the instruction mulx rsp,rsp,rdx
> causes a segfault in QEMU.
>
> Was wondering if anyone would be kind enough to verify. And since I am
> not familiar with the bug reporting process, I am posting here.
>
>
On 11/17/2015 10:14 AM, John Snow wrote:
>
>
> On 11/16/2015 08:44 PM, Toni Nedialkov wrote:
>> There is some evidence to suggest that the instruction mulx rsp,rsp,rdx
>> causes a segfault in QEMU.
>>
>> Was wondering if anyone would be kind enough to verify. And since I am
>> not familiar with
There is some evidence to suggest that the instruction mulx rsp,rsp,rdx
causes a segfault in QEMU.
Was wondering if anyone would be kind enough to verify. And since I am not
familiar with the bug reporting process, I am posting here.
Thank you.
Ping?
> Consider the following circumstances:
>
> - An x86-64 multicore system is running with all cores set for long mode
> (EFER.LME and EFER.LMA set)
> - The OS decides to re-launch one of the AP CPUs using an INIT IPI
>
> According to the Intel architecture manual, an INIT IPI should
On 25/09/2015 01:26, Bill Paul wrote:
> The result of this is that if the CPU was in long mode and you do an INIT
> IPI,
> the CPU still has the EFER.LMA and EFER.LME bits set, even though it's not
> actually running in long mode anymore. It doesn't seem possible for the guest
> to get the
Consider the following circumstances:
- An x86-64 multicore system is running with all cores set for long mode
(EFER.LME and EFER.LMA set)
- The OS decides to re-launch one of the AP CPUs using an INIT IPI
According to the Intel architecture manual, an INIT IPI should reset the CPU
state
Hi,
I find a critical problem about pci devices migration
when we configure a pci device not assign the devfn. Qemu will
auto assign the devfn in function do_pci_register_device.
At the migration src end, When we hotplug two pci devices, such as virtio-net.
Qemu will assign devfn 4 (assumed
Fam Zheng f...@redhat.com wrote:
Bcc:
Subject: Re: [Qemu-devel] Possible bug in monitor code
Reply-To:
In-Reply-To: 52e0ec4b.7010...@grnet.gr
On Thu, 01/23 12:17, Stratos Psomadakis wrote:
On 01/23/2014 05:07 AM, Fam Zheng wrote:
On Wed, 01/22 17:53, Stratos Psomadakis wrote:
Hi,
we've
Luiz Capitulino lcapitul...@redhat.com wrote:
On Thu, 23 Jan 2014 19:23:51 +0800
Fam Zheng f...@redhat.com wrote:
Bcc:
Subject: Re: [Qemu-devel] Possible bug in monitor code
Reply-To:
In-Reply-To: 52e0ec4b.7010...@grnet.gr
On Thu, 01/23 12:17, Stratos Psomadakis wrote:
On 01
Hi all,
On 12:14 Fri 24 Jan , Stratos Psomadakis wrote:
On 01/23/2014 08:28 PM, Luiz Capitulino wrote:
Not yet, I may have some time tomorrow. How reproducible is it for
you?
We can trigger it (by following the steps described in the first mail)
consistently.
Another question:
On Wed, 22 Jan 2014 17:53:52 +0200
Stratos Psomadakis pso...@grnet.gr wrote:
Hi,
we've encountered a weird issue regarding monitor (qmp and hmp) behavior
with qemu-1.7 (and qemu-1.5). The following steps will reproduce the issue:
1) Client A connects to qmp socket with socat
2)
On 01/23/2014 05:07 AM, Fam Zheng wrote:
On Wed, 01/22 17:53, Stratos Psomadakis wrote:
Hi,
we've encountered a weird issue regarding monitor (qmp and hmp) behavior
with qemu-1.7 (and qemu-1.5). The following steps will reproduce the issue:
1) Client A connects to qmp socket with socat
Bcc:
Subject: Re: [Qemu-devel] Possible bug in monitor code
Reply-To:
In-Reply-To: 52e0ec4b.7010...@grnet.gr
On Thu, 01/23 12:17, Stratos Psomadakis wrote:
On 01/23/2014 05:07 AM, Fam Zheng wrote:
On Wed, 01/22 17:53, Stratos Psomadakis wrote:
Hi,
we've encountered a weird issue
On Thu, 23 Jan 2014 08:44:02 -0500
Luiz Capitulino lcapitul...@redhat.com wrote:
On Thu, 23 Jan 2014 19:23:51 +0800
Fam Zheng f...@redhat.com wrote:
Bcc:
Subject: Re: [Qemu-devel] Possible bug in monitor code
Reply-To:
In-Reply-To: 52e0ec4b.7010...@grnet.gr
On Thu, 01/23 12:17
On Thu, 23 Jan 2014 19:23:51 +0800
Fam Zheng f...@redhat.com wrote:
Bcc:
Subject: Re: [Qemu-devel] Possible bug in monitor code
Reply-To:
In-Reply-To: 52e0ec4b.7010...@grnet.gr
On Thu, 01/23 12:17, Stratos Psomadakis wrote:
On 01/23/2014 05:07 AM, Fam Zheng wrote:
On Wed, 01/22 17
On 01/23/2014 03:54 PM, Luiz Capitulino wrote:
On Thu, 23 Jan 2014 08:44:02 -0500
Luiz Capitulino lcapitul...@redhat.com wrote:
On Thu, 23 Jan 2014 19:23:51 +0800
Fam Zheng f...@redhat.com wrote:
Bcc:
Subject: Re: [Qemu-devel] Possible bug in monitor code
Reply-To:
In-Reply
:
Subject: Re: [Qemu-devel] Possible bug in monitor code
Reply-To:
In-Reply-To: 52e0ec4b.7010...@grnet.gr
On Thu, 01/23 12:17, Stratos Psomadakis wrote:
On 01/23/2014 05:07 AM, Fam Zheng wrote:
On Wed, 01/22 17:53, Stratos Psomadakis wrote:
Hi,
we've encountered a weird issue
Hi,
we've encountered a weird issue regarding monitor (qmp and hmp) behavior
with qemu-1.7 (and qemu-1.5). The following steps will reproduce the issue:
1) Client A connects to qmp socket with socat
2) Client A gets greeting message {QMP: {version: ..}
3) Client A waits (select on
On Wed, 01/22 17:53, Stratos Psomadakis wrote:
Hi,
we've encountered a weird issue regarding monitor (qmp and hmp) behavior
with qemu-1.7 (and qemu-1.5). The following steps will reproduce the issue:
1) Client A connects to qmp socket with socat
2) Client A gets greeting message
Hi folks !
I was debugging a problem with 16bpp support, when I found out that
my attempts at writing to the Hidden DAC Register were not working.
The reason was that I (well, cirrusdrmfb really) was doing the sequence
READ, READ, READ, READ, WRITE (to the DAC mask register), which should
have
Hi all,
I'm having some troubles with QEMU's hard disk images and may have bumped
into a bug. I'm trying to import data into my emulated MINIX, but somehow
it is truncated.
I successfully created a qemu-img called hda.img of 512 MB and installed
the latest version from MINIX on it. Trying
On Monday 01 August 2005 18:27, J.N. Herder wrote:
Hi all,
I'm having some troubles with QEMU's hard disk images and may have bumped
into a bug. I'm trying to import data into my emulated MINIX, but somehow
it is truncated.
I successfully created a qemu-img called hda.img of 512 MB and
28 matches
Mail list logo
