Bug 92111 - acpi_osi=!Darwin does not work, thunderbolt can not be disabled causing Power consumption regression
Summary: acpi_osi=!Darwin does not work, thunderbolt can not be disabled causing Power...
Status: CLOSED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Power Management
Classification: Unclassified
Component: Other (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Lv Zheng
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-26 21:51 UTC by Attila
Modified: 2016-10-10 09:32 UTC (History)
17 users (show)

See Also:
Kernel Version: 3.18.3
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
Output of Turbostat on Kernel series 3.16 (5.05 KB, text/plain)
2015-01-27 08:13 UTC, Attila
Details
Output of Turbostat on Kernel series 3.18 (9.09 KB, text/plain)
2015-01-27 08:13 UTC, Attila
Details
Output of dmesg on Kernel series 3.16 (85.98 KB, application/octet-stream)
2015-01-27 08:14 UTC, Attila
Details
Output of dmesg on Kernel series 3.18 (106.21 KB, text/plain)
2015-01-27 08:14 UTC, Attila
Details
Output of lsmod on Kernel series 3.16 (3.17 KB, application/octet-stream)
2015-01-27 08:15 UTC, Attila
Details
Output of lsmod on Kernel series 3.18 (3.16 KB, application/octet-stream)
2015-01-27 08:15 UTC, Attila
Details
Output of ps -A on Kernel series 3.16 (6.97 KB, application/octet-stream)
2015-01-27 08:15 UTC, Attila
Details
Output of ps -A on Kernel series 3.18 (7.29 KB, text/plain)
2015-01-27 08:16 UTC, Attila
Details
Output of lspci on Kernel series 3.16 (1.48 KB, application/octet-stream)
2015-01-27 08:16 UTC, Attila
Details
Output of lspci on Kernel series 3.18 (1.83 KB, application/octet-stream)
2015-01-27 08:16 UTC, Attila
Details
Output of lsusb on Kernel series 3.18 (367 bytes, application/octet-stream)
2015-01-27 08:17 UTC, Attila
Details
Git bisect log (2.23 KB, text/plain)
2015-02-10 23:51 UTC, Attila
Details
turbostat utility (49.00 KB, application/gzip)
2015-03-24 00:48 UTC, Len Brown
Details
turbostat output with "acpi_osi=" in kernel command line (3.00 KB, text/plain)
2015-03-24 21:55 UTC, Attila
Details
turbostat output with NO "acpi_osi=" in kernel command line (3.02 KB, text/plain)
2015-03-24 21:56 UTC, Attila
Details
turbostat output, 3 scenarios (8.39 KB, text/plain)
2015-05-16 20:29 UTC, Nir
Details
Compare various settings of energy bias (62.47 KB, image/png)
2015-05-20 15:39 UTC, Doug Smythies
Details
shows differences (or lack thereof) in response to various energy bias (50.58 KB, image/png)
2015-05-26 16:50 UTC, Doug Smythies
Details
disable darwin if acpi_osi=!darwin is provided in command line (1.24 KB, application/octet-stream)
2016-01-26 13:41 UTC, Chen Yu
Details
acpidump (259.21 KB, application/octet-stream)
2016-02-02 02:51 UTC, Chen Yu
Details
[PATCH 1/3] ACPI / osi: Cleanup _OSI("Linux") related code before introducing new support (6.31 KB, patch)
2016-04-25 07:18 UTC, Lv Zheng
Details | Diff
[PATCH 2/3] ACPI / osi: Fix an issue that acpi_osi=!* cannot disable ACPICA internal strings (4.07 KB, patch)
2016-04-25 07:18 UTC, Lv Zheng
Details | Diff
[PATCH 3/3] ACPI / osi: Change default _OSI(Darwin) support (5.10 KB, patch)
2016-04-25 07:19 UTC, Lv Zheng
Details | Diff
[PATCH] ACPI / osi: Change default _OSI(Darwin) support (5.52 KB, patch)
2016-04-25 07:38 UTC, Lv Zheng
Details | Diff

Description Attila 2015-01-26 21:51:40 UTC
I realized that when upgrading the kernel from 3.17.7 to 3.18.3 my Intel HSW Iris Pro based Macbook pro draws 2.5W more (15.8W instead of 13.3W) energy. That is almost 20%. Battery time is of course much less in this case.

I tried 3.18RC1 as well and it already had the problem. 3.19RC6 still has the problem.

I used Ubuntu Vivid and downloaded kernels from the Ubuntu Kernel PPA.

I even tried to boot into debug mode with most of the modules disabled. The Power difference was less, but still 1.3W.

For power measure I used Powertop unplugged from AC.

Is this a known problem, or just related to hardware ?

Thank you for the help in advanced !

Attila
Comment 1 Attila 2015-01-26 23:12:41 UTC
Just to mention, the values above are idle values. The same difference occurs when full load.
Comment 2 Zhang Rui 2015-01-27 00:58:10 UTC
please attach the turbostat output on both kernels (3.17.7 and 3.18.3/3.19-rc6).
Comment 3 Attila 2015-01-27 08:13:30 UTC
Created attachment 164851 [details]
Output of Turbostat on Kernel series 3.16
Comment 4 Attila 2015-01-27 08:13:50 UTC
Created attachment 164861 [details]
Output of Turbostat on Kernel series 3.18
Comment 5 Attila 2015-01-27 08:14:16 UTC
Created attachment 164871 [details]
Output of dmesg on Kernel series 3.16
Comment 6 Attila 2015-01-27 08:14:38 UTC
Created attachment 164881 [details]
Output of dmesg on Kernel series 3.18
Comment 7 Attila 2015-01-27 08:15:01 UTC
Created attachment 164891 [details]
Output of lsmod on Kernel series 3.16
Comment 8 Attila 2015-01-27 08:15:23 UTC
Created attachment 164901 [details]
Output of lsmod on Kernel series 3.18
Comment 9 Attila 2015-01-27 08:15:51 UTC
Created attachment 164911 [details]
Output of ps -A on Kernel series 3.16
Comment 10 Attila 2015-01-27 08:16:02 UTC
Created attachment 164921 [details]
Output of ps -A on Kernel series 3.18
Comment 11 Attila 2015-01-27 08:16:40 UTC
Created attachment 164931 [details]
Output of lspci on Kernel series 3.16
Comment 12 Attila 2015-01-27 08:16:56 UTC
Created attachment 164941 [details]
Output of lspci on Kernel series 3.18
Comment 13 Attila 2015-01-27 08:17:13 UTC
Created attachment 164951 [details]
Output of lsusb on Kernel series 3.18
Comment 14 Attila 2015-01-27 08:21:53 UTC
I added some other useful info as well.
Just as a note, when running turbostat, power consumption (by powertop battery drain calculation) was 13.5W on Kernel 3.16 and 15.8W on Kernel 3.18.

Please note if you need any more info, or if I should try anything !
Comment 15 Attila 2015-02-01 21:54:01 UTC
Any idea ? What could I try to get the cause identified ?
Thanks
Comment 16 Aaron Lu 2015-02-06 06:00:13 UTC
Looks like it is related to the residency change in Pkg%pc6: in v3.16, it stays in Pkg%pc6 63% when idle while in v3.18, it stays in Pkg%pc3 instead:

v3.18.3:
    Core     CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz     SMI  CPU%c1  CPU%c3  CPU%c6  CPU%c7 CoreTmp  PkgTmp Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 PkgWatt CorWatt GFXWatt
       -       -       3    0.11    2219    1995       0    0.17    0.00    1.06   98.66      39      41   40.07   58.79    0.00    0.00    3.34    0.01    0.00

v3.16:
    Core     CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz     SMI  CPU%c1  CPU%c3  CPU%c6  CPU%c7 CoreTmp  PkgTmp Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 PkgWatt CorWatt GFXWatt 
       -       -       2    0.19     908    1995       0    0.30    0.01    0.01   99.48      37      42   34.64    0.44   63.05    0.00    2.84    0.01    0.00

Not sure what caused this, can you do a bisect?
Comment 17 Attila 2015-02-06 08:36:12 UTC
Hi Aaron !

Thanks for looking into it. I can compile a kernel, but never did a bisect. Can you suggest a tutorial or something what is the best way to do ?

I guess, I should try to compile different git revisions between 3.17 and 3.18RC1. That is a LOT of commits :-) Any idea where to look for the culprit ?

