qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL 00/30] Migration pull patches (take 4)


From: Juan Quintela
Subject: Re: [PULL 00/30] Migration pull patches (take 4)
Date: Fri, 17 Jan 2020 13:22:10 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Peter Maydell <address@hidden> wrote:
> On Tue, 14 Jan 2020 at 12:53, Juan Quintela <address@hidden> wrote:
>>
>> The following changes since commit 3c8a6575985b1652b45bfa670b5e1907d642cfa0:
>>
>>   Merge remote-tracking branch
>> 'remotes/kraxel/tags/usb-20200113-pull-request' into staging
>> (2020-01-13 14:19:57 +0000)
>>
>> are available in the Git repository at:
>>
>>   https://github.com/juanquintela/qemu.git tags/migration-pull-pull-request
>>
>> for you to fetch changes up to b039b02c25d1725cf0296721d98e35e024468b20:
>>
>>   migration: Support QLIST migration (2020-01-14 13:45:29 +0100)
>>
>> ----------------------------------------------------------------
>> Migration pull request (take 4)
>>
>> - both patches for x32 archs in
>> - reorder the pages to make git bisect happy
>>
>> Thanks a lot to Daniel for helping with the bugs.  Twice.
> (processes started 45 mins ago, unreaped processes in zombie state.)
>
> It looks like the multifd/tcp test fails, but doesn't manage to
> actually turn the failure into the test case exiting:
>
> /i386/migration/multifd/tcp: qemu-system-i386: -accel kvm: invalid
> accelerator kvm
> qemu-system-i386: falling back to tcg
> qemu-system-i386: -accel kvm: invalid accelerator kvm
> qemu-system-i386: falling back to tcg
> qemu-system-i386: multifd_send_sync_main: multifd_send_pages fail
> qemu-system-i386: failed to save SaveStateEntry with id(name): 3(ram)
> qemu-system-i386: Unable to write to socket: Broken pipe
> qemu-system-i386: Unknown combination of migration flags: 0
> qemu-system-i386: error while loading state section id 3(ram)
> qemu-system-i386: load of migration failed: Invalid argument
> [hangs here]
>
> I think you need to find a system which has 32-bit ram_addr_t
> and test this, because this is about the fourth time round
> for this patchset failing on this configuration.

That is arm32 bits at the moment, right?

Later, Juan.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]