| Summary: | some 2.6.26 kernels don't have the built-in intel quirks | ||
|---|---|---|---|
| Product: | pm-utils | Reporter: | Jon Dowland <jon+bugs.freedesktop.org> |
| Component: | General | Assignee: | Victor Lowther <victor.lowther> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Handle ACPI S3 quirks even if --quirk-none is present | ||
|
Description
Jon Dowland
2008-06-21 09:10:03 UTC
update os/hw in bug notes Created attachment 17299 [details] [review] Handle ACPI S3 quirks even if --quirk-none is present Can you try this patch to see if it resolves your issue? Victor, if we are doing kernel modesetting, we don't have to apply any quirks. Can someone point me at the files/branches/commit logs for the kernel where the quirk stuff was folded in? I've spent some time digging and can't figure it out. I'll try that patch tonight. (In reply to comment #2) > Created an attachment (id=17299) [details] > Handle ACPI S3 quirks even if --quirk-none is present > > Can you try this patch to see if it resolves your issue? It does indeed. Based on the test [ -d /sys/module/i915 ], should I be looking at the linux/drivers/char/drm/i915* files to find the quirks stuff? (In reply to comment #3) > Victor, if we are doing kernel modesetting, we don't have to apply any quirks. > Apparently we do, at least in part. :( I do not have a box with Intel graphics to test -- have all the Intel kernel modesetting patches gone in to the mainline kernel? If so, then we have a some bugs to file against them... (In reply to comment #5) > (In reply to comment #2) > > Created an attachment (id=17299) [details] [details] > > Handle ACPI S3 quirks even if --quirk-none is present > > > > Can you try this patch to see if it resolves your issue? > > It does indeed. That is both good and bad news -- the workaround is really easy, but as Richard pointed out, we should not need these quirks with kernel modesetting. > Based on the test [ -d /sys/module/i915 ], should I be looking at the > linux/drivers/char/drm/i915* files to find the quirks stuff? I honestly have no idea -- someone more familiar with the kernel modesetting patches would be better qualified to answer. HI folks, apparently the suspend-quirks stuff is in arlied's drm tree. A friendly kernel hacker on IRC said "Looks like the 855 code hasn't made it. Sigh.", referring to mainline. I'm not sure if that means none of the quirk stuff is in mainline, or if just the S3-specific stuff isn't in mainline. I'm looking at the git log for ./drivers/char/drm in the drm tree to see if I can relate commits there to the quirks but nothing is jumping out at my untrained eyes so far. Apparently this works on Jesse's 855 machine. I've just confirmed the bug on my hardware with 2.6.26-rc8. (In reply to comment #9) > Apparently this works on Jesse's 855 machine. I've just confirmed the bug on my > hardware with 2.6.26-rc8. > Sorry, that is a little unclear -- did you mean: "Jesse's 855 machine has the same set of quirks mine does, but it suspends/resumes normally without the patch in this bug", or "Jesse's machine has the same set of quirks mine does and also requires this patch", or "Jesse's machine has the same video hardware mine does, but has a different set of quirks, and kernel modesetting works as advertised"? I'm sorry, yes, that was unclear. To clarify, Jesse has the same video hardware, I do not know the precise quirks that are required for it, but kernel modesetting is working fine for him, apparently. (I think he wrote a lot of it). I've reported the kernel issue upstream at http://bugzilla.kernel.org/show_bug.cgi?id=10985 . Hello. I've tracked this down to a problem with s2ram, rather than pm-utils. It turns out that a Debian-specific patch to the pm-utils stuff causes it to use s2ram if it is found in /usr/sbin, rather than defaulting to kernel mode. I'm sorry for the runaround. With 2.6.26 on my hardware, "s2ram --force" invoked either by-hand or via pm-suspend will fail to start the backlight on resume. So, you might still think it's a good idea to not disable the acpi mode quirks if s2ram is the backend. (In reply to comment #12) > Hello. I've tracked this down to a problem with s2ram, rather than pm-utils. It > turns out that a Debian-specific patch to the pm-utils stuff causes it to use > s2ram if it is found in /usr/sbin, rather than defaulting to kernel mode. > > I'm sorry for the runaround. > > With 2.6.26 on my hardware, "s2ram --force" invoked either by-hand or via > pm-suspend will fail to start the backlight on resume. So, you might still > think it's a good idea to not disable the acpi mode quirks if s2ram is the > backend. > Just to verify: If you force Debian to use kernel suspend/resume (by moving s2ram or whatever), you do not need the patch contained in this bug report? (In reply to comment #13) > Just to verify: > > If you force Debian to use kernel suspend/resume (by moving s2ram or whatever), > you do not need the patch contained in this bug report? That is correct. (In reply to comment #14) > (In reply to comment #13) > > Just to verify: > > > > If you force Debian to use kernel suspend/resume (by moving s2ram or whatever), > > you do not need the patch contained in this bug report? > > That is correct. > Excellent, I will close this bug, then. Hello. I'm afraid some of my earlier test results are flawed because various acpi bits had been prodded between tests and I hadn't performed each test from a cold boot. I've just discovered that from a cold boot, echo mem > /sys/power/state does not relight my backlight. I've therefore re-opened the upstream bug. I do not know if you want to change this ones status, in light of the fact that at present it would seem not all 2.6.26 kernel/machine combos are quirk-free. However I've yet to hear of anyone else running into this problem. Hi folks, 2.6.26 is now out and it does not include a fix for the backlight issue with the 855GM chipset in the thinkpad X40 (see http://bugzilla.kernel.org/show_bug.cgi?id=10985). Therefore the assumption in 98smart-kernel-video that no quirks are needed on 2.6.26 is incorrect. To summarize the situation: issuing 'echo mem > /sys/power/state' invokes a suspend but on resume, the backlight on my thinkpad x40 does not come on. The quirks that sort this out normally are exposed by HAL. They correspond to pm-suspend arguments --quirk-s3-mode and --quirk-s3-bios. 98smart-kernel-video purposefully ignores these arguments if the running kernel is 2.6.26, but 2.6.26 does not fix this bug for this hardware. I have been thinking: is pm-utils the right place to do this kind-of quirk management anyway? Would it not make more sense to have HAL take the kernel version into account and not expose quirks that are not needed (in userspace)? (In reply to comment #17) > Hi folks, 2.6.26 is now out and it does not include a fix for the backlight > issue with the 855GM chipset in the thinkpad X40 (see > http://bugzilla.kernel.org/show_bug.cgi?id=10985). > > Therefore the assumption in 98smart-kernel-video that no quirks are needed on > 2.6.26 is incorrect. Well, crap. > To summarize the situation: issuing 'echo mem > /sys/power/state' invokes a > suspend but on resume, the backlight on my thinkpad x40 does not come on. The > quirks that sort this out normally are exposed by HAL. They correspond to > pm-suspend arguments --quirk-s3-mode and --quirk-s3-bios. 98smart-kernel-video > purposefully ignores these arguments if the running kernel is 2.6.26, but > 2.6.26 does not fix this bug for this hardware. In theory, the kernel drivers should handle it. > I have been thinking: is pm-utils the right place to do this kind-of quirk > management anyway? Would it not make more sense to have HAL take the kernel > version into account and not expose quirks that are not needed (in userspace)? It would be better to have this quirk management in the kernel modesetting drivers as advertised, and then in HAL, and then here. The reason the kernel modesetting quirks are currently here is that (right now) it is easier to support them here than in HAL, for reasons to ugly to get in to right now. This bug will be resolved (mostly) by the same update that fixes bug# 16175, so marking this bug as a duplicate of that one. *** This bug has been marked as a duplicate of bug 16175 *** |
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.