Bug 92974

(In reply to charlie from comment #0)
> With AMD Powerplay disabled in the kernel there are no startup issues.

Do you mean CONFIG_DRM_AMD_POWERPLAY=n in .config or amdgpu.powerplay=0 on the kernel command line?


> Toggling or including/excluding these kernel boot, "lilo.conf" options have
> no effect on the bug: "amdgpu.enable_scheduler=0 ; radeon.modeset=1 ;
> radeon.hw_i2c=1 ; radeon.disp_priority=2 ; radeon.fastfb=1 ;
> radeon.backlight=1 ; radeon.pcie_gen2=-1 ; radeon.hard_reset=0"

radeon.* parameters don't have any effect with the amdgpu driver.

Sorry for the delay in response.  My computer was down.

I mean with CONFIG_DRM_AMD_POWERPLAY=n in kernel the ".config" file the computer starts up normally and X starts normally too without a 2 minute delay after each.

With CONFIG_DRM_AMD_POWERPLAY=y in the kernel .config file there are two minute delays at boot and also after type, "startx".

However with CONFIG_DRM_AMD_POWERPLAY=y in kernel this delay/bug can be bypassed if, "Device Drivers/Graphics support/Direct Rendering Manager/Enable legacy fbdev support for your modesetting driver" is set to, "n".  I don't know what ".config" line name is for that option which I set using, "make menuconfig".  Bypassing the bug this way just causes a blank screen however I can still login blind and start X to a normal display.  Or I can use KDM or SDDM to auto-login for me.

What if you enable building the PowerPlay code with CONFIG_DRM_AMD_POWERPLAY=y but disable it at runtime with amdgpu.powerplay=0 on the kernel command line? Does the problem occur then or not?

With these options there is no ~2 minute kernel boot or startx delay bug:

CONFIG_DRM_AMD_POWERPLAY=y in kernel ".config"

"Device Drivers/Graphics support/Direct Rendering Manager/Enable legacy fbdev support for your modesetting driver" set to, "y" in kernel "make menuconfig".

"amdgpu.powerplay=0" on lilo append line.

I recently tried out kernel code up to this version: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=amdgpu-powerplay&id=a7b21a9055f2576df9ff69d52811a047b9399e36

There has been no change--bug remains.

Created attachment 120362 [details]
dmesg Friday Dec. 4, 2015

I recently compiled this kernel version: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=amdgpu-powerplay&id=ab72939ad61cc7c22b03946cac94153a1fa23e43

There was no change in the bug.  I'll submit my kernel ".config" as well.

Created attachment 120363 [details]
Kernel config Dec. 4, 2015

This commit:

"drm/amdgpu/powerplay/fiji: query supported pcie info from cgs (v2)"

http://cgit.freedesktop.org/~agd5f/linux/commit/?h=amdgpu-powerplay&id=64797db892500bc02f5f15524aca3be97368b7f9

and everything after the above commit has the long boot bug.

______________________

This commit:

"drm/amdgpu/powerplay/tonga: query supported pcie info from cgs (v2)"

http://cgit.freedesktop.org/~agd5f/linux/commit/?h=amdgpu-powerplay&id=211e86eee365c63028c2f25978b964caa9ad622e

does not have the long boot bug on Fiji Nano.

______________________

I did a "git reset --hard HEAD~49" (among others...) from the current git at "amd/powerplay: don't enable ucode fan control if vbios has no fan table" to eventually get to a normal boot.

Created attachment 120642 [details] [review]
disable pcie dpm

Does this patch help?

Created attachment 120643 [details] [review]
disable pcie gen3 switching

Please try this patch independent of the previous one.

Both patches ("disable_gen3.diff" and "fiji_disable_pcie_dpm.diff") applied independently of each other work.  The kernel boots normally and X starts normally.

These commands were issued before each *.diff was applied and compiled:
"git clean -dxf ; git fetch --all ; git reset --hard origin/amdgpu-powerplay"

I'm now using "drm-next-4.8-wip" (from https://cgit.freedesktop.org/~agd5f/linux/).  I still require "fiji_disable_pcie_dpm.diff" to overcome the bug.  I can't remember if "disable_gen3.diff" no longer patches cleanly or does not work once the kernel is compiled.  In any case, "disable_gen3.diff" is no longer effective.

Is this a bios issue?  If so, then I can upgrade to the latest bios for my motherboard to see if the bug persists without patching the kernel.

(In reply to charlie from comment #13)
> I'm now using "drm-next-4.8-wip" (from
> https://cgit.freedesktop.org/~agd5f/linux/).  I still require
> "fiji_disable_pcie_dpm.diff" to overcome the bug.  I can't remember if
> "disable_gen3.diff" no longer patches cleanly or does not work once the
> kernel is compiled.  In any case, "disable_gen3.diff" is no longer effective.
> 
> Is this a bios issue?  If so, then I can upgrade to the latest bios for my
> motherboard to see if the bug persists without patching the kernel.

It could be.  Does a new bios help?  We've seen similar issues with certain boards internally.  What CPU/motherboard is this?  If your board has options for configuring the default pcie gen or generic pcie performance options does changing any of them help?

(In reply to charlie from comment #13)
> I'm now using "drm-next-4.8-wip" (from
> https://cgit.freedesktop.org/~agd5f/linux/).  I still require
> "fiji_disable_pcie_dpm.diff" to overcome the bug.  I can't remember if
> "disable_gen3.diff" no longer patches cleanly or does not work once the
> kernel is compiled.  In any case, "disable_gen3.diff" is no longer effective.
>

On newer kernels you can configure the supported pcie gen modes via module option.  E.g., append:
amdgpu.pcie_gen_cap=0x00030003
to the kernel command line in grub to limit the bus and the card to pcie gen2.

Motherboard: Asus A88X-PRO
APU: AMD A10-7850K (monitor only receiving R9 Nano output)

I will update the bios and see if there are any "new pcie gen or generic pcie performance options".

I report back on the use of "amdgpu.pcie_gen_cap=0x00030003" in lilo although  "PCIe 3.0" is printed on the motherboard.

The bios was updated from 0801 to 2603. The machine booted normally with an unpatched kernel.  I restored previous overclocking settings and the long boot bug returned.  Among testing a few bios parameters I found that adjusting "NB Configuration--PCIEX16_1"--like forcing auto(PCIEX16_2), X16 or X8--has no effect on the bug.

"APU Frequency" or base clock is the only setting found to effect the long boot/startx bug.  Any base clock values greater than 100 causes the bug.  Underclocking CPU, NB and RAM has no effect when base clock is set to 101--the bug remains.

This behavior did not occur before the commit mentioned earlier in this bug report thread as the base clock remained the same since before I first submitted the bug and until my recent testing today.

With "amdgpu.pcie_gen_cap=0x00030003" applied through LILO this machine is capable of running at 104 base clock stable with system RAM near 2500mhz--without the long boot/startx bug.

-- 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/59.