On Thu, Dec 26, 2024 at 10:29:06AM +0800, Oliver Sang wrote: > > Thanks. Unfortunately, the issue does not reproduce for me when following these > > commands. > > > > The kernel does panic from not being able to find the rootfs, both before and > > after. That seems to be caused by the rootfs from the job script not being > > available on the 01.org server, as indicated by the following output: > > > > /usr/bin/wget -q --timeout=3600 --tries=1 --local-encoding=UTF-8 https://download.01.org/0day-ci/lkp-qemu/osimage/pkg/quantal-i386-core.cgz/trinity-static-i386-x86_64-f93256fb_2019-08-28.cgz -N -P /home/e/.lkp/cache/osimage/pkg/quantal-i386-core.cgz > > Failed to download osimage/pkg/quantal-i386-core.cgz/trinity-static-i386-x86_64-f93256fb_2019-08-28.cgz > > cat: '': No such file or directory > > > > It doesn't print the error information from wget, but I checked and it is HTTP > > error 404 Not Found. Thus, there seem to be bugs in lkp where (a) it links to a > > non-existent rootfs, and (b) errors downloading the rootfs are not fatal. > > sorry for this. I just made the upload. the issue should be gone now. > I retried it and the rootfs downloads now. I still see some error messages during boot which suggest the rootfs is broken: ls: cannot access /boot/config-*: No such file or directory ... mkdir: cannot create directory `/var/lock/lkp-bootstrap.lock': File exists ... chroot: failed to run command `trinity': Permission denied Anyway, this all seems unrelated to the reported issue which occurred before mounting the rootfs, based on the provided dmesg.xz. In 10 boots the issue still doesn't reproduce for me, following the 'reproduce' script as closely as possible. Note: for "gcc-12" I used gcc commit 08f1bd108806 from the gcc-12 release branch, and for QEMU I used v9.1.2. And I don't think my commit can be the root cause, especially when the x86 CRC32 code is disabled. So I'm afraid there's nothing I can do here. - Eric
