On 5/19/19 5:16 PM, Aleksandar Markovic wrote:
>> From: Jakub Jermar
>>
>> On 5/19/19 2:00 PM, Aleksandar Markovic wrote:
>>>>>
>>>>> * A fix for HelenOS boot hang (related to the flag PAGE_EXEC)
>>>>
>>>> This was r
On 5/19/19 2:00 PM, Aleksandar Markovic wrote:
>>>
>>> * A fix for HelenOS boot hang (related to the flag PAGE_EXEC)
>>
>> This was rather a problem with failing non-executable page tests in
>> L4Re, not HelenOS. Even though I tested HelenOS for regressions.
>
> OK, Jakub, what would be your sug
Hi Aleksandar,
On 5/19/19 12:52 PM, Aleksandar Markovic wrote:
> From: Aleksandar Markovic
>
> The following changes since commit 1b46b4daa6fbf45eddcf77877379a0afac341df9:
>
> Merge remote-tracking branch 'remotes/kraxel/tags/ui-20190517-pull-request'
> into staging (2019-05-17 17:25:19 +010
Hi Aleksandar and Philippe,
On 5/16/19 8:04 PM, Aleksandar Markovic wrote:
>
> On May 16, 2019 6:31 PM, "Philippe Mathieu-Daudé" <mailto:phi...@redhat.com>> wrote:
>>
>> Hi Jakub,
>>
>> On 5/16/19 3:10 PM, Jakub Jermar wrote:
>> > Hi,
Hi Philippe,
On 5/16/19 6:31 PM, Philippe Mathieu-Daudé wrote:
> Hi Jakub,
>
> On 5/16/19 3:10 PM, Jakub Jermar wrote:
>> Hi,
>>
>> On 5/3/19 12:02 PM, Jakub Jermar wrote:
>>> Hi,
>>>
>>> On 4/23/19 4:58 PM, Jakub Jermar wrote:
>>&g
Also attaching the 64-bit version of the reproducer.
** Attachment added: "64-bit version of the reproducer"
https://bugs.launchpad.net/qemu/+bug/1825311/+attachment/5264428/+files/reproducer64.tar.xz
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
Hi,
On 5/3/19 12:02 PM, Jakub Jermar wrote:
> Hi,
>
> On 4/23/19 4:58 PM, Jakub Jermar wrote:
>> Hi Philippe!
>>
>> On 4/23/19 3:48 PM, Philippe Mathieu-Daudé wrote:
>>> Hi Jakub,
>>>
>>> On 4/23/19 1:00 PM, Jakub Jerm
Hi,
On 4/23/19 4:58 PM, Jakub Jermar wrote:
> Hi Philippe!
>
> On 4/23/19 3:48 PM, Philippe Mathieu-Daudé wrote:
>> Hi Jakub,
>>
>> On 4/23/19 1:00 PM, Jakub Jermář wrote:
>>> This commit addresses QEMU Bug #1825311:
>>>
>>> mips_cpu_
I am attaching a reproducer image and script.
Unpatched execution ends like this:
...
TAP TEST START
1..2
not ok 1 NonExecutable::ElfDataIsNotExecutable
# Assertion failed
/home/jermar/Kernkonzept/software/l4/pkg/l4re-core/test/moe/test_nx.cc:103
# Expected: -(L4_EIPC_LO + l4_ipc_error(tag, l4_u
Hi Philippe!
On 4/23/19 3:48 PM, Philippe Mathieu-Daudé wrote:
> Hi Jakub,
>
> On 4/23/19 1:00 PM, Jakub Jermář wrote:
>> This commit addresses QEMU Bug #1825311:
>>
>> mips_cpu_handle_mmu_fault renders all accessed pages executable
>>
>> It allows finer-grained control over whether the accesse
Public bug reported:
On MIPS, data accesses to pages mapped in the TLB result in
mips_cpu_handle_mmu_fault() marking the page unconditionally executable,
even if the TLB entry has the XI bit set. Later on, when there is an
attempt to execute this page, no exception is generated, even though
TLBXI
As for the other outcome, when the guest hangs (instead of QEMU
crashing), the guest CPUs that block forward progress are halted in an
idle loop, have interrupts enabled and have a queued timer IRQ 248 and a
pending software IPI IRQ 250. It appears another timer IRQ is currently
being serviced (but
** Attachment added: "Debug binary with symbols"
https://bugs.launchpad.net/qemu/+bug/1811244/+attachment/5229552/+files/qemu-system-i386.xz
** Description changed:
When MTTCG is enabled, QEMU 3.1.0 sometimes crashes when running the
following command line:
qemu-system-i386 -kernel
** Attachment added: "coredump"
https://bugs.launchpad.net/qemu/+bug/1811244/+attachment/5229551/+files/qemu-system-i386.core.xz
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1811244
Title:
qem
Public bug reported:
When MTTCG is enabled, QEMU 3.1.0 sometimes crashes when running the
following command line:
qemu-system-i386 -kernel
/home/jermar/Kernkonzept/software/l4/.build-i386/bin/x86_gen/bootstrap
-append bootstrap -initrd
"/home/jermar/work/software/l4/fiasco/.build-i386/fiasco
-ser
Public bug reported:
When negotiating virtio-net feature bits, the device ignores the absence
of the VIRTIO_NET_F_CTRL_VQ bit in driver feature bits and provides
three virtqueues, including the control virtqueue, even though the
driver is expecting only the receive and transmit virtqueues. Looking
** Changed in: qemu
Status: Incomplete => New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1128935
Title:
MIPS r4k "TLB modified exception" generated for TLB entries that are
not visible
A shorter command line to reproduce this with QEMU 2.11.0 and HelenOS
0.7.1 would be:
$ qemu-system-mips -cpu 4Kc -kernel HelenOS-0.7.1-mips32-malta-be.boot
-nographic
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.laun
Yes, running the following command line with QEMU 2.11.0 on the HelenOS
0.7.1 image downloaded from
http://www.helenos.org/releases/HelenOS-0.7.1-mips32-malta-be.boot will
result in occasional "failures" of the TLBP instruction as described in
this bug and as evidenced by a warning printed by Helen
Turns out integratorcm_init() depends on the memsz property being
already set, but that unfortunately is not the case as setting of memsz
depends on integratorcm_init() having completed:
dev = qdev_create(NULL, TYPE_INTEGRATOR_CM);<= calls
integratorcm_init(), needs memsz
qdev
** Bug watch added: Email to helenos-devel@lists #
mailto:helenos-de...@lists.modry.cz
** Also affects: helenos via
mailto:helenos-de...@lists.modry.cz
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is sub
Public bug reported:
The following command line no longer works (i.e. the guest does not
boot) with QEMU 2.7.0:
qemu-system-arm -M integratorcp -m 128M -kernel
HelenOS-0.6.0-arm32-integratorcp.boot
The HelenOS image can be downloaded here:
http://www.helenos.org/releases/HelenOS-0.6.0-arm32
For me the icon looks ugly if QEMU is run by the normal user. However,
when run via sudo, it looks normal for some reason and does not display
any of the white pixels.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launc
It may be actually easier to start with recreating the Ski machine
inside QEMU. The result will be a faster Ski in a maintained codebase.
Definitely not a bad start.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchp
Yes, the patch fixes the problem for me. Thank you.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1359930
Title:
[ARMv5] Integrator/CP regression when reading FPSID register
Status in Home for var
** Summary changed:
- [ARMv5] Integrator/CP regression when reading FPSID instruction
+ [ARMv5] Integrator/CP regression when reading FPSID register
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1359
Public bug reported:
There seems to be a regression in QEMU 2.1.0 which demonstrates itself
when running the attached HelenOS Integrator/CP (i.e. ARMv5) image. The
offending instruction seems to be:
vmrs r0, fpsid
Upon its execution, HelenOS kernel receives an Undefined instruction
exception (
Here is the respective HelenOS kernel with debug symbols.
** Attachment added: "HelenOS kernel with debug symbols"
https://bugs.launchpad.net/helenos/+bug/1359930/+attachment/4183966/+files/kernel.raw
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
Hello,
there seems to be a regression in QEMU 2.1.0 which demonstrates itself
when running the mainline HelenOS Integrator/CP (i.e. ARMv5) image. The
offending instruction seems to be:
vmrs r0, fpsid
Upon its execution, HelenOS kernel receives an Undefined instruction
exception (which it does
I think I am seeing the same symptoms when I let two QEMU instances talk
to each other over pipe serial.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1181796
Title:
Qemu locks up when incoming ser
Guys, perhaps we should move this dialogue to a different thread as we
are abusing the unrelated Bug 1128935.
Jakub
On 04/06/2013 07:01 PM, blueswirl wrote:
> On Sat, Apr 6, 2013 at 9:31 AM, agraf <1128...@bugs.launchpad.net> wrote:
>> Hi Lurie,
>>
>> On 04.04.2013, at 19:34, Iurie wrote:
>>
>>>
On 04/04/2013 07:34 PM, Gigi D'Agostino wrote:
> in the past year gsoc qemu proposed projects there where on eproject that i
> liked, which were: qemu IA64 emulation :
> http://wiki.qemu.org/Google_Summer_of_Code_2012#IA64_emulation
>
> this year i have not seen this project to be proposed, so i w
Linux under QEMU does not hit this issue because it turns out that its
"TLB modified" handler does not check the P bit of the Index register
after the TLBP instruction.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.laun
** Summary changed:
- MIPS r4k TLB modified exception generated for TLB entries not visible to the
TLBP instruction
+ MIPS r4k "TLB modified exception" generated for TLB entries that are not
visible to the TLBP instruction
--
You received this bug notification because you are a member of qemu-
Public bug reported:
I occasionally see that the TLBP instruction fails to find the
corresponding TLB entry in the TLB Modified exception handler. This
behavior is unexpected, because the invocation of the TLB Modified
exception suggests there indeed is such an entry in the TLB and only
requires
** Also affects: helenos
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1128935
Title:
MIPS r4k TLB modified exception generated for TLB entries not visib
Hello,
there appears to be a bug in the hand-written machine code which causes
the YAMON print subroutine to jump to a wrong location after printing
the first character. In hw/mips_malta.c, line 619, there is:
stl_raw(p++, 0x08000205);/* j 814 */
which results
On 20.4.2012 12:17, Jakub Jermar wrote:
> I am observing an interesting phenomenon on the latest QEMU git and the
> latest HelenOS mainline (the problem is likely guest-neutral though).
> The QEMU command line is as follows:
>
> $ qemu-system-i386 -device rtl8139,vlan=0 -net user
Hi,
I am observing an interesting phenomenon on the latest QEMU git and the
latest HelenOS mainline (the problem is likely guest-neutral though).
The QEMU command line is as follows:
$ qemu-system-i386 -device rtl8139,vlan=0 -net user -boot d -redir \
udp:8080::8080 -redir udp:8081::8081 -redir
On 04/18/2012 05:30 PM, Alexander Graf wrote:
> On 04/13/2012 06:53 PM, Mark Cave-Ayland wrote:
>> On 11/04/12 02:08, David Gibson wrote:
>>
>> Hi David,
>>
Commit 41557447d30eeb944e42069513df13585f5e6c7f introduced a new
method of
calculating the MSR for the interrupt context. Howev
On 04/18/2012 05:30 PM, Alexander Graf wrote:
> On 04/13/2012 06:53 PM, Mark Cave-Ayland wrote:
>> On 11/04/12 02:08, David Gibson wrote:
>>
>> Hi David,
>>
Commit 41557447d30eeb944e42069513df13585f5e6c7f introduced a new
method of
calculating the MSR for the interrupt context. Howev
How to reproduce:
1. make sure openbios-ppc from Qemu 0.11.1 is installed
2. $ qemu-system-ppc -cdrom HelenOS-0.4.2-ppc32.iso -boot d
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/942299
Title:
Re
Public bug reported:
Mark Cave-Ayland identified Qemu commit
41557447d30eeb944e42069513df13585f5e6c7f as the first bad commit which
prevents HelenOS/ppc from booting with OpenBIOS taken from Qemu 0.11.1.
Note that we deliberately use the OpenBIOS from Qemu 0.11.1 because
there is another suspecte
** Tags added: ia64-softmmu itanium qemu
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/917645
Title:
[Feature request] ia64-softmmu wanted
Status in Home for various HelenOS development branches:
Public bug reported:
Qemu is missing support for full system emulation of the Itanium
architecture, which is one of the main non-x86 server architectures
today (despite the alleged decline in popularity). It would be really
nice if someone had interest in adding full ia64 support to Qemu. Many
OS
Hi,
When emulating HelenOS/ppc with Qemu 0.15, I get the following abort
while booting the kernel:
jermar@hexatonsil:~/software/HelenOS.mainline$ qemu-system-ppc -cdrom
image.iso -boot d
qemu: fatal: Trying to execute code outside RAM or ROM at 0x7ff97ff8
NIP 7ff97ff8 LR 00029434 CTR 7ff97ff9
On 1.7.2011 16:24, Laurent Desnogues wrote:
> On Fri, Jul 1, 2011 at 4:11 PM, Jakub Jermar wrote:
> [...]
>> Actually, the testcase can be further reduced into:
>>
>> .global _start
>>
>> .text
>>
>> .space 0x20
>>
>> _start:
>>
On 1.7.2011 16:15, Laurent Desnogues wrote:
> You don't have to use gdb to reproduce the issue, just add -singlestep
> when running qemu.
This is strange, -singlestep does not work for me here as the testcase
still ends with trap 0x101. The only way how the testcase can succeed
for me is via GDB's
On 1.7.2011 14:57, Jakub Jermar wrote:
> On 1.7.2011 12:41, Artyom Tarasenko wrote:
>> Looks like it's a pretty nice test case.
>>
>> The test case scenario is to load the initial values into the
>> registers (you already know them),
>> calculate the mins,
On 1.7.2011 12:41, Artyom Tarasenko wrote:
> Looks like it's a pretty nice test case.
>
> The test case scenario is to load the initial values into the
> registers (you already know them),
> calculate the mins, cmp the result with expected and jump somewhere.
> Since it happens with interrupts dis
Hi Artyom,
On 1.7.2011 11:15, Artyom Tarasenko wrote:
> Hi Jakub,
> 2011/6/30 Jakub Jermar :
>> Hi,
>>
>> we have been observing a problem with HelenOS running on the latest git
>> Qemu/sparc64. The gist of the problem is that the following computation
>> o
Hi,
we have been observing a problem with HelenOS running on the latest git
Qemu/sparc64. The gist of the problem is that the following computation
of minimum of 64 and 512 surprisingly gives 512:
bytes = min(len, BPS(bs) - pos % BPS(bs));
bytes = min(bytes, nodep->size - pos);
On input, `len`
Hello,
I noticed that the layout of the PL050 keyboard used on Integrator/CP
incompatibly changed sometime between Qemu 0.10.5 and Qemu 0.11.1. The
current layout used in Qemu's model of Integrator/CP is the standard PC
layout. What puzzles me is whether this was a fix or a regression. Does
anybod
Hello,
is it at least theoretically possible that the guest atomic instructions (e.g.
XCHG,
LOCK CMPXCHG) on target-i386 are somehow not atomic when simulated/translated
by Qemu?
I am observing a problem with one of my HelenOS/ia32 builds which suggests me
that for
some reason HelenOS spinlock
Hi,
can someone summarize the status of the sparc64 port for me?
I'd be especially interested in having an opensource simulator of some
UltraSPARC II/UltraSPARC IIi based machines (like Ultra 5 or Ultra 60,
even Sun Blades with UltraSPARC IIe and IIi).
What is the biggest showstopper for incl
55 matches
Mail list logo
