Bug 105728

Summary: radeon_init takes longer than a few milliseconds
Product: DRI Reporter: Paul Menzel <pmenzel+bugs.freedesktop.org>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium CC: pmenzel+bugs.freedesktop.org
Version: DRI git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Screenshot from HTML output of `bootgraph.py` none

Description Paul Menzel 2018-03-24 10:39:07 UTC
On a Asus F2A85-M PRO with an AMD A6-6400K APU with Radeon HD Graphics and Linux 4.14.13 `radeon_init`, according to `initcall_debug`, takes over two seconds to execute. Init functions should not take longer than a few milliseconds to load.

```
$ sudo dmesg | grep -i radeon
[   18.767379] calling  radeon_init+0x0/0xab [radeon] @ 292
[   18.767382] [drm] radeon kernel modesetting enabled.
[   18.809797] radeon 0000:00:01.0: VRAM: 768M 0x0000000000000000 - 0x000000002FFFFFFF (768M used)
[   18.809798] radeon 0000:00:01.0: GTT: 1024M 0x0000000030000000 - 0x000000006FFFFFFF
[   18.811498] [drm] radeon: 768M of VRAM memory ready
[   18.811499] [drm] radeon: 1024M of GTT memory ready.
[   18.812019] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/ARUBA_pfp.bin
[   18.812512] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/ARUBA_me.bin
[   18.812674] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/ARUBA_rlc.bin
[   18.812813] [drm] radeon: dpm initialized
[   18.813730] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/TAHITI_uvd.bin
[   18.814178] radeon 0000:00:01.0: firmware: direct-loading firmware radeon/TAHITI_vce.bin
[   18.867545] radeon 0000:00:01.0: WB enabled
[   18.867549] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000030000c00 and cpu addr 0xffff8a5af9339c00
[   18.867928] radeon 0000:00:01.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffab8a01435a18
[   18.888018] radeon 0000:00:01.0: fence driver on ring 6 use gpu addr 0x0000000030000c18 and cpu addr 0xffff8a5af9339c18
[   18.888021] radeon 0000:00:01.0: fence driver on ring 7 use gpu addr 0x0000000030000c1c and cpu addr 0xffff8a5af9339c1c
[   18.888022] radeon 0000:00:01.0: fence driver on ring 1 use gpu addr 0x0000000030000c04 and cpu addr 0xffff8a5af9339c04
[   18.888024] radeon 0000:00:01.0: fence driver on ring 2 use gpu addr 0x0000000030000c08 and cpu addr 0xffff8a5af9339c08
[   18.888025] radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000030000c0c and cpu addr 0xffff8a5af9339c0c
[   18.888026] radeon 0000:00:01.0: fence driver on ring 4 use gpu addr 0x0000000030000c10 and cpu addr 0xffff8a5af9339c10
[   18.916268] radeon 0000:00:01.0: radeon: MSI limited to 32-bit
[   18.917088] radeon 0000:00:01.0: radeon: using MSI.
[   18.917113] [drm] radeon: irq initialized.
[   20.736792] [drm] Radeon Display Connectors
[   21.035055] fbcon: radeondrmfb (fb0) is primary device
[   21.152576] radeon 0000:00:01.0: fb0: radeondrmfb frame buffer device
[   21.172202] [drm] Initialized radeon 2.50.0 20080528 for 0000:00:01.0 on minor 0
[   21.172314] initcall radeon_init+0x0/0xab [radeon] returned 0 after 2348527 usecs
[  126.973651] radeon_dp_aux_transfer_native: 74 callbacks suppressed
```
Comment 1 Paul Menzel 2018-03-24 10:55:24 UTC
Created attachment 138334 [details]
Screenshot from HTML output of `bootgraph.py`

`bootgraph.py` [1][2] gives the result below.

> radeon_init: start=14003.930, end=16336.770, length(w/o overhead)=2278.062 ms, return=0

Most of the time is spent in `local_pci_probe (2322.816 ms @ 14.013451)`.

Set it up, using `sudo ./bootgraph.py -f -fstat -maxdepth 10 -manual` to see what to add to `/boot/grub/grub.cfg`. Then reboot, and execute `sudo ./bootgraph.py -f -fstat -maxdepth 10`.

If your system is powerful enough, you can use a higher maximum depth. I didn’t get around how `-cgfilter` works to get smaller HTML files.

[1] https://01.org/suspendresume
[2] https://github.com/01org/pm-graph
Comment 2 Martin Peres 2019-11-19 09:32:59 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/848.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.