David Wolfskill
2021-03-28 16:31:36 UTC
I am trying to get a laptop running stable/13 working at least as
well as it does under stable/12. At the moment, stable/13 has the
advantage that the mouse works (under stable/12, it does not), but
the "resume" part of "suspend/resume" works under stable/12, but
does not under stable/13.
For the specific points at which the behaviors are noted, here are
the uname strings in question, for reference:
FreeBSD g1-48.catwhisker.org 12.2-STABLE FreeBSD 12.2-STABLE #985 stable/12-n232904-6008a5fad3c: Sun Mar 28 03:33:20 PDT 2021 ***@g1-48.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY amd64 1202505 1202505
FreeBSD g1-48.catwhisker.org 13.0-STABLE FreeBSD 13.0-STABLE #182 stable/13-n245050-c7d10e7ec872: Sun Mar 28 04:27:46 PDT 2021 ***@g1-48.catwhisker.org:/common/S3/obj/usr/src/amd64.amd64/sys/CANARY amd64 1300500 1300500
As I mention behavior under head, as well:
FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #191 main-n245702-1c1ff7979571: Sun Mar 28 04:02:23 PDT 2021 ***@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1400006 1400006
For each of the environments, /etc/src.conf contains:
PORTS_MODULES+=x11/nvidia-driver
and the x11/nvidia-driver modules are rebuilt whenever the kernel is.
* Under stable/12, the machine is normally run with
kern.vty="sc"
in /boot/loader.conf and (as noted) suspend/resume Just Works
nearly all the time (based on my experiences with an older laptop
that is similarly configured -- from back when I was still commuting
to work, and thus had occasion to exercise the suspend/resume
code). I note that this machine (Dell Precision 7520) does not
cause any lights that I can see to "blink" while suspended --
unlike the Dell Precision M4800.
A few minutes ago, I commented that line in /boot/loader.conf out
and rebooted the machine and re-tested suspend/resume. I was
gratified to note that suspend/resume still worked, even with vt.
X11 worked, of course, but vtys are ... not useful for displaying
human-readable information. (It looks like some wildly-colored
character-cell-sized boxes.) I switched it back to sc.
* Under stable/13, after the recent work in loader by tsoome@, I had
switched to letting vty default to vt (just before stable/13 was
branched, IIRC).
Thus, recalling some earlier issues where vt appeared to be
implicated in failure of "resume" to (re-?)initialize the video
display, I had thought that the use of vt (vs. sc) might be at
the root of the failure to resume for stable/13 (and head).
However, an experiment showed that after an attempted resume,
which casued the power light to come back on (while the screen
stayed dark and the machine remained unresponsive to anything but
the power button -- well, I suppose unplugging it and removing
the battery would probably have caused a reaction, as well, but
that's a bit extreme -- I was unable to do as much as ping the
machine from another one.
That seems to me to indicate something rather more profound than
"video did not re-initialize."
* Unsurprisingly, behavior under head is as described above for
stable/13.
How might I proceed to get the above resolved?
While I use the M4800 quite heavily, the 7520 spends most of its time
powered off, so making use of it seems like a Good Idea. :-)
I have dumped some files from the machine at
http://www.catwhisker.org/~david/FreeBSD/suspend_resume/; I am happy to
supplement those.
Peace,
david
well as it does under stable/12. At the moment, stable/13 has the
advantage that the mouse works (under stable/12, it does not), but
the "resume" part of "suspend/resume" works under stable/12, but
does not under stable/13.
For the specific points at which the behaviors are noted, here are
the uname strings in question, for reference:
FreeBSD g1-48.catwhisker.org 12.2-STABLE FreeBSD 12.2-STABLE #985 stable/12-n232904-6008a5fad3c: Sun Mar 28 03:33:20 PDT 2021 ***@g1-48.catwhisker.org:/common/S1/obj/usr/src/amd64.amd64/sys/CANARY amd64 1202505 1202505
FreeBSD g1-48.catwhisker.org 13.0-STABLE FreeBSD 13.0-STABLE #182 stable/13-n245050-c7d10e7ec872: Sun Mar 28 04:27:46 PDT 2021 ***@g1-48.catwhisker.org:/common/S3/obj/usr/src/amd64.amd64/sys/CANARY amd64 1300500 1300500
As I mention behavior under head, as well:
FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #191 main-n245702-1c1ff7979571: Sun Mar 28 04:02:23 PDT 2021 ***@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1400006 1400006
For each of the environments, /etc/src.conf contains:
PORTS_MODULES+=x11/nvidia-driver
and the x11/nvidia-driver modules are rebuilt whenever the kernel is.
* Under stable/12, the machine is normally run with
kern.vty="sc"
in /boot/loader.conf and (as noted) suspend/resume Just Works
nearly all the time (based on my experiences with an older laptop
that is similarly configured -- from back when I was still commuting
to work, and thus had occasion to exercise the suspend/resume
code). I note that this machine (Dell Precision 7520) does not
cause any lights that I can see to "blink" while suspended --
unlike the Dell Precision M4800.
A few minutes ago, I commented that line in /boot/loader.conf out
and rebooted the machine and re-tested suspend/resume. I was
gratified to note that suspend/resume still worked, even with vt.
X11 worked, of course, but vtys are ... not useful for displaying
human-readable information. (It looks like some wildly-colored
character-cell-sized boxes.) I switched it back to sc.
* Under stable/13, after the recent work in loader by tsoome@, I had
switched to letting vty default to vt (just before stable/13 was
branched, IIRC).
Thus, recalling some earlier issues where vt appeared to be
implicated in failure of "resume" to (re-?)initialize the video
display, I had thought that the use of vt (vs. sc) might be at
the root of the failure to resume for stable/13 (and head).
However, an experiment showed that after an attempted resume,
which casued the power light to come back on (while the screen
stayed dark and the machine remained unresponsive to anything but
the power button -- well, I suppose unplugging it and removing
the battery would probably have caused a reaction, as well, but
that's a bit extreme -- I was unable to do as much as ping the
machine from another one.
That seems to me to indicate something rather more profound than
"video did not re-initialize."
* Unsurprisingly, behavior under head is as described above for
stable/13.
How might I proceed to get the above resolved?
While I use the M4800 quite heavily, the 7520 spends most of its time
powered off, so making use of it seems like a Good Idea. :-)
I have dumped some files from the machine at
http://www.catwhisker.org/~david/FreeBSD/suspend_resume/; I am happy to
supplement those.
Peace,
david
--
David H. Wolfskill ***@catwhisker.org
Describing the 6 Jan 2021 Capitol insurrection as "hugging and kissing
the police and the guards, you know, they had great relationships" is
what I'd expect from someone who conflates affection with sexual assault.
See https://www.catwhisker.org/~david/publickey.gpg for my public key.
David H. Wolfskill ***@catwhisker.org
Describing the 6 Jan 2021 Capitol insurrection as "hugging and kissing
the police and the guards, you know, they had great relationships" is
what I'd expect from someone who conflates affection with sexual assault.
See https://www.catwhisker.org/~david/publickey.gpg for my public key.