public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Baolu Lu <baolu.lu@linux.intel.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: baolu.lu@linux.intel.com, "Jörg Rödel" <joro@8bytes.org>,
	"Will Deacon" <will@kernel.org>,
	iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: DMAR-IR: IRQ remapping was enabled on dmar6 but we are not in kdump mode
Date: Wed, 15 May 2024 10:13:59 +0800	[thread overview]
Message-ID: <7eb01b85-9233-4f21-865e-6d128f39fb46@linux.intel.com> (raw)
In-Reply-To: <61ce93c7-e89c-4217-8095-dde9fb01763c@molgen.mpg.de>

On 5/15/24 3:46 AM, Paul Menzel wrote:
> Am 23.01.24 um 01:55 schrieb Baolu Lu:
>> On 2024/1/22 22:53, Paul Menzel wrote:
>>> Am 22.01.24 um 13:38 schrieb Baolu Lu:
>>>> On 2024/1/19 22:45, Paul Menzel wrote:
>>>>>
>>>>> On a Dell PowerEdge T640, Linux 5.9 and 6.6.12 warn about kdump:
>>>>>
>>>>>      [    2.728445] DMAR-IR: IRQ remapping was enabled on dmar6 but 
>>>>> we are not in kdump mode
>>>>>      [    2.736544] DMAR-IR: IRQ remapping was enabled on dmar5 but 
>>>>> we are not in kdump mode
>>>>>      [    2.744620] DMAR-IR: IRQ remapping was enabled on dmar4 but 
>>>>> we are not in kdump mode
>>>>>      [    2.752695] DMAR-IR: IRQ remapping was enabled on dmar3 but 
>>>>> we are not in kdump mode
>>>>>      [    2.760774] DMAR-IR: IRQ remapping was enabled on dmar2 but 
>>>>> we are not in kdump mode
>>>>>      [    2.768847] DMAR-IR: IRQ remapping was enabled on dmar1 but 
>>>>> we are not in kdump mode
>>>>>      [    2.776922] DMAR-IR: IRQ remapping was enabled on dmar0 but 
>>>>> we are not in kdump mode
>>>>>      [    2.784999] DMAR-IR: IRQ remapping was enabled on dmar7 but 
>>>>> we are not in kdump mode
>>>>>
>>>>> Looking through the logs, this only happens when using kexec to 
>>>>> restart the system.
>>>>
>>>> The code that warned this is,
>>>>
>>>>   599         if (ir_pre_enabled(iommu)) {
>>>>   600                 if (!is_kdump_kernel()) {
>>>>   601                         pr_warn("IRQ remapping was enabled on 
>>>> %s but we are not in kdump mode\n",
>>>>   602                                 iommu->name);
>>>>   603                         clear_ir_pre_enabled(iommu);
>>>>   604                         iommu_disable_irq_remapping(iommu);
>>>>   605                 }
>>>>
>>>> The VT-d interrupt remapping is enabled during boot, but this is not a
>>>> kdump kernel.
>>>>
>>>> Do you mind checking whether the disable interrupt remapping callback
>>>> was called during kexec reboot?
>>>>
>>>> 1121 struct irq_remap_ops intel_irq_remap_ops = {
>>>> 1122         .prepare                = intel_prepare_irq_remapping,
>>>> 1123         .enable                 = intel_enable_irq_remapping,
>>>> 1124         .disable                = disable_irq_remapping,
>>>> 1125         .reenable               = reenable_irq_remapping,
>>>> 1126         .enable_faulting        = enable_drhd_fault_handling,
>>>> 1127 };
>>>
>>> Is there a way to check this without rebuilding the Linux kernel?
>>
>> I am not sure, but you can check whether any messages are dumped in the
>> path of .disable callback? or try to use ftrace?
> 
> With
> 
> ```
> diff --git a/drivers/iommu/intel/irq_remapping.c 
> b/drivers/iommu/intel/irq_remapping.c
> index 712ebfc9870c6..146f19ae5b5f1 100644
> --- a/drivers/iommu/intel/irq_remapping.c
> +++ b/drivers/iommu/intel/irq_remapping.c
> @@ -1030,6 +1030,7 @@ static void disable_irq_remapping(void)
>       struct dmar_drhd_unit *drhd;
>       struct intel_iommu *iommu = NULL;
> 
> +    pr_warn("XXX: Called %s\n", __func__);
>       /*
>        * Disable Interrupt-remapping for all the DRHD's now.
>        */
> ```
> 
> I can’t see anything in the logs, so it does not seem to be called.
> 
> Can you reproduce the issue?

How did you reproduce this?

Best regards,
baolu

  reply	other threads:[~2024-05-15  2:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-19 14:45 DMAR-IR: IRQ remapping was enabled on dmar6 but we are not in kdump mode Paul Menzel
2024-01-19 15:11 ` Jörg Rödel
2024-01-22 12:38 ` Baolu Lu
2024-01-22 14:53   ` Paul Menzel
2024-01-23  0:55     ` Baolu Lu
2024-05-14 19:46       ` Paul Menzel
2024-05-15  2:13         ` Baolu Lu [this message]
2024-05-15  6:02           ` Paul Menzel
2024-06-08 11:07             ` Paul Menzel
2024-06-09  7:30               ` Baolu Lu

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=7eb01b85-9233-4f21-865e-6d128f39fb46@linux.intel.com \
    --to=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmenzel@molgen.mpg.de \
    --cc=will@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