# radeon 6570, loading turks microcode hangs for 30 seconds

## nateo

I'm a gentoo newbie, but have been using Debian for a long time. 

Anyway, I am unable to get my kernels to run my Radeon 6570 card. I'm pretty certain I'm following the directions properly and have included the requisite binary blobs. That said, whenever I boot, the system hangs for about 60 seconds while it is "loading TURKS microcode". Subsequent attempts to start X fall back on VESA, which runs but doesn't look very pretty.

Any suggestions?

----------

## DONAHUE

```
emerge wgetpaste

wgetpaste /usr/src/linux/.config

wgetpaste /etc/portage/make.conf 

wgetpaste /etc/make.conf

ls /lib/firmware/radeon | wgetpaste
```

post the url's returned. you may not have one or the other make.conf

----------

## NeddySeagoon

nateo,

Welcome to Gentoo.

You should find some messages in dmesg about microcode loading, what files were lokked for and the varyig degrees of success.

Radeon should work without microcode but you will be missing 3D hardware acceleration.  That suggests you have two issues

Tell us where the microcode file(s) are and if the radeon kernel module is configured as <M> or <*>.

Mane friends with wgetpaste and put your kernel .config file and your dmesg on a pastebin site, then tell us the URLs.

----------

## nateo

Here you go:

http://bpaste.net/show/46455/

http://bpaste.net/show/46456/

http://bpaste.net/show/46457/

Thanks for taking a look!

----------

## DONAHUE

It wants turks  *Quote:*   

> "loading TURKS microcode"

  but you only gave it

```
 CONFIG_EXTRA_FIRMWARE="radeon/BARTS_mc.bin radeon/BARTS_me.bin radeon/BARTS_pfp.bin"
```

 built into kernel

----------

## NeddySeagoon

nateo,

Please choose the make.conf you like best and delete the other one.  Portage will use both, in order. It won't get confused but you might.

```
CONFIG_EXTRA_FIRMWARE="radeon/BARTS_mc.bin radeon/BARTS_me.bin radeon/BARTS_pfp.bin"

CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
```

make me nervous.

Does the kernel add the trailing / to "/lib/firmware" or not?

I have CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/"  with the trailing /.

/lib/firmwareradeon/BARTS_mc.bin will fail.   /lib/firmware//radeon/BARTS_mc.bin is safe.

----------

## nateo

Sorry about that. That last .config was not typical of my kernel setup.

This one better represents what I've been doing:

http://bpaste.net/show/46459/

