On Sun, 9 Jun 2013, Thomas Schwinge wrote:
> In my reading of the relevant documents, the latter change is not correct
> for o32, and empirically has "interesting" effects on the glibc math
> testsuite, for example. Keeping the FR register unset for o32 I'm
> proposing to fix with the following p
On Thu, 13 Sep 2012, Jan Kiszka wrote:
> > I've also just skimmed parts of the 8254 section of "The Indispensable PC
> > Hardware Book", by Hans-Peter Messmer, Copyright 1994 Addison-Wesley,
> > although I probably ought to read it more carefully.
>
> http://download.intel.com/design/archives/per
On Wed, 12 Sep 2012, Matthew Ogilvie wrote:
> Also, how big of a concern is a very rare gained or lost IRQ0
> actually? Under normal conditions, I would expect this to at most
> cause a one time clock drift in the guest OS of a fraction of
> a second. If that only happens when rebooting or migra
On Mon, 10 Sep 2012, Matthew Ogilvie wrote:
> > > This bug manifested itself when the guest was Microport UNIX
> > > System V/386 v2.1 (ca. 1987), because it would sometimes mask
> > > off IRQ14 in the slave IMR after it had already been asserted.
> > > The master would still try to deliver an int
On Sun, 9 Sep 2012, Matthew Ogilvie wrote:
> This bug manifested itself when the guest was Microport UNIX
> System V/386 v2.1 (ca. 1987), because it would sometimes mask
> off IRQ14 in the slave IMR after it had already been asserted.
> The master would still try to deliver an interrupt even thoug
On Mon, 10 Sep 2012, Avi Kivity wrote:
> >>> So the only difference between edge triggered and level triggered
> >>> is in the leading edge, with no difference in the trailing edge.
> >>
> >> Hard to believe. So an edge while cpu interrupts are disabled is ignored?
Please note that x86 CPU's I
On Tue, 4 Sep 2012, Jan Kiszka wrote:
> >> What I'm trying to understand and translate from the description is
> >> rather "note that for inputs a high-to-low transition cancels the
> >> interrupt as in the level-triggered mode." This is surely not what we do
> >> right now. OTOH, I'm afraid that
On Mon, 3 Sep 2012, Jan Kiszka wrote:
> > - Qemu output (without this patch):
> > elcr=0c00 cmdRead ummask mask sti irq15 unmask DONE
> >
> > But on real hardware, the master seems to treat IRQ2 as level triggered,
That is not universally true, however in reality it does not matter, m
On Tue, 4 Sep 2012, Jan Kiszka wrote:
> What I'm trying to understand and translate from the description is
> rather "note that for inputs a high-to-low transition cancels the
> interrupt as in the level-triggered mode." This is surely not what we do
> right now. OTOH, I'm afraid that switching to
Hi Andreas,
> > I find quilt patches easier to manage when I need to reorder them,
> > revert, manually edit the diffs (that I routinely do), etc. Perhaps I'm
> > just outdated, but that's the workflow I've found most efficient for me
> > while not disturbing anyone else. I've used quilt pat
Andreas,
> >> Actually there were better patches for the same bug by Meador, including
> >> git-style rather than SVN patches and adding a helper to initialize it
> >> consistently at all call sites.
I find quilt patches easier to manage when I need to reorder them,
revert, manually edit the di
On Thu, 9 Aug 2012, Phil Staub wrote:
> > > > > For this purpose the usual approach is to follow up to the patch
> > > > > mail saying "Ping" and giving a url to the patch in patchwork,
> > > > > like this one:
> > > > > http://patchwork.ozlabs.org/patch/163705/
> > > > >
> > > > > Eventually som
On Fri, 8 Jun 2012, Andreas Färber wrote:
> >>> The problem was seen with the 24Kf MIPS32r2 processor in user emulation.
> >>>
> >>> The new approach prevents system and user emulation from diverging -- all
> >>> the hflags state is initialized in one place now.
> >>
> >> I submitted a patch
On Fri, 8 Jun 2012, Meador Inge wrote:
> > The problem was seen with the 24Kf MIPS32r2 processor in user emulation.
> > The new approach prevents system and user emulation from diverging -- all
> > the hflags state is initialized in one place now.
>
> I submitted a patch to fix this issue and
rect to me, and the same
calculation is already used in exception_resume_pc applied to ordinary,
Debug and NMI exceptions. This code on the other hand applies to reset
exceptions and instruction restarts in the context of I/O.
Signed-off-by: Maciej W. Rozycki
---
Sent on behalf of Nathan, w
ate the comment accordingly was missed and not
propagated. Here's an update to remove the obsolete and now misleading
comment.
Signed-off-by: Maciej W. Rozycki
---
Mostly obvious, please apply.
Maciej
qemu-mips16-jal.diff
Index: qemu-git-trunk/tar
diverging -- all
the hflags state is initialized in one place now.
Signed-off-by: Maciej W. Rozycki
---
This is effectively a follow-up to Nathan's FCR0 fix -- please apply.
Maciej
qemu-mips-hflags.patch
Index: qemu-git-trunk/target-mips/
fpu_init
setup, then proceeds to reinitialize all the CP0 registers...but not
FCR0."
I have verified this change with system emulation running the GDB test
suite for the mips-sde-elf target (o32, big endian, 24Kf CPU emulated),
there were 55 progressions and no regressions.
Signed-off-b
The CP1 FIR register is read-only, ignore any write attempts from the GDB
stub.
Signed-off-by: Maciej W. Rozycki
---
Definitely obvious, please apply.
Maciej
qemu-mips-fir.diff
Index: qemu-git-trunk/gdbstub.c
===
--- qemu
x80004d34 in _start ()
5: x/i $pc
=> 0x80004d34 <_start+380>: mtc0t1,c0_config
(gdb)
0x80004d34 in _start ()
5: x/i $pc
=> 0x80004d34 <_start+380>: mtc0t1,c0_config
(gdb)
0x80004d34 in _start ()
5: x/i $pc
=> 0x80004d34 <_start+380>: mtc0t1,c0_confi
_libc_init_array+132>: lw v0,0(s1)
(gdb)
0x8000b46c in __libc_init_array ()
4: /x $ra = 0x8000b460
2: x/i $pc
=> 0x8000b46c <__libc_init_array+136>: lw ra,28(sp)
(gdb)
0x8000b470 in __libc_init_array ()
4: /x $ra = 0x8000891c
2: x/i $pc
=> 0x8000b470 <__libc_init_array+14
setting Cause to 0x300 and
then Status to 0x201, and then making a few single steps, but that didn't
cause the interrupt exception to be taken for some reason. That does not
appear to be a problem with my change though. Perhaps there is a bug
elsewhere.
Signed-off-by: Maciej W. Ro
201 - 222 of 222 matches
Mail list logo
