radeon_hd can't wake screen after DPMS off (regression)

[vidrep]

hrev48068 Select "blackness" screensaver in preferences After screensaver activates there is no way to recover the desktop with mouse movement or keystrokes.

[anevilyak]

Could you please at least try to set a component when you file tickets? It's been asked more than once.

[pulkomandy]

I don't think blackness is the problem here. Have you tried this with other screensavers? Have you tried unchecking the "turn off screen" checkbox?

I have noticed that when there is a system panic or app_server crash we don't wake up the display from powersaving mode. Can you reach the machine by ssh and get a syslog, ps output, or other useful information after it is crashed?

Also, what is your video card and driver?

[vidrep]

My hard drive on this PC has three partitions - alpha 4.1, dev, and x86_64. I have tested the blackness screensaver on alpha 4.1, and it is working normally. Only the hybrid and 64 bit nightly does not work. They are all using the same hardware. So, naturally I assume if something works on alpha 4.1, but does not work on the nightly build, it must be broken due to some change in the software since then. This Haiku PC is also connected to a Windows PC with a serial cable for capturing debugging output. I do not use any emulator - always real hardware. I have attached a listdev. If there is some tests you can suggest, let me know, and I'll do my best to give you the information you need to resolve the problem

[pulkomandy]

Yes, obviously something got broken here. I'm trying to understand which part of the system, as one of several things can have happened:

• The video driver has crashed, or
• There is a bug in DPMS/powersave handling in the video driver and that prevents wakeup, or
• app server crashed, or
• there was a kernel panic for an unrelated reason, or
• the screen_blanker crashed, but the screen was turned off

... and so on.

So here are the things to try:

• Run the screensaver in test mode from the screen preflet. Does it crash? (if it does, this rules out screen_blanker, as in this case the ScreenSaver preflet handles things directly)
• Uncheck "turn off screen" checkbox. Wait for screensaver. Does it crash? (if it does, it is not an issue with powersaving)
• Wait for the crash with serial port connected and the windows machine capturing from it. Is there some output? (if there is, it would be a kernel crash)
• Configure your machine for ssh use useradd sshd ; passwd. Connect to it from another machine on your network (you can use Putty as an ssh client for windows, or ssh from linux or Haiku). Wait for the crash. Is the ssh session also blocked, or does it still work? If it still work, can we get the output of:

  ps
  cat /var/log/syslog
  

At least one of these tests should point to what/where the crash actually is.

[vidrep]

Replying to pulkomandy:

• Run the screensaver in test mode from the screen preflet. Does it crash? YES
• Uncheck "turn off screen" checkbox. Wait for screensaver. Does it crash? YES
• Wait for the crash with serial port connected and the windows machine capturing from it. Is there some output? YES (serial debug log attached)

This was tested with hrev48073 x86_gcc2 "Turn Off Screen" checkbox was unchecked during serial debug logging Serial debug logging was started at boot and stopped after shutdown Previous syslogs were deleted before testing. I'll attach syslog from test session.

[vidrep]

Did some experimenting with different hardware and found that this is a problem exclusive to Radeon video. This was reproducable on two different PC's. First PC is Intel core 2 with on-board Intel graphics, which works. Installed Radeon card - not working. Second PC is AMD Athlon X2. Nvidia video works. Install Radeon card - not working. I'll try some different Radeon cards to see if any other types exhibit the same problem.

[vidrep]

Here is what I found. RV610 HD 2400 card works in both PC's. RV620 LE HD3450 does not work in either PC. RV620 HD3470 does not work in either PC. So, it appears this issue is exclusive to RV620 Radeon (and later?) video cards.

[vidrep]

Are there any users with Radeon RV620 and later video cards who can test whether the newer cards are affected by this bug as well? This bug is present in both 32 and 64 bit builds. Thanks.

[vidrep]

Tried today with a newer Radeon HD 6450/7450/8450 / R5 230 OEM video card. It is working. So, this problem may be limited to a small segmant of Radeon cards (Radeon HD3000 series).

[vidrep]

Since kallisti5 is testing newer Radeons this week, how about fixing this bug on an older card...please:)

[vidrep]

This is another regression in Haiku. The same video card, on the same PC, is working with Alpha 4.1.

[diver]

Maybe you can try to bisect the driver? Or binary search when it has been broken.

[vidrep]

I'll give it a try tonight after work. There appears to be a good selection of older images still available for testing.

[vidrep]

