5.19.9 regression: DMAR error on i7-8650U

5.19.9 regression: DMAR error on i7-8650U

[George Hilliard]

I'm experiencing a regression on 5.19.9 from 5.19.8. Not sure if you are
already aware of this, apologies if it's noise.  My hunch is that this
is an iommu problem since there were quite a few iommu changes in .9,
but I have also Cc'd Firewire maintainers on the chance that I'm wrong.

My Apple Thunderbolt to Firewire adapter has quit working on 5.19.9 on
my Thinkpad T480s (i7-8650U), with the following log message while
enumerating the device (reformatted for email):

    [  318.263546] thunderbolt 0-1: new device found, vendor=0x1 device=0x8004
    [  318.263559] thunderbolt 0-1: Apple, Inc. Thunderbolt to FireWire Adapter
    [  318.342416] pcieport 0000:05:01.0: pciehp: Slot(1): Card present
    [  318.342428] pcieport 0000:05:01.0: pciehp: Slot(1): Link Up
    (snip)
    [  318.503177] pcieport 0000:08:00.0: enabling device (0000 -> 0003)
    [  318.504976] firewire_ohci 0000:09:00.0: enabling device (0000 -> 0002)
    [  318.562000] firewire_ohci 0000:09:00.0: added OHCI v1.10 device
                   as card 4, 8 IR + 8 IT contexts, quirks 0x0, physUB
    [  318.562109] DMAR: DRHD: handling fault status reg 2
    [  318.562114] DMAR: [INTR-REMAP] Request device [09:00.0] fault
                   index 0x8080 [fault reason 0x25] Blocked a
                   compatibility format interrupt request

The last two lines are the new error.

Happy to provide more details or experiment; this happens nearly every time.

George

Re: 5.19.9 regression: DMAR error on i7-8650U

[Baolu Lu]

On 9/18/22 8:00 AM, George Hilliard wrote:
> I'm experiencing a regression on 5.19.9 from 5.19.8. Not sure if you are
> already aware of this, apologies if it's noise.  My hunch is that this
> is an iommu problem since there were quite a few iommu changes in .9,
> but I have also Cc'd Firewire maintainers on the chance that I'm wrong.
> 
> My Apple Thunderbolt to Firewire adapter has quit working on 5.19.9 on
> my Thinkpad T480s (i7-8650U), with the following log message while
> enumerating the device (reformatted for email):
> 
>      [  318.263546] thunderbolt 0-1: new device found, vendor=0x1 device=0x8004
>      [  318.263559] thunderbolt 0-1: Apple, Inc. Thunderbolt to FireWire Adapter
>      [  318.342416] pcieport 0000:05:01.0: pciehp: Slot(1): Card present
>      [  318.342428] pcieport 0000:05:01.0: pciehp: Slot(1): Link Up
>      (snip)
>      [  318.503177] pcieport 0000:08:00.0: enabling device (0000 -> 0003)
>      [  318.504976] firewire_ohci 0000:09:00.0: enabling device (0000 -> 0002)
>      [  318.562000] firewire_ohci 0000:09:00.0: added OHCI v1.10 device
>                     as card 4, 8 IR + 8 IT contexts, quirks 0x0, physUB
>      [  318.562109] DMAR: DRHD: handling fault status reg 2
>      [  318.562114] DMAR: [INTR-REMAP] Request device [09:00.0] fault
>                     index 0x8080 [fault reason 0x25] Blocked a
>                     compatibility format interrupt request
> 
> The last two lines are the new error.
> 
> Happy to provide more details or experiment; this happens nearly every time.
> 
> George
> 

+ Mika.

Best regards,
baolu

Re: 5.19.9 regression: DMAR error on i7-8650U

[Mika Westerberg]

Hi George,

On Mon, Sep 19, 2022 at 08:53:48AM +0800, Baolu Lu wrote:
> On 9/18/22 8:00 AM, George Hilliard wrote:
> > I'm experiencing a regression on 5.19.9 from 5.19.8. Not sure if you are
> > already aware of this, apologies if it's noise.  My hunch is that this
> > is an iommu problem since there were quite a few iommu changes in .9,
> > but I have also Cc'd Firewire maintainers on the chance that I'm wrong.
> > 
> > My Apple Thunderbolt to Firewire adapter has quit working on 5.19.9 on
> > my Thinkpad T480s (i7-8650U), with the following log message while
> > enumerating the device (reformatted for email):
> > 
> >      [  318.263546] thunderbolt 0-1: new device found, vendor=0x1 device=0x8004
> >      [  318.263559] thunderbolt 0-1: Apple, Inc. Thunderbolt to FireWire Adapter
> >      [  318.342416] pcieport 0000:05:01.0: pciehp: Slot(1): Card present
> >      [  318.342428] pcieport 0000:05:01.0: pciehp: Slot(1): Link Up
> >      (snip)
> >      [  318.503177] pcieport 0000:08:00.0: enabling device (0000 -> 0003)
> >      [  318.504976] firewire_ohci 0000:09:00.0: enabling device (0000 -> 0002)
> >      [  318.562000] firewire_ohci 0000:09:00.0: added OHCI v1.10 device
> >                     as card 4, 8 IR + 8 IT contexts, quirks 0x0, physUB
> >      [  318.562109] DMAR: DRHD: handling fault status reg 2
> >      [  318.562114] DMAR: [INTR-REMAP] Request device [09:00.0] fault
> >                     index 0x8080 [fault reason 0x25] Blocked a
> >                     compatibility format interrupt request
> > 
> > The last two lines are the new error.
> > 
> > Happy to provide more details or experiment; this happens nearly every time.
> > 
> > George
> > 
> 
> + Mika.

