Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <efe7e25e-8b05-90e7-fc02-4f1dc84fe324@igalia.com>
Date:   Wed, 21 Dec 2022 12:46:51 -0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Subject: Re: kdump kernel randomly hang with tick_periodic call trace on bare
 metal system
Content-Language: en-US
To:     Baoquan He <bhe@redhat.com>
Cc:     x86@kernel.org, kexec@lists.infradead.org,
        Thomas Gleixner <tglx@linutronix.de>,
        linux-kernel@vger.kernel.org
References: <Y6FJgh3fOYoF0wSV@MiWiFi-R3L-srv>
 <Y6FK++b4buO5EgjD@MiWiFi-R3L-srv> <Y6FNTFbH9DbhEogg@MiWiFi-R3L-srv>
From:   "Guilherme G. Piccoli" <gpiccoli@igalia.com>
In-Reply-To: <Y6FNTFbH9DbhEogg@MiWiFi-R3L-srv>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 20/12/2022 02:51, Baoquan He wrote:
> On 12/20/22 at 01:41pm, Baoquan He wrote:
>> On one intel bare metal system, I can randomly reproduce the kdump hang
>> as below with tick_periodic call trace. Attach the kernel config for
>> reference.
> 
> Forgot mentioning this random hang is also caused by adding
> 'nr_cpus=2' into normal kernel's cmdline, then triggering crash will get
> kdump kernel hang as below kdump log shown.
> 

The weird thing is that you seem to be using "nr_cpus=1" instead - this
is the cmdline from the log:

"nr_cpus=2 irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off
numa=off udev.children-max=2 panic=10 acpi_no_memhotplug
transparent_hugepage=never nokaslr hest_disable novmcoredd cma=0
hugetlb_cma=0 disable_cpu_apicid=16 [...]"

You seems to pass twice the "nr_cpus" thing, and I guess kernel pick the
last one?

Also, what is "disable_cpu_apicid=16"? Could this be related?


Thanks for the report!
Cheers,


Guilherme