# ALL kernels hang after "...clocksource tsc" [SOLVED]

## DawgG

on my perfectly running and up-to-date htpc ~amd64-system i did not do any updates between March 23 and April 12. then i updated everything including gentoo-sources (from 3.8.2 to 3.8.7 recently).

since then all kernels compiled in the upated environment hang for ~1min at "Switching to clocksource tsc" and then the whole screen turns white and the system is frozen. Luckily i have a backup of the previous 3.8.2-kernel and modules. Even booting a kernel compiled using the same sources and .config  (3.8.2) has this result.

It is an amd-5600-apu with an on-cpu radeon 7540d (firmware-files are ARUBA*); i have compiled the kernel with and w/out the firmware inside it; with ALL firmwares in /lib/fimware/radeon/* inside it but the result is always the same. (The working kernel has RLC_600.bin and RLC_700.bin compiled into it which should be wrong according to http://wiki.gentoo.org/wiki/Radeon but it works perfectly and dmesg states "Loading ARUBA firmware"). with "make oldconfig" and the .config from the working kernel no options were changed or added. everything regarding CONFIG_DEVTMPFS* is there and working; no boot-options that were suggested (eg "clocksource=jiffies") have changed anything. i even recompiled glibc and gcc. last nite smae result with 3.8.2 and 3.8.7

i am completely at a loss what's going on here - is there an error in x11-drivers/radeon-ucode or sth.?

THX for your help!

----------

## krinn

While someone suggest that already, i would suggest it again but with hpet, try the clocksource=hpet (as you don't need to change anything if your kenrel handle it, it will be fast to test)

The next test is slower to do, as you need to rebuild your kernel : disable the radeon like if you don't have any.

After this two tests, you should be able to find the cause, still not the cure, but finding cause is 90% of the cure. If none of them works, your first guess at the clocksource and the radeon were wrong.

----------

## DawgG

THX for your reply.

booting with 

```
clocksource=hpet
```

 changed nothing, but leaving anything with radeon out of the kernel (drm-drivers deactivated and also using vesafb instead of radeon) makes the kernel boot again.

but what to do now? the system is practicably unusable now, just showing the gui of xbmc uses 100% of one core and it sounds like a vacuum-cleaner then  :wink: 

(also there is one error about "libpng icc error - wrong sRGB profile" - but i guess that is unrelated.)

i'll compile a new kernel with vesafb, radeon-drm as a module and ARUBA_*.bin inside it and see what happens then.

----------

## DawgG

 *Quote:*   

> with vesafb, radeon-drm as a module and ARUBA_*.bin inside it and see what happens then.

 

that was it, it boots AND works now. the reason for the error was radeonfb

```
lsmod

<SNIP>

drm_kms_helper         26887  1 radeon

</SNIP>
```

```
dmesg

<SNIP>

[    1.974842] [drm] GART: num cpu pages 131072, num gpu pages 131072

[    1.975690] [drm] Loading ARUBA Microcode

</SNIP>
```

```
CONFIG_EXTRA_FIRMWARE="ARUBA_rlc.bin ARUBA_pfp.bin ARUBA_me.bin"

CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/radeon"

CONFIG_DRM_RADEON=m

CONFIG_DRM_RADEON_KMS=y

CONFIG_FB=y

CONFIG_FB_BOOT_VESA_SUPPORT=y

CONFIG_FB_CFB_FILLRECT=y

CONFIG_FB_CFB_COPYAREA=y

CONFIG_FB_CFB_IMAGEBLIT=y

CONFIG_FB_MODE_HELPERS=y

CONFIG_FB_VESA=y
```

maybe i'll play around with it a little bit more but you set me on the right track.

THX for your help again!

----------

