Bug 41971

Summary: [kms] Muxless radeon takes 20 seconds to fetch rom
Product: DRI Reporter: Mike Lothian <mike>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: mike
Version: XOrg git   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg
none
System ACPI Info
none
New dmesg with debugging
none
Newest dmesg
none
Dmesg with added chunks :D none

Description Mike Lothian 2011-10-18 12:18:17 UTC
Created attachment 52491 [details] [review]
dmesg

My laptop has muxless switchable graphics but it seems to spend >20 seconds during boot in the radeon drm before handing off to the intel modesetting
Comment 1 Mike Lothian 2011-10-18 12:19:06 UTC
here's my lspci:


0:00.0 Host bridge [0600]: Intel Corporation Device [8086:0104] (rev 09)
00:01.0 PCI bridge [0604]: Intel Corporation Device [8086:0101] (rev 09)
00:01.1 PCI bridge [0604]: Intel Corporation Sandy Bridge PCI Express Root Port [8086:0105] (rev 09)
00:01.2 PCI bridge [0604]: Intel Corporation Sandy Bridge PCI Express Root Port [8086:0109] (rev 09)
00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:0116] (rev 09)
00:16.0 Communication controller [0780]: Intel Corporation Cougar Point HECI Controller #1 [8086:1c3a] (rev 04)
00:1a.0 USB Controller [0c03]: Intel Corporation Cougar Point USB Enhanced Host Controller #2 [8086:1c2d] (rev 05)
00:1b.0 Audio device [0403]: Intel Corporation Cougar Point High Definition Audio Controller [8086:1c20] (rev 05)
00:1c.0 PCI bridge [0604]: Intel Corporation Cougar Point PCI Express Root Port 1 [8086:1c10] (rev b5)
00:1c.4 PCI bridge [0604]: Intel Corporation Cougar Point PCI Express Root Port 5 [8086:1c18] (rev b5)
00:1c.7 PCI bridge [0604]: Intel Corporation Cougar Point PCI Express Root Port 8 [8086:1c1e] (rev b5)
00:1d.0 USB Controller [0c03]: Intel Corporation Cougar Point USB Enhanced Host Controller #1 [8086:1c26] (rev 05)
00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:1c49] (rev 05)
00:1f.2 SATA controller [0106]: Intel Corporation Cougar Point 6 port SATA AHCI Controller [8086:1c03] (rev 05)
00:1f.3 SMBus [0c05]: Intel Corporation Cougar Point SMBus Controller [8086:1c22] (rev 05)
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Device [1002:6741]
09:00.0 Network controller [0280]: Intel Corporation Device [8086:0090] (rev 34)
0a:00.0 Ethernet controller [0200]: Attansic Technology Corp. Device [1969:1083] (rev c0)
0b:00.0 USB Controller [0c03]: NEC Corporation Device [1033:0194] (rev 04)

Please let me know if you need anything else
Comment 2 Mike Lothian 2011-10-18 12:35:38 UTC
Created attachment 52493 [details]
System ACPI Info
Comment 3 Mike Lothian 2011-10-18 12:40:14 UTC
Created attachment 52494 [details]
New dmesg with debugging
Comment 4 Mike Lothian 2011-10-18 12:52:23 UTC
Created attachment 52496 [details]
Newest dmesg
Comment 5 Mike Lothian 2011-10-18 13:05:53 UTC
Created attachment 52497 [details]
Dmesg with added chunks :D
Comment 6 Eugeni Dodonov 2011-10-19 04:53:38 UTC
@Mike - could you try with the patch from bug #41059, which is at http://cgit.freedesktop.org/~eugeni/kernel? There is one patch at http://cgit.freedesktop.org/~eugeni/kernel/commit/?h=edid-i915 and another at http://cgit.freedesktop.org/~eugeni/kernel/commit/?h=edid-drm, they do the same thing but on different levels. There is no need to apply them both at the same time, just one at a time.

Could you check if any of those would fix - or improve - the issue for you?

Thanks!
Comment 7 Eugeni Dodonov 2011-10-19 04:54:59 UTC
(I know that you already tested them via my blog post, but I added some small changes to them - try booting with 'drm.debug=0.04' with both of those patches now, and attach the dmesg with timing results in both case).
Comment 8 Eugeni Dodonov 2011-10-19 04:55:52 UTC
Errrr of course, I meant drm.debug=0x04. In the morning, I guess I type faster than I mentally spell-check :).
Comment 9 Alex Deucher 2011-10-19 06:48:39 UTC
(In reply to comment #6)
> @Mike - could you try with the patch from bug #41059, which is at
> http://cgit.freedesktop.org/~eugeni/kernel? There is one patch at
> http://cgit.freedesktop.org/~eugeni/kernel/commit/?h=edid-i915 and another at
> http://cgit.freedesktop.org/~eugeni/kernel/commit/?h=edid-drm, they do the same
> thing but on different levels. There is no need to apply them both at the same
> time, just one at a time.
> 
> Could you check if any of those would fix - or improve - the issue for you?

The problem here has nothing to do with modesetting.  There are no displays even attached to the radeon.  The delay is due to fetching the rom from acpi.  I've updated the summary appropriately.
Comment 10 Mike Lothian 2011-10-26 13:16:58 UTC
I was wondering what actions I could take next

Would it be possible to have the switcheroo code detect that the laptop is muxless and disable the radeon card from the start?
Comment 11 Mike Lothian 2011-11-02 06:29:06 UTC
I've removed the vgaswitcheroo and radeon options from my kernel and my boot time has returned to normal, as I have a muxless laptop not having the card available makes no difference just now 

When no module is loaded is the card still drawing power?
Comment 12 Alex Deucher 2011-11-02 06:37:47 UTC
(In reply to comment #11)
> 
> When no module is loaded is the card still drawing power?

It depends whether the bios turns it on by default or not.  If it's off, you are not drawing power.  If it's on, you can turn it off via vgaswitcheroo.
Comment 13 Mike Lothian 2011-11-02 09:02:00 UTC
Is there a way for switcheroo to detect a muxless laptop and automatically switch it off (if it isn't already)
Comment 14 Mike Lothian 2011-11-13 19:38:21 UTC
I just thought I'd add I've now compiled radeon as a module and it only takes 2 seconds to load the BIOS when modprobed after everything else is loaded
Comment 16 Mike Lothian 2012-02-21 10:29:55 UTC
Yes it's still an issue
Comment 17 Mike Lothian 2012-11-14 03:27:52 UTC
I'm not sure when this was fixed but it's now no longer an issue

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.