Re: Thinkpad t460 acpi issues
Thanks. Works perfectly!
I take it that backlight is often better as it can be run as a user and
does not require acpi_video to be loaded. I don't see anything in acp_video
that I need if I don't need it to adjust/report brightness. I saw a note in
the comment about drm-devel-kmod about this, but no specific command was
mentioned.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
On Thu, Apr 1, 2021 at 7:13 PM Jung-uk Kim wrote:
> On 21. 3. 29., Kevin Oberman wrote:
> > The best way to support these keys is to use devd to respond to them and
> > dispatch to programs that can do what the key should do.
> >
> > I wanted my new laptop brightness keys to work. pressing them had no
> > obvious effect. I created the following file in /etc/devd/:
> > notify 10 {
> > match "system" "ACPI";
> > match "subsystem" "IBM";
> > match "notify" "0x10";
> > action "/usr/local/sbin/L15-backlight.pl Brighter";
> > };
> > notify 10 {
> > match "system" "ACPI";
> > match "subsystem" "IBM";
> > match "notify" "0x11";
> > action "/usr/local/sbin/L15-backlight.pl Dimmer";
> > };
> > /*
> > notify 10 {
> > match "system" "ACPI";
> > match "subsystem" "IBM";
> > action "logger Notify = $notify";
> > };
> > */
> > and trivial perl script (probably sh or python would be most people's
> > choice) to actually do the job:
> > #!/usr/local/bin/perl
> > use strict;
> > use Sys::Syslog;
> > if ($#ARGV != 0) {
> > print STDERR "usage: L15-backlight.pl (incr|decr)";
> > exit 0;
> > }
> > #openlog("brightness", ,);
> > my $new_bright;
> > my $notify = $ARGV[0];
> > my $curr_bright = `sysctl -n hw.acpi.video.lcd0.brightness`;
> > if ($notify eq "Brighter") {$new_bright = ($curr_bright + 4)};
> > if ($notify eq "Dimmer") {$new_bright = ($curr_bright - 4)};
> > #syslog ("debug", "Notify = $notify, Old = $curr_bright, New =
> $new_bright
> > ");
> > `sysctl -n hw.acpi.video.lcd0.brightness=$new_bright`;
>
> For AMD and Intel GPUs, you may use backlight(8) with amdgpukms.ko or
> i915kms.ko rather than sysctl(8) with acpi_video.ko.
>
> Jung-uk Kim
>
> > This adjusted the brightness by 5% on each press.You may notice that the
> > adjustment is + or - 4, not 5. It turns out that the brightness keys
> worked
> > fine, but only adjusted the brightness by 1%.
> >
> > Similar devd entries can work for other keys. The final rule and the log
> > statement in the script are commented out, but can be used to track down
> > which key maps to which event number.
> >
> > I should thank the person who gave me the technique, but I can't seem to
> > find the e-mail. My apologies to him.
> >
> > Kevin Oberman, Part time kid herder and retired Network Engineer
> > E-mail: rkober...@gmail.com
> > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> >
> >
> > On Mon, Mar 29, 2021 at 6:16 AM Softwafe Engineer
> > wrote:
> >
> >> Hello.
> >> Freebsd 13 rc3
> >>
> >> I'm trying to enable acpi hotkeys on my thinkpad t460 but
> >> unfortunately looks lite it unsupported.
> >> I've loaded acpi_ibm and acpi_video but only three hotkeys works (on
> >> my laptop it's fn+F(number)).
> >>
> >> As well I noticed strange behaviour on closing laptop cover. When I do
> >> it then laptop starts to increase funspeed and no keys or trackpad
> >> reaction after opening. Only reset works (long pressing on power
> >> button).
> >>
> >> Is it possible to add supporting for my laptop?
>
___
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: Thinkpad t460 acpi issues
The best way to support these keys is to use devd to respond to them and
dispatch to programs that can do what the key should do.
I wanted my new laptop brightness keys to work. pressing them had no
obvious effect. I created the following file in /etc/devd/:
notify 10 {
match "system" "ACPI";
match "subsystem" "IBM";
match "notify" "0x10";
action "/usr/local/sbin/L15-backlight.pl Brighter";
};
notify 10 {
match "system" "ACPI";
match "subsystem" "IBM";
match "notify" "0x11";
action "/usr/local/sbin/L15-backlight.pl Dimmer";
};
/*
notify 10 {
match "system" "ACPI";
match "subsystem" "IBM";
action "logger Notify = $notify";
};
*/
and trivial perl script (probably sh or python would be most people's
choice) to actually do the job:
#!/usr/local/bin/perl
use strict;
use Sys::Syslog;
if ($#ARGV != 0) {
print STDERR "usage: L15-backlight.pl (incr|decr)";
exit 0;
}
#openlog("brightness", ,);
my $new_bright;
my $notify = $ARGV[0];
my $curr_bright = `sysctl -n hw.acpi.video.lcd0.brightness`;
if ($notify eq "Brighter") {$new_bright = ($curr_bright + 4)};
if ($notify eq "Dimmer") {$new_bright = ($curr_bright - 4)};
#syslog ("debug", "Notify = $notify, Old = $curr_bright, New = $new_bright
");
`sysctl -n hw.acpi.video.lcd0.brightness=$new_bright`;
This adjusted the brightness by 5% on each press.You may notice that the
adjustment is + or - 4, not 5. It turns out that the brightness keys worked
fine, but only adjusted the brightness by 1%.
Similar devd entries can work for other keys. The final rule and the log
statement in the script are commented out, but can be used to track down
which key maps to which event number.
I should thank the person who gave me the technique, but I can't seem to
find the e-mail. My apologies to him.
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
On Mon, Mar 29, 2021 at 6:16 AM Softwafe Engineer
wrote:
> Hello.
> Freebsd 13 rc3
>
> I'm trying to enable acpi hotkeys on my thinkpad t460 but
> unfortunately looks lite it unsupported.
> I've loaded acpi_ibm and acpi_video but only three hotkeys works (on
> my laptop it's fn+F(number)).
>
> As well I noticed strange behaviour on closing laptop cover. When I do
> it then laptop starts to increase funspeed and no keys or trackpad
> reaction after opening. Only reset works (long pressing on power
> button).
>
> Is it possible to add supporting for my laptop?
> ___
> 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: ACPI battery states
Also, "acpiconf -i battnum" will tell you most eeverything you wanted to know about the batteries. If you have only a single battery, battnum is '0'. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Wed, Oct 23, 2019 at 10:50 PM Kevin Oberman wrote: > "apm -b" reports state. See "man 8 apm". > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > > On Wed, Oct 23, 2019 at 9:11 PM Takanori Watanabe > wrote: > >> On Thu, Oct 24, 2019 at 01:31:01AM +, Namkhai Bourquin via >> freebsd-acpi wrote: >> > Hi all! I'm writing a script to get battery status and capacity, and >> I'm using hw.acpi.battery for that. But I can't find a reference as to >> which states hw.acpi.battery.state supports. Not in DuckDuckGo, nor google, >> nor the mailing lists archive, nothing. I only managed to discover this by >> discharging the battery and monitoring: >> > state: 0 = unknow? >> > state: 1 = discharging >> > state: 2 = charging >> > state: 5 = discharging critical (life < 6) >> > state: 4 = same as 0, but with critical charge? >> > state: 6 = charging critical >> >> This is originally raw value of _BST which is specific ACPI method for >> control method battery, but smart battery device also simulate it. >> >> The bit macro is in /usr/include/dev/acpica/acpiio.h . >> >> #define ACPI_BATT_STAT_DISCHARG 0x0001 >> #define ACPI_BATT_STAT_CHARGING 0x0002 >> #define ACPI_BATT_STAT_CRITICAL 0x0004 >> >> >> > I can't find anything on the man pages either. >> > Should this be documented, either on a man page or the sysctl's tunable >> description? >> >> It will be good. >> >> >> >> ___ >> 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: ACPI battery states
"apm -b" reports state. See "man 8 apm". -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Wed, Oct 23, 2019 at 9:11 PM Takanori Watanabe wrote: > On Thu, Oct 24, 2019 at 01:31:01AM +, Namkhai Bourquin via > freebsd-acpi wrote: > > Hi all! I'm writing a script to get battery status and capacity, and I'm > using hw.acpi.battery for that. But I can't find a reference as to which > states hw.acpi.battery.state supports. Not in DuckDuckGo, nor google, nor > the mailing lists archive, nothing. I only managed to discover this by > discharging the battery and monitoring: > > state: 0 = unknow? > > state: 1 = discharging > > state: 2 = charging > > state: 5 = discharging critical (life < 6) > > state: 4 = same as 0, but with critical charge? > > state: 6 = charging critical > > This is originally raw value of _BST which is specific ACPI method for > control method battery, but smart battery device also simulate it. > > The bit macro is in /usr/include/dev/acpica/acpiio.h . > > #define ACPI_BATT_STAT_DISCHARG 0x0001 > #define ACPI_BATT_STAT_CHARGING 0x0002 > #define ACPI_BATT_STAT_CRITICAL 0x0004 > > > > I can't find anything on the man pages either. > > Should this be documented, either on a man page or the sysctl's tunable > description? > > It will be good. > > > > ___ > 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: suspend to RAM stopped working on 11.2 (11.1 was OK)
kernel: uhub4 on uhub3 > Sep 27 19:49:58 pf-bsd kernel: uhub4: 9/0, rev 1.10/1.10, addr 3> on usbus0 > Sep 27 19:49:58 pf-bsd kernel: uhub4: 4 ports with 3 removable, self > powered > Sep 27 19:49:59 pf-bsd kernel: ugen0.5: at > usbus0 > Sep 27 19:49:59 pf-bsd root: Unknown USB device: vendor 0x0b97 product > 0x7772 bus uhub4 > Sep 27 19:50:02 pf-bsd wpa_supplicant[58136]: wlan0: Trying to associate > with f0:79:59:d2:7a:00 (SSID='pf's Network' freq=2427 MHz) > Sep 27 19:50:02 pf-bsd wpa_supplicant[58136]: wlan0: Associated with > f0:79:59:d2:7a:00 > Sep 27 19:50:02 pf-bsd kernel: wlan0: link state changed to UP > > From the log, it appears that the system sis resume. The network reports that wlan0 is UP an hte wpa_supplicant reports success. I suspect that you system is up, but that the display is hung. Near the top I see "vgapci0: child drmn0 requested pci_set_powerstate" followed by "pci0: failed to set ACPI power state D3 on \_SB_.PCI0.GFX0: AE_BAD_PARAMETER". It looks like this is a failure to properly wake the graphics processor. (The sound system also appears to fail.) This well out of my area of expertise, so I hope someone more clueful about GPU/ACPI interaction might help. You should be able to ssh into the system to confirm that it is up. You might be able to log in blind from the keyboard as well, but that would be a bit less useful. At least you should log in and so a clean shutdown. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: power off issues
On Tue, Jul 17, 2018 at 5:54 PM, Anthony Jenkins via freebsd-acpi < freebsd-acpi@freebsd.org> wrote: > On 07/17/18 09:54, Andrew Vylegzhanin wrote: > > Hi! > > > > I have a following problem with Dell PowerEdge R740 servers: > > shutdown -p and shutdown -r does not perform power off or reseting system > > actually. > > > > I need to do it manually or via iDRAC after. > > > > Counted on two systems. > > Can you post the output of dmesg(8)? Want to see if there are any boot > ACPI errors. > > Anthony Jenkins > > > > > WBR, > > -- > > Andrew > Better yet, post the contents of /var/run/dmesg. if it is the messages are too long, dmesg(8) output will be missing lines from the beginning. The file does not have the limit on length. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: ACPI problems op ASrock
he problem you are having is probably that enabling the newer, really effective power management tool was not committed to 10.2 when TCC was disabled. It is now in HEAD and I am hoping to see it in 10.3 as well as 11. (I'm not a committer, so I only can go on what I've been told by the one who committed disabling TCC.) C-states do not change the clock speed. You will only have a small set of frequencies reported as those will be REAL clock speeds from EST, not the synthetic ones shown when using throttling/TCC, so the number of them shown by default on 10.2 will be 1/8th of when was shown by prior versions. I you do need to do this, please let us know. That should not be happening! I am now working (slowly) on a power management section of the handbook which will do a better job of explaining the issues. -- Kevin Oberman, Part time goatherd and retired Network Engineer ___ 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: ACPI Exception AE_BAD_ADDRESS in Lenovo ThinkPad S440
On Mon, Jul 20, 2015 at 5:34 AM, Juan Ramón Molina Menor lis...@club-internet.fr wrote: Le 20/07/2015 05:48, Kevin Oberman a écrit : On Sun, Jul 19, 2015 at 2:54 AM, Juan Ramón Molina Menor lis...@club-internet.fr mailto:lis...@club-internet.fr wrote: Hello. I’ve just got a Lenovo ThinkPad S440 and would like to test FreeBSD 10.2-BETA2 on it. I’ve tried with the UEFI memstick image (FreeBSD-10.2-BETA2-amd64-uefi-mini-memstick.img.xz). Unfortunately, shortly after the installer starts, the screen fills with errors related to ACPI thermal zones: ACPI Exception: AE_BAD_ADDRESS, Returned by Handler for [EmbeddedControl] (20150515/evregion-312) S (20150515/psparse-552) I have tested some features of the acpi_ibm, some do not work: fan control, for example, but I’m not sure I’m doing it right and this is an issue for later. I’ve created a PR with the information asked for in the ACPI chapter of the handbook: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201678 Best regards, Juan ___ freebsd-acpi@freebsd.org mailto: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 mailto:freebsd-acpi-unsubscr...@freebsd.org IIRC, fan control has not worked since the days of the T61. Newer BIOS end EC don't seem to work. The ACPI Exception: AE_BAD_ADDRESS has shown up on various systems for a while.It's reportedly harmless. Thanks Kevin. Could you please give me a hint for silencing these errors? They are making very hard to use the installer or live USB for testing purposes. I guess the BIOS will take care of thermal and fan control. You could edit the syslogd configuration, but that does not really make sense when running the installer. Lars' suggestion for using another VTY will work, though. When I was getting these errors, I only saw a burst of them earlier in the boot process. Sounds like you are seeing s different manifestation. :-( Brightness is finally working on most or all. Thermal should show up in hw.acpi and dev.cpu. Brightness levels are correctly shown (1-100) after loading the acpi_video kernel module, but I cannot change them. Maybe it’s the Haswell chip not responding. I’m going to try CURRENT. Haswell is still officially not supported, so it is a possibility. Brightness works on Sandy Bridge and Ivy Bridge. Last I heard, Haswell support is hoped for in September. I believe that i915 support in CURRENT is very close to that in 10-STABLE. How are you attempting to adjust brightness? Keys or the sysctl? At least on T and X systems, the rightness keys (and any other in blue) require the Fn key to work. Volume and mute are about the only ones that work without Fn on my system, as they are dedicated keys on T systems, Have you tried setting the brightness with sysctl? hw.acpi.video.lcd0.brightness. Thermal hw.acpi sysctls show bogus values, but dev.cpu works after loading the coretemp kernel module. As far as I know, most hw.acpi.thermal values are set by the system at boot and are fixed. That includes all prefaced with '_'. The ones reporting '-1' simply indicate a lack of support on your system. Here are my values: hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._CRT: 98.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.temperature: 47.0C hw.acpi.thermal.user_override: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.min_runtime: 0 A bit of good news is that support for ThinkPads usually improves fairly quickly as they tend to be the choice of several of the BSD developers, though the S series is not listed by Lenovo as a ThinkPad, but just a Lenovo Laptop. They appear to use less expensive processors (Celeron), smaller memorys and hard drives (actually eMMCs). Notably, they lack the ThinkPad TrackPoint, though a few ThinkPads did, as well, until customer feedback caused Lenovo to restore it. (Yes! I hate touchpads!) Best regards, Juan I don't have any experience on S series systems, only X and T, but I suspect the ACPI is similar. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ 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: Fan speed settings on MSI motherboard with AMD cpu
On Wed, May 6, 2015 at 9:59 AM, hiren panchasara hi...@strugglingcoder.info wrote: On 05/05/15 at 05:48P, hiren panchasara wrote: Running -head as of today and have amdtemp.ko loaded. rc.conf has: powerd_enable=YES performance_cx_lowest=Cmax economy_cx_lowest=Cmax $ sysctl hw.model hw.model: AMD FX(tm)-8350 Eight-Core Processor $ sysctl hw.ncpu hw.ncpu: 8 $ sysctl dev.cpu | grep temp dev.cpu.7.temperature: 24.6C dev.cpu.6.temperature: 24.6C dev.cpu.5.temperature: 24.6C dev.cpu.4.temperature: 24.6C dev.cpu.3.temperature: 24.6C dev.cpu.2.temperature: 24.6C dev.cpu.1.temperature: 24.6C dev.cpu.0.temperature: 24.6C (printing for cpu.0 just for example) $ sysctl dev.cpu.0 dev.cpu.0.cx_usage_counters: 10760 68435 dev.cpu.0.cx_usage: 13.58% 86.41% last 75us dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_supported: C1/1/0 C2/2/100 dev.cpu.0.freq_levels: 4000/15767 3500/13796 3400/11637 2975/10182 2800/8437 2450/7382 2100/5400 1837/4725 1575/4050 1400/3150 1225/2756 1050/2362 875/1968 700/1575 525/1181 350/787 175/393 dev.cpu.0.freq: 875 dev.cpu.0.temperature: 24.2C dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%location: handle=\_PR_.P001 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU $ sysctl hw.acpi hw.acpi.cpu.cx_lowest: C8 hw.acpi.reset_video: 0 hw.acpi.handle_reboot: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.verbose: 0 hw.acpi.s4bios: 0 hw.acpi.sleep_delay: 1 hw.acpi.suspend_state: S3 hw.acpi.standby_state: NONE hw.acpi.lid_switch_state: NONE hw.acpi.sleep_button_state: S3 hw.acpi.power_button_state: S5 hw.acpi.supported_sleep_state: S3 S4 S5 I can literally head the fan noise. Even when the box is not doing anything. Now, from the bios side, I tried a bunch of things without much success. This is what I am looking at: Power Management Setup - ACPI Standby State options - S1/S3 H/W Monitor - CPU Smart Fan Target : Disabled by default options - 40/45/50/44/60 - SYS FAN 1 Control : Default 100% options - 50%/75%/100% - PC Health Status -- CPU Temperature 55C/131F System Temperature38C/100F CPU FAN Speed 5928RPM SYS FAN 1 Speed 0 RPM?? It is definitely spinning. CPU VCore 1.312 V 3.3 V 3.312 V 5V4.970 V 12V 12.320 V Green Power - CPU Phase Control : Disabled by default options - Auto/Disabled What should be correct values for these? Any help/pointers would be great. Bah. Also, the reason I started looking into this is that I believe, cpu cooling is busted. When I compile anything with more -j values, box shuts down. I don't see any error on console or /var/log/messages but I did see the temperature going up to dev.cpu.0.temperature: 86.0C right before it shutdown. I'll probably reapply the thermal paste and see. cheers, Hiren When you reapply the paste, clean the heat sink. Dust is an excellent thermal insulator!. Does the system fan have three wires? If there are only two, the fan lacks tachometer feedback and will always read '0'. I have seen many systems that have a motherboard supporting fan speed reporting (I think all modern ones do), but lacking the slightly more expensive fan that actually provides the information. I also would suggest disabling throttling and TCC on non-current systems. 11 will FINALLY disable these by default. (I've been beating this horse since at least v7 and I am amazed that it was not dead!) While this might not help, it will leave TCC at its default of AUTO for thermal control instead of attempting to make it a power management tool. In /boot/loader.conf: hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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: HP Compaq CQ62/42 acpi
On Tue, Mar 24, 2015 at 3:23 AM, Da Rock freebsd-a...@herveybayaustralia.com.au wrote: I have 2 laptops as mentioned, 3 all amd athlon based. The 3rd is an asus which I'm relatively happy with. What I have is when I pull the AC out of it, the sysctl for cpu speed goes from 2200 to 100 or 400. Basically the system becomes rather unusable. I tried the acpi_hp module, and it now switches to 800. This is better, but barely usable still. I'd like to see a response similar to the asus if its possible; this effectively stays the same, but drops speed if nothing is happening. Ideally, I'd think that it would be better if the system adjusted speed to use requirements during operation, but neither does that. I suspect that the asus should (in theory) as it does do it on battery only; but unless I'm really hammering all the time, it just doesn't seem to happen when I'm looking at it. The settings used on all for powerd is hiadaptive for AC, adaptive for battery. If I'm doing something wrong let me know, if more data is required I'm happy to help the cause :) TIA First, let's get a bit more information. Please provide: sysctl dev.cpu.0 (on AC and then on battery) uname -a /etc/sysctl.conf (If present) /boot/loader.conf (if present) -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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: Fwd: Activating Suspend/Resume on FreeBSD 10.1
On Tue, Feb 17, 2015 at 7:40 AM, John Baldwin j...@freebsd.org wrote: On Friday, January 30, 2015 12:37:10 pm Kevin Oberman wrote: My experience is the opposite. With KMS I could run with VESA and without it I needed to pull VESA from my kernel. As of today I am running fine with KMS, i915, and vt(4) with a standard GENERIC 10-STABLE kernel. I was running KMS and vt(4) well before they were MFCed, so I don't remember when I stopped adding nooptions VESA, but I definitely used to need it to make suspect/resume work and don't any longer. In any case, trying kernel without VESA is a good idea. FYI, VESA only applies to sc(4). It is ignored for vt(4). That is why it works with vt(4). -- John Baldwin I suspected that was the case, but did not recall for sure. Thanks for the confirmation, though it does not help with the problem reported. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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: Haswell, i3, fail to acpi_throttle fail
On Mon, Jan 5, 2015 at 8:09 PM, Dan Lukes d...@obluda.cz wrote: On 6.1.2015 4:57, Kevin Oberman wrote: acpi_throttle0: ACPI CPU Throttling on cpu0 acpi_throttle0: P_CNT from P_BLK 0x1810 est0: Enhanced SpeedStep Frequency Control on cpu0 acpi_throttle1: ACPI CPU Throttling on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 Attach to cpu0 successful, but failing on non-zero cpu's ? I never tried to analyze it, but I can deny it new issue. I never seen other result as far as I remember. Dan I missed that it attached on cpu0. I think this is reality if throttling is done as it was in older CPUs. It required 3 physical pins on the CPU and predates (by some time) multi-core processors. Throttling in FreeBSD refers only to the old external form and is not related in any way to TCC, ST, or EST, all of which also do dynamic CPU Throttling, but in much more effective ways. Since throttling used physical pins, I have doubts that multi-core processors actually allocate three pins per CPU for a technique that is totally obsolete. It might be implemented as a compatibility thing and is really just TCC in disguise or they allocate three pins per chip and throttle all CPUs at once. If it is the latter, the behavior of only one CPU attaching is really more realistic than throttling per CPU. In either case, it is still best to disable it. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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: Haswell, i3, fail to acpi_throttle fail
On Mon, Jan 5, 2015 at 4:56 PM, Sean Bruno sbr...@ignoranthack.me wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 acpi_throttle0: ACPI CPU Throttling on cpu0 acpi_throttle0: P_CNT from P_BLK 0x1810 est0: Enhanced SpeedStep Frequency Control on cpu0 acpi_throttle1: ACPI CPU Throttling on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 est1: Enhanced SpeedStep Frequency Control on cpu1 acpi_throttle2: ACPI CPU Throttling on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 est2: Enhanced SpeedStep Frequency Control on cpu2 acpi_throttle3: ACPI CPU Throttling on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 est3: Enhanced SpeedStep Frequency Control on cpu3 The call to acpi_bus_alloc_gas() in acpi_throttle.c seems to be failing to attach. What should I be poking at here? Excellent! Throttling is counter-productive and always has been. It's been at least 5 years since mav@ posted his excellent wiki article on power management which demonstrated the futility of throttling. More important, even if it was useful for power management, it has long since been superseded by TCC. Intel tried to make the purpose of TCC clear by the name: Thermal Control Circuit. So it is ineffective for power management and FreeBSD still tries to use it. Looks like the vendor broke ACPI so throttling won't work. Or, maybe, Intel simply removed it as unused legacy. Don't worry. Be happy! Make sure that hint.acpi_throttle.0.disabled=1 is set in /boot/loader.conf to disable it. I'd strongly urge that you also disable P4TCC with hint.p4tcc.0.disabled=1. It will trivially improve battery life and will seriously compromise performance if powerd is enabled. It can also cause hangs with elevated C-states on some systems. If you really want to improve battery life with minimal impact on performance, set both performance_cx_lowest and economy_cx_lowest to Cmax in rc,conf. No other technique is more effective in saving power than C-states. EST helps, too, but not nearly so much and with a greater impact on performance. If you have not read it, read the wiki article at https://duckduckgo.com/l/?kh=-1uddg=https%3A%2F%2Fwiki.freebsd.org%2FTuningPowerConsumption -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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 T520: Present (-STABLE) vs. Future (-CURRENT) ACPI Support
On Thu, Jan 1, 2015 at 9:52 AM, Bigby James bigby.ja...@dimthoughts.com wrote: ADDENDUM: I just found the 'Subversion Primer' chapter in the FreeBSD Committer's Guide. Looks like this might be a good place to start. I just tried it on my T520 and it works just fine! Adrian, any chance of MFH to 10-Stable. Probably works for supported 8 and 9 versions support, but I can't confirm. It should work on any version supporting i915kms. The main patch (intel_opregion.c) applies cleanly. There are fairly large offsets for the other two, but that is it. Thanks to Henry Hu who wrote the fix and all who helped fix this long term annoyance! -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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: ThinkPad X61s suspend/resume status
On Sun, Oct 5, 2014 at 8:48 AM, Ian Smith smi...@nimnet.asn.au wrote: On Sun, 5 Oct 2014 15:24:26 +0100, Sevan / Venture37 wrote: On 5 October 2014 08:43, Ian Smith smi...@nimnet.asn.au wrote: Current configuration does not allow embedding of the file devinfo.out because of its mimetype application/octet-stream.: devinfo.out You may like to ask allanj...@freebsd.org what MIME type should be used on wiki attachments (eg https://wiki.freebsd.org/Laptops/Thinkpad_T530) as it's very handy being able to view them directly without downloading, apart from acpidumps anyway. That should be fixed now. Yes, thanks. Still need to get xorg installed to test the suspend/resume, but the initial details are up on https://wiki.freebsd.org/SuspendResume As an aside, authors of T400s and X200 there should find the reported problem with losing USB ports on resume was fixed some months ago - on stable/9 on my X200 at least - thanks again John! Worth testing with a 10 release or 11 current live env or was the fix MFC? Always worth testing, 'my X200' is a relatively small sample :) http://svnweb.freebsd.org/base?view=revisionrevision=267983 MFC'd to 10 and 9 stable on Jun 27, just 2 days after the diff applied cleanly from head and worked on 9.3-PRE through many joyous! S/R cycles. Sorry to get carried away, but that made the X200 'fit for purpose'. cheers, Ian It is also in 10.1-RC1 and has been working fine on my T520 since the MFH back in June. It's nice to finally have S/R working after total failure due to the weird VESA issue (no longer present with vt(4) and NEW_XORG) and the USB issue which was usually just an annoyance for me. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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: My laptop can't resume from suspend.
On Mon, Aug 11, 2014 at 9:20 PM, 张晓靖 zhangxiaoj...@hotmail.com wrote: Hello, I am having a problem. My laptop is lenovo's zhaoyang K47A series HM65. I used ati graphics CARDS, Use the url ( https://wiki.freebsd.org/Graphics https://wiki.freebsd.org/Graphics) the method of normal driving the graphics card. After set sysctl debug. Bootverbose = 1 sysctl debug. Acpi. Suspend_bounce = 1 sysctl debug. Acpi. Resume_beep = 1 acpiconf -s 3 The laptop can't resume, the screen no display, no beep sound. Disabling ACPI not helps to fix the problem. All files downloaded from http://url.cn/WVISGF. Output from sysctl hw.acpi hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 1 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.acline: 1 hw.acpi.battery.life: 100 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 2 hw.acpi.battery.info_expire: 5 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 62.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 95.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 100.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 2 hw.acpi.thermal.tz0._TC2: 3 hw.acpi.thermal.tz0._TSP: 100 Sincerely, ZhangXiaoJing. Have you tried building the kernel without VESA? Many laptops won't resume if you leave VESA in the kernel build. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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 support - Freebsd 10 on Sony Vaio VPCCA3C5E
On Fri, Jul 25, 2014 at 3:19 PM, Bykov Vladislav envol...@gmail.com wrote: On Fri, Jul 25, 2014 at 10:43:11PM +0200, Daniele Mazzotti wrote: The error I get anytime I try to switch between terminals is the following one drmDropMaster failed: Unknown error: -22 This is okay, if you can't switch back to tty after starting Xorg in KMS mode using old syscons driver. There is already work going on with new driver, vt. I didn't test it though. At least, suspend is works now? Try adding kern.vty=vt to /boot/loader.conf. In recent 9-stable, 10-stable, and head kernels, this is all it takes to switch to vt(4). If you have an older kernel or are running any release, you will need to rebuild the kernel using the VT configuration. The loader option may have made 9.3, but I'm not sure. I don't believe vt(4) is available for 8. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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 support - Freebsd 10 on Sony Vaio VPCCA3C5E
On Sat, Jul 26, 2014 at 9:31 AM, Kevin Oberman rkober...@gmail.com wrote: On Sat, Jul 26, 2014 at 1:46 AM, Daniele Mazzotti kappe...@gmail.com wrote: Hi, thanks again for your precious help. The suspend mode is not working yet as VESA option is still in my kernel configuration. I wanted to wait before removing it as I was not sure that intel video driver would have worked. My intention was to have a working setup with intel and being able to switch amongst vt(s) before getting rid of vesa, as I would peferer having the possibility to switch amongst vt(s) than putting my laptop to suspend. By the way I have a 10-RELEASE therefore I suspect I will have to recompile the kernel with VT. Did I get you right? I googled a bit and it seems that the only thing I have to do is to add these devices to my kernel: device vt device vt_vga This is the source I am referring to: https://wiki.freebsd.org/Newcons. Is this it? Cheers and thanks again, Daniele. Maybe and maybe not. The wiki page needs updating. Look at /sys/ARCH/conf for a VT configuration. If it is there, just build a kernel with: # make buildkernel kernconf=VT make installkernel kernconf=VT (You probably want to add a reasonable -j option for your hardware to the buildkernel.) If you don't have a VT config file, than just set the kern.vty=vt loadable in /boot/loader.conf. No need to build a new kernel. I just looked at teh repo an can say that just adding kern.vty=vt to /boot/loader.conf will work on head r 267965 or newer and 10-Stable r268366 or newer. Looks like this has not been MFCed to 9. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com 2014-07-26 8:14 GMT+02:00 Kevin Oberman rkober...@gmail.com: On Fri, Jul 25, 2014 at 3:19 PM, Bykov Vladislav envol...@gmail.com wrote: On Fri, Jul 25, 2014 at 10:43:11PM +0200, Daniele Mazzotti wrote: The error I get anytime I try to switch between terminals is the following one drmDropMaster failed: Unknown error: -22 This is okay, if you can't switch back to tty after starting Xorg in KMS mode using old syscons driver. There is already work going on with new driver, vt. I didn't test it though. At least, suspend is works now? Try adding kern.vty=vt to /boot/loader.conf. In recent 9-stable, 10-stable, and head kernels, this is all it takes to switch to vt(4). If you have an older kernel or are running any release, you will need to rebuild the kernel using the VT configuration. The loader option may have made 9.3, but I'm not sure. I don't believe vt(4) is available for 8. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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 support - Freebsd 10 on Sony Vaio VPCCA3C5E
On Mon, Jul 21, 2014 at 12:47 PM, Daniele Mazzotti kappe...@gmail.com wrote: Hi guys, I successfully managed to survive the business trip and this damn hot weekend here in the north Germany, so I am back on track! I have a few (not that nice to me) news to you all: 1. I have applied the patch, but the suspend mode (acpiconf -s 3) is not working; 2. I am still having problems with the battery. Actually when I put the pc to suspend and then try to wake it up, the screen stays black. I never had many, but I am running out of ideas! Let's review a few things here. When you resume, the screen is black. But is the system running? Do you see any disk activity? Can you ssh into the system remotely? Are you running vt(4)? Or syscons? Are you running X when you suspenf? What video driver is running? I may have missed it, but I don't think you said what graphics device you have or whether you are running NEW_XORG. While this information won't help with the battery issue, it might deal with resuming. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Fri, May 9, 2014 at 1:36 PM, Adrian Chadd adr...@freebsd.org wrote: cool! next; # pkg install intel-pcm # kldload cpuctl # pcm.x 1 See what it reports. OK. Any documentation on what this is supposed to tell me? Some of it makes perfect sense and some baffles me. I see C-states of C1 and C6 when on AC and C1, C3, and C7 when on battery (and, of course, C0). FREQ vs. AFREQ look interesting, but I'm not sure I really understand the implications. The last few lines, from PHYSICAL CORE IPC, are particularly mysterious to me. I can understand the words, but I think that they carry more significance than is obvious, at least to me. I'm not a hardware guy. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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: proposal: set default lid state to S3, performance/economy Cx states to Cmax
On Fri, May 9, 2014 at 3:25 AM, Adrian Chadd adr...@freebsd.org wrote: Hi! On 9 May 2014 02:55, Poul-Henning Kamp p...@phk.freebsd.dk wrote: In message 20140505163316.r11...@sola.nimnet.asn.au, Ian Smith writes: On Mon, 5 May 2014 06:25:21 +, Poul-Henning Kamp wrote: In message 20140505153421.w11...@sola.nimnet.asn.au, Ian Smith writes: Do we have a canonical page with all the various workarounds one should attempt in order to get suspend/resume to work ? Bits scattered all over the place. For the above there's: So based on various scattered hints, I tried booting the VT kernel, r265336, on my Thinkpad T430s and that seems to fix both Suspend/Resume and also console switching. Much appreciated! I'll keep an eye on any peripheral bogons as I used it now. Woo! Would you mind populating http://wiki.freebsd.org/Laptops with your details? Thanks! -a Excellent! This alone will save batteries and also lower the carbon footprint of FreeBSD servers! Just to clarify the various settings of *_cx_lowest in rc.conf, HIGH is obvious. At one time, LOW was also obvious, but then some vendors started shipping BIOS that skipped some C-states in different power conditions. E.g. C1, C2 and C3 when on Battery, but only C1 and C3 when on AC. This scenario was common on Sandybridge systems (like my T320). Skipping a state broke LOW as it only saw C1 when on AC. Thus, Cmax appeared. Cmax is simply C8. It is just easier ot remember then C8. The code was re-written to ignore missing C-states and try all possible C-states until C8 was reached. Why LOW was not just changed to deal with this I don't understand, but Cmax (or C8) is recommended to gain the maximum power savings from C-states. On AC power: dev.cpu.0.cx_supported: C1/1/1 C2/3/104 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 8.86% 91.13% last 2685us On battery: dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 3.09% 0.74% 96.15% last 728us Note the supported list on AC? C2/3/104 The first part, C2, is what the OS labels that second state. The next part, 3, is the ACPI number of this state. On AC, this system has no C-state 2, so FreeBSD call the ACPI state 3 C2. Oh, the last number is the number of clock cycles required to get into/out of that state. so in my case, when on battery, my CPU goes ot C2 after being halted for 80 clock cycles and C3 after 109. I hope this makes sense to everyone. I'm not really sure that it does to me! -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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 bug submission
On Sat, Apr 19, 2014 at 2:15 PM, Matt Grice m...@atarian.co.uk wrote: Hi all, First of all, let me apologise if I have sent this report to you in error. I am using the latest version of PC-BSD 10 which I believe uses a vanilla kernel (excuse the linuxism) from FreeBSD. Symptoms: Lid close does not initiate sleep, battery is not recognised and does not charge. My hardware is an Acer Extensa 5630EZ. I hope the rest of the information you might find interesting is in the output of dmesg after a verbose boot, which is attached. The output of acpidump -dt can be found here: http://pastebin.com/vpPN86qR Kind regards Matt Grice Could you provide the output of: sysctl hw.acpi acpiconf -i 0 -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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: kern/173414: [acpi] ACPI battery time incorrect
The following reply was made to PR kern/173414; it has been noted by GNATS. From: Kevin Oberman rkober...@gmail.com To: bug-follo...@freebsd.org, jb.1234a...@gmail.com Cc: Subject: Re: kern/173414: [acpi] ACPI battery time incorrect Date: Wed, 16 Apr 2014 22:11:16 -0700 --047d7b10cf8b0fcbe604f736106a Content-Type: text/plain; charset=UTF-8 Im most systems, ACPI does not return the battery lifetime when on AC power. The actual remaining time is calculated by the EC BIOS and is calculated mostly be taking the discharge rate in mW and the current capacity in mWh. As far as I know, no OS attempts to calculate the time. It is simply read from the the EC via ACPI. When plugged in to AC, the discharge rate is 0, making the calculation undefined (division by zero). Even the remaining battery time reported by ACPI is, at best, a very rough guess as discharge rate can vary dramatically depending on system load. On FreeBSD you can see detailed information on batteries with the acpiconf(8) command. acpiconf -i N where 'N' is the battery number; 0 if only one battery is present. My system on battery: esign capacity:50540 mWh Last full capacity:46660 mWh Technology:secondary (rechargeable) Design voltage:10800 mV Capacity (warn):2333 mWh Capacity (low):200 mWh Low/warn granularity:1 mWh Warn/full granularity:1 mWh Model number:42T4795 Serial number: 2654 Type:LION OEM info:SONY State:discharging Remaining capacity:96% Remaining time:2:12 Present rate:20460 mW Present voltage:11652 mV And after plugging in to AC: Design capacity:50540 mWh Last full capacity:46660 mWh Technology:secondary (rechargeable) Design voltage:10800 mV Capacity (warn):2333 mWh Capacity (low):200 mWh Low/warn granularity:1 mWh Warn/full granularity:1 mWh Model number:42T4795 Serial number: 2654 Type:LION OEM info:SONY State:high Remaining capacity:96% Remaining time:unknown Present rate:0 mW Present voltage:11648 mV Looking at the raw sysctl when on battery shows hw.acpi.battery.time: -1. This is normal. I don't see that ACPI -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com --047d7b10cf8b0fcbe604f736106a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable div dir=3DltrdivdivdivdivIm most systems, ACPI does not return = the battery lifetime when on AC power. The actual remaining time is calcula= ted by the EC BIOS and is calculated mostly be taking the discharge rate in= mW and the current capacity in mWh. As far as I know, no OS attempts to ca= lculate the time. It is simply read from the the EC via ACPI. When plugged = in to AC, the discharge rate is 0, making the calculation undefined (divisi= on by zero). Even the remaining battery time reported by ACPI is, at best, = a very rough guess as discharge rate can vary dramatically depending on sys= tem load.br br/divOn FreeBSD you can see detailed information on batteries with the= acpiconf(8) command. quot;acpiconf -i Nquot; where #39;N#39; is the ba= ttery number; 0 if only one battery is present.br/divMy system on batte= ry:br esign capacity:=C2=A0=C2=A0=C2=A0 50540 mWhbrLast full capacity:=C2=A0=C2= =A0=C2=A0 46660 mWhbrTechnology:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 sec= ondary (rechargeable)brDesign voltage:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2= =A0 10800 mVbrCapacity (warn):=C2=A0=C2=A0=C2=A0 2333 mWhbrCapacity (lo= w):=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 200 mWhbrLow/warn granularity:= =C2=A0=C2=A0=C2=A0 1 mWhbr Warn/full granularity:=C2=A0=C2=A0=C2=A0 1 mWhbrModel number:=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 42T4795brSerial number:=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 =C2=A02654brType:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0 LIONbrOEM info:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 S= ONYbrState:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 disch= arging brRemaining capacity:=C2=A0=C2=A0=C2=A0 96%brRemaining time:=C2= =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 2:12br Present rate:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 20460 mWbrPresent volt= age:=C2=A0=C2=A0=C2=A0 11652 mVbrbr/divAnd after plugging in to AC:b= rDesign capacity:=C2=A0=C2=A0=C2=A0 50540 mWhbrLast full capacity:=C2=A0= =C2=A0=C2=A0 46660 mWhbrTechnology:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 = secondary (rechargeable)br Design voltage:=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 10800 mVbrCapacity (= warn):=C2=A0=C2=A0=C2=A0 2333 mWhbrCapacity (low):=C2=A0=C2=A0=C2=A0 =C2= =A0=C2=A0=C2=A0 200 mWhbrLow/warn granularity:=C2=A0=C2=A0=C2=A0 1 mWhbr= Warn/full granularity:=C2=A0=C2=A0=C2=A0 1 mWhbrModel number:=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0 42T4795brSerial number:=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0 =C2=A02654br
Re: C-States configuration
On Fri, Apr 11, 2014 at 1:31 AM, Ian Smith smi...@nimnet.asn.au wrote: On Fri, 11 Apr 2014 00:22:43 -0700, hiren panchasara wrote: On Thu, Apr 10, 2014 at 12:18 AM, Kevin Oberman rkober...@gmail.com wrote: On Wed, Apr 9, 2014 at 11:22 AM, hiren panchasara hiren.panchas...@gmail.com wrote: On Wed, Apr 9, 2014 at 11:07 AM, Anton Sayetsky vsj...@gmail.com wrote: 2014-04-09 20:40 GMT+03:00 hiren panchasara hiren.panchas...@gmail.com: I am running -current on my T420 at r263906M debug.acpi.acpi_ca_version: 20130823 o/p of sysctl -a | grep acpi - http://bpaste.net/show/199806/ and I have following in my rc.conf: performance_cx_lowest=Cmax economy_cx_lowest=Cmax But I still get: % sysctl -a | grep cx_lowest hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_lowest: C1 dev.cpu.1.cx_lowest: C1 dev.cpu.2.cx_lowest: C1 dev.cpu.3.cx_lowest: C1 And I can do: # sysctl dev.cpu.0.cx_lowest=Cmax dev.cpu.0.cx_lowest: C1 - C8 that tells me that Cmax is C8. % sysctl -d dev.cpu.0.cx_lowest dev.cpu.0.cx_lowest: lowest Cx sleep state to use I was expecting cx_lowest to be set to C8 because of rc.conf config I have. What am I missing here? cheers, Hiren Try to set LOW instead of Cmax. I will try it again. Interestingly enough, on an amd machine, it worked as I expected with a bit more current version of -head but same version of acpica: debug.acpi.acpi_ca_version: 20130823 cpus came up with cx_lowest set to C8 with Cmax in rc.conf cheers, Hiren Setting Cx values is a bit confusing. Things may not mean what you think. CMax is always C8 because this is the largest possible value of a Cx state, not because C8 is actually available.The reason for this is that some systems have non-sequencial Cx states. That is the maximum value my be C5, but C2 may not be available. So the idea is to allow ANY C-state up to the maximum. LOWEST works well as long as no states are skipped. If they are, you are limited to the states before the skipped state. To see the actual available states, look at dev.cpu.0.cx_supported. The recommended value for best power savings is :Cmax. That will allow skipping over missing C-states. Also, the available states often differ between AC power and battery. On my T320: AC dev.cpu.0.cx_supported: C1/1/1 C2/3/104 Battery dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109 AC: hw.acpi.cpu.cx_lowest: C8 dev.cpu.0.cx_supported: C1/1/1 C2/3/104 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 8.23% 91.76% last 38us Battery: hw.acpi.cpu.cx_lowest: C8 dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 12.35% 3.22% 84.42% last 3088us So, pretty similar on my T420 with following in rc.conf performance_cx_lowest=Cmax economy_cx_lowest=Cmax How do I know what C-state cpu0 is in, at any point in time? Or thats not how things work? smithi@x200:~ % x200stat Fri Apr 11 18:24:19 EST 2014 dev.cpu.0.freq: 200 0.00% 2.47% 97.51% last 520us 0.01% 2.22% 97.75% last 817us dev.acpi_ibm.0.fan_speed: 3391 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.thermal: 40 44 -1 41 36 -1 35 -1 hw.acpi.thermal.tz0.temperature: 40.0C hw.acpi.thermal.tz1.temperature: 36.0C State: high Remaining capacity: 96% Remaining time: unknown Present rate: 0 mW Present voltage:12329 mV I'm not sure that 'at any point in time' could be very meaningful. The above shows sysctl -n dev.cpu.0.cx_usage sysctl -n dev.cpu.1.cx_usage at one time - or rather at the two relativelty close times that each of those sysctls was retrieved, both covering less than 1ms. Heisenberg's Uncertainty Principle would most likely apply to any closer examination, but you could chase down where the statistics are accumulated, somewhere in cpufreq IIRC. Since hte state changes very quickly and quite often, I agree with Ian. Don't know hat I can quite attribute it ti Heisengerg, but I can agree that trying ot look at it will distort the results, probably significantly. the fact that it is reported over times of less than 10 ms makes it clear that this changes a LOT. Adrian Chadd posted a patch to count the changes. Here is what I see after 10 seconds while quiescent: sysctl dev.cpu.0 | grep usage dev.cpu.0.cx_usage: 8.43% 2.51% 89.05% last 1761us dev.cpu.0.cx_usage_counters: 121 36 1277 And while compiling wxgtk (i.e. the CPUs are all at near 100%): sysctl dev.cpu.0 | grep usage dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 117us dev.cpu.0.cx_usage_counters: 7 0 0 As you can see, the CPU is only occasionally halted while the compile is going on and never long enough to get past C1. When idle
Re: C-States configuration
On Wed, Apr 9, 2014 at 11:22 AM, hiren panchasara hiren.panchas...@gmail.com wrote: On Wed, Apr 9, 2014 at 11:07 AM, Anton Sayetsky vsj...@gmail.com wrote: 2014-04-09 20:40 GMT+03:00 hiren panchasara hiren.panchas...@gmail.com : I am running -current on my T420 at r263906M debug.acpi.acpi_ca_version: 20130823 o/p of sysctl -a | grep acpi - http://bpaste.net/show/199806/ and I have following in my rc.conf: performance_cx_lowest=Cmax economy_cx_lowest=Cmax But I still get: % sysctl -a | grep cx_lowest hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_lowest: C1 dev.cpu.1.cx_lowest: C1 dev.cpu.2.cx_lowest: C1 dev.cpu.3.cx_lowest: C1 And I can do: # sysctl dev.cpu.0.cx_lowest=Cmax dev.cpu.0.cx_lowest: C1 - C8 that tells me that Cmax is C8. % sysctl -d dev.cpu.0.cx_lowest dev.cpu.0.cx_lowest: lowest Cx sleep state to use I was expecting cx_lowest to be set to C8 because of rc.conf config I have. What am I missing here? cheers, Hiren Try to set LOW instead of Cmax. I will try it again. Interestingly enough, on an amd machine, it worked as I expected with a bit more current version of -head but same version of acpica: debug.acpi.acpi_ca_version: 20130823 cpus came up with cx_lowest set to C8 with Cmax in rc.conf cheers, Hiren Setting Cx values is a bit confusing. Things may not mean what you think. CMax is always C8 because this is the largest possible value of a Cx state, not because C8 is actually available.The reason for this is that some systems have non-sequencial Cx states. That is the maximum value my be C5, but C2 may not be available. So the idea is to allow ANY C-state up to the maximum. LOWEST works well as long as no states are skipped. If they are, you are limited to the states before the skipped state. To see the actual available states, look at dev.cpu.0.cx_supported. The recommended value for best power savings is :Cmax. That will allow skipping over missing C-states. Also, the available states often differ between AC power and battery. On my T320: AC dev.cpu.0.cx_supported: C1/1/1 C2/3/104 Battery dev.cpu.0.cx_supported: C1/1/1 C2/2/80 C3/3/109 I am unsure why you are only seeing C1. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ 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: Xeon E5 cpu work in low status
On Mon, Nov 4, 2013 at 12:46 AM, 李森 lisen1...@gmail.com wrote: hi,all: the cpu of my machine is : Intel(R) Xeon(R) CPU E5-2643 0 @ 3.30GHz. after a reboot. The cpu freq is : sysctl dev.cpu.0.freq dev.cpu.0.freq: 1200 i didn't set any power savings config in rc.conf. How can i fix this? It's not clear what is broken. Is the server busy? Is there some reason to expect it to be running at full clock-rate? What is the content of dev.cpu.0.freq_levels? By default, FreeBSD runs powerd and that will, by default, throttle back the clock when the system is not busy. I think that this is a bad thing., but it is not a bug. It's by design. I really think, based on my own testing, research and a major NSF computer center (SDSC), and work done by mav@ which can be found on the FreeBSD wiki ( https://wiki.freebsd.org/TuningPowerConsumption), those power management tools are broken by design a they are actually there for thermal control, not power management and are, at best, break-even, and in most cases are actually a loser in both power savings and system performance. (There are a very few edge cases where they can be beneficial, but as a side effect for very specific loads under fairly unusual circumstances.) To turn off these (mis)features, add the following to /boot/loader.conf: # Disable CPU throttling hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 rant All real power management is through the use of EST and CPU sleep (CX) states. These can provide a big power win at minimal performance impact. Unfortunately CX states and throttling lay very badly together, probably because processor designers don't think that TCC and throttling are for power management, so are not an issue. For reasons that have always baffled me, rather than disable the inappropriate use of thermal management as power management, we disable the most effective power management tools by default. performance_cx_lowest=HIGH # Online CPU idle state economy_cx_lowest=HIGH # Offline CPU idle state Even the comments are confusing: what do Online and Offline mean? Offline means running on battery and online means AC power. In any case, it's not clear that there is any issue with your system other than that, by default, FreeBSD tries to really, really hard to manage power as badly as humanly possible. /rant -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ 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)
On Sat, Aug 31, 2013 at 9:53 AM, Adrian Chadd adr...@freebsd.org wrote: Ok. I'm glad this is actually working for people. But now comes the hard bit - figuring out why the VESA driver is breaking resume. :( I actually use VESA text modes in console mode so I'll take a look but I can't promise anything. Who actually has experience with the VESA code and may be able to help? Does anyone know? Thanks, -adrian Of course this is the real issue. Removing VESA is just a band-aid and will become a problem once newcons makes it out the door (any day now). I'd like to try to figure out the scope of the problem, if possible. In most (all?) reports, removing VESA has worked on Thinkpads. I think I have seen reports that it works on other platforms, but I'm not positive. I also believe that it has been reported to not work for attempts to suspend/resume when in text mode... only when in X. (I guess I can test this myself.) For almost four years all vesa commits were by jkim. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ 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)
On Fri, Aug 30, 2013 at 3:12 PM, Laura Marie Feeney lmfee...@sics.sewrote: On 08/30/13 23:53, Sergey A. Osokin wrote: Maybe try x11perf before and after? 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). I'm also using i3 now, previously it was fvwm2 earlier with slowdown. Hmm... Gleb and Luara, could you try x11-wm/i3 for suspend/resume trick and check slowdown? I was using twm (like i3, it's very lightweight window manager and actually my personal preference for everyday use) and saw little or no slowdown under normal use. (I was able to get the cpu load to spike quite a bit higher by scrolling an xterm as fast as I could, but that's not very normal.) Will try i3 tomorrow. Perhaps cairo-perf with some common set of traces would be a good comparison? Laura Woo hoo! for the first time in the 2+ years I've owned it I can resume my T520. Removing VESA from the kernel did the trick! After resume, X was rather slow for some operations. Not painfully slow, but noticeably slower than normal. I did nothing to the system but ran x11perf. After about 2.5 hours it completed. When I resumed use of the system, it seems to be back to normal. No idea what made it change. I am running Gnome2, so it is a very heavyweight system running 9.2-Stable from last Wednesday (r255013). I'm delighted to finally have a working resume. It's been YEARS since I've had it that works on any of my Thinkpads (600E, T43, T520). -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ 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: Hyper mode for powerd
On Thu, Jul 4, 2013 at 7:12 PM, Warren Block wbl...@wonkity.com wrote: Attached is a proposed patch for -head that adds a hyper mode to powerd. Instead of slewing like the adaptive modes, this mode drops all the way to the lowest frequency when the system is idle, and jumps all the way to the highest frequency when there is any load. Subjectively, it seems more responsive for desktop use than hiadaptive mode. That's hard to benchmark. Power usage is another question. This mode might use less power than the adaptive modes, but that's also difficult to benchmark. Comments welcome. I have not looked at the patch yet, but it should really only use EST and not TC or throttling as many systems, when throttled and put into deep sleep modes (C3 or lower) will hang. Studies have shown (sorry, but since I retired I have lost the papers on the subject) that best power efficiency is when the system is operated at minimum performance when idle and maximum when not, so this is probably a good idea for most any non-mobile system and most mobile system applications. There are cases when you may be willing to pay a response price to keep the battery alive a little longer when performing ongoing activities that don't need large amounts of CPU like listening to music. As I have often pointed out, TCC and throttling were never intended for power management and I strongly recommend that they be disabled. OTOH, deep sleep states are huge winners and should be used to their maximum. EST is a smaller win, but can make a system seem sluggish, especially when added to TCC or throttling. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ 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_termal sysctl interface strange temperature value
On Sun, Feb 24, 2013 at 5:40 PM, Dmitry Sarkisov ait.ml...@gmail.comwrote:
Hello,
I'm trying to poll cpu temperature with the following code:
#define TEMP_MIB hw.acpi.thermal.tz0.temperature
size_t len;
int t;
len = sizeof(t);
bzero(temp, len);
if(sysctlbyname(TEMP_MIB, t, len, NULL, 0) == -1 ){
perror(sysctl);
return -1;
}else{
printf(%d\n, t);
}
Values I'm geting are like this:
3732
while actual is:
sysctl -n hw.acpi.thermal.tz0.temperature
55.0C
ACPI does not report temperature in degrees Celsius, but in tenths of a
degree Kelvin. So both agree.
When ACPI was first introduced into head (v5?), the sysctl reported the
raw number, but the code was later modified to provide a more human
friendly value. Directly probing ACPI for temperature still returns the raw
value.
--
R. Kevin Oberman, Network Engineer
E-mail: rkober...@gmail.com
___
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: what is required to support a new laptop?
On Mon, Jan 28, 2013 at 11:06 AM, Eitan Adler li...@eitanadler.com wrote: On 28 January 2013 06:49, Lars Engels lars.eng...@0x20.net wrote: On Fri, Jan 25, 2013 at 08:55:40AM -0500, Eitan Adler wrote: Hi all, I recently purchased a Lenovo Y530 and attempted to use some of the ACPI features (brightness of backlight, etc.) I attempted to load acpi_ibm but devd reported no events (running with devd -dD). What information might be useful to help support this laptop? Did you set dev.acpi_ibm.0.events=1? I don't see this as an option at all. Setting dev.acpi_ibm.0.events=1 still does not cause the brightness functions to generate events. Could the initialmask and or availmask tie into this in some way? -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: what is required to support a new laptop?
On Sun, Jan 27, 2013 at 4:20 PM, Erich Dollansky erichsfreebsdl...@alogt.com wrote: Hi, On Sun, 27 Jan 2013 18:24:36 -0500 Eitan Adler li...@eitanadler.com wrote: On 27 January 2013 12:59, Kevin Oberman kob6...@gmail.com wrote: On Fri, Jan 25, 2013 at 9:25 PM, Eitan Adler li...@eitanadler.com wrote: On 25 January 2013 14:51, Kevin Oberman kob6...@gmail.com wrote: There are several threads in the archives of acpi@ and mobile@ discussing this. Most things are pretty easy. Use xev to find the events generated by the volume buttons. I'm handling the volume keys with xbindkeys. Mute and the ThinkLight (if your system has one) should work as is. Mute does not function - I am using xbindkeys to handle it. The video key generates no event. Brightness is a bit bigger issue as Lenovo has completely revamped it These buttons don't generate events. :-( Where *should* they be handled? How do they work on windows? FWIW they seem to change hw.acpi.video.brightness, but change nothing visible on the screen. You can install the acpi_call port and use it to set the brightness, but it is a pain as it does not allow for setting incremental changes, only absolute values.(16 of them). Any pointers for what to look at? I have no idea what I'm doing w.r.t. computers ^W ACPI. Install sysutils/acpi_call kldload acpi_call acpi_call -p '\VBRC' -i [0-15] There seem to be some differences on the range, but in my T530 0=off and 15=full. Unfortunately, the brightness functions do not generate X events and I have not seen any posts on how to tie them to anything to adjust brightness. [2881 root@gravity ~ ]#acpi_call -p '\VBRC' -i 1 Unknown object type '0' [2882 root@gravity ~ !5!]#acpi_call -p '\VBRC' -i 2 Unknown object type '0' [2883 root@gravity ~ !5!]#acpi_call -p '\VBRC' -i 0 Unknown object type '0' [2884 root@gravity ~ !5!]#acpi_call -p '\VBRC' -i 15 Unknown object type '0' I can confirm that this works on an X220: acpi_call -p '\VBRC' -i $value It also works lower case for me. Erich Probably won't help, but can you confirm that acpi_call is loaded (kldstat)? -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: what is required to support a new laptop?
On Fri, Jan 25, 2013 at 6:12 AM, Glen Barber g...@freebsd.org wrote: On Fri, Jan 25, 2013 at 09:09:53AM -0500, Glen Barber wrote: On Fri, Jan 25, 2013 at 08:55:40AM -0500, Eitan Adler wrote: Hi all, I recently purchased a Lenovo Y530 and attempted to use some of the ACPI features (brightness of backlight, etc.) I attempted to load acpi_ibm but devd reported no events (running with devd -dD). What information might be useful to help support this laptop? Where are events such as fn+pgup (brightness up) reported? http://freebsd.org/~eadler/files/asl.y530.gz - acpidump -dt if this may be useful. Try apci_toshiba.ko. Erm.. Sorry, that may not help. I'm confusing thinkpad for toshiba. Sorry for the noise... There are several threads in the archives of acpi@ and mobile@ discussing this. Most things are pretty easy. Use xev to find the events generated by the volume buttons. Mute and the ThinkLight (if your system has one) should work as is. Brightness is a bit bigger issue as Lenovo has completely revamped it These buttons don't generate events. :-( You can install the acpi_call port and use it to set the brightness, but it is a pain as it does not allow for setting incremental changes, only absolute values.(16 of them). Google for FreeBSD acpi x220 notes. That should find the thread with the details. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: improve cx_lowest logic
On Tue, Sep 4, 2012 at 11:28 PM, Andriy Gapon a...@freebsd.org wrote: on 25/08/2012 13:52 Vitaly Magerya said the following: On 08/07/2012, Andriy Gapon a...@freebsd.org wrote: I would like to propose the following change for review and testing: http://people.freebsd.org/~avg/acpi_cpu_cx_lowest.diff On 13/07/2012, Andriy Gapon a...@freebsd.org wrote: Many thanks to all who reviewed and tested! I've just committed this change. Andriy, will this change be available in 9.1? I'm not seeing it in 9.1-RC1, and using my previous workarounds now that a proper solution is available is a pain. Vitaly, sorry for taking so long to reply. I've managed to sneak the Cmax commit into releng/9.1 branch, so it should appear in 9.1-RC2. Thank you for prodding me about that. Thanks so much! This should finally make Cx states work on my ThinkPad! I really appreciate it. Guess it's time to do my weekly upgrade of this system. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: improve cx_lowest logic
On Wed, Sep 5, 2012 at 9:12 AM, Andriy Gapon a...@freebsd.org wrote: on 05/09/2012 18:17 Kevin Oberman said the following: Thanks so much! This should finally make Cx states work on my ThinkPad! I really appreciate it. Guess it's time to do my weekly upgrade of this system. I haven't sneaked in that other commit :-( Oops! :-( Oh, well. At least it should make it to /base/stable/9 soon. Right??? (I only run release/ or releng/ or for an occasional test.) -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: improve cx_lowest logic
On Wed, Sep 5, 2012 at 9:32 AM, Andriy Gapon a...@freebsd.org wrote: on 05/09/2012 19:23 Kevin Oberman said the following: On Wed, Sep 5, 2012 at 9:12 AM, Andriy Gapon a...@freebsd.org wrote: on 05/09/2012 18:17 Kevin Oberman said the following: Thanks so much! This should finally make Cx states work on my ThinkPad! I really appreciate it. Guess it's time to do my weekly upgrade of this system. I haven't sneaked in that other commit :-( Oops! :-( Oh, well. At least it should make it to /base/stable/9 soon. Right??? (I only run release/ or releng/ or for an occasional test.) It's already in stable/9 :) Ahh! I now see C3/109, but I see some strange behavior. When on AC power, only C1/1 and C2/104 are available, but cx_lowest is C3, even though C3 is not available. If I switch to battery, C1/1, C2/80 and C3/109 are available (???), but cx_lowest is set to C2. I find the Cx value sets a bit odd, but the setting of cx_lowest appears to be a bug, at least to me. I can manually set cx_lowest to C3 and I actually use C3. My suspicion is that there is either a race or a logic issue where x_lowest is reset to the lowest value before the available Cx values are set, so cx_lowest is always set the the lowest Cx state from the previous power configuration. (This is a guess, but it fits what I am seeing very well.) -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: [CFT] acpi_ibm event handler
On Fri, Jun 15, 2012 at 6:30 PM, freegih free...@gmail.com wrote:
Thanks, it looks good, works on my X61, I also have SL500 , the lenovo tp.
can somebody make acpi_ibm works on the Lenovo ThinkPads ?
On 2012/06/16 01:58, Mitsuru IWASAKI wrote:
Hi,
I've noticed that brightness up/down keys on my Thinkpad X61 doesn't
work. Checking DSDT of X61, many changes were found comparing with
older Thinkpad (eg. X41). So I made the patches against acpi_ibm(4)
as a workaround so that devd(8) events are handled by event handler in
acpi_ibm(4).
the patches at:
http://people.freebsd.org/~iwasaki/acpi/acpi_ibm-20120615.diff
With the following sysctl setting, now brightness control is working :)
sysctl dev.acpi_ibm.0.events=1
sysctl dev.acpi_ibm.0.handlerevents='0x04 0x10 0x11'
Thanks!
Lots of stiff has been moved from ACPI to the EC, so the changes are
pretty significant. The easiest is to add LEN0068 to the list of
ibm_ids in /usr/src/sys/dev/acpi_support/icpi_ibm.c:
static char*ibm_ids[] = {IBM0068,LEN0068, NULL};
That will get a few things like the ThinkLight and several other
things. It won't provide volume or brightness control, though. You can
fix volume by defining the keys XF86AudioLowerVolume and
XF86AudioRaiseVolume to execute the mixer command:
/usr/sbin/mixer vol -5:-5 and /usr/sbin/mixer vol +5:+5 This can be
done in most desktops.
Brightness can be adjusted using acpi_call -p '\VBRC' -i n (where n
is 0-15). acpi_call must be installed from ports. But this command
sets absolute brightness, so it can't raise or lower the brightness
unless you have the current value and I don't know how to get that.
This is the case on my T520.
--
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.com
___
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: How can I help with thinkpad x220 issues?
On Tue, May 29, 2012 at 2:38 AM, Natacha Porté nat...@instinctive.eu wrote: Hello, on Wednesday 23 May 2012 at 10:05, Любомир Григоров wrote: Well, brightness works with the command line, sooo I think it has to be mapped to the hardware keys. There is a long thread where I discussed this with a couple other members (toward the bottom for the recent brightness discussion). http://comments.gmane.org/gmane.os.freebsd.current/135827 Thanks a lot for pointing this discussion, I found there information more up-to-date than what I previously found. In particular, according to what I understand from http://marc.info/?l=freebsd-currentm=133341372825281w=2 helping with the brightness seems to require a quite broad understanding of ACPI and/or EC, and maybe also a good overview of how things work currently in FreeBSD. Both of these seem to be far beyond anything that I can reach in a reasonable amount of time :-( Still, my offer stands, and if anybody can think of anything useful I can do or learn, please don't hesitate to tell me so. Good news is that Konstantin's latest patch works with FreeBSD 9-STABLE so no longer need to run HEAD. I would love to see resume work, though. I'm not sure whether this is the right place to ask for such help, but I haven't been able to get it working as much as I would like. More specifically, I checked out 9-STABLE, and merged all 14 commits listed at the end of http://wiki.freebsd.org/Intel_GPU I then added WITH_NEW_XORG=YES and WITH_KMS=YES to /etc/make.conf and compiled x11/xorg metaport with default options, except for KMS=on for graphics/libdrm. It seems that adding i915kms in /boot/loader.conf freezes the system, but that's only a minor inconvenience. Now I kldload it just before starting slim. The screen resolution is correctly detected, everything in Xorg.0.log and `dmesg` looks fine, DRI2 is enabled, xdriinfo reports i915 dri activated for the screen. Well, all in all, as far as I can tell everything is fine, except I don't see any acceleration : it takes up to a whole second for my rxvt-unicode to refresh its 80x56 window (whether scrolling or switching tmux window, and no image background is set), opaque window moving is very jumpy (but I can live without it), and armagetron runs at 7-12 fps (to test whether 3D acceleration fared better than 2D acceleration). Do you see the same behavior? Would you have any idea on how to diagnose whatever could be wrong? Have you applied the kernel patches? Installing the new Xorg stuff after building them with the two lines added to make.conf. only builds the tools to send the appropriate requests to the kernel, but, without the patches, the kernel does not know how to deal with them. The required kernel changes have been committed to HEAD,but not to 9-Stable, so y0ou still need to manually apply these. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: How can I help with thinkpad x220 issues?
On Fri, May 25, 2012 at 10:10 PM, Pierre-Luc Drouin pldro...@pldrouin.net wrote: On Friday, May 25, 2012, Kevin Oberman wrote: On Wed, May 23, 2012 at 11:55 PM, Lars Engels lars.eng...@0x20.net wrote: On Wed, May 23, 2012 at 03:19:14PM -0700, Kevin Oberman wrote: On Wed, May 23, 2012 at 8:13 AM, Natacha Porté nat...@instinctive.eu wrote: Hello, I happen to be the owner of a brand new Lenovo Thinkpad X220. From a recent thread here I gather it almost works with FreeBSD, and the remaining problems are screen brightness and screen left unpowered at resume. Is that right? So my question is, how can I help make progress in any of these area? (though I admit I'm more interested in having the brightness problem solved than the resume one) I don't know anything about ACPI or about FreeBSD or Linux internals, but I'm quite proficient in C and somewhat used to navigate in unknown huge code bases. So I guess the first steps to help would be to first learn stuff. However I don't have much time available. I guess FreeBSD 11 would reach end-of-life before I could reach a level of understanding I find satisfying (though I admit I have high standards there), so I would have to prioritize. So my question is rather *what* should I learn to provide help as soon as possible? For example, if the brightness issue is just a matter of extracting the right numbers from linux kernel code and plug them into FreeBSD, I probably won't need to learn anything more about ACPI than what I would gather looking at the code. I guess if it was that simple someone would have already done it, but that illustrate well my point about prioritizing learning. Or is the barrier of entry too high for me to be of any use? If it has not been committed, the minor fix to make acpi_ibm work on modern ThinkPads needs to be committed. Once done, the issues mentioned need to be addressed.This includes getting brightness to be setable from both the keypad hot-keys and from applications. ATM, I can set the brightness, but making the hot-keys work will require the ability to extract the current level so that it may be adjusted plus/minus one. The other issue is volume control keys don't work. I suspect it will be similar to brightness, but I don't know just how to figure it out. I should also mention that I don't have an X220. I have a T520, but the issues seem to be identical, so fixing one will probably fix a lot of recent ThinkPads. About the key: Did you try loading acpi_ibm, sysctl dev.acpi_ibm.0.events=1, cat /var/run/devd.pipe and then press the keys. Does anything show up? After adding LEN0068 ti the ACPI IDs, I tried this and I get no ACPI event when pressing either button, but I do get regular key press events: KeyPress event, serial 30, synthetic NO, window 0x461, root 0x121, subw 0x0, time 166670035, (96,121), root:(100,750), state 0x0, keycode 176 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x461, root 0x121, subw 0x0, time 166670185, (96,121), root:(100,750), state 0x0, keycode 176 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 33, synthetic NO, window 0x461, root 0x121, subw 0x0, time 166927339, (98,0), root:(102,629), state 0x0, keycode 174 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x461, root 0x121, subw 0x0, time 166927451, (98,0), root:(102,629), state 0x0, keycode 174 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False I can set these up as hot keys and issue a command, but I have no idea what I can set to adjust the hardware volume. But I will also need to read out the current volume so I know what value to which is should be set. (Same issue as with brightness.) -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com You should be able to bind these keys to commands such as mixer vol +5 amd mixer vol -5 Actually, to get it to work I had to bind to /usr/sbin/mixer vol +5:+5 and /usr/sbin/mixer vol -5:-5 Just doing +5 set the volume to 5% (absolute) and -5 did nothing. Slightly odd, but I do have it working, now, t least when Gnome is being used. Thanks! -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd
Re: How can I help with thinkpad x220 issues?
On Sat, May 26, 2012 at 5:45 AM, Lars Engels lars.eng...@0x20.net wrote: On Fri, May 25, 2012 at 08:25:47PM -0700, Kevin Oberman wrote: On Wed, May 23, 2012 at 11:55 PM, Lars Engels lars.eng...@0x20.net wrote: On Wed, May 23, 2012 at 03:19:14PM -0700, Kevin Oberman wrote: On Wed, May 23, 2012 at 8:13 AM, Natacha Porté nat...@instinctive.eu wrote: Hello, I happen to be the owner of a brand new Lenovo Thinkpad X220. From a recent thread here I gather it almost works with FreeBSD, and the remaining problems are screen brightness and screen left unpowered at resume. Is that right? So my question is, how can I help make progress in any of these area? (though I admit I'm more interested in having the brightness problem solved than the resume one) I don't know anything about ACPI or about FreeBSD or Linux internals, but I'm quite proficient in C and somewhat used to navigate in unknown huge code bases. So I guess the first steps to help would be to first learn stuff. However I don't have much time available. I guess FreeBSD 11 would reach end-of-life before I could reach a level of understanding I find satisfying (though I admit I have high standards there), so I would have to prioritize. So my question is rather *what* should I learn to provide help as soon as possible? For example, if the brightness issue is just a matter of extracting the right numbers from linux kernel code and plug them into FreeBSD, I probably won't need to learn anything more about ACPI than what I would gather looking at the code. I guess if it was that simple someone would have already done it, but that illustrate well my point about prioritizing learning. Or is the barrier of entry too high for me to be of any use? If it has not been committed, the minor fix to make acpi_ibm work on modern ThinkPads needs to be committed. Once done, the issues mentioned need to be addressed.This includes getting brightness to be setable from both the keypad hot-keys and from applications. ATM, I can set the brightness, but making the hot-keys work will require the ability to extract the current level so that it may be adjusted plus/minus one. The other issue is volume control keys don't work. I suspect it will be similar to brightness, but I don't know just how to figure it out. I should also mention that I don't have an X220. I have a T520, but the issues seem to be identical, so fixing one will probably fix a lot of recent ThinkPads. About the key: Did you try loading acpi_ibm, sysctl dev.acpi_ibm.0.events=1, cat /var/run/devd.pipe and then press the keys. Does anything show up? After adding LEN0068 ti the ACPI IDs, I tried this and I get no ACPI event when pressing either button, but I do get regular key press events: KeyPress event, serial 30, synthetic NO, window 0x461, root 0x121, subw 0x0, time 166670035, (96,121), root:(100,750), state 0x0, keycode 176 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x461, root 0x121, subw 0x0, time 166670185, (96,121), root:(100,750), state 0x0, keycode 176 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 33, synthetic NO, window 0x461, root 0x121, subw 0x0, time 166927339, (98,0), root:(102,629), state 0x0, keycode 174 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x461, root 0x121, subw 0x0, time 166927451, (98,0), root:(102,629), state 0x0, keycode 174 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False Hmm, okay, that's not too bad. At least the keys are recognized. I can set these up as hot keys and issue a command, but I have no idea what I can set to adjust the hardware volume. But I will also need to read out the current volume so I know what value to which is should be set. (Same issue as with brightness.) Do you have dev.acpi_ibm.0.lcd_brightness and .volume? If you cou can write a script that raises / lowers the values with sysctl. Unfortunately newer Lenovo systems no longer play correctly with the acpi_ibm module. Some things do work, but brightness, volume, and fan speed control don't use the same ACPI methods as older units. Brightness now uses /VBRC instead of /_BCL and can be accessed via the call_acpi port do do raw ACPI operations. See http://lists.freebsd.org/pipermail/freebsd-current/2012-March/032511.html Of course, you need to add LEN0068 to the list of IDs to get
Re: How can I help with thinkpad x220 issues?
On Wed, May 23, 2012 at 11:55 PM, Lars Engels lars.eng...@0x20.net wrote: On Wed, May 23, 2012 at 03:19:14PM -0700, Kevin Oberman wrote: On Wed, May 23, 2012 at 8:13 AM, Natacha Porté nat...@instinctive.eu wrote: Hello, I happen to be the owner of a brand new Lenovo Thinkpad X220. From a recent thread here I gather it almost works with FreeBSD, and the remaining problems are screen brightness and screen left unpowered at resume. Is that right? So my question is, how can I help make progress in any of these area? (though I admit I'm more interested in having the brightness problem solved than the resume one) I don't know anything about ACPI or about FreeBSD or Linux internals, but I'm quite proficient in C and somewhat used to navigate in unknown huge code bases. So I guess the first steps to help would be to first learn stuff. However I don't have much time available. I guess FreeBSD 11 would reach end-of-life before I could reach a level of understanding I find satisfying (though I admit I have high standards there), so I would have to prioritize. So my question is rather *what* should I learn to provide help as soon as possible? For example, if the brightness issue is just a matter of extracting the right numbers from linux kernel code and plug them into FreeBSD, I probably won't need to learn anything more about ACPI than what I would gather looking at the code. I guess if it was that simple someone would have already done it, but that illustrate well my point about prioritizing learning. Or is the barrier of entry too high for me to be of any use? If it has not been committed, the minor fix to make acpi_ibm work on modern ThinkPads needs to be committed. Once done, the issues mentioned need to be addressed.This includes getting brightness to be setable from both the keypad hot-keys and from applications. ATM, I can set the brightness, but making the hot-keys work will require the ability to extract the current level so that it may be adjusted plus/minus one. The other issue is volume control keys don't work. I suspect it will be similar to brightness, but I don't know just how to figure it out. I should also mention that I don't have an X220. I have a T520, but the issues seem to be identical, so fixing one will probably fix a lot of recent ThinkPads. About the key: Did you try loading acpi_ibm, sysctl dev.acpi_ibm.0.events=1, cat /var/run/devd.pipe and then press the keys. Does anything show up? After adding LEN0068 ti the ACPI IDs, I tried this and I get no ACPI event when pressing either button, but I do get regular key press events: KeyPress event, serial 30, synthetic NO, window 0x461, root 0x121, subw 0x0, time 166670035, (96,121), root:(100,750), state 0x0, keycode 176 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x461, root 0x121, subw 0x0, time 166670185, (96,121), root:(100,750), state 0x0, keycode 176 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 33, synthetic NO, window 0x461, root 0x121, subw 0x0, time 166927339, (98,0), root:(102,629), state 0x0, keycode 174 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x461, root 0x121, subw 0x0, time 166927451, (98,0), root:(102,629), state 0x0, keycode 174 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False I can set these up as hot keys and issue a command, but I have no idea what I can set to adjust the hardware volume. But I will also need to read out the current volume so I know what value to which is should be set. (Same issue as with brightness.) -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: How can I help with thinkpad x220 issues?
On Wed, May 23, 2012 at 8:13 AM, Natacha Porté nat...@instinctive.eu wrote: Hello, I happen to be the owner of a brand new Lenovo Thinkpad X220. From a recent thread here I gather it almost works with FreeBSD, and the remaining problems are screen brightness and screen left unpowered at resume. Is that right? So my question is, how can I help make progress in any of these area? (though I admit I'm more interested in having the brightness problem solved than the resume one) I don't know anything about ACPI or about FreeBSD or Linux internals, but I'm quite proficient in C and somewhat used to navigate in unknown huge code bases. So I guess the first steps to help would be to first learn stuff. However I don't have much time available. I guess FreeBSD 11 would reach end-of-life before I could reach a level of understanding I find satisfying (though I admit I have high standards there), so I would have to prioritize. So my question is rather *what* should I learn to provide help as soon as possible? For example, if the brightness issue is just a matter of extracting the right numbers from linux kernel code and plug them into FreeBSD, I probably won't need to learn anything more about ACPI than what I would gather looking at the code. I guess if it was that simple someone would have already done it, but that illustrate well my point about prioritizing learning. Or is the barrier of entry too high for me to be of any use? If it has not been committed, the minor fix to make acpi_ibm work on modern ThinkPads needs to be committed. Once done, the issues mentioned need to be addressed.This includes getting brightness to be setable from both the keypad hot-keys and from applications. ATM, I can set the brightness, but making the hot-keys work will require the ability to extract the current level so that it may be adjusted plus/minus one. The other issue is volume control keys don't work. I suspect it will be similar to brightness, but I don't know just how to figure it out. I should also mention that I don't have an X220. I have a T520, but the issues seem to be identical, so fixing one will probably fix a lot of recent ThinkPads. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: x220 notes
2012/4/5 Любомир Григоров nm.kn...@gmail.com: Hey Matt, a couple of things, since I am experiencing a different situation Yes, it should be possible if your sources are in synchronization with world/kernel. Just make the edit and go to /usr/src/sys/modules/acpi/acpi_ibm and type make make install I unloaded, recompiled that part, and rebooted, but I see no change for the hotkeys. Most still don't work. Only volume mute work, but that worked before the change. Trying to change the brightness didn't corrupt the fan. Neither from hotkeys, nor from acpi_call You'll notice that fan speed becomes something ugly after trying to set brightness, but everything will work otherwise as far as I have tested. I have found that the machine gets quite hot on its own especially with turbo core on the i7 and heavy usage, even with power tuning. Adjusting fan speed could be dangerous, I would certainly keep a close eye on temperatures during something like buildworld to be sure. On the other side, my temp now drops below 50C to about 46C. The fan goes into its lowest spin. I didn't have this before. At 50C it kicks to next step, at 60C it kicks to the crazy speed (usually on compile or 720p video). P.S. All tests were done from X with Konstantin's patch on 9.0-STABLE with powerd and no other mods. X220 with i5 2520M, BIOS 1.28, IPS, 9cell batter, 16GB RAM, Intel 1000-N, SSD. P.S.S. Workaround for fan corruption can be changing the brightness while it boots, before OS starts, function keys work there. But I don't have the crazy fan. If by crazy fan you mean not the lowest spin, then I had that before LEN change as well. Are you sure acpi_ibm is actually doing the connect? What do you see for 'sysctl dev.acpi_ibm'? You should see a list of items, many of which will be '0', even though they should not be. Things like 'fan_speed'. Setting dev.acpi_ibm.0.mute or dev.acpi_ibm.0.thiklight to '1' should work. I think the hotkeys should default to 2484. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: x220 notes
2012/3/31 Erich Dollansky erichfreebsdl...@ovitrap.com: Hi, this just reminds me of my Fujitsu P2120. On Sunday 01 April 2012 11:27:02 Любомир Григоров wrote: Any news on the brightness? My X220 came and FreeBSD installs and boots fine with MBR. But like you said brightness control is not working and I am stuck at max. Even with me 9cell battery, it brings it down to 5 hours instead of 8-9 with a slightly dimmer setting. I could not adjust brightness inside X on my P2120 too. But switching to a console allowed me to adjust with the keys assigned to this. I never got used to this procedure but it worked. Did you try this? Does not work for me. :-( First press of either brightness up or down will echo ^@ (null), but that's all that happens. The system does not have discrete brightness buttons. It uses Fn+Home and Fn+End to adjust brightness. Thanks for the suggestion. though. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: x220 notes
2012/4/1 Hannes Mehnert han...@mehnert.org: Hi, controlling brightness works for me (via shell) - taking matt's advice into account: \VBRC seems to allow control over the backlight, at least, so those of you with sore eyes or the 3-cell battery may have some success using the acpi_call port (Danger!) kldload acpi_call acpi_call -p '\VBRC' -i n (where n is 0-16; 17 (and -1) is off) This works well, but I'll need to look at how to make Gnome do the job so the automatic dimming will work. Also, at least on my ThinkPad, its 0-15. 16 and 14 are identical and slightly dimmer than 15. Maybe it's a BIOS issue on my laptop? I see Lenovo has released a new one recently. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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 for Asus Notebook N50Vc
On Wed, Feb 15, 2012 at 4:05 AM, simplicissimus hans-wurs...@web.de wrote: I forgot to mention that the volume control keys now also work. I tried this utility to find out the scancodes of the multimedia keys, but unfortunately the Fn+something keys didn’t generate any output. http://hack.org/mc/hacks/kbdscan/ You might try xev. It's been a standard X11 app since the earliest days of X11and reports all X events (mouse move, mouse click, key pres, key release. If you did a standard xorg install, you should already have it. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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_ibm fails to work on new laptop
I recently went from a ThinkPad T43 to a T520. On the T520, ac[i_ibm is not functional. 'sysctl dev.acpi_ibm' returns nothing. No volume control, though MUTE does work. Any idea about a fix? Can I just change the OEMID to LENOVO? (Probably should change all IBM references to LENOVO while I'm at it.) I'll probably give this a shot, just to see if it works. -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@gmail.com ___ 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