Since this is a regression, I wonder if you are able to bisect it to the
commit that caused the issue? As you say there are a couple of IOMMU
related changes between v5.19.8 and v5.19.9 so one option is to revert
them one by one and see if the problem goes away:

f7f13b8d49bf3eff2c98230532e0671195277216 swiotlb: avoid potential left shift overflow
9516acba29e322202674d18f4dc383879f7813a5 iommu/vt-d: Fix possible recursive locking in intel_iommu_init()
420d2045715588ad44cd7d806864a223b4fc05c9 iommu/vt-d: Correctly calculate sagaw value of IOMMU
77a2d61334f715293c20f4fa30df035fd870fba4 iommu/virtio: Fix interaction with VFIO
32e4b8dbc9119c07ea1888e72c8a5681b82e180c iommu: Fix false ownership failure on AMD systems with PASID activated

Re: 5.19.9 regression: DMAR error on i7-8650U

[Mika Westerberg]

On Mon, Sep 19, 2022 at 08:27:20AM +0300, Mika Westerberg wrote:
> Hi George,
> 
> On Mon, Sep 19, 2022 at 08:53:48AM +0800, Baolu Lu wrote:
> > On 9/18/22 8:00 AM, George Hilliard wrote:
> > > I'm experiencing a regression on 5.19.9 from 5.19.8. Not sure if you are
> > > already aware of this, apologies if it's noise.  My hunch is that this
> > > is an iommu problem since there were quite a few iommu changes in .9,
> > > but I have also Cc'd Firewire maintainers on the chance that I'm wrong.
> > > 
> > > My Apple Thunderbolt to Firewire adapter has quit working on 5.19.9 on
> > > my Thinkpad T480s (i7-8650U), with the following log message while
> > > enumerating the device (reformatted for email):
> > > 
> > >      [  318.263546] thunderbolt 0-1: new device found, vendor=0x1 device=0x8004
> > >      [  318.263559] thunderbolt 0-1: Apple, Inc. Thunderbolt to FireWire Adapter
> > >      [  318.342416] pcieport 0000:05:01.0: pciehp: Slot(1): Card present
> > >      [  318.342428] pcieport 0000:05:01.0: pciehp: Slot(1): Link Up
> > >      (snip)
> > >      [  318.503177] pcieport 0000:08:00.0: enabling device (0000 -> 0003)
> > >      [  318.504976] firewire_ohci 0000:09:00.0: enabling device (0000 -> 0002)
> > >      [  318.562000] firewire_ohci 0000:09:00.0: added OHCI v1.10 device
> > >                     as card 4, 8 IR + 8 IT contexts, quirks 0x0, physUB
> > >      [  318.562109] DMAR: DRHD: handling fault status reg 2
> > >      [  318.562114] DMAR: [INTR-REMAP] Request device [09:00.0] fault
> > >                     index 0x8080 [fault reason 0x25] Blocked a
> > >                     compatibility format interrupt request
> > > 
> > > The last two lines are the new error.
> > > 
> > > Happy to provide more details or experiment; this happens nearly every time.
> > > 
> > > George
> > > 
> > 
> > + Mika.
> 
> Since this is a regression, I wonder if you are able to bisect it to the
> commit that caused the issue? As you say there are a couple of IOMMU
> related changes between v5.19.8 and v5.19.9 so one option is to revert
> them one by one and see if the problem goes away:
> 
> f7f13b8d49bf3eff2c98230532e0671195277216 swiotlb: avoid potential left shift overflow
> 9516acba29e322202674d18f4dc383879f7813a5 iommu/vt-d: Fix possible recursive locking in intel_iommu_init()
> 420d2045715588ad44cd7d806864a223b4fc05c9 iommu/vt-d: Correctly calculate sagaw value of IOMMU
> 77a2d61334f715293c20f4fa30df035fd870fba4 iommu/virtio: Fix interaction with VFIO
> 32e4b8dbc9119c07ea1888e72c8a5681b82e180c iommu: Fix false ownership failure on AMD systems with PASID activated

Here's bugzilla report that looks to have similar symptoms:

