https://bugzilla.kernel.org/show_bug.cgi?id=71891
Bug ID: 71891 Summary: 3.13 fails to boot with the radeon module Product: Drivers Version: 2.5 Kernel Version: 3.13.6-1-ARCH Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri@kernel-bugs.osdl.org Reporter: sh.siddhartha@gmail.com Regression: No
$ lspci -k | grep -A3 VGA 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV730/M96 [Mobility Radeon HD 4650/5165] Subsystem: Dell Device 0447 Kernel driver in use: fglrx_pci Kernel modules: radeon, fglrx
Dell Inspiron N5010 (BIOS)
Legacy catalyst works properly. Using the open source radeon driver either boots to tty login with above errors, or boots to a locked up black screen.
drm syslog: [drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver [drm] initializing kernel modesetting (RV730 0x1002:0x9480 0x1028:0x0447). [drm] register mmio base: 0xFBE20000 [drm] register mmio size: 65536 [drm] Detected VRAM RAM=1024M, BAR=256M [drm] RAM width 128bits DDR [drm] radeon: 1024M of VRAM memory ready [drm] radeon: 1024M of GTT memory ready. [drm] GART: num cpu pages 262144, num gpu pages 262144 [drm] Loading RV730 Microcode [drm] PCIE GART of 1024M enabled (table at 0x000000000025D000). [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] ring test on 0 succeeded in 1 usecs [drm] ring test on 3 succeeded in 1 usecs [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [drm:uvd_v1_0_start] *ERROR* UVD not responding, giving up!!! [drm:rv770_startup] *ERROR* radeon: failed initializing UVD (-1). [drm] Enabling audio 0 support [drm] ib test on ring 0 succeeded in 0 usecs [drm] ib test on ring 3 succeeded in 0 usecs [drm] radeon atom DIG backlight initialized [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA-1 [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] HDMI-A-1 [drm] HPD1 [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY [drm] Connector 2: [drm] LVDS-1 [drm] DDC: 0x7f68 0x7f68 0x7f6c 0x7f6c 0x7f70 0x7f70 0x7f74 0x7f74 [drm] Encoders: [drm] LCD1: INTERNAL_UNIPHY2 [drm] Internal thermal controller with fan control [drm] radeon: dpm initialized [drm] fb mappable at 0xC045E000 [drm] vram apper at 0xC0000000 [drm] size 4325376 [drm] fb depth is 24 [drm] pitch is 5632 fbcon: radeondrmfb (fb0) is primary device [drm:rv770_dpm_set_power_state] *ERROR* rv770_restrict_performance_levels_before_switch failed radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device [drm] Initialized radeon 2.36.0 20080528 for 0000:01:00.0 on minor 0
https://bugzilla.kernel.org/show_bug.cgi?id=71891
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexdeucher@gmail.com
--- Comment #1 from Alex Deucher alexdeucher@gmail.com --- Is this a regression? If so when did it last work? Does booting with radeon.dpm=0 on the kernel command line in grub help?
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #2 from sdh sh.siddhartha@gmail.com --- Booting with 3.12 kernel gives no such error. Using 3.13, booting from the Arch install iso gives the above errors.
The only difference with radeon.dpm=0 is that the line "rv770_restrict_performance_levels_before_switch failed" disappears.
I suppose this is related to the issue I faced with 3.10, where I could successfully boot using a install iso, but installing xorg + ati-dri and rebooting lead to a locked up black screen. In 3.13, it occurs in the initial booting itself.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #3 from Alex Deucher alexdeucher@gmail.com --- if 3.12 works, can you use git to bisect?
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #4 from sdh sh.siddhartha@gmail.com --- Have never done it before. Will attempt to do it when I have some free time and report back :)
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #5 from sdh sh.siddhartha@gmail.com --- Finally got around to doing this. And the result:
ec5891fbe1b078b191b25a13a2cc40b58fb7a693 is the first bad commit commit ec5891fbe1b078b191b25a13a2cc40b58fb7a693 Author: Christian König deathsimple@vodafone.de Date: Mon Apr 8 12:41:36 2013 +0200
drm/radeon: init UVD clocks to sane defaults
Just until we get proper DPM for that.
Signed-off-by: Christian König christian.koenig@amd.com Reviewed-by: Jerome Glisse jglisse@redhat.com Signed-off-by: Alex Deucher alexander.deucher@amd.com
:040000 040000 e76a3b2d04c78c73e66b5882155dbf1a26651282 900d340c7fc5a2952f1c4e38a17062e466a0b70a Mdrivers
So this has been present since 3.10, but was triggered only after installing the radeon driver (xf86-video-ati in Arch Linux). From 3.13 onwards, this is always triggered. But that may only be due to config changes in the Arch installer.
This is a one line edit, which later was shifted to a different function. Is enough to resolve the bug (which is still present in the latest kernel tested until v3.14-7247-gcd6362b).
Thanks
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #6 from sdh sh.siddhartha@gmail.com --- s/Is enough/Is it enough/ Sorry for the typo, meant it as a question.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
Christian König deathsimple@vodafone.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |deathsimple@vodafone.de
--- Comment #7 from Christian König deathsimple@vodafone.de --- Well, have you updated the firmware as well while upgrading to 3.13?
The driver now needs both new UVD firmware and updated RLC firmware present.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #8 from sdh sh.siddhartha@gmail.com --- I suppose you mean these firmwares: http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree...
The Arch Linux package is built from the latest commit, and is installed on my laptop.
% modinfo radeon | grep firmware | grep uvd firmware: radeon/BONAIRE_uvd.bin firmware: radeon/TAHITI_uvd.bin firmware: radeon/SUMO_uvd.bin firmware: radeon/CYPRESS_uvd.bin firmware: radeon/RV710_uvd.bin
% modinfo radeon | grep firmware | grep rlc firmware: radeon/SUMO_rlc.bin firmware: radeon/CYPRESS_rlc.bin firmware: radeon/JUNIPER_rlc.bin firmware: radeon/REDWOOD_rlc.bin firmware: radeon/CEDAR_rlc.bin firmware: radeon/R700_rlc.bin firmware: radeon/R600_rlc.bin firmware: radeon/ARUBA_rlc.bin firmware: radeon/CAYMAN_rlc.bin firmware: radeon/BTC_rlc.bin firmware: radeon/HAINAN_rlc.bin firmware: radeon/OLAND_rlc.bin firmware: radeon/VERDE_rlc.bin firmware: radeon/PITCAIRN_rlc.bin firmware: radeon/TAHITI_rlc.bin firmware: radeon/KABINI_rlc.bin firmware: radeon/KAVERI_rlc.bin firmware: radeon/HAWAII_rlc.bin firmware: radeon/BONAIRE_rlc.bin
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #9 from sdh sh.siddhartha@gmail.com --- Hi,
Any update on this? Is there any other information required to fix the bug?
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #10 from Christian König deathsimple@vodafone.de --- Created attachment 131871 --> https://bugzilla.kernel.org/attachment.cgi?id=131871&action=edit Possible fix.
Please try the attached patch.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #11 from sdh sh.siddhartha@gmail.com --- Nopes. It makes the UVD errors go away, but the boot still gets stuck at the same point. Everything hangs up, requiring me to do a hard reboot.
Weirdly, I could not find any errors in either syslog or Xorg, which makes me feel I'm doing something wrong on my side (but I compiled it exactly like in the official repo, with the additional patch).
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #12 from Christian König deathsimple@vodafone.de --- (In reply to sdh from comment #11)
Nopes. It makes the UVD errors go away, but the boot still gets stuck at the same point. Everything hangs up, requiring me to do a hard reboot.
Well that the UVD errors go away is already an rather interesting result. Please attach a new dmesg log if possible.
Weirdly, I could not find any errors in either syslog or Xorg, which makes me feel I'm doing something wrong on my side (but I compiled it exactly like in the official repo, with the additional patch).
Your compile is probably working right, but it is possible that we actually see two different problems here.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #13 from sdh sh.siddhartha@gmail.com --- Can you suggest me a good way to debug this and read the logs? Everything hangs up, so I do a hard reboot and start with nomodeset parameter to see the logs. Is there a better way to do this?
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #14 from Christian König deathsimple@vodafone.de --- (In reply to sdh from comment #13)
Can you suggest me a good way to debug this and read the logs? Everything hangs up, so I do a hard reboot and start with nomodeset parameter to see the logs. Is there a better way to do this?
Not sure how to do it on Arch, but on Ubuntu I would but the radeon module on the blacklist and boot into text only mode.
Then SSH into the system over the network, load the radeon module manually. If that doesn't crash try to also start X manually.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #15 from sdh sh.siddhartha@gmail.com --- Thanks, that helped :)
Doing a 'modprobe radeon' after booting up gives the following errors: radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000000002 last fence id 0x0000000000000000 on ring 5) [drm:uvd_v1_0_ib_test] *ERROR* radeon: fence wait failed (-35). [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-35).
Doing a startx completely hangs up the system
Full log: # journalctl --since="2014-04-12" -o cat | grep 'drm|radeon' [drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver [drm] initializing kernel modesetting (RV730 0x1002:0x9480 0x1028:0x0447). [drm] register mmio base: 0xFBE20000 [drm] register mmio size: 65536 radeon 0000:01:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used) radeon 0000:01:00.0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF [drm] Detected VRAM RAM=1024M, BAR=256M [drm] RAM width 128bits DDR [drm] radeon: 1024M of VRAM memory ready [drm] radeon: 1024M of GTT memory ready. [drm] Loading RV730 Microcode [drm] Internal thermal controller with fan control [drm] radeon: dpm initialized [drm] GART: num cpu pages 262144, num gpu pages 262144 [drm] PCIE GART of 1024M enabled (table at 0x000000000025D000). radeon 0000:01:00.0: WB enabled radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff8800b665cc00 radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff8800b665cc0c radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x000000000005c598 and cpu addr 0xffffc90012f1c598 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. radeon 0000:01:00.0: irq 50 for MSI/MSI-X radeon 0000:01:00.0: radeon: using MSI. [drm] radeon: irq initialized. [drm] ring test on 0 succeeded in 1 usecs [drm] ring test on 3 succeeded in 1 usecs [drm] ring test on 5 succeeded in 1 usecs [drm] UVD initialized successfully. [drm] ib test on ring 0 succeeded in 0 usecs [drm] ib test on ring 3 succeeded in 0 usecs radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000000002 last fence id 0x0000000000000000 on ring 5) [drm:uvd_v1_0_ib_test] *ERROR* radeon: fence wait failed (-35). [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-35). Starting Load/Save Screen Backlight Brightness of backlight:radeon_bl0... Started Load/Save Screen Backlight Brightness of backlight:radeon_bl0. [drm] radeon atom DIG backlight initialized [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA-1 [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] HDMI-A-1 [drm] HPD1 [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY [drm] Connector 2: [drm] LVDS-1 [drm] DDC: 0x7f68 0x7f68 0x7f6c 0x7f6c 0x7f70 0x7f70 0x7f74 0x7f74 [drm] Encoders: [drm] LCD1: INTERNAL_UNIPHY2 [drm] fb mappable at 0xC0460000 [drm] vram apper at 0xC0000000 [drm] size 4325376 [drm] fb depth is 24 [drm] pitch is 5632 fbcon: radeondrmfb (fb0) is primary device radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device radeon 0000:01:00.0: registered panic notifier [drm] Initialized radeon 2.37.0 20080528 for 0000:01:00.0 on minor 0 radeon 0000:01:00.0: GPU reset succeeded, trying to resume [drm:rv770_dpm_set_power_state] *ERROR* rv770_set_sw_state failed [drm] PCIE GART of 1024M enabled (table at 0x000000000025D000). radeon 0000:01:00.0: WB enabled radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff8800b665cc00 radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff8800b665cc0c radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x000000000005c598 and cpu addr 0xffffc90012f1c598
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #16 from sdh sh.siddhartha@gmail.com --- ping.
I guess the above response got lost in the huge amount of mails you must be receiving :)
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #17 from sdh sh.siddhartha@gmail.com --- ping again. I'm wondering whether you're very busy, or this email is getting buried in your inbox.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #18 from Christian König deathsimple@vodafone.de --- I did got your original message, I just didn't had time to look into it.
There must be something wrong with the clock settings for your system, I just don't know what it is.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #19 from sdh sh.siddhartha@gmail.com --- Anything I can do to help debug this?
https://bugzilla.kernel.org/show_bug.cgi?id=71891
Ciel Avenir cielartisan@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cielartisan@gmail.com
--- Comment #20 from Ciel Avenir cielartisan@gmail.com --- *** Bug 73111 has been marked as a duplicate of this bug. ***
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #21 from Christian König deathsimple@vodafone.de --- (In reply to sdh from comment #19)
Anything I can do to help debug this?
Well, do you have some experience with kernel hacking?
The problem is somewhere in rv770_set_uvd_clocks found in the kernel source file drivers/gpu/drm/radeon/rv770.c. Despite the name this function is used for RV710, RV730 (yours) and RV770.
The implementation works fine on my RV710, but it looks like on some asics the reference frequency (or something else) is different and so programming the PLL results in a way to high frequency and the whole box becomes completely unstable because of this.
A good start would be to get me the values of fb_div, vclk_div and dclk_div used in that function.
You could also try to play with the frequencies used for radeon_set_uvd_clocks. Defaults are 533MHz and 400MHz (e.g. radeon_set_uvd_clocks(rdev, 53300, 40000)), but using those seems to make your system unstable.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
Christian König deathsimple@vodafone.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #131871|0 |1 is obsolete| |
--- Comment #22 from Christian König deathsimple@vodafone.de --- Created attachment 133521 --> https://bugzilla.kernel.org/attachment.cgi?id=133521&action=edit Possible fix v2.
Meanwhile please test the attached patch.
It won't fix the issue, but might at least allow your system to boot.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #23 from sdh sh.siddhartha@gmail.com --- (In reply to Christian König from comment #22)
Possible fix v2. Meanwhile please test the attached patch. It won't fix the issue, but might at least allow your system to boot.
Yes indeed, thank you. Successfully booted to desktop using the radeon module. \m/
(In reply to Christian König from comment #21)
Well, do you have some experience with kernel hacking?
The git bisect I did earlier is the most I have done ^_^
The problem is somewhere in rv770_set_uvd_clocks found in the kernel source file drivers/gpu/drm/radeon/rv770.c. Despite the name this function is used for RV710, RV730 (yours) and RV770.
A good start would be to get me the values of fb_div, vclk_div and dclk_div used in that function.
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c index fef3107..2fbc787 100644 --- a/drivers/gpu/drm/radeon/rv770.c +++ b/drivers/gpu/drm/radeon/rv770.c @@ -67,6 +67,9 @@ int rv770_set_uvd_clocks(struct radeon_device *rdev, u32 vclk, u32 dclk) r = radeon_uvd_calc_upll_dividers(rdev, vclk, dclk, 50000, 160000, 43663, 0x03FFFFFE, 1, 30, ~0, &fb_div, &vclk_div, &dclk_div); + + pr_notice("SDH: %d %d %d",fb_div,vclk_div,dclk_div); + if (r) return r;
gives "SDH: 808574 5 5"
https://bugzilla.kernel.org/show_bug.cgi?id=71891
Dieter Nützel Dieter@nuetzel-hh.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Dieter@nuetzel-hh.de
--- Comment #24 from Dieter Nützel Dieter@nuetzel-hh.de --- Tested it on my RV730 AGP, too. The later values are after uvd playback.
Both kernels have these additional patches: drm-radeon-Inline-r100_mm_rreg-wreg-v3.patch drm-radeon-add-missing-radeon_semaphore_free-to-error-path.patch 0001-drm-radeon-print-uvd-clocks.patch
Other than that I can't see any change. mplayer startup took ~4 sec for HDTV (.mkv; 1920x1080p) stuff, sometimes longer with both values - Christian? Do you need full dmesg?
/home/dieter> grep SDH dmesg-3.15.0-rc2-1-desktop.log [ 11.455469] SDH: 2585818 3 4 [ 11.702222] SDH: 2585818 3 4 [ 4837.269874] SDH: 2585818 3 4 [ 4839.337562] SDH: 2585818 3 4 [ 4849.109778] SDH: 2585818 3 4 [ 4860.157849] SDH: 2585818 3 4 [ 4871.636301] SDH: 2585818 3 4 [ 4885.174251] SDH: 2585818 3 4
/home/dieter> grep SDH dmesg-3.15.0-rc2-1-desktop-lower-clocks.log [ 11.453487] SDH: 808574 5 5 [ 11.700600] SDH: 808574 5 5 [ 330.936109] SDH: 2585818 3 4 [ 332.969812] SDH: 2585818 3 4 [ 349.357418] SDH: 2585818 3 4 [ 371.532244] SDH: 2585818 3 4 [ 372.860656] SDH: 2585818 3 4 [ 387.290967] SDH: 2585818 3 4 [ 432.414145] SDH: 2585818 3 4 [ 433.611991] SDH: 2585818 3 4
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #25 from Christian König deathsimple@vodafone.de --- Thanks for testing this Dieter, that actually saved me quite some time.
The formular for the clock is (fb_div*ref_clock)/(fb_factor*post_div).
fb_factor is a fixed value comming from the hardware design (43663)
ref_clock (reference clock) is the external input clock to the RV730 asic, it's value is burned into the BIOS (usually 27MHz for R7xx).
fb_div and post_div are the values the driver calculates to get a certain frequency for the chip.
So for our values here we get: (808574*27MHz)/(43663*5) = ~100MHz (2585818*27MHz)/(43663*3) = ~533MHz (2585818*27MHz)/(43663*4) = ~400MHz Over all that looks perfectly fine.
Please provide the content of the registers CG_UPLL_FUNC_CNTL, CG_UPLL_FUNC_CNTL_2 and CG_UPLL_FUNC_CNTL_3. E.g. install radeontool and execute:
radeonreg regmatch 0x718 radeonreg regmatch 0x71c radeonreg regmatch 0x720
Thx, Christian.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #26 from Dieter Nützel Dieter@nuetzel-hh.de --- 0x718 0x20010002 (536936450) 0x71c 0x021f2111 (35594513) 0x720 0x102774da (271021274)
Only for 3.15.0-rc2-1-desktop-lower-clocks.
Do you need more? --- Need some sleep, badly!
Cheers, Dieter.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #27 from sdh sh.siddhartha@gmail.com --- (In reply to Christian König from comment #25)
Please provide the content of the registers CG_UPLL_FUNC_CNTL, CG_UPLL_FUNC_CNTL_2 and CG_UPLL_FUNC_CNTL_3. E.g. install radeontool and execute:
radeonreg regmatch 0x718 radeonreg regmatch 0x71c radeonreg regmatch 0x720
On my system (3.14.0-1-git), the values are: 0x718 0x20010002 (536936450) 0x71c 0x021f2222 (35594786) 0x720 0x100c567e (269244030)
https://bugzilla.kernel.org/show_bug.cgi?id=71891
Yuking yuking_net@sohu.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |yuking_net@sohu.com
--- Comment #28 from Yuking yuking_net@sohu.com --- My video card is HD6850, motherboard is ASUS P8Z68-LE.
System can not boot up with radeon module very often. After powerup, the screen always goes blank, no any information, and it will not reboot immediately after pressing the reset button ( Reboot occurs 10 or 15s later). System will boot up after pressing the reset button 2, 3, or even 7 times. And the whole system crashes very often after boot up normally, too. The system log has no any failure information after several boot failures. Version 3.13~3.15 or earlier versions have the same problem. Any idea about it?
P. S. Windows works very well.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #29 from Alex Deucher alexdeucher@gmail.com --- (In reply to Yuking from comment #28)
My video card is HD6850, motherboard is ASUS P8Z68-LE.
System can not boot up with radeon module very often. After powerup, the screen always goes blank, no any information, and it will not reboot immediately after pressing the reset button ( Reboot occurs 10 or 15s later). System will boot up after pressing the reset button 2, 3, or even 7 times. And the whole system crashes very often after boot up normally, too. The system log has no any failure information after several boot failures. Version 3.13~3.15 or earlier versions have the same problem. Any idea about it?
Your issue doesn't sound related to this bug. Please open a new bug and include your xorg log and dmesg output and note whether it is a regression or not.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #30 from sdh sh.siddhartha@gmail.com --- Hi. Any update on this?
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #31 from sdh sh.siddhartha@gmail.com --- I just noticed I'm getting the following errors during the sleep and wake up cycle:
[drm:rv730_stop_dpm] *ERROR* Could not force DPM to low [drm:rv770_dpm_set_power_state] *ERROR* rv770_set_sw_state failed
Kernel is 3.14.2-1-git-dirty with above patch
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #32 from Christian König deathsimple@vodafone.de --- (In reply to sdh from comment #30)
Hi. Any update on this?
I've pushed the workaround upstream. So you should at least have a booting system. Just don't try to use any accelerated video decoding since that would crash the box again.
My best guess is that the information in the BIOS about the reference frequency is wrong, but without having the hardware here I can't do much else to get UVD working properly.
(In reply to sdh from comment #31)
I just noticed I'm getting the following errors during the sleep and wake up cycle:
[drm:rv730_stop_dpm] *ERROR* Could not force DPM to low [drm:rv770_dpm_set_power_state] *ERROR* rv770_set_sw_state failed
Kernel is 3.14.2-1-git-dirty with above patch
Sounds like an unrelated DPM problem to me, but who knows.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #33 from Alex Deucher alexdeucher@gmail.com --- I wonder if UVD uses the reference clock directly, or if it uses xclk. If it uses xclk, they may explain the problems. Can you post your dmesg output with this patch applied?
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c index fef3107..bda9137 100644 --- a/drivers/gpu/drm/radeon/rv770.c +++ b/drivers/gpu/drm/radeon/rv770.c @@ -1594,6 +1594,9 @@ static void rv770_gpu_init(struct radeon_device *rdev) WREG32(PA_CL_ENHANCE, (CLIP_VTX_REORDER_ENA | NUM_CLIP_SEQ(3))); WREG32(VC_ENHANCE, 0); + + DRM_INFO("ref: %u, xclk: %u\n", + rdev->clock.spll.reference_freq, rv770_get_xclk(rdev)); }
void r700_vram_gtt_location(struct radeon_device *rdev, struct radeon_mc *mc)
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #34 from Christian König deathsimple@vodafone.de --- (In reply to Alex Deucher from comment #33)
I wonder if UVD uses the reference clock directly, or if it uses xclk. If it uses xclk, they may explain the problems.
They can be different? Yeah that would indeed explain the issue. AFAIK RV730 uses XTALIN directly for the UVD PLLs.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #35 from Dieter Nützel Dieter@nuetzel-hh.de --- (In reply to Alex Deucher from comment #33)
I wonder if UVD uses the reference clock directly, or if it uses xclk. If it uses xclk, they may explain the problems. Can you post your dmesg output with this patch applied?
Here is mine (with latest stuff from Christian):
[ 11.159443] [drm] initializing kernel modesetting (RV730 0x1002:0x9495 0x174B:0x0028).
[ 11.257005] [drm] ref: 2700, xclk: 2700
[ 11.263794] radeon 0000:01:00.0: WB disabled <--- Is this intended?
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV730 [Radeon HD 4600 AGP Series] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited / Sapphire Technology Radeon HD 4650 AGP DDR2 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 Memory at c0000000 (32-bit, prefetchable) [size=256M] I/O ports at a800 [size=256] Memory at dfdf0000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at dfdc0000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] AGP version 3.0 Kernel driver in use: radeon Kernel modules: radeon
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #36 from Alex Deucher alexdeucher@gmail.com --- (In reply to Dieter Nützel from comment #35)
(In reply to Alex Deucher from comment #33)
I wonder if UVD uses the reference clock directly, or if it uses xclk. If it uses xclk, they may explain the problems. Can you post your dmesg output with this patch applied?
Here is mine (with latest stuff from Christian):
[ 11.159443] [drm] initializing kernel modesetting (RV730 0x1002:0x9495 0x174B:0x0028).
[ 11.257005] [drm] ref: 2700, xclk: 2700
On your board (and most boards) they are the same, so your board would not be affected if this proves to be an issue.
[ 11.263794] radeon 0000:01:00.0: WB disabled <--- Is this intended?
On AGP cards, WB is disabled.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #37 from sdh sh.siddhartha@gmail.com --- (In reply to Christian König from comment #32)
I've pushed the workaround upstream. So you should at least have a booting system. Just don't try to use any accelerated video decoding since that would crash the box again.
Cool, so 3.15 will boot normally for me, thanks! \m/ I am able to play games like Batman Arkham Origins (using wine) without crashing, so no issues so far.
My best guess is that the information in the BIOS about the reference frequency is wrong, but without having the hardware here I can't do much else to get UVD working properly.
Everything is working properly for now. What issues could I face because of this workaround?
(In reply to Alex Deucher from comment #33)
I wonder if UVD uses the reference clock directly, or if it uses xclk. If it uses xclk, they may explain the problems. Can you post your dmesg output with this patch applied?
My output is the same as Dieter's: [drm] ref: 2700, xclk: 2700
https://bugzilla.kernel.org/show_bug.cgi?id=71891
Howard Chu hyc@highlandsun.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hyc@highlandsun.com
--- Comment #38 from Howard Chu hyc@highlandsun.com --- I'm also seeing this UVD not responding on a Trinity laptop - Asus N56DP with A10-4600M and discrete GPU. Was working fine on 3.12, fails on 3.13 and 3.14. I tried 3.15 but that crashes within 30 seconds of bootup if radeon.dpm is enabled. I typically can barely login and type "dmesg" before it dies.
Aside from the UVD failing to initialize, X still comes up ok on 3.13 and 3.14.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #39 from Christian König deathsimple@vodafone.de --- (In reply to Howard Chu from comment #38)
I'm also seeing this UVD not responding on a Trinity laptop - Asus N56DP with A10-4600M and discrete GPU. Was working fine on 3.12, fails on 3.13 and 3.14. I tried 3.15 but that crashes within 30 seconds of bootup if radeon.dpm is enabled. I typically can barely login and type "dmesg" before it dies.
Aside from the UVD failing to initialize, X still comes up ok on 3.13 and 3.14.
That's a completely different problem. This tracker is about UVD clock settings on RV7xx.
Please open up a new bug report and attach you dmesg to it.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #40 from sdh sh.siddhartha@gmail.com --- Hi. Do we close this bug report now that I can successfully boot into 3.15 along with the radeon module?
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #41 from Christian König deathsimple@vodafone.de --- (In reply to sdh from comment #40)
Hi. Do we close this bug report now that I can successfully boot into 3.15 along with the radeon module?
I think we can close it, but it's your bug report you need to update the status.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
sdh sh.siddhartha@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |CODE_FIX
--- Comment #42 from sdh sh.siddhartha@gmail.com --- Ah ok cool. Thanks a lot for getting this resolved.
Cheers!
https://bugzilla.kernel.org/show_bug.cgi?id=71891
Dino dino.omanovic.15@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dino.omanovic.15@gmail.com
--- Comment #43 from Dino dino.omanovic.15@gmail.com --- I have similar issue which seems to occur since 3.12 kernel. I get [drm] initialized then I get this weird screen. http://imgbox.com/LXh03H2o It hangs up at that point, so I have to hold power button then power it on again. It does boot with radeon.modeset=0 Graphics is HD7640G Trinity (AMD A8-4500M, microcode is ARUBA) and laptop is ASUS K55N-DS81.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #44 from Dino dino.omanovic.15@gmail.com --- Solved. Last line before this happened was fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
It works after passing radeon.dpm=0 to boot options.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
J joerg.schaible@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |joerg.schaible@gmx.de
--- Comment #45 from J joerg.schaible@gmx.de --- I suffer from the same problem with vanilla-sources from 3.13.0 to 3.17.1, however, this issue is closed as solved ... since when?
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #46 from Alex Deucher alexdeucher@gmail.com --- The original issue reported was fixed. Please file a new bug if you are having an issue.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
closesrc bluesinn@outlook.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bluesinn@outlook.com
--- Comment #47 from closesrc bluesinn@outlook.com --- how do I apply the patch, any instructions please? thanks.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #48 from Christian König deathsimple@vodafone.de --- (In reply to closesrc from comment #47)
how do I apply the patch, any instructions please? thanks.
You simply don't. This bug is already closed and the fix upstream. No need to apply anything manually any more.
If you have similar problems please open up a new bug report.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
Weber K. weberkai@yahoo.com.br changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |weberkai@yahoo.com.br
--- Comment #49 from Weber K. weberkai@yahoo.com.br --- Hi!
I have HD 6850 and Kernel 4.4.14.
This problem appeared for me when I changed rootflags. Solved with rootflags=relatime,lazytime,commit=60 in kernel parameters.
HTH
Best regards Weber Kai
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #50 from Weber K. weberkai@yahoo.com.br --- Forgot to mention: And relatime,lazytime,commit=60 in fstab I believe maybe dpm need some fs information to work well.
https://bugzilla.kernel.org/show_bug.cgi?id=71891
Mike Diehl (noahwittman0208@gmail.com) changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |noahwittman0208@gmail.com
--- Comment #51 from Mike Diehl (noahwittman0208@gmail.com) --- dpm need some fs information to work well. https://www.geometrydash.me/
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠bugzilla.kernel.org