gmane.linux.acpi.devel

Re: REGRESSION: 3.10-rc1: Dell Latitude e6410 hangs within 3 seconds

Paul E. McKenney — 2013-05-18T23:06:51

Thank you for trying it out, and glad that it worked for you!

And I did already send the pull request.  But if I need to re-send it,
I will update to add your Tested-by.

Thanx, Paul


--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: REGRESSION: 3.10-rc1: Dell Latitude e6410 hangs within 3 seconds

Arend van Spriel — 2013-05-18T07:14:25

Thanks, Paul

That did the trick. Made me bumping into another regression in the 
driver I am maintaining so more fun to do :-)

Looking at the commit message I guess it is already in some tree. 
Otherwise I would have said: "You may add

Tested-by: Arend van Spriel <arend< at >broadcom.com>"


Oh, there is a typo in the commit message: sense iso senes.


Gr. AvS

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: REGRESSION: 3.10-rc1: Dell Latitude e6410 hangs within 3 seconds

Paul E. McKenney — 2013-05-18T01:47:25

Hello, Arend,

Thank you for tracking this down!  Could you please try out the following
patch?

Thanx, Paul

------------------------------------------------------------------------

rcu: Fix comparison sense in rcu_needs_cpu()

Commit c0f4dfd4f (rcu: Make RCU_FAST_NO_HZ take advantage of numbered
callbacks) introduced a bug that can result in excessively long grace
periods.  This bug reverse the senes of the "if" statement checking
for lazy callbacks, so that RCU takes a lazy approach when there are
in fact non-lazy callbacks.  This can result in excessive boot, suspend,
and resume times.

This commit therefore fixes the sense of this "if" statement.

Reported-by: Borislav Petkov <bp< at >alien8.de>
Reported-by: Bjørn Mork <bjorn< at >mork.no>
Reported-by: Joerg Roedel <joro< at >8bytes.org>
Signed-off-by: Paul E. McKenney <paulmck< at >linux.vnet.ibm.com>
Tested-by: Bjørn Mork <bjorn< at >mork.no>
Tested-by: Joerg Roedel <joro< at >8bytes.org>

diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 170814d..6d9

Re: enabling aspm on ati radeon

Phillip Susi — 2013-05-18T01:20:37

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/17/2013 08:40 PM, Bjorn Helgaas wrote:

I assume it would do no good to change it at this point; it would need
to already be set at the time the kernel reads it and decides whether
or not to enable it, so I'd have to have grub set it before loading
the kernel.


After
enabling it on both ends ( despite the root port still claiming
it is not supported ) I still see ~121 watts according to the
Kill-A-Watt my system is plugged into.  Oh well.

Now that I double check myself, I realize that I misread the Intel
spec.  I was actually looking at the description for the link control
register instead of capabilities.  It uses the word "supported"
instead of "enabled" when describing the enable bits in the control
register, and they seem to skip right over describing the capability
register.  Trying to write to that has no effect, so it seems the CPU
is really telling me it doesn't support ASPM on that link, though it
is supposed to according to the feature descript

Re: enabling aspm on ati radeon

Bjorn Helgaas — 2013-05-18T00:40:12

Right; I meant RO per the PCIe spec.  If it's RW on your chip, setpci
should be able to write it.


I don't think software can actually tell -- those transitions are
completely managed by hardware, and whenever the link is active, e.g.,
when you're accessing config space or transferring data, it would be
in L0.

If you can measure the power consumption, you might be able to see a
difference there.  I've seen people report that, but don't know how
they do it.  For example:
https://lkml.kernel.org/r/CANUX_P3F5YhbZX3WGU-j1AGpbXb_T9Bis2ErhvKkFMtDvzatVQ< at >mail.gmail.com

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: enabling aspm on ati radeon

Phillip Susi — 2013-05-18T00:15:23

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/17/2013 07:52 PM, Bjorn Helgaas wrote:

I assume it is RO according to the PCIe spec ( buggers seem to only
allow members of pcisig to download it ), but I checked the Intel
specs for the chip ( Sandybridge ) and it's RW.  It looks like it
powers up as 00 and it's up to the bios to change it to advertise the
capability, and it seems Asus didn't bother with that.


