On Wed, Sep 22, 2021 at 12:28 PM Maxime Ripard maxime@cerno.tech wrote:
On Wed, Sep 22, 2021 at 11:10:34AM +0100, Sudip Mukherjee wrote:
On Wed, Sep 22, 2021 at 10:57 AM Maxime Ripard maxime@cerno.tech wrote:
<snip>
Still works fine (and it required some mangling of the kernel command line).
If we summarize:
- You initially just dumped a panic and a link to your QA, without any more context:
The SHA was also given, and I didn't know what else you would need. The openQA link was given to show the dmesg.
- Then stating that you're not doing any test, really;
Yes, and I still say that, its just a boot test.
Well, except for booting Ubuntu, but no other modification
But you're not booting the standard image
And with a custom initrd
yes, something which has always worked in boot-testing LTS kernel or mainline kernel.
- And that QA link states that you're booting from QEMU, but you're not.
I only found that the "WORKER_CLASS" has the name "qemu_rpi4", that is a name which I choose to give as that worker laptop is connected to rpi4 and also running qemu tests. If you want I can change the name of the WORKER_CLASS. :) iiuc, dmesg shows if its booting in a qemu or on a real hardware.
Please provide a full documentation on what you're doing to generate that image, from scratch, in order to get that panic you reported previously.
I have now ordered another rpi4 board and will create the image from scratch and give you the steps.
I've spent an entire day trying to make sense of what you're doing exactly to get into that situation. I have other things to work on and I don't plan on figuring out any random CI system.
I am not really sure why you are trying to figure out a random CI system. I can reproduce the problem in our setup everytime I test with that reverted commit and I have already said I am happy to test with a debug patch or anything else.