Re: AMD A12-8800B ACPI questions (turbo mode, temp zones)

[Bengt Ahlgren]

Ian Smith  writes:

> On Sun, 13 Dec 2015 19:53:52 -0500, Johannes Dieterich wrote:
>  > Dear list,
>  > 
>  > I am running CURRENT on an HP elitebook 745 G3 which comes with a AMD
>  > A12-8800B CPU. All in all, it runs very well with just a few nits to
>  > pick. Two of them are ACPI related.
>  > 
>  > 1) there are 5 thermal zones defined out of which only two provide
>  > reasonable numbers it seems:
>  > 
>  > hw.acpi.thermal.tz4.temperature: 34.1C
>  > hw.acpi.thermal.tz3.temperature: 0.1C
>  > hw.acpi.thermal.tz2.temperature: 0.1C
>  > hw.acpi.thermal.tz1.temperature: 0.1C
>  > hw.acpi.thermal.tz0.temperature: 56.1C
>  > 
>  > my gut feeling is that tz0-tz3 may be the CPU cores and tz4 would be
>  > the GPU (which does not work in BSD ATM, hence consistently lower
>  > temp). I guess this is not a big deal (everything works) but I still
>  > wonder how to fix it.
>
> Not sure if anything needs fixing, but I only have Intel gear these 
> days and am not up on the AMD side of things.  However, please show:
>
> % sysctl dev.cpu
> % sysctl hw.acpi.thermal
>
> which may provide more clues.  Perhaps all 4 cores are in one package, 
> in which case individual CPU temperatures may not be too meaningful.  I 
> don't know whether there's any equivalent to coretemp(4) for AMD CPUs?

Yes, amdtemp(4), which on this system gives one value per processor
package:

$ sysctl dev.amdtemp
dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
dev.amdtemp.0.%driver: amdtemp
dev.amdtemp.0.%parent: hostb4
dev.amdtemp.0.sensor_offset: 0
dev.amdtemp.0.core0.sensor0: 24.6C
dev.amdtemp.1.%desc: AMD CPU On-Die Thermal Sensors
dev.amdtemp.1.%driver: amdtemp
dev.amdtemp.1.%parent: hostb10
dev.amdtemp.1.sensor_offset: 0
dev.amdtemp.1.core0.sensor0: 25.3C

Those values however seem a bit low to be true...

> Yours won't use est(4) but perhaps powernow(0) - 0 meaning no manpage :) 
> but both are in GENERIC kernels.  You should be able to glean from dmesg 
> which driver/s are in use; a verbose dmesg.boot might come in handy.

It is called "hwpstate":

