On Wed, Jan 10, 2018 at 10:34:18AM +, Peter Maydell wrote:
> On 10 January 2018 at 08:57, Steven Seeger
> wrote:
> > Sorry for another post. I did a bisect and found what is the bad commit for
> > me:
> >
> > 044897ef4a22af89aecb8df509477beba0a2e0ce is the first bad commit
> > commit 044897ef4
Thanks I will start posting over there a bit later when I have some
free time.
Original Message
Subject: Re: [Qemu-discuss] ppc and icount
From: Peter Maydell <[1]peter.mayd...@linaro.org>
Date: Wed, January 10, 2018 1:35 pm
To: [2]alar...@ddci.com
On 10 January 2018 at 16:42, wrote:
> "Qemu-discuss" wrote on
> 01/10/2018 10:27:32 AM:
>
>> When I have icount on, I see one character sent every 40 ms of
>> QEMU_CLOCK_VIRTUAL time. This is why it's so slow. If I change to
>> QEMU_CLOCK_VIRTUAL_RT then it runs "fast."
>
> Steven, this sounds s
"Qemu-discuss" wrote on
01/10/2018 10:27:32 AM:
> When I have icount on, I see one character sent every 40 ms of
> QEMU_CLOCK_VIRTUAL time. This is why it's so slow. If I change to
> QEMU_CLOCK_VIRTUAL_RT then it runs "fast."
Steven, this sounds similar to an issue I raised early last year.
I removed the commit that caused the icount related error and continued to
run. What I'm observing is that I have modified the serial.c file to have a
timer to set a delay between transmit of characters. VxWorks has always had
(and they will not fix) a bug in their 16550 uart code where if the u
On 10 January 2018 at 08:57, Steven Seeger
wrote:
> Sorry for another post. I did a bisect and found what is the bad commit for
> me:
>
> 044897ef4a22af89aecb8df509477beba0a2e0ce is the first bad commit
> commit 044897ef4a22af89aecb8df509477beba0a2e0ce
> Author: Richard Purdie
> Date: Mon Dec 4
Sorry for another post. I did a bisect and found what is the bad commit for
me:
044897ef4a22af89aecb8df509477beba0a2e0ce is the first bad commit
commit 044897ef4a22af89aecb8df509477beba0a2e0ce
Author: Richard Purdie
Date: Mon Dec 4 22:25:43 2017 +
target/ppc: Fix system lockups caused
On Tuesday, January 9, 2018 5:29:07 PM EST Peter Maydell wrote:
> You should also check whether icount mode works with upstream
> QEMU's standard powerpc boards -- if so, then that suggests
> your local changes are the issue; if not, then the problem is
> with upstream QEMU, and we can look at fix
On Tuesday, January 9, 2018 5:29:07 PM EST Peter Maydell wrote:
> The abort cares about all kinds of CPU interrupts (which includes
> some kinds of internal things). These are not supposed to happen
> unexpectedly when in icount mode. If you run under gdb you can
> get a backtrace of what it was th
Peter Maydell wrote
of the CPU's external interrupt line.
>
> The abort cares about all kinds of CPU interrupts (which includes
> some kinds of internal things). These are not supposed to happen
> unexpectedly when in icount mode. If you run under gdb you can
> get a backtrace of wha
On 9 January 2018 at 20:41, Steven Seeger
wrote:
> I am working with a custom model powerpc board (750-based) and I am having an
> issue with icount (any shift value).
>
> First, upon the first execution of the rfi instruction, I get:
>
> qemu: fatal: Raised interrupt while not in I/O function
> N
I am working with a custom model powerpc board (750-based) and I am having an
issue with icount.
First, upon the first execution of the rfi instruction, I get:
qemu: fatal: Raised interrupt while not in I/O function
NIP 00030354 LR CTR XER CPU#0
MSR 1000 HID0 000
I am working with a custom model powerpc board (750-based) and I am having an
issue with icount (any shift value).
First, upon the first execution of the rfi instruction, I get:
qemu: fatal: Raised interrupt while not in I/O function
NIP 00030354 LR CTR XER CPU#0
MSR
13 matches
Mail list logo
