Bug 15166 - Changing brightness of backlight freezes kernel with radeon kms enabled.
Summary: Changing brightness of backlight freezes kernel with radeon kms enabled.
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 high
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-28 21:02 UTC by Manuel Ullmann
Modified: 2010-05-29 23:47 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.32.6 - 2.6.34
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Xorg-log from a normal X startup. (24.17 KB, text/plain)
2010-01-28 21:02 UTC, Manuel Ullmann
Details
Output from dmesg (66.19 KB, text/plain)
2010-01-28 21:12 UTC, Manuel Ullmann
Details
kernel configration file .config (59.76 KB, text/plain)
2010-01-28 21:28 UTC, Manuel Ullmann
Details
kernel 2.6.33-rc5 configuration file .config (61.84 KB, text/plain)
2010-01-30 23:45 UTC, Manuel Ullmann
Details
relevant lines of dmesg, when the kernel boots up without firmware (1.63 KB, text/plain)
2010-02-08 21:36 UTC, Manuel Ullmann
Details
kernel configration file .config of 2.6.33-rc7 (61.81 KB, text/plain)
2010-02-08 21:40 UTC, Manuel Ullmann
Details
kernel configuration file of 2.6.32.7 (59.60 KB, text/plain)
2010-02-08 21:44 UTC, Manuel Ullmann
Details
syslog-ng output of an isuue caused by BIOS. (140.84 KB, text/plain)
2010-02-09 20:58 UTC, Manuel Ullmann
Details
kernel 2.6.32.8 configuration file (59.31 KB, text/plain)
2010-02-10 11:28 UTC, Manuel Ullmann
Details
kernel 2.6.33-rc8 configuration file (61.66 KB, text/plain)
2010-02-19 14:46 UTC, Manuel Ullmann
Details
Dmesg output with drm in debug mode (grepped drm) (53.17 KB, application/octet-stream)
2010-02-19 14:56 UTC, Manuel Ullmann
Details
Dmesg output with drm in debug mode (grepped drm) (53.17 KB, text/plain)
2010-02-19 14:56 UTC, Manuel Ullmann
Details
.config file of kernel 2.6.33 (61.66 KB, text/plain)
2010-02-25 18:09 UTC, Manuel Ullmann
Details
possible fix (9.69 KB, patch)
2010-04-14 19:45 UTC, Alex Deucher
Details | Diff
alternate fix (10.26 KB, patch)
2010-04-14 19:47 UTC, Alex Deucher
Details | Diff
add accel parameter (7.67 KB, patch)
2010-04-27 17:35 UTC, Alex Deucher
Details | Diff
output from patch -p1 for all three patches (3.99 KB, text/plain)
2010-04-30 23:44 UTC, Manuel Ullmann
Details

Description Manuel Ullmann 2010-01-28 21:02:35 UTC
Created attachment 24769 [details]
Xorg-log from a normal X startup.

Overview:

Changing the brightness of the backlight freezes the kernel, when radeon kms (radeon.modeset=1) is enabled. Closing the LID for ca. 5 minutes does the same.

There are several ways to reproduce this:

1.