Thanks in advanced !
Comment 18 Aaron Lu 2015-02-06 08:44:36 UTC
(In reply to Attila from comment #17)
> Hi Aaron !
> 
> Thanks for looking into it. I can compile a kernel, but never did a bisect.
> Can you suggest a tutorial or something what is the best way to do ?

Take a look at this:
http://git-scm.com/docs/git-bisect

> 
> I guess, I should try to compile different git revisions between 3.17 and
> 3.18RC1. That is a LOT of commits :-) Any idea where to look for the culprit
> ?

v3.16 is OK and v3.18 is bad. I think you can first test v3.17. If v3.17 is good, than bisect between v3.17..v3.18; if v3.17 is bad, then bisect between v3.16..v3.17.

Anyway, it will take a long time.
Let's see if Len Brown has any better idea here:

Len,
Attila's system stays less time in Pkg%pc6 state and that caused some more power consumption. Do you have any idea what might be the cause?
Comment 19 Rafael J. Wysocki 2015-02-06 14:23:20 UTC
(In reply to Aaron Lu from comment #18)
> 
> Len,
> Attila's system stays less time in Pkg%pc6 state and that caused some more
> power consumption. Do you have any idea what might be the cause?

The only reason I can see at the moment is that in the newer kernels the governor's next event time predictions are consistently less than the state's wakeup latency.

That may result from one of two things: Either the governor's prediction algorithm has changed or the states definitions have changed to that effect.

What combination of the cpuidle driver/governor is used?  intel_idle/menu or something else?
Comment 20 Johan Olby 2015-02-06 18:58:44 UTC
I have seen the same power regression. But for me it is due to a firmware update thet were installed as a part of the lates os x update.

I have a enabled gpe that triggers alot...

It is visible if you run:
grep . -r /sys/firmware/acpi/interrupts/ 

for me it is gpe06 others has reported gpe66
/sys/firmware/acpi/interrupts/gpe06:  871215   enabled
Comment 21 Attila 2015-02-06 20:25:50 UTC
(In reply to Johan Olby from comment #20)
> I have seen the same power regression. But for me it is due to a firmware
> update thet were installed as a part of the lates os x update.
> for me it is gpe06 others has reported gpe66
> /sys/firmware/acpi/interrupts/gpe06:  871215   enabled

Thanks for the info.


I have the line: 

/sys/firmware/acpi/interrupts/gpe06:       8   enabled

The other enabled interrupt was:

/sys/firmware/acpi/interrupts/gpe17:   14699   enabled

I have not really updated OSX lately. How can I know I have the same problem ?
Comment 22 Johan Olby 2015-02-06 20:40:17 UTC
I get a couple of million wakeups due to the gpe handler within a minute after system start. So our issues is not the same if the gpe17 with 14699 events is the highest number.

Running:
perf top 

Shows acpi methods with high overhead until i disable the gpe.
Comment 23 Attila 2015-02-06 21:06:21 UTC
(In reply to Johan Olby from comment #22)
> I get a couple of million wakeups due to the gpe handler within a minute
> after system start. So our issues is not the same if the gpe17 with 14699
> events is the highest number.

Correct. My issue is different. I tried to disable this interrupts, but nothing changed in power consumption.

Something changed between 3.17 and 3.18rc1 that prevens my cpu going into pc6.
Comment 24 Attila 2015-02-06 21:09:03 UTC
(In reply to Rafael J. Wysocki from comment #19)
> What combination of the cpuidle driver/governor is used?  intel_idle/menu or
> something else?

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
intel_pstate

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

I have not changed the default values coming with Ubuntu 15.04.
Comment 25 Rafael J. Wysocki 2015-02-06 22:05:00 UTC
I was talking about cpuidle, not about cpufreq.

Also it is correct that the difference may be due to the increased number of wakeups in which case the processor will wake up from idle to often for the governor to even consider C6 (which then autoporomotes to PC6 in the right conditions).

It looks like bisection would be the most straightforward way to determine what change caused that.

Before that, have you tried 3.19-rc7 to see if the issue is still there?
Comment 26 Attila 2015-02-06 22:57:54 UTC
(In reply to Rafael J. Wysocki from comment #25)
> I was talking about cpuidle, not about cpufreq.
> 
> Also it is correct that the difference may be due to the increased number of
> wakeups in which case the processor will wake up from idle to often for the
> governor to even consider C6 (which then autoporomotes to PC6 in the right
> conditions).
> 
> It looks like bisection would be the most straightforward way to determine
> what change caused that.
> 
> Before that, have you tried 3.19-rc7 to see if the issue is still there?

Tried 3.19-rc7 with the same results.
I checked cpuidle. I am using intel_idle/menu.

What I don't understand (sorry for being noob here) is by  turbostat output cpu spends most of the time in C7 state, but it NEVER gets to PC6:

CPU%c1  CPU%c3  CPU%c6  CPU%c7 Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 PkgWatt
0.17    0.00    1.06   98.66     40.07   58.79    0.00    0.00    3.34 

Isn't that odd ?
Comment 27 Rafael J. Wysocki 2015-02-08 22:24:01 UTC
It looks like it never goes to PC7, even with 3.16, though.

Can you please run powertop with 3.17 and 3.18 and see if there are any obvious differences in the numbers of wakeups reported by it?
Comment 28 Attila 2015-02-08 22:47:27 UTC
(In reply to Rafael J. Wysocki from comment #27)
> Can you please run powertop with 3.17 and 3.18 and see if there are any
> obvious differences in the numbers of wakeups reported by it?

Done it. No difference in wakeups/s. In fact 3.18 had less (25-35) compared to 3.17's 50-60.

I started the bisect. At half time between v3.17 and v3.18-rc1 (git rev: 35a9ad8) it is fine.
Comment 29 Zhang Rui 2015-02-09 05:37:18 UTC
Attila, any update?
Comment 30 Attila 2015-02-09 07:00:33 UTC
(In reply to Zhang Rui from comment #29)
> Attila, any update?

I am slowly aproaching. 8 bisect steps to go. I can provide the info tonight in ca. 16 hours from now, when I get home and finish the bisect.
Comment 31 Attila 2015-02-10 17:24:39 UTC
Still a few steps to go, but what is already sure that the problem starts with "Merge tag 'pm+acpi-3.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
"

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=b528392669415dc1e53a047215e5ad6c2de879fc

I am going forward to narrow it down to one commit out of 105 in this pull.
Comment 32 Attila 2015-02-10 23:50:19 UTC
Strange result, but git bisect shows this commit to be the first bad:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7bc5a2bad0b8d9d1ac9f7b8b33150e4ddf197334

I guess this acpi change results that CPU is not allowed to go deeper states than pc3. I will do a build of 3.18 reverting this commit to make sure this was the problem.

I will enclose a bisect log soon.
Comment 33 Attila 2015-02-10 23:51:33 UTC
Created attachment 166431 [details]
Git bisect log
Comment 34 Rafael J. Wysocki 2015-02-11 00:09:54 UTC
Not as strange as it seems.

Does it help if you comment out the

	if (!strcmp("Darwin", interface)) {
		/*
		 * Apple firmware will behave poorly if it receives positive
		 * answers to "Darwin" and any other OS. Respond positively
		 * to Darwin and then disable all other vendor strings.
		 */
		acpi_update_interfaces(ACPI_DISABLE_ALL_VENDOR_STRINGS);
		supported = ACPI_UINT32_MAX;
	}

block in acpi_osi_handler() (drivers/acpi/osl.c) in 3.19?
Comment 35 Rafael J. Wysocki 2015-02-11 00:24:42 UTC
Or try to pass acpi_os="!Darwin" to the kernel in the command line.  That should have the same effect as the above.
Comment 36 Rafael J. Wysocki 2015-02-11 00:25:36 UTC
(In reply to Rafael J. Wysocki from comment #35)
> Or try to pass acpi_os="!Darwin" to the kernel in the command line.  That
> should have the same effect as the above.

Argh, typo.

acpi_osi="!Darwin"

is the correct one, sorry.
Comment 37 Attila 2015-02-11 07:59:34 UTC
Well. Reverting the whole commit works, but just putting acpi_os="!Darwin" in the boot parameters does NOT!

Maybe this is not the problematic part of that commit. There is also this part:
+	 * Apple always return failure on _OSC calls when _OSI("Darwin") has
+	 * been called successfully. We know the feature set supported by the
+	 * platform, so avoid calling _OSC at all
+	 */
+
+	if (dmi_match(DMI_SYS_VENDOR, "Apple Inc.")) {
+		root->osc_control_set = ~OSC_PCI_EXPRESS_PME_CONTROL;
+		decode_osc_control(root, "OS assumes control of",
+				   root->osc_control_set);
+		return;
+	}
+
+	/*

I am doing a build checking which part of the commit is causeing the problem.
Comment 38 Rafael J. Wysocki 2015-02-11 13:58:19 UTC
(In reply to Attila from comment #37)
> Well. Reverting the whole commit works, but just putting acpi_os="!Darwin"
> in the boot parameters does NOT!

Please see comment #36.  That should be

acpi_osi="!Darwin"

(the second "i" in the option name being essential).
Comment 39 Attila 2015-02-11 15:04:51 UTC
I did further tests. Results:

Changes in 
    -drivers/acpi/pci_root.c: unchanged,
    -drivers/acpi/osl.c: reverted
Result: BUG Persists

Changes in 
    -drivers/acpi/pci_root.c: reverted,
    -drivers/acpi/osl.c: unchanged
Result: BUG Solved

Changes in 
    -drivers/acpi/pci_root.c: unchanged,
    -drivers/acpi/osl.c: unchanged
Result: BUG Persists

Changes in 
    -drivers/acpi/pci_root.c: reverted,
    -drivers/acpi/osl.c: reverted
Result: BUG Solved

So indeed the problem is when this if statement code runs:

	if (!strcmp("Darwin", interface)) {
		/*
		 * Apple firmware will behave poorly if it receives positive
		 * answers to "Darwin" and any other OS. Respond positively
		 * to Darwin and then disable all other vendor strings.
		 */
		acpi_update_interfaces(ACPI_DISABLE_ALL_VENDOR_STRINGS);
		supported = ACPI_UINT32_MAX;
	}

I was unable to pass the Kernel parameter correctly. I tried all kinds of escaping without a luck. Any idea how to put this into /etc/default/grub ?

I tried:
GRUB_CMDLINE_LINUX='acpi_osi=!Darwin'
GRUB_CMDLINE_LINUX='acpi_osi="!Darwin"'
GRUB_CMDLINE_LINUX='acpi_osi=\"!Darwin\"'
GRUB_CMDLINE_LINUX='acpi_osi=\\"!Darwin\\"'
GRUB_CMDLINE_LINUX='acpi_osi=\\\"!Darwin\\\"'

dmesg |grep OSI
shows that I "ADDED" \"!Darwin\" to the system :-)
I will try to put it in manually when I get home, but no way I can do it over ssh so far.
Comment 40 Attila 2015-02-12 08:41:06 UTC
(In reply to Rafael J. Wysocki from comment #38)
> Please see comment #36.  That should be
> 
> acpi_osi="!Darwin"
> 
> (the second "i" in the option name being essential).

Now I am officially stuck with removing Darwin with kernel parameter. I tried EVERYTHING already.

I can remove "Windows 2006" with grub line:
GRUB_CMDLINE_LINUX='acpi_osi="!Windows 2006"'

cat /proc/cmdline outputs:

BOOT_IMAGE=/boot/vmlinuz-3.19.0-git root=UUID=5185e8da-7372-4a38-afd4-65cdcb2ac09f ro "acpi_osi=!Windows 2006" quiet splash vt.handoff=7

dmesg |grep OSI outputs:
[    0.321788] ACPI: Added _OSI(Module Device)
[    0.321790] ACPI: Added _OSI(Processor Device)
[    0.321792] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.321793] ACPI: Added _OSI(Processor Aggregator Device)
[    0.321794] ACPI: Deleted _OSI(Windows 2006)
[    0.329275] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored


But when I try it with !Darwin it NEVER works. Grub line:
GRUB_CMDLINE_LINUX='acpi_osi="!Darwin"'

cat /proc/cmdline outputs:
BOOT_IMAGE=/boot/vmlinuz-3.19.0-git root=UUID=5185e8da-7372-4a38-afd4-65cdcb2ac09f ro acpi_osi=!Darwin quiet splash vt.handoff=7


dmesg |grep OSI outputs:
[    0.302015] ACPI: Added _OSI(Module Device)
[    0.302017] ACPI: Added _OSI(Processor Device)
[    0.302019] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.302020] ACPI: Added _OSI(Processor Aggregator Device)
[    0.309294] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored

Darwin is not deleted and CPU states reach only up to pc3. The problematic code gets executed by the extra log I made there.

I even tried it manually typing in while booting with all possible escaping without any luck.The only line that works is 
GRUB_CMDLINE_LINUX='acpi_osi='

This way I get with dmesg |grep OSI
[    0.000000] ACPI: _OSI method disabled
[    0.302141] ACPI: Added _OSI(Module Device)
[    0.302143] ACPI: Added _OSI(Processor Device)
[    0.302144] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.302146] ACPI: Added _OSI(Processor Aggregator Device)

And CPU reaches up to PC6 states. But I think it is not a good workaround to remove all OSI strings.

Any suggestions ?
Comment 41 Attila 2015-02-12 10:27:11 UTC
Following from previous post, I discovered why acpi_osi="!Darwin" parameter does not work. It is because it has never been defined in the default supported interfaces:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/acpica/utosi.c?id=refs/tags/v3.19#n87

So the function acpi_remove_interface(str) here https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/osl.c?id=refs/tags/v3.19#n1523

ALWAYS returns a failure.

So currently there is no way to explicitly remove Darwin only.

I guess the right way would be to define Darwin as supported interface, so it can be enabled or disabled later and check that state with the problematic if statement.
Comment 42 Attila 2015-02-14 12:14:02 UTC
So to summarize for other users, who also faced by this bug:

- Affected hardware: Intel CPU based Apple products

- Situation before 3.18: Apple thunderbolt was broken with default kernel parameters, but power consumption was a lot better due to CPU can enter into better power-saving states.

- Situation after 3.18: Apple thunderbolt is working with default kernel parameters, but we have increased power consumption, due to CPU only entering a less power saving state.

Temporary workaround: disable the ability of the kernel to report "Darwin" to Apple firmware, by putting 'acpi_osi=' into the kernel command line as a parameter. For most common distributions, for this you have to put this line into the default grub configuration file (on Ubuntu it is located at /etc/default/grub)

GRUB_CMDLINE_LINUX='acpi_osi='

Note that with this workaround you will have broken thunderbolt again.

Hopefully kernel devs will have a solution in the future to have both thunderbolt and the best possible power consumption together with default kernel paramaters.
Comment 43 Len Brown 2015-03-24 00:48:49 UTC
Created attachment 171871 [details]
turbostat utility

please show the output from the attached turbostat utility

# turbostat --debug sleep 10 2>&1 | tee ts.out

it will show what C-states are enabled in hardware by the BIOS
eg. for another system, pc6 is enabled:
cpu0: MSR_NHM_SNB_PKG_CST_CFG_CTL: 0x00008403 (locked: pkg-cstate-limit=3: pc6)
Comment 44 Attila 2015-03-24 21:55:37 UTC
Created attachment 172201 [details]
turbostat output with "acpi_osi=" in kernel command line
Comment 45 Attila 2015-03-24 21:56:17 UTC
Created attachment 172211 [details]
turbostat output with NO "acpi_osi=" in kernel command line
Comment 46 Attila 2015-03-24 21:59:16 UTC
Added output of turbostat with both cases. The only noticable difference (besides the different power saving states) Is this line:

cpu0: MSR_IA32_POWER_CTL: 0x0004005f (C1E auto-promotion: ENabled)

It is DISabled when we have the increased power consumption. I think this is important.
Comment 47 Len Brown 2015-04-04 17:28:50 UTC
The high power case gets only into pc3,
while the low power case gets into pc6.

This may be related to enabling thunderbolt.
powertop
may help debug that.
you can show what that utility sees with "powertop --html"

I can't explain why C1E promotion would not be disabled
for both cases, as "dmesg | grep idle" shows that you
are running the intel_idle driver in both cases.
That is a mystery, but compared to PC3 vs PC6, it shouldn't
be material to power savings when profoundly idle.

A bigger factor may be this difference:

< cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x00000006 (balanced)
> cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x00000000 (performance)

I can't explain why they would be different in your different
scenarios.  If the platform boots with EPB 0, the kernel sets it to 6.
I don't know why this didn't happen, or why it got un-done
in the high power case.

Please run

# x86_energy_perf_policy -v normal

and re-measure.

If your distro doesn't have this utility, then you can
get it from the Linux kernel source tree:

tools/power/x86/x86_energy_perf_policy/
Comment 48 Nir 2015-05-05 03:25:01 UTC
This bug is confirmed also on Macbook Air 6,2.
Adding "acpi_osi=" to the kernel cmdline helps.

On the core i7: 
the low power case get to pc7.
the high power case only get to pc3.

I bisected the kernel and got to the same commit: 7bc5a2bad0b8d9d1ac9f7b8b33150e4ddf197334 is the first bad commit.

Also reported here: https://askubuntu.com/questions/617413/why-ubuntu-15-04-with-kernel-3-19-0-15-is-using-significantly-more-power
Comment 49 Doug Smythies 2015-05-05 04:01:59 UTC
(In reply to Len Brown from comment #47)

> That is a mystery, but compared to PC3 vs PC6, it shouldn't
> be material to power savings when profoundly idle.

In Nir's case, there was actually much more load in the "profoundly idle" case. He has 4 CPUs and it was always CPU3 that was busier, and it never had a long "duration" (time between executions of the intel_pstate driver). Something I have never seen before on any other "profoundly idle" system. That being said, I don't have a similar trace for the "good" kernel for a complete comparison.
Comment 50 Len Brown 2015-05-12 15:47:45 UTC
Nir, thanks for confirming that

7bc5a2bad0b8d9d1ac9f7b8b33150e4ddf197334 
"ACPI: Support _OSI("Darwin") correctly"

causes this regression.

Atilla,
Thanks for exposing that the same commit hard-coded
an OSI string, but doesn't honor acpi_osi=!Darwin
and does not honor acpi_osi=!*
and that disabling OSI capability completely with acpi_osi=
is necessary to restore the power level on the system.

Nir,
Can you show turbostat --debug output with and without acpi_osi=
to see if the ENERGY_PERF_BIAS is also an issue the macbook air?
If yes, please run the test requested comment #47 to see if
manually changing ENERGY_PERF_BIAS helps.  Beware that the BIOS
may have a different default for this MSR depending on if
the system is on AC or DC power.

Also, for both systems, please attache the output from acpidump,
so we can see what _OSI("Darwin") actually does.  The original
cause for the regression was to power-on Thunderbolt -- it is also
possible that we simply have to choose between enabling thunderbolt
and power saving.
Comment 51 Nir 2015-05-16 20:29:54 UTC
Created attachment 177061 [details]
turbostat output, 3 scenarios
Comment 52 Nir 2015-05-16 20:33:14 UTC
Comment on attachment 177061 [details]
turbostat output, 3 scenarios

Len,

Please see attached info, I hope this helps. On my end, as far as battery life goes, newer kernels are much worse, this bug is only one cause, and there are other which I could not yet figure out. The first situation in the attachment is the best case so far.
Comment 53 Doug Smythies 2015-05-17 15:43:56 UTC
This is interesting:

cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x0000000f (custom)

Nir: It might be worth running "powertop --html" as per Len's comment 47 anyhow.
Comment 54 Nir 2015-05-20 14:11:56 UTC
Doug: The MSR_IA32_ENERGY_PERF_BIAS: 0x0000000f is set after one run `x86_energy_perf_policy powersave` I'm now using 'normal' and see little different.

I did run `powertop --html`, and will run it again. Is there any particular information you'd like to see, or just attach all of it, for the 3 scenarios?

FYI, manually changing MSR_IA32_ENERGY_PERF_BIAS using `x86_energy_perf_policy normal` does not help when "acpi_osi=" isn't present in the cmdline.
Comment 55 Doug Smythies 2015-05-20 15:36:26 UTC
(In reply to Nir from comment #54)

> I did run `powertop --html`, and will run it again. Is there any particular
> information you'd like to see, or just attach all of it, for the 3 scenarios?

I didn't see the data from your previous run, I must have missed it somewhere.

I do not know what I'd like to see, until I see it. It is juts that I was unable to determine (both on this bug report and another) what is going on from the trace data. So Len's suggestion see,ed like a good one.
Yes all 3 scenarios.

> 
> FYI, manually changing MSR_IA32_ENERGY_PERF_BIAS using
> `x86_energy_perf_policy normal` does not help when "acpi_osi=" isn't present
> in the cmdline.

The effect seems rather subtle in powersave mode and there is no effect in performance mode. I'll attach a graph in a moment.
Comment 56 Doug Smythies 2015-05-20 15:39:43 UTC
Created attachment 177501 [details]
Compare various settings of energy bias

just comparing response verses some settings for energy perf bias. Ignore the "doug 0 6" line, as it is related to my proposed patch set.
Comment 57 Len Brown 2015-05-26 16:13:35 UTC
Doug, how is the graph in comment 56 related to this issue?
It has lots of ink on it, but I don't understand that that ink means.
Comment 58 Len Brown 2015-05-26 16:18:19 UTC
> cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x0000000f (custom)

BTW. this is a typo in turbostat, it should print "(powersave)".
I will fix that.
Comment 59 Doug Smythies 2015-05-26 16:43:35 UTC
(In reply to Len Brown from comment #57)
> Doug, how is the graph in comment 56 related to this issue?
> It has lots of ink on it, but I don't understand that that ink means.

Len: The short answer is that I don't know that the graph is related to this issue.

The longer answer is that on this, and other, bug reports I have been noticing that the state of MSR_IA32_ENERGY_PERF_BIAS seems inconsistent and was, perhaps, a reason for some of the increased power consumptions being observed. I did the graph, just to know what we really get for the various settings.

Subsequently, I did another graph using fixed work packet mode (I'll post it in a moment), instead of fixed load mode. Conclusion: The state of MSR_IA32_ENERGY_PERF_BIAS seems, to me at least, to be a red herring, as in the end it makes no difference.
Comment 60 Doug Smythies 2015-05-26 16:50:49 UTC
Created attachment 177961 [details]
shows differences (or lack thereof) in response to various energy bias

This graph uses fixed work packets, which is more representative of real world scenarios. In the end, there is virtually no difference, and the conclusion is that the perf bias register state isn't a contributor.
Comment 61 Imre Kaloz 2015-05-27 14:53:54 UTC
Poking through /sys/firmware/acpi produces the following diff:

diff -Nur nodarwin/acpi/interrupts/gpe4E darwin/acpi/interrupts/gpe4E
--- nodarwin/acpi/interrupts/gpe4E	2015-05-27 16:49:00.907552831 +0200
+++ darwin/acpi/interrupts/gpe4E	2015-05-27 16:51:40.724663610 +0200
@@ -1 +1 @@
-    1237   enabled
+    1712   enabled
diff -Nur nodarwin/acpi/interrupts/gpe_all darwin/acpi/interrupts/gpe_all
--- nodarwin/acpi/interrupts/gpe_all	2015-05-27 16:49:00.911552972 +0200
+++ darwin/acpi/interrupts/gpe_all	2015-05-27 16:51:40.724663610 +0200
@@ -1 +1 @@
-    1239
+    1714
diff -Nur nodarwin/acpi/interrupts/sci darwin/acpi/interrupts/sci
--- nodarwin/acpi/interrupts/sci	2015-05-27 16:49:00.911552972 +0200
+++ darwin/acpi/interrupts/sci	2015-05-27 16:51:40.724663610 +0200
@@ -1 +1 @@
-    1239
+    1714
diff -Nur nodarwin/acpi/interrupts/sci_not darwin/acpi/interrupts/sci_not
--- nodarwin/acpi/interrupts/sci_not	2015-05-27 16:49:00.911552972 +0200
+++ darwin/acpi/interrupts/sci_not	2015-05-27 16:51:40.724663610 +0200
@@ -1 +1 @@
-       2
+       0
Comment 62 Len Brown 2015-06-23 14:31:17 UTC
for starts, i'll write a patch to support acpi_osi=!darwin
as mjg's original patch did not correctly support that.
Comment 63 pldubouilh 2015-08-08 19:00:12 UTC
My two cents : 

3.17.6-1
 > Decent battery life out of the box
 > Thunderbolt working, hotplug working, no HDMI sound

4.1.4 
 > Decent battery life using acpi_osi= 
 > Thunderbolt, hotplug and HDMI sound all working - even with acpi_osi=


Some more info :

 * Last Macbook Air (early 2015) : Apple Inc. 1.0 MacBookAir7,1
 * BIOS : MBA71.88Z.0166.B02.1503241251
 * Latest Arch Kernel : Linux 4.1.4-1-ARCH
Comment 64 Piotr Szczepanik 2015-10-11 14:32:31 UTC
Hi,
I have not tried older kernels (before 3.18) on my MacBook Pro 11,3 but in my opinion the problem is that now when Thunderbolt is enabled its ASPM is in disabled state.

I have also had no package C6 state residency in recent kernels (without using acpi_osi=) but I have tried enabling ASPM with the following two commands.

setpci -s 06:00.0 0xd0.B=0x43
setpci -s 07:06.0 0xd0.B=0x43

After issuing those two commands my C6 residency came back to 70-80% on battery and now I get 7-9W usage in idle (gnome-terminal with NVIDIA card powered off with gmux commands).


MacBook Pro (mid-2014) 11,3
Linux 4.2.2-1-ARCH #1 SMP PREEMPT Tue Sep 29 22:21:33 CEST 2015 x86_64 GNU/Linux
addition cmdline params: elevator=noop i915.enable_fbc=1 i915.lvds_downclock=1

lspci excerpt regarding Thunderbolt devices:
06:00.0 PCI bridge: Intel Corporation Device 156d
07:00.0 PCI bridge: Intel Corporation Device 156d
07:03.0 PCI bridge: Intel Corporation Device 156d
07:04.0 PCI bridge: Intel Corporation Device 156d
07:05.0 PCI bridge: Intel Corporation Device 156d
07:06.0 PCI bridge: Intel Corporation Device 156d
Comment 65 Maxime Hadjinlian 2015-10-18 08:55:24 UTC
Hi,

I too noticed the problem on my MacBookPro11,3, I also noticed that the laptop would resume from suspend by itself at regular interval and very quickly, then goes back to sleep.

Haven't had the occasion to look into it (using analyze_suspend.py, crash when it tries to close the fd, have to give it another go), but I tried enabling ASPM using the command given by Piotr and left my laptop in suspend for the night.
I lost 3% of battery (I don't have value in mA so I don't know if it means much).

Piotr: How are you able to check the state residency of your CPU ? And how did you measure the consumption ? A wattmeter ?

Linux 4.2.3-mbpr #1 SMP Sat Oct 10 12:44:33 CEST 2015 x86_64 GNU/Linux
cmdline: rootflags=data=writeback acpi_osi=Darwin libata.force=noncq
Comment 66 Chen Yu 2016-01-26 13:39:03 UTC
According to Len's suggestion at #Comment 62, a patch might be needed to first fix the 'regression' that acpi_osi=!Darwin  does not work problem. 
Hi Attila, Nir,  could you please help check if the patch help drop the energe consumed if acpi_osi=!Darwin is provided? And I recently get a Mac pro, I'll try to do some investigation/reproduce the problem on this platform.
Comment 67 Chen Yu 2016-01-26 13:41:40 UTC
Created attachment 202011 [details]
disable darwin if acpi_osi=!darwin is provided in command line
Comment 68 Attila 2016-01-26 14:04:34 UTC
(In reply to Chen Yu from comment #66)
> According to Len's suggestion at #Comment 62, a patch might be needed to
> first fix the 'regression' that acpi_osi=!Darwin  does not work problem. 
> Hi Attila, Nir,  could you please help check if the patch help drop the
> energe consumed if acpi_osi=!Darwin is provided? And I recently get a Mac
> pro, I'll try to do some investigation/reproduce the problem on this
> platform.

Sorry guys, but I really don't have any free-time nowadays. Also my test environment is gone as I had to re-install the OS. Could someone else help out testing this patch ?
Comment 69 Chen Yu 2016-01-26 14:36:12 UTC
(In reply to Attila from comment #68)
> (In reply to Chen Yu from comment #66)
> > According to Len's suggestion at #Comment 62, a patch might be needed to
> > first fix the 'regression' that acpi_osi=!Darwin  does not work problem. 
> > Hi Attila, Nir,  could you please help check if the patch help drop the
> > energe consumed if acpi_osi=!Darwin is provided? And I recently get a Mac
> > pro, I'll try to do some investigation/reproduce the problem on this
> > platform.
> 
> Sorry guys, but I really don't have any free-time nowadays. Also my test
> environment is gone as I had to re-install the OS. Could someone else help
> out testing this patch ?
 Never mind, I'll make a double check on my side. BTW, with regard to your original report, did it occur when the whole system was in idle?
Comment 70 Attila 2016-01-26 14:44:07 UTC
(In reply to Chen Yu from comment #69)
>  Never mind, I'll make a double check on my side. BTW, with regard to your
> original report, did it occur when the whole system was in idle?

Yes it was in idle state, after leaving the laptop idle down for 2-3 minutes after boot-time (this was always needed at every reboot), but note that the difference was also noticeable in load mode.
Comment 71 Lukas Wunner 2016-01-31 16:38:59 UTC
It would be helpful if an ACPI dump could be attached to this bug for each affected model.

The real solution to this bug would be to add runtime pm to the thunderbolt driver. I have a thunderbolt branch on GitHub which adds support for more controllers and I've pretty much figured out how to add runtime pm for the 1st gen Light Ridge controller. Apple provides ACPI methods to power the controller up and down, but they're different for each controller and I would need an ACPI dump to come up with patches for other controllers:
https://github.com/l1k/linux/commits/thunderbolt
Comment 72 Chen Yu 2016-02-02 02:51:15 UTC
Created attachment 202721 [details]
acpidump

acpidump from Mac Pro 12.1, i5, 2.7GHz, memory 8G
Comment 73 Chen Yu 2016-02-02 02:55:08 UTC
besides here's the link for disable Darwin in commandline:
https://patchwork.kernel.org/patch/8185441/
Comment 74 Chen Yu 2016-02-02 05:08:35 UTC
(In reply to Attila from comment #0)
> I realized that when upgrading the kernel from 3.17.7 to 3.18.3 my Intel HSW
> Iris Pro based Macbook pro draws 2.5W more (15.8W instead of 13.3W) energy.
> That is almost 20%. Battery time is of course much less in this case.
> 
> I tried 3.18RC1 as well and it already had the problem. 3.19RC6 still has
> the problem.
> 
> I used Ubuntu Vivid and downloaded kernels from the Ubuntu Kernel PPA.
> 
> I even tried to boot into debug mode with most of the modules disabled. The
> Power difference was less, but still 1.3W.
> 
> For power measure I used Powertop unplugged from AC.
> 
> Is this a known problem, or just related to hardware ?
> 
> Thank you for the help in advanced !
> 
> Attila

BTW, Attila, how do you measure power consumption by Powertop? can you provide your command? thanks
Comment 75 Chen Yu 2016-02-22 08:05:09 UTC
update:
There is a better solution for acpi_osi=!Darwin, regards of the  patch I sent previously, and Lv is planning to take over the fix for !Darwin.
Comment 76 Chen Yu 2016-03-14 14:19:23 UTC
update:
Per Lv's suggestion, new solution for !Darwin would look like:

1. revert matthew patch
2. improve acpi_osi=Linux/Darwin, automatically do acpi_osi=! for them
   (meanwhile add entry in acpi_default_supported_interfaces)
Comment 77 Lukas Wunner 2016-03-14 14:31:17 UTC
I've implemented runtime pm for Thunderbolt now, this should at least partially fix the power regression. Maybe we don't need to change the OSI behaviour at all if this gets merged?

https://github.com/l1k/linux/commits/thunderbolt

It would be great if others could test it, so far I've only tested it with the 1st gen Light Ridge controller built into my MBP, it's unclear if it works with the Cactus Ridge and Falcon Ridge built into newer machines.

The version on GitHub has one minor annoyance, it runtime resumes before system suspend and before shutdown, I have fixed this in my local repo and will push it to GitHub in a bit.

I had to make some changes to PCI core but I think I will be able to rework the patch to do without that.
Comment 78 Lukas Wunner 2016-03-16 15:35:51 UTC
I've just posted an initial version of runtime pm for thunderbolt.ko to linux-pci, linux-acpi, linux-pm.

It would be good if someone with a Cactus Ridge or Falcon Ridge controller could test this as I only have a machine with an older Light Ridge available for testing. The patches work fine on that machine, I'm seeing a 1.5 W drop in powertop once the controller is powered down.

The patches can be fetched from GitHub or as a tarball, they apply cleanly to 4.5:
https://github.com/l1k/linux/commits/thunderbolt_runpm_v1
http://wunner.de/thunderbolt_runpm_v1.tar.gz
Comment 79 Imre Kaloz 2016-03-17 13:12:12 UTC
(In reply to Lukas Wunner from comment #78)
> It would be good if someone with a Cactus Ridge or Falcon Ridge controller
> could test this as I only have a machine with an older Light Ridge available
> for testing. The patches work fine on that machine, I'm seeing a 1.5 W drop
> in powertop once the controller is powered down.

Tested on a 2013 MBA with Cactus Ridge. On bootup there's no change at all, but if I plug in the ethernet adapter and remove it, PM seems to kick in. We're talking about ~11.3W (bootup), ~13W (adapter plugged in without any connection), ~9.3W (after removing the adapter). The even more interesting part is that after plugging in the adapter again, consumption only goes up to ~10.4W instead of the initial value.
Comment 80 Hugo 2016-03-29 22:31:57 UTC
Since on of the recent releases (unsure which one), setting `acpi_osi=` seems to have introduced a new regression; the battery device is no longer created in /sys/class/power_supply, so I can't tell how much power I'm using/remaining battery.

This is reproducible in Linux 4.5.0.
Comment 81 Chen Yu 2016-04-03 01:25:18 UTC
(In reply to Hugo Osvaldo Barrera from comment #80)
> Since on of the recent releases (unsure which one), setting `acpi_osi=`
> seems to have introduced a new regression; the battery device is no longer
> created in /sys/class/power_supply, so I can't tell how much power I'm
> using/remaining battery.
> 
> This is reproducible in Linux 4.5.0.

I checked the log commit for osl.c, but can not find any changes directly related to your issue. Could you please help do a bisect for us? thx
Comment 82 Lv Zheng 2016-04-05 05:08:42 UTC
(In reply to Lukas Wunner from comment #77)
> I've implemented runtime pm for Thunderbolt now, this should at least
> partially fix the power regression. Maybe we don't need to change the OSI
> behaviour at all if this gets merged?
> 
> https://github.com/l1k/linux/commits/thunderbolt

IMO, Matthew's commit breaks acpi_osi= behavior, thus need to be reverted.
It's not related to the gap.
And the same functionality should be achieved in a different way.

Thanks and best regards
-Lv
Comment 83 Lukas Wunner 2016-04-05 13:25:17 UTC
@Lv Zheng: I'm fine with that as long as the default behaviour on Macs is to masquerade as Darwin (as it is now). Otherwise the Thunderbolt controller isn't accessible at all. (It's powered down on boot if the OS isn't Darwin.)
Comment 84 Lv Zheng 2016-04-06 04:16:25 UTC
(In reply to Lukas Wunner from comment #83)
> @Lv Zheng: I'm fine with that as long as the default behaviour on Macs is to
> masquerade as Darwin (as it is now). Otherwise the Thunderbolt controller
> isn't accessible at all. (It's powered down on boot if the OS isn't Darwin.)

Yes, we know.
The default behavior should be achieved with other means.
While the current way breaks things.

IMO, Linux should be able to detect if the machine is Darwin very early.
Earlier than the _OSI(Darwin) or any other _OSI(xxx) is invoked.
Then Linux can disable all Windows strings and enable Darwin string at that early stage.
Otherwise the code breaks things a lot.
It makes mess to other users.
Why don't you let the user specifying acpi_osi=Darwin from command line.
Users know this better than us.

It is almost impossible to make Linux to pretend to be both Windows and MacOS.
The choice has to be made by the user.

Thanks and best regards
-Lv
Comment 85 Lukas Wunner 2016-04-06 22:21:01 UTC
(In reply to Lv Zheng from comment #84)
> The default behavior should be achieved with other means.

The following should be functionally equivalent to the current behaviour:

if (dmi_match(DMI_SYS_VENDOR, "Apple Inc.") ||
    dmi_match(DMI_SYS_VENDOR, "Apple Computer, Inc.")) {
        <disable all Windows strings and enable Darwin string>
}

I'd be fine with that. Would you be comfortable with it as well? I'm not sure exactly at which point you would like to have that called so it would probably be best if you could come up with a patch. I'll be happy to test it, feel free to cc: me.

We already have a couple of similar Apple-specific quirks in drivers/acpi/.

The reason we need to check for two vendor names is that Apple changed their name in 2007. I don't think they ever used anything else as vendor name in the DMI table.
Comment 86 Lv Zheng 2016-04-07 02:51:02 UTC
(In reply to Lukas Wunner from comment #85)
> (In reply to Lv Zheng from comment #84)
> > The default behavior should be achieved with other means.
> 
> The following should be functionally equivalent to the current behaviour:
> 
> if (dmi_match(DMI_SYS_VENDOR, "Apple Inc.") ||
>     dmi_match(DMI_SYS_VENDOR, "Apple Computer, Inc.")) {
>         <disable all Windows strings and enable Darwin string>
> }
> 
> I'd be fine with that. Would you be comfortable with it as well? I'm not
> sure exactly at which point you would like to have that called so it would
> probably be best if you could come up with a patch. I'll be happy to test
> it, feel free to cc: me.
> 
> We already have a couple of similar Apple-specific quirks in drivers/acpi/.
> 
> The reason we need to check for two vendor names is that Apple changed their
> name in 2007. I don't think they ever used anything else as vendor name in
> the DMI table.

OK.
We'll generate a patch according to your suggestion.

Thanks
-Lv
Comment 87 Chen Yu 2016-04-19 04:06:14 UTC
Reassign to Lv for patch rewrite.
Comment 88 Lv Zheng 2016-04-25 07:18:06 UTC
Created attachment 213941 [details]
[PATCH 1/3] ACPI / osi: Cleanup _OSI("Linux") related code before introducing new support
Comment 89 Lv Zheng 2016-04-25 07:18:35 UTC
Created attachment 213951 [details]
[PATCH 2/3] ACPI / osi: Fix an issue that acpi_osi=!* cannot disable ACPICA internal strings
Comment 90 Lv Zheng 2016-04-25 07:19:00 UTC
Created attachment 213961 [details]
[PATCH 3/3] ACPI / osi: Change default _OSI(Darwin) support
Comment 91 Lv Zheng 2016-04-25 07:38:20 UTC
Created attachment 213971 [details]
[PATCH] ACPI / osi: Change default _OSI(Darwin) support

Uploaded the wrong version.
This is a correction.
Comment 92 Lv Zheng 2016-04-25 07:42:38 UTC
Hi,

Please help to:

1. apply the following patches:
attachment 213941 [details]
attachment 213951 [details]
attachment 213971 [details]

2. build and boot the kernel on an apple platform to see if _OSI("Darwin") != 0, and all _OSI("WindowsXXX") = 0

3. boot the kernel with acpi_osi=!Darwin on an apple platform to see if _OSI("Darwin") = 0 and all _OSI("WindowsXX") != 0

Thanks on advance.

Best regards
-Lv
Comment 93 Chen Yu 2016-04-28 08:23:37 UTC
Patch at 
https://patchwork.kernel.org/patch/8953891/
to avoid
Comment 94 Chen Yu 2016-04-28 08:28:15 UTC
(In reply to Chen Yu from comment #93)
> Patch at 
> https://patchwork.kernel.org/patch/8953891/
> to avoid

Patch sent to maillist to support acpi_osi=!Darwin.
And for runtime pm thunderbolt, I think it should be a feature rather than
a bug fix? @Lukas Wunner
Comment 95 Hugo 2016-04-28 11:23:36 UTC
The patch fails to apply for on both on 4.5.2, and mainline (4.6rc5):

$ cat src/linux-4.5/drivers/acpi/osl.c.rej 
--- drivers/acpi/osl.c
+++ drivers/acpi/osl.c
@@ -135,6 +135,9 @@  static struct acpi_osi_config {
        unsigned int    linux_enable:1;
        unsigned int    linux_dmi:1;
        unsigned int    linux_cmdline:1;
+       unsigned int    darwin_enable:1;
+       unsigned int    darwin_dmi:1;
+       unsigned int    darwin_cmdline:1;
        u8              default_disabling;
 } osi_config = {0, 0, 0, 0};
Comment 96 Lukas Wunner 2016-04-28 14:25:46 UTC
(In reply to Chen Yu from comment #94)
> Patch sent to maillist to support acpi_osi=!Darwin.
> And for runtime pm thunderbolt, I think it should be a feature rather than
> a bug fix? @Lukas Wunner

Sorry for the delay, Chen Yu & Lv Zheng, I've just saved v2 of your patches from the mailing list, will test them and report back either today or tomorrow. Thanks for your patience.
Comment 97 Lv Zheng 2016-04-29 01:29:37 UTC
I messed (In reply to Hugo Osvaldo Barrera from comment #95)
> The patch fails to apply for on both on 4.5.2, and mainline (4.6rc5):
> 
> $ cat src/linux-4.5/drivers/acpi/osl.c.rej 
> --- drivers/acpi/osl.c
> +++ drivers/acpi/osl.c
> @@ -135,6 +135,9 @@  static struct acpi_osi_config {
>         unsigned int    linux_enable:1;
>         unsigned int    linux_dmi:1;
>         unsigned int    linux_cmdline:1;
> +       unsigned int    darwin_enable:1;
> +       unsigned int    darwin_dmi:1;
> +       unsigned int    darwin_cmdline:1;
>         u8              default_disabling;
>  } osi_config = {0, 0, 0, 0};

Don't worry, we re-based the patches to make it stable materials.
So it won't trigger so many back porting issues.
http://www.spinics.net/lists/linux-acpi/msg65564.html

Thanks
-Lv
Comment 98 Lv Zheng 2016-04-29 01:45:21 UTC
(In reply to Lukas Wunner from comment #96)
> (In reply to Chen Yu from comment #94)
> > Patch sent to maillist to support acpi_osi=!Darwin.
> > And for runtime pm thunderbolt, I think it should be a feature rather than
> > a bug fix? @Lukas Wunner
> 
> Sorry for the delay, Chen Yu & Lv Zheng, I've just saved v2 of your patches
> from the mailing list, will test them and report back either today or
> tomorrow. Thanks for your patience.

It's not necessary.
Yu has macbook test platform and he has confirmed the patches to be working.
So linux-pm tree will ship them and you'll see them in 4.7 mainline.

If you want to give the fixes a try:

1. You need to modify attachment 213971 [details] by changing "Apple INC." and "Apple Computer, INC." to "Apple Inc." and "Apple Computer, Inc.".
I only did necessary unit test by faking DSDT on non Apple platforms.
So since I do not have real macbook I cannot notice this mistake.

2. You also can download the latest version from the following links:
https://patchwork.kernel.org/patch/8953941/
https://patchwork.kernel.org/patch/8953931/
https://patchwork.kernel.org/patch/8953921/
https://patchwork.kernel.org/patch/8953891/
For the last patch, you also need to modify "Apple INC." and "Apple Computer, INC." to "Apple Inc." and "Apple Computer, Inc.".

Thanks
-Lv
Comment 99 Lv Zheng 2016-04-29 01:59:20 UTC
It is not easy to confirm if Linux kernel returns _OSI(“WindowsXXX") correctly.
We confirmed that using the following unit testing mechanism:
Modify osl.c and add the following lines into acpi_osi_handler():
=====
if (!strcmp("Darwin", interface))
  pr_info("_OSI(Darwin) - %d\n", supported);
if (!strcmp("Windows 2000", interface))
  pr_info("_OSI(Windows 2000) - %d\n", supported);
=====
Hope the above information is usful for those want to confirm the patches.

Thanks
-Lv
Comment 100 Chen Yu 2016-04-29 02:01:47 UTC
(In reply to Lv Zheng from comment #99)
> It is not easy to confirm if Linux kernel returns _OSI(“WindowsXXX")
> correctly.
> We confirmed that using the following unit testing mechanism:
> Modify osl.c and add the following lines into acpi_osi_handler():
> =====
> if (!strcmp("Darwin", interface))
>   pr_info("_OSI(Darwin) - %d\n", supported);
> if (!strcmp("Windows 2000", interface))
>   pr_info("_OSI(Windows 2000) - %d\n", supported);

Actually they are 'Windows 2009' and 'Windows 2012'on Mac pro 12.
Comment 101 Lv Zheng 2016-04-29 02:13:42 UTC
(In reply to Chen Yu from comment #100)
> (In reply to Lv Zheng from comment #99)
> > We confirmed that using the following unit testing mechanism:
> > Modify osl.c and add the following lines into acpi_osi_handler():
> > =====
> > if (!strcmp("Darwin", interface))
> >   pr_info("_OSI(Darwin) - %d\n", supported);
> > if (!strcmp("Windows 2000", interface))
> >   pr_info("_OSI(Windows 2000) - %d\n", supported);
> 
> Actually they are 'Windows 2009' and 'Windows 2012'on Mac pro 12.

IMO, the validators should find the queried "WindowsXXX" string from the DSDT used on his own test platforms.
You can find the useful test string by the following commands:
# acpidump -b
# iasl -d dsdt.dat
# find *.dsl | xargs grep "_OSI (\"Windows"

Thanks and best regards
-Lv
Comment 102 Lv Zheng 2016-05-10 00:50:04 UTC
Patch was merged by linux-pm repo and will appear 4.7 mainline.
Let's close it.

Thanks and best regards
-Lv
Comment 103 David Purton 2016-10-04 07:13:22 UTC
Hi everyone,

I have a 11" MacBook Air 6,2 (early 2013). I am seeing battery life regression since kernel 4.4. Under 4.4 with acpi_osi= my idle power usage is around 3.5W. This translates to fantastic battery life lasting me all day.

Things broke badly with 4.5 (I gather this was to do with thunderbolt support). I'd hoped that the patch from this bug report would improve the situation, but I'm still not able to achieve the same power usage under 4.7. With kernel 4.7 and acpi_osi= my power usage is just under 5W. All other combinations I've tried for acpi_osi (including !Darwin) give even worse results.

Can anyone give me any pointers?

I use debian kernels. But have confirmed with vanilla ones built from git myself.

I am able to use git bisect to try and track things down. But if the problems are related to thunderbolt support being included from 4.5 I'm not sure how helpful this will be.

Thanks.

David
Comment 104 Lv Zheng 2016-10-10 08:20:54 UTC
Please file another bug, tracking this power regression.
Comment 105 David Purton 2016-10-10 09:32:08 UTC
New bug reported: https://bugzilla.kernel.org/show_bug.cgi?id=177151

Note You need to log in before you can comment on or make changes to this bug.