The fix for bug 613509
actually meant we avoiding VT switching on kms drivers, however due to the fact that this has been broken for at least 2 fedora releases means that particular code path was never actually tested in the field.
I noticed a regression during testing on a HP laptop on resume I wouldn't always get the X server back, sometimes it should end up pointing the hardware that the console.
This is due to the fact on resume, the kernel resumes into X, but pm-utils then echos to a file in /sys/class/graphics/fb0 to set the unsuspended state, however touching this file causes the fbcon to set a mode and crap all over the X mode.
I think at this point in EL6 we should just remove the quirk addition and try and fix this upstream first.
for pm, this is a definite blocker.
Please could you be more specific where is the regression related to fix for bug 613509? The implementation of 613509 differs from the rawhide version but the behaviour should be the same as in rawhide.
Please what is the point of this bug report? Removing/changing fix for bug 613509? Removing --quirk-no-chvt from KMS? Or something different? I think that for RHEL-6.0 is a bit late for complex changes/fixing things upstream.
I'll restate, before you fixed the problem, the chvt avoidance code never happened because it was broken, this means the code was never tested in production. That codepath seems to be broken in the kernel, as it was never tested as it was never enabled.
So we should explicitly disable the --quirk-no-chvt for RHEL6.0 on purpose instead of by typo. In rawhide I'd leave it alone and we can try and fix the kernel to do not be broken, if this fix went into a stable fedora release it should also be backed out. Maybe for 6.1 we can backport the kernel fix and re-enable this feature.
So yes for EL6.0 remove the --quirk-no-chvt is my suggestion.
actually it looks like the bugfix to #590541 that fixed the call to chvt.
Not sure why we haven't noticed this before, but lets just be safe for EL6.0 and remove the VT switch and file a bug for 6.1 to investigate further.
Thanks for info. I checked with my Intel GPU (KMS forced on):
# cat /sys/module/i915/parameters/modeset
For my HW the video resumes correctly with --quirk-no-chvt. But without --quirk-no-chvt it sometimes doesn't resume and I have to manually chvt. Thus I got the opposite of your observation (but I had to force KMS on, thus it may not worked correctly).
Please note that upstream of pm-utils have --quirk-no-chvt for KMS. And I worry that after dropping it, I will start receiving bugs on non working video resume (there were some during the period of broken chvt-avoidance-code in Fedora).
It seems there exist video HW needing --quirk-no-chvt and also video HW needing no --quirk-no-chvt. I think that correctly working KMS shouldn't break by manual call of chvt and also correctly working KMS shouldn't need chvt. But maybe I am not right. Now I don't know which one causes less problems. Please could anybody clarify this?
Okay I've spent some time after I cleared off my other problems and I tracked down the actual cause of the issue.
On my laptop where I noticed the issue, I get an oops on resume, and this causes a write to the fb0 state file to call into a codepath that isn't called into normally. If no oops happens things operate as normal. I'm not sure we really need pm-utils writing into the fb0 files on KMS but we should fix that upstream.
I'll close this bug an open a new 6.1 bug against the kernel for me to investigate later.