One thing I don't see anywhere is a status bit showing whether it
actually *is* in L0s or L1 currently, so how to know if it's working?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJRlsgbAAoJEJrBOlT6nu75mVEIAIsgXJjpqx5BTaocW3fJdq/D
6uqBiZxrIiwzCxHcsxyyq2gf2z1cwV/SExb8KCtjycZjXha4Y4awa1ba+1H8QnUe
YjLwRzsVSxlXUArwcUTrGQXsCYL5Q5IYejXAE0ki36Yfp5YvrKDLfuoKet76ROAY
cIGY7w202o9jfCVVoc2nskwXWCOuTgdfffD3Kjhg5eLnB/SxcCfbIWvxw7pNmlW1
bmzBNg3Mbs/UpGSFoSAOKl2/gzniMtjej3iXEuPy/gp/BjrT9ijExlaE5s4gdxom
12GgHMO/+rt

Re: REGRESSION: 3.10-rc1: Dell Latitude e6410 hangs within 3 seconds

Rafael J. Wysocki — 2013-05-17T23:45:30

Hi Paul,

Is this known?

Rafael


On Friday, May 17, 2013 10:49:16 PM Arend van Spriel wrote:

Re: enabling aspm on ati radeon

Bjorn Helgaas — 2013-05-17T21:28:56

A link has two ends.  Both ends have to support ASPM in order for it
to work.  But ASPM on a particular link has no dependency on things
elsewhere in the hierarchy.


The link between 00:01.0 and 01:00.0 apparently only supports ASPM on
one end (the downstream end), so ASPM won't work on it.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] efi: Work around bogus pointers in BGRT

Andy Lutomirski — 2013-05-17T21:05:33

