All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.