From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?J=F6rg-Volker_Peetz?= Subject: Re: "radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600 [Solved] Date: Wed, 03 Jul 2013 10:19:48 +0200 Message-ID: <51D3DEA4.9060900@web.de> References: <51D334CC.5020206@web.de> <51D33948.4050007@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by gabe.freedesktop.org (Postfix) with ESMTP id E7726E63AE for ; Wed, 3 Jul 2013 01:19:58 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UuII9-0002SX-W3 for dri-devel@lists.freedesktop.org; Wed, 03 Jul 2013 10:19:57 +0200 Received: from p5b379a7a.dip0.t-ipconnect.de ([91.55.154.122]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Jul 2013 10:19:57 +0200 Received: from jvpeetz by p5b379a7a.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Jul 2013 10:19:57 +0200 In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org Alex Deucher wrote, on 07/03/2013 00:49: > On Tue, Jul 2, 2013 at 4:34 PM, J=F6rg-Volker Peetz wrot= e: >> Alex Deucher wrote, on 07/02/2013 22:17: >>> On Tue, Jul 2, 2013 at 4:15 PM, J=F6rg-Volker Peetz wr= ote: >>>> Alex Deucher wrote, on 07/02/2013 21:46: >>>>> On Tue, Jul 2, 2013 at 10:09 AM, J=F6rg-Volker Peetz = wrote: >>>>>> With self-compiled linux 3.10 on a HP Pavilion dv7 with hybrid graph= ics (ATI >>>>>> RS880M [Mobility Radeon HD 4200 Series] / ATI Manhattan [Mobility Ra= deon HD 5400 >>>>>> Series]) uvd seems to be broken. >>>>>> >>>>>> The new firware files are installed in /lib/firmware/radeon: >>>>>> >>>>>> sha1 hashes >>>>>> 3142a64061ade6032c95ed948c85b15dd0ae46be CEDAR_me.bin >>>>>> a92856a4fa16926e2451a6335da7e20f01fde210 CEDAR_pfp.bin >>>>>> 644b29756636687ad31a49da4aa3ed85dcedecdb CEDAR_rlc.bin >>>>>> 992d49518d3936986b5ce3ddb0d9bbd75135bb8f CYPRESS_uvd.bin >>>>>> 3e04529600d666ddb2f2f83bb0112d4fab516c04 R600_rlc.bin >>>>>> >>>>>> The system boots without initial ram disk. >>>>> >>>>> Make sure your system is using the latest CEDAR_rlc.bin as well. >>>>> >>>>> Alex >>>>> >>>> Thanks for the hint, Alex. Actually I took the files today from your r= epository >>>> at http://people.freedesktop.org/~agd5f/radeon_ucode/ and checked them= against >>>> the ones downloaded from >>>> http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.gi= t . >>> >>> Make sure that your kernel is actually using the new ones. >>> >>> Alex >>> >> >> The files are located in /lib/firmware/radeon , the kernel configuration= contains >> >> CONFIG_EXTRA_FIRMWARE=3D"amd-ucode/microcode_amd.bin radeon/R600_rlc.bin >> radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin radeon/CEDAR_rlc.bin >> radeon/CYPRESS_uvd.bin" >> CONFIG_EXTRA_FIRMWARE_DIR=3D"/lib/firmware" >> >> I compiled the kernel with the firmware files already in /lib/firmware/r= adeon . >> The kernel boots without initial ram disk. >> > = > I've encountered people having all sorts of problems with stale or > truncated firmware, so I just wanted to double check. The best test > would be to build the driver as a module and blacklist the module, > then, once the system is booted to a non-X runlevel, manually load the > module so it loads the ucode directly from the filesystem. > = > Alex > = Thank you Alex, for insisting. The "Denkfehler" was indeed at my side: At f= irst, I compiled the kernel with the old firmware. Then I noticed the missing fir= mware module "CYPRESS_uvd.bin". After an information trip around the internet, I downloaded the missing and the up-to-date firmware modules and put them into place as well as adapted the kernel configuration. Then I just did a new "make" in the kernel directory. But, it seems the make rules don't recognize changed firmware modules. In t= he end I still saw the described error messages in the dmesg-output. Today, after reading your e-mail I came to this conclusion and recompiled t= he kernel completely, i.e., beginning with a "make clean". And, voil=E0, every= thing now works. Best regards, J=F6rg-Volker. [P.S.: I'm sorry, if you receive this letter twice, I somehow didn't send i= t to the list the first time.]