ACPI error messages on Lenovo W540

[Eric McCorkle]

Hello,

I'm trying to set up on a lenovo W540 mobile workstation I recently 
purchased.  Things work well for the most part (including 
suspend/resume), however there's some error messages that I suspect are 
at the root of why the nvidia Xorg driver doesn't work, and possibly 
also at the root of why USB 3.0 won't work either.


At suspend/resume, the following error messages show up:

pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_:
AE_BAD_PARAMETER
pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1:
AE_BAD_PARAMETER
pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2:
AE_BAD_PARAMETER
pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP3:
AE_BAD_PARAMETER
pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5:
AE_BAD_PARAMETER

I suspect these might have something to do with the USB 3.0 system not 
working, though I don't have experience with either the ACPI or USB 
subsystems.


Also, the nvidia Xorg driver fails to work, and causes a similar error 
message:


ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch -
Found [Buffer], APCI requires [Package] (20130823/nsarguments-97)
(the same message gets repeated about 10 times)

Again, I don't have any experience with ACPI, but this looks to me like 
a vendor-specific quirk.


Any advice on how to go about fixing/working around this?


Thanks,
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

Re: ACPI error messages on Lenovo W540

[Eric McCorkle]

Yes it does.  The messages may not be related at all; it's just a suspicion.

I am more certain, however, that there's an issue preventing the nvidia driver 
from working.

 On Jun 17, 2014, at 10:16 AM, Hans Petter Selasky h...@selasky.org wrote:
 
 On 06/17/14 15:54, Eric McCorkle wrote:
 I suspect these might have something to do with the USB 3.0 system not
 working, though I don't have experience with either the ACPI or USB
 subsystems.
 
 Regarding USB 3.0, does pciconf -lv list xhci?
 
 --HPS
___
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: ACPI error messages on Lenovo W540

[Eric McCorkle]

On 06/18/2014 03:17, Ian Smith wrote:

On Tue, 17 Jun 2014 09:54:57 -0400, Eric McCorkle wrote:

   I'm trying to set up on a lenovo W540 mobile workstation I recently
   purchased.  Things work well for the most part (including suspend/resume),
   however there's some error messages that I suspect are at the root of why 
the
   nvidia Xorg driver doesn't work, and possibly also at the root of why USB 
3.0
   won't work either.
  
   At suspend/resume, the following error messages show up:
  
   pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_:
   AE_BAD_PARAMETER
   pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1:
   AE_BAD_PARAMETER
   pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2:
   AE_BAD_PARAMETER
   pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP3:
   AE_BAD_PARAMETER
   pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5:
   AE_BAD_PARAMETER
  
   I suspect these might have something to do with the USB 3.0 system not
   working, though I don't have experience with either the ACPI or USB
   subsystems.
  
   Also, the nvidia Xorg driver fails to work, and causes a similar error
   message:
  
   ACPI Warning: \134_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch -
   Found [Buffer], APCI requires [Package] (20130823/nsarguments-97)
   (the same message gets repeated about 10 times)
  
   Again, I don't have any experience with ACPI, but this looks to me like a
   vendor-specific quirk.
  
   Any advice on how to go about fixing/working around this?

Hi Eric,

I refer you to freebsd-mobile@ archives for May re these 'failed to set
ACPI power state D2' messages, in thread 'Thinkpad T410: resume broken'.
I'm also cross-posting this back there.


I ran across those also.


These appear on the suspend path on (AFAICT) all modern Lenovos; X2xx,
T4xx and T5xx at least, though I get similar messages for the Cardbus
bridges on my old T23s.  The EXPn messages at least do appear to be
harmless though they keep causing your sort of concern, and it would be
good in the long run to find out why attempts are being made to set
state D2 on devices that (should indicate that they) don't support it.

John Baldwin (cc'd) explains in that thread that the EXPn devices are
probably PCI-PCI bridges that represent the downstream ports of your
PCI-e root complex) though I can't say I understand what that means ..
with verbose boot messages you may also see that these are initialised
back into D0 state twice, unlike the other devices.


Whatever they do, the messages suggest that it might just be what 
amounts to a type error in the ACPI code (apologies for any 
inaccuracies; I have only cursory knowledge of ACPI, but I know there's 
some kind of interpreted language in there somewhere).


