Announcement

Collapse
No announcement yet.

AMDGPU hangup at boot with R9 M295X

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • AMDGPU hangup at boot with R9 M295X

    Hi,
    The problem I have with my R9 M295X card in a Dell 7710 is the following:
    With all "older" kernels (amdgpu drivers) I can only boot if I use the "nomodeset" boot option, otherwise the screen goes black (after a white flash) directly after the kernel and initrd is loaded.
    Fortunately, this changed when I upgraded my SuSE-Tumbleweed via the Kernel:/HEAD repository to the kernel kernel-default-4.5rc3.
    Everything was fine, especially after suspend to RAM it did come back with the backlight turned *on* and even the 3D-performance was great.
    Unfortunately, there came a new kernel-head update.
    With kernel-default-4.5rc4 the old behavior is back. The boot process stops (white flash then and black-screen and no reaction to any key anymore) after the kernel and initrd is loaded and it tries the KMS.
    To be clear: This is all independent of any X11. If I boot into run-level 3 the system also stop when KMS is activated.

    Now I tried all I can do with the current kernel-sources (git master) disabling all other graphics cards (Intel) and so on, but no success up to now.
    (also trying to compile kernel-4.5rc3 doesn't help anymore, so the problem could be subtle).

    Any other hints how to get the KMS working on this system?
    Without KMS I can not suspend to RAM which is also the case with the fglrx 15.30.1025 driver, so the notebook is "quite" useless without this feature.

    Thanks a lot for your hints,
    Michael (quite desperate...)

  • #2
    Thanks for the proposal. I tried this way, also described here: https://en.opensuse.org/SDB:AMD_fglrx.
    Unfortunately, this resulted in new problems: the screen updates only when the mouse is moved. Strange...
    But to your proposal. The Dell Precision 7710 is Dell's top of the line and most recent notebook. I use the most recent BIOS (1.3.10) and enabled the "fast boot". I just timed the bootup. This notebook needs from pressing the power-button to grub 20 seconds. Then 10 more to boot. I have many applications all the time open and ssh-passphrases and gpg-keys have to be entered. This takes really quite a while to get everything back to where I left it. Turning off a laptop which you use many times a day also to quickly answer emails is not really an alternative for my use-case.

    But the world is really strange:
    Today, it booted with the 4.5.0-rc4-2.gea92baf-default kernel and amdgpu with kms *worked*. I have no idea why...
    It hang for a short while in the black screen state and then continued, which it normally doesn't....
    Here are most likely the relevant entries in the log:
    Feb 21 14:32:59 r5 kernel: [drm] fb mappable at 0xC0BAA000
    Feb 21 14:32:59 r5 kernel: [drm] vram apper at 0xC0000000
    Feb 21 14:32:59 r5 kernel: [drm] size 33177600
    Feb 21 14:32:59 r5 kernel: [drm] fb depth is 24
    Feb 21 14:32:59 r5 kernel: [drm] pitch is 15360
    Feb 21 14:32:59 r5 kernel: fbcon: amdgpudrmfb (fb0) is primary device
    Feb 21 14:33:06 r5 kernel: Console: switching to colour frame buffer device 480x135
    Feb 21 14:33:06 r5 kernel: amdgpu 0000:01:00.0: fb0: amdgpudrmfb frame buffer device
    Feb 21 14:33:06 r5 kernel: [drm] ib test on ring 0 succeeded in 0 usecs
    Feb 21 14:33:06 r5 kernel: [drm] ib test on ring 1 succeeded in 0 usecs
    Feb 21 14:33:06 r5 kernel: [drm] ib test on ring 2 succeeded in 0 usecs
    Feb 21 14:33:06 r5 kernel: [drm] ib test on ring 3 succeeded in 0 usecs
    Feb 21 14:33:06 r5 kernel: [drm] ib test on ring 4 succeeded in 0 usecs
    Feb 21 14:33:06 r5 kernel: [drm] ib test on ring 5 succeeded in 0 usecs
    Feb 21 14:33:06 r5 kernel: [drm] ib test on ring 6 succeeded in 0 usecs
    Feb 21 14:33:06 r5 kernel: [drm] ib test on ring 7 succeeded in 0 usecs
    Feb 21 14:33:06 r5 kernel: [drm] ib test on ring 8 succeeded in 0 usecs
    Feb 21 14:33:06 r5 kernel: [drm] ib test on ring 9 succeeded in 0 usecs
    Feb 21 14:33:06 r5 kernel: [drm] ib test on ring 10 succeeded in 0 usecs
    Feb 21 14:33:06 r5 kernel: [drm] ib test on ring 11 succeeded
    Feb 21 14:33:06 r5 kernel: [drm] ib test on ring 12 succeeded
    Feb 21 14:33:06 r5 kernel: [drm] Initialized amdgpu 3.1.0 20150101 for 0000:01:00.0 on minor 0

    For 7 seconds it was stuck, but then it continued.
    I bet, when I reboot it again, it will stay stuck...
    Any hints?

    Comment


    • #3
      I don't dual-boot with windows. i only have linux on the notebook. And the correct EFI-path for grub is used, as I can check in the UEFI-settings GUI (F12 while boot).
      Do I understand you correctly, that you say that in the UEFI there exists a *very* fast boot method, which directly runs the grubx64.efi directly after pressing the power button. Because the UEFI itself is also quite slow: To go into the UEFI settings menu also takes 20s, so I assumed that booting in the UEFI (most likely also running a small LINUX) just takes 20s and there is no way around it.... Thanks for all the tips!
      Back to the original problem:
      It is getting stranger and stranger... So, after reboot the problem came back. The time the systems blocks while initializing the KMS seems to be undetermined. Yesterday I left it with the black screen for 10 minutes and suddenly it continued to boot and KMS worked (also suspend to RAM) and 3D performance was good! I have to try the boot some times more to learn *if* and when it will continue with the boot process.... When it is in the correct mode once, I'm happy for quite a while (until a new kernel-update is needed)...
      I doubt that it is really bad for the battery if the notebook is in suspend to RAM and connected to the power supply. The supplies are today very efficient and the battery will only drain very slowly and only be charged if necessary. Yes, there is a small effect (more discharges and charges than *really* necessary, but this is a device to be used and the battery is one part which has to be replaced after 2 years...
      Thanks again for your suggestions!

      Comment


      • #4
        Are we not doing a sufficiently good job of communicating that upstream amdgpu support should still be considered experimental and not recommended for general use ? Testing is appreciated but the code is still under development.

        When you say "broke", do you mean the longer boot time or something else ?
        Test signature

        Comment

        Working...
        X