Summary: | [KMS] sysrq-g doesn't bring back console | ||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Shuang He <shuang.he> | ||||||||||||||||||||
Component: | DRM/Intel | Assignee: | Jesse Barnes <jbarnes> | ||||||||||||||||||||
Status: | CLOSED FIXED | QA Contact: | |||||||||||||||||||||
Severity: | normal | ||||||||||||||||||||||
Priority: | medium | ||||||||||||||||||||||
Version: | XOrg git | ||||||||||||||||||||||
Hardware: | Other | ||||||||||||||||||||||
OS: | Linux (All) | ||||||||||||||||||||||
Whiteboard: | |||||||||||||||||||||||
i915 platform: | i915 features: | ||||||||||||||||||||||
Attachments: |
|
Description
Shuang He
2009-03-03 21:41:58 UTC
Created attachment 23500 [details]
xorg log
Created attachment 23501 [details]
xorg.conf
Created attachment 23502 [details]
dmesg for Q35
This issue also happens on Q35, 945GM. But on both Q35, the sysrq-g won't take effect, only "SysRq : force restore of fb console, but we're not switch back to console." in dmesg on Q45, sysrq-g won't have effect, and there's some backtrace in dmesg, pls check dmesg for Q45 on 945GM, sysrq-g will turn screen into black, only the mouse cursor can't be seen (you can still move it around, and it change its shape when it's in xterm window), and there's some backtrace in dmesg, pls check dmesg for 945GM Created attachment 23504 [details]
dmesg for 945GM
Created attachment 23505 [details]
dmesg for Q45
Hm, works on my GM45, and in your G45 log it appears the sysrq function is getting called correctly at least. The other logs show a might sleep warning, which I need to fix... Can you capture logs with the drm debug flag set? Just modprobe drm with debug=1 on the command line and KMS should be a lot more verbose. Oh this could also be related to bad output detection; maybe the console is getting restored on a non-existent output that's falsely detected as present. (In reply to comment #7) > Hm, works on my GM45, and in your G45 log it appears the sysrq function is > getting called correctly at least. The other logs show a might sleep warning, > which I need to fix... Can you capture logs with the drm debug flag set? Just > modprobe drm with debug=1 on the command line and KMS should be a lot more > verbose. > I tried it on our GM45, it's also not working. Created attachment 23820 [details]
dmesg after sysrq-g
Created attachment 23821 [details]
dmesg before sysrq-g
Ok, I'm not sure what's going on then. Maybe you don't have sysrq enabled? /proc/sys/kernel/sysrq should be set to 1... (In reply to comment #12) > Ok, I'm not sure what's going on then. Maybe you don't have sysrq enabled? > /proc/sys/kernel/sysrq should be set to 1... > I tried it on GM45 echo 1 > /proc/sys/kernel/sysrq then echo g > /proc/sysrq-trigger It has same symptom with 945GM, only a blinking cursor on the top-left. Ok so maybe there's nothing on the fbcon that gets restored... If you set a verbose log level before loading drm (with debug=1) and i915 you should see lots of kernel messages, and sysrq-g should show them, but it may be that your console is getting cleared for some reason, so I'll have to figure out how to make fbcon repaint everything. Jesse, could you upload a photo about how it would look like? Looks like http://bugzilla.kernel.org/show_bug.cgi?id=13130 may be the real problem here. For some reason I wasn't seeing that backtrace in my testing though; will fix. Please confirm that this is fixed. The kernel bits landed awhile back. I have tried latest codes on drm-intel-next on my Q35, it will stay at X, won't restore to framebuffer console, and dmesg show: [ 144.073754] [drm] TMDS-8: set mode 1280x1024 16 [ 220.773654] SysRq : Restore framebuffer console I'm using following sequence of commands: echo 1 > /proc/sys/kernel/sysrq echo v > /proc/sysrq-trigger Is there any other dependency that I'm missing? I'd have to reopen this bug first. The intelfb restore function may fail, are you getting an error from the mode set call in that function? (In reply to comment #19) > The intelfb restore function may fail, are you getting an error from the mode > set call in that function? I've checked a bit on my Q35. <Shuang: start system> [ 0.310768] [drm] Initialized drm 1.1.0 20060810 [ 0.892585] [drm:drm_crtc_helper_set_config] [ 0.892588] [drm:drm_crtc_helper_set_config] crtc: f6859800 3 fb: f6899c00 connectors: f6859c48 num_connectors: 1 (x, y) (0, 0) [ 0.892590] [drm:drm_crtc_helper_set_config] crtc has no fb, full mode set [ 0.892592] [drm:drm_crtc_helper_set_config] modes are different, full mode set [ 0.892594] [drm:drm_crtc_helper_set_config] setting connector 7 crtc to f6859800 [ 0.892595] [drm:drm_crtc_helper_set_config] attempting to set mode from userspace [ 0.965869] [drm] TMDS-8: set mode 1680x1050 13 [ 1.196013] [drm:drm_crtc_helper_set_config] [ 1.196015] [drm:drm_crtc_helper_set_config] crtc: f6859800 3 fb: f6899c00 connectors: f6859c48 num_connectors: 1 (x, y) (0, 0) [ 1.196018] [drm:drm_crtc_helper_set_config] setting connector 7 crtc to f6859800 [ 1.202842] fb0: inteldrmfb frame buffer device [ 1.202853] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 18.994393] [drm:drm_crtc_helper_set_config] [ 18.994398] [drm:drm_crtc_helper_set_config] crtc: f6859800 3 fb: f6899c00 connectors: f6859c48 num_connectors: 1 (x, y) (0, 0) [ 18.994402] [drm:drm_crtc_helper_set_config] setting connector 7 crtc to f6859800 <Shuang: start X> [ 211.491521] [drm:drm_crtc_helper_set_config] [ 211.491525] [drm:drm_crtc_helper_set_config] crtc: f6859800 3 fb: f6899c00 connectors: f6859c48 num_connectors: 1 (x, y) (0, 0) [ 211.491530] [drm:drm_crtc_helper_set_config] setting connector 7 crtc to f6859800 [ 211.668225] [drm:drm_crtc_helper_set_config] [ 211.668229] [drm:drm_crtc_helper_set_config] crtc: f685a800 4 fb: f6899c00 connectors: f685ac48 num_connectors: 0 (x, y) (0, 0) [ 211.668233] [drm:drm_crtc_helper_set_config] crtc has no fb, full mode set [ 211.668236] [drm:drm_crtc_helper_set_config] setting connector 7 crtc to f6859800 [ 212.258082] [drm:drm_crtc_helper_set_config] [ 212.258087] [drm:drm_crtc_helper_set_config] crtc: f6859800 3 fb: f66a6600 connectors: f680da90 num_connectors: 1 (x, y) (0, 0) [ 212.258091] [drm:drm_crtc_helper_set_config] setting connector 7 crtc to f6859800 <Shuang: sysrq-g> [ 412.380328] [drm:drm_crtc_helper_set_config] [ 412.380332] [drm:drm_crtc_helper_set_config] crtc: f685a800 4 fb: f6899c00 connectors: f685ac48 num_connectors: 0 (x, y) (0, 0) [ 412.380336] [drm:drm_crtc_helper_set_config] crtc has no fb, full mode set [ 412.380339] [drm:drm_crtc_helper_set_config] setting connector 7 crtc to f6859800 <Shuang: didn't restore to fb, still with X, now do vt switch> [ 490.920288] [drm:drm_crtc_helper_set_config] [ 490.920292] [drm:drm_crtc_helper_set_config] crtc: f6859800 3 fb: f6899c00 connectors: f6859c48 num_connectors: 1 (x, y) (0, 0) [ 490.920297] [drm:drm_crtc_helper_set_config] setting connector 7 crtc to f6859800 On Wed, 24 Jun 2009 01:46:40 -0700 (PDT) bugzilla-daemon@freedesktop.org wrote: > http://bugs.freedesktop.org/show_bug.cgi?id=20451 > > > > > > --- Comment #20 from Shuang He <shuang.he@intel.com> 2009-06-24 > 01:46:40 PST --- (In reply to comment #19) > > The intelfb restore function may fail, are you getting an error > > from the mode set call in that function? > > I've checked a bit on my Q35. > > <Shuang: sysrq-g> > [ 412.380328] [drm:drm_crtc_helper_set_config] > [ 412.380332] [drm:drm_crtc_helper_set_config] crtc: f685a800 4 fb: > f6899c00 connectors: f685ac48 num_connectors: 0 (x, y) (0, 0) > [ 412.380336] [drm:drm_crtc_helper_set_config] crtc has no fb, full > mode set [ 412.380339] [drm:drm_crtc_helper_set_config] setting > connector 7 crtc to f6859800 Ah interesting, so we have a 0 in num_connectors... that seems wrong. > > <Shuang: didn't restore to fb, still with X, now do vt switch> > > [ 490.920288] [drm:drm_crtc_helper_set_config] > [ 490.920292] [drm:drm_crtc_helper_set_config] crtc: f6859800 3 fb: > f6899c00 connectors: f6859c48 num_connectors: 1 (x, y) (0, 0) > [ 490.920297] [drm:drm_crtc_helper_set_config] setting connector 7 > crtc to f6859800 And then this works ok; the other values are the same but we actually have num_connectors set... Created attachment 28901 [details] [review] Set kernelfb_mode correctly Jason Wessel and I found this looking at the KDB code... I think it will fix this issue. Created attachment 28906 [details] [review] Handle all CRTCs when restoring the console This one should handle all CRTCs correctly, rather than just restoring the last one. (In reply to comment #23) > Created an attachment (id=28906) [details] > Handle all CRTCs when restoring the console > > This one should handle all CRTCs correctly, rather than just restoring the last > one. > This one is working for me. Fix has been pushed upstream, I think it was included in: commit 785b93ef8c309730c2de84ce9c229e40e2d01480 Author: Dave Airlie <airlied@redhat.com> Date: Fri Aug 28 15:46:53 2009 +1000 drm/kms: move driver specific fb common code to helper functions (v2) Thanks, verified on Q35 with: Kernel (drm-intel-next)8d91104aac6e21e6ca2a56124e2e47b0db043ea8 Closing old verified. |
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.