Again, sorry for lack of knowledge, but does FreeBSD have any sort of 
functionality for working around these sort of vendor quirks?




The PEG_ message seems to appear on the more recent ones with integrated
graphics.  I don't know if that message represents a problem or not,
though the later warnings re \134_SB_.PCI0.PEG_.VID_._DSM seem ominous.


Some poking around on google seems to show other lenovos (the T440p) 
having similar problems with the nvidia drivers.


I suppose a worthwhile experiment might be to remove ACPI from the 
kernel and see if the driver works successfully.  If the driver issues 
persist, I'm not sure what to do other than contact nvidia directly.


If it does work, however, that suggests digging into the ACPI stuff on 
the lenovo as a possible way forward.  I'd be willing to try, and again, 
the messages suggest it's a relatively simple programming error 
somewhere in the Lenovo ACPI stuff.



It would be good to know if your USB3 issues are connected to the more
generic issue all these Lenovos appear to have of USB failing entirely,
only on the external ports, after - depending on model - one or two
suspend/resume cycles.  There's not even any 5V on these ports, whether
or not the BIOS has been set to provide 5V on these ports in suspend or
power-off states.  Does that also happen on yours?


The apparent connection to the USB issues seems likely to be a red 
herring at this point.  The messages show up near some USB error 
messages, but that seems to just be luck.


I found some other threads about USB 3.0 issues, but in general, USB 
seems to work.  There were serious issues when I first installed, but 
after an update and a kernel compile, they went away.  I can mount a 
thumb drive and my phone starts charging if I plug it in.  There's still 
an error message, but honestly, I'm more interested in getting the 
nvidia driver working at this point.

___
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: ACPI error messages on Lenovo W540

[Eric McCorkle]

Finally got time to do some more poking around regarding this.  I 
haven't read the entire ACPI spec, so bear with me...


As John Baldwin said, the wrapper nvidia_acpi.c passes in a buffer 
instead of a package.  In the definition for _DSM, you can see calls to 
NVOP, NVPS, and NBCI.  I looked at all three, and they seem to treat 
Arg3 as a buffer as well (they call CreateField on it, which according 
to the ACPI spec, should take a buffer argument).


So it looks like both the nvidia driver as well as the ALS code are 
pretty thoroughly convinced that Arg3 (the fourth arg) is a buffer 
instead of a package, despite what the spec says about what it should be.


Could this possibly be fixed by adding some kind of quirk to the ACPI 
execution engine that says _DSM's fourth argument is a buffer?


On 06/24/2014 20:51, Eric McCorkle wrote:


It looks like this is the definition:

 Method (_DSM, 4, NotSerialized)  // _DSM:
Device-Specific Method
 {
 If (\CMPB (Arg0, Buffer (0x10)
 {
 /*  */   0xF8, 0xD8, 0x86,
0xA4, 0xDA, 0x0B, 0x1B, 0x47,
 /* 0008 */   0xA7, 0x2B, 0x60,
0x42, 0xA6, 0xB5, 0xBE, 0xE0
 }))
 {
 Return (NVOP (Arg0, Arg1, Arg2, Arg3))
 }

 If (\CMPB (Arg0, Buffer (0x10)
 {
 /*  */   0x01, 0x2D, 0x13,
0xA3, 0xDA, 0x8C, 0xBA, 0x49,
 /* 0008 */   0xA5, 0x2E, 0xBC,
0x9D, 0x46, 0xDF, 0x6B, 0x81
 }))
 {
 Return (NVPS (Arg0, Arg1, Arg2, Arg3))
 }

 If (\WIN8)
 {
 If (\CMPB (Arg0, Buffer (0x10)
 {
 /*  */   0x75, 0x0B, 0xA5,
0xD4, 0xC7, 0x65, 0xF7, 0x46,
 /* 0008 */   0xBF, 0xB7, 0x41,
0x51, 0x4C, 0xEA, 0x02, 0x44
 }))
 {
 Return (NBCI (Arg0, Arg1, Arg2, Arg3))
 }
 }

 Return (Buffer (0x04)
 {
  0x01, 0x00, 0x00, 0x80
 })
 }

Not sure if that's helpful at all...


