Created attachment 78493 [details] Longer dmesg output (drm.debug=0xe) Using the code from drm-next-3.10-2 with linux-3.9-rc8, UVD does not initialize on my TURKS chip in a MacBookPro8,2. [ 2.610025] [drm] initializing kernel modesetting (TURKS 0x1002:0x6741 0x106B:0x00E2). [ 2.610055] [drm] register mmio base: 0xB0800000 [ 2.610058] [drm] register mmio size: 131072 [ 2.610092] radeon 0000:01:00.0: Invalid ROM contents [ 2.610128] radeon 0000:01:00.0: Invalid ROM contents [ 2.610149] ATOM BIOS: Apple [ 2.610225] [drm] GPU not posted. posting now... [ 2.627463] radeon 0000:01:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used) [ 2.627469] radeon 0000:01:00.0: GTT: 512M 0x0000000040000000 - 0x000000005FFFFFFF [ 2.632776] [drm] Detected VRAM RAM=1024M, BAR=256M [ 2.632783] [drm] RAM width 128bits DDR [ 2.632839] [TTM] Zone kernel: Available graphics memory: 4042554 kiB [ 2.632842] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 2.632845] [TTM] Initializing pool allocator [ 2.632851] [TTM] Initializing DMA pool allocator [ 2.632886] [drm] radeon: 1024M of VRAM memory ready [ 2.632889] [drm] radeon: 512M of GTT memory ready. [ 2.632910] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 2.632913] [drm] Driver supports precise vblank timestamp query. [ 2.632962] radeon 0000:01:00.0: irq 45 for MSI/MSI-X [ 2.632973] radeon 0000:01:00.0: radeon: using MSI. [ 2.633008] [drm] radeon: irq initialized. [ 2.635037] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 2.635477] [drm] probing gen 2 caps for device 8086:101 = 2212c82/0 [ 2.635484] [drm] PCIE gen 2 link speeds already enabled [ 2.635532] [drm] Loading TURKS Microcode [ 2.638103] [drm] PCIE GART of 512M enabled (table at 0x0000000000273000). [ 2.638226] radeon 0000:01:00.0: WB enabled [ 2.638231] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff880265785c00 [ 2.638236] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff880265785c0c [ 2.638540] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000072118 and cpu addr 0xffffc9000b932118 [ 2.655105] [drm] ring test on 0 succeeded in 3 usecs [ 2.655172] [drm] ring test on 3 succeeded in 0 usecs [ 2.774845] ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared [ 2.774856] ACPI: Battery Slot [BAT0] (battery present) [ 3.532304] tsc: Refined TSC clocksource calibration: 2200.015 MHz [ 3.532310] Switching to clocksource tsc [ 3.679502] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 4.698818] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 5.718146] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 6.737460] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 7.756774] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 8.776088] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 9.795419] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 10.814734] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 11.834049] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 12.853380] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 12.873372] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!! [ 12.873377] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).
Make sure you have installed the new UVD and RLC ucode for TURKS.
These are the versions I have: blee@supra /lib/firmware/radeon $ md5sum BTC_rlc.bin SUMO_uvd.bin TURKS* 25d61fad839b30b263f52328c1f678fb BTC_rlc.bin 51d9e0e2247c313c5bfc8fa7bb5b213d SUMO_uvd.bin 158f8e21ccf228ef063888c4f637fbf0 TURKS_mc.bin 8012e24b187c6b1ba17fa48691c3b048 TURKS_me.bin 25f26ba407a9bb13528b903c617209c8 TURKS_pfp.bin They have the same hashes as what is available at http://people.freedesktop.org/~agd5f/radeon_ucode/. Is there different uvd and rlc ucode I should be using?
(In reply to comment #0) > Using the code from drm-next-3.10-2 with linux-3.9-rc8, What does this mean? Does it work ok with plain drm-next-3.10-2? perhaps you missed some patches?
Thanks for the suggestion. I built drm-next-3.10-2 and got the same issue. I had to apply patches fffe01f7a768d07cc50ace71abe28fbf2f786a43 (PCI: Add PCI ROM helper for platform-provided ROM images) and 06a08570085b3b20c45f45dc66dc46851ecbcb5b (radeon: Attempt to use platform-provided ROM image) from 3.9-rc6 for my system to boot, but other than that it is unmodified.
Created attachment 78497 [details] dmesg from drm-next-3.10-2 plus fix for EFI boot regression
FWIW, I'm seeing this same firmware issue on a SUMO2 system: [ 1.305718] [drm] Initialized drm 1.1.0 20060810 [ 1.305767] [drm] radeon kernel modesetting enabled. [ 1.305964] [drm] initializing kernel modesetting (SUMO2 0x1002:0x9644 0x1849:0x9640). [ 1.306030] [drm] register mmio base: 0xFEF00000 [ 1.306064] [drm] register mmio size: 262144 [ 1.306155] ATOM BIOS: General [ 1.306231] radeon 0000:00:01.0: VRAM: 256M 0x0000000000000000 - 0x000000000FFFFFFF (256M used) [ 1.306272] radeon 0000:00:01.0: GTT: 512M 0x0000000010000000 - 0x000000002FFFFFFF [ 1.306315] mtrr: type mismatch for c0000000,10000000 old: write-back new: write-combining [ 1.306355] [drm] Detected VRAM RAM=256M, BAR=256M [ 1.306389] [drm] RAM width 32bits DDR [ 1.306520] [TTM] Zone kernel: Available graphics memory: 1885900 kiB [ 1.306563] [TTM] Initializing pool allocator [ 1.306601] [TTM] Initializing DMA pool allocator [ 1.306659] [drm] radeon: 256M of VRAM memory ready [ 1.306694] [drm] radeon: 512M of GTT memory ready. [ 1.306730] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 1.306765] [drm] Driver supports precise vblank timestamp query. [ 1.306839] radeon 0000:00:01.0: irq 41 for MSI/MSI-X [ 1.306849] radeon 0000:00:01.0: radeon: using MSI. [ 1.306901] [drm] radeon: irq initialized. [ 1.307950] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 1.309023] [drm] Loading SUMO2 Microcode [ 1.316957] [drm] PCIE GART of 512M enabled (table at 0x0000000000273000). [ 1.317116] radeon 0000:00:01.0: WB enabled [ 1.317148] radeon 0000:00:01.0: fence driver on ring 0 use gpu addr 0x0000000010000c00 and cpu addr 0xffff88012a178c00 [ 1.317186] radeon 0000:00:01.0: fence driver on ring 3 use gpu addr 0x0000000010000c0c and cpu addr 0xffff88012a178c0c [ 1.317414] radeon 0000:00:01.0: fence driver on ring 5 use gpu addr 0x0000000000072118 and cpu addr 0xffffc900106b2118 [ 1.334080] [drm] ring test on 0 succeeded in 1 usecs [ 1.334176] [drm] ring test on 3 succeeded in 1 usecs [ 2.281926] tsc: Refined TSC clocksource calibration: 2695.097 MHz [ 2.376808] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 3.394476] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 4.412139] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 5.429805] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 6.447468] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 7.465130] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 8.482797] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 9.500460] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 10.518126] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 11.535793] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 11.555786] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!! [ 11.575783] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). [ 11.576227] [drm] ib test on ring 0 succeeded in 0 usecs [ 11.576294] [drm] ib test on ring 3 succeeded in 0 usecs [ 11.577202] [drm] Radeon Display Connectors [ 11.577236] [drm] Connector 0: [ 11.577269] [drm] HDMI-A-1 [ 11.577302] [drm] HPD2 [ 11.577335] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [ 11.578434] [drm] Encoders: [ 11.578467] [drm] DFP1: INTERNAL_UNIPHY2 [ 11.578501] [drm] Connector 1: [ 11.578533] [drm] VGA-1 [ 11.578566] [drm] HPD1 [ 11.578599] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [ 11.578652] [drm] Encoders: [ 11.578685] [drm] CRT1: INTERNAL_UNIPHY2 [ 11.578719] [drm] CRT1: NUTMEG [ 11.595893] [drm] Internal thermal controller without fan control [ 11.595949] [drm] radeon: power management initialized [ 11.660512] [drm] fb mappable at 0xC0375000 [ 11.660542] [drm] vram apper at 0xC0000000 [ 11.660570] [drm] size 9216000 [ 11.660598] [drm] fb depth is 24 [ 11.660626] [drm] pitch is 7680 [ 11.660828] fbcon: radeondrmfb (fb0) is primary device [ 11.738729] Console: switching to colour frame buffer device 240x75 [ 11.745079] radeon 0000:00:01.0: fb0: radeondrmfb frame buffer device [ 11.745110] radeon 0000:00:01.0: registered panic notifier [ 11.745140] [drm] Initialized radeon 2.33.0 20080528 for 0000:00:01.0 on minor 0 This is on a machine I use as a file server, with no X Windows installed; on my desktop machine (using Juniper), I have successfully built and run the same kernel with the new JUNIPER_rlc.bin and CYPRESS_uvd.bin files (and the old JUNIPER_me.bin and JUNIPER_pfp.bin files). (Not trying to hijack this bug report; just throwing in some extra info that seems related.) - DW
I am getting the same error on HD6750M - I verified the kernel (Linus git from today) I am running has the raise clocks patch. I've also replaced everything in /lib/firmware/radeon from http://people.freedesktop.org/~agd5f/radeon_ucode/. lspci | grep -i radeon ---------------------- 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Whistler [Radeon HD 6600M/6700M/7600M Series] 01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Turks/Whistler HDMI Audio [Radeon HD 6000 Series] dmesg ----- dmesg |grep -i uvd [ 17.676387] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 18.697587] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 19.718765] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 20.739957] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 21.761139] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 22.782347] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 23.803569] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 24.824728] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 25.845904] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 26.867070] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 26.887096] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!! [ 26.887102] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).
I booted in Apple's BIOS emulation mode and found that UVD initializes successfully, so the problem is limited to EFI booting (like the former video BIOS issue). Is there any debugging output I can provide that would help identify what is different when EFI booting?
Noting Benjamin's experience with EFI in comment 8, I took a look at my 3 machines on which I am trying the UVD support. I have a laptop, a desktop, and another (inexpensive) desktop which I use as a file server. Desktop: JUNIPER, no EFI support (several years old) CONFIG_EXTRA_FIRMWARE="radeon/JUNIPER_me.bin radeon/JUNIPER_pfp.bin radeon/JUNIPER_rlc.bin radeon/CYPRESS_uvd.bin ..." Boot results: [ 0.816646] [drm] UVD initialized successfully. Laptop: SUMO, no EFI support (not old, but not new enough for EFI) CONFIG_EXTRA_FIRMWARE="radeon/SUMO_rlc.bin radeon/SUMO_me.bin radeon/SUMO_pfp.bin radeon/SUMO_uvd.bin ..." Boot results: [ 1.650383] [drm] UVD initialized successfully. "fileserver": SUMO2, EFI support (newest motherboard of the 3) CONFIG_EXTRA_FIRMWARE="radeon/SUMO_rlc.bin radeon/SUMO2_me.bin radeon/SUMO2_pfp.bin radeon/SUMO_uvd.bin" Boot results: [ 11.575783] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). See comment 6 above. This looks like further evidence of EFI involvement with the problem. I cannot see any BIOS settings that would allow me to alter EFI support on my "fileserver" motherboard. The only option I could find had to do with PCI ROM support ("legacy" vs "EFI"), but this had defaulted to "legacy" when I installed the motherboard and I never touched it.
Thanks allot for the hint with the EFI install. Currently trying to install one of my system with EFI to reproduce the problem. Christian.
Same issue with SUMO on laptop without UEFI.
Is it known what is going on exactly here? This seems almost like an incomplete new feature or a regression and hence a candidate to be reverted in 3.10.
(In reply to comment #12) > Is it known what is going on exactly here? > > This seems almost like an incomplete new feature or a regression and hence a > candidate to be reverted in 3.10. The initial investigation seems to indicate that the initrd gets corrupted on UEFI systems. It doesn't appear to be driver related, but we are still digging.
Try booting into runlevel 3 with radeon kms (radeon.modeset=0 on the kernel command line in grub, etc.), then manually load radeon with kms enabled (modprobe -r radeon; modprobe radeon modeset=1).
(In reply to comment #14) > Try booting into runlevel 3 with radeon kms (radeon.modeset=0 on the kernel > command line in grub, etc.), then manually load radeon with kms enabled > (modprobe -r radeon; modprobe radeon modeset=1). Already tried that, doesn't work either. The good news is that I can reproduce the problem, and it indeed looks like the firmware image gets corrupted. But that seems to always happen not only when the image is loaded from initrd. Going to investigate further.
(In reply to comment #15) > > The good news is that I can reproduce the problem, and it indeed looks like > the firmware image gets corrupted. But that seems to always happen not only > when the image is loaded from initrd. That is a fact. I run my locally-built kernels without initrd files; the kernel has an initramfs facility which allows files to be manually selected for inclusion in the vmlinuz image (I used to use this for uvesafb), and a separate set of config options (CONFIG_EXTRA_FIRMWARE*, see comment 9 above) specifically for including firmware files into a particular location in the initial filesystem. I have been doing this for several years. It currently works for UVD on 2 out of 3 systems. (A fourth machine has an integrated Radeon GPU too old to be supported by this UVD code, though it also boots Linux without an initrd.)
Make sure you have the updated RLC ucode in addition to the UVD ucode. Unfortunately, I can't reproduce this on the UEFI systems I have access to.
(In reply to comment #17) > Make sure you have the updated RLC ucode in addition to the UVD ucode. > Unfortunately, I can't reproduce this on the UEFI systems I have access to. Benjamin and Parag have already indicated which firmware versions they are using, and I feel it's safe to assume that Christian is also using the proper versions as well. I see that I have forgotten to list my versions: the *_rlc.bin (and *_uvd.bin) files I use were listed in comment 9, and all 4 of them are dated Apr. 2, 2013. They were obtained from http://people.freedesktop.org/~agd5f/radeon_ucode on Apr. 28.
(In reply to comment #18) > (In reply to comment #17) > > Make sure you have the updated RLC ucode in addition to the UVD ucode. > > Unfortunately, I can't reproduce this on the UEFI systems I have access to. > > Benjamin and Parag have already indicated which firmware versions they are > using, and I feel it's safe to assume that Christian is also using the > proper versions as well. It's worth double checking. I've forgotten to update my ucode a number of times and run into similar problems. Christian was using out of date ucode and when he fixed it his UEFI system started working fine. We can take a look at register dumps. grab radeonreg: http://cgit.freedesktop.org/~airlied/radeontool/ and dump the regs when booted with legacy vbios vs. UEFI and attach the outputs. boot with legacy bios (as root): radeonreg regs all > legacy.regs boot with UEFI (as root): radeonreg regs all > uefi.regs
I am using a monolithic kernel without initrd (CONFIG_DRM_RADEON=y and CONFIG_EXTRA_FIRMWARE) using the exact same vmlinuz file between EFI and BIOS modes, so I don't believe I have a ucode issue since BIOS mode works correctly. RADEON_AUX_SC_CNTL is different between EFI and BIOS emulation: blee@supra ~/tmp $ diff bios.regs efi.regs 8c8 < RADEON_AUX_SC_CNTL 52f7377c --- > RADEON_AUX_SC_CNTL 52f7337c 46,48c46,48 < RADEON_CRTC2_H_TOTAL_DISP 0200000f < RADEON_CRTC2_H_SYNC_STRT_WID 00000000 < RADEON_CRTC2_V_TOTAL_DISP 00000100 --- > RADEON_CRTC2_H_TOTAL_DISP 0000000f > RADEON_CRTC2_H_SYNC_STRT_WID 00003f3f > RADEON_CRTC2_V_TOTAL_DISP 00000000 I built a separate kernel for fglrx and found that RADEON_AUX_SC_CNTL matched the BIOS emulation mode: blee@supra ~/tmp $ diff fglrx.regs bios.regs 46c46 < RADEON_CRTC2_H_TOTAL_DISP 0203000f --- > RADEON_CRTC2_H_TOTAL_DISP 0200000f
Created attachment 79441 [details] radeontool regs from Apple BIOS emulation mode
Created attachment 79442 [details] radeontool regs from EFI booting
Created attachment 79443 [details] radeontool regs with fglrx
(In reply to comment #19) > (In reply to comment #18) > > Benjamin and Parag have already indicated which firmware versions they are > > using, and I feel it's safe to assume that Christian is also using the > > proper versions as well. > > It's worth double checking. I've forgotten to update my ucode a number of > times and run into similar problems. Christian was using out of date ucode > and when he fixed it his UEFI system started working fine. OK, I see your point. There was a firmware update in Debian Sid on May 6, and that _did_ overwrite the newer firmware files that are also present in the firmware package. But I checked for this at the time (May 6) and have been vigilant about it since. The files are up to date right now, and have been since that firmware package upgrade. > We can take a look at register dumps. grab radeonreg: > http://cgit.freedesktop.org/~airlied/radeontool/ > and dump the regs when booted with legacy vbios vs. UEFI and attach the > outputs. Looks like I cannot play; I have SUMO2 while Benjamin has TURKS, and with the git version of 'radeontool' I see this: # ./radeonreg regs all unknown chipset, specify the regs to dump # grep SUMO radeon_chipinfo_gen.h # grep TURKS radeon_chipinfo_gen.h { 0x6740, CHIP_FAMILY_TURKS, 1, 0, 0, 0, 0 }, { 0x6741, CHIP_FAMILY_TURKS, 1, 0, 0, 0, 0 }, { 0x6742, CHIP_FAMILY_TURKS, 1, 0, 0, 0, 0 }, { 0x6743, CHIP_FAMILY_TURKS, 1, 0, 0, 0, 0 }, { 0x6744, CHIP_FAMILY_TURKS, 1, 0, 0, 0, 0 }, { 0x6745, CHIP_FAMILY_TURKS, 1, 0, 0, 0, 0 }, { 0x6746, CHIP_FAMILY_TURKS, 0, 0, 0, 0, 0 }, { 0x6747, CHIP_FAMILY_TURKS, 0, 0, 0, 0, 0 }, { 0x6748, CHIP_FAMILY_TURKS, 0, 0, 0, 0, 0 }, { 0x6749, CHIP_FAMILY_TURKS, 0, 0, 0, 0, 0 }, { 0x6750, CHIP_FAMILY_TURKS, 0, 0, 0, 0, 0 }, { 0x6758, CHIP_FAMILY_TURKS, 0, 0, 0, 0, 0 }, { 0x6759, CHIP_FAMILY_TURKS, 0, 0, 0, 0, 0 }, My hardware is shown in comment 6, at this line of the 'dmesg' output: [drm] initializing kernel modesetting (SUMO2 0x1002:0x9644 0x1849:0x9640) # grep 9644 radeon_chipinfo_gen.h # grep 6741 radeon_chipinfo_gen.h { 0x6741, CHIP_FAMILY_TURKS, 1, 0, 0, 0, 0 }, Bummer. It looks like Benjamin has some good results. Hopefully that will lead to a fix.
Created attachment 79447 [details] radeonreg regs all in BIOS emulation mode
Created attachment 79448 [details] radeonreg regs all in EFI booting
I accidentally attached radeontool output instead of radeonreg. The correct output (radeonreg) is attached now.
My mistake was that I've forgotton to update the initrd, so if you are using one make sure that it is up to date as well. Actually "radeonreg regs all" won't give you the UVD regs, cause it doesn't know about them yet. So could you guys give us a dump of the following regs, once with EFI and once in BIOS mode? Thanks in advance, Christian. 0xef00 0xef04 0xef08 0xef0c 0xef10 0xef14 0xef18 0xef40 0xef44 0xef48 0xef4c 0xef50 0xef54 0xf400 0xf480 0xf498 0xf4a8 0xf4d4 0xf4d8 0xf4dc 0xf4e0 0xf4e4 0xf4e8 0xf4ec 0xf4f4 0xf500 0xf594 0xf598 0xf5b4 0xf5bC 0xf5dC 0xf5e4 0xf5e8 0xf5eC 0xf5f0 0xf5f4 0xf5f8 0xf660 0xf680 0xf684 0xf688 0xf68c 0xf690 0xF690 0xf694 0xF694 0xf698 0xf6a4 0xf6a8 0xf6bc 0xf6c0 0xf6c4 0xf6c8 0xf6cc 0xf6f4
(In reply to comment #28) > Actually "radeonreg regs all" won't give you the UVD regs, cause it doesn't > know about them yet. So could you guys give us a dump of the following regs, > once with EFI and once in BIOS mode? In comment 9 I mentioned that I did not see any BIOS settings that would allow me to switch off EFI mode on my problematic SUMO2 machine. I will look again. For now, this is the list of registers you requested: # for reg in 0xef00 0xef04 0xef08 0xef0c 0xef10 0xef14 0xef18 0xef40 0xef44 0xef48 0xef4c 0xef50 0xef54 0xf400 0xf480 0xf498 0xf4a8 0xf4d4 0xf4d8 0xf4dc 0xf4e0 0xf4e4 0xf4e8 0xf4ec 0xf4f4 0xf500 0xf594 0xf598 0xf5b4 0xf5bC 0xf5dC 0xf5e4 0xf5e8 0xf5eC 0xf5f0 0xf5f4 0xf5f8 0xf660 0xf680 0xf684 0xf688 0xf68c 0xf690 0xF690 0xf694 0xF694 0xf698 0xf6a4 0xf6a8 0xf6bc 0xf6c0 0xf6c4 0xf6c8 0xf6cc 0xf6f4; do ./radeontool regmatch $reg; done 0xef00 0x00000000 (0) 0xef04 0x00000000 (0) 0xef08 0x00000080 (128) 0xef0c 0x00000000 (0) 0xef10 0x00000000 (0) 0xef14 0x00000000 (0) 0xef18 0x00000000 (0) 0xef40 0x00000000 (0) 0xef44 0x00000000 (0) 0xef48 0x04010040 (67174464) 0xef4c 0x02010002 (33619970) 0xef50 0x02010002 (33619970) 0xef54 0x02010002 (33619970) 0xf400 0x00000003 (3) 0xf480 0x00000000 (0) 0xf498 0x80090000 (-2146893824) 0xf4a8 0x00000000 (0) 0xf4d4 0x0100000d (16777229) 0xf4d8 0x00008000 (32768) 0xf4dc 0x00006600 (26112) 0xf4e0 0x0000e600 (58880) 0xf4e4 0x00020000 (131072) 0xf4e8 0x0002e600 (189952) 0xf4ec 0x00020000 (131072) 0xf4f4 0x00000030 (48) 0xf500 0x00000000 (0) 0xf594 0x00000000 (0) 0xf598 0x00302340 (3154752) 0xf5b4 0x00000000 (0) 0xf5bC 0x00000000 (0) 0xf5dC 0x00000000 (0) 0xf5e4 0x040c2040 (67903552) 0xf5e8 0x00000000 (0) 0xf5eC 0x040c2040 (67903552) 0xf5f0 0x00000000 (0) 0xf5f4 0x00000088 (136) 0xf5f8 0x00000000 (0) 0xf660 0x00000200 (512) 0xf680 0x00000000 (0) 0xf684 0x00000000 (0) 0xf688 0x00000000 (0) 0xf68c 0x00000000 (0) 0xf690 0x00000000 (0) 0xF690 0x00000000 (0) 0xf694 0x00000000 (0) 0xF694 0x00000000 (0) 0xf698 0x00000000 (0) 0xf6a4 0x01000101 (16777473) 0xf6a8 0x00000000 (0) 0xf6bc 0x00000000 (0) 0xf6c0 0x00000000 (0) 0xf6c4 0x02000000 (33554432) 0xf6c8 0x02000000 (33554432) 0xf6cc 0x02000000 (33554432) 0xf6f4 0x00000000 (0)
Created attachment 79474 [details] UVD regs only, BIOS emulation
Created attachment 79475 [details] UVD regs only, EFI
UVD register dumps attached. blee@supra ~/tmp $ diff uvdregs-bios.txt uvdregs-efi.txt 4c4 < 0xef0c 0x80000002 (-2147483646) --- > 0xef0c 0x00000000 (0) 16,18c16,18 < 0xf498 0x80100000 (-2146435072) < 0xf4a8 0x0003f786 (259974) < 0xf4d4 0x00000000 (0) --- > 0xf498 0x80090000 (-2146893824) > 0xf4a8 0x00000000 (0) > 0xf4d4 0x01000011 (16777233) 26c26 < 0xf500 0x00000006 (6) --- > 0xf500 0x00000000 (0) 31c31 < 0xf5dC 0x00000010 (16) --- > 0xf5dC 0x00000000 (0) 40,46c40,46 < 0xf684 0x40122100 (1074929920) < 0xf688 0x00000010 (16) < 0xf68c 0x40121000 (1074925568) < 0xf690 0x00000060 (96) < 0xF690 0x00000060 (96) < 0xf694 0x00000060 (96) < 0xF694 0x00000060 (96) --- > 0xf684 0x00000000 (0) > 0xf688 0x00000000 (0) > 0xf68c 0x00000000 (0) > 0xf690 0x00000000 (0) > 0xF690 0x00000000 (0) > 0xf694 0x00000000 (0) > 0xF694 0x00000000 (0) 48,50c48,50 < 0xf6a4 0x0000010c (268) < 0xf6a8 0x10000280 (268436096) < 0xf6bc 0x00000002 (2) --- > 0xf6a4 0x01000101 (16777473) > 0xf6a8 0x00000000 (0) > 0xf6bc 0x00000000 (0) 52,55c52,55 < 0xf6c4 0x000fffff (1048575) < 0xf6c8 0x000fffff (1048575) < 0xf6cc 0x000fffff (1048575) < 0xf6f4 0x00000002 (2) --- > 0xf6c4 0x02000000 (33554432) > 0xf6c8 0x02000000 (33554432) > 0xf6cc 0x02000000 (33554432) > 0xf6f4 0x00000000 (0)
As somewhat expected, v3.10-rc2 still has this. Has anyone done a bisection to find out which commit causes the corruption?
(In reply to comment #33) > As somewhat expected, v3.10-rc2 still has this. > > Has anyone done a bisection to find out which commit causes the corruption? Austin, this is new support for previously unsupported hardware present on several generations of AMD GPUs. My understanding is that it is an unforeseen problem with initializing the new support on certain kinds of systems. The developers are not really able to reproduce the problem being reported by several us. No (official) kernel has been released yet with this new support, and we have at least 6 weeks to work on it before the first such kernel will be released. Can you tell us a bit about your system? 1) What kind of hardware are you using -- can you show us the error messages from you log files? 2) Are you using the necessary firmware for your system to allow this new support to work? (Most distributions haven't packaged it yet, so most of us have to download the new firmware directly; see comment 2.) 3) Is your system built around a newer EFI motherboard, or do have a traditional non-EFI BIOS? There may still be some question of whether us users are doings something wrong -- although I personally have 2 systems that initialize UVD correctly and only 1 (EFI) system giving me trouble -- but if you have the firmware which enables this new UVD support, then maybe you could offer to do some register dumps if Christian or one of the other developers thinks it would be helpful to them?
(In reply to comment #34) > > Can you tell us a bit about your system? > > 1) What kind of hardware are you using -- can you show us the error > messages from you log files? Machine is a MacBookpro 8,2. lspci -v -s 01:00.0: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6600M/6700M/7600M Series] (prog-if 00 [VGA controller]) Subsystem: Apple Inc. MacBookPro8,2 [Core i7, 15", Late 2011] Flags: bus master, fast devsel, latency 0, IRQ 49 Memory at 90000000 (64-bit, prefetchable) [size=256M] Memory at b0800000 (64-bit, non-prefetchable) [size=128K] I/O ports at 2000 [size=256] Expansion ROM at b0820000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [150] Advanced Error Reporting Kernel driver in use: radeon Kernel modules: radeon Abridged log output: May 21 10:21:12 lund-macbookpro kernel: ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) May 21 10:21:12 lund-macbookpro kernel: input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/LNXVIDEO:00/input/input9 May 21 10:21:12 lund-macbookpro kernel: ACPI: Video Device [IGPU] (multi-head: yes rom: no post: no) May 21 10:21:12 lund-macbookpro kernel: input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input10 May 21 10:21:12 lund-macbookpro kernel: EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null) May 21 10:21:12 lund-macbookpro kernel: [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 May 21 10:21:12 lund-macbookpro kernel: snd_hda_intel 0000:00:1b.0: enabling device (0000 -> 0002) May 21 10:21:12 lund-macbookpro kernel: [drm] initializing kernel modesetting (TURKS 0x1002:0x6741 0x106B:0x00E2). May 21 10:21:12 lund-macbookpro kernel: snd_hda_intel 0000:00:1b.0: irq 48 for MSI/MSI-X May 21 10:21:12 lund-macbookpro kernel: [drm] register mmio base: 0xB0800000 May 21 10:21:12 lund-macbookpro kernel: [drm] register mmio size: 131072 May 21 10:21:12 lund-macbookpro kernel: vga_switcheroo: enabled May 21 10:21:12 lund-macbookpro kernel: radeon 0000:01:00.0: Invalid ROM contents May 21 10:21:12 lund-macbookpro kernel: radeon 0000:01:00.0: Invalid ROM contents May 21 10:21:12 lund-macbookpro kernel: ATOM BIOS: Apple May 21 10:21:12 lund-macbookpro kernel: [drm] GPU not posted. posting now... May 21 10:21:12 lund-macbookpro kernel: radeon 0000:01:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used) May 21 10:21:12 lund-macbookpro kernel: radeon 0000:01:00.0: GTT: 512M 0x0000000040000000 - 0x000000005FFFFFFF May 21 10:21:12 lund-macbookpro kernel: [drm] Detected VRAM RAM=1024M, BAR=256M May 21 10:21:12 lund-macbookpro kernel: [drm] RAM width 128bits DDR May 21 10:21:12 lund-macbookpro kernel: [TTM] Zone kernel: Available graphics memory: 4053880 kiB May 21 10:21:12 lund-macbookpro kernel: [TTM] Zone dma32: Available graphics memory: 2097152 kiB May 21 10:21:12 lund-macbookpro kernel: [TTM] Initializing pool allocator May 21 10:21:12 lund-macbookpro kernel: [TTM] Initializing DMA pool allocator May 21 10:21:12 lund-macbookpro kernel: [drm] radeon: 1024M of VRAM memory ready May 21 10:21:12 lund-macbookpro kernel: [drm] radeon: 512M of GTT memory ready. May 21 10:21:12 lund-macbookpro kernel: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). May 21 10:21:12 lund-macbookpro kernel: [drm] Driver supports precise vblank timestamp query. May 21 10:21:12 lund-macbookpro kernel: radeon 0000:01:00.0: irq 49 for MSI/MSI-X May 21 10:21:12 lund-macbookpro kernel: radeon 0000:01:00.0: radeon: using MSI. May 21 10:21:12 lund-macbookpro kernel: [drm] radeon: irq initialized. May 21 10:21:12 lund-macbookpro kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072 May 21 10:21:12 lund-macbookpro kernel: [drm] probing gen 2 caps for device 8086:101 = 2212c82/0 May 21 10:21:12 lund-macbookpro kernel: [drm] PCIE gen 2 link speeds already enabled May 21 10:21:12 lund-macbookpro kernel: [drm] Loading TURKS Microcode May 21 10:21:12 lund-macbookpro kernel: [drm] PCIE GART of 512M enabled (table at 0x0000000000273000). May 21 10:21:12 lund-macbookpro kernel: radeon 0000:01:00.0: WB enabled May 21 10:21:12 lund-macbookpro kernel: radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff88025f667c00 May 21 10:21:12 lund-macbookpro kernel: radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff88025f667c0c May 21 10:21:12 lund-macbookpro kernel: radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000072118 and cpu addr 0xffffc9001c6b2118 May 21 10:21:12 lund-macbookpro kernel: input: HDA Intel PCH SPDIF In as /devices/pci0000:00/0000:00:1b.0/sound/card0/input12 May 21 10:21:12 lund-macbookpro kernel: input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input13 May 21 10:21:12 lund-macbookpro kernel: input: HDA Intel PCH Line as /devices/pci0000:00/0000:00:1b.0/sound/card0/input14 May 21 10:21:12 lund-macbookpro kernel: [drm] ring test on 0 succeeded in 2 usecs May 21 10:21:12 lund-macbookpro kernel: [drm] ring test on 3 succeeded in 1 usecs May 21 10:21:13 lund-macbookpro kernel: [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off May 21 10:21:13 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! May 21 10:21:14 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! May 21 10:21:16 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! May 21 10:21:17 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! May 21 10:21:18 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! May 21 10:21:19 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! May 21 10:21:20 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! May 21 10:21:21 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! May 21 10:21:22 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! May 21 10:21:23 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! May 21 10:21:23 lund-macbookpro kernel: [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!! May 21 10:21:23 lund-macbookpro kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1). May 21 10:21:23 lund-macbookpro kernel: [drm] ib test on ring 0 succeeded in 0 usecs May 21 10:21:23 lund-macbookpro kernel: [drm] ib test on ring 3 succeeded in 0 usecs May 21 10:21:23 lund-macbookpro kernel: [drm] radeon atom DIG backlight initialized > 2) Are you using the necessary firmware for your system to allow this new > support to work? (Most distributions haven't packaged it yet, so most of us > have to download the new firmware directly; see comment 2.) $ md5sum TURKS* 158f8e21ccf228ef063888c4f637fbf0 TURKS_mc.bin 8012e24b187c6b1ba17fa48691c3b048 TURKS_me.bin 25f26ba407a9bb13528b903c617209c8 TURKS_pfp.bin > 3) Is your system built around a newer EFI motherboard, or do have a > traditional non-EFI BIOS? Apple's EFI. There is a BIOS compatibility mode, but I'm unable to do gpu switching in that mode. > > There may still be some question of whether us users are doings something > wrong -- although I personally have 2 systems that initialize UVD correctly > and only 1 (EFI) system giving me trouble -- but if you have the firmware > which enables this new UVD support, then maybe you could offer to do some > register dumps if Christian or one of the other developers thinks it would > be helpful to them? Would this be the same as others have done above?
(In reply to comment #35) > Would this be the same as others have done above? Thanks for the input, but we already have enough register dumps for now. Currently I'm analyzing them and trying to figure out what the heck is going wrong here. Cheers, Christian.
Created attachment 79663 [details] [review] don't re-post mac cards For the non-Macs, this patch should fix the issue: http://lists.freedesktop.org/archives/dri-devel/2013-May/038894.html For the macs, does the attached patch help?
(In reply to comment #37) > For the non-Macs, this patch should fix the issue: > http://lists.freedesktop.org/archives/dri-devel/2013-May/038894.html Thanks, Alex. Christian had me test the SUMO2 fix yesterday, and I let him know that it worked then. Any chance I can get a "Tested-By:"? ;)
(In reply to comment #38) > Any chance I can get a "Tested-By:"? ;) done!
(In reply to comment #37) > Created attachment 79663 [details] [review] [review] > don't re-post mac cards > > For the non-Macs, this patch should fix the issue: > http://lists.freedesktop.org/archives/dri-devel/2013-May/038894.html > > For the macs, does the attached patch help? Yes, with the attached patch UVD initializes successfully on my MacBookPro8,2. Thank you!
(In reply to comment #40) > (In reply to comment #37) > > Created attachment 79663 [details] [review] [review] [review] > > don't re-post mac cards > > > > For the non-Macs, this patch should fix the issue: > > http://lists.freedesktop.org/archives/dri-devel/2013-May/038894.html > > > > For the macs, does the attached patch help? > > Yes, with the attached patch UVD initializes successfully on my > MacBookPro8,2. Thank you! I can also confirm this. So do the conditions which required commit bcc65fd8 (which introduced this test) not exist anymore?
(In reply to comment #41) > So do the conditions which required commit bcc65fd8 (which introduced this > test) not exist anymore? Good question, hopefully Matthew can retest that. Anyway I think we can close this bugreport now. Christian.
As I understand this patch will be included into next 3.10 RC?
I got exactly same issue on BARTS (HD6850) with 3.10-rc2 kernel. Waiting for next rc for testing.
On 05/24/13 13:01, bugzilla-daemon@freedesktop.org wrote: > Erdem U. Altinyurt <mailto:spamjunkeater@gmail.com> changed bug 63935 > <https://bugs.freedesktop.org/show_bug.cgi?id=63935> > What Removed Added > CC spamjunkeater@gmail.com > > *Comment # 44 <https://bugs.freedesktop.org/show_bug.cgi?id=63935#c44> > on bug 63935 <https://bugs.freedesktop.org/show_bug.cgi?id=63935> from > Erdem U. Altinyurt <mailto:spamjunkeater@gmail.com> * > > I got exactly same issue on BARTS (HD6850) with 3.10-rc2 kernel. > > Waiting for next rc for testing. > > ------------------------------------------------------------------------ > You are receiving this mail because: > > * You are the assignee for the bug. > > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > I got exactly same issue on [AMD/ATI] RV710 [Radeon HD 4350/4550] with RV710_uvd.bin with 3.10-rc2 kernel. Will also test again with next rc.
The changes didn't make 3.10-rc3 (too soon?). Also, no answers yet for if the test for EFI booted macs it can be removed.
(In reply to comment #42) > (In reply to comment #41) > > So do the conditions which required commit bcc65fd8 (which introduced this > > test) not exist anymore? > > Good question, hopefully Matthew can retest that. > > Anyway I think we can close this bugreport now. > > Christian. I can confirm that the patch works on boot, also on a mac 8,2 with drm-next and patches, but fails on suspend resume. It reappears on resume. Please reopen the bug.
(In reply to comment #47) > > I can confirm that the patch works on boot, also on a mac 8,2 with drm-next > and patches, but fails on suspend resume. It reappears on resume. > Please reopen the bug. I have a MacbookPro8,2 and this doesn't happen to me. My pci ID for the radeon is 1002:6741 and subsystem 106b:00e2. Is it the same message in the dmesg log?
Patch doesn't fix the issue on radeon HD 6850 (BARTS 0x1002:0x6739 0x174B:0xE174) kernel 3.10-rc3 + SUMO_uvs.patch (https://bugs.freedesktop.org/attachment.cgi?id=79663) Still got [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!! errors. :(
Also patched SUMO2 patch from http://lists.freedesktop.org/archives/dri-devel/2013-May/038894.html '''Still no success!''' Still got [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!
(In reply to comment #50) > Also patched SUMO2 patch from > http://lists.freedesktop.org/archives/dri-devel/2013-May/038894.html > > '''Still no success!''' > > Still got [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset > the VCPU!!! Well is this a Mac you are trying to get working? This bugreport is about Macs booting in EFI mode, if you have issues with another system please open another bugreport even if you have the same symptoms. Christian.
(In reply to comment #48) > (In reply to comment #47) > > > > I can confirm that the patch works on boot, also on a mac 8,2 with drm-next > > and patches, but fails on suspend resume. It reappears on resume. > > Please reopen the bug. > > I have a MacbookPro8,2 and this doesn't happen to me. My pci ID for the > radeon is 1002:6741 and subsystem 106b:00e2. Is it the same message in the > dmesg log? Hi, I have a slightly different PCI-ID for my ATI graphics card. According to lspci -nn it's: 1002:6760 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI Seymour [Radeon HD 6400M/7400M Series] [1002:6760] According to dmesg: [drm] initializing kernel modesetting (CAICOS 0x1002:0x6760 0x106B:0x00E1).
Fixed for my MacBookPro8,2 in 3.10-rc4.
I am also seeing this with a PALM ASIC in the drm-next-3.11-wip branch. The machine is a Lenovo x121e.
Sorry for the noise, I am seeing a different issue related to DPM.
(In reply to comment #55) > Sorry for the noise, I am seeing a different issue related to DPM. Well then please open up a new bugreport, cause this one is about Macs not booting the UVD block correctly.
The suspend/resume issue was something completely different, so we probably can now close this bugreport.
Created attachment 84488 [details] create full dmesg attachment. My same issue with RV730
Created attachment 84489 [details] create success dmesg attachment After remove generic driver xf86-video-vesa, it work fine :)
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.