Bug 55006

Summary:

video playback causes total freeze on RV350

Product:

DRI

Reporter:

spamfang1199

Component:

DRM/Radeon

Assignee:

Default DRI bug account <dri-devel>

Status:

RESOLVED MOVED

QA Contact:

Severity:

major

Priority:

high

Version:

XOrg git

Hardware:

x86 (IA32)

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
logs from an affected boot right after a crash and a reboot	none
next row of crashes	none

Description spamfang1199 2012-09-17 10:35:24 UTC

Video playback and switching between tabs while browsing often leads to total freeze of my system. Even the magic SysRQ keys wont work then.

steps to reproduce:
Watching movies with vlc, or switching between tabs is often enough to freeze the system.

It all started with introducing KernelModeSetting to Linux. This bug has been affecting me since i upgraded from Debian Lenny to Squeeze and thus to Kernel 2.6.32. I could avoid that bug however by adding "radeon.modeset=0" at the boot prompt from 2.6.32.

Now with Linux 3.2 even passing "radeon.modeset=0" at the boot prompt does not work any more for me. 

I reported the bug to Debian and they told me to try Linux 3.5, which also freezes often. For reference here is the link to my bug report:

http://bugs.debian.org/680097 

This is a very serious regression for my RV350 and causes file system corruption & data loss (for my work progress)

I cannot add a log from the freeze, since nothing gets logged then. If you know a way i could give you one, let me know.

Comment 1 spamfang1199 2012-09-17 10:50:33 UTC

Created attachment 67273 [details]
logs from an affected boot right after a crash and a reboot

Comment 2 Alex Deucher 2012-09-17 13:19:25 UTC

Make sure you install the firmware nonfree package for debian.

Comment 3 Michel Dänzer 2012-09-17 14:31:45 UTC

Does radeon.agpmode=-1 on the kernel command line help?

Comment 4 spamfang1199 2012-09-18 17:06:14 UTC

Firmware linux-free & non-free are installed.

I tested Linux 3.2 again, this time with radeon.agpmode=-1. It seems to work for me. I put the machine under heavy load and played several vids at the same time: no freeze so far.

So what do you guess the problem is? And in case you solve the bug, could you backport it to Linux 3.2 too?

Comment 5 Alex Deucher 2012-09-18 17:10:24 UTC

(In reply to comment #4)
> Firmware linux-free & non-free are installed.
> 
> I tested Linux 3.2 again, this time with radeon.agpmode=-1. It seems to work
> for me. I put the machine under heavy load and played several vids at the same
> time: no freeze so far.
> 
> So what do you guess the problem is? And in case you solve the bug, could you
> backport it to Linux 3.2 too?

AGP seems to be unstable on your system.  Setting radeon.agpmode=-1 should work on older kernels as well.  You might also try setting other values for agpmode.  Try values 1, 2, 4, or 8 and see if any work for you and if so we can add a quirk for your system.

Comment 6 spamfang1199 2012-09-19 10:32:29 UTC

Created attachment 67371 [details]
next row of crashes

Comment 7 spamfang1199 2012-09-19 10:32:49 UTC

Sorry my cheers about radeon.agpmode=-1 came too early. I did some more testing and the results are these:

radeon.agpmode=-1 freeze
radeon.agpmode= 1 freeze
radeon.agpmode= 2 freeze
radeon.agpmode= 4 freeze
radeon.agpmode= 8 invalid mode, kernel leaves it at 4

I add another logfile to this comment. It contains all the crashes from my agpmode tryouts. I hope this may help you somehow.

Comment 8 spamfang1199 2012-10-15 14:36:26 UTC

Another thing which might be helpful in finding the bug might be this:

When i add radeon.agpmode=-1 to the kernel 2.6.32 commandline, the system shows the same freeze behaviour as with 3.2 and 3.5, BUT it stays freezed only for a few seconds, then continues to operate normally.

For that reason i am using radeon.modeset=0 (with kernel 2.6.32), which does not lead to these short time freezes.

Please fix this serious regression. I dont want to buy new hardware.

Comment 9 Martin Peres 2019-11-19 08:29:16 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/301.

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.