Bug 1724276 - arm-smmu e0800000.smmu: Unexpected global fault, this could be serious
Summary: arm-smmu e0800000.smmu: Unexpected global fault, this could be serious
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: aarch64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Mark Salter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2019-06-26 16:03 UTC by Paul Whalen
Modified: 2020-06-22 15:11 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-06-22 15:11:21 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Seattle nonacpi boot (72.86 KB, text/plain)
2019-06-26 16:03 UTC, Paul Whalen
no flags Details
Seattle with acpi=force (34.15 KB, text/plain)
2019-06-26 16:04 UTC, Paul Whalen
no flags Details

Description Paul Whalen 2019-06-26 16:03:58 UTC
Created attachment 1584845 [details]
Seattle nonacpi boot

1. Please describe the problem:

Repeated messages on Seattle Overdrive serial console with nonacpi:

[  292.023147] arm-smmu e0600000.smmu: Unexpected global fault, this could be serious
[  292.030736] arm-smmu e0600000.smmu: 	GFSR 0x00000001, GFSYNR0 0x00000000, GFSYNR1 0x00000003, GFSYNR2 0x00000000
[  292.040961] arm-smmu e0600000.smmu: 	GFSR 0x00000001, GFSYNR0 0x00000000, GFSYNR1 0x00000005, GFSYNR2 0x00000000
[  292.051190] arm-smmu e0600000.smmu: 	GFSR 0x00000001, GFSYNR0 0x00000000, GFSYNR1 0x00000007, GFSYNR2 0x00000000
[  292.061414] arm-smmu e0600000.smmu: 	GFSR 0x00000001, GFSYNR0 0x00000000, GFSYNR1 0x00000000, GFSYNR2 0x00000000


2. What is the Version-Release number of the kernel:

5.2.0-0.rcX

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

5.2.0-0.rc0.git6.1.fc31.aarch64

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

Install 5.2 rcX kernel on Seattle, boot nonacpi. Booting with acpi=force there are no messages. 


5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:

Yes. 


6. Are you running any modules that not shipped with directly Fedora's kernel?:

No.


7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

Comment 1 Paul Whalen 2019-06-26 16:04:49 UTC
Created attachment 1584846 [details]
Seattle with acpi=force

Comment 2 Mark Salter 2019-06-27 17:32:22 UTC
commit 954a03be033c :

   iommu/arm-smmu: Break insecure users by disabling bypass by default
    
    If you're bisecting why your peripherals stopped working, it's
    probably this CL.  Specifically if you see this in your dmesg:
      Unexpected global fault, this could be serious
    ...then it's almost certainly this CL.

I'll look into this...

Comment 3 Mark Salter 2019-07-25 16:48:03 UTC
I wasn't able to reproduce this with the upstream edk2 firmware I had on my seattle. I finally found my dediprog (lost during a recent move) and was able to install the AMI firmware and reproduce the problem. So, the iommus are *not* running in bypass mode but it still triggers global faults. It appears to be related to legacy arm,smmu DT bindings. The upstream edk2 uses the newer bindings where the older AMI uses the legacy bindings. I'm still not sure if there's a problem in the firmware tables or in the arm-smmu driver. In any case, this can be worked around with "arm-smmu.disable_bypass=n".


Note You need to log in before you can comment on or make changes to this bug.