Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 Jul 2015 11:10:30 -0700
From:      Adrian Chadd <adrian.chadd@gmail.com>
To:        Eric McCorkle <eric@metricspace.net>
Cc:        "freebsd-mobile@freebsd.org" <freebsd-mobile@freebsd.org>,  "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org>
Subject:   Re: Attempting to diagnose suspend/resume issue
Message-ID:  <CAJ-Vmo=TTbBDfkJXeU%2Bbmtx99YxWpNkGcSgc37EpdYoz4us2jw@mail.gmail.com>
In-Reply-To: <559F4B70.8060402@metricspace.net>
References:  <559F4B70.8060402@metricspace.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <eric@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
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=TTbBDfkJXeU%2Bbmtx99YxWpNkGcSgc37EpdYoz4us2jw>