$ sysctl dev.hwpstate
dev.hwpstate.0.%desc: Cool`n'Quiet 2.0
dev.hwpstate.0.%driver: hwpstate
dev.hwpstate.0.%parent: cpu0
dev.hwpstate.0.freq_settings: 3100/10920 2700/8600 2200/6200 1800/4500 1400/3105

Bengt

>  > 2) turbo mode: this is a more major issue. sysctl reports the
>  > following for all four cores:
>  > 
>  > dev.cpu.0.cx_lowest: C2
>  > dev.cpu.0.cx_supported: C1/1/0 C2/2/400
>  > dev.cpu.0.freq_levels: 2100/4717 1800/3450 1400/2320
>  > dev.cpu.0.freq: 2100
>  > 
>  > >From the intel CPUs w/ turbo mode I had before I know that there
>  > should be (at least) a 2101 frequency indicating the turbo clock. This
>  > frequency is absent, I suspect this means turbo mode does not work.
>
> Or that these CPUs just don't have a turbo mode, as such?  I expect the 
> specs on AMD's site should mention that, either way?
>
>  > How can I debug this? I believe also that this AMD chip has multiple
>  > frequencies above the base clock of 2100, so how would that show?
>
> What leads you to believe that?  Where is this documented?
>
>  > Loaded modules:
>  > 
>  > Id Refs AddressSize Name
>  >  1   23 0x8020 1e79670  kernel
>  >  21 0x8207b000 384858   zfs.ko
>  >  32 0x8240 ca38 opensolaris.ko
>  >  41 0x8240d000 22b98geom_eli.ko
>  >  51 0x82431000 ac60 aesni.ko
>  >  61 0x8243d000 1c520fuse.ko
>  >  71 0x82621000 358b ums.ko
>  >  81 0x82625000 223c4ipfw.ko
>  > 
>  > I should note that I boot in legacy mode, not EFI.
>  > 
>  > asl dump available from http://llamapost.net/elitebook.asl
>
> If it cxomes to that ..
>
>  > Thanks a lot!
>  > 
>  > Johannes
>
> Not much help, but I see noone else springing to your aid so far ..
>
> cheers, Ian
> ___
> 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"
___
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: 9.2-RC3 - suspend/resume causes slow system performance

[Bengt Ahlgren]

Now having some experience with my new TP X201 and Intel/KMS graphics,
I also ran into severe Xorg perfomance issues, but it was _not_
connected to suspend/resume, because it persisted after a clean reboot.

I plugged in a projector to the VGA port, and used xrandr.  The Xorg
server seemed to come to a halt, in practice unusable.  After the fact I
saw in the log file that there were tons of these messages:

[   136.238] (II) intel(0): EDID vendor IFS, prod id 4354
[   136.238] (II) intel(0): Using hsync ranges from config file
[   136.238] (II) intel(0): Using vrefresh ranges from config file
[   136.238] (II) intel(0): Printing DDC gathered Modelines:
[   136.238] (II) intel(0): Modeline 1280x800x0.0   83.40  1280 1344 1480 
1680  800 801 804 828 -hsync +vsync (49.6 kHz eP)
[   136.238] (II) intel(0): Modeline 800x600x0.0   40.00  800 840 968 1056  
600 601 605 628 +hsync +vsync (37.9 kHz e)
[   136.238] (II) intel(0): Modeline 800x600x0.0   36.00  800 824 896 1024  
600 601 603 625 +hsync +vsync (35.2 kHz e)
[   136.238] (II) intel(0): Modeline 640x480x0.0   31.50  640 656 720 840  
480 481 484 500 -hsync -vsync (37.5 kHz e)
[   136.238] (II) intel(0): Modeline 640x480x0.0   31.50  640 664 704 832  
480 489 492 520 -hsync -vsync (37.9 kHz e)
[   136.238] (II) intel(0): Modeline 640x480x0.0   30.24  640 704 768 864  
480 483 486 525 -hsync -vsync (35.0 kHz e)
[   136.238] (II) intel(0): Modeline 640x480x0.0   25.18  640 656 752 800  
480 490 492 525 -hsync -vsync (31.5 kHz e)
[   136.238] (II) intel(0): Modeline 720x400x0.0   28.32  720 738 846 900  
400 412 414 449 -hsync +vsync (31.5 kHz e)
[   136.238] (II) intel(0): Modeline 1280x1024x0.0  135.00  1280 1296 1440 
1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[   136.238] (II) intel(0): Modeline 1024x768x0.0   78.75  1024 1040 1136 
1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
[   136.238] (II) intel(0): Modeline 1024x768x0.0   75.00  1024 1048 1184 
1328  768 771 777 806 -hsync -vsync (56.5 kHz e)
[   136.238] (II) intel(0): Modeline 1024x768x0.0   65.00  1024 1048 1184 
1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[   136.238] (II) intel(0): Modeline 832x624x0.0   57.28  832 864 928 1152  
624 625 628 667 -hsync -vsync (49.7 kHz e)
[   136.238] (II) intel(0): Modeline 800x600x0.0   49.50  800 816 896 1056  
600 601 604 625 +hsync +vsync (46.9 kHz e)
[   136.238] (II) intel(0): Modeline 800x600x0.0   50.00  800 856 976 1040  
600 637 643 666 +hsync +vsync (48.1 kHz e)
[   136.238] (II) intel(0): Modeline 1152x864x0.0  108.00  1152 1216 1344 
1600  864 865 868 900 +hsync +vsync (67.5 kHz e)
[   136.238] (II) intel(0): Modeline 1280x720x60.0   74.48  1280 1336 1472 
1664  720 721 724 746 -hsync +vsync (44.8 kHz e)
[   136.238] (II) intel(0): Modeline 1280x960x0.0  108.00  1280 1376 1488 
1800  960 961 964 1000 +hsync +vsync (60.0 kHz e)
[   136.238] (II) intel(0): Modeline 1280x1024x0.0  108.00  1280 1328 1440 
1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[   136.238] (II) intel(0): Modeline 1366x768x59.8   84.75  1366 1431 1567 
1776  768 771 781 798 -hsync +vsync (47.7 kHz e)
[   136.238] (II) intel(0): Modeline 1440x900x0.0  106.50  1440 1520 1672 
1904  900 903 909 934 -hsync +vsync (55.9 kHz e)
[   136.238] (II) intel(0): Modeline 1400x1050x0.0  121.75  1400 1488 1632 
1864  1050 1053 1057 1089 -hsync +vsync (65.3 kHz e)
[   136.238] (II) intel(0): Modeline 1600x1200x0.0  162.00  1600 1664 1856 
2160  1200 1201 1204 1250 +hsync +vsync (75.0 kHz e)
[   136.238] (II) intel(0): Modeline 1680x1050x0.0  146.25  1680 1784 1960 
2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz e)

That is, the Xorg server constantly queried the display device for its
capabilities (perhaps on behalf of some client - I run KDE, so you never
know what it tries to do...).

This seems to be a somewhat known issue:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/310857

Is this something different, or is this a variant of the slowdown others
are seeing?

Bengt

Adrian Chadd adr...@freebsd.org writes:

 .. anything happening?


 -adrian


 On 2 September 2013 07:29, Adrian Chadd adr...@freebsd.org wrote:


 On 2 September 2013 07:25, Mike Harding mvhard...@gmail.com wrote:

 It's detailed in the ticket,  see
 http://www.freebsd.org/cgi/query-pr.cgi?pr=181632 and search for
 'reverted'.


 Ok. You and avg@ are digging into it deeper, so I'll leave it be for now.
 I'll retest this on my test laptops when I'm back home.



 -adrian
___
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: suspend/resume on Lenovo X1 (regression from reports on wiki)

[Bengt Ahlgren]

Ganael LAPLANCHE ganael.laplan...@martymac.org writes:

 On Fri, 30 Aug 2013 11:53:22 -0400, John Baldwin wrote

 I just removed VESA from my kernel on an X220 and it now suspends and
 resumes great in X.  I don't notice any slowdown, but I'm using a very
 simple tiling window manager (i3wm).

 Great, I can confirm that suspend/resume also works on my X220 with this
 trick !

 I had once opened a PR for that problem and I had managed to track the
 change that, at that time, broke suspend/resume :

 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/174504

 I don't know how it relates to VESA (the change does not seem to be
 related to VESA), but it might help ?

I believe this (the PR) is a completely different issue, since you write
resume make the computer hang.  The nooptions VESA fixed wedging of
Intel/KMS graphics _after_ resume.  There have been many other changes
since r231797 (15 feb 2012).

But nice that it works for you too!

Bengt
___
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: suspend/resume on Lenovo X1 (regression from reports on wiki)

[Bengt Ahlgren]

Jung-uk Kim j...@freebsd.org writes:

 On 2013-09-04 18:47:47 -0400, Jung-uk Kim wrote:
 On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote:
 The value of hw.acpi.video.lcd0.brightness changes when the
 screen brightness keys (Fn+Home/End) are pressed, but nothing
 happens with the screen.  Same goes for changing the value with
 sysctl.  After a fresh boot it works with one issue.  The screen
 brightness level seems to lag behind one keypress.  Without
 acpi_video, screen brightness changes without the lag.
 
 hw.acpi.video.lcd0.active is always stuck at 0 - can't change
 with sysctl (regardless if the screen is on after a fresh boot,
 or black after a text console suspend/resume):
 
 [root@bit ~]# sysctl hw.acpi.video.lcd0.active=1 
 hw.acpi.video.lcd0.active: 0 - 0
 
 Again, for my old X40 with non-KMS Xorg intel driver has 
 (curiously, the screen blinks when issuing this sysctl command):
 
 [bengta@P142 ~]$ sysctl hw.acpi.video hw.acpi.video.lcd0.active:
 1 hw.acpi.video.crt0.active: 0
 
 Then, KMS probably breaks acpi_video(4), too. :-(

 kib let me know that there is a way to make it work but it was not
 well-integrated to i915kms.ko.  If you are interested in fixing it,
 dev/drm2/i915/intel_opregion.c is the source and you can download the
 specification from here:

 https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf

Hmm, scanning that spec, I wonder whether the opregion functionality is
better placed together with acpi_video, and then i915kms makes calls to
that instead?  Hmm, again, perhaps the intel platform needs opregion
support to work properly also without the kms driver.  Could be an
explanation for the backlight issues.  (Just speculation so far...  I
have no idea if/how this relates to or interacts with options VESA)

Bengt
___
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: suspend/resume on Lenovo X1 (regression from reports on wiki)

[Bengt Ahlgren]

Jung-uk Kim j...@freebsd.org writes:

 On 2013-09-04 09:29:35 -0400, John Baldwin wrote:
 On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote:
 On 2013-09-03 16:47:47 -0400, John Baldwin wrote:
 Even with that hacked so I force vgapm0 and dpms0 to attach, I 
 still can't resume in console mode, ...
 
 What happens?  Does it panic, hang, or just no backlight?
 
 Just no backlight.  It resumes fine and if I do it in multiuser I 
 can ssh in, etc.  It's just the backlight that doesn't resume.  I
 was hopeful dpms.ko would fix that, but it didn't. :(

 Ah, that's a well-known problem and we cannot fix it without help of
 machine-specific code, e.g., drm1/drm2.  Actually, both acpi_video and
 dpms try to restore video settings but nothing worked for Intel GPUs +
 LVDS + LCD panel AFAIK.

 I think i915drm has code to specifically turn on the backlight as
 I get some weird error message in the kernel console about a
 timeout trying to turn the panel off during suspend when I'm in X.
 So, I guess it has an ordering issue.  If my memory serves, drm1 was
 okay with vesa, however.  I *think* it accidentally worked because of
 automatic VT-switching, which is still broken for KMS.

Yes, perhaps, but there is also the sysctl hw.acpi.reset_video which I
have enabled on my older hardware (TP X40 running 8.3-REL and an old
Xorg server) for it to work properly.  (I however have some faint memory
that reset_video might a no-op these days, or?)  In this old mail
regarding reset_video, there is a thought that it could be good with
more reinitialisation:

http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html

I however have one datapoint that I think contradicts John's thought.
This is on a X201 with stable/9 and no options VESA.  I first just
booted up and stayed in text console, suspended and resumed.  No
backlight, of course, and also no content on the LCD, it is completely
black.  Then, I started Xorg with KMS.  Still no backlight, but you can
see that the LCD is driven with the desired content, which is one step
forward.  Finally, I suspended and resumed, but no difference, the
backlight is still off.  Xorg/KMS didn't manage to turn the backlight
on, so the text console suspend/resume cycle managed to persistently
turn the backlight off.

One more thing, the kernel logs this at resume directly after the
devices are powered on (transition to D0), but I have no idea whether it
is relevant:

Sep  2 19:57:21 bit kernel: error: [drm:pid1904:intel_lvds_enable] *ERROR* 
timed out waiting for panel to power off

Bengt
___
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: suspend/resume on Lenovo X1 (regression from reports on wiki)

[Bengt Ahlgren]

Jung-uk Kim j...@freebsd.org writes:

 On 2013-09-04 15:14:32 -0400, Bengt Ahlgren wrote:
 Jung-uk Kim j...@freebsd.org writes:
 
 On 2013-09-04 09:29:35 -0400, John Baldwin wrote:
 On Tuesday, September 03, 2013 6:58:55 pm Jung-uk Kim wrote:
 On 2013-09-03 16:47:47 -0400, John Baldwin wrote:
 Even with that hacked so I force vgapm0 and dpms0 to
 attach, I still can't resume in console mode, ...
 
 What happens?  Does it panic, hang, or just no backlight?
 
 Just no backlight.  It resumes fine and if I do it in multiuser
 I can ssh in, etc.  It's just the backlight that doesn't
 resume.  I was hopeful dpms.ko would fix that, but it didn't.
 :(
 
 Ah, that's a well-known problem and we cannot fix it without help
 of machine-specific code, e.g., drm1/drm2.  Actually, both
 acpi_video and dpms try to restore video settings but nothing
 worked for Intel GPUs + LVDS + LCD panel AFAIK.
 
 I think i915drm has code to specifically turn on the backlight
 as I get some weird error message in the kernel console about
 a timeout trying to turn the panel off during suspend when I'm
 in X.
 So, I guess it has an ordering issue.  If my memory serves, drm1
 was okay with vesa, however.  I *think* it accidentally worked
 because of automatic VT-switching, which is still broken for
 KMS.
 
 Yes, perhaps, but there is also the sysctl hw.acpi.reset_video
 which I have enabled on my older hardware (TP X40 running 8.3-REL
 and an old Xorg server) for it to work properly.  (I however have
 some faint memory that reset_video might a no-op these days, or?)

 No, I didn't remove it.  However, I strongly discourage it.  In fact,
 the same functionality exists in vesa.c and it is safer.

 In this old mail regarding reset_video, there is a thought that it 
 could be good with more reinitialisation:
 
 http://lists.freebsd.org/pipermail/freebsd-acpi/2006-July/002959.html

 vesa.c
 
 does pretty much the same thing.  FYI, vbetool does more but
 it does not really do more reinitialisation.

 % grep ^MAINTAINER sysutils/vbetool/Makefile
 MAINTAINER= j...@freebsd.org

 :-)

Great!  Is vesa.c = options VESA = vesa.ko?

 I however have one datapoint that I think contradicts John's
 thought. This is on a X201 with stable/9 and no options VESA.  I
 first just booted up and stayed in text console, suspended and
 resumed.  No backlight, of course, and also no content on the LCD,
 it is completely black.

 Panel may be completely off.

 Then, I started Xorg with KMS.  Still no backlight, but you can see
 that the LCD is driven with the desired content, which is one step 
 forward.  Finally, I suspended and resumed, but no difference, the 
 backlight is still off.

 I believe i915kms explicitly turns on LVDS/LCD panel.  I guess it
 doesn't change brightness, though.

 Xorg/KMS didn't manage to turn the backlight on, so the text
 console suspend/resume cycle managed to persistently turn the
 backlight off.

 Can you change the brightness via hotkeys or acpi_video?

The value of hw.acpi.video.lcd0.brightness changes when the screen
brightness keys (Fn+Home/End) are pressed, but nothing happens with the
screen.  Same goes for changing the value with sysctl.  After a fresh
boot it works with one issue.  The screen brightness level seems to lag
behind one keypress.  Without acpi_video, screen brightness changes
without the lag.

hw.acpi.video.lcd0.active is always stuck at 0 - can't change with
sysctl (regardless if the screen is on after a fresh boot, or black
after a text console suspend/resume):

[root@bit ~]# sysctl hw.acpi.video.lcd0.active=1
hw.acpi.video.lcd0.active: 0 - 0

Again, for my old X40 with non-KMS Xorg intel driver has (curiously, the
screen blinks when issuing this sysctl command):

[bengta@P142 ~]$ sysctl hw.acpi.video
hw.acpi.video.lcd0.active: 1
hw.acpi.video.crt0.active: 0

Jumping to another thing.  The Xorg intel/KMS driver does not present a
backlight property using RandR (older non-KMS intel driver did):

[bengta@bit ~]$ xbacklight 
No outputs have backlight property

Bengt

 One more thing, the kernel logs this at resume directly after the 
 devices are powered on (transition to D0), but I have no idea
 whether it is relevant:
 
 Sep  2 19:57:21 bit kernel: error: [drm:pid1904:intel_lvds_enable]
 *ERROR* timed out waiting for panel to power off

 Yes, it looks relevant.

 Jung-uk Kim
___
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: suspend/resume on Lenovo X1 (regression from reports on wiki)

[Bengt Ahlgren]

Just a mee too report for a Thinkpad X201.  Resume now results in a
usable display with Intel/KMS graphics thanks to removing options VESA
from the kernel config!  Still no backlight in console mode, however.  I
have not investigated any slow-downs.

Thanks for the crucial piece of info!

(I'm on stable/9 and a ports tree as of today.)

Bengt

Glen Barber g...@freebsd.org writes:

 On Thu, Aug 29, 2013 at 06:42:28PM +0200, Laura Marie Feeney wrote:
 No xorg.conf is needed and all acpi options are as default.  It
 seems to work correctly both with and without acpi_video and
 acpi_ibm in the kernel.  It's still necessary to compile  out
 'options VESA' from the kernel, otherwise resume fails entirely.
 

 I can also confirm that removing VESA from the kernel allows my system
 to resume properly, both with Xorg and console.

 root@nucleus:~ # kldstat 
 Id Refs AddressSize Name
  1   28 0x8020 eb6148   kernel
  21 0x810b7000 22ca40   zfs.ko
  32 0x812e4000 5e58 opensolaris.ko
  41 0x81412000 6149fi915kms.ko
  51 0x81474000 3e5c7drm2.ko

 I also observe the issue that Gleb Smirnoff mentions below, that the
 xorg server is quite slow after result.  Using 'xterm -sb' and
 moving the scrollbar up and down very fast, I was able to able to
 get the xorg process up to ~20% of CPU.  On casual observation, it
 didn't seem to get worse after several suspend/resume cycles.
 

 I did not see any unusual CPU chewing by X after resume in my case.
 I did see something unpleasant with xrandr(1), however.  I have dual
 external monitors attached, which I have a login script set the
 resolution properly.  With my resolution set to 3840x1080, X is unusable
 on resume.  (The screen is fuzzy, but the machine does not crash.)
 Without changing the resolution before suspend, X works properly at
 resume.

 Glen
___
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: AMT console

[Bengt Ahlgren]

Konstantin Belousov kostik...@gmail.com writes:

 On Thu, Jun 20, 2013 at 09:16:19AM +0300, Konstantin Belousov wrote:
 On Thu, Jun 20, 2013 at 12:20:27AM +0200, Bengt Ahlgren wrote:
  John Baldwin j...@freebsd.org writes:
  
   On Thursday, June 13, 2013 10:00:21 am Ganael LAPLANCHE wrote:
   Hi,
   
   As you may know, suspend/resume has been broken on Lenovo x220 for a
   long time now, see :
   
   http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/174504
   
   I have been able to do a suspend(S3)/resume operation in text mode (it
   works, but console stays dark at resume, I had to connect through ssh ;
   also, resume hangs if X is started with i915kms.ko loaded) and collect
   the following verbose logs :
  
   Interesting, I connected a serial console via AMT but wasn't able to get
   any output during resume.  Is this with a stock kernel?
  
  Does the console via AMT otherwise work for you?
  
  I'm trying to set up AMT as the console on a TP X201.  I got the serial
  over LAN working using amtterm from another machine - verified with cu
  on the tty (ttyu2) that typing on both ends shows up at the other end
  before trying console redirection.  The device is:
  
  uart2: Non-standard ns8250 class UART with FIFOs port
  0x1808-0x180f mem 0xf2524000-0xf2524fff irq 17 at device 22.3 on
  pci0
  
  uart2@pci0:0:22:3: class=0x070002 card=0x216217aa chip=0x3b678086
  rev=0x06 hdr=0x00
  vendor = 'Intel Corporation'
  device = '5 Series/3400 Series Chipset KT Controller'
  class  = simple comms
  subclass   = UART
  bar   [10] = type I/O Port, range 32, base 0x1808, size  8, enabled
  bar   [14] = type Memory, range 32, base 0xf2524000, size 4096, enabled
  cap 01[c8] = powerspec 3  supports D0 D3  current D0
  cap 05[d0] = MSI supports 1 message, 64 bit 
  
  I've set:
  
  hint.uart.2.flags=0x10
  console=comconsole
  
  in /boot/loader.conf, but the loader just hangs after printing:
  
  Loading /boot/defaults/loader.conf
  
  Any advice?  Is uart2 unusable as a console?  It does not say flags
  0x10 in the device probe - does that mean it won't work?
 
 You should use
 comconsole_pcidev=0:0:22:3
 Oops,
 comconsole_pcidev=0:22:3

No difference, I'm afraid.  The port does not show up here either:

# sysctl kern.console
kern.console: ttyv0,dcons,/dcons,ttyv0,ucom,

Forgot to tell, but this is a 9.1-REL-p3/amd64 system running GENERIC.

(I wanted to set up the console for KMS shutdown and resume debugging.)

Bengt
___
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

AMT console (was: Fixing suspend/resume on Lenovo x220)

[Bengt Ahlgren]

John Baldwin j...@freebsd.org writes:

 On Thursday, June 13, 2013 10:00:21 am Ganael LAPLANCHE wrote:
 Hi,
 
 As you may know, suspend/resume has been broken on Lenovo x220 for a
 long time now, see :
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/174504
 
 I have been able to do a suspend(S3)/resume operation in text mode (it
 works, but console stays dark at resume, I had to connect through ssh ;
 also, resume hangs if X is started with i915kms.ko loaded) and collect
 the following verbose logs :

 Interesting, I connected a serial console via AMT but wasn't able to get
 any output during resume.  Is this with a stock kernel?

Does the console via AMT otherwise work for you?

I'm trying to set up AMT as the console on a TP X201.  I got the serial
over LAN working using amtterm from another machine - verified with cu
on the tty (ttyu2) that typing on both ends shows up at the other end
before trying console redirection.  The device is:

uart2: Non-standard ns8250 class UART with FIFOs port 0x1808-0x180f mem 
0xf2524000-0xf2524fff irq 17 at device 22.3 on pci0

uart2@pci0:0:22:3:  class=0x070002 card=0x216217aa chip=0x3b678086 rev=0x06 
hdr=0x00
vendor = 'Intel Corporation'
device = '5 Series/3400 Series Chipset KT Controller'
class  = simple comms
subclass   = UART
bar   [10] = type I/O Port, range 32, base 0x1808, size  8, enabled
bar   [14] = type Memory, range 32, base 0xf2524000, size 4096, enabled
cap 01[c8] = powerspec 3  supports D0 D3  current D0
cap 05[d0] = MSI supports 1 message, 64 bit 

I've set:

hint.uart.2.flags=0x10
console=comconsole

in /boot/loader.conf, but the loader just hangs after printing:

Loading /boot/defaults/loader.conf

Any advice?  Is uart2 unusable as a console?  It does not say flags
0x10 in the device probe - does that mean it won't work?

Bengt
___
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: Asus M2N32 sli deluxe acpi_themal problem (ACPI Warning for \\_TZ_.THRM._PSL)

[Bengt Ahlgren]

Mario Sergio Fujikawa Ferreira li...@freebsd.org writes:

 Hi,

   MOBO: Asus m2n32 sli deluxe wireless edition with bios version 2209.
   FreeBSD: FreeBSD home.here 8.0-STABLE FreeBSD 8.0-STABLE #20: Tue Apr 27 
 07:09:25 BRT 2010 li...@home:/usr/obj/usr/src/sys/LIOUX i386

   I would like to use acpi_thermal(4) passive cooling feature.

   However, hw.acpi.thermal.tzo.temperature reports incorrect temperature. It 
 always return 40,0C regardless of the value I get from other sysctls:

 dev.acpi_aiboost.0.temp0: 550
 dev.acpi_aiboost.0.temp1: 390
 dev.amdtemp.0.sensor0.core0: 39,0C
 dev.amdtemp.0.sensor0.core1: 42,0C

I had the same problem with an Asus A8N-E MB.  It was easily fixed in
the ASL.  See:

http://lists.freebsd.org/pipermail/freebsd-acpi/2006-October/003178.html

Bengt
___
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