From: Eric Biggers <ebiggers@kernel.org>
To: Oliver Sang <oliver.sang@intel.com>
Cc: oe-lkp@lists.linux.dev, lkp@intel.com,
Ard Biesheuvel <ardb@kernel.org>,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-scsi@vger.kernel.org, target-devel@vger.kernel.org
Subject: Re: [linux-next:master] [x86/crc32] 55d1ecceb8: INFO:task_blocked_for_more_than#seconds
Date: Thu, 26 Dec 2024 17:27:49 -0800 [thread overview]
Message-ID: <20241227012749.GA87183@sol.localdomain> (raw)
In-Reply-To: <Z2y/cmuCmv22DiHo@xsang-OptiPlex-9020>
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
prev parent reply other threads:[~2024-12-27 1:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-25 6:50 [linux-next:master] [x86/crc32] 55d1ecceb8: INFO:task_blocked_for_more_than#seconds kernel test robot
2024-12-25 21:32 ` Eric Biggers
2024-12-26 2:29 ` Oliver Sang
2024-12-27 1:27 ` Eric Biggers [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241227012749.GA87183@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=ardb@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lkp@intel.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=target-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox