[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZIsCIp7Vq735hfxl@gallifrey>
Date: Thu, 15 Jun 2023 12:20:50 +0000
From: "Dr. David Alan Gilbert" <linux@...blig.org>
To: "Richard W.M. Jones" <rjones@...hat.com>
Cc: YiFei Zhu <zhuyifei@...gle.com>, dev@...ont.org,
linux-kernel@...r.kernel.org, peterz@...radead.org,
zhuyifei1999@...il.com
Subject: Re: printk.time causes rare kernel boot hangs
* Richard W.M. Jones (rjones@...hat.com) wrote:
> On Thu, Jun 15, 2023 at 11:04:29AM +0000, YiFei Zhu wrote:
> > see if you can send a alt-sysrq-w to show stacks of
> > blocked tasks.
>
> I guess this is a virtual console thing? I have to boot this hundreds
> of times with a serial console to even get to the bug, so it's tricky.
If you open a monitor device you should be able to do things to the qemu
after you detect the hang; and then I think a :
sendkey alt-sysrq-w
on HMP should do it.
However, some other thoughts:
a) You could try taking a dump and then importing it into crash rather
than using gdb; both ways are touchy, but that does mean you could
give the dump to someone else who can't trigger the bug.
b) You could try giving your kernel to someone who can't trigger it;
if they can trigger it on their host with your kernel that would
suggest something is different in your build environment of your
kernel (e.g. compiler version or flags) rather than the host kernel.
Dave
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
>
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
Powered by blists - more mailing lists