On 8 March 2015 at 04:18, Timothy Baldwin
wrote:
> From ebcb08f4f4ed90c8557cafc02593360c59e10a49 Mon Sep 17 00:00:00 2001
> From: Timothy E Baldwin
> Date: Sat, 7 Mar 2015 18:42:41 +
> Subject: [PATCH] Actually block signals that have been queued in TaskState.
>
> Actually block signals that
From ebcb08f4f4ed90c8557cafc02593360c59e10a49 Mon Sep 17 00:00:00 2001
From: Timothy E Baldwin
Date: Sat, 7 Mar 2015 18:42:41 +
Subject: [PATCH] Actually block signals that have been queued in TaskState.
Actually block signals that have been queued in TaskState.
For this purpose the set of b
On 3 March 2015 at 14:51, wrote:
> From: Gonglei
>
> The following changes since commit 0856579cac2f1dacecd847cfcd89680d26ff78f5:
>
> Revert "Merge remote-tracking branch
> 'remotes/ehabkost/tags/x86-pull-request' into staging" (2015-03-03 00:29:17
> +)
>
> are available in the git repos
Hello,
after having upgraded QEMU to the end-of-February release, the problem (still
there) evolved.
Now there is no more a "nevereding loop", but QEMU crashes on stratup with the
above described startup command :
qemu-system-x86_64w.exe -hda debian.img -m 256 -net nic -net
> tap,ifname=TAP32 -
On 3 March 2015 at 10:18, Bastian Koppelmann
wrote:
> The following changes since commit b8a173b25c887a606681fc35a46702c164d5b2d0:
>
> Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into
> staging (2015-03-02 14:25:48 +)
>
> are available in the git repository at:
>
>
2015年3月5日 06:15于 "Philipp Hahn" 写道：
>
> Hi,
>
> On 04.03.2015 15:18, Xiaodong Gong wrote:
> > @@ -157,6 +178,224 @@ static int vpc_probe(const uint8_t *buf, int
buf_size, const char *filename)
> ..
> > +static int vpc_decode_maxc_loc(BlockDriverState *bs, uint32_t
data_length)
> ...
> > +cd = g
According to "arch/tile/include/uapi/arch/opcode_tilegx.h" in Linux
kernel source code, qemu can parse all opcode:
"grep _OPCODE_X0 opcode_tilegx.h | awk '{print $3, $1}' | sort -n"
"grep _OPCODE_X1 opcode_tilegx.h | awk '{print $3, $1}' | sort -n"
"grep _OPCODE_Y0 opcode_tilegx.h | awk '{pr
On 8 March 2015 at 03:17, Michael S. Tsirkin wrote:
> OK Markus now confirmed this wasn't (necessarily) triggered
> by these patches. So nothing should block this pull request now?
Fails to build with clang:
/home/petmay01/linaro/qemu-for-merges/hw/i386/acpi-build.c:471:20:
error: unused functio
On 3 March 2015 at 06:45, Stefan Hajnoczi wrote:
> The following changes since commit b8a173b25c887a606681fc35a46702c164d5b2d0:
>
> Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into
> staging (2015-03-02 14:25:48 +)
>
> are available in the git repository at:
>
>
Sparse report:
target-ppc/mmu-hash64.c:353:9: warning: returning void-valued expression
target-ppc/mmu-hash64.c:620:9: warning: returning void-valued expression
Cc: Alexander Graf
Signed-off-by: Stefan Weil
---
Should we fix this kind of warnings? QEMU includes more than
60 lines of code which
Sparse reports this warning:
block/qapi.c:417:47: warning:
too long initializer-string for array of char(no space for nul char)
Replacing the string by an array of characters fixes this warning.
Signed-off-by: Stefan Weil
---
block/qapi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
08.03.2015 01:10, Michael Tokarev wrote:
[]
> Heh. Is this all that I can say about this patch? ;)
s/I/you/ ofcourse ;)
/mjt
07.03.2015 23:37, Eric Blake wrote:
> On 03/06/2015 02:43 PM, Michael Tokarev wrote:
>> All filesystem methods that call common v9fs_request() function
>> also convert return value to errno. Move this conversion to the
>> common function and remove redundand error handling in methods.
>
> s/redun
On 03/06/2015 02:43 PM, Michael Tokarev wrote:
> The 9pfs-proxy code is actually terrible: it does the same
> things again and again, ignoring function arguments and
> re-inventing the same values again, and a lot of code must
> be consistent with each other.
s/redundrand/redundant/ in the subject
On 03/06/2015 02:43 PM, Michael Tokarev wrote:
> All filesystem methods that call common v9fs_request() function
> also convert return value to errno. Move this conversion to the
> common function and remove redundand error handling in methods.
s/redundand/redundant/
--
Eric Blake eblake redh
Am 06.03.2015 um 22:08 schrieb Stefan Hajnoczi:
> On Fri, Mar 06, 2015 at 12:16:06PM -0500, Jeff Cody wrote:
>> The block layer maintainership is being split up into smaller, more
>> manageable pieces.
>>
>> I propose that I take over / assist with the following areas:
>>
>> * blockjobs
>>
Am 07.03.2015 um 10:14 schrieb Stefan Weil:
> The variable user in struct iscsi_url is a character array, not a pointer.
> Therefore its address will never be NULL.
>
> clang reports this error:
>
> block/iscsi.c:1329:20: warning:
> comparison of array 'iscsi_url->user' not equal to a null pointer
this code:
aml_append(foo, bar);
might, non-intuitively, modify bar, which means that e.g. the following
might not DTRT:
c = ;
aml_append(a, c);
aml_append(b, c);
to fix, simply allocate an intermediate array,
and always modify that.
Signed-off-by: Michael S. Tsirkin
---
h
Hi Rusty!
There are a bunch of (mostly virtio 1.0 related) fixes for virtio
that need to go into 4.0 I think.
virtio_blk: typo fix
virtio_blk: fix comment for virtio 1.0
virtio_console: init work unconditionally
virtio_console: avoid config access from irq
vi
** Changed in: qemu
Assignee: (unassigned) => Timothy Baldwin (t-e-baldwin99)
** Changed in: qemu
Status: New => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1429313
Title:
virtio spec requires that all drivers set DRIVER_OK
before using devices. While rpmsg isn't yet
included in the virtio 1 spec, previous spec versions
also required this.
virtio rpmsg violates this rule: is calls kick
before setting DRIVER_OK.
The fix isn't trivial since simply calling virtio_devi
On 2015-03-06 23:10, Jeff Cody wrote:
On Fri, Mar 06, 2015 at 03:08:29PM -0600, Stefan Hajnoczi wrote:
On Fri, Mar 06, 2015 at 12:16:06PM -0500, Jeff Cody wrote:
> The block layer maintainership is being split up into smaller,
more
> manageable pieces.
>
> I propose that I take over / assist w
On Fri, Mar 06, 2015 at 11:37:49PM +0900, Peter Maydell wrote:
> On 6 March 2015 at 23:27, Markus Armbruster wrote:
> > It looks like we now generate a bunch of files that used to be
> > git-controlled. The "generate" part is fine. But generating into the
> > source tree is asking for trouble.
>
On Fri, Mar 06, 2015 at 05:15:59PM +0100, Markus Armbruster wrote:
> Igor Mammedov writes:
>
> > On Fri, 06 Mar 2015 15:27:07 +0100
> > Markus Armbruster wrote:
> >
> >> "Michael S. Tsirkin" writes:
> >>
> >> > Sorry about all the problems.
> >> > Same as v4, but updated generated files for no
On Fri, Mar 06, 2015 at 11:37:49PM +0900, Peter Maydell wrote:
> On 6 March 2015 at 23:27, Markus Armbruster wrote:
> > It looks like we now generate a bunch of files that used to be
> > git-controlled. The "generate" part is fine. But generating into the
> > source tree is asking for trouble.
>
On Fri, Mar 06, 2015 at 03:27:07PM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > Sorry about all the problems.
> > Same as v4, but updated generated files for non-iasl systems.
> > Not re-sending the patches therefore.
> >
> > The following changes since commit 11d39a131020
On 06/03/2015 16:54, Eric Blake wrote:
> > The problem is that releasing error-checking locks in the child
> > fails under glibc with EPERM, because the mutex stores a different
> > owner tid than the duplicated thread in the child process.
>
> Is that a bug in glibc?
Possibly, but I wouldn't b
clang report:
target-tricore/op_helper.c:1247:24: warning:
taking the absolute value of unsigned type 'uint32_t' (aka 'unsigned int')
has no effect [-Wabsolute-value]
target-tricore/op_helper.c:1248:25: warning:
taking the absolute value of unsigned type 'uint32_t' (aka 'unsigned int')
has
Sat, Mar 07, 2015 at 01:06:24AM CET, dsah...@gmail.com wrote:
>Consolidate all forward typedef declarations to rocker.h.
>
>Signed-off-by: David Ahern
>Acked-by: Scott Feldman
Thanks for taking care of this David.
Acked-by: Jiri Pirko
hi,
i'm thinking about doing a gsoc this year, and i'm interested if you
have any opinions on my idea. (i hope i'm not late for this...)
currently the audio system in qemu is limited to 2 channels (stereo)
sound. also it mixes all sound (if there's more than one sound card)
into a single str
On 03/07/2015 12:34 PM, Peter Maydell wrote:
On 7 March 2015 at 18:33, Stefan Weil wrote:
diff --git a/target-tricore/op_helper.c b/target-tricore/op_helper.c
index ed26b30..52ad80b 100644
--- a/target-tricore/op_helper.c
+++ b/target-tricore/op_helper.c
@@ -1244,9 +1244,9 @@ uint64_t helper_
at:
git://github.com/OSLL/qemu-xtensa.git tags/20150307-xtensa
for you to fetch changes up to 12004c9eb4486a134b1f49b17890a364adca5f8c:
target-xtensa: xtfpga: fix ml605 flash size (2015-03-07 15:27:55 +0300)
Xtensa updates:
-
On 7 March 2015 at 18:33, Stefan Weil wrote:
> diff --git a/target-tricore/op_helper.c b/target-tricore/op_helper.c
> index ed26b30..52ad80b 100644
> --- a/target-tricore/op_helper.c
> +++ b/target-tricore/op_helper.c
> @@ -1244,9 +1244,9 @@ uint64_t helper_dvinit_b_13(CPUTriCoreState *env,
> uin
Am 07.03.2015 um 12:14 schrieb Paolo Bonzini:
On 07/03/2015 00:47, Peter Maydell wrote:
1. It complains about glib headers:
In file included from /home/stefanha/qemu/include/net/eth.h:32:
In file included from /home/stefanha/qemu/include/qemu/iov.h:17:
In file included from /home/stefanha/qemu/i
On 07/03/2015 00:47, Peter Maydell wrote:
> > 1. It complains about glib headers:
> > In file included from /home/stefanha/qemu/include/net/eth.h:32:
> > In file included from /home/stefanha/qemu/include/qemu/iov.h:17:
> > In file included from /home/stefanha/qemu/include/qemu-common.h:43:
> > In
Am 07.03.2015 um 10:04 schrieb Stefan Weil:
Am 06.03.2015 um 20:06 schrieb Stefan Hajnoczi:
Hi Peter,
You are rejecting pull requests that produce warnings under clang.
clang 3.5.0 on Fedora 21 produces so much noise that it's extremely
tedious and error-prone to try finding relevant new warnin
Hi Stefan,
On 03/07/2015 09:33 AM, Stefan Weil wrote:
clang report:
target-tricore/op_helper.c:1247:24: warning:
taking the absolute value of unsigned type 'uint32_t' (aka 'unsigned int')
has no effect [-Wabsolute-value]
target-tricore/op_helper.c:1248:25: warning:
taking the absolute
clang report:
target-tricore/op_helper.c:1247:24: warning:
taking the absolute value of unsigned type 'uint32_t' (aka 'unsigned int')
has no effect [-Wabsolute-value]
target-tricore/op_helper.c:1248:25: warning:
taking the absolute value of unsigned type 'uint32_t' (aka 'unsigned int')
has
The variable user in struct iscsi_url is a character array, not a pointer.
Therefore its address will never be NULL.
clang reports this error:
block/iscsi.c:1329:20: warning:
comparison of array 'iscsi_url->user' not equal to a null pointer
is always true [-Wtautological-pointer-compare]
Signe
Am 06.03.2015 um 20:06 schrieb Stefan Hajnoczi:
Hi Peter,
You are rejecting pull requests that produce warnings under clang.
clang 3.5.0 on Fedora 21 produces so much noise that it's extremely
tedious and error-prone to try finding relevant new warnings.
Are you using a different clang version
40 matches
Mail list logo
