[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/1] hw/arm/aspeed: Add fby35 machine type
From: |
Peter Delevoryas |
Subject: |
Re: [PATCH 0/1] hw/arm/aspeed: Add fby35 machine type |
Date: |
Tue, 31 May 2022 18:00:08 +0000 |
> On May 30, 2022, at 8:29 AM, Philippe Mathieu-Daudé via <qemu-arm@nongnu.org>
> wrote:
>
> On 4/5/22 00:47, Peter Delevoryas wrote:
>>> On May 3, 2022, at 2:35 PM, Cédric Le Goater <clg@kaod.org> wrote:
>>>
>>> On 5/3/22 22:44, Peter Delevoryas wrote:
>>>> Hey everyone,
>>>> I'm submitting another Facebook (Meta Platforms) machine type: this time
>>>> I'm
>>>> including an acceptance test too.
>>>> Unfortunately, this machine boots _very_ slowly. 300+ seconds.
>>>
>>> This is too much for avocado tests.
>
> Use:
>
> @skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
> @skipUnless(os.getenv('AVOCADO_TIMEOUT_EXPECTED'),
> 'Big initramfs and run from flash')
Thanks for this suggestion!
>
>> Erg, yeah I figured as much. I’ll just resubmit it without the avocado test
>> then,
>> if that sounds ok to you.
>
> No, please keep the test. While it won't run on CI, we can run it locally,
> very useful to bisect.
Ok, I’d be happy to resubmit the test now with the @skipIf and @skipUnless
decorators
(Since the machine definition has been merged at this point).
>
>>>> I'm not sure why this is (so I don't know how to fix it easily)
>>>
>>> The fuji has the same kind of problem. It takes ages to load the lzma
>>> ramdisk.
>>> Could it be a modeling issue ? or how the FW image is compiled ?
>> Yeah, one reason is that Facebook OpenBMC machines have an unnecessarily
>> big initramfs that includes all the rootfs stuff, whereas regular OpenBMC
>> machines have a smaller initramfs right? I don’t entirely know what I’m
>> talking
>> about though.
>> I think most FB machines have moved to zstd compression recently though,
>> but this one may have been missed: I can fix that on the image side. I’ll
>> also experiment more to see if it’s something wrong with the image, or
>> possibly
>> a regression in QEMU. It would really be super awesome if it could boot
>> faster,
>> so I’m very motivated to find a solution.
>