Ah, the nvidia driver calls _DSM and it has the bug.  In its
nvidia_acpi.c file
it uses a Buffer instead of a Package for the fourth argument to
_DSM.  OTOH, the
warning doesn't prevent the method from running, so the warning may be
harmless.
You can try contacting the nvidia folks to tell them about the warning
and point
out the bug in their _DSM wrapper in nvidia_acpi.c to see what they say.


Will do.  Is there a preferred point of contact?

___
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: ACPI error messages on Lenovo W540

[Eric McCorkle]

Actually, I managed to get a kernel panic to happen, which provides some 
more information:


NVRM: GPU at :01:00.0 has fallen off the bus.
NVRM: RmInitAdapter failed! (0x25:0x28:1169)
nvidia0: NVRM: rm_init_adapter() failed!


Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address   = 0x8
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x817eeeb5
stack pointer   = 0x28:0xfe021d481420
frame pointer   = 0x28:0xfe021d481500
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 3
current process = 73254 (Xorg)
trap number = 12
panic: page fault
cpuid = 2
Uptime: 12h17m8s

It looks like rm_init_adapter is contained in nvidia's .o file that 
comes with the driver, so I'm out of luck for trying to track it down. 
I can't tell whether this is caused by the ACPI errors or not...


On 08/17/2014 08:31, Eric McCorkle wrote:

Finally got time to do some more poking around regarding this.  I
haven't read the entire ACPI spec, so bear with me...

As John Baldwin said, the wrapper nvidia_acpi.c passes in a buffer
instead of a package.  In the definition for _DSM, you can see calls to
NVOP, NVPS, and NBCI.  I looked at all three, and they seem to treat
Arg3 as a buffer as well (they call CreateField on it, which according
to the ACPI spec, should take a buffer argument).

So it looks like both the nvidia driver as well as the ALS code are
pretty thoroughly convinced that Arg3 (the fourth arg) is a buffer
instead of a package, despite what the spec says about what it should be.

Could this possibly be fixed by adding some kind of quirk to the ACPI
execution engine that says _DSM's fourth argument is a buffer?

On 06/24/2014 20:51, Eric McCorkle wrote:


It looks like this is the definition:

 Method (_DSM, 4, NotSerialized)  // _DSM:
Device-Specific Method
 {
 If (\CMPB (Arg0, Buffer (0x10)
 {
 /*  */   0xF8, 0xD8, 0x86,
0xA4, 0xDA, 0x0B, 0x1B, 0x47,
 /* 0008 */   0xA7, 0x2B, 0x60,
0x42, 0xA6, 0xB5, 0xBE, 0xE0
 }))
 {
 Return (NVOP (Arg0, Arg1, Arg2, Arg3))
 }

 If (\CMPB (Arg0, Buffer (0x10)
 {
 /*  */   0x01, 0x2D, 0x13,
0xA3, 0xDA, 0x8C, 0xBA, 0x49,
 /* 0008 */   0xA5, 0x2E, 0xBC,
0x9D, 0x46, 0xDF, 0x6B, 0x81
 }))
 {
 Return (NVPS (Arg0, Arg1, Arg2, Arg3))
 }

 If (\WIN8)
 {
 If (\CMPB (Arg0, Buffer (0x10)
 {
 /*  */   0x75, 0x0B, 0xA5,
0xD4, 0xC7, 0x65, 0xF7, 0x46,
 /* 0008 */   0xBF, 0xB7, 0x41,
0x51, 0x4C, 0xEA, 0x02, 0x44
 }))
 {
 Return (NBCI (Arg0, Arg1, Arg2, Arg3))
 }
 }

 Return (Buffer (0x04)
 {
  0x01, 0x00, 0x00, 0x80
 })
 }

Not sure if that's helpful at all...


Ah, the nvidia driver calls _DSM and it has the bug.  In its
nvidia_acpi.c file
it uses a Buffer instead of a Package for the fourth argument to
_DSM.  OTOH, the
warning doesn't prevent the method from running, so the warning may be
harmless.
You can try contacting the nvidia folks to tell them about the warning
and point
out the bug in their _DSM wrapper in nvidia_acpi.c to see what they say.


Will do.  Is there a preferred point of contact?

___
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

