On Wed, Sep 22, 2021 at 12:28 PM Maxime Ripard <maxime@xxxxxxxxxx> 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@xxxxxxxxxx> 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. -- Regards Sudip