The above has all the blobs that the gentoo xorg guide specifies (http://www.gentoo.org/doc/en/xorg-config.xml).

Anyway, I re-compiled and copied to boot, but it still doesn't work and I am have the same symptoms (i.e., hangs for 60 sec. while loading microcode, fallback to VESA when starting X).

Thanks again for looking.

----------

## nateo

 *NeddySeagoon wrote:*   

> Does the kernel add the trailing / to "/lib/firmware" or not?

 

I've tried it with both a trailing / and without. Doesn't make any difference. The kernel seems to find the firmware and compile it in. I've also checked that the requisite firmware is in the specified directory. It is.

----------

## DONAHUE

```
dmesg | wgetpaste

lspci -k | wgetpaste
```

post url's

----------

## nateo

Here's dmesg:

http://bpaste.net/show/46460/

Thanks for your time!

----------

## nateo

And I have radeon built into the kernel with <*>

----------

## nateo

And here's lspci:

http://bpaste.net/show/46461/

Thanks indeed!

----------

## NeddySeagoon

nateo,

```
[    0.709805] [drm] Loading TURKS Microcode

[   61.920599] ni_cp: Failed to load firmware "radeon/BTC_rlc.bin"

[   61.920743] [drm:evergreen_startup] *ERROR* Failed to load firmware!
```

The file radeon/BTC_rlc.bin is not compiled into your kernel.  When you have that, the kernel may fail to load another file.

Add that file to your CONFIG_EXTRA_FIRMWARE=, rebuild your kernel, rinse and repeat.

----------

## nateo

That seemed to make it hang longer at "loading TURKS microcode".

X still falls back to VESA.

It was still showing a failure to load firmware "radeon/BTC_rlc.bin"

I thought this was weird so I did a "make clean" and built and copied to boot again. No change, no joy. 

Here's the latest dmesg:

http://bpaste.net/show/46480/

Here's the new .config:

http://bpaste.net/show/46479/

BTC_rlc.bin has been added.

Any other thoughts/instructions would be greatly appreciated.

----------

## DONAHUE

I would add  *Quote:*   

> <*> /dev/agpgart (AGP Support)  --->
> 
> <*>   VIA chipset support 
> 
> <*> Support for frame buffer devices  --->
> ...

 to graphics support.

----------

## NeddySeagoon

nateo,

```
00:00.0 Host bridge: VIA Technologies, Inc. K8M890CE Host Bridge

   Subsystem: VIA Technologies, Inc. K8M890CE Host Bridge

   Kernel driver in use: agpgart-amd64
```

DONAHUE beat me to that one, except based on the above, I would suggest   agpgart-amd64.

Do you have lib/fimrmware/radeon/BTC_rlc.bin ?

----------

## nateo

That didn't change anything.

Anyway...

New dmesg:

http://bpaste.net/show/46496/

New .config:

http://bpaste.net/show/46498/

Thanks for your help!

----------

## BillWho

nateo,

I would suggest following the instructions by jasn  halfway down this thread https://forums.gentoo.org/viewtopic-t-931426.html?sid=895deb73eef1f22e8d2ce49ead30a99cwww.google.com

UPDATE: This should take you directly to it: https://forums.gentoo.org/viewtopic-p-7101452.html#7101452

----------

## nateo

Well, I tried that too, but no joy. 

Here's dmesg:

http://bpaste.net/show/46516/

And here's the new .config

http://bpaste.net/show/46517/

Everything that jasn said should be a module is. He also said that I should remove the references to the microcode in the .config. I did this using menuconfig and rerolled the kernel, but that didn't change anything. The blobs are still in the directory /lib/firmware/radeon although there is now now reference them in the .config. 

With the exception of a (possibly imagined) longer hang during "Loading TURKS Microcode" it doesn't seem like anything we've tried has altered in any way this problem. 

I'm starting to wonder if there is something absolutely basic that I'm missing, but I can't think of what it might be... 

I know this card works with a 3.2 kernel and later as it was running in this same machine (different Linux flavor) not long ago. It also runs fine with the Gentoo live DVD. I looked at dmesg from the live DVD and it loaded the microcode without a problem. This board (ASUS M2V-MX SE) does have an onboard VIA Chrome video chipset, but it is turned off in the BIOS--and that has never caused a problem before.

----------

## DONAHUE

you need the firmware in any case. if not built in it is loaded when the radeon module loads

----------

## DONAHUE

what is the make model of your computer

----------

## BillWho

nateo,

All your dmesg posts show the same messages. I don't know how you're compiling the kernel so  I just have to ask if bzImage's time stamp matches /boot/kernel   :Question: 

```
[    0.808837] [drm] Loading TURKS Microcode

[   61.920127] ni_cp: Failed to load firmware "radeon/BTC_rlc.bin"

[   61.920271] [drm:evergreen_startup] *ERROR* Failed to load firmware!

[   61.920416] radeon 0000:02:00.0: disabling GPU acceleration

[   61.921586] radeon 0000:02:00.0: ffff88013a53bc00 unpin not necessary

[   61.921764] radeon 0000:02:00.0: ffff88013a53b800 unpin not necessary

[   61.921908] radeon 0000:02:00.0: ffff88013a53b800 unpin not necessary

[   61.922076] [drm:evergreen_init] *ERROR* radeon: MC ucode required for NI+.

[   61.922219] radeon 0000:02:00.0: Fatal error during GPU init
```

----------

## nateo

The time stamps match and correspond to what I was doing last night. That is, I'm copying the kernel over over to boot properly. 

The machine is an ASUS M2V-MX SE running an Athlon X2 6000+ CPU and 4Gb of RAM

The GPU is a Radeon 6570.

Just to be sure I'm going nuke the original .config and start from scratch. We'll see how it goes.

Thanks for taking a look!

----------

## nateo

Well, I don't think that changed anything. Still hanging for 60 seconds while trying to load turks and X still falls back to VESA. I am a bit stumped here now. I did notice that the requisite firmware is in both /lib and /lib64. So, I changed the pointer in menuconfig to look for it in the lib64 directory, but it has made no difference.

I was looking through what seems the relevant section in dmesg, and there is a reference on line 571 which seems interesting:

 *Quote:*   

> radeon: No suitable DMA available.

 

That was a few lines before starts to hang at

 *Quote:*   

> [    1.537584] [drm] Loading TURKS Microcode
> 
> [   61.920123] ni_cp: Failed to load firmware "radeon/BTC_rlc.bin"
> 
> [   61.920266] [drm:evergreen_startup] *ERROR* Failed to load firmware!

 

Here's the whole dmesg dump:

http://bpaste.net/show/46590/

Here's the new .config:

http://bpaste.net/show/46591/

Before trying anything radical, like an EMP gun, I booted from the live DVD and took a look at dmesg. Here's the relevant section (I think):

 *Quote:*   

> [    0.433234] agpgart-amd64 0000:00:00.0: AGP bridge [1106/0336]
> 
> [    0.433241] agpgart-amd64 0000:00:00.0: aperture from AGP @ c0000000 size 256 MB
> 
> [    0.440722] agpgart-amd64 0000:00:00.0: AGP aperture is 256M @ 0xc0000000
> ...

 

It seems that the livd DVD is loading TURKS just fine and doesn't even look for radeon/BTC_rlc.bin, like my kernels are doing. 

Any ideas (short of an EMP gun)?

----------

## BillWho

nateo,

I don't know if this will be of any help or not, but for all it's worth here's my config http://bpaste.net/show/46598/

I don't have that card, but it is an amd - Advanced Micro Devices [AMD] nee ATI RS780 [Radeon HD 3200]

----------

## nateo

I was looking back at my quotes, and it seems that it is trying to load radeon "Evergreen" microcode for a "Northern Islands" chipset. Surely this can't be right.  Is this a bug or am I not understanding something.

----------

## BillWho

nateo,

I just ran across this https://forums.gentoo.org/viewtopic-t-925692-start-0.html

I seems that you're not the only one having difficulties with firmware.

The thread's solution seems a little strange to me   :Confused: 

----------

## nateo

Thanks for the help. That didn't seem to work either. I've read some various posts from people with similar problems and some of them seem to get fixed when they upgrade their kernels. I'm running 3.4.9, which I think is the latest stable (if that's what you call it in Gentoo). I notice you were running 3.6.x. Could you point me to some documentation on getting newer kernel sources?

Thanks for your time!

----------

## BillWho

 *nateo wrote:*   

> Thanks for the help. That didn't seem to work either. I've read some various posts from people with similar problems and some of them seem to get fixed when they upgrade their kernels. I'm running 3.4.9, which I think is the latest stable (if that's what you call it in Gentoo). I notice you were running 3.6.x. Could you point me to some documentation on getting newer kernel sources?
> 
> Thanks for your time!

 

No problem   :Very Happy: 

I'm using git-sources for that particular installation. You can find info on it  here  along with other kernels.

gentoo-sources is the most popular - I'm surprised that it's giving you so much trouble   :Confused: 

----------