___
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

ACPI debug messages

[Eric McCorkle]

Hello,

I decided to try tracing through the evaluation of the DSM method in 
order to track down where the graphics driver failure I mentioned 
earlier is coming from.


However, it looks like there's already an extensive debug logging system 
in place in the acpica system.


Can this be controlled from user space (presumably through sysctls), or 
does it need to be compiled in?

___
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: ACPI debug messages

[Eric McCorkle]

Thanks.

I turned on maximum logging, tried starting X, and walked through the 
traces.  I think I can definitely rule out the ACPI error messages as 
being relevant at this point.  The argument type check fails, but the 
methods all execute normally.


The actual issue seems to be optimus-related instead.  Thanks for all 
the help, though.


On 10/12/2014 07:14, Ian Smith wrote:

On Sat, 11 Oct 2014 14:10:07 -0400, Eric McCorkle wrote:
   Hello,
  
   I decided to try tracing through the evaluation of the DSM method in order 
to
   track down where the graphics driver failure I mentioned earlier is coming
   from.
  
   However, it looks like there's already an extensive debug logging system in
   place in the acpica system.
  
   Can this be controlled from user space (presumably through sysctls), or does
   it need to be compiled in?

It's all in acpi(4), and in the Handbook in the nowadays rather
poorly-named Power and Resource Management at section 12.13.4:
http://www.freebsd.org/doc/handbook/acpi-overview.html

You can add it to your kernel, but I think acpi is now always loaded as
a module, therefore you just need to rebuild the module, as described.

cheers, Ian


___
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

Lenovo W540 blank screen on suspend/resume after update

[Eric McCorkle]

Hello,

I updated my kernel and userland with a fresh update from 11 yesterday, 
and I'm now seeing a blank screen after suspend/resume, where it was 
working fine previously.


I had been trying out the new vt console, so I switched back to sc, but 
the blank screen is still there.


Sorry, I don't have any information beyond this (quite busy these days).

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

Re: Lenovo W540 blank screen on suspend/resume after update

[Eric McCorkle]

Sorry, don't remember the working version.

I have acpi_video compiled in to my kernel. I've tried it with both vt and sc 
and gotten the same result. 

Might try to do more diagnostics this weekend. 

On November 14, 2014 11:18:57 AM EST, Chagin Dmitry dcha...@freebsd.org wrote:
On Thu, Nov 13, 2014 at 02:13:35PM -0800, Adrian Chadd wrote:
 Hi,
 
 Does it stay blank if you have acpi_video (+ vt) loaded?
 
 What was the revision of 11 you were previously running?
 
 
 
 -adrian
 
 
 On 13 November 2014 14:10, Eric McCorkle e...@metricspace.net
wrote:
  Hello,
 
  I updated my kernel and userland with a fresh update from 11
yesterday, and
  I'm now seeing a blank screen after suspend/resume, where it was
working
  fine previously.
 
  I had been trying out the new vt console, so I switched back to sc,
but the
  blank screen is still there.
 
  Sorry, I don't have any information beyond this (quite busy these
days).
 
  Eric


Lenovo t540, same here. r274463 + sc. resume worked two weeks ago.


-- 
Have fun!
chd

-- 
Sent from my Blackphone with K-9 Mail. Please excuse my brevity.
___
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: Old suspend/resume issue likely root cause

[Eric McCorkle]

On 10/17/15 11:14, Glen Barber wrote:

On Sat, Oct 17, 2015 at 11:09:03AM -0400, Eric McCorkle wrote:

A while back (in May or June or so), I was attempting to figure out why my
laptop screen stayed blank on suspend/resume.  I posted some dmesg outputs
and theorized that it might be something about the devices coming back up in
the wrong order.  John Baldwin suggested I try doing
hw.pci.do_power_suspend=0.

I got tangled up with other projects and had to set it aside.  However, I
now finally have more information:


* hw.pci.power_suspend=0 does cause the screen to come back up properly.
The network (wireless via iwm driver) needs to be re-initialized, but
everything else seems to work properly.

* Without hw.pci.power_suspend=0, the issue persists even when booting from
EFI, so we can rule out some kind of legacy BIOS issue.  The issue manifests
even with the experimental i915 driver, so we can rule out something with
the efifb or VGA framebuffer drivers.


