Re: Re: Thinkpad T410: resume broken

On 05/17/2014 14:20, John Baldwin wrote:
> On 5/16/14, 2:10 PM, Kevin Oberman wrote:
>> On Fri, May 16, 2014 at 10:44 AM, Adrian Chadd <adrian_at_freebsd.org> wrote:
>>
>>> Hi!
>>>
>>> I wonder what changed between 9.2-RELEASE and 10.0-RELEASE.
>>>
>>> Please poke me about this next week. I'm busy this week with work and
>>> maker faire but I will try to help you later.
>>>
>>> (It's possible something like ACPI updates or a driver update has
>>> broken things.)
>>>
>>>
>>> -a
>>>
>>
>> Does your kernel include VESA? My T320 behaved as you describe until I
>> removed VESA from my kernel. I think using vt may also fix this without the
>> need to remove VESA, bug I have not gotten around to confirming this.
> 
> To be clear, vt does not fix resume.  Using i915kms is what actually
> fixes resume when using Intel GPUs on the Thinkpad as i915kms is what
> actually turns the LCD backlight on during resume.  You just have to use
> vt to have a useable console when you use i915kms.  You can
> suspend/resume fine in X with syscons + i915kms, you just can't use your
> console if you do.
> 
> If you are using the Nvidia GPU, then i915kms can't help you with
> turning the LCD backlight back on (and using vt shouldn't make any
> difference).  VESA needs to be removed for i915kms, but I've no idea if
> it needs to be removed for Nvidia.  The video reset code was reworked in
> 10 so that having VESA is supposed to be like using
> 'hw.acpi.reset_video=1' on 9, but in theory it works more often.  The
> ACPI_PM setting to the kernel module along with removing VESA would seem
> like your best bet, but I see in follow-ups that that wasn't completely
> reliable.  However, you can try using ACPI_PM with syscons, no need to
> use vt.

Yes, without VESA, resume seems much more reliable on 10.0-RELEASE/amd64
with Nvidia: With a generic kernel, I put vesa_load="YES" in
/boot/loader.conf to be able to kldunload vesa later. With that, I just
had four successful suspend-and-resume cycles.

Unfortunately, my USB mouse does not work anymore: After the first
resume, it took a few seconds until it worked again (the build in
touchpad was back immediately). After the second resume, it would not
work anymore at all, even after reconnecting it to a different EHCI
port. It does work at a XHCI, though, until the next resume. Anyhow,
this is obviously not related to the original problem.

Cheers,
Jan Henrik