Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On Fri, 30 Aug 2013 11:53:22 -0400, John Baldwin wrote I just removed VESA from my kernel on an X220 and it now suspends and resumes great in X. I don't notice any slowdown, but I'm using a very simple tiling window manager (i3wm). Great, I can confirm that suspend/resume also works on my X220 with this trick ! I had once opened a PR for that problem and I had managed to track the change that, at that time, broke suspend/resume : http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/174504 I don't know how it relates to VESA (the change does not seem to be related to VESA), but it might help ? Best regards, -- Ganael LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymac marty...@freebsd.org, http://www.FreeBSD.org ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
Ganael LAPLANCHE ganael.laplan...@martymac.org writes: On Fri, 30 Aug 2013 11:53:22 -0400, John Baldwin wrote I just removed VESA from my kernel on an X220 and it now suspends and resumes great in X. I don't notice any slowdown, but I'm using a very simple tiling window manager (i3wm). Great, I can confirm that suspend/resume also works on my X220 with this trick ! I had once opened a PR for that problem and I had managed to track the change that, at that time, broke suspend/resume : http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/174504 I don't know how it relates to VESA (the change does not seem to be related to VESA), but it might help ? I believe this (the PR) is a completely different issue, since you write resume make the computer hang. The nooptions VESA fixed wedging of Intel/KMS graphics _after_ resume. There have been many other changes since r231797 (15 feb 2012). But nice that it works for you too! Bengt ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-05 16:04:56 -0400, Bengt Ahlgren wrote: Jung-uk Kim j...@freebsd.org writes: On 2013-09-04 18:47:47 -0400, Jung-uk Kim wrote: On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote: The value of hw.acpi.video.lcd0.brightness changes when the screen brightness keys (Fn+Home/End) are pressed, but nothing happens with the screen. Same goes for changing the value with sysctl. After a fresh boot it works with one issue. The screen brightness level seems to lag behind one keypress. Without acpi_video, screen brightness changes without the lag. hw.acpi.video.lcd0.active is always stuck at 0 - can't change with sysctl (regardless if the screen is on after a fresh boot, or black after a text console suspend/resume): [root@bit ~]# sysctl hw.acpi.video.lcd0.active=1 hw.acpi.video.lcd0.active: 0 - 0 Again, for my old X40 with non-KMS Xorg intel driver has (curiously, the screen blinks when issuing this sysctl command): [bengta@P142 ~]$ sysctl hw.acpi.video hw.acpi.video.lcd0.active: 1 hw.acpi.video.crt0.active: 0 Then, KMS probably breaks acpi_video(4), too. :-( kib let me know that there is a way to make it work but it was not well-integrated to i915kms.ko. If you are interested in fixing it, dev/drm2/i915/intel_opregion.c is the source and you can download the specification from here: https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf Hmm, scanning that spec, I wonder whether the opregion functionality is better placed together with acpi_video, and then i915kms makes calls to that instead? Traditionally, platform-specific code goes to dev/acpi_support. So, dev/acpi_support/acpi_intel.c may be created to cater its needs, if it is absolutely necessary. Hmm, again, perhaps the intel platform needs opregion support to work properly also without the kms driver. Could be anexplanation for the backlight issues. Yes and yes, I think. However, many developers are tired of dealing with syscons ugliness and now the Foundation is sponsoring ray@ to replace syscons with newcons+KMS if my understanding is correct. I am not sure how it will be layered at the end, though. (Just speculation so far... I have no idea if/how this relates to or interacts with options VESA) Apparently, they interact badly. :-( Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSKOpXAAoJECXpabHZMqHOSnIIANS/Kt043RI7fFLNYVeWvpH0 zQ8C3wTi66aIW9B5bvYcXcJXcE1yazfegbtAHT6i0Hf4/BrvoMkN3umHIRYMbMv9 ei7WoFDLRIuyGzqgMy7CP3t9byYZolRBuyIt+zELsNU/5zCkgSP3di40TK+oLJ+3 NXhALsLZA37B1S3TYaiLy+U4BylfC3iNhFDlDRrikuYvAym/s5o/Ro0Ea8dyUw4i CtWDEomCIwjzOuythAl1wlXYeMtZZp+6Fj2Pemhh9COzFXgHiTfhfVySRVt0tBAs 6FKmQnc30ra2clU1o5JJuzwlOsgGH+aztvrdjc4VGr/wGpdmKW6FrNlpcku1VkQ= =i0JD -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
Jung-uk Kim j...@freebsd.org writes: On 2013-09-04 18:47:47 -0400, Jung-uk Kim wrote: On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote: The value of hw.acpi.video.lcd0.brightness changes when the screen brightness keys (Fn+Home/End) are pressed, but nothing happens with the screen. Same goes for changing the value with sysctl. After a fresh boot it works with one issue. The screen brightness level seems to lag behind one keypress. Without acpi_video, screen brightness changes without the lag. hw.acpi.video.lcd0.active is always stuck at 0 - can't change with sysctl (regardless if the screen is on after a fresh boot, or black after a text console suspend/resume): [root@bit ~]# sysctl hw.acpi.video.lcd0.active=1 hw.acpi.video.lcd0.active: 0 - 0 Again, for my old X40 with non-KMS Xorg intel driver has (curiously, the screen blinks when issuing this sysctl command): [bengta@P142 ~]$ sysctl hw.acpi.video hw.acpi.video.lcd0.active: 1 hw.acpi.video.crt0.active: 0 Then, KMS probably breaks acpi_video(4), too. :-( kib let me know that there is a way to make it work but it was not well-integrated to i915kms.ko. If you are interested in fixing it, dev/drm2/i915/intel_opregion.c is the source and you can download the specification from here: https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf Hmm, scanning that spec, I wonder whether the opregion functionality is better placed together with acpi_video, and then i915kms makes calls to that instead? Hmm, again, perhaps the intel platform needs opregion support to work properly also without the kms driver. Could be an explanation for the backlight issues. (Just speculation so far... I have no idea if/how this relates to or interacts with options VESA) Bengt ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-05 04:24:58 -0400, Bengt Ahlgren wrote: Ganael LAPLANCHE ganael.laplan...@martymac.org writes: On Fri, 30 Aug 2013 11:53:22 -0400, John Baldwin wrote I just removed VESA from my kernel on an X220 and it now suspends and resumes great in X. I don't notice any slowdown, but I'm using a very simple tiling window manager (i3wm). Great, I can confirm that suspend/resume also works on my X220 with this trick ! I had once opened a PR for that problem and I had managed to track the change that, at that time, broke suspend/resume : http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/174504 I don't know how it relates to VESA (the change does not seem to be related to VESA), but it might help ? I believe this (the PR) is a completely different issue, since you write resume make the computer hang. The nooptions VESA fixed wedging of Intel/KMS graphics _after_ resume. There have been many other changes since r231797 (15 feb 2012). Correct. r231797 had an issue but it was quickly fixed, I think, and it was completely unrelated to VESA. But nice that it works for you too! Unfortunately, many people think that no video == hang because they cannot see anything on their screen/panel. Moreover, I realized that more users are now complaining about suspend/resume problems with DRM/KMS, which is not directly related to ACPI. - From lots of responses I gathered from users and developers yesterday, I can definitely say that i915kms.ko does not cooperatively work with syscons(4) and acpi_video(4). Basically, it was not a priority at the time of porting according to the author. I am quite sure radeonkms.ko has similar problems. FYI... Jung-uk Kim * PS: https://wiki.freebsd.org/SuspendResume needs more love, I guess. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSKMadAAoJECXpabHZMqHOvpMH/0RVq4KZCTDZqsxOibrIY9/9 INNEZXsVWP+Y8+BQacXP3x45eUOGVKa2IGiDo/O7Oediqh/DIhWa8pqonzJ474qY UadV+SQTjQE1EDUcjWmKnAY4OT0dHiN6eAIUv5o+dnFOxb6HupQ2hTGziReQoupS QE9YgwUVU5yOlGZXFbhq2RHvqT2Bi52dHC1qP2waVOlghNY7PIbYMTwQ4X6S4fGC Fjgjvx4tUU4EhjWuaK8mH0t/gCsUjpRico7YmYVVb2N5hu9SrojGPsIgGLaD1Aqi 4Nkmd59Asu+NBR0A22c7UAcoRpP2aJ65q/MU8CdRp/FOTE+W2LLlsXy2JIiKCBk= =Pf+z -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-04 09:29:35 -0400, John Baldwin wrote: On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote: On 2013-09-03 16:47:47 -0400, John Baldwin wrote: Even with that hacked so I force vgapm0 and dpms0 to attach, I still can't resume in console mode, ... What happens? Does it panic, hang, or just no backlight? Just no backlight. It resumes fine and if I do it in multiuser I can ssh in, etc. It's just the backlight that doesn't resume. I was hopeful dpms.ko would fix that, but it didn't. :( Ah, that's a well-known problem and we cannot fix it without help of machine-specific code, e.g., drm1/drm2. Actually, both acpi_video and dpms try to restore video settings but nothing worked for Intel GPUs + LVDS + LCD panel AFAIK. I think i915drm has code to specifically turn on the backlight as I get some weird error message in the kernel console about a timeout trying to turn the panel off during suspend when I'm in X. So, I guess it has an ordering issue. If my memory serves, drm1 was okay with vesa, however. I *think* it accidentally worked because of automatic VT-switching, which is still broken for KMS. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJ2VUAAoJECXpabHZMqHOJtgIAIagXbUGDBGR6cdu1EncP8bU eN+03coO4KBsCuFesNkOBF8GgCsoGf+n+IrUjGnazuyK9UTi5flLMieg3TpIkGrL YxOTTo6hfMswII8c5B67ZqPjvY/EmhgQdCQ34WsUGptDvUnqq23u3ounOiQY75iu FXJqQf5s1X6M5a5bzgvfWZd8yhJhUoYsrQftFOpiZBx1Xyb6hrfCRUJquQklx1Y8 zFDVYm6zr34Aan/lHOWTjAI2ZWBFeiu6BswWdFy2BCbKUUh5b9tToBikfsBRWmSn isgnm4y8NNDlz/wY42eoXvGFonJLH6+lR7sasxQayIZU7bkfrLlgs9SBex1vh4g= =dj+e -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
Jung-uk Kim j...@freebsd.org writes: On 2013-09-04 09:29:35 -0400, John Baldwin wrote: On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote: On 2013-09-03 16:47:47 -0400, John Baldwin wrote: Even with that hacked so I force vgapm0 and dpms0 to attach, I still can't resume in console mode, ... What happens? Does it panic, hang, or just no backlight? Just no backlight. It resumes fine and if I do it in multiuser I can ssh in, etc. It's just the backlight that doesn't resume. I was hopeful dpms.ko would fix that, but it didn't. :( Ah, that's a well-known problem and we cannot fix it without help of machine-specific code, e.g., drm1/drm2. Actually, both acpi_video and dpms try to restore video settings but nothing worked for Intel GPUs + LVDS + LCD panel AFAIK. I think i915drm has code to specifically turn on the backlight as I get some weird error message in the kernel console about a timeout trying to turn the panel off during suspend when I'm in X. So, I guess it has an ordering issue. If my memory serves, drm1 was okay with vesa, however. I *think* it accidentally worked because of automatic VT-switching, which is still broken for KMS. Yes, perhaps, but there is also the sysctl hw.acpi.reset_video which I have enabled on my older hardware (TP X40 running 8.3-REL and an old Xorg server) for it to work properly. (I however have some faint memory that reset_video might a no-op these days, or?) In this old mail regarding reset_video, there is a thought that it could be good with more reinitialisation: http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html I however have one datapoint that I think contradicts John's thought. This is on a X201 with stable/9 and no options VESA. I first just booted up and stayed in text console, suspended and resumed. No backlight, of course, and also no content on the LCD, it is completely black. Then, I started Xorg with KMS. Still no backlight, but you can see that the LCD is driven with the desired content, which is one step forward. Finally, I suspended and resumed, but no difference, the backlight is still off. Xorg/KMS didn't manage to turn the backlight on, so the text console suspend/resume cycle managed to persistently turn the backlight off. One more thing, the kernel logs this at resume directly after the devices are powered on (transition to D0), but I have no idea whether it is relevant: Sep 2 19:57:21 bit kernel: error: [drm:pid1904:intel_lvds_enable] *ERROR* timed out waiting for panel to power off Bengt ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-04 15:14:32 -0400, Bengt Ahlgren wrote: Jung-uk Kim j...@freebsd.org writes: On 2013-09-04 09:29:35 -0400, John Baldwin wrote: On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote: On 2013-09-03 16:47:47 -0400, John Baldwin wrote: Even with that hacked so I force vgapm0 and dpms0 to attach, I still can't resume in console mode, ... What happens? Does it panic, hang, or just no backlight? Just no backlight. It resumes fine and if I do it in multiuser I can ssh in, etc. It's just the backlight that doesn't resume. I was hopeful dpms.ko would fix that, but it didn't. :( Ah, that's a well-known problem and we cannot fix it without help of machine-specific code, e.g., drm1/drm2. Actually, both acpi_video and dpms try to restore video settings but nothing worked for Intel GPUs + LVDS + LCD panel AFAIK. I think i915drm has code to specifically turn on the backlight as I get some weird error message in the kernel console about a timeout trying to turn the panel off during suspend when I'm in X. So, I guess it has an ordering issue. If my memory serves, drm1 was okay with vesa, however. I *think* it accidentally worked because of automatic VT-switching, which is still broken for KMS. Yes, perhaps, but there is also the sysctl hw.acpi.reset_video which I have enabled on my older hardware (TP X40 running 8.3-REL and an old Xorg server) for it to work properly. (I however have some faint memory that reset_video might a no-op these days, or?) No, I didn't remove it. However, I strongly discourage it. In fact, the same functionality exists in vesa.c and it is safer. In this old mail regarding reset_video, there is a thought that it could be good with more reinitialisation: http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html vesa.c does pretty much the same thing. FYI, vbetool does more but it does not really do more reinitialisation. % grep ^MAINTAINER sysutils/vbetool/Makefile MAINTAINER= j...@freebsd.org :-) I however have one datapoint that I think contradicts John's thought. This is on a X201 with stable/9 and no options VESA. I first just booted up and stayed in text console, suspended and resumed. No backlight, of course, and also no content on the LCD, it is completely black. Panel may be completely off. Then, I started Xorg with KMS. Still no backlight, but you can see that the LCD is driven with the desired content, which is one step forward. Finally, I suspended and resumed, but no difference, the backlight is still off. I believe i915kms explicitly turns on LVDS/LCD panel. I guess it doesn't change brightness, though. Xorg/KMS didn't manage to turn the backlight on, so the text console suspend/resume cycle managed to persistently turn the backlight off. Can you change the brightness via hotkeys or acpi_video? One more thing, the kernel logs this at resume directly after the devices are powered on (transition to D0), but I have no idea whether it is relevant: Sep 2 19:57:21 bit kernel: error: [drm:pid1904:intel_lvds_enable] *ERROR* timed out waiting for panel to power off Yes, it looks relevant. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJ5HRAAoJECXpabHZMqHOZWQIAMHMrSWRw55HslMhQBpdbiI6 lT/iKNGUsHu4um9o8ULJMuuq2aKsSPxygz62a+XokefTbMEBIxQPFfcXAqvvGq2Y 6CvLjimTzfPO8axvvLRLEbVXDKcnHboabW5YxwJ6NreXwiWID+Noifc3EiEs5knj /Y0la3PP9ZWJu71DinGeyNLMoIeNdRC/E+o45P9uDTy3uZh7jBbIIwVdzAUEho+7 dN9xx88FkgYvnaNVJIf2sGmcMbMo0PJHB/9RNnz5AxNtmgVzrlEJaMMwKr1rnRu5 J5mUyuLt27/hGjSamqWaTMA/jS8gYJeF1Gyq7NWb2AvIsWHe68DY2a0MVZe1Oz0= =9xfZ -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On Wednesday, September 04, 2013 3:14:32 pm Bengt Ahlgren wrote: Jung-uk Kim j...@freebsd.org writes: On 2013-09-04 09:29:35 -0400, John Baldwin wrote: On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote: On 2013-09-03 16:47:47 -0400, John Baldwin wrote: Even with that hacked so I force vgapm0 and dpms0 to attach, I still can't resume in console mode, ... What happens? Does it panic, hang, or just no backlight? Just no backlight. It resumes fine and if I do it in multiuser I can ssh in, etc. It's just the backlight that doesn't resume. I was hopeful dpms.ko would fix that, but it didn't. :( Ah, that's a well-known problem and we cannot fix it without help of machine-specific code, e.g., drm1/drm2. Actually, both acpi_video and dpms try to restore video settings but nothing worked for Intel GPUs + LVDS + LCD panel AFAIK. I think i915drm has code to specifically turn on the backlight as I get some weird error message in the kernel console about a timeout trying to turn the panel off during suspend when I'm in X. So, I guess it has an ordering issue. If my memory serves, drm1 was okay with vesa, however. I *think* it accidentally worked because of automatic VT-switching, which is still broken for KMS. Yes, perhaps, but there is also the sysctl hw.acpi.reset_video which I have enabled on my older hardware (TP X40 running 8.3-REL and an old Xorg server) for it to work properly. (I however have some faint memory that reset_video might a no-op these days, or?) In this old mail regarding reset_video, there is a thought that it could be good with more reinitialisation: http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html I however have one datapoint that I think contradicts John's thought. This is on a X201 with stable/9 and no options VESA. I first just booted up and stayed in text console, suspended and resumed. No backlight, of course, and also no content on the LCD, it is completely black. Then, I started Xorg with KMS. Still no backlight, but you can see that the LCD is driven with the desired content, which is one step forward. Finally, I suspended and resumed, but no difference, the backlight is still off. Xorg/KMS didn't manage to turn the backlight on, so the text console suspend/resume cycle managed to persistently turn the backlight off. Try starting X before you suspend the first time. For me resume works fine if I do that. One more thing, the kernel logs this at resume directly after the devices are powered on (transition to D0), but I have no idea whether it is relevant: Sep 2 19:57:21 bit kernel: error: [drm:pid1904:intel_lvds_enable] *ERROR* timed out waiting for panel to power off I see this even when resume works fine. -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
Jung-uk Kim j...@freebsd.org writes: On 2013-09-04 15:14:32 -0400, Bengt Ahlgren wrote: Jung-uk Kim j...@freebsd.org writes: On 2013-09-04 09:29:35 -0400, John Baldwin wrote: On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote: On 2013-09-03 16:47:47 -0400, John Baldwin wrote: Even with that hacked so I force vgapm0 and dpms0 to attach, I still can't resume in console mode, ... What happens? Does it panic, hang, or just no backlight? Just no backlight. It resumes fine and if I do it in multiuser I can ssh in, etc. It's just the backlight that doesn't resume. I was hopeful dpms.ko would fix that, but it didn't. :( Ah, that's a well-known problem and we cannot fix it without help of machine-specific code, e.g., drm1/drm2. Actually, both acpi_video and dpms try to restore video settings but nothing worked for Intel GPUs + LVDS + LCD panel AFAIK. I think i915drm has code to specifically turn on the backlight as I get some weird error message in the kernel console about a timeout trying to turn the panel off during suspend when I'm in X. So, I guess it has an ordering issue. If my memory serves, drm1 was okay with vesa, however. I *think* it accidentally worked because of automatic VT-switching, which is still broken for KMS. Yes, perhaps, but there is also the sysctl hw.acpi.reset_video which I have enabled on my older hardware (TP X40 running 8.3-REL and an old Xorg server) for it to work properly. (I however have some faint memory that reset_video might a no-op these days, or?) No, I didn't remove it. However, I strongly discourage it. In fact, the same functionality exists in vesa.c and it is safer. In this old mail regarding reset_video, there is a thought that it could be good with more reinitialisation: http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html vesa.c does pretty much the same thing. FYI, vbetool does more but it does not really do more reinitialisation. % grep ^MAINTAINER sysutils/vbetool/Makefile MAINTAINER= j...@freebsd.org :-) Great! Is vesa.c = options VESA = vesa.ko? I however have one datapoint that I think contradicts John's thought. This is on a X201 with stable/9 and no options VESA. I first just booted up and stayed in text console, suspended and resumed. No backlight, of course, and also no content on the LCD, it is completely black. Panel may be completely off. Then, I started Xorg with KMS. Still no backlight, but you can see that the LCD is driven with the desired content, which is one step forward. Finally, I suspended and resumed, but no difference, the backlight is still off. I believe i915kms explicitly turns on LVDS/LCD panel. I guess it doesn't change brightness, though. Xorg/KMS didn't manage to turn the backlight on, so the text console suspend/resume cycle managed to persistently turn the backlight off. Can you change the brightness via hotkeys or acpi_video? The value of hw.acpi.video.lcd0.brightness changes when the screen brightness keys (Fn+Home/End) are pressed, but nothing happens with the screen. Same goes for changing the value with sysctl. After a fresh boot it works with one issue. The screen brightness level seems to lag behind one keypress. Without acpi_video, screen brightness changes without the lag. hw.acpi.video.lcd0.active is always stuck at 0 - can't change with sysctl (regardless if the screen is on after a fresh boot, or black after a text console suspend/resume): [root@bit ~]# sysctl hw.acpi.video.lcd0.active=1 hw.acpi.video.lcd0.active: 0 - 0 Again, for my old X40 with non-KMS Xorg intel driver has (curiously, the screen blinks when issuing this sysctl command): [bengta@P142 ~]$ sysctl hw.acpi.video hw.acpi.video.lcd0.active: 1 hw.acpi.video.crt0.active: 0 Jumping to another thing. The Xorg intel/KMS driver does not present a backlight property using RandR (older non-KMS intel driver did): [bengta@bit ~]$ xbacklight No outputs have backlight property Bengt One more thing, the kernel logs this at resume directly after the devices are powered on (transition to D0), but I have no idea whether it is relevant: Sep 2 19:57:21 bit kernel: error: [drm:pid1904:intel_lvds_enable] *ERROR* timed out waiting for panel to power off Yes, it looks relevant. Jung-uk Kim ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote: Jung-uk Kim j...@freebsd.org writes: On 2013-09-04 15:14:32 -0400, Bengt Ahlgren wrote: Jung-uk Kim j...@freebsd.org writes: On 2013-09-04 09:29:35 -0400, John Baldwin wrote: On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote: On 2013-09-03 16:47:47 -0400, John Baldwin wrote: Even with that hacked so I force vgapm0 and dpms0 to attach, I still can't resume in console mode, ... What happens? Does it panic, hang, or just no backlight? Just no backlight. It resumes fine and if I do it in multiuser I can ssh in, etc. It's just the backlight that doesn't resume. I was hopeful dpms.ko would fix that, but it didn't. :( Ah, that's a well-known problem and we cannot fix it without help of machine-specific code, e.g., drm1/drm2. Actually, both acpi_video and dpms try to restore video settings but nothing worked for Intel GPUs + LVDS + LCD panel AFAIK. I think i915drm has code to specifically turn on the backlight as I get some weird error message in the kernel console about a timeout trying to turn the panel off during suspend when I'm in X. So, I guess it has an ordering issue. If my memory serves, drm1 was okay with vesa, however. I *think* it accidentally worked because of automatic VT-switching, which is still broken for KMS. Yes, perhaps, but there is also the sysctl hw.acpi.reset_video which I have enabled on my older hardware (TP X40 running 8.3-REL and an old Xorg server) for it to work properly. (I however have some faint memory that reset_video might a no-op these days, or?) No, I didn't remove it. However, I strongly discourage it. In fact, the same functionality exists in vesa.c and it is safer. In this old mail regarding reset_video, there is a thought that it could be good with more reinitialisation: http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html vesa.c does pretty much the same thing. FYI, vbetool does more but it does not really do more reinitialisation. % grep ^MAINTAINER sysutils/vbetool/Makefile MAINTAINER= j...@freebsd.org :-) Great! Is vesa.c = options VESA = vesa.ko? Yes. I however have one datapoint that I think contradicts John's thought. This is on a X201 with stable/9 and no options VESA. I first just booted up and stayed in text console, suspended and resumed. No backlight, of course, and also no content on the LCD, it is completely black. Panel may be completely off. Then, I started Xorg with KMS. Still no backlight, but you can see that the LCD is driven with the desired content, which is one step forward. Finally, I suspended and resumed, but no difference, the backlight is still off. I believe i915kms explicitly turns on LVDS/LCD panel. I guess it doesn't change brightness, though. Xorg/KMS didn't manage to turn the backlight on, so the text console suspend/resume cycle managed to persistently turn the backlight off. Can you change the brightness via hotkeys or acpi_video? The value of hw.acpi.video.lcd0.brightness changes when the screen brightness keys (Fn+Home/End) are pressed, but nothing happens with the screen. Same goes for changing the value with sysctl. After a fresh boot it works with one issue. The screen brightness level seems to lag behind one keypress. Without acpi_video, screen brightness changes without the lag. hw.acpi.video.lcd0.active is always stuck at 0 - can't change with sysctl (regardless if the screen is on after a fresh boot, or black after a text console suspend/resume): [root@bit ~]# sysctl hw.acpi.video.lcd0.active=1 hw.acpi.video.lcd0.active: 0 - 0 Again, for my old X40 with non-KMS Xorg intel driver has (curiously, the screen blinks when issuing this sysctl command): [bengta@P142 ~]$ sysctl hw.acpi.video hw.acpi.video.lcd0.active: 1 hw.acpi.video.crt0.active: 0 Then, KMS probably breaks acpi_video(4), too. :-( Jung-uk Kim Jumping to another thing. The Xorg intel/KMS driver does not present a backlight property using RandR (older non-KMS intel driver did): [bengta@bit ~]$ xbacklight No outputs have backlight property Bengt One more thing, the kernel logs this at resume directly after the devices are powered on (transition to D0), but I have no idea whether it is relevant: Sep 2 19:57:21 bit kernel: error: [drm:pid1904:intel_lvds_enable] *ERROR* timed out waiting for panel to power off Yes, it looks relevant. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJ7iTAAoJECXpabHZMqHOX0kH/Ag+vuvrx3YKyeYHKiGwlOKR eOp8s4m9EJgdPFy2Tw5u9xQsLiQ1JBgT10kZ+PDXaqFGEPGlVROrfc/lsoUVx6u3 ArOGaG1+NO1dTHurfrysRl/k35fcnY3p8+KrYmzbia6BNWC/3DmtnHItaWn+nOs2 PFJfCBWjjljVpZa+TNRBR2H5QMGOFnOGA9kDgZQe3QJY0JGZOMTuXizWatEYWo5q 7hLZsyvEsIQNSbmofE7KO5JNekllQ/F5A9RLilXRPnJBaJm1to2BT89Nf8JgiIxm
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-04 18:47:47 -0400, Jung-uk Kim wrote: On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote: The value of hw.acpi.video.lcd0.brightness changes when the screen brightness keys (Fn+Home/End) are pressed, but nothing happens with the screen. Same goes for changing the value with sysctl. After a fresh boot it works with one issue. The screen brightness level seems to lag behind one keypress. Without acpi_video, screen brightness changes without the lag. hw.acpi.video.lcd0.active is always stuck at 0 - can't change with sysctl (regardless if the screen is on after a fresh boot, or black after a text console suspend/resume): [root@bit ~]# sysctl hw.acpi.video.lcd0.active=1 hw.acpi.video.lcd0.active: 0 - 0 Again, for my old X40 with non-KMS Xorg intel driver has (curiously, the screen blinks when issuing this sysctl command): [bengta@P142 ~]$ sysctl hw.acpi.video hw.acpi.video.lcd0.active: 1 hw.acpi.video.crt0.active: 0 Then, KMS probably breaks acpi_video(4), too. :-( kib let me know that there is a way to make it work but it was not well-integrated to i915kms.ko. If you are interested in fixing it, dev/drm2/i915/intel_opregion.c is the source and you can download the specification from here: https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJ8rwAAoJECXpabHZMqHOz3cIAIH5qAXbfWZrWgwJWYAyL9UI z0f/LC5ufqlpgnyvFAHZO75oDebKiDq8skGWDFDhEj8vjp8JIydZSM89EK5wj0zB eCAVwquzcasduGXQZSGyN2tPUqwCm3Fuw3Bsj2Fhwgy3Y0TA9Vsz2KGTH4qCuqWU 7W97FXpLmIOpMBh/LcWCE96hY8u0HxZmzFhjMn5MlJ7z07zEc58YRpieZ3MqACCx ml3dp56RVUQhXXZzrc5Vj+Oxgmti13Xrat7YrzVmpqSRzDtOLNaoqvk4sMz1Crh4 aXq1de1+7Hc+g2oroN3mqDcb5RXknqZ7Aq7wbiOCeQwOzK7vrs3khFWq9luWG9E= =nWlO -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On Sunday, September 01, 2013 3:51:47 pm Adrian Chadd wrote: (cc jkim) Hi! Would you mind taking a look at the -acpi list posts with this subject? It looks like a lot of the video suspend/resume issues on these thinkpads boil down to the VESA driver code. If it's disabled, (at least) x11 resume works. Would you be able to help us track down what's going on? Thanks! Most likely vga_suspend()/vga_resume() in sys/isa/vga_isa.c is calling vidd_save_state() and vidd_load_state() which in the VESA case map to the _save_state() and _load_state() methods in sys/dev/fb/vesa.c. These methods look fairly sane to me, so it's probably either a BIOS bug, or the fact that KMS is bypassing the BIOS, so when KMS is active we should perhaps disable the VESA BIOS. I'd argue that we should be it is a BIOS bug regardless. However, one thing that might help is that this is being called at a random time rather than when vgapci0 is being suspended and resumed. Actually, it looks like jkim fixed this via the vgapm driver, except I have no vgapm0 device on my laptop. I wonder if it's supposed to be device_get_unit() instead of device_get_flags() in the vgapm identify routine? -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-03 16:47:47 -0400, John Baldwin wrote: On Tuesday, September 03, 2013 4:12:01 pm Jung-uk Kim wrote: On 2013-09-03 12:28:30 -0400, John Baldwin wrote: On Sunday, September 01, 2013 3:51:47 pm Adrian Chadd wrote: (cc jkim) Hi! Would you mind taking a look at the -acpi list posts with this subject? It looks like a lot of the video suspend/resume issues on these thinkpads boil down to the VESA driver code. If it's disabled, (at least) x11 resume works. Would you be able to help us track down what's going on? Thanks! Most likely vga_suspend()/vga_resume() in sys/isa/vga_isa.c is calling vidd_save_state() and vidd_load_state() which in the VESA case map to the _save_state() and _load_state() methods in sys/dev/fb/vesa.c. Unfortunately, I don't really know where it actually fails because I do not have *any* Intel GPUs to test. If vesa.c is really causing trouble, vesa_bios_post() in vesa_load_state() may be the culprit, however. I can try narrowing it down. Please do. These methods look fairly sane to me, so it's probably either a BIOS bug, or the fact that KMS is bypassing the BIOS, so when KMS is active we should perhaps disable the VESA BIOS. AFAIK, KMS does not play nice with syscons(4) ATM, e.g., syscons does automatic VT switching and it may need to be turned off. Again, it is just my guess. Well, I don't have to do that, just having no VESA in the kernel results in resume working fine in X. It seems that the i915drm driver is doing something to explicitly enable the backlight on the LCD btw. Normally, I expect a device tree like this to do properly suspend/resume with *drm1*: nexus0 acpi0 pcib0 pci0 hostb0 pcib1 pci1 vgapci0 vgapm0 dpms0 drm0 ... isab0 isa0 sc0 vga0 ... Not sure about i915kms.ko. However, one thing that might help is that this is being called at a random time rather than when vgapci0 is being suspended and resumed. Actually, it looks like jkim fixed this via the vgapm driver, except I have no vgapm0 device on my laptop. If you don't have vgapm0, its BIOS is not setting PCIB_BCR_VGA_ENABLE bit to its bridge. Often times, that means it is legacy free stuff. I wonder if it's supposed to be device_get_unit() instead of device_get_flags() in the vgapm identify routine? No. With multiple GPUs, it is (was?) the only way to find the boot display because unit number is not always 0. Although dumbbell added vga_pci_is_boot_display() in current, this interface should be kept for 9.x. Hmm, so there is magic to set this I guess? Ah, I see it now in vga_pci.c. That does seem gross compared to an ivar or some such. :) And you said the almost exact same thing but okayed at the time. :-) In my case btw, x86bios_match_device() doesn't work because the BIOS ROM has a PCI device ID of 0x0106 while the device itself is 0x0126. It's a bug. Even with that hacked so I force vgapm0 and dpms0 to attach, I still can't resume in console mode, and resume in X refuses to wakeup with VESA in the kernel (hitting the power button doesn't make it wakeup). Please try to make syscons resume first. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSJmgdAAoJECXpabHZMqHOh6kH/RpRVeXz3n8eb72PMfZ1eQDy 2LBn/NCpxbRAHhNkwclLqCorQp6CDAEM1iO4IJMgUG4BrRYcrGUybM7kHDGn5Oy3 7qLkXmu1TmBGwFndHMZ8VaqLsUV2mgKG1DLgCCEp2NG3szOuSgg1KwBaZuT1OUhm TtJIWyuuwWld+DAaBaJJqCTJun6s3rpddXIEKj/2R+f4q99cjLt5I5qel+goArE+ yym4VrkY0S1Fn3Vj5+Nv8WMXlTgknIymsEg7fNJ9RDBGDPZ11l5DLztLjj+UfvIL K6L3+AMNJ58HRA/PibPIGNgI0WXUDJ/KSNN0A44RIItiYwTxJSh482PkghlrLE4= =jHx2 -END PGP SIGNATURE- ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
(cc jkim) Hi! Would you mind taking a look at the -acpi list posts with this subject? It looks like a lot of the video suspend/resume issues on these thinkpads boil down to the VESA driver code. If it's disabled, (at least) x11 resume works. Would you be able to help us track down what's going on? Thanks! -adrian On 31 August 2013 10:23, Kevin Oberman rkober...@gmail.com wrote: On Sat, Aug 31, 2013 at 9:53 AM, Adrian Chadd adr...@freebsd.org wrote: Ok. I'm glad this is actually working for people. But now comes the hard bit - figuring out why the VESA driver is breaking resume. :( I actually use VESA text modes in console mode so I'll take a look but I can't promise anything. Who actually has experience with the VESA code and may be able to help? Does anyone know? Thanks, -adrian Of course this is the real issue. Removing VESA is just a band-aid and will become a problem once newcons makes it out the door (any day now). I'd like to try to figure out the scope of the problem, if possible. In most (all?) reports, removing VESA has worked on Thinkpads. I think I have seen reports that it works on other platforms, but I'm not positive. I also believe that it has been reported to not work for attempts to suspend/resume when in text mode... only when in X. (I guess I can test this myself.) For almost four years all vesa commits were by jkim. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On Sun, Sep 01, 2013 at 12:51:47PM -0700, Adrian Chadd wrote: (cc jkim) Hi! Would you mind taking a look at the -acpi list posts with this subject? It looks like a lot of the video suspend/resume issues on these thinkpads boil down to the VESA driver code. If it's disabled, (at least) x11 resume works. Just to clarify on some information I provided a few days ago, I did not realize at first (when I replied) that this thread was targeted towards Thinkpad laptops. For what it is worth, my laptop is an ASUS X53E. For a long time, suspend/resume did not work (well, resume did not work, suspend worked fine). avg@ fixed this with r246251. However, after a few weeks, the next Xorg update broke it. In between those updates, I did not change anything for my kernel config (in fact, the latest thing I recall adding/removing was the VESA to test this out). TLDR: this is broader than just Thinkpads. I am happy to put VESA back into my kernel config and test patches, if that is helpful. Glen pgpBVccnd9cA5.pgp Description: PGP signature
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On Sat, Aug 31, 2013 at 9:53 AM, Adrian Chadd adr...@freebsd.org wrote: Ok. I'm glad this is actually working for people. But now comes the hard bit - figuring out why the VESA driver is breaking resume. :( I actually use VESA text modes in console mode so I'll take a look but I can't promise anything. Who actually has experience with the VESA code and may be able to help? Does anyone know? Thanks, -adrian Of course this is the real issue. Removing VESA is just a band-aid and will become a problem once newcons makes it out the door (any day now). I'd like to try to figure out the scope of the problem, if possible. In most (all?) reports, removing VESA has worked on Thinkpads. I think I have seen reports that it works on other platforms, but I'm not positive. I also believe that it has been reported to not work for attempts to suspend/resume when in text mode... only when in X. (I guess I can test this myself.) For almost four years all vesa commits were by jkim. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On Fri, Aug 30, 2013 at 01:39:59AM -0700, Adrian Chadd wrote: On 29 August 2013 20:14, Sergey A. Osokin o...@freebsd.org wrote: On Wed, Aug 28, 2013 at 07:03:10PM +0400, Gleb Smirnoff wrote: Laura, Now bad news :) Last major Xorg update in ports, which happened couple of months ago, introduced a regression: xorg performs very slowly after resume. If the server process is restarted, then a new one performs okay. Agree with Gleb. Kind of a slowness exist after resume. Can y'all grab some basic, naive benchmarks (disk, CPU) and compare them before/after a suspend/resume cycle? Unfortunately, I'm not sure what I need to check... -- Sergey A. Osokin o...@freebsd.org ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
Just a mee too report for a Thinkpad X201. Resume now results in a usable display with Intel/KMS graphics thanks to removing options VESA from the kernel config! Still no backlight in console mode, however. I have not investigated any slow-downs. Thanks for the crucial piece of info! (I'm on stable/9 and a ports tree as of today.) Bengt Glen Barber g...@freebsd.org writes: On Thu, Aug 29, 2013 at 06:42:28PM +0200, Laura Marie Feeney wrote: No xorg.conf is needed and all acpi options are as default. It seems to work correctly both with and without acpi_video and acpi_ibm in the kernel. It's still necessary to compile out 'options VESA' from the kernel, otherwise resume fails entirely. I can also confirm that removing VESA from the kernel allows my system to resume properly, both with Xorg and console. root@nucleus:~ # kldstat Id Refs AddressSize Name 1 28 0x8020 eb6148 kernel 21 0x810b7000 22ca40 zfs.ko 32 0x812e4000 5e58 opensolaris.ko 41 0x81412000 6149fi915kms.ko 51 0x81474000 3e5c7drm2.ko I also observe the issue that Gleb Smirnoff mentions below, that the xorg server is quite slow after result. Using 'xterm -sb' and moving the scrollbar up and down very fast, I was able to able to get the xorg process up to ~20% of CPU. On casual observation, it didn't seem to get worse after several suspend/resume cycles. I did not see any unusual CPU chewing by X after resume in my case. I did see something unpleasant with xrandr(1), however. I have dual external monitors attached, which I have a login script set the resolution properly. With my resolution set to 3840x1080, X is unusable on resume. (The screen is fuzzy, but the machine does not crash.) Without changing the resolution before suspend, X works properly at resume. Glen ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On Friday, August 30, 2013 10:51:02 am Sergey A. Osokin wrote: On Fri, Aug 30, 2013 at 01:39:59AM -0700, Adrian Chadd wrote: On 29 August 2013 20:14, Sergey A. Osokin o...@freebsd.org wrote: On Wed, Aug 28, 2013 at 07:03:10PM +0400, Gleb Smirnoff wrote: Laura, Now bad news :) Last major Xorg update in ports, which happened couple of months ago, introduced a regression: xorg performs very slowly after resume. If the server process is restarted, then a new one performs okay. Agree with Gleb. Kind of a slowness exist after resume. Can y'all grab some basic, naive benchmarks (disk, CPU) and compare them before/after a suspend/resume cycle? Unfortunately, I'm not sure what I need to check... Maybe try x11perf before and after? I just removed VESA from my kernel on an X220 and it now suspends and resumes great in X. I don't notice any slowdown, but I'm using a very simple tiling window manager (i3wm). -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On 08/30/13 23:53, Sergey A. Osokin wrote: Maybe try x11perf before and after? I just removed VESA from my kernel on an X220 and it now suspends and resumes great in X. I don't notice any slowdown, but I'm using a very simple tiling window manager (i3wm). I'm also using i3 now, previously it was fvwm2 earlier with slowdown. Hmm... Gleb and Luara, could you try x11-wm/i3 for suspend/resume trick and check slowdown? I was using twm (like i3, it's very lightweight window manager and actually my personal preference for everyday use) and saw little or no slowdown under normal use. (I was able to get the cpu load to spike quite a bit higher by scrolling an xterm as fast as I could, but that's not very normal.) Will try i3 tomorrow. Perhaps cairo-perf with some common set of traces would be a good comparison? Laura ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On Fri, Aug 30, 2013 at 11:53:22AM -0400, John Baldwin wrote: On Friday, August 30, 2013 10:51:02 am Sergey A. Osokin wrote: On Fri, Aug 30, 2013 at 01:39:59AM -0700, Adrian Chadd wrote: On 29 August 2013 20:14, Sergey A. Osokin o...@freebsd.org wrote: On Wed, Aug 28, 2013 at 07:03:10PM +0400, Gleb Smirnoff wrote: Laura, Now bad news :) Last major Xorg update in ports, which happened couple of months ago, introduced a regression: xorg performs very slowly after resume. If the server process is restarted, then a new one performs okay. Agree with Gleb. Kind of a slowness exist after resume. Can y'all grab some basic, naive benchmarks (disk, CPU) and compare them before/after a suspend/resume cycle? Unfortunately, I'm not sure what I need to check... Maybe try x11perf before and after? I just removed VESA from my kernel on an X220 and it now suspends and resumes great in X. I don't notice any slowdown, but I'm using a very simple tiling window manager (i3wm). I'm also using i3 now, previously it was fvwm2 earlier with slowdown. Hmm... Gleb and Luara, could you try x11-wm/i3 for suspend/resume trick and check slowdown? -- Sergey A. Osokin o...@freebsd.org ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On Sat, Aug 31, 2013 at 12:12:59AM +0200, Laura Marie Feeney wrote: On 08/30/13 23:53, Sergey A. Osokin wrote: Maybe try x11perf before and after? I just removed VESA from my kernel on an X220 and it now suspends and resumes great in X. I don't notice any slowdown, but I'm using a very simple tiling window manager (i3wm). I'm also using i3 now, previously it was fvwm2 earlier with slowdown. Hmm... Gleb and Luara, could you try x11-wm/i3 for suspend/resume trick and check slowdown? I was using twm (like i3, it's very lightweight window manager and actually my personal preference for everyday use) and saw little or no slowdown under normal use. (I was able to get the cpu load to spike quite a bit higher by scrolling an xterm as fast as I could, but that's not very normal.) The main difference in these two wms its toolkits - i3 mostly uses a xcb, twm uses a widget toolkit and it looks like xcb works well... -- Sergey A. Osokin o...@freebsd.org ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On Fri, Aug 30, 2013 at 3:12 PM, Laura Marie Feeney lmfee...@sics.sewrote: On 08/30/13 23:53, Sergey A. Osokin wrote: Maybe try x11perf before and after? I just removed VESA from my kernel on an X220 and it now suspends and resumes great in X. I don't notice any slowdown, but I'm using a very simple tiling window manager (i3wm). I'm also using i3 now, previously it was fvwm2 earlier with slowdown. Hmm... Gleb and Luara, could you try x11-wm/i3 for suspend/resume trick and check slowdown? I was using twm (like i3, it's very lightweight window manager and actually my personal preference for everyday use) and saw little or no slowdown under normal use. (I was able to get the cpu load to spike quite a bit higher by scrolling an xterm as fast as I could, but that's not very normal.) Will try i3 tomorrow. Perhaps cairo-perf with some common set of traces would be a good comparison? Laura Woo hoo! for the first time in the 2+ years I've owned it I can resume my T520. Removing VESA from the kernel did the trick! After resume, X was rather slow for some operations. Not painfully slow, but noticeably slower than normal. I did nothing to the system but ran x11perf. After about 2.5 hours it completed. When I resumed use of the system, it seems to be back to normal. No idea what made it change. I am running Gnome2, so it is a very heavyweight system running 9.2-Stable from last Wednesday (r255013). I'm delighted to finally have a working resume. It's been YEARS since I've had it that works on any of my Thinkpads (600E, T43, T520). -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
Hi! What's the result of all of this? Laura - do you have functioning suspend/resume with xorg now? -adrian On 28 August 2013 08:03, Gleb Smirnoff gleb...@freebsd.org wrote: Laura, according to your Xorg.log PCI device ID of your video card exactly matches mine 8086:0166:17aa:21f9, so it should work. It looks like versions of Xorg and Xorg Intel driver installed from packages are too old, and this is the biggest difference between your setup and mine. You are running Xorg 1.7.7. This is what I run: glebius@think:~:|pkg info xorg-server xf86-video-intel xorg-server-1.12.4,1 xf86-video-intel-2.21.9 To get these packages you need to update your ports tree, put these lines into /etc/make.conf: WITH_NEW_XORG=yes WITH_KMS=yes , and reinstall xorg-server and xf86-video-intel from ports. You'd probably need to rebuild all xorg drivers like mouse and keyboard, to make them compatible with new server version. If this isn't enough I can send my xorg.conf and kernel config. But I hope default configs should be fine. Now bad news :) Last major Xorg update in ports, which happened couple of months ago, introduced a regression: xorg performs very slowly after resume. If the server process is restarted, then a new one performs okay. So this looks like xorg issue, not FreeBSD kernel problem. On Wed, Aug 28, 2013 at 02:48:04PM +0200, Laura Marie Feeney wrote: L Thanks! I think that X1 and Carbon are different names, as Lenovo seems L to use them quite interchangably (perhaps for different countries?). L This isn't an X1 Touch, which surely has non-trivial differences for the L touchscreen. X1 and X1 Carbon are really different, I owned both. Yep, both work with FreeBSD. -- Totus tuus, Glebius. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
Hi Yes! I now have working suspend/resume building xorg using the updated ports and compile options that Gleb Smirnoff kindly pointed me at. No xorg.conf is needed and all acpi options are as default. It seems to work correctly both with and without acpi_video and acpi_ibm in the kernel. It's still necessary to compile out 'options VESA' from the kernel, otherwise resume fails entirely. I also observe the issue that Gleb Smirnoff mentions below, that the xorg server is quite slow after result. Using 'xterm -sb' and moving the scrollbar up and down very fast, I was able to able to get the xorg process up to ~20% of CPU. On casual observation, it didn't seem to get worse after several suspend/resume cycles. Definitely suspend/resume are working and amazingly fast compared to 8.2 (though running on a much older machine). Thanks to all for the useful suggestions! Laura On 08/29/13 16:22, Adrian Chadd wrote: Hi! What's the result of all of this? Laura - do you have functioning suspend/resume with xorg now? -adrian On 28 August 2013 08:03, Gleb Smirnoff gleb...@freebsd.org mailto:gleb...@freebsd.org wrote: Laura, according to your Xorg.log PCI device ID of your video card exactly matches mine 8086:0166:17aa:21f9, so it should work. It looks like versions of Xorg and Xorg Intel driver installed from packages are too old, and this is the biggest difference between your setup and mine. You are running Xorg 1.7.7. This is what I run: glebius@think:~:|pkg info xorg-server xf86-video-intel xorg-server-1.12.4,1 xf86-video-intel-2.21.9 To get these packages you need to update your ports tree, put these lines into /etc/make.conf: WITH_NEW_XORG=yes WITH_KMS=yes , and reinstall xorg-server and xf86-video-intel from ports. You'd probably need to rebuild all xorg drivers like mouse and keyboard, to make them compatible with new server version. If this isn't enough I can send my xorg.conf and kernel config. But I hope default configs should be fine. Now bad news :) Last major Xorg update in ports, which happened couple of months ago, introduced a regression: xorg performs very slowly after resume. If the server process is restarted, then a new one performs okay. So this looks like xorg issue, not FreeBSD kernel problem. On Wed, Aug 28, 2013 at 02:48:04PM +0200, Laura Marie Feeney wrote: L Thanks! I think that X1 and Carbon are different names, as Lenovo seems L to use them quite interchangably (perhaps for different countries?). L This isn't an X1 Touch, which surely has non-trivial differences for the L touchscreen. X1 and X1 Carbon are really different, I owned both. Yep, both work with FreeBSD. -- Totus tuus, Glebius. ___ freebsd-acpi@freebsd.org mailto:freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org mailto:freebsd-acpi-unsubscr...@freebsd.org ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
Hi! On 29 August 2013 09:42, Laura Marie Feeney lmfee...@sics.se wrote: Hi Yes! I now have working suspend/resume building xorg using the updated ports and compile options that Gleb Smirnoff kindly pointed me at. No xorg.conf is needed and all acpi options are as default. It seems to work correctly both with and without acpi_video and acpi_ibm in the kernel. It's still necessary to compile out 'options VESA' from the kernel, otherwise resume fails entirely. I also observe the issue that Gleb Smirnoff mentions below, that the xorg server is quite slow after result. Using 'xterm -sb' and moving the scrollbar up and down very fast, I was able to able to get the xorg process up to ~20% of CPU. On casual observation, it didn't seem to get worse after several suspend/resume cycles. Definitely suspend/resume are working and amazingly fast compared to 8.2 (though running on a much older machine). Thanks to all for the useful suggestions! Let's not finish this just yet! I'd like to try and nail down exactly what's going on so PRs can be filed. * Is this with 9.2-RC2? Are you wiling to try out a -HEAD snapshot to make sure this stuff in -10 is also going to work? * Ok, so if you have no VESA option, does suspend/resume work in console mode? * Try manually setting the cpu frequency low and high (sysctl dev.0.cpu - you can change 'freq') - see if that fixes your speed issues. Someone else has reported this. Thanks! -adrian ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On 08/29/13 18:44, Adrian Chadd wrote: Hi! Let's not finish this just yet! I'd like to try and nail down exactly what's going on so PRs can be filed. Absolutely. (I was thinking to do this off-list to minimize spam.) * Is this with 9.2-RC2? Yes this is 9.2-RC2. I think the problem is that the simple install path ends up with out-of-date components, rather than anything wrong with the components that should be used. Are you wiling to try out a -HEAD snapshot to make sure this stuff in -10 is also going to work? Yes, but probably not until the weekend. * Ok, so if you have no VESA option, does suspend/resume work in console mode? No. The system resumes (can ssh in), but the backlight doesn't come on (using a flashlight, I don't see any video mode running either). See http://www.sics.se/~lmfeeney/9.2-RC2/messages_console. * Try manually setting the cpu frequency low and high (sysctl dev.0.cpu - you can change 'freq') - see if that fixes your speed issues. Someone else has reported this. Before and after resume, dev.cpu.0.freq: 1700. Setting to 100 and back to 1700 didn't seem to have much effect. Basically, what I see is that after resume, it seems to be easier to increase the load on the cpu (i.e. looking at top) by e.g. scrolling quickly. My test sequence was: boot, 'startx' (so twm and a couple xterms) 'top (in one xterm) 'xterm -sb -geometry 100x65' (make xterm w/ scrollbar), 'cat /var/log/messages' (in the new xterm) scroll very rapidly up and down for ~20sec look at top output suspend/resume and repeat the scrolling. The load seems to go quite a bit higher after resuming (CPU from ~10% to ~20%). But this is definitely not a scientific test AND I was primed by Gleb Smirnoff's comments to look for a performance hit. For sensible use (i.e. not madly scrolling), I don't sense slowdown. But the machine is completely minimal: portmaster and xorg are the only ports installed. It could be that KDE + web + mail + applications managing lots of things on the screen would show a big slowdown, as reported by others. It would probably make sense to define some metric that people who have reported problems can compare before and after suspsend/resume. Best, Laura ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On Thu, Aug 29, 2013 at 08:51:18PM +0200, Laura Marie Feeney wrote: L suspend/resume and repeat the scrolling. The load seems to go quite a L bit higher after resuming (CPU from ~10% to ~20%). But this is L definitely not a scientific test AND I was primed by Gleb Smirnoff's L comments to look for a performance hit. Hmm, my slowdown is really noticable, I barely can work after resume. Can you tell exact versions of xorg-server and x86-intel-driver you installed? -- Totus tuus, Glebius. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On Thu, Aug 29, 2013 at 03:04:28PM -0400, Glen Barber wrote: G I also observe the issue that Gleb Smirnoff mentions below, that the G xorg server is quite slow after result. Using 'xterm -sb' and G moving the scrollbar up and down very fast, I was able to able to G get the xorg process up to ~20% of CPU. On casual observation, it G didn't seem to get worse after several suspend/resume cycles. G G I did not see any unusual CPU chewing by X after resume in my case. G I did see something unpleasant with xrandr(1), however. I have dual G external monitors attached, which I have a login script set the G resolution properly. With my resolution set to 3840x1080, X is unusable G on resume. (The screen is fuzzy, but the machine does not crash.) G Without changing the resolution before suspend, X works properly at G resume. I also have external monitor and observe slowdown after resume on it. -- Totus tuus, Glebius. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
I don't see noticable slowdown. But there is NOTHING (twm and a couple of xterms) running on the machine. A more practical machine is going to be interacting with a lot more X functionality. If you just run 'startx' from the console, do you still have a problem? xf86-input-keyboard-1.7.0 xf86-input-mouse-1.9.0 xf86-video-intel-2.21.9 xorg-7.7 xorg-server-1.12.4_1,1 dri-8.0.5_3,2 libdrm-2.4.46 On 08/29/13 20:58, Gleb Smirnoff wrote: On Thu, Aug 29, 2013 at 08:51:18PM +0200, Laura Marie Feeney wrote: L suspend/resume and repeat the scrolling. The load seems to go quite a L bit higher after resuming (CPU from ~10% to ~20%). But this is L definitely not a scientific test AND I was primed by Gleb Smirnoff's L comments to look for a performance hit. Hmm, my slowdown is really noticable, I barely can work after resume. Can you tell exact versions of xorg-server and x86-intel-driver you installed? ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On Wed, Aug 28, 2013 at 07:03:10PM +0400, Gleb Smirnoff wrote: Laura, Now bad news :) Last major Xorg update in ports, which happened couple of months ago, introduced a regression: xorg performs very slowly after resume. If the server process is restarted, then a new one performs okay. Agree with Gleb. Kind of a slowness exist after resume. -- Sergey A. Osokin o...@freebsd.org ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On 08/28/13 06:05, Sergey A. Osokin wrote: On Tue, Aug 27, 2013 at 09:53:18PM +0200, Laura Marie Feeney wrote: At https://wiki.freebsd.org/SuspendResume, users osa and glebius both report on Thinkpad Carbon X1. This is wrong, please read wiki carefully cause I'm using Lenovo ThinkPad X1 nor ThinkPad Carbon. Thanks! I think that X1 and Carbon are different names, as Lenovo seems to use them quite interchangably (perhaps for different countries?). This isn't an X1 Touch, which surely has non-trivial differences for the touchscreen. Even if you're sure they're not exactly the same model, it might be helpful to have some more information about your configuration, to see what the difference is between working and not. Best, Laura ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
Hi Mattias, These results I described (system resumes, but video is not restored, x server exits with error) are with 'options VESA' compiled out of a minimal kernel. See http://www.sics.se/~lmfeeney/9.2-RC2/ANKUNGE.config for the full config) With 'options VESA' included in the same minimal kernel, the machine totally fails to resume - it doesn't even respond to ping. Best, Laura On 08/28/13 16:37, Laura Marie Feeney wrote: Hi Laura, Am 27.08.2013 22:32, schrieb Laura Marie Feeney: I tried suspend/resume (less systematically) with 9.1-RELEASE and didn't have success. I can build minimal kernels for both 9.1 and 9.0 and will report (probably not tonight). Unfortunately, the SuspendResume wiki isn't completely clear about what build was used - perhaps the folks who reported will be able to clarify. Can you rebuild your kernel without options VESA. This helped to fix suspend/resume for my Thinkpad X121e. Regards, Matthias ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
Laura, according to your Xorg.log PCI device ID of your video card exactly matches mine 8086:0166:17aa:21f9, so it should work. It looks like versions of Xorg and Xorg Intel driver installed from packages are too old, and this is the biggest difference between your setup and mine. You are running Xorg 1.7.7. This is what I run: glebius@think:~:|pkg info xorg-server xf86-video-intel xorg-server-1.12.4,1 xf86-video-intel-2.21.9 To get these packages you need to update your ports tree, put these lines into /etc/make.conf: WITH_NEW_XORG=yes WITH_KMS=yes , and reinstall xorg-server and xf86-video-intel from ports. You'd probably need to rebuild all xorg drivers like mouse and keyboard, to make them compatible with new server version. If this isn't enough I can send my xorg.conf and kernel config. But I hope default configs should be fine. Now bad news :) Last major Xorg update in ports, which happened couple of months ago, introduced a regression: xorg performs very slowly after resume. If the server process is restarted, then a new one performs okay. So this looks like xorg issue, not FreeBSD kernel problem. On Wed, Aug 28, 2013 at 02:48:04PM +0200, Laura Marie Feeney wrote: L Thanks! I think that X1 and Carbon are different names, as Lenovo seems L to use them quite interchangably (perhaps for different countries?). L This isn't an X1 Touch, which surely has non-trivial differences for the L touchscreen. X1 and X1 Carbon are really different, I owned both. Yep, both work with FreeBSD. -- Totus tuus, Glebius. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
suspend/resume on Lenovo X1 (regression from reports on wiki)
At https://wiki.freebsd.org/SuspendResume, users osa and glebius both report on Thinkpad Carbon X1. They agree that suspend and resume work from X (but not console) for '9.0-stable' and 'head' respectively. Sadly, I can't reproduce this on 9.2-RC2: Under X, resume fails to restore video. I don't know whether this is a configuration error on my part, or a regression, or the original reports on the wiki were misunderstood. (I do reproduce it not working on console.) Suggestions are welcome, especially from those who report working configurations. Details below, log files at http://www.sics.se/~lmfeeney/9.2-RC2. This is a new machine, with a minimal 9.2-RC2 install from memstick. X and its dependencies are installed from packages via portmaster and hald and dbus are enabled, as is ssh. These are the only packages installed. X is started using startx (with twm) and no xorg.conf. The kernel is a minimal kernel with no devices complied in and no option VESA (see ANKUNGE.config, dmesg, devinfo, pciconf, acpi.) Suspend appears to work (screen turns off, no ping, power light pulses slowly). On resume, the kernel resumes and if iwn is loaded, I can ssh into the machine. The screen does not resume, not even the backlight. (Looking with a flashlight, it doesn't seem to be in any mode.) The X server seems to have exited with error message (see messages, Xorg.0.log), but hald and dbus are still running. Fatal server error: EnterVT failed for screen 0 Using debug.bootverbose and debug.acpi.suspend_bounce leaves the backlight on, but doesn't restore the screen. If I ssh into the machine, the X server seems still be running (see messages_bouce, Xorg.0.log_bounce). Loading acpi_video and acpi_ibm modules into the kernel doesn't change the behavior. Same is true for i915 module. (These modules are reported in the working configuration info on the wiki.) The SuspendResume wiki notes that sdhci must be unloaded. These aren't in my minimal kernel, checked by loading and unloading the module). The old acpi.reset_video=1 option gives kernel panic on resume. With option VESA in the minimal kernel, the machine seems to suspend OK. On resume, the backlight comes on and the wlan indicator blinks a couple of times. Otherwise, the machine is unresponsive to both ping and (blind) keyboard commands. The GENERIC kernel has similar behavior. Thanks for any suggestion -- I really hope it's a configuration error on my part, Laura ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
On 08/27/13 21:54, Adrian Chadd wrote: Hi! Hi Adrian, Can you try 9.0-RELEASE? ANd 9.1-RELEASE? I tried suspend/resume (less systematically) with 9.1-RELEASE and didn't have success. I can build minimal kernels for both 9.1 and 9.0 and will report (probably not tonight). Unfortunately, the SuspendResume wiki isn't completely clear about what build was used - perhaps the folks who reported will be able to clarify. When you get a panic on resume - how do you know that? Can you get a photo of it? The machine seems to suspend (slow pulsing power light). When I resume, the machine reboots and that's the first screen that's visible. I don't find a core in /var/crash and savecore says there isn't one, so it must be a quite hard reset. /var/log/messages has nothing after the ...acpi: suspend at date time other than the new kernel booting. Since the reset_video is deprecated, I'm not sure this is too meaningful. I just tried it because it's required on older systems. Best, Laura -adrian ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
Hi Laura, Am 27.08.2013 22:32, schrieb Laura Marie Feeney: I tried suspend/resume (less systematically) with 9.1-RELEASE and didn't have success. I can build minimal kernels for both 9.1 and 9.0 and will report (probably not tonight). Unfortunately, the SuspendResume wiki isn't completely clear about what build was used - perhaps the folks who reported will be able to clarify. Can you rebuild your kernel without options VESA. This helped to fix suspend/resume for my Thinkpad X121e. Regards, Matthias ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: suspend/resume on Lenovo X1 (regression from reports on wiki)
Laura, On Tue, Aug 27, 2013 at 09:53:18PM +0200, Laura Marie Feeney wrote: L At https://wiki.freebsd.org/SuspendResume, users osa and glebius both L report on Thinkpad Carbon X1. They agree that suspend and resume work L from X (but not console) for '9.0-stable' and 'head' respectively. I am running only head. It is always quite fresh, I upgrade beweekly. I've got Thinkpad X1 Carbon. L Sadly, I can't reproduce this on 9.2-RC2: Under X, resume fails to L restore video. I don't know whether this is a configuration error on my L part, or a regression, or the original reports on the wiki were L misunderstood. (I do reproduce it not working on console.) L L Suggestions are welcome, especially from those who report working L configurations. Details below, log files at L http://www.sics.se/~lmfeeney/9.2-RC2. Please do chmod o+r ~lmfeeney/9.2-RC2/* :) I will respond today later, when I come to job, where my Carbon is right now. -- Totus tuus, Glebius. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
