vt does not resume properly after zzz

[Kevin Oberman]

On Thu, Oct 2, 2014 at 1:52 PM, <marekrud at gmail.com> wrote:

> Kevin Oberman <rkoberman at gmail.com> writes:
>
> > On Mon, Sep 29, 2014 at 1:20 PM, <marekrud at gmail.com> wrote:
> >
> >> Hi all,
> >>
> >> I have configured vt by adding `kern.vty=vt' to /boot/loader.conf.
> >>
> >> After suspending the system using zzz and resuming, I can only see black
> >> screen.  The system seem to be running, but the display is off.  I was
> >> able to reproduce it on two different computers running 10.1-BETA2 and
> >> 10.1-BETA3.
> >>
> >> Is there a simple way to fix it?  Should I report it to Bugzilla?
> >>
> >> Thank you for help!
> >>
> >> Marek
> >>
> >
> > Since it works fine for me and, I presume, for many others, a bit more
> > information would help.
> >
> > 1. Does syscons work after resume?
>
> Yes.
>
>
> > 2. Does the system run a graphics interface or is it text only? If so,
> does
> > the problem show up in both modes?
>
> In the default graphical mode (hw.vga.textmode not set), the display
> seem to be off.
>
> If I set hw.vga.textmode=1, then I get kernel panic right after calling
> zzz.
>
>
Sorry. I guess I was unclear in my question. I was asking whether you were
just running with a textual display (vt, syscons, or VGA text mode) or
using an X-based graphical desktop. I am quite surprised to see the panic
on suspend with hw.vga.textmode=1, though. I don't think I've ever tried
suspending when I had this set. Still, it i almost certainly unrelated to
your problem.


> > 3. WITH_NEW_XORG? (I am pretty sure it is, but confirmation would be
> good.)
>
> I'm not sure, where to check it.  I did not modify it, so should be the
> default from 10.1-BETA.
>
> This used to be easy. If make.conf had WITH_NEW_XORG defined, you had it.
Now it has been made default. Take a look at /usr/ports/Mk/mk.port.mk for
the revision in the $FreeBSD line. If it is >= 369693, NEW_XORG is the
default. You can force this by defining  WITH_NEW_XORG or WITHOUT_NEW_XORG
in /etc/make.conf.
"cat WITHOUT_NEW_XORG=YES > /etc/make.conf" or "cat WITH_NEW_XORG=YES >
/etc/make.conf".
If you change this, you need to rebuild your x11-servers/xorg-server,
xorg-drivers graphics/dri, graphics/libdrm, graphics/libEGL,
graphics/libGL, graphics/libglapi and graphics/libglesv2 ports. You may not
have all of them.


> > 4. What driver?
>
> The default, probably vesa (?)
>

If you're running X, it should be in /var/log/Xorg.0.log.


>
> > 5. What graphics system?
> > 6. What type of system? (This stuff is tied closely to BIOS, so exact
> > hardware is significant.)
>
> Both are laptops:
>
>  - Lenovo with Radeon HD 8240 (I think, this card is unsupported by the
>    ati driver)
>

As far as I know, the 8000 series is, indeed, unsupported by the ATI
driver. So it will use VESA. 8000 support should be in the next update of
the ATI  KMS bits, but it will be a while, again as far as I know.


>  - DELL M1330 with Intel graphics card (Xorg used to work with intel
>    driver


All of the information I can find says that this unit has nVidia graphics,
but Intel may be a low-priced option, as well. Again, /var/log/Xorg.0.log
should have this information as should "pciconf -lv | grep -A3 vga". This
laptop goes back to 2007, so it should be using the old UMS Intel graphics.
It should not be using VESA, but if it is, that might point out a common
thread.

I don't know the details and the actual problem was never identified, but I
know that some systems needed to have a kernel built with "NOOPTION VESA"
to get it to resume. I had this problem on my Lenovo T520 (which I am using
to send this reply).


> > 7. Contents of /etc/make.conf, /etc/src.conf, /boot/loader.conf, and
> > /etc/sysctl.conf
>
>
> /boot/loader.conf:
>
> geom_eli_load="YES"
> geli_ada0p3_keyfile0_load="YES"
> geli_ada0p3_keyfile0_type="ada0p3:geli_keyfile0"
> geli_ada0p3_keyfile0_name="ZZZ"
>
> zfs_load="YES"
> vfs.root.mountfrom="zfs:zroot"
>
> kern.vty=vt
>
>
>
>
> /etc/sysctl.conf
>
> kern.coredump=0
>
>
>
> /etc/make.conf, /etc/src.conf don't exist.
>

Nothing interesting here.


>
>
>
> > 8. Contents of messages log at the time of the suspend and resume
>
> Oct  2 22:43:51 thinkpad devd: Executing '/etc/rc.suspend acpi 0x03'
> Oct  2 22:43:51 thinkpad acpi: suspend at 20141002 22:43:51
> Oct  2 22:43:55 thinkpad kernel: uhub0: at usbus0, port 1, addr 1
> (disconnected)
> Oct  2 22:43:55 thinkpad kernel: uhub2: at usbus1, port 1, addr 1
> (disconnected)
> Oct  2 22:44:06 thinkpad kernel: uhub1: at usbus2, port 1, addr 1
> (disconnected)
> Oct  2 22:44:06 thinkpad kernel: uhub3: at usbus3, port 1, addr 1
> (disconnected)
> Oct  2 22:44:06 thinkpad kernel: uhub4: at usbus4, port 1, addr 1
> (disconnected)
> Oct  2 22:44:06 thinkpad kernel: ugen4.2: <Vimicro corp.> at usbus4
> (disconnected)
> Oct  2 22:44:06 thinkpad kernel: acpi0: cleared fixed power button status
> Oct  2 22:44:06 thinkpad kernel: ACPI Error: No handler or method for
> GPE02, disabling event (20130823/evgpe-840)
> Oct  2 22:44:06 thinkpad kernel: re0: link state changed to DOWN
> Oct  2 22:44:06 thinkpad kernel: xhci0: 32 byte context size.
> Oct  2 22:44:06 thinkpad kernel: uhub0: <AMD EHCI root HUB, class 9/0, rev
> 2.00/1.00, addr 1> on usbus4
> Oct  2 22:44:06 thinkpad kernel: uhub1: <AMD EHCI root HUB, class 9/0, rev
> 2.00/1.00, addr 1> on usbus2
> Oct  2 22:44:06 thinkpad kernel: uhub2: <0x1022 XHCI root HUB, class 9/0,
> rev 3.00/1.00, addr 1> on usbus0
> Oct  2 22:44:06 thinkpad kernel: uhub3: <AMD OHCI root HUB, class 9/0, rev
> 1.00/1.00, addr 1> on usbus1
> Oct  2 22:44:06 thinkpad kernel: uhub4: <AMD OHCI root HUB, class 9/0, rev
> 1.00/1.00, addr 1> on usbus3
> Oct  2 22:44:06 thinkpad kernel: uhub2: 4 ports with 4 removable, self
> powered
> Oct  2 22:44:06 thinkpad kernel: uhub3: 4 ports with 4 removable, self
> powered
> Oct  2 22:44:06 thinkpad kernel: uhub4: 4 ports with 4 removable, self
> powered
> Oct  2 22:44:06 thinkpad devd: Executing '/etc/rc.resume acpi 0x03'
> Oct  2 22:44:06 thinkpad acpi: resumed at 20141002 22:44:06
> Oct  2 22:44:06 thinkpad kernel: re0: link state changed to UP
> Oct  2 22:44:06 thinkpad devd: Executing '/etc/rc.d/dhclient quietstart
> re0'
> Oct  2 22:44:07 thinkpad kernel: uhub0: 4 ports with 4 removable, self
> powered
> Oct  2 22:44:07 thinkpad kernel: uhub1: 4 ports with 4 removable, self
> powered
> Oct  2 22:44:07 thinkpad dhclient: New IP Address (re0): ZZZ
> Oct  2 22:44:07 thinkpad dhclient: New Subnet Mask (re0): ZZZ
> Oct  2 22:44:07 thinkpad dhclient: New Broadcast Address (re0): ZZZ
> Oct  2 22:44:07 thinkpad dhclient: New Routers (re0): ZZZ
> Oct  2 22:44:08 thinkpad kernel: ugen4.2: <Vimicro corp.> at usbus4
> Oct  2 22:44:08 thinkpad devd: Executing '/usr/local/etc/rc.d/webcamd
> start ugen4.2'
> Oct  2 22:44:08 thinkpad devd: Executing '/usr/local/etc/rc.d/webcamd
> start ugen4.2'
> Oct  2 22:44:08 thinkpad devd: Executing 'logger Unknown USB device:
> vendor 0x5986 product 0x0299 bus uhub0'
> Oct  2 22:44:09 thinkpad root: Unknown USB device: vendor 0x5986 product
> 0x0299 bus uhub0
> Oct  2 22:44:09 thinkpad devd: Executing 'logger Unknown USB device:
> vendor 0x5986 product 0x0299 bus uhub0'
> Oct  2 22:44:09 thinkpad root: Unknown USB device: vendor 0x5986 product
> 0x0299 bus uhub0
> Oct  2 22:44:09 thinkpad devd: Executing 'logger Unknown USB device:
> vendor 0x5986 product 0x0299 bus uhub0'
> Oct  2 22:44:09 thinkpad root: Unknown USB device: vendor 0x5986 product
> 0x0299 bus uhub0
>
>
>
> > 9. If not using GENERIC, your configuration file.
>
> Yes
>
>
> > 10. After the resume, is the system accessible over the network?
>
> Yes
>
>
> > 11. Is the display working but the backlight not on? Try looking at the
> > screen in bright light and see if you can see anything on the screen
>
> The display looks really off.
>
>
> > I'm probably missing a few things, but those will at least help narrow it
> > down.
>
> Thank you!  I'll be glad for any further feedback.
>
>
> Marek
>
>
>
> > --
> > R. Kevin Oberman, Network Engineer, Retired
> > E-mail: rkoberman at gmail.com
>