Step 1: Become root and enter the following:
echo 90 | dd of=/proc/acpi/video/*/LCD/brightness
The system should freeze.

2.

Step 1: If you have a laptop, you can close your LID and wait ca. 5 min. When you open it, you shouldn´t get your screen on.

3.

Step 1: If you have KDE 4 with powerdevil installed, simply type: startx
I guess, the system freezes when powerdevil tries to get control about the backlight.

Actual Results:

The system freezes.

Expected Results:

Changing the brightness should work. Switching on the monitor should work.

Build Date and Platform:

Build 2010-01-25 on Gentoo Linux 10.0

Additional Builds and Platforms:

Occurs also with Gentoo-kernel 2.6.32-gentoo-r2

Additional Information:

Hardware:

HP Compaq 6735b (FU308EA)
(Radeon HD 3200)

See also:
http://h10010.www1.hp.com/wwpc/uk/en/sm/WF06b/321957-321957-64295-3955547-3955547-3687779-3840808.html

Userspace-drivers were compiled from Gentoo x11-overlay.

The symptoms of the freeze are very similar to those of a kernel panic:

- MAGIC_SYSRQ is not working.
- New USB-devices are not powered.
- Mouse freezes.
- In console the cursor is disappearing.

But:

- Num Lock and Caps Lock LED are not blinking
- Caps Lock LED does not glow.

I could not boot the 2.6.33-rc5-kernel, because amd-ucode was missing. I will fix it and test this version later.

I´ll attach Xorg-log.
Comment 1 Manuel Ullmann 2010-01-28 21:08:14 UTC
I forgot to mention, that the screen of course switches on, when the LID is opened before these 5 minutes. I guess the freeze is caused, because radeon tries to switch off the video signal.

If you need any debug outputs from specific kernel-drivers, just tell me the needed kernel options.
Comment 2 Manuel Ullmann 2010-01-28 21:12:29 UTC
Created attachment 24770 [details]
Output from dmesg
Comment 3 Manuel Ullmann 2010-01-28 21:28:27 UTC
Created attachment 24771 [details]
kernel configration file .config
Comment 4 Manuel Ullmann 2010-01-28 22:21:38 UTC
I tested this with kernel 2.6.33-rc5 now. This kernel-version is still affected by this bug.
Comment 5 Manuel Ullmann 2010-01-30 23:45:54 UTC
Created attachment 24810 [details]
kernel 2.6.33-rc5 configuration file .config
Comment 6 Manuel Ullmann 2010-01-31 00:18:38 UTC
Ah, I forgot the fourth way of reproducing this bug:

If you have Laptop with BIOS-driven brightness-changing (they change the brightness, when the power cable is unplugged), you can unplug it to get your system frozen.

This bug affects also kernel-version 2.6.32.7.
Comment 7 Alexey Diomin 2010-02-01 19:20:55 UTC
HP Compaq 6735b (KU214EA)
(Radeon HD 3200)

bug reproduced
Comment 8 Alexey Diomin 2010-02-01 21:20:21 UTC
2.6.33-rc6 also with bug
Comment 9 Manuel Ullmann 2010-02-03 22:16:02 UTC
Thank you for confirming this bug. I reproduced this also with 2.6.33-rc6.

To summarize the bug again:

This bug seems to occur, whenever any software (BIOS, powerdevil, echo using the /proc filesystem) tries to reach control over the backlight and when radeon itself tries to switch off the video signal.

It would be interesting, if it affects only RS780M (Radeon HD 3200 mobile version) or also other Mobility chips of R6xx-7xx or even all Mobility chips. (The desktop chips usually don´t need to change the backlight brightness.)
Maybe I´ll ask on forums.gentoo.org, if some guys with this hardware could test this with radeon kms.
Comment 10 Rafał Miłecki 2010-02-03 22:22:27 UTC
I have Sony VAIO notebook with ATI 34xx GPU and I use KMS since it's first day.

Brightness on my notebook is controlled by GPU (I can hack GPU registers to change brightness). I have /sys/class/backlight/acpi_video0 created by acpi/video.c driver. Changing brightness with /sys/class/backlight/acpi_video0, or with KDE doesn't cause problems.

I get lock up on resuming (bug #15096) but this should not be related.
Comment 11 Alex Deucher 2010-02-03 23:30:07 UTC
I have a rs780-based laptop and the backlight works just fine via acpi.
Comment 12 Alexey Diomin 2010-02-04 14:16:11 UTC
2 Rafał Miłecki

cat /sys/class/backlight/acpi_video0/brightness
0

echo 10 > cat /sys/class/backlight/acpi_video0/brightness
system freeze

with patch http://bugzilla.kernel.org/attachment.cgi?id=24711 from you bug

cat /sys/class/backlight/acpi_video0/brightness
24
correct.

echo 10 > cat /sys/class/backlight/acpi_video0/brightness
system freeze
Comment 13 Manuel Ullmann 2010-02-05 20:07:19 UTC
@Rafał Miłecki:
Your bug should indeed not be related to this one, because, as you wrote in your report, you switched to init 3 and disabled radeon (and kms, in consequence) in your kernel configuration for testing purposes.

@Alex Deucher:
And you are using kms? Cause of course brightness-changing works fine, if appending radeon.modeset=0 to kernel command line. If you are using kms, the reasons for this bug are shrinking. The question is now: What has this notebook series, what others don´t have? The first thing, that comes into my mind, is UEFI with its BIOS. It changes the brightness, when the power cable is unplugged (but actually there are other BIOSes like that and I´m wondering, why this bug doesn´t occur without kms or with my old framebuffer driver uvesafb).

What you all could test, is the second way - I mentioned above - to reproduce a system freeze. Actually this should be another bug, but I didn´t realize that while writing the bug report.

Close the LID for ca. 5 minutes. Radeon should try to switch off the video signal then and freeze the system. Switching on and off the monitor is no problem.
Comment 14 Alex Deucher 2010-02-05 20:35:34 UTC
Yes, I'm using KMS. closing the lid or changing the brightness works fine.  Likely, acpi is interacting badly with the hw.  We probably need to set some additional scratch reg bits for newer systems.
Comment 15 Manuel Ullmann 2010-02-05 21:58:45 UTC
I guess you took in account, that waiting the 5 minutes is important. Cause I wrote in Comment #1 already, that LID closing and opening within this time amount is not the problem (radeon disables and enables the monitor fine). But I guess it is as you said a problem of new hardware.

I just reproduced it and found, that the system freeze differs slightly from that of the brightness-changing. While the sound-mute-LED changes her color as usual from yellow to blue and back, if pressed after a system freeze through brightness-changing, it does not, when the freeze is caused by closing LID (and waiting 5 min.). All other symptoms are the same (sysrq not working, USB-devices not powered etc.). Triggering the other LEDs seems to work; they are dimmed and brightened as usual, when pressed (on both freezes). The Wireless-LED of course does not work, because the (USB-)wireless-chip has to be initialized before. 

Ah, and I asserted, that Knoppix 6.1 freezes on boot, when I booted it without acpi=off. But all other linux distributions didn´t have that problem (including an installed Gentoo and Ubuntu and Live CDs like grml and dsl) so I guess it is not relevant. (Knoppix 6.1 had kernel version 2.6.28.4)
Comment 16 Alex Deucher 2010-02-05 22:03:00 UTC
Does messing with the display switch hotkey also cause problems?
Comment 17 Manuel Ullmann 2010-02-08 13:32:53 UTC
Sorry, that this took so long. I was offline for 2 days.

I guess you mean the Ctrl+Alt+Fn key-combo, because laptops have usually also a key with the keycode 'SWITCHVIDEOMODE' on a Fn+Fx key-combo.

Well, display switching works fine. Switching from console to X takes ca. 2 seconds. The switchvideomode-key (for me Fn+F4) switches backwards through consoles from F12 to F1, while there is actually a 13th X interface (this would be F13) before switching to F12 (/var/log/messages). But maybe it is reserved for something else. Using Fn+F4 writes also 'p' out to console and X.

Since a comparison with the kernel behaviour of a desktop pc, I know now what the kernel is trying to do after this time amount of 5 min. in console. It tries to blank the screen. But with kms enabled, the monitor is instead switched off and the system freezes. So it´s not necessary to close the lid. You just have to wait 5 minutes doing nothing. But the LED of the sound-mute-button is still working then. (in contrast to a system freeze with lid closed)
Comment 18 Manuel Ullmann 2010-02-08 21:36:46 UTC
Created attachment 24955 [details]
relevant lines of dmesg, when the kernel boots up without firmware

I found accidentally the piece of code, which causes the system freeze. I was searching for a reason for the 20% CPU-load of X and thought this could be radeon-ucode (I didn´t know at this point, that this is built into all kernel-releases except for release candidates; well, i guess now that the experimental drivers alone are the reason). So I removed radeon-ucode from kernel configuration and rebooted. I was wondering, why the kernel took about 2 minutes to boot, but when it started, brightness control and blanking the screen worked.

A look into dmesg (see attachement) showed me unfortunately, that the kernel was missing firmware for radeon and had for this reason deactivated GPU acceleration. To be specific, the firmware is:

R600_rlc.bin for me in /lib/firmware/radeon/

The kernel waits ca. 1 min. before continuing the boot sequence without it.
2.6.33-rc5 hangs without it, so it "works" only with 2.6.33-rc6 and rc7.
So I think, until the firmware is not updated, kms won´t be usable for me.

Any other suggestions? Do you need some more debug outputs?
Comment 19 Manuel Ullmann 2010-02-08 21:40:41 UTC
Created attachment 24956 [details]
kernel configration file .config of 2.6.33-rc7
Comment 20 Manuel Ullmann 2010-02-08 21:42:10 UTC
As this bug affects also 2.6.33-rc7 (also it´s the firmware), I mark it as affected.
Comment 21 Manuel Ullmann 2010-02-08 21:44:29 UTC
Created attachment 24957 [details]
kernel configuration file of 2.6.32.7

@Comment 20: I meant although
Comment 22 Manuel Ullmann 2010-02-09 20:58:17 UTC
Created attachment 24980 [details]
syslog-ng output of an isuue caused by BIOS.

@Alex Deucher:

You mentioned earlier some 'scratch reg bits'. What are they doing? How could they fix issues specific to certain systems like the Compaq 6735b series?
Your patch at http://people.freedesktop.org/~agd5f/0001-drm-radeon-kms-add-additional-safe-regs-for-r4xx-rs.patch seems to be related to those bits, but it is specific to some graphic chips.


I have experienced, that waking up from S3 or S4 can indeed change the brightness with kms. As mentioned in Comment 12, the brightness uninitialized until it is changed. /sys/class/backlight/acpi_video?/backlight has the value 0, although the backlight has full brightness, which should be 24. When hibernate-script reinitializes the backlight, it is switched to its lowest brightness. So I can choose now between the highest and lowest brightness. But nevertheless the main issue, that the system freezes after certain amount of inactivity, remains.

I understand, that the firmware is not likely to be updated and that instead the kernel framework around it maybe has to be fixed. Of course this could be also BIOS-related, as I had already an issue, which was caused by an error in BIOS with this notebook (see attachement). But as this Bug is not OS-independent, I doubt that it would be fixed ever.
Comment 23 Manuel Ullmann 2010-02-10 11:28:03 UTC
Created attachment 24987 [details]
kernel 2.6.32.8 configuration file
Comment 24 Manuel Ullmann 2010-02-19 14:46:53 UTC
Created attachment 25115 [details]
kernel 2.6.33-rc8 configuration file

Bug persists in 2.6.33-rc8. However there is a new kms-driver. But according to help, support for R6xx-7xx is not finished yet. Additionally it´s based on a new driver stack, which is not specified. I´ve found the branch 'kms-support' in xf86-video-ati, but don´t know, if it was for initially kms-support in 2.6.32 or it is new. Do you know which branches are needed for the new driver stack?
Comment 25 Manuel Ullmann 2010-02-19 14:56:08 UTC
Created attachment 25116 [details]
Dmesg output with drm in debug mode (grepped drm)

I´ve tested the kernel option drm.debug=15, but it does not give any hints on the cause of this problem. Is there any way to see the kernel-output on screen, although screen freezes? Syslog-ng saves no output, but it is of course not able to, because the kernel freezes. I´m quite sure, that the kernel should give some output, although I can not see that.
Comment 26 Manuel Ullmann 2010-02-19 14:56:16 UTC
Created attachment 25117 [details]
Dmesg output with drm in debug mode (grepped drm)

I´ve tested the kernel option drm.debug=15, but it does not give any hints on the cause of this problem. Is there any way to see the kernel-output on screen, although screen freezes? Syslog-ng saves no output, but it is of course not able to, because the kernel freezes. I´m quite sure, that the kernel should give some output, although I can not see that.
Comment 27 Alex Deucher 2010-02-19 16:27:17 UTC
(In reply to comment #24)
> Bug persists in 2.6.33-rc8. However there is a new kms-driver. But according
> to
> help, support for R6xx-7xx is not finished yet. Additionally it´s based on a
> new driver stack, which is not specified. I´ve found the branch 'kms-support'
> in xf86-video-ati, but don´t know, if it was for initially kms-support in
> 2.6.32 or it is new. Do you know which branches are needed for the new driver
> stack?

R6xx-R7xx is finished, the help is outdated.  As to the driver stack, you need xf86-video-ati from git master, and mesa from git master or 7.7 branch both built against libdrm from git master or 2.4.18.
Comment 28 Manuel Ullmann 2010-02-19 22:15:11 UTC
Tried this with both the master and 7.7 mesa branch. Bug was not fixed. Would it be possible to see any output from kernel, if I would be on a remote ssh session?
Comment 29 Manuel Ullmann 2010-02-25 18:06:36 UTC
Bug still in 2.6.33. As expected. I´ll attach the config.
Comment 30 Manuel Ullmann 2010-02-25 18:09:23 UTC
Created attachment 25223 [details]
.config file of kernel 2.6.33
Comment 31 Alexey Diomin 2010-04-14 12:20:25 UTC
2.6.34-rc3 with latest patches from drm-next aslo freeze
Comment 32 Alex Deucher 2010-04-14 14:14:24 UTC
Does setting:
Option "NoAccel" "True"
in the device section of your xorg.conf avoid the problem?  Make sure you are using xf86-video-ati 6.12.191 or newer.
Comment 33 Alex Deucher 2010-04-14 14:18:15 UTC
One more thing, does disabling kms avoid the problem as well?  E.g., disable KMS and make sure ums + acceleration is working.
Comment 34 Alex Deucher 2010-04-14 19:45:51 UTC
Created attachment 26004 [details]
possible fix

Possible fix version 1.  Please try these patches individually and let me know if either of them fixes the problem.
Comment 35 Alex Deucher 2010-04-14 19:47:01 UTC
Created attachment 26005 [details]
alternate fix

Alternate fix.  Please try these patches individually and let me know if either of them fixes the problem.
Comment 36 Alexey Diomin 2010-04-15 15:04:51 UTC
fixs not helped

mesa & xf86-video-ati from git, but all tests in runlevel 3 (without starting X)

when run F13-Beta-i686-Live-KDE.iso (del rhgb) freeze after start kms
http://ivctrans.by/temp/PIC-0032.jpg

on f12 (tested half of the year earlier) has message as on f13 beta now
Comment 37 Aurélien Couderc 2010-04-26 17:38:07 UTC
Lenovo X100e also affected.
(Radeon HD 3200)
Comment 38 Aurélien Couderc 2010-04-27 16:51:41 UTC
To answer Alex Deucher's questions:
#32 NoAccel doen't solve the problem (driver 6.13.0)
#33 disabling KMS solves the problem and ums+acceleration works fine
Comment 39 Alex Deucher 2010-04-27 17:35:11 UTC
Created attachment 26161 [details]
add accel parameter

This patch adds an accel parameter that allows you to disable acceleration in the drm.  boot with radeon.accel=0 and see if you still get the hang.
Comment 40 Alex Deucher 2010-04-28 03:38:58 UTC
I managed to get remote access to an affected machine today, and to start off with I tried Linus' git tree, bc113f151a73cb2195c2fb40d7d70acf8e2f9208, to be exact.  And, low and behold, the backlight worked fine. Switched back to an older kernel and it hung.  So it appears to be fixed, at least as of that commit.  Can anyone else confirm and if so, help bisect to see what fixed it?
Comment 41 Alexey Diomin 2010-04-28 16:43:41 UTC
2.6.34-rc5-git8 bug affected

with your patch and boot with radeon.accel=0 all working without freeze
Comment 42 Alexey Diomin 2010-04-29 08:48:57 UTC
updated Linus' and your git tree

apply 2 patch on 2.6.34-rc5-git8

1. diff origin...dave_drm/drm-linus 
2. diff origin...dave_drm/drm-radeon-next

kms work fine
Comment 43 Alex Deucher 2010-04-29 15:56:47 UTC
(In reply to comment #42)
> updated Linus' and your git tree
> 
> apply 2 patch on 2.6.34-rc5-git8
> 

Which patches are you referring to?

> 1. diff origin...dave_drm/drm-linus 
> 2. diff origin...dave_drm/drm-radeon-next
> 
> kms work fine

Does an updated tree without the patches also work?
Comment 44 Manuel Ullmann 2010-04-30 23:44:09 UTC
Created attachment 26191 [details]
output from patch -p1 for all three patches

I tested kernel-2.6.34-rc6 from git. The kernel itself has not fixed the hang.

The patches probably do not apply, because the patched files have changed too much. I attached the output of 'patch'. However it would be great, if you could adjust them.

The "add accel parameter patch" applies mostly correct, so the radeon.accel=0 works and in consequence the brightness changing (as Alexey said).

But so far I could not get kms completely to work.
Comment 45 Alexey Diomin 2010-05-03 08:35:05 UTC
For testing I switch to drm-radeon-testing branch

commit 6b8b1786a8c29ce6e32298b93ac8d4a18a2b11c4 resolved bug.
Comment 46 Manuel Ullmann 2010-05-03 21:58:30 UTC
Confirmed. Fixed in drm-radeon-testing branch. No patch needed.

Aurélien Couderc, could you confirm this on your notebook?
Comment 47 Aurélien Couderc 2010-05-04 22:59:41 UTC
Yes, it's fixed in drm-radeon-testing for my laptop too.
Comment 48 Alex Deucher 2010-05-05 15:00:30 UTC
One of my coworkers who is also experiencing the problem bisected it down to:
f3eee54276dfd1117fd94259f2b4a38388264724:

commit f3eee54276dfd1117fd94259f2b4a38388264724
Author: Yinghai Lu <yinghai@kernel.org>
Date:   Mon Dec 14 11:52:15 2009 +0900

   x86: Gart: fix breakage due to IOMMU initialization cleanup

   This fixes the following breakage of the commit
   75f1cdf1dda92cae037ec848ae63690d91913eac:

   - GART systems that don't AGP with broken BIOS and more than 4GB
     memory are forced to use swiotlb. They can allocate aperture by
     hand and use GART.

   - GART systems without GAP must disable GART on shutdown.

   - swiotlb usage is forced by the boot option,
     gart_iommu_hole_init() is not called, so we disable GART
     early_gart_iommu_check().

   Signed-off-by: Yinghai Lu <yinghai@kernel.org>
   Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
   LKML-Reference:
   <1260759135-6450-3-git-send-email-fujita.tomonori@lab.ntt.co.jp>
   Signed-off-by: Ingo Molnar <mingo@elte.hu>
Comment 49 Manuel Ullmann 2010-05-12 11:27:42 UTC
If it has been confirmed, that the kernel is bug affected immediately before this commit, then it´s fine for me. But it seems, that it can be caused by the broken BIOS alone. The Radeon chip is not linked via AGP, but PCI express and I don´t have more than 4GB memory (actually 2). Well, I guess we can close the Bug now. Does anyone disagree? Btw, will this fix be merged into master until the 2.6.34 release?
Comment 50 Manuel Ullmann 2010-05-14 20:57:16 UTC
Well, I´ll close the bug now. Would be nice, if anyone could answer my question, though.
Comment 51 Alex Deucher 2010-05-15 12:02:06 UTC
No one has yet tracked down what fixed it.  That is just the commit that apparently broke it, at least for one user.
Comment 52 Manuel Ullmann 2010-05-15 12:35:50 UTC
Ah, sorry. I misunderstood you. (my english is quite bad)
Comment 53 Alexey Diomin 2010-05-15 15:24:17 UTC
Revert f3eee54276dfd1117fd94259f2b4a38388264724 on current 2.5.34-rc7 also not resolved bug
Comment 54 Jérôme Glisse 2010-05-16 10:47:38 UTC
Alexey what do you mean ? The bug is still present on 2.6.34-rc7 ? and reverting 
f3eee54276dfd1117fd94259f2b4a38388264724 doesn't solve the issue ?
Comment 55 Alexey Diomin 2010-05-19 08:33:13 UTC
2 Jérôme Glisse 

On current moment bug fix only in drm-next brunch, on 2.6.34-rc7 kms freeze.

As say Alex: bug started with commit f3eee54276dfd1117fd94259f2b4a38388264724.
For testing I revert f3eee54276dfd1117fd94259f2b4a38388264724 on 2.6.34-rc7, but bug remain.

P.S. it's all work for me and maybe for Manuel (laptop equals)
Comment 56 Manuel Ullmann 2010-05-24 00:14:19 UTC
The fix is in both branches; drm-next and drm-radeon-testing. It is:

commit 7547a917fa5f3b2406f52c7dcf7ec9ad3c8532eb
Merge: a8089e8 6b8b178
Author: Dave Airlie <airlied@redhat.com>
Date:   Tue Apr 20 14:15:09 2010 +1000

    Merge branch 'drm-ttm-unmappable' into drm-core-next

    * drm-ttm-unmappable:
      drm/radeon/kms: enable use of unmappable VRAM V2
      drm/ttm: remove io_ field from TTM V6
      drm/vmwgfx: add support for new TTM fault callback V5
      drm/nouveau/kms: add support for new TTM fault callback V5
      drm/radeon/kms: add support for new fault callback V7
      drm/ttm: ttm_fault callback to allow driver to handle bo placement V6
      drm/ttm: split no_wait argument in 2 GPU or reserve wait

    Conflicts:
        drivers/gpu/drm/nouveau/nouveau_bo.c

Steps to confirm:

1. Create new drm-2.6 repository

2. Checkout one of the mentioned branches

3. Reset to this commit

4. Compile, install kernel and reboot

5. Test backlight changing.
-> Result: Bug fixed

6. cd to git repository. Reset to one commit before (git reset --hard HEAD^).

7. Compile, install kernel and reboot

8. Test backlight changing.
-> Result: kms freeze
Comment 57 Manuel Ullmann 2010-05-28 19:52:31 UTC
Marking 2.6.34 as affected. Fixed however in drm-next and drm-radeon-testing since 2.6.34-rc5 by the mentioned fix. Any chances, that this will be merged into 2.6.35 master?
Comment 58 Alex Deucher 2010-05-28 20:31:43 UTC
Already merged into 2.6.35.
Comment 59 Manuel Ullmann 2010-05-29 23:47:03 UTC
Thank you. It´s indeed fixed in latest git. No need to leave the bug open, I think.

Note You need to log in before you can comment on or make changes to this bug.