After 5 hours and at least 20 installs to a spare hard drive partition I have narrowed down the range to between hrev45218 (working) and hrev45326 (not working). The Radeon driver was broken with hrev45219 and then reverted in hrev45325. It appears something was missed during the revert.

[vidrep]

Let me know if any further information is required to close this ticket.

[vidrep]

Please, can somebody have another look at this ticket? I have had my screensaver disabled for a year waiting for the fix. Please read comment 16 for the commit which broke the driver. Thanks in advance.

[vidrep]

Can somebody change the title of the ticket to "radeon_hd can't wake screen after DPMS off (regression)?

[kallisti5]

hm... Looking over the syslogs... the modesetting DPMS powerdown / powerup performs a lock before powerdown and an unlock after powerup.

KERN: radeon_hd: encoder_output_lock: true
KERN: radeon_hd: display_crtc_lock
KERN: radeon_hd: encoder_dpms_set: power: false
KERN: radeon_hd: encoder_dpms_set_dig: power: false

KERN: radeon_hd: encoder_dpms_set: power: true
KERN: radeon_hd: encoder_dpms_set_dig: power: true
KERN: radeon_hd: transmitter_dig_setup
KERN: radeon_hd: transmitter_dig_setup: table 1.1
KERN: radeon_hd: encoder_pick_dig
KERN: radeon_hd: display_crtc_lock
KERN: radeon_hd: encoder_output_lock: false

However the DPMS call at the end of the syslog doesn't seem to do this lock / unlock. Not 100% sure, however that looks.. "off"

[kallisti5]

A random guess at a fix

[kallisti5]

I've attached a drive-by fix. No idea if it will work... please test and share results ;-)

[vidrep]

Thanks for having a look. I'll try it out as soon as I get home from work tonight. In the event it still doesn't work, is there some test I can do to get better information?

[kallisti5]

Just the syslogs, those give us the most information.

Thanks for testing this patch! This is the kind of off-loading of testing that really helps us churn fixes out faster.

[vidrep]

Quick question: What is the best way to test this patch? Do I have to build the radeon driver from source?

[kallisti5]

Yup. You'll need to compile from source after patching the sources.

​https://www.haiku-os.org/guides/building

To patch haiku sources:

patch -p1 < dpms_encoder_lock.diff

[vidrep]

I patched the driver and built the bin. Now, where to put it? I tried /boot/home/config/non-packaged/add-ons/kernel/drivers/bin, but the driver is not being used, even though I blacklisted the radeon_hd driver.

[waddlesplash]

Wherever the radeon_hd driver is + "non-packaged/" right after "system/". "home/config" won't work (pretty sure this is by design, for security reasons.)

[anevilyak]

The patch in question is against the accelerant, not the driver. You'll want to build radeon_hd.accelerant and replace that.

[vidrep]

Built the radeon_hd.accelerant against the patch. Put it into /boot/system/non-packaged/add-ons/accelerants/. Listimage says it is now being used. However, it does not fix the problem, sorry to say.

[vidrep]

I know this is a hack, but I thought I'd try it anyway. I copied the radeon_hd.accelerant from Alpha 4.1 to /boot/system/non-packaged/add-ons/accelerants/ and now everything works.

[kallisti5]

so.... did you grab the syslogs from the failed patch?

[vidrep]

Sorry, I'll post them tonight after work.

[vidrep]

Attached are the syslog(s) and a listimage.

[vidrep]

Have you had a chance to look at the attached syslogs yet?

[vidrep]

Looking at this ticket again today with hrev50544 x86_gcc2. Radeon HD3450 - I tried each available video output interface (DVI, S-VID, VGA) Screensaver Preferences set to the following: Start Screensaver 30 seconds; Turn Off Screen 1 minute VGA - screen turns back on with mouse movement or keyboard input DVI - screen does NOT turn back on with mouse movement or keyboard input after screen is turned off S-VID - not supported on this graphics card Do you want syslogs for each scenario?

[vidrep]

I also tested a Radeon HD3470 as well. It only has DVI and DP (no VGA). The behavior is the same as the HD3450 when connecting the monitor through DVI

[pulkomandy]

You can use the "dpms" command to test this more easily. "dpms off" puts the screen to sleep. "dpms on" wakes it up.

Usually I do something like this from Terminal:

dpms off ; sleep 2 ; dpms on

You can also check the "suspend" and "standby" states if available (but don't forget the "dpms on" or you'll have to type it while the screen is black!)

[vidrep]

Tested Radeon HD3450 and HD3470 today with Haiku hrev50575 x86_gcc2. I am very happy to report that this issue is now resolved.

[pulkomandy]

thanks for reporting!