Re: Attempting to diagnose suspend/resume issue

[Eric McCorkle]

Here is the output from before the problematic patch (ie. when the
screen worked with suspend/resume).

A couple of things:

* It looks like the card is getting powered down twice.
* It looks like the video state is saved after attempting to set the
power state the first time. So that probably isn't the problem

So the code that saves the card state is failing mysteriously after
274386. I doubt this is the fault of the ACPI changes that patch made.
Add to that the fact that the efifb and vga text mode suspends
apparently never worked, and I'd say it's probably something in the card
state save/restore code.

So I guess I'll go poke around in that code for a while and see what I
can find.

On 07/10/2015 02:10 PM, Adrian Chadd wrote:
> Hi,
>
> can you post some more debugging showing that the VGA driver is
> restoring the VGA state before the power is applied?
>
> Thanks!
>
>
> -a
>
>
> On 9 July 2015 at 21:34, Eric McCorkle <er...@metricspace.net> wrote:
>> A long while ago, I reported my screen not coming back on after resume,
>> shortly after r274386 went in. Unfortunately, the follow-on patch
>> didn't seem to work for me.
>>
>> (r274386 changed the way devices get powered down/up, and r274397 fixed
>> a typo in r274386 that tried to power down/up the wrong devices.)
>>
>> I finally found the time to try and track this thing down, and I got
>> some information that might prove useful in tracking it down.
>>
>>
>> * The screen comes back up only for syscons in pixel mode up to r274835.
>> As far as I can tell, it doesn't work for vt in any revision (not as
>> sure about text-mode syscons, but there is at least one revision where
>> it works for pixel mode, but not text mode)
>>
>> * Comparing logs from r274385 and r274397, it seems the likely cause is
>> that the changes in r274386 reordered things so that the VGA driver
>> attempts to restore the state of the card before its power has been
>> turned back on (you can clearly see this happening, and you can see the
>> attempt to restore the state failing).
>>
>> * Suspend/resume works fine in Linux (I'm not sure how to get linux to
>> printout a debug trace similar to debug.bootverbose), so the hardware
>> can't be /that/ broken.
>>
>> * The order in which things happen during resume seems to be different
>> between vt and syscons resumes, though I can't tell where vt restores
>> the state of the card (or the efifb device)
>>
>> My guess as to the likely cause is that vt also tries to restore the
>> state of the card before its power has been turned back on similar to
>> what syscons does after r274386, or else the dual happens during suspend
>> (it tries to save the state after the device is powered down). It does
>> seem a little wierd that syscons would behave differently in that
>> respect for pixel mode vs text mode, though.
>>
>> I'm open to suggestions as to what to look at next, or theories as to
>> what might be the culprit. I also have dmesg logs for the various
>> revisions and drivers.
>>
>> Best,
>> Eric
>>
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
> To unsubscribe, send any mail to "freebsd-mobil...@freebsd.org"
>