uglink: https://bugs.launchpad.net/qemu/+bug/1861605
Cc: Aurelien Jarno
Cc: Aleksandar Markovic
Cc: Aleksandar Rikalo
Cc: Richard Henderson
Signed-off-by: James Clarke
---
target/mips/op_helper.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/target/mips/op_helper.c
If the receive window presented to the guest closes, slirp should send a
window update once the window reopens sufficiently, rather than forcing
the guest to send a window probe, which can take several seconds.
Signed-off-by: James Clarke
---
Hi,
I encountered this whilst running a (k)FreeBSD
On 6 Nov 2017, at 19:57, Riku Voipio wrote:
>
> On Wed, Oct 04, 2017 at 10:38:50AM +0200, John Paul Adrian Glaubitz wrote:
>> Hi!
>>
>> Any chance that this patch gets merged soon?
>>
>> Looks like it has been reviewed by at least Richard and Philippe.
>
> Sorry, slipped under radar. Applied t
And to confirm, while somewhat of a hack, that patch does indeed fix
aptitude as expected (as well as my minimal test case I wrote when
debugging this before stumbling upon this bug report).
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to Q
What's the status of this? This is causing aptitude in Debian chroots to
reliably segfault under qemu-arm-user.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1594394
Title:
Using setreuid / setegid
Fixes: https://bugs.launchpad.net/qemu/+bug/1716767
Signed-off-by: James Clarke
---
Changes since v2:
* Fixed opening curly brace formatting, both for my new SH4-specific
regpairs_aligned function, as well as the Arm one I touched, to appease
checkpatch.pl
Changes since v1:
* Removed
Fixes: https://bugs.launchpad.net/qemu/+bug/1716767
Signed-off-by: James Clarke
---
Changes since v1:
* Removed all changes in v1 :)
* Added syscall num argument to regpairs_aligned
* Added SH4-specific implementation of regpairs_aligned to return 1 for
p{read,write}64
linux-user
Fixes: https://bugs.launchpad.net/qemu/+bug/1716767
Signed-off-by: James Clarke
---
linux-user/syscall.c | 12
1 file changed, 12 insertions(+)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 9b6364a266..24d6a81c21 100644
--- a/linux-user/syscall.c
+++ b/linux-user
With the attached patch, qemu-sh4-static now works for file:
root@debian:/# /usr/bin/qemu-sh4-static.new2 /usr/bin/file /bin/bash
/bin/bash: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), dynamically
linked, interpreter /lib/ld-linux.so.2,
BuildID[sha1]=579b7ca73585e30c022e6dec83666ecc
Bah, and that's "read *from an offset of* 0x34 bytes"; I
got confused between count and pos midway through that paragraph.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1716767
Title:
(Currently regpairs_aligned gets checked, but this, rightly, returns
false for SH; alignment is not a requirement of the SH ABI, but
p{read,write}64 are an exception for it.)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bug
Ok, I was wrong, there's a whole load of code being included inside the
function from a header. The issue seems to be the pread:
20771@1505254578.94:guest_user_syscall cpu=0x62850620
num=0x00b4 arg1=0x0003 arg2=0xf6fe6798
arg3=0x0020 arg4=0x000
I just ran it myself inside and outside the sh4 chroot. The logging
output is the same, with the exception of the final line. Something is
happening once it's decided it's elf; looking at file_tryelf, my guess
is the fstat call is failing[0].
[0] http://sources.debian.net/src/file/1:5.31-1/src/rea
The "0 == 18446744073709551615 = 0" is actually fine, it's just printing
"-1" as a 64-bit unsigned integer. Could you please upload the fill
output of `file -d /bin/bash 2>&1`?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://b
Yes, I can still reproduce this with 2.8.0, and it gives exactly the
same output.
** Changed in: qemu
Status: Expired => 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/1258626
Title:
Cur
This has been fixed by 40493c5f2b0f124c9b2581e539bba14522e51269, which
is exactly the same diff as given here.
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launc
On Sparc, gcc implicitly passes --relax to the linker, but -r is
incompatible with this. Therefore, if --no-relax is supported, it should
be passed to the linker.
Signed-off-by: James Clarke
---
Hi Peter,
Sorry about that, I wasn't building in a git repository, so werror was
set to no (
On Sparc, gcc implicitly passes --relax to the linker, but -r is
incompatible with this. Therefore, if --no-relax is supported, it should
be passed to the linker.
Signed-off-by: James Clarke
---
Hi Peter,
Sorry about that, I wasn't building in a git repository, so werror was
set to no (
On Sparc, gcc implicitly passes --relax to the linker, but -r is
incompatible with this. Therefore, if --no-relax is supported, it should
be passed to the linker.
Signed-off-by: James Clarke
---
configure | 13 +
rules.mak | 2 +-
2 files changed, 14 insertions(+), 1 deletion
> On 31 Jan 2016, at 23:50, David Gibson wrote:
> On Fri, Jan 29, 2016 at 06:40:21PM +, James Clarke wrote:
>> Here is the description of the mcrfs instruction from the PowerPC
>> Architecture
>> Book, Version 2.02, Book I: PowerPC User Instruction Set Architectur
such as condition flags not persisting
when they should if read, and if you were to read a specific field with some
exception bits set, but no others were set in the entire register, then the
bits would be cleared correctly, but FEX/VX would not be updated to 0 as they
should be.
Signed-off-by: J
logies for submitting such a broken patch.
James Clarke (2):
target-ppc: Make every FPSCR_ macro have a corresponding FP_ macro
target-ppc: mcrfs should always update FEX/VX and only clear exception
bits
target-ppc/cpu.h | 37 -
target-ppc/transl
Signed-off-by: James Clarke
---
target-ppc/cpu.h | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 9706000..3a967b7 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -686,24 +686,37 @@ enum
me FP_ macros needed to calculate
FP_EX_CLEAR_BITS did not exist, and I reordered all the FP_ macros so that they
are defined in the same order as the FPSCR_ macros.
James Clarke (2):
target-ppc: Make every FPSCR_ macro have a corresponding FP_ macro
target-ppc: mcrfs should always update FEX/VX
Signed-off-by: James Clarke
---
target-ppc/cpu.h | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 9706000..3a967b7 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -686,24 +686,37 @@ enum
Signed-off-by: James Clarke
---
target-ppc/cpu.h | 6 ++
target-ppc/translate.c | 15 +++
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 3a967b7..d811bc9 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
Public bug reported:
Whenever I run ``qemu-system-i386 -curses ...'' (with or without a ``-k
en-gb'') on OS X 10.9, the keyboard does not work properly. For example,
when attempting to switch to the QEMU console with Alt+2, I get:
``Warning: no scancode found for keysym 226
Warning: no scancode f
EDIT: I should have mentioned that this is using QEMU 1.6.1, but the
problem also occurs with 1.3.1. Also, in case it makes a difference, I
installed QEMU using Homebrew.
** Description changed:
Whenever I run ``qemu-system-i386 -curses ...'' (with or without a ``-k
en-gb'') on OS X 10.9, the
28 matches
Mail list logo
