# ATI Radeon 5800 series kernel crash

## Phr33d0m

Hello people, I've been having some problems with ati-drivers... I wouldn't want to go to the opensource ones as I like my 3D acceleration... 

Any help with this will be greatly appreciated.

Since almost always I've been having my dmesg full with this kind of stuff:

http://dpaste.org/dE6EL/

And sometimes I could work with my system for some hours, even days, but it alwasy appeared a kernel panic - which I could never get it dumped somewhere...

Unil now, today I got this dump which I think it's what I needed in order to make a bug or report or whatever...

http://dpaste.org/fNm4F/

Is there any way I can fix this (at least temporary)? So I can keep using ati-drivers?

```
-(~)> lspci | grep VGA

01:00.0 VGA compatible controller: ATI Technologies Inc Cypress [Radeon HD 5800 Series]
```

I've been having this problem with: 

* my current ATI Radeon 5850 (sapphire)

* ATI Radeon 5830

* my brother's 5870

EDIT: Something very important I forgot to mention: 

It's NOT a kernel panic, as everything else keeps running (if I have audacious playing music for example). 

My screen just gets frozen and I can't move mouse neither my keyboard responds, but music, ssh, httpd and mysql servers keep running and I can connect to ssh and issue a 'reboot'.

EDIT 2: The first error log only shows if I have set my kernel as PREEMPT, if the kernel has no preemption the errors doesn't show but I still get the screen freeze after some time (and sometimes it's even a kernel panic).

----------

## Hu

According to the output, fglrx.ko is using smp_processor_id in a context where it is not safe to do so.  Normally, the correct response is to fix the code.  However, since this is the closed driver, you cannot do that.  You can raise a ticket with ATI to have them fix the code or you can disable preemption.  Using smp_processor_id in that context should be safe when preemption is off.

The ASIC hang in your second paste could be a side effect of the fglrx bug that caused the trace in your first paste.  If you can reproduce the ASIC hang without preemption, then you should raise a bug with the fglrx authors.

----------

## Phr33d0m

 *Hu wrote:*   

> According to the output, fglrx.ko is using smp_processor_id in a context where it is not safe to do so.  Normally, the correct response is to fix the code.  However, since this is the closed driver, you cannot do that.  You can raise a ticket with ATI to have them fix the code or you can disable preemption.  Using smp_processor_id in that context should be safe when preemption is off.
> 
> The ASIC hang in your second paste could be a side effect of the fglrx bug that caused the trace in your first paste.  If you can reproduce the ASIC hang without preemption, then you should raise a bug with the fglrx authors.

 

Thanks for your answer.

There's only one problem, with preemption the problem is "screen freezing" and it might occur even in a couple of days.

With no preemption - I get rid of the errors but then in some hours (not even a day) what I get is a kernel panic and the only thing I can do is a forced reset (from the case button).

Any other ideas/suggestions?

----------

## Hu

Kernel panics are much better than screen problems.  With a kernel panic, you can capture the text and send it to the fglrx authors to have them fix their code.

Your other option is to stop using buggy drivers.  It is up to you whether that means switching to the stable open drivers or picking through alternate versions of the closed drivers in hopes of finding one that is stable.

----------

## Phr33d0m

 *Hu wrote:*   

> Kernel panics are much better than screen problems.  With a kernel panic, you can capture the text and send it to the fglrx authors to have them fix their code.
> 
> Your other option is to stop using buggy drivers.  It is up to you whether that means switching to the stable open drivers or picking through alternate versions of the closed drivers in hopes of finding one that is stable.

 

The second pastebin I gave was actually the kernel panic itself http://dpaste.org/fNm4F/

I've been going through all the drivers in portage but none seems to work.

I'll try to contact fglrx's devs and see what they say. For now, stick with the opensource.

----------

## IQgryn

Do you have a bug link?  I think I'm getting hit by the same issue, and I'd like to follow the fix progress.

----------