Based on this, it looks pretty likely that the pci bus is the culprit. Any
suggestions on where to look?


What graphics chipset do you have?  I noticed with dumbbell's i915kms
update branch [1], suspend/resume now works for me with Haswell
graphics, whereas previously I would experience the same blank screen on
resume you report.


Intel i7-4700.  I tried suspend with the i915kms driver active, hoping 
that would do the trick, but it didn't work.




(And I also see the iwm(4) reinitialization issue, as well.)


The workaround there is just to take netif, wpa_supplicant, dhclient, 
and rtsold down in rc.suspend and bring them back up in rc.resume.



[1] https://github.com/freebsd/freebsd-base-graphics.git branch
 drm-i915-update-38

Glen


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

Attempting to diagnose suspend/resume issue

[Eric McCorkle]

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



signature.asc
Description: OpenPGP digital signature

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 e...@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

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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  
Features2=0x7fdafbbfSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,b11,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND
  AMD Features=0x2c100800SYSCALL,NX,Page1GB,RDTSCP,LM
  AMD Features2=0x21LAHF,ABM
  Structured Extended 
Features=0x27abFSGSBASE,TSCADJ,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID
  XSAVE Features=0x1XSAVEOPT
  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: LENOVO TP-GN   
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 Version 2.0 irqs 0-23 on motherboard
random: entropy device infrastructure driver
random: selecting highest priority adaptor Dummy
kbd1 at kbdmux0
random: SOFT: yarrow init()
random: selecting highest priority adaptor Yarrow
random: live provider: Intel Secure Key RNG
cryptosoft0: software crypto on motherboard
acpi0: LENOVO TP-GN on motherboard
acpi_ec0: Embedded Controller: GPE 0x11, ECDT port 0x62,0x66 on acpi0
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 7f90 (3) failed
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
cpu2: ACPI CPU on acpi0
cpu3: ACPI CPU on acpi0
cpu4: ACPI CPU on acpi0
cpu5: ACPI CPU on acpi0
cpu6: ACPI CPU on acpi0
cpu7: ACPI CPU on acpi0
attimer0: AT timer port 0x40-0x43 irq 0 on acpi0
Timecounter i8254 frequency 1193182 Hz quality 0
Event timer i8254 frequency 1193182 Hz quality 100
hpet0: High Precision Event

Re: Blank screen on resume

[Eric McCorkle]

Note: I've moved the patch and logs to a new branch: 
https://github.com/emc2/freebsd/tree/resume_blank_screen


On March 12, 2016 10:39:42 PM EST, Eric McCorkle <e...@metricspace.net> wrote:
>Hello everyone,
>
>It seems I'm plagued by blank screens on resume again on a different
>laptop... *sigh*
>
>I've done quite a bit of diagnostic work on this, and there seem to be
>some clues, but I'm a bit stumped at this point.  The following github
>repo has patches that add extra logging, which has proven useful in my
>attempts to diagnose the issue: https://github.com/emc2/freebsd (sorry
>for distributing patches/logs in this way, but the logs are quite big).
>Also in this repo, there's a pciconf, devinfo, and dmesg file.  The
>dmesg file shows the trace from booting a patched kernel in verbose
>mode then suspending it.
>
>There's two main curiosities in the dmesg trace.  The first is that the
>power state of all the vgapci device seems to be 0 as opposed to 3
>during resume, which was causing acpi_set_powerstate_method to skip
>resetting its power during resume.  I tried a simple patch (you can see
>it in the patch and its effects in the trace), but that didn't seem to
>work.  A second curiosity is that acpi_pwr_switch_consumer only seems
>to have an effect during resume.
>
>The only other real lead I have is that the display doesn't seem to be
>active in acpi_video.  I'm not sure if this is an artifact of the efifb
>driver.
>
>Lastly, I recall looking into vga bios calls from earlier such efforts.
>I imagine there's something similar for efifb, but I've been unable to
>track down where this is happening.  Advice or information on that
>front would be much appreciated.
>
>Best,
>Eric
>___
>freebsd-acpi@freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Blank screen on resume

[Eric McCorkle]

Laptop is the librem 13 (not helpful, I know). 

