Re: Attempting to diagnose suspend/resume issue

[John Baldwin]

On Friday, July 10, 2015 04:48:28 PM Eric McCorkle wrote:
> Complete dmesg trace attached
> 
> Correction: it looks like it tries to save the state after the power's
> been turned off.
> 
> Possibly related: the SD card reader started failing to come back up at
> the same patch.

Note that while vga0 is later in the suspend, it is actually more of a dummy
device on isa0.  I think it is sc/vt that actually save/restore the frame
buffer.  Still, can you add a debug printf in bus_generic_suspend_child()
in sys/kern/subr_bus.c to note when DEVICE_SUSPEND() is called for each
device (something like 'device_printf(child, "calling device_suspend()\n");'
above DEVICE_SUSPEND())?

You can also try setting hw.pci.do_power_suspend=0 as a workaround.  If that
fixes it, then I think it lends credence to your suggestion.

Hmm, certainly in the syscons case this is probably just exposing a old bug
in that sc0 is hung off of isa0 which is not going to be in the same part
of the hierarchy as the "real" VGA device.  Usually isa0 is off of isab0
which is often the "last" device on pci0, so normally syscons will suspend
after the VGA device is powered down.

I think vt(4) should in theory do this better, though it might only do so if
you have a drm driver loaded.  When drm is loaded and there is a drm-specific
vt(4) backend, then it will be suspended as part of the tree under the real
VGA device.

-- 
John Baldwin
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Attempting to diagnose suspend/resume issue

[Eric McCorkle]

Complete dmesg trace attached

Correction: it looks like it tries to save the state after the power's
been turned off.

Possibly related: the SD card reader started failing to come back up at
the same patch.

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  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
>>
Copyright (c) 1992-2014 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-CURRENT #9 r274397: Thu Jul  9 14:27:57 EDT 2015
root@atom-edge:/usr/obj/usr/src/sys/CUSTOM amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
CPU: Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz (2394.51-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306c3  Family=0x6  Model=0x3c  Stepping=3
  
Features=0xbfebfbff
  
Features2=0x7fdafbbf,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
  AMD Features=0x2c100800
  AMD Features2=0x21
  Structured Extended 
Features=0x27ab
  XSAVE Features=0x1
  VT-x: (disabled in BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 7824838656 (7462 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
 cpu4 (AP): APIC ID:  4
 cpu5 (AP): APIC ID:  5
 cpu6 (AP): APIC ID:  6
 cpu7 (AP): APIC ID:  7
ioapic0  irqs 0-23 on motherboard
random: entropy device infrastructure driver
random: selecting highest priority adaptor 
kbd1 at kbdmux0
random: SOFT: yarrow init()
random: selecting highest priority adaptor 
random: live provider: "Intel Secure Key RNG"
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi_ec0:  port 0x62,0x66 on acpi0
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 7f90 (3) failed
cpu0:  on acpi0
cpu1:  on acpi0
cpu2:  on acpi0
cpu3:  on acpi0
cpu4:  on acpi0
cpu5:  on acpi0
cpu6:  on acpi0
cpu7:  on acpi0
attimer0:  port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 550
atrtc0:  port 0x70-0x71 irq 8 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
acpi_lid0: 

Re: Attempting to diagnose suspend/resume issue

[Adrian Chadd]

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  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-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"