Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1918888 - coresight backtraces when booting ThunderX2
Summary: coresight backtraces when booting ThunderX2
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 33
Hardware: aarch64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2021-01-21 16:31 UTC by Paul Whalen
Modified: 2021-01-21 18:28 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:

Attachments (Terms of Use)
dmesg.txt (449.77 KB, text/plain)
2021-01-21 16:33 UTC, Paul Whalen 		no flags Details
View All

Description Paul Whalen 2021-01-21 16:31:07 UTC 
1. Please describe the problem:

Coresight backtraces when booting ThunderX2

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

Seeing this in Rawhide and F33

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.10.0-98.fc33

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

Boot on ThunderX2

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 2021-01-21 16:33:52 UTC 
Created attachment 1749451 [details]
dmesg.txt
Comment 2 Jeremy Linton 2021-01-21 18:28:30 UTC 
Per Suzuki Poulose:

The bindings clearly show that the funnel descriptions are messed up. For e.g,

_SB.NOD1.CP00.THD0.ETM0
_SB.NOD1.CP08.THD0.ETM0
_SB.NOD1.CP08.THD1.ETM0
_SB.NOD1.CP08.THD2.ETM0
_SB.NOD1.CP08.THD3.ETM0
_SB_.NOD1.CP09.THD1.ETM0

They all "connect" to port 0 of the _SB.NOD1.FUN0. But if you look at the Node for NOD1.FUN0, it lists _SB.NOD1.CP00.THD0.ETM0 as the other end. It looks like a copy-paste error and has forgot to update the FUN for each of the items.
Note You need to log in before you can comment on or make changes to this bug.