Intermittant bug in 14.0-RELEASE DRI/crocus driver?

For completeness I gave glexcess a spin, fullscreen. Seems to be working fine. CPU hovers around 10-20% utilisation, temp around 52 C. Can't expect much :)
 
An update from the linked bugzilla, a reliable source has confirmed that this bug does NOT occur in the Wayland case, they say it's only a problem when X11 is used as the gui. Interesting bug. So according to that, using a wayland gui should fix the problem. Heh.

Meanwhile I've been testing the fix for the suspend-review case suggested by smithi all afternoon and can confirm that it does appear to fix the problem of suspend-resume knocking out hw accel when X11 is used. So the only remaining problem is doing a manual switch to a different VT and then back to X still knocks out gpu hardware acceleration, at least that's what I'm seeing here.

Just to recap, the fix for the suspend-resume case with an X11 desktop is to set
sysctl kern.vt.suspendswitch=0
Just don't do any VT switches and gpu hardware acceleration will stay up.

It's better than nowt.
 
blackbird9 said:
sysctl kern.vt_suspendswitch=0
Click to expand...

blackbird9 said:
sysctl kern.vt_suspendswitch=0
Click to expand...

blackbird9 said:
sysctl kern.vt_suspendswitch=0
Click to expand...

Code: 
% sysctl kern.vt_suspendswitch
sysctl: unknown oid 'kern.vt_suspendswitch'
% sysctl kern.vt.suspendswitch
kern.vt.suspendswitch: 1
% uname -KU
1500008 1500008
%

2014-03-18, svn revision 263321:

github.com

Switch kern.vt.suspendswitch to 0 by default (disabled). · freebsd/freebsd-src@b3ea9d9

kern.vt.suspendswitch - sysctl/tunable which enable switch to VT0 before going to suspend and switch back after resume. MFC after: 7 days
github.com github.com
 
Graham,

Bah... looks like I made a typo, apologies; kern.vt.suspendswitch is the correct name.
I've gone back and corrected the errors.

I removed the setting from /etc/sysctl.conf, rebooted and read the value for a sanity check:-

$ sysctl kern.vt.suspendswitch
kern.vt.suspendswitch: 1

$ uname -KU
1400097 1400097

That is the level I ended up with after upgrading from 13.2-RELEASE to 14.0-RELEASE.

So did that patch from 2014 get backed out at some point? It's not defaulting to 0 here or in your system.

Can you please do the following test on your 15.x box, for interest?

$ xdriinfo
Screen 0: crocus
# confirm this output, indicating accelerated DRI driver loaded; I assume intel platform

# ctrl-alt-F4, then ctrl-alt-F9
then if you repeat xdriinfo, what is the output?
 
Ah, I wondered if it might be a security problem. I've been using xsecurelock/xss-lock on linux.. works quite well (wmaker). On fbsd I use xidle and slock, doesn't work too badly but not really secure. Of course with the suspendswitch sysctl turned off, when the lid is open the last screen is momentarily visible before the screenlock overwrites the video buffer. Trade-off for having accelerated video.
 
You must log in or register to reply here.
Back
Top