https://bugzilla.kernel.org/show_bug.cgi?id=216497

Re: 5.19.9 regression: DMAR error on i7-8650U

[Mika Westerberg]

Hi Baolu,

On Mon, Sep 19, 2022 at 11:09:02AM +0300, Mika Westerberg wrote:
> Here's bugzilla report that looks to have similar symptoms:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=216497

The reporters of the above bugzilla bisected this down to:

  https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.19.y&id=9516acba29e322202674d18f4dc383879f7813a5

Re: 5.19.9 regression: DMAR error on i7-8650U

[George Hilliard]

On Mon, Sep 19, 2022 at 9:43 AM Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
>
> Hi Baolu,
>
> On Mon, Sep 19, 2022 at 11:09:02AM +0300, Mika Westerberg wrote:
> > Here's bugzilla report that looks to have similar symptoms:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=216497
>
> The reporters of the above bugzilla bisected this down to:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.19.y&id=9516acba29e322202674d18f4dc383879f7813a5

I can confirm that reverting 9516acba29e322202674d18f4dc383879f7813a5
fixes the problem for me as well.

Cheers,
George

Re: 5.19.9 regression: DMAR error on i7-8650U

[Baolu Lu]

On 2022/9/20 3:05, George Hilliard wrote:
> On Mon, Sep 19, 2022 at 9:43 AM Mika Westerberg
> <mika.westerberg@linux.intel.com>  wrote:
>> Hi Baolu,
>>
>> On Mon, Sep 19, 2022 at 11:09:02AM +0300, Mika Westerberg wrote:
>>> Here's bugzilla report that looks to have similar symptoms:
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=216497
>> The reporters of the above bugzilla bisected this down to:
>>
>>    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.19.y&id=9516acba29e322202674d18f4dc383879f7813a5
> I can confirm that reverting 9516acba29e322202674d18f4dc383879f7813a5
> fixes the problem for me as well.

Thanks for doing this. I will post a patch to revert this commit.

Best regards,
baolu

Re: 5.19.9 regression: DMAR error on i7-8650U #forregzbot

[Thorsten Leemhuis]

TWIMC: this mail is primarily send for documentation purposes and for
regzbot, my Linux kernel regression tracking bot. These mails usually
contain '#forregzbot' in the subject, to make them easy to spot and filter.

[TLDR: I'm adding this regression report to the list of tracked
regressions; all text from me you find below is based on a few templates
paragraphs you might have encountered already already in similar form.]

Hi, this is your Linux kernel regression tracker.

On 18.09.22 02:00, George Hilliard wrote:
> I'm experiencing a regression on 5.19.9 from 5.19.8. Not sure if you are
> already aware of this, apologies if it's noise.  My hunch is that this
> is an iommu problem since there were quite a few iommu changes in .9,
> but I have also Cc'd Firewire maintainers on the chance that I'm wrong.
> 
> My Apple Thunderbolt to Firewire adapter has quit working on 5.19.9 on
> my Thinkpad T480s (i7-8650U), with the following log message while
> enumerating the device (reformatted for email):
> 
>     [  318.263546] thunderbolt 0-1: new device found, vendor=0x1 device=0x8004
>     [  318.263559] thunderbolt 0-1: Apple, Inc. Thunderbolt to FireWire Adapter
>     [  318.342416] pcieport 0000:05:01.0: pciehp: Slot(1): Card present
>     [  318.342428] pcieport 0000:05:01.0: pciehp: Slot(1): Link Up
>     (snip)
>     [  318.503177] pcieport 0000:08:00.0: enabling device (0000 -> 0003)
>     [  318.504976] firewire_ohci 0000:09:00.0: enabling device (0000 -> 0002)
>     [  318.562000] firewire_ohci 0000:09:00.0: added OHCI v1.10 device
>                    as card 4, 8 IR + 8 IT contexts, quirks 0x0, physUB
>     [  318.562109] DMAR: DRHD: handling fault status reg 2
>     [  318.562114] DMAR: [INTR-REMAP] Request device [09:00.0] fault
>                    index 0x8080 [fault reason 0x25] Blocked a
>                    compatibility format interrupt request
> 
> The last two lines are the new error.
> 
> Happy to provide more details or experiment; this happens nearly every time.

CCing the regression mailing list, as it should be in the loop for all
regressions, as explained here:
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html

Thanks for the report. To be sure below issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression
tracking bot:

#regzbot introduced v5.19.8..v5.19.9 ^
https://bugzilla.kernel.org/show_bug.cgi?id=216497
#regzbot title iommu: DMAR errors
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply -- ideally with also
telling regzbot about it, as explained here:
https://linux-regtracking.leemhuis.info/tracked-regression/

Reminder for developers: When fixing the issue, add 'Link:' tags
pointing to the report (the mail this one replies to), as explained for
in the Linux kernel's documentation; above webpage explains why this is
important for tracked regressions.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.