The MSI MS-7760 supplies a BGRT marked "invalid" that contains a
pointer to nowhere.  Since an "invalid" BGRT isn't particularly
useful (userspace isn't supposed to use it anyway), ignore the BGRT
if it's marked "invalid" and the pointer points outside of EFI boot
services space.

Signed-off-by: Andy Lutomirski <luto< at >amacapital.net>
---
This seems to fix the problem for me.

 arch/x86/platform/efi/efi-bgrt.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/x86/platform/efi/efi-bgrt.c b/arch/x86/platform/efi/efi-bgrt.c
index 7145ec6..c77b7cf 100644
--- a/arch/x86/platform/efi/efi-bgrt.c
+++ b/arch/x86/platform/efi/efi-bgrt.c
< at >< at > -49,6 +49,18 < at >< at > void __init efi_bgrt_init(void)
 
 image = efi_lookup_mapped_addr(bgrt_tab->image_address);
 if (!image) {
+if (!(bgrt_tab->status & 1)) {
+/*
+ * The MSI MS-7760 exposes an "invalid" BGRT
+ * containing a pointer to nowhere.  This heuristic
+ * will avoid following that pointer.  (The idea
+ * is that an "invalid" image pointing

Re: REGRESSION: 3.10-rc1: Dell Latitude e6410 hangs within 3 seconds

Arend van Spriel — 2013-05-17T20:49:16

Hi Rafael,

The bisect result found commit c0f4dfd4f as culprit. I also verified 
that the merge into Linus' tree introduced the issue upstream, ie. 
6c24499 works and 1f889ec does not. I tried to revert the commit, but 
that was a bit risky (conflict to resolve) and did not give me a stable 
kernel. The only thing that works is selecting acpi=off. I tried also 
nohz=off but that resulted in /init failure.

Regards,
Arend

---8<----------------------------------------------------------------

commit 1f889ec62c3f0d8913f3c32f9aff2a1e15099346
   Merge: 6c24499 8fcfae3

   commit 8fcfae31719c0a6c03f2cf63f815b46d378d8be4
     Merge: d02a9a8 6d87669

     commit 6d87669357936bffa1e8fea7a4e7743e76905736
       Merge: 3f944ad 81e5949 910ee45

       commit c0f4dfd4f90f1667d234d21f15153ea09a2eaa66
       Author: Paul E. McKenney <paul.mckenney< at >linaro.org>
       Date:   Fri Dec 28 11:30:36 2012 -0800

           rcu: Make RCU_FAST_NO_HZ take advantage of numbered callbacks

           Because RCU callbacks are now a

Re: enabling aspm on ati radeon

Phillip Susi — 2013-05-17T20:10:07

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 5/17/2013 3:52 PM, Bjorn Helgaas wrote:

So do you still want the lspci -xxxs output, or was that just to
answer the question of why it said unknown instead of not supported?
Are we then back to no idea?

I notice a number of functions in drivers/pci/pcie/aspm.c that look
like they need used to configure aspm.  The radeon driver does not
appear to call any of them ( grep for aspm came up with nothing ).
Could that be why?  I can't find anything under Documentation/ about
what a driver needs to do to enable aspm.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRlo6eAAoJEJrBOlT6nu75lxQIAMwrt4oDHt5MKiRfpPWIkPO4
DLoFtEax1CGy1Gqmhvw8QpzYw+daqWzYw01t2SDd+owLEHVdp8zzqW21TSld83yb
W9EmZH4NLIO9vsR/UqAHhmbbf9ooAwz+O26Vb7EarPtpNxkRHybDSPYVsv7Cs/R7
54gJOefq7SroiiSr31I0dQT8j57SBRjekJJMGsEh+Et2Cxz+z8CwynCYCoNjQdOQ
g89lyifTEdEy2DuXcRfeCcIH1mTNQazjsRu2/P6I+P/klpyS+b9HqMSUUwNUDwc

Re: enabling aspm on ati radeon

Bjorn Helgaas — 2013-05-17T19:52:18

Nope, that one shouldn't affect the other devices.  I was just curious.

I just sent a patch to make lspci decode all possible values there.
In the PCIe r2.1 spec, only 1 ("L0s") and 3 ("L0s and L1") were
defined.  The r3 spec added 0 ("not supported") and 2 ("L1"), but
lspci hadn't quite kept up.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BGRT wild pointer

Andy Lutomirski — 2013-05-17T19:36:47

My MSI 79A-GD65 (8D) (MS-7760), which is a shining example of firmware
engineering, warns like this on startup:

[    0.061363] ioremap: invalid physical address d0bb01800000001
[    0.061365] ------------[ cut here ]------------
[    0.061368] WARNING: at arch/x86/mm/ioremap.c:85
__ioremap_caller+0x35a/0x370()
[    0.061369] Hardware name: MS-7760
[    0.061370] Modules linked in:
[    0.061372] Pid: 0, comm: swapper/0 Not tainted 3.8.11-200.fc18.x86_64 #1
[    0.061373] Call Trace:
[    0.061377]  [<ffffffff8105e675>] warn_slowpath_common+0x75/0xa0
[    0.061379]  [<ffffffff8105e6ba>] warn_slowpath_null+0x1a/0x20
[    0.061381]  [<ffffffff8104779a>] __ioremap_caller+0x35a/0x370
[    0.061383]  [<ffffffff81059645>] ? efi_bgrt_init+0xc5/0x160
[    0.061385]  [<ffffffff813800b0>] ? acpi_get_table_with_size+0x5f/0xbe
[    0.061386]  [<ffffffff81047807>] ioremap_nocache+0x17/0x20
[    0.061388]  [<ffffffff81059645>] efi_bgrt_init+0xc5/0x160
[    0.061390]  [<ffffffff81d18bb6>] efi_late_init+0x9/0xb
[    0.06139

Get your Free $5 in 30 Seconds or Less

Shelby Clark — 2013-05-17T15:31:50

Yes! Now Free Members can make a whole lot of money and never be harassed about paying for membership. There are no paid memberships. Only Free members that make "You" money on 3 different levels and you get paid 7 different ways. This is the craziest thing you've ever seen. Finally a Real Online Business that you make money with on the first day you sign up and just tell others to get their $5 to make even more. If your one of the vast majority of people that made little or no money online, than that is about to end in 30 Seconds (Unless you type slowly)



Again, thats:

    $5 Free just for Signing Up Guaranteed

    No Paid Memberships so It's Always Free

    Get paid in 7 Different ways

    Get Paid on 3 Levels, No confusing matrices or procedures

    Get Paid for Telling Others to get their free $5

    Grow your own Massive List for Free to contact about anything



Change that situation Right Now.



Go Here Now!!!!

http://goo.gl/YthnO



Make sure to click "Free Member" or "Money Plug-In"

--
To

Re: [PATCH 1/2] ACPI/APEI: Add parameter check before error injection

Borislav Petkov — 2013-05-17T09:07:16

I already did my review. Having a bool checkparam and querying it
straight afterwards is clumsy code. Also you're adding a redundant
definiton of PAGE_MASK even though it already exists in the kernel.
Maybe you should've grepped the sources first...

Not to mention that this check seems wrong:

((param2 & PAGE_MASK) != PAGE_MASK)

But hey, I have better things to do instead of wasting time with this.

Re: [PATCH 2/2] ACPI/APEI: Update einj documentation for param1/param2

Chen Gong — 2013-05-17T05:10:40

OK, I will(exmaple & relatd).

Re: [PATCH 1/2] ACPI/APEI: Add parameter check before error injection

Chen Gong — 2013-05-17T05:09:32

Hi, Boris

Thanks for your review. I agree with you about readability enhancement.
IMHO, I don't think your attached patch has obvious improvment. I paste
my updated patch here and please continue to review. I will send updated
patch based on your further review.

In this patch, I update previous confused definition at the same time.
They are very little and no ill-efect so I don't write a new patch
for it.

diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
index 8d457b5..dba59be 100644
--- a/drivers/acpi/apei/einj.c
+++ b/drivers/acpi/apei/einj.c
< at >< at > -32,6 +32,7 < at >< at >
 #include <linux/seq_file.h>
 #include <linux/nmi.h>
 #include <linux/delay.h>
+#include <linux/mm.h>
 #include <acpi/acpi.h>

 #include "apei-internal.h"
< at >< at > -41,6 +42,11 < at >< at >
 #define SPIN_UNIT              100                     /* 100ns */
 /* Firmware should respond within 1 milliseconds */
 #define FIRMWARE_TIMEOUT       (1 * NSEC_PER_MSEC)
+#define ACPI5_VENDOR_BIT       BIT(31)
+#define PAGE_MASK              0xfffffffffffff0

Re: [GIT PULL] Power management and ACPI fixes for v3.10-rc2

Dirk Brandewie — 2013-05-16T23:36:12

No they are not I will send the patch out in the morning.


--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Power management and ACPI fixes for v3.10-rc2

Linus Torvalds — 2013-05-16T22:25:35

Btw, is there some fundamental reason why the pstate driver is limited
to so few models?

I've tested it on models 0x25 (i5-670) and 0x3a (i5-3427U), and it
seems to work. But neither model is listed. (only 0x2a and 0x2d are).

I understand that people want to be careful, but it's not actually
getting very much *testing* right now, is it? Are models 0x2a/0x2d
actually special in any way?

                  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2, part3 11/11] PCI, ACPI, pci_root: use PCI bus lock to protect PCI device hotplug

Rafael J. Wysocki — 2013-05-16T19:59:27

Acked-by: Rafael J. Wysocki <rafael.j.wysocki< at >intel.com>

[RFC PATCH v2, part3 11/11] PCI, ACPI, pci_root: use PCI bus lock to protect PCI device hotplug

Jiang Liu — 2013-05-16T15:50:59

Use PCI bus lock to protect concurrent PCI device hotplug operations.

Signed-off-by: Jiang Liu <jiang.liu< at >huawei.com>
Cc: Thomas Gleixner <tglx< at >linutronix.de>
Cc: Ingo Molnar <mingo< at >redhat.com>
Cc: "H. Peter Anvin" <hpa< at >zytor.com>
Cc: x86< at >kernel.org
Cc: Len Brown <lenb< at >kernel.org>
Cc: "Rafael J. Wysocki" <rjw< at >sisk.pl>
Cc: Yinghai Lu <yinghai< at >kernel.org>
Cc: Feng Tang <feng.tang< at >intel.com>
Cc: linux-kernel< at >vger.kernel.org
Cc: linux-acpi< at >vger.kernel.org
---
 arch/ia64/pci/pci.c     |  2 +-
 arch/x86/pci/acpi.c     |  3 ++-
 drivers/acpi/pci_root.c | 14 ++++++++------
 drivers/pci/Kconfig     |  2 +-
 4 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index de1474f..6e91e87 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
< at >< at > -384,7 +384,7 < at >< at > struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
 }
 
 pci_scan_child_bus(pbus);
-return pbus;
+return pci_bus_get(pbus);
 
 out3:
 kfree(controller->window);
diff --git a/arch/x86/pci/acpi