On 08/03/2020 13:39, Peter Maydell wrote:
> On Sun, 8 Mar 2020 at 11:58, Mark Cave-Ayland
> wrote:
>> I just tried this patchset applied on top of git master and it causes
>> qemu-system-ppc
>> to segfault on startup:
>>
>> $ gdb --args ./qemu-system-ppc
>> ...
>> ...
>> Thread 1 "qemu-system-pp
On 3/8/2020 9:39 PM, Peter Maydell wrote:
> On Sun, 8 Mar 2020 at 11:58, Mark Cave-Ayland
> wrote:
>> I just tried this patchset applied on top of git master and it causes
>> qemu-system-ppc
>> to segfault on startup:
>>
>> $ gdb --args ./qemu-system-ppc
>> ...
>> ...
>> Thread 1 "qemu-system-
On Sun, 8 Mar 2020 at 11:58, Mark Cave-Ayland
wrote:
> I just tried this patchset applied on top of git master and it causes
> qemu-system-ppc
> to segfault on startup:
>
> $ gdb --args ./qemu-system-ppc
> ...
> ...
> Thread 1 "qemu-system-ppc" received signal SIGSEGV, Segmentation fault.
> 0x000
On 05/03/2020 06:54, Pan Nengyuan wrote:
> This series delay timer_new from init into realize to avoid memleaks when we
> call 'device_list_properties'.
> And do timer_free only in s390x_cpu_finalize because it's hotplugable.
> However, mos6522_realize is never called
> at all due to the incorr
Patchew URL:
https://patchew.org/QEMU/20200305065422.12707-1-pannengy...@huawei.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Subject: [PATCH v4 0/3] delay timer_new from init to realize to fix memleaks.
Message-id: 20200305065422.12707
This series delay timer_new from init into realize to avoid memleaks when we
call 'device_list_properties'.
And do timer_free only in s390x_cpu_finalize because it's hotplugable. However,
mos6522_realize is never called
at all due to the incorrect creation of it. So we aslo fix the incorrect
cr
