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.
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.
Created attachment 24770 [details] Output from dmesg
Created attachment 24771 [details] kernel configration file .config
I tested this with kernel 2.6.33-rc5 now. This kernel-version is still affected by this bug.
Created attachment 24810 [details] kernel 2.6.33-rc5 configuration file .config
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.
HP Compaq 6735b (KU214EA) (Radeon HD 3200) bug reproduced
2.6.33-rc6 also with bug
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.
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.
I have a rs780-based laptop and the backlight works just fine via acpi.
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
@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.
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.
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)
Does messing with the display switch hotkey also cause problems?
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)
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?
Created attachment 24956 [details] kernel configration file .config of 2.6.33-rc7
As this bug affects also 2.6.33-rc7 (also it´s the firmware), I mark it as affected.
Created attachment 24957 [details] kernel configuration file of 2.6.32.7 @Comment 20: I meant although
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.
Created attachment 24987 [details] kernel 2.6.32.8 configuration file
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?
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.
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.
(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.
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?
Bug still in 2.6.33. As expected. I´ll attach the config.
Created attachment 25223 [details] .config file of kernel 2.6.33
2.6.34-rc3 with latest patches from drm-next aslo freeze
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.
One more thing, does disabling kms avoid the problem as well? E.g., disable KMS and make sure ums + acceleration is working.
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.
Created attachment 26005 [details] alternate fix Alternate fix. Please try these patches individually and let me know if either of them fixes the problem.
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
Lenovo X100e also affected. (Radeon HD 3200)
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
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.
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?
2.6.34-rc5-git8 bug affected with your patch and boot with radeon.accel=0 all working without freeze
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
(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?
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.
For testing I switch to drm-radeon-testing branch commit 6b8b1786a8c29ce6e32298b93ac8d4a18a2b11c4 resolved bug.
Confirmed. Fixed in drm-radeon-testing branch. No patch needed. Aurélien Couderc, could you confirm this on your notebook?
Yes, it's fixed in drm-radeon-testing for my laptop too.
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>
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?
Well, I´ll close the bug now. Would be nice, if anyone could answer my question, though.
No one has yet tracked down what fixed it. That is just the commit that apparently broke it, at least for one user.
Ah, sorry. I misunderstood you. (my english is quite bad)
Revert f3eee54276dfd1117fd94259f2b4a38388264724 on current 2.5.34-rc7 also not resolved bug
Alexey what do you mean ? The bug is still present on 2.6.34-rc7 ? and reverting f3eee54276dfd1117fd94259f2b4a38388264724 doesn't solve the issue ?
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)
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
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?
Already merged into 2.6.35.
Thank you. It´s indeed fixed in latest git. No need to leave the bug open, I think.