Graphics chipset is broadwell.  Cpu is i5-5200.

Haven't been able to get the motherboard model. However, I have model numbers 
from the bios. 

Bios is American Megatrends.

BIOS Version is 108.
EC version is 2.1u. 
M/B version is D. 

On March 12, 2016 11:45:00 PM EST, Adrian Chadd  wrote:
>Hi,
>
>Which laptop? Which chipset? etc.
>
>
>
>-adrian

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Blank screen on resume

[Eric McCorkle]

So no options at all until then? :(

On March 14, 2016 3:43:08 PM EDT, Adrian Chadd  wrote:
>Hiya,
>
>Yeah - the drm2 code needs to be involved in resuming, and right now
>there's no broadwell support in i915kms.
>
>Once that gets updated then yeah, the resume backlight will work. :-P
>
>
>
>-a

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Re: Blank screen on resume

[Eric McCorkle]

I think I will give that a shot, actually...  It seems pretty unfortunate that 
we'd have to wait for full 3D graphics support on a card in order to get resume 
working.

I can't guarantee success, of course. 

On March 14, 2016 4:49:51 PM EDT, Adrian Chadd <adrian.ch...@gmail.com> wrote:
>On 14 March 2016 at 13:22, Eric McCorkle <e...@metricspace.net> wrote:
>> So no options at all until then? :(
>
>If you want to figure out what minimal set you need from the
>dri/i915kms code to restore backlight happiness, please do. :-P
>
>But yeah. We'll need to wait for the next dri sync
>
>
>-adrian
>
>>
>> On March 14, 2016 3:43:08 PM EDT, Adrian Chadd
><adrian.ch...@gmail.com>
>> wrote:
>>>
>>> Hiya,
>>>
>>> Yeah - the drm2 code needs to be involved in resuming, and right now
>>> there's no broadwell support in i915kms.
>>>
>>> Once that gets updated then yeah, the resume backlight will work.
>:-P
>>>
>>>
>>>
>>> -a
>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Blank screen on resume

[Eric McCorkle]

Hello everyone,

It seems I'm plagued by blank screens on resume again on a different laptop... 
*sigh*

I've done quite a bit of diagnostic work on this, and there seem to be some 
clues, but I'm a bit stumped at this point.  The following github repo has 
patches that add extra logging, which has proven useful in my attempts to 
diagnose the issue: https://github.com/emc2/freebsd (sorry for distributing 
patches/logs in this way, but the logs are quite big).  Also in this repo, 
there's a pciconf, devinfo, and dmesg file.  The dmesg file shows the trace 
from booting a patched kernel in verbose mode then suspending it.

There's two main curiosities in the dmesg trace.  The first is that the power 
state of all the vgapci device seems to be 0 as opposed to 3 during resume, 
which was causing acpi_set_powerstate_method to skip resetting its power during 
resume.  I tried a simple patch (you can see it in the patch and its effects in 
the trace), but that didn't seem to work.  A second curiosity is that 
acpi_pwr_switch_consumer only seems to have an effect during resume.

The only other real lead I have is that the display doesn't seem to be active 
in acpi_video.  I'm not sure if this is an artifact of the efifb driver.

Lastly, I recall looking into vga bios calls from earlier such efforts.  I 
imagine there's something similar for efifb, but I've been unable to track down 
where this is happening.  Advice or information on that front would be much 
appreciated.

Best,
Eric
___
freebsd-acpi@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"

Adding platform ACPI extras - getting started

[Eric McCorkle]

Hello everyone,

I'm looking into what it would take to add support for various bits of
functionality on my platform (Purism's Librem laptops).  Specific things
I'm looking to do are the following:

* Screen brightness support (the brightness sysctls don't currently do
anything when changed)

* If possible, ambient light detection.

* Hotkeys.  Some presently work, others don't.  Here are the ones I'd
like to get working:

  * Suspend button
  * Volume up, down, and mute buttons
  * Video output switch
  * Bluetooth/wireless enable/disable
  * Brightness adjust

I'm willing to write a driver in the style of acpi_ibm and others if
necessary; however, I just need some pointers as to whether that's
necessary and if so, how to get started.

Thanks,
Eric



signature.asc
Description: OpenPGP digital signature