Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1555979 > unrolled thread

[char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

Back to article view | Back to linux.kernel

Contents

  [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer Tomas Winkler <tomas.winkler@intel.com> - 2017-01-10 23:40 +0100
    Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for  SPT and newer Jan Niehusmann <jan@gondor.com> - 2017-01-11 00:00 +0100
      RE: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only  for SPT and newer "Winkler, Tomas" <tomas.winkler@intel.com> - 2017-01-11 10:30 +0100
        Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for  SPT and newer Paul Menzel <pmenzel@molgen.mpg.de> - 2017-01-11 11:30 +0100
          RE: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only  for SPT and newer "Winkler, Tomas" <tomas.winkler@intel.com> - 2017-01-11 12:00 +0100
          RE: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only  for SPT and newer "Winkler, Tomas" <tomas.winkler@intel.com> - 2017-01-11 15:20 +0100
            Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for  SPT and newer Paul Menzel <pmenzel@molgen.mpg.de> - 2017-01-11 15:30 +0100
              RE: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only  for SPT and newer "Winkler, Tomas" <tomas.winkler@intel.com> - 2017-01-11 17:20 +0100
              Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for  SPT and newer Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-13 14:10 +0100
                Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for  SPT and newer Paul Menzel <pmenzel@molgen.mpg.de> - 2017-01-14 20:30 +0100
                  Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for  SPT and newer Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-14 20:40 +0100
                    RE: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only  for SPT and newer "Winkler, Tomas" <tomas.winkler@intel.com> - 2017-01-15 08:20 +0100
                      Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for  SPT and newer Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-15 12:00 +0100
                        Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for  SPT and newer Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-01-16 12:10 +0100
                          Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for  SPT and newer Thorsten Leemhuis <linux@leemhuis.info> - 2017-01-17 09:40 +0100
                            RE: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:  bus: enable OS version only for SPT and newer) <Mario.Limonciello@dell.com> - 2017-01-17 18:00 +0100
                              Re: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:  bus: enable OS version only for SPT and newer) Greg KH <gregkh@linuxfoundation.org> - 2017-01-17 19:40 +0100
                                RE: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:  bus: enable OS version only for SPT and newer) <Mario.Limonciello@dell.com> - 2017-01-17 20:00 +0100
                                  Re: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:  bus: enable OS version only for SPT and newer) Darren Hart <dvhart@infradead.org> - 2017-01-18 00:40 +0100
                                    RE: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:  bus: enable OS version only for SPT and newer) <Mario.Limonciello@dell.com> - 2017-01-21 00:20 +0100
                                      Re: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:  bus: enable OS version only for SPT and newer) Greg KH <gregkh@linuxfoundation.org> - 2017-01-21 10:20 +0100
                                        Re: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:  bus: enable OS version only for SPT and newer) "Rafael J. Wysocki" <rafael@kernel.org> - 2017-01-21 13:00 +0100
                                          Re: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:  bus: enable OS version only for SPT and newer) Greg KH <gregkh@linuxfoundation.org> - 2017-01-22 12:30 +0100
                                        RE: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:  bus: enable OS version only for SPT and newer) <Mario.Limonciello@dell.com> - 2017-01-24 21:30 +0100
                                      Re: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:  bus: enable OS version only for SPT and newer) "Rafael J. Wysocki" <rafael@kernel.org> - 2017-01-22 10:50 +0100
                                        RE: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:  bus: enable OS version only for SPT and newer) <Mario.Limonciello@dell.com> - 2017-01-24 21:20 +0100
                              Re: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:  bus: enable OS version only for SPT and newer) "Rafael J. Wysocki" <rafael@kernel.org> - 2017-01-18 03:20 +0100
                                Re: Regression on Dell XPS13 Paul Menzel <pmenzel@molgen.mpg.de> - 2017-01-18 12:20 +0100
                                  Re: Regression on Dell XPS13 "Rafael J. Wysocki" <rafael@kernel.org> - 2017-01-18 12:40 +0100
                            Re: Regression on Dell XPS13 Thorsten Leemhuis <linux@leemhuis.info> - 2017-01-17 18:40 +0100

Page 1 of 2  [1] 2  Next page →

#1555979 — [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

From: Alexander Usyskin <alexander.usyskin@intel.com>

Sending OS version for support of TPM2_ChangeEPS() is required only
for SPT FW (HMB version 2.0) and newer.
On older platforms the command should be just ignored by the firmware
but some older platforms misbehave so it's safer to send the command
only if required.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=192051
Fixes: 7279b238bade (mei: send OS type to the FW)
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
V2: use correct sha1 of the original buggy patch

 drivers/misc/mei/bus-fixup.c | 3 +++
 drivers/misc/mei/debugfs.c   | 2 ++
 drivers/misc/mei/hbm.c       | 4 ++++
 drivers/misc/mei/hw.h        | 6 ++++++
 drivers/misc/mei/mei_dev.h   | 2 ++
 5 files changed, 17 insertions(+)

diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 18e05ca7584f..3600c9993a98 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -152,6 +152,9 @@ static void mei_mkhi_fix(struct mei_cl_device *cldev)
 {
 	int ret;
 
+	if (!cldev->bus->hbm_f_os_supported)
+		return;
+
 	ret = mei_cldev_enable(cldev);
 	if (ret)
 		return;
diff --git a/drivers/misc/mei/debugfs.c b/drivers/misc/mei/debugfs.c
index c6c051b52f55..c6217a4993ad 100644
--- a/drivers/misc/mei/debugfs.c
+++ b/drivers/misc/mei/debugfs.c
@@ -180,6 +180,8 @@ static ssize_t mei_dbgfs_read_devstate(struct file *fp, char __user *ubuf,
 				 dev->hbm_f_ev_supported);
 		pos += scnprintf(buf + pos, bufsz - pos, "\tFA: %01d\n",
 				 dev->hbm_f_fa_supported);
+		pos += scnprintf(buf + pos, bufsz - pos, "\tOS: %01d\n",
+				 dev->hbm_f_os_supported);
 	}
 
 	pos += scnprintf(buf + pos, bufsz - pos, "pg:  %s, %s\n",
diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index dd7f15a65eed..25b4a1ba522d 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -989,6 +989,10 @@ static void mei_hbm_config_features(struct mei_device *dev)
 	/* Fixed Address Client Support */
 	if (dev->version.major_version >= HBM_MAJOR_VERSION_FA)
 		dev->hbm_f_fa_supported = 1;
+
+	/* OS ver message Support */
+	if (dev->version.major_version >= HBM_MAJOR_VERSION_OS)
+		dev->hbm_f_os_supported = 1;
 }
 
 /**
diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h
index 9daf3f9aed25..e1e4d47d4d7d 100644
--- a/drivers/misc/mei/hw.h
+++ b/drivers/misc/mei/hw.h
@@ -76,6 +76,12 @@
 #define HBM_MINOR_VERSION_FA               0
 #define HBM_MAJOR_VERSION_FA               2
 
+/*
+ * MEI version with OS ver message support
+ */
+#define HBM_MINOR_VERSION_OS               0
+#define HBM_MAJOR_VERSION_OS               2
+
 /* Host bus message command opcode */
 #define MEI_HBM_CMD_OP_MSK                  0x7f
 /* Host bus message command RESPONSE */
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index 699693cd8c59..8dadb98662a9 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -406,6 +406,7 @@ const char *mei_pg_state_str(enum mei_pg_state state);
  * @hbm_f_ev_supported  : hbm feature event notification
  * @hbm_f_fa_supported  : hbm feature fixed address client
  * @hbm_f_ie_supported  : hbm feature immediate reply to enum request
+ * @hbm_f_os_supported  : hbm feature support OS ver message
  *
  * @me_clients_rwsem: rw lock over me_clients list
  * @me_clients  : list of FW clients
@@ -487,6 +488,7 @@ struct mei_device {
 	unsigned int hbm_f_ev_supported:1;
 	unsigned int hbm_f_fa_supported:1;
 	unsigned int hbm_f_ie_supported:1;
+	unsigned int hbm_f_os_supported:1;
 
 	struct rw_semaphore me_clients_rwsem;
 	struct list_head me_clients;
-- 
2.7.4

[toc] | [next] | [standalone]

#1555985 — Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler wrote:
> On older platforms the command should be just ignored by the firmware
> but some older platforms misbehave so it's safer to send the command
> only if required.

Thanks! This fixes suspend-to-ram for me (on a Thinkpad x201s).

Jan

[toc] | [prev] | [next] | [standalone]

#1556318 — RE: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

> 
> On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler wrote:
> > On older platforms the command should be just ignored by the firmware
> > but some older platforms misbehave so it's safer to send the command
> > only if required.
> 
> Thanks! This fixes suspend-to-ram for me (on a Thinkpad x201s).

What about Dell XPS13 ? 

Thanks
Tomas 

[toc] | [prev] | [next] | [standalone]

#1556370 — Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

Dear Tomas,


On 01/11/17 10:24, Winkler, Tomas wrote:
>>
>> On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler wrote:
>>> On older platforms the command should be just ignored by the firmware
>>> but some older platforms misbehave so it's safer to send the command
>>> only if required.
>>
>> Thanks! This fixes suspend-to-ram for me (on a Thinkpad x201s).
>
> What about Dell XPS13?

With Linus’ master branch from today, and Greg’s char-misc-linus merged 
(Merge: 807b93e995d1 546cf3ef9c92), the regression is still there.

I am now building a Linux kernel image with the two commits touching 
`bus-fixup.c` reverted.

Do you want me to open a separate bug report for that, or continue 
debugging in the existing report [1], which is currently marked as resolved?

Do you have Kaby Lake devices sitting around for testing?


Kind regards,

Paul


[1] https://bugzilla.kernel.org/show_bug.cgi?id=192051
     "[Bug 192051] [bisected] No hibernation/suspend/shutdown after 
commit 7279b238badec09efd0545293e64c21feee97f73"

[toc] | [prev] | [next] | [standalone]

#1556389 — RE: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

> Dear Tomas,
> 
> 
> On 01/11/17 10:24, Winkler, Tomas wrote:
> >>
> >> On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler wrote:
> >>> On older platforms the command should be just ignored by the
> >>> firmware but some older platforms misbehave so it's safer to send
> >>> the command only if required.
> >>
> >> Thanks! This fixes suspend-to-ram for me (on a Thinkpad x201s).
> >
> > What about Dell XPS13?
> 
> With Linus' master branch from today, and Greg's char-misc-linus merged
> (Merge: 807b93e995d1 546cf3ef9c92), the regression is still there.
> 
Hmm, this should work on KBL....

> I am now building a Linux kernel image with the two commits touching `bus-
> fixup.c` reverted.

Thanks for the effort.

> Do you want me to open a separate bug report for that, or continue debugging
> in the existing report [1], which is currently marked as resolved?

Let's get some more data, shouldn't take long time.
> 
> Do you have Kaby Lake devices sitting around for testing?

We will of course try to reproduce the issue locally.

Thanks
Tomas

[toc] | [prev] | [next] | [standalone]

#1556513 — RE: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

> > Dear Tomas,
> >
> >
> > On 01/11/17 10:24, Winkler, Tomas wrote:
> > >>
> > >> On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler wrote:
> > >>> On older platforms the command should be just ignored by the
> > >>> firmware but some older platforms misbehave so it's safer to send
> > >>> the command only if required.
> > >>
> > >> Thanks! This fixes suspend-to-ram for me (on a Thinkpad x201s).
> > >
> > > What about Dell XPS13?
> >
> > With Linus' master branch from today, and Greg's char-misc-linus
> > merged
> > (Merge: 807b93e995d1 546cf3ef9c92), the regression is still there.
> >
> Hmm, this should work on KBL....
> 
> > I am now building a Linux kernel image with the two commits touching
> > `bus- fixup.c` reverted.
> 
> Thanks for the effort.
> 
> > Do you want me to open a separate bug report for that, or continue
> > debugging in the existing report [1], which is currently marked as resolved?
> 
> Let's get some more data, shouldn't take long time.
> >
> > Do you have Kaby Lake devices sitting around for testing?
> 
> We will of course try to reproduce the issue locally.
>

Paul, currently we cannot reproduce this issue on Kaby Lake platforms on our side, we would be great for more debug data from your side.
You can get more info by enabling  mode debug logs

echo -n 'module mei +lfp' > /sys/kernel/debug/dynamic_debug/control
echo -n 'module mei_me +lfp' > /sys/kernel/debug/dynamic_debug/control


Thanks
Tmas

[toc] | [prev] | [next] | [standalone]

#1556523 — Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

Dear Tomas,


On 01/11/17 15:12, Winkler, Tomas wrote:

>>> On 01/11/17 10:24, Winkler, Tomas wrote:
>>>>>
>>>>> On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler wrote:
>>>>>> On older platforms the command should be just ignored by the
>>>>>> firmware but some older platforms misbehave so it's safer to send
>>>>>> the command only if required.
>>>>>
>>>>> Thanks! This fixes suspend-to-ram for me (on a Thinkpad x201s).
>>>>
>>>> What about Dell XPS13?
>>>
>>> With Linus' master branch from today, and Greg's char-misc-linus
>>> merged
>>> (Merge: 807b93e995d1 546cf3ef9c92), the regression is still there.
>>
>> Hmm, this should work on KBL....
>>
>>> I am now building a Linux kernel image with the two commits touching
>>> `bus- fixup.c` reverted.
>>
>> Thanks for the effort.
>>
>>> Do you want me to open a separate bug report for that, or continue
>>> debugging in the existing report [1], which is currently marked as resolved?
>>
>> Let's get some more data, shouldn't take long time.
>>>
>>> Do you have Kaby Lake devices sitting around for testing?
>>
>> We will of course try to reproduce the issue locally.
>
> Paul, currently we cannot reproduce this issue on Kaby Lake platforms on our side,

It looks like it’s a different issue. Reverting the two commits touching 
`bus-fixup.c`, did not help.

> we would be great for more debug data from your side.
> You can get more info by enabling  mode debug logs
>
> echo -n 'module mei +lfp' > /sys/kernel/debug/dynamic_debug/control
> echo -n 'module mei_me +lfp' > /sys/kernel/debug/dynamic_debug/control

I am currently bisecting to find the culprit. 13 steps will take some 
time though.

Tomas, I believe Intel’s “ACPI department” got access to a Dell XPS13.


Kind regards,

Paul

[toc] | [prev] | [next] | [standalone]

#1556675 — RE: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

> On 01/11/17 15:12, Winkler, Tomas wrote:
> 
> >>> On 01/11/17 10:24, Winkler, Tomas wrote:
> >>>>>
> >>>>> On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler wrote:
> >>>>>> On older platforms the command should be just ignored by the
> >>>>>> firmware but some older platforms misbehave so it's safer to send
> >>>>>> the command only if required.
> >>>>>
> >>>>> Thanks! This fixes suspend-to-ram for me (on a Thinkpad x201s).
> >>>>
> >>>> What about Dell XPS13?
> >>>
> >>> With Linus' master branch from today, and Greg's char-misc-linus
> >>> merged
> >>> (Merge: 807b93e995d1 546cf3ef9c92), the regression is still there.
> >>
> >> Hmm, this should work on KBL....
> >>
> >>> I am now building a Linux kernel image with the two commits touching
> >>> `bus- fixup.c` reverted.
> >>
> >> Thanks for the effort.
> >>
> >>> Do you want me to open a separate bug report for that, or continue
> >>> debugging in the existing report [1], which is currently marked as resolved?
> >>
> >> Let's get some more data, shouldn't take long time.
> >>>
> >>> Do you have Kaby Lake devices sitting around for testing?
> >>
> >> We will of course try to reproduce the issue locally.
> >
> > Paul, currently we cannot reproduce this issue on Kaby Lake platforms
> > on our side,
> 
> It looks like it's a different issue. Reverting the two commits touching `bus-
> fixup.c`, did not help.
> 
> > we would be great for more debug data from your side.
> > You can get more info by enabling  mode debug logs
> >
> > echo -n 'module mei +lfp' > /sys/kernel/debug/dynamic_debug/control
> > echo -n 'module mei_me +lfp' > /sys/kernel/debug/dynamic_debug/control
> 
> I am currently bisecting to find the culprit. 13 steps will take some time
> though.
> 
> Tomas, I believe Intel's "ACPI department" got access to a Dell XPS13.
> 
> 
> Kind regards,
> 
Thanks for updated, really appreciated your engagement.  I believe this closes the issue from MEI side.
I'll be watching this ACPI issue as well. 
Thanks
Tomas

[toc] | [prev] | [next] | [standalone]

#1558390 — Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

On Wed, Jan 11, 2017 at 03:26:06PM +0100, Paul Menzel wrote:
> Dear Tomas,
> 
> 
> On 01/11/17 15:12, Winkler, Tomas wrote:
> 
> > > > On 01/11/17 10:24, Winkler, Tomas wrote:
> > > > > > 
> > > > > > On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler wrote:
> > > > > > > On older platforms the command should be just ignored by the
> > > > > > > firmware but some older platforms misbehave so it's safer to send
> > > > > > > the command only if required.
> > > > > > 
> > > > > > Thanks! This fixes suspend-to-ram for me (on a Thinkpad x201s).
> > > > > 
> > > > > What about Dell XPS13?
> > > > 
> > > > With Linus' master branch from today, and Greg's char-misc-linus
> > > > merged
> > > > (Merge: 807b93e995d1 546cf3ef9c92), the regression is still there.
> > > 
> > > Hmm, this should work on KBL....
> > > 
> > > > I am now building a Linux kernel image with the two commits touching
> > > > `bus- fixup.c` reverted.
> > > 
> > > Thanks for the effort.
> > > 
> > > > Do you want me to open a separate bug report for that, or continue
> > > > debugging in the existing report [1], which is currently marked as resolved?
> > > 
> > > Let's get some more data, shouldn't take long time.
> > > > 
> > > > Do you have Kaby Lake devices sitting around for testing?
> > > 
> > > We will of course try to reproduce the issue locally.
> > 
> > Paul, currently we cannot reproduce this issue on Kaby Lake platforms on our side,
> 
> It looks like it’s a different issue. Reverting the two commits touching
> `bus-fixup.c`, did not help.
> 
> > we would be great for more debug data from your side.
> > You can get more info by enabling  mode debug logs
> > 
> > echo -n 'module mei +lfp' > /sys/kernel/debug/dynamic_debug/control
> > echo -n 'module mei_me +lfp' > /sys/kernel/debug/dynamic_debug/control
> 
> I am currently bisecting to find the culprit. 13 steps will take some time
> though.

I can duplicate this on my laptop here as well :(

Did you get anywhere with your bisection?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1559060 — Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

Dear Greg,


On 2017-01-13 14:00, Greg Kroah-Hartman wrote:
> On Wed, Jan 11, 2017 at 03:26:06PM +0100, Paul Menzel wrote:

>> On 01/11/17 15:12, Winkler, Tomas wrote:
>> 
>> > > > On 01/11/17 10:24, Winkler, Tomas wrote:
>> > > > > >
>> > > > > > On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler wrote:
>> > > > > > > On older platforms the command should be just ignored by the
>> > > > > > > firmware but some older platforms misbehave so it's safer to send
>> > > > > > > the command only if required.
>> > > > > >
>> > > > > > Thanks! This fixes suspend-to-ram for me (on a Thinkpad x201s).
>> > > > >
>> > > > > What about Dell XPS13?
>> > > >
>> > > > With Linus' master branch from today, and Greg's char-misc-linus
>> > > > merged
>> > > > (Merge: 807b93e995d1 546cf3ef9c92), the regression is still there.
>> > >
>> > > Hmm, this should work on KBL....
>> > >
>> > > > I am now building a Linux kernel image with the two commits touching
>> > > > `bus- fixup.c` reverted.
>> > >
>> > > Thanks for the effort.
>> > >
>> > > > Do you want me to open a separate bug report for that, or continue
>> > > > debugging in the existing report [1], which is currently marked as resolved?
>> > >
>> > > Let's get some more data, shouldn't take long time.
>> > > >
>> > > > Do you have Kaby Lake devices sitting around for testing?
>> > >
>> > > We will of course try to reproduce the issue locally.
>> >
>> > Paul, currently we cannot reproduce this issue on Kaby Lake platforms on our side,
>> 
>> It looks like it’s a different issue. Reverting the two commits 
>> touching
>> `bus-fixup.c`, did not help.
>> 
>> > we would be great for more debug data from your side.
>> > You can get more info by enabling  mode debug logs
>> >
>> > echo -n 'module mei +lfp' > /sys/kernel/debug/dynamic_debug/control
>> > echo -n 'module mei_me +lfp' > /sys/kernel/debug/dynamic_debug/control
>> 
>> I am currently bisecting to find the culprit. 13 steps will take some 
>> time
>> though.
> 
> I can duplicate this on my laptop here as well :(

Which system do you have?

> Did you get anywhere with your bisection?

Sorry, I replied to a different message with my status.

Please see my status below. I’ll have access to the machine on Monday 
again.

```
$ git bisect log
git bisect start
# good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9
git bisect good 69973b830859bc6529a7a0468ba0d80ee5117826
# good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9
git bisect good 69973b830859bc6529a7a0468ba0d80ee5117826
# bad: [a121103c922847ba5010819a3f250f1f7fc84ab8] Linux 4.10-⁠rc3
git bisect bad a121103c922847ba5010819a3f250f1f7fc84ab8
# bad: [72cca7baf4fba777b8ab770b902cf2e08941773f] Merge tag 
'staging-4.10-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
git bisect bad 72cca7baf4fba777b8ab770b902cf2e08941773f
# good: [b8d2798f32785398fcd1c48ea80c0c6c5ab88537] Merge tag 
'clk-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
git bisect good b8d2798f32785398fcd1c48ea80c0c6c5ab88537
# good: [9439b3710df688d853eb6cb4851256f2c92b1797] Merge tag 
'drm-for-v4.10' of git://people.freedesktop.org/~airlied/linux
git bisect good 9439b3710df688d853eb6cb4851256f2c92b1797
```


Kind regards,

Paul

[toc] | [prev] | [next] | [standalone]

#1559064 — Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

On Sat, Jan 14, 2017 at 08:27:31PM +0100, Paul Menzel wrote:
> Dear Greg,
> 
> 
> On 2017-01-13 14:00, Greg Kroah-Hartman wrote:
> > On Wed, Jan 11, 2017 at 03:26:06PM +0100, Paul Menzel wrote:
> 
> > > On 01/11/17 15:12, Winkler, Tomas wrote:
> > > 
> > > > > > On 01/11/17 10:24, Winkler, Tomas wrote:
> > > > > > > >
> > > > > > > > On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler wrote:
> > > > > > > > > On older platforms the command should be just ignored by the
> > > > > > > > > firmware but some older platforms misbehave so it's safer to send
> > > > > > > > > the command only if required.
> > > > > > > >
> > > > > > > > Thanks! This fixes suspend-to-ram for me (on a Thinkpad x201s).
> > > > > > >
> > > > > > > What about Dell XPS13?
> > > > > >
> > > > > > With Linus' master branch from today, and Greg's char-misc-linus
> > > > > > merged
> > > > > > (Merge: 807b93e995d1 546cf3ef9c92), the regression is still there.
> > > > >
> > > > > Hmm, this should work on KBL....
> > > > >
> > > > > > I am now building a Linux kernel image with the two commits touching
> > > > > > `bus- fixup.c` reverted.
> > > > >
> > > > > Thanks for the effort.
> > > > >
> > > > > > Do you want me to open a separate bug report for that, or continue
> > > > > > debugging in the existing report [1], which is currently marked as resolved?
> > > > >
> > > > > Let's get some more data, shouldn't take long time.
> > > > > >
> > > > > > Do you have Kaby Lake devices sitting around for testing?
> > > > >
> > > > > We will of course try to reproduce the issue locally.
> > > >
> > > > Paul, currently we cannot reproduce this issue on Kaby Lake platforms on our side,
> > > 
> > > It looks like it’s a different issue. Reverting the two commits
> > > touching
> > > `bus-fixup.c`, did not help.
> > > 
> > > > we would be great for more debug data from your side.
> > > > You can get more info by enabling  mode debug logs
> > > >
> > > > echo -n 'module mei +lfp' > /sys/kernel/debug/dynamic_debug/control
> > > > echo -n 'module mei_me +lfp' > /sys/kernel/debug/dynamic_debug/control
> > > 
> > > I am currently bisecting to find the culprit. 13 steps will take
> > > some time
> > > though.
> > 
> > I can duplicate this on my laptop here as well :(
> 
> Which system do you have?

A Dell XPS13, don't know what cpu type it is, here's the output of one
cpu from /proc/cpuinfo

processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 78
model name	: Intel(R) Core(TM) i7-6560U CPU @ 2.20GHz
stepping	: 3
microcode	: 0x8a
cpu MHz		: 712.207
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 2
apicid		: 3
initial apicid	: 3
fpu		: yes
fpu_exception	: yes
cpuid level	: 22
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
bugs		:
bogomips	: 4419.34
clflush size	: 64
cache_alignment	: 64
address sizes	: 39 bits physical, 48 bits virtual
power management:

> > Did you get anywhere with your bisection?
> 
> Sorry, I replied to a different message with my status.
> 
> Please see my status below. I’ll have access to the machine on Monday again.
> 
> ```
> $ git bisect log
> git bisect start
> # good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9
> git bisect good 69973b830859bc6529a7a0468ba0d80ee5117826
> # good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9
> git bisect good 69973b830859bc6529a7a0468ba0d80ee5117826
> # bad: [a121103c922847ba5010819a3f250f1f7fc84ab8] Linux 4.10-⁠rc3
> git bisect bad a121103c922847ba5010819a3f250f1f7fc84ab8
> # bad: [72cca7baf4fba777b8ab770b902cf2e08941773f] Merge tag
> 'staging-4.10-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
> git bisect bad 72cca7baf4fba777b8ab770b902cf2e08941773f
> # good: [b8d2798f32785398fcd1c48ea80c0c6c5ab88537] Merge tag 'clk-for-linus'
> of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
> git bisect good b8d2798f32785398fcd1c48ea80c0c6c5ab88537
> # good: [9439b3710df688d853eb6cb4851256f2c92b1797] Merge tag 'drm-for-v4.10'
> of git://people.freedesktop.org/~airlied/linux
> git bisect good 9439b3710df688d853eb6cb4851256f2c92b1797
> ```
> 

You are close!  I'll try bisection tomorrow if I have some spare time.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1559174 — RE: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

> Subject: Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT
> and newer
> 
> On Sat, Jan 14, 2017 at 08:27:31PM +0100, Paul Menzel wrote:
> > Dear Greg,
> >
> >
> > On 2017-01-13 14:00, Greg Kroah-Hartman wrote:
> > > On Wed, Jan 11, 2017 at 03:26:06PM +0100, Paul Menzel wrote:
> >
> > > > On 01/11/17 15:12, Winkler, Tomas wrote:
> > > >
> > > > > > > On 01/11/17 10:24, Winkler, Tomas wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler
> wrote:
> > > > > > > > > > On older platforms the command should be just ignored
> > > > > > > > > > by the firmware but some older platforms misbehave so
> > > > > > > > > > it's safer to send the command only if required.
> > > > > > > > >
> > > > > > > > > Thanks! This fixes suspend-to-ram for me (on a Thinkpad x201s).
> > > > > > > >
> > > > > > > > What about Dell XPS13?
> > > > > > >
> > > > > > > With Linus' master branch from today, and Greg's
> > > > > > > char-misc-linus merged
> > > > > > > (Merge: 807b93e995d1 546cf3ef9c92), the regression is still there.
> > > > > >
> > > > > > Hmm, this should work on KBL....
> > > > > >
> > > > > > > I am now building a Linux kernel image with the two commits
> > > > > > > touching
> > > > > > > `bus- fixup.c` reverted.
> > > > > >
> > > > > > Thanks for the effort.
> > > > > >
> > > > > > > Do you want me to open a separate bug report for that, or
> > > > > > > continue debugging in the existing report [1], which is currently
> marked as resolved?
> > > > > >
> > > > > > Let's get some more data, shouldn't take long time.
> > > > > > >
> > > > > > > Do you have Kaby Lake devices sitting around for testing?
> > > > > >
> > > > > > We will of course try to reproduce the issue locally.
> > > > >
> > > > > Paul, currently we cannot reproduce this issue on Kaby Lake
> > > > > platforms on our side,
> > > >
> > > > It looks like it’s a different issue. Reverting the two commits
> > > > touching `bus-fixup.c`, did not help.
> > > >
> > > > > we would be great for more debug data from your side.
> > > > > You can get more info by enabling  mode debug logs
> > > > >
> > > > > echo -n 'module mei +lfp' >
> > > > > /sys/kernel/debug/dynamic_debug/control
> > > > > echo -n 'module mei_me +lfp' >
> > > > > /sys/kernel/debug/dynamic_debug/control
> > > >
> > > > I am currently bisecting to find the culprit. 13 steps will take
> > > > some time though.
> > >
> > > I can duplicate this on my laptop here as well :(
> >
> > Which system do you have?
> 
> A Dell XPS13, don't know what cpu type it is, here's the output of one cpu from
> /proc/cpuinfo
> 
> processor	: 3
> vendor_id	: GenuineIntel
> cpu family	: 6
> model		: 78
> model name	: Intel(R) Core(TM) i7-6560U CPU @ 2.20GHz
> stepping	: 3
> microcode	: 0x8a
> cpu MHz		: 712.207
> cache size	: 4096 KB
> physical id	: 0
> siblings	: 4
> core id		: 1
> cpu cores	: 2
> apicid		: 3
> initial apicid	: 3
> fpu		: yes
> fpu_exception	: yes
> cpuid level	: 22
> wp		: yes
> flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
> pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl
> xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
> ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic
> movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm
> 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase
> tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt
> xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify
> hwp_act_window hwp_epp
> bugs		:
> bogomips	: 4419.34
> clflush size	: 64
> cache_alignment	: 64
> address sizes	: 39 bits physical, 48 bits virtual
> power management:
> 
> > > Did you get anywhere with your bisection?
> >
> > Sorry, I replied to a different message with my status.
> >
> > Please see my status below. I’ll have access to the machine on Monday
> again.
> >
> > ```
> > $ git bisect log
> > git bisect start
> > # good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9 git
> > bisect good 69973b830859bc6529a7a0468ba0d80ee5117826
> > # good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9 git
> > bisect good 69973b830859bc6529a7a0468ba0d80ee5117826
> > # bad: [a121103c922847ba5010819a3f250f1f7fc84ab8] Linux 4.10-⁠rc3 git
> > bisect bad a121103c922847ba5010819a3f250f1f7fc84ab8
> > # bad: [72cca7baf4fba777b8ab770b902cf2e08941773f] Merge tag
> > 'staging-4.10-rc1' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
> > git bisect bad 72cca7baf4fba777b8ab770b902cf2e08941773f
> > # good: [b8d2798f32785398fcd1c48ea80c0c6c5ab88537] Merge tag 'clk-for-
> linus'
> > of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
> > git bisect good b8d2798f32785398fcd1c48ea80c0c6c5ab88537
> > # good: [9439b3710df688d853eb6cb4851256f2c92b1797] Merge tag 'drm-
> for-v4.10'
> > of git://people.freedesktop.org/~airlied/linux
> > git bisect good 9439b3710df688d853eb6cb4851256f2c92b1797
> > ```
> >
> 
> You are close!  I'll try bisection tomorrow if I have some spare time.
> 
> thanks,

Greg,  is that same Laptop mode as Paul's, you've experience the issue on?
Thanks
Tomas

[toc] | [prev] | [next] | [standalone]

#1559200 — Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

On Sun, Jan 15, 2017 at 07:19:03AM +0000, Winkler, Tomas wrote:
> > Subject: Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT
> > and newer
> > 
> > On Sat, Jan 14, 2017 at 08:27:31PM +0100, Paul Menzel wrote:
> > > Dear Greg,
> > >
> > >
> > > On 2017-01-13 14:00, Greg Kroah-Hartman wrote:
> > > > On Wed, Jan 11, 2017 at 03:26:06PM +0100, Paul Menzel wrote:
> > >
> > > > > On 01/11/17 15:12, Winkler, Tomas wrote:
> > > > >
> > > > > > > > On 01/11/17 10:24, Winkler, Tomas wrote:
> > > > > > > > > >
> > > > > > > > > > On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler
> > wrote:
> > > > > > > > > > > On older platforms the command should be just ignored
> > > > > > > > > > > by the firmware but some older platforms misbehave so
> > > > > > > > > > > it's safer to send the command only if required.
> > > > > > > > > >
> > > > > > > > > > Thanks! This fixes suspend-to-ram for me (on a Thinkpad x201s).
> > > > > > > > >
> > > > > > > > > What about Dell XPS13?
> > > > > > > >
> > > > > > > > With Linus' master branch from today, and Greg's
> > > > > > > > char-misc-linus merged
> > > > > > > > (Merge: 807b93e995d1 546cf3ef9c92), the regression is still there.
> > > > > > >
> > > > > > > Hmm, this should work on KBL....
> > > > > > >
> > > > > > > > I am now building a Linux kernel image with the two commits
> > > > > > > > touching
> > > > > > > > `bus- fixup.c` reverted.
> > > > > > >
> > > > > > > Thanks for the effort.
> > > > > > >
> > > > > > > > Do you want me to open a separate bug report for that, or
> > > > > > > > continue debugging in the existing report [1], which is currently
> > marked as resolved?
> > > > > > >
> > > > > > > Let's get some more data, shouldn't take long time.
> > > > > > > >
> > > > > > > > Do you have Kaby Lake devices sitting around for testing?
> > > > > > >
> > > > > > > We will of course try to reproduce the issue locally.
> > > > > >
> > > > > > Paul, currently we cannot reproduce this issue on Kaby Lake
> > > > > > platforms on our side,
> > > > >
> > > > > It looks like it’s a different issue. Reverting the two commits
> > > > > touching `bus-fixup.c`, did not help.
> > > > >
> > > > > > we would be great for more debug data from your side.
> > > > > > You can get more info by enabling  mode debug logs
> > > > > >
> > > > > > echo -n 'module mei +lfp' >
> > > > > > /sys/kernel/debug/dynamic_debug/control
> > > > > > echo -n 'module mei_me +lfp' >
> > > > > > /sys/kernel/debug/dynamic_debug/control
> > > > >
> > > > > I am currently bisecting to find the culprit. 13 steps will take
> > > > > some time though.
> > > >
> > > > I can duplicate this on my laptop here as well :(
> > >
> > > Which system do you have?
> > 
> > A Dell XPS13, don't know what cpu type it is, here's the output of one cpu from
> > /proc/cpuinfo
> > 
> > processor	: 3
> > vendor_id	: GenuineIntel
> > cpu family	: 6
> > model		: 78
> > model name	: Intel(R) Core(TM) i7-6560U CPU @ 2.20GHz
> > stepping	: 3
> > microcode	: 0x8a
> > cpu MHz		: 712.207
> > cache size	: 4096 KB
> > physical id	: 0
> > siblings	: 4
> > core id		: 1
> > cpu cores	: 2
> > apicid		: 3
> > initial apicid	: 3
> > fpu		: yes
> > fpu_exception	: yes
> > cpuid level	: 22
> > wp		: yes
> > flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
> > pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl
> > xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
> > ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic
> > movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm
> > 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase
> > tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt
> > xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify
> > hwp_act_window hwp_epp
> > bugs		:
> > bogomips	: 4419.34
> > clflush size	: 64
> > cache_alignment	: 64
> > address sizes	: 39 bits physical, 48 bits virtual
> > power management:
> > 
> > > > Did you get anywhere with your bisection?
> > >
> > > Sorry, I replied to a different message with my status.
> > >
> > > Please see my status below. I’ll have access to the machine on Monday
> > again.
> > >
> > > ```
> > > $ git bisect log
> > > git bisect start
> > > # good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9 git
> > > bisect good 69973b830859bc6529a7a0468ba0d80ee5117826
> > > # good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9 git
> > > bisect good 69973b830859bc6529a7a0468ba0d80ee5117826
> > > # bad: [a121103c922847ba5010819a3f250f1f7fc84ab8] Linux 4.10-⁠rc3 git
> > > bisect bad a121103c922847ba5010819a3f250f1f7fc84ab8
> > > # bad: [72cca7baf4fba777b8ab770b902cf2e08941773f] Merge tag
> > > 'staging-4.10-rc1' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
> > > git bisect bad 72cca7baf4fba777b8ab770b902cf2e08941773f
> > > # good: [b8d2798f32785398fcd1c48ea80c0c6c5ab88537] Merge tag 'clk-for-
> > linus'
> > > of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
> > > git bisect good b8d2798f32785398fcd1c48ea80c0c6c5ab88537
> > > # good: [9439b3710df688d853eb6cb4851256f2c92b1797] Merge tag 'drm-
> > for-v4.10'
> > > of git://people.freedesktop.org/~airlied/linux
> > > git bisect good 9439b3710df688d853eb6cb4851256f2c92b1797
> > > ```
> > >
> > 
> > You are close!  I'll try bisection tomorrow if I have some spare time.
> > 
> > thanks,
> 
> Greg,  is that same Laptop mode as Paul's, you've experience the issue on?

It's the same model name, but as this model has been shipped with many
different CPU versions over the years, I'm not sure if it is the exact
same one.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1559639 — Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

On Sun, Jan 15, 2017 at 11:58:30AM +0100, Greg Kroah-Hartman wrote:
> On Sun, Jan 15, 2017 at 07:19:03AM +0000, Winkler, Tomas wrote:
> > > Subject: Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT
> > > and newer
> > > 
> > > On Sat, Jan 14, 2017 at 08:27:31PM +0100, Paul Menzel wrote:
> > > > Dear Greg,
> > > >
> > > >
> > > > On 2017-01-13 14:00, Greg Kroah-Hartman wrote:
> > > > > On Wed, Jan 11, 2017 at 03:26:06PM +0100, Paul Menzel wrote:
> > > >
> > > > > > On 01/11/17 15:12, Winkler, Tomas wrote:
> > > > > >
> > > > > > > > > On 01/11/17 10:24, Winkler, Tomas wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler
> > > wrote:
> > > > > > > > > > > > On older platforms the command should be just ignored
> > > > > > > > > > > > by the firmware but some older platforms misbehave so
> > > > > > > > > > > > it's safer to send the command only if required.
> > > > > > > > > > >
> > > > > > > > > > > Thanks! This fixes suspend-to-ram for me (on a Thinkpad x201s).
> > > > > > > > > >
> > > > > > > > > > What about Dell XPS13?
> > > > > > > > >
> > > > > > > > > With Linus' master branch from today, and Greg's
> > > > > > > > > char-misc-linus merged
> > > > > > > > > (Merge: 807b93e995d1 546cf3ef9c92), the regression is still there.
> > > > > > > >
> > > > > > > > Hmm, this should work on KBL....
> > > > > > > >
> > > > > > > > > I am now building a Linux kernel image with the two commits
> > > > > > > > > touching
> > > > > > > > > `bus- fixup.c` reverted.
> > > > > > > >
> > > > > > > > Thanks for the effort.
> > > > > > > >
> > > > > > > > > Do you want me to open a separate bug report for that, or
> > > > > > > > > continue debugging in the existing report [1], which is currently
> > > marked as resolved?
> > > > > > > >
> > > > > > > > Let's get some more data, shouldn't take long time.
> > > > > > > > >
> > > > > > > > > Do you have Kaby Lake devices sitting around for testing?
> > > > > > > >
> > > > > > > > We will of course try to reproduce the issue locally.
> > > > > > >
> > > > > > > Paul, currently we cannot reproduce this issue on Kaby Lake
> > > > > > > platforms on our side,
> > > > > >
> > > > > > It looks like it’s a different issue. Reverting the two commits
> > > > > > touching `bus-fixup.c`, did not help.
> > > > > >
> > > > > > > we would be great for more debug data from your side.
> > > > > > > You can get more info by enabling  mode debug logs
> > > > > > >
> > > > > > > echo -n 'module mei +lfp' >
> > > > > > > /sys/kernel/debug/dynamic_debug/control
> > > > > > > echo -n 'module mei_me +lfp' >
> > > > > > > /sys/kernel/debug/dynamic_debug/control
> > > > > >
> > > > > > I am currently bisecting to find the culprit. 13 steps will take
> > > > > > some time though.
> > > > >
> > > > > I can duplicate this on my laptop here as well :(
> > > >
> > > > Which system do you have?
> > > 
> > > A Dell XPS13, don't know what cpu type it is, here's the output of one cpu from
> > > /proc/cpuinfo
> > > 
> > > processor	: 3
> > > vendor_id	: GenuineIntel
> > > cpu family	: 6
> > > model		: 78
> > > model name	: Intel(R) Core(TM) i7-6560U CPU @ 2.20GHz
> > > stepping	: 3
> > > microcode	: 0x8a
> > > cpu MHz		: 712.207
> > > cache size	: 4096 KB
> > > physical id	: 0
> > > siblings	: 4
> > > core id		: 1
> > > cpu cores	: 2
> > > apicid		: 3
> > > initial apicid	: 3
> > > fpu		: yes
> > > fpu_exception	: yes
> > > cpuid level	: 22
> > > wp		: yes
> > > flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> > > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
> > > pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl
> > > xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
> > > ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic
> > > movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm
> > > 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase
> > > tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt
> > > xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify
> > > hwp_act_window hwp_epp
> > > bugs		:
> > > bogomips	: 4419.34
> > > clflush size	: 64
> > > cache_alignment	: 64
> > > address sizes	: 39 bits physical, 48 bits virtual
> > > power management:
> > > 
> > > > > Did you get anywhere with your bisection?
> > > >
> > > > Sorry, I replied to a different message with my status.
> > > >
> > > > Please see my status below. I’ll have access to the machine on Monday
> > > again.
> > > >
> > > > ```
> > > > $ git bisect log
> > > > git bisect start
> > > > # good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9 git
> > > > bisect good 69973b830859bc6529a7a0468ba0d80ee5117826
> > > > # good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9 git
> > > > bisect good 69973b830859bc6529a7a0468ba0d80ee5117826
> > > > # bad: [a121103c922847ba5010819a3f250f1f7fc84ab8] Linux 4.10-⁠rc3 git
> > > > bisect bad a121103c922847ba5010819a3f250f1f7fc84ab8
> > > > # bad: [72cca7baf4fba777b8ab770b902cf2e08941773f] Merge tag
> > > > 'staging-4.10-rc1' of
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
> > > > git bisect bad 72cca7baf4fba777b8ab770b902cf2e08941773f
> > > > # good: [b8d2798f32785398fcd1c48ea80c0c6c5ab88537] Merge tag 'clk-for-
> > > linus'
> > > > of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
> > > > git bisect good b8d2798f32785398fcd1c48ea80c0c6c5ab88537
> > > > # good: [9439b3710df688d853eb6cb4851256f2c92b1797] Merge tag 'drm-
> > > for-v4.10'
> > > > of git://people.freedesktop.org/~airlied/linux
> > > > git bisect good 9439b3710df688d853eb6cb4851256f2c92b1797
> > > > ```
> > > >
> > > 
> > > You are close!  I'll try bisection tomorrow if I have some spare time.
> > > 
> > > thanks,
> > 
> > Greg,  is that same Laptop mode as Paul's, you've experience the issue on?
> 
> It's the same model name, but as this model has been shipped with many
> different CPU versions over the years, I'm not sure if it is the exact
> same one.

Ok, 4.10-rc4 seems to have fixed this issue with me.  I don't know what
it was, but I can't duplicate it anymore.

Paul, are you still having this issue?

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1560348 — Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer

Greg Kroah-Hartman wrote on 16.01.2017 12:05:
> On Sun, Jan 15, 2017 at 11:58:30AM +0100, Greg Kroah-Hartman wrote:
>> On Sun, Jan 15, 2017 at 07:19:03AM +0000, Winkler, Tomas wrote:
>> > > Subject: Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT
>> > > and newer
>> > > On Sat, Jan 14, 2017 at 08:27:31PM +0100, Paul Menzel wrote:
>> > > > On 2017-01-13 14:00, Greg Kroah-Hartman wrote:
>> > > > > On Wed, Jan 11, 2017 at 03:26:06PM +0100, Paul Menzel wrote:
>> > > > > > On 01/11/17 15:12, Winkler, Tomas wrote:
>> > > > > > > > > On 01/11/17 10:24, Winkler, Tomas wrote:
>> > > > > > > > > > > On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler
>> > > wrote:
>> > > > > > > > > > > > On older platforms the command should be just ignored
>> > > > > > > > > > > > by the firmware but some older platforms misbehave so
>> > > > > > > > > > > > it's safer to send the command only if required.
>> > > > > > > > > > > Thanks! This fixes suspend-to-ram for me (on a Thinkpad x201s).
>> > > > > > > > > > What about Dell XPS13?
>> > > > > > > > > With Linus' master branch from today, and Greg's
>> > > > > > > > > char-misc-linus merged
>> > > > > > > > > (Merge: 807b93e995d1 546cf3ef9c92), the regression is still there.
> […]
>> > > > > > I am currently bisecting to find the culprit. 13 steps will take
>> > > > > > some time though.
>> > > > > I can duplicate this on my laptop here as well :(
>> > > > Which system do you have?
>> > > A Dell XPS13, don't know what cpu type it is, here's the output of one cpu from
>> > > /proc/cpuinfo
> […]
>> > > model name	: Intel(R) Core(TM) i7-6560U CPU @ 2.20GHz
>> > > > > Did you get anywhere with your bisection?
>> > > > Sorry, I replied to a different message with my status.
> > > You are close!  I'll try bisection tomorrow if I have some spare time.

Paul, did you get any closer? I have trouble finding time for a proper
bisection (it's a bit chaotic here right now :-/ )

>> > Greg,  is that same Laptop mode as Paul's, you've experience the issue on?
>> It's the same model name, but as this model has been shipped with many
>> different CPU versions over the years, I'm not sure if it is the exact
>> same one.

Gregs afaics is Skylake generation (XPS 13 (9350)), Paul and I have a
Kaby Lake (XPS 13 (9360)), which is one generation newer (Wifi is also
different; other components likely as well).

> Ok, 4.10-rc4 seems to have fixed this issue with me.  I don't know what
> it was, but I can't duplicate it anymore.

Good to hear.

> Paul, are you still having this issue?

Don't know about Paul, but I did a quick test with rc4 on my machine and
the issue is still there :-/

Ciao, Thorsten

[toc] | [prev] | [next] | [standalone]

#1560820 — RE: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer)

Hi Paul,

Thanks for raising this topic and including me.  
Suspend to Idle support in Linux as an alternative S3 on x86 is a new 
topic.  In all, I expected that some problems would arise as a result 
of this patch, and I hope they will spur interesting discussions and 
solutions.

Something that might not be immediately obvious is that by supporting
suspend to idle, new driver bugs are going to be identified for drivers
that don't properly put hardware into low enough power modes for the CPU
to go into the proper state.  Traditionally with S3 the BIOS would be responsible 
for powering devices down before S3 and back up when exiting S3.
This onus is now on the OS.

> -----Original Message-----
> From: Paul Menzel [mailto:pmenzel@molgen.mpg.de]
> Sent: Tuesday, January 17, 2017 8:34 AM
> To: Rafael J. Wysocki <rafael.j.wysocki@intel.com>; Limonciello, Mario
> <Mario_Limonciello@Dell.com>
> Cc: Thorsten Leemhuis <linux@leemhuis.info>; Greg Kroah-Hartman
> <gregkh@linuxfoundation.org>; Tomas Winkler <tomas.winkler@intel.com>;
> Jan Niehusmann <jan@gondor.com>; Usyskin, Alexander
> <alexander.usyskin@intel.com>; linux-kernel@vger.kernel.org; Chen, Yu C
> <yu.c.chen@intel.com>; Sarvela, Tomi P <tomi.p.sarvela@intel.com>; Daniel
> Blueman <daniel@quora.org>; Len Brown <len.brown@intel.com>; linux-
> pm@vger.kernel.org
> Subject: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei: bus:
> enable OS version only for SPT and newer)
> 
> Dear Rafael, dear Mario,
> 
> 
> On 01/17/17 09:14, Thorsten Leemhuis wrote:
> > Greg Kroah-Hartman wrote on 16.01.2017 12:05:
> >> On Sun, Jan 15, 2017 at 11:58:30AM +0100, Greg Kroah-Hartman wrote:
> >>> On Sun, Jan 15, 2017 at 07:19:03AM +0000, Winkler, Tomas wrote:
> >>>>> Subject: Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS
> >>>>> version only for SPT and newer On Sat, Jan 14, 2017 at 08:27:31PM
> >>>>> +0100, Paul Menzel wrote:
> >>>>>> On 2017-01-13 14:00, Greg Kroah-Hartman wrote:
> >>>>>>> On Wed, Jan 11, 2017 at 03:26:06PM +0100, Paul Menzel wrote:
> >>>>>>>> On 01/11/17 15:12, Winkler, Tomas wrote:
> >>>>>>>>>>> On 01/11/17 10:24, Winkler, Tomas wrote:
> >>>>>>>>>>>>> On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler
> wrote:
> >>>>>>>>>>>>>> On older platforms the command should be just ignored
> by
> >>>>>>>>>>>>>> the firmware but some older platforms misbehave so it's
> >>>>>>>>>>>>>> safer to send the command only if required.
> >>>>>>>>>>>>> Thanks! This fixes suspend-to-ram for me (on a Thinkpad
> x201s).
> >>>>>>>>>>>> What about Dell XPS13?
> 
> There is a regression with Linux 4.10-rc{1,2,3} on the Intel Kaby Lake device
> Dell XPS13 (9360). Hitting the power button, the light of the power button
> never goes off. Pressing it again, nothing happen. Only pressing it like ten
> seconds the screen comes back for five seconds, and then it seems to try to
> suspend again.


When it's in suspend to idle, the EC will modify some behaviors that align
to vendor specifications.  These include both the power button and 
the power light.  Both are actually expected, but the power button is 
indicative of other problems in the stack that need work.  
Let me explain how it all works:

When in suspend to idle, if the power button is pressed only momentarily (~ <6s),
the EC sends a wakeup event to the firmware which sends it to the OS 
through an ACPI event to the Intel HID event filter driver (intel-hid).

If it's pressed for longer (~6-9 seconds) then an IRQ is triggered to wake up 
the system the traditional way through a power button press.

If the button is pressed for a very long time (~10+ seconds) then 
the system will be force powered off.

So in the <6s scenario, the intel-hid driver is responsible to receive the ACPI
event and process accordingly.  The maintainer has a patch ready for the intel-hid
portion of this work, but it's currently being reviewed by Intel to ensure it
can be legally submitted into the kernel.

After that patch is approved for disclosure, submitted and accepted, the other 
missing part is that the ACPI subsystem itself is frozen when in suspend to idle, 
so this event can't be received by intel-hid.  This part needs discussion on how to fix.

In the 6-9s scenario there are no problems as this is the traditional wakeup
(as you found).

> 
> >>>>>>>>>>> With Linus' master branch from today, and Greg's
> >>>>>>>>>>> char-misc-linus merged
> >>>>>>>>>>> (Merge: 807b93e995d1 546cf3ef9c92), the regression is still
> there.
> >> […]
> >>>>>>>> I am currently bisecting to find the culprit. 13 steps will
> >>>>>>>> take some time though.
> >>>>>>> I can duplicate this on my laptop here as well :(
> >>>>>> Which system do you have?
> >>>>> A Dell XPS13, don't know what cpu type it is, here's the output of
> >>>>> one cpu from /proc/cpuinfo
> >> […]
> >>>>> model name	: Intel(R) Core(TM) i7-6560U CPU @ 2.20GHz
> >>>>>>> Did you get anywhere with your bisection?
> >>>>>> Sorry, I replied to a different message with my status.
> >>>> You are close!  I'll try bisection tomorrow if I have some spare time.
> >
> > Paul, did you get any closer? I have trouble finding time for a proper
> > bisection (it's a bit chaotic here right now :-/ )
> >
> >>>> Greg,  is that same Laptop mode as Paul's, you've experience the issue
> on?
> >>> It's the same model name, but as this model has been shipped with
> >>> many different CPU versions over the years, I'm not sure if it is
> >>> the exact same one.
> >
> > Gregs afaics is Skylake generation (XPS 13 (9350)), Paul and I have a
> > Kaby Lake (XPS 13 (9360)), which is one generation newer (Wifi is also
> > different; other components likely as well).
> >
> >> Ok, 4.10-rc4 seems to have fixed this issue with me.  I don't know
> >> what it was, but I can't duplicate it anymore.
> >
> > Good to hear.
> >
> >> Paul, are you still having this issue?
> >
> > Don't know about Paul, but I did a quick test with rc4 on my machine
> > and the issue is still there :-/
> 
> I didn’t test Linux 4.10-rc4 yet, but I completed the bisection.
> 
> ```
> 406e79385f3223d82272cf2be86bc95cd000a258 is the first bad commit commit
> 406e79385f3223d82272cf2be86bc95cd000a258
> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Date:   Mon Nov 21 22:45:40 2016 +0100
> 
>      PM / sleep: System sleep state selection interface rework
> 
>      There are systems in which the platform doesn't support any special
>      sleep states, so suspend-to-idle (PM_SUSPEND_FREEZE) is the only
>      available system sleep state.  However, some user space frameworks
>      only use the "mem" and (sometimes) "standby" sleep state labels, so
>      the users of those systems need to modify user space in order to be
>      able to use system suspend at all and that may be a pain in practice.
> 
>      Commit 0399d4db3edf (PM / sleep: Introduce command line argument for
>      sleep state enumeration) attempted to address this problem by adding
>      a command line argument to change the meaning of the "mem" string in
>      /sys/power/state to make it trigger suspend-to-idle (instead of
>      suspend-to-RAM).
> 
>      However, there also are systems in which the platform does support
>      special sleep states, but suspend-to-idle is the preferred one anyway
>      (it even may save more energy than the platform-provided sleep states
>      in some cases) and the above commit doesn't help in those cases.
> 
>      For this reason, rework the system sleep state selection interface
>      again (but preserve backwards compatibiliby).  Namely, add a new
>      sysfs file, /sys/power/mem_sleep, that will control the system
>      suspend mode triggered by writing "mem" to /sys/power/state (in
>      analogy with what /sys/power/disk does for hibernation).  Make it
>      select suspend-to-RAM ("deep" sleep) by default (if supported) and
>      fall back to suspend-to-idle ("s2idle") otherwise and add a new
>      command line argument, mem_sleep_default, allowing that default to
>      be overridden if need be.
> 
>      At the same time, drop the relative_sleep_states command line
>      argument that doesn't make sense any more.
> 
>      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>      Tested-by: Mario Limonciello <mario.limonciello@dell.com>
> 
> :040000 040000 a5770fe0413cbe7794eab28f72dfe8ede1f090c2
> a2882c77659517aa7137c930e0e7f178bc76bfbd M      Documentation
> :040000 040000 2594b1a87815173e97199ef9d9c5918fec22fcfd
> fe0b69953be653644c5366ac631131fdbbdb9bcc M      kernel
> $ git tag --contains 406e79385f3223d82272cf2be86bc95cd000a258
> v4.10-rc1
> v4.10-rc2
> v4.10-rc3
> ```
> 
> Please find the config and the bisection log attached. Sometimes I had to
> cherry-pick build fix commits for PIE enabled GCC on top.
> 
> Rafael, do you want me to open a bug report for that? Mario, what systems
> did you actually test this on? (Why isn’t that listed in the commit message?)
> Mario, do you have access to Dell XPS13 (9360) devices to help getting this
> fixed?
> 

I tested this on several systems and ensured that the kernel was doing the
right thing in terms of choosing the correct state to go into.

As I mentioned above, those behaviors are currently expected until these
types issues are identified and fixed in the proper subsystems.  If they
end up being troublesome to resolve, it's possible to quirk individual systems,
to disable this behavior and return to traditional S3 but I would prefer to actually 
identify and fix the various problems so that we can push the Linux stack forward.

[toc] | [prev] | [next] | [standalone]

#1560905 — Re: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer)

On Tue, Jan 17, 2017 at 04:57:49PM +0000, Mario.Limonciello@dell.com wrote:
> So in the <6s scenario, the intel-hid driver is responsible to receive the ACPI
> event and process accordingly.  The maintainer has a patch ready for the intel-hid
> portion of this work, but it's currently being reviewed by Intel to ensure it
> can be legally submitted into the kernel.

Who at Intel do I need to go kick to make this mythical legal review
happen faster so we can see the code?

Len and Rafael, what is going on here?

> > 406e79385f3223d82272cf2be86bc95cd000a258 is the first bad commit commit
> > 406e79385f3223d82272cf2be86bc95cd000a258
> > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Date:   Mon Nov 21 22:45:40 2016 +0100
> > 
> >      PM / sleep: System sleep state selection interface rework
> > 
> >      There are systems in which the platform doesn't support any special
> >      sleep states, so suspend-to-idle (PM_SUSPEND_FREEZE) is the only
> >      available system sleep state.  However, some user space frameworks
> >      only use the "mem" and (sometimes) "standby" sleep state labels, so
> >      the users of those systems need to modify user space in order to be
> >      able to use system suspend at all and that may be a pain in practice.
> > 
> >      Commit 0399d4db3edf (PM / sleep: Introduce command line argument for
> >      sleep state enumeration) attempted to address this problem by adding
> >      a command line argument to change the meaning of the "mem" string in
> >      /sys/power/state to make it trigger suspend-to-idle (instead of
> >      suspend-to-RAM).
> > 
> >      However, there also are systems in which the platform does support
> >      special sleep states, but suspend-to-idle is the preferred one anyway
> >      (it even may save more energy than the platform-provided sleep states
> >      in some cases) and the above commit doesn't help in those cases.
> > 
> >      For this reason, rework the system sleep state selection interface
> >      again (but preserve backwards compatibiliby).  Namely, add a new
> >      sysfs file, /sys/power/mem_sleep, that will control the system
> >      suspend mode triggered by writing "mem" to /sys/power/state (in
> >      analogy with what /sys/power/disk does for hibernation).  Make it
> >      select suspend-to-RAM ("deep" sleep) by default (if supported) and
> >      fall back to suspend-to-idle ("s2idle") otherwise and add a new
> >      command line argument, mem_sleep_default, allowing that default to
> >      be overridden if need be.
> > 
> >      At the same time, drop the relative_sleep_states command line
> >      argument that doesn't make sense any more.
> > 
> >      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >      Tested-by: Mario Limonciello <mario.limonciello@dell.com>
> > 
> > :040000 040000 a5770fe0413cbe7794eab28f72dfe8ede1f090c2
> > a2882c77659517aa7137c930e0e7f178bc76bfbd M      Documentation
> > :040000 040000 2594b1a87815173e97199ef9d9c5918fec22fcfd
> > fe0b69953be653644c5366ac631131fdbbdb9bcc M      kernel
> > $ git tag --contains 406e79385f3223d82272cf2be86bc95cd000a258
> > v4.10-rc1
> > v4.10-rc2
> > v4.10-rc3
> > ```
> > 
> > Please find the config and the bisection log attached. Sometimes I had to
> > cherry-pick build fix commits for PIE enabled GCC on top.
> > 
> > Rafael, do you want me to open a bug report for that? Mario, what systems
> > did you actually test this on? (Why isn’t that listed in the commit message?)
> > Mario, do you have access to Dell XPS13 (9360) devices to help getting this
> > fixed?
> > 
> 
> I tested this on several systems and ensured that the kernel was doing the
> right thing in terms of choosing the correct state to go into.
> 
> As I mentioned above, those behaviors are currently expected until these
> types issues are identified and fixed in the proper subsystems.  If they
> end up being troublesome to resolve, it's possible to quirk individual systems,
> to disable this behavior and return to traditional S3 but I would prefer to actually 
> identify and fix the various problems so that we can push the Linux stack forward.

If the machine stops working on a newer kernel when it used to work
before, then you need to either revert the change, or provide a fix for
it.

I think I might have access to a newer Dell XPS13 now, I'll try to set
it up tomorrow to test 4.10-rc4 out...

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1560935 — RE: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer)

> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Tuesday, January 17, 2017 12:24 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: pmenzel@molgen.mpg.de; rafael.j.wysocki@intel.com;
> linux@leemhuis.info; tomas.winkler@intel.com; jan@gondor.com;
> alexander.usyskin@intel.com; linux-kernel@vger.kernel.org;
> yu.c.chen@intel.com; tomi.p.sarvela@intel.com; daniel@quora.org;
> len.brown@intel.com; linux-pm@vger.kernel.org
> Subject: Re: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:
> bus: enable OS version only for SPT and newer)
> 
> On Tue, Jan 17, 2017 at 04:57:49PM +0000, Mario.Limonciello@dell.com
> wrote:
> > So in the <6s scenario, the intel-hid driver is responsible to receive
> > the ACPI event and process accordingly.  The maintainer has a patch
> > ready for the intel-hid portion of this work, but it's currently being
> > reviewed by Intel to ensure it can be legally submitted into the kernel.
> 
> Who at Intel do I need to go kick to make this mythical legal review happen
> faster so we can see the code?
> 
> Len and Rafael, what is going on here?
>

Len and Darren are both in the loop on the discussion around this patch.
I don't know if they'll have any (public) comments they can add on the matter
yet however.

We haven't broached the topic of the ACPI subsystem being frozen with Rafael
as it doesn't affect helping this problem until the intel-hid patch is added.

Rafael, since this is in process now, what are your thoughts?

> > > 406e79385f3223d82272cf2be86bc95cd000a258 is the first bad commit
> > > commit
> > > 406e79385f3223d82272cf2be86bc95cd000a258
> > > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > Date:   Mon Nov 21 22:45:40 2016 +0100
> > >
> > >      PM / sleep: System sleep state selection interface rework
> > >
> > >      There are systems in which the platform doesn't support any special
> > >      sleep states, so suspend-to-idle (PM_SUSPEND_FREEZE) is the only
> > >      available system sleep state.  However, some user space frameworks
> > >      only use the "mem" and (sometimes) "standby" sleep state labels, so
> > >      the users of those systems need to modify user space in order to be
> > >      able to use system suspend at all and that may be a pain in practice.
> > >
> > >      Commit 0399d4db3edf (PM / sleep: Introduce command line argument
> for
> > >      sleep state enumeration) attempted to address this problem by adding
> > >      a command line argument to change the meaning of the "mem" string
> in
> > >      /sys/power/state to make it trigger suspend-to-idle (instead of
> > >      suspend-to-RAM).
> > >
> > >      However, there also are systems in which the platform does support
> > >      special sleep states, but suspend-to-idle is the preferred one anyway
> > >      (it even may save more energy than the platform-provided sleep
> states
> > >      in some cases) and the above commit doesn't help in those cases.
> > >
> > >      For this reason, rework the system sleep state selection interface
> > >      again (but preserve backwards compatibiliby).  Namely, add a new
> > >      sysfs file, /sys/power/mem_sleep, that will control the system
> > >      suspend mode triggered by writing "mem" to /sys/power/state (in
> > >      analogy with what /sys/power/disk does for hibernation).  Make it
> > >      select suspend-to-RAM ("deep" sleep) by default (if supported) and
> > >      fall back to suspend-to-idle ("s2idle") otherwise and add a new
> > >      command line argument, mem_sleep_default, allowing that default to
> > >      be overridden if need be.
> > >
> > >      At the same time, drop the relative_sleep_states command line
> > >      argument that doesn't make sense any more.
> > >
> > >      Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > >      Tested-by: Mario Limonciello <mario.limonciello@dell.com>
> > >
> > > :040000 040000 a5770fe0413cbe7794eab28f72dfe8ede1f090c2
> > > a2882c77659517aa7137c930e0e7f178bc76bfbd M      Documentation
> > > :040000 040000 2594b1a87815173e97199ef9d9c5918fec22fcfd
> > > fe0b69953be653644c5366ac631131fdbbdb9bcc M      kernel
> > > $ git tag --contains 406e79385f3223d82272cf2be86bc95cd000a258
> > > v4.10-rc1
> > > v4.10-rc2
> > > v4.10-rc3
> > > ```
> > >
> > > Please find the config and the bisection log attached. Sometimes I
> > > had to cherry-pick build fix commits for PIE enabled GCC on top.
> > >
> > > Rafael, do you want me to open a bug report for that? Mario, what
> > > systems did you actually test this on? (Why isn’t that listed in the
> > > commit message?) Mario, do you have access to Dell XPS13 (9360)
> > > devices to help getting this fixed?
> > >
> >
> > I tested this on several systems and ensured that the kernel was doing
> > the right thing in terms of choosing the correct state to go into.
> >
> > As I mentioned above, those behaviors are currently expected until
> > these types issues are identified and fixed in the proper subsystems.
> > If they end up being troublesome to resolve, it's possible to quirk
> > individual systems, to disable this behavior and return to traditional
> > S3 but I would prefer to actually identify and fix the various problems so
> that we can push the Linux stack forward.
> 
> If the machine stops working on a newer kernel when it used to work
> before, then you need to either revert the change, or provide a fix for it.
> 

So in my mind there isn't exactly a clear cut definition of "stops working", 
particularly when it's an intentional change in behavior.

If the desire is to go back to S3 on this system, I'm happy to submit a patch
that will quirk this back to S3 on this system until we can get ACPI to not
freeze and Intel-HID to pick up the event it needs.

> I think I might have access to a newer Dell XPS13 now, I'll try to set it up
> tomorrow to test 4.10-rc4 out...
> 

If you don't, please contact me privately and I'm happy to try to help get
you access to one.

[toc] | [prev] | [next] | [standalone]

#1561120 — Re: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer)

On Tue, Jan 17, 2017 at 06:38:43PM +0000, Mario.Limonciello@dell.com wrote:
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Sent: Tuesday, January 17, 2017 12:24 PM
> > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > Cc: pmenzel@molgen.mpg.de; rafael.j.wysocki@intel.com;
> > linux@leemhuis.info; tomas.winkler@intel.com; jan@gondor.com;
> > alexander.usyskin@intel.com; linux-kernel@vger.kernel.org;
> > yu.c.chen@intel.com; tomi.p.sarvela@intel.com; daniel@quora.org;
> > len.brown@intel.com; linux-pm@vger.kernel.org
> > Subject: Re: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:
> > bus: enable OS version only for SPT and newer)
> > 
> > On Tue, Jan 17, 2017 at 04:57:49PM +0000, Mario.Limonciello@dell.com
> > wrote:
> > > So in the <6s scenario, the intel-hid driver is responsible to receive
> > > the ACPI event and process accordingly.  The maintainer has a patch
> > > ready for the intel-hid portion of this work, but it's currently being
> > > reviewed by Intel to ensure it can be legally submitted into the kernel.
> > 
> > Who at Intel do I need to go kick to make this mythical legal review happen
> > faster so we can see the code?
> > 
> > Len and Rafael, what is going on here?
> >
> 
> Len and Darren are both in the loop on the discussion around this patch.
> I don't know if they'll have any (public) comments they can add on the matter
> yet however.

Thanks Mario. Yes, there isn't much to say here in public other than to confirm
we are keenly aware of the problem and have been actively working on fixing it,
both for this instance, and the deeper systematic failure that resulted in this
situation. No amount of kicking will expedite the process at this point, but
should we feel the need, we'll reach out.

-- 
Darren Hart
Intel Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1563988 — RE: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer)

Greg,

> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Tuesday, January 17, 2017 5:34 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> Cc: gregkh@linuxfoundation.org; rafael.j.wysocki@intel.com;
> pmenzel@molgen.mpg.de; linux@leemhuis.info; tomas.winkler@intel.com;
> jan@gondor.com; alexander.usyskin@intel.com; linux-kernel@vger.kernel.org;
> yu.c.chen@intel.com; tomi.p.sarvela@intel.com; daniel@quora.org;
> len.brown@intel.com; linux-pm@vger.kernel.org
> Subject: Re: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:
> bus: enable OS version only for SPT and newer)
> 
> On Tue, Jan 17, 2017 at 06:38:43PM +0000, Mario.Limonciello@dell.com
> wrote:
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > Sent: Tuesday, January 17, 2017 12:24 PM
> > > To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> > > Cc: pmenzel@molgen.mpg.de; rafael.j.wysocki@intel.com;
> > > linux@leemhuis.info; tomas.winkler@intel.com; jan@gondor.com;
> > > alexander.usyskin@intel.com; linux-kernel@vger.kernel.org;
> > > yu.c.chen@intel.com; tomi.p.sarvela@intel.com; daniel@quora.org;
> > > len.brown@intel.com; linux-pm@vger.kernel.org
> > > Subject: Re: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:
> > > bus: enable OS version only for SPT and newer)
> > >
> > > On Tue, Jan 17, 2017 at 04:57:49PM +0000, Mario.Limonciello@dell.com
> > > wrote:
> > > > So in the <6s scenario, the intel-hid driver is responsible to
> > > > receive the ACPI event and process accordingly.  The maintainer
> > > > has a patch ready for the intel-hid portion of this work, but it's
> > > > currently being reviewed by Intel to ensure it can be legally submitted
> into the kernel.
> > >
> > > Who at Intel do I need to go kick to make this mythical legal review
> > > happen faster so we can see the code?
> > >
> > > Len and Rafael, what is going on here?
> > >
> >
> > Len and Darren are both in the loop on the discussion around this patch.
> > I don't know if they'll have any (public) comments they can add on the
> > matter yet however.
> 
> Thanks Mario. Yes, there isn't much to say here in public other than to confirm
> we are keenly aware of the problem and have been actively working on fixing
> it, both for this instance, and the deeper systematic failure that resulted in this
> situation. No amount of kicking will expedite the process at this point, but
> should we feel the need, we'll reach out.
> 

The approval has come through and the patch has been submitted.
http://www.spinics.net/lists/platform-driver-x86/msg10286.html

Note: this is only half of the fix, the second half needs the ACPI subsystem to
not be frozen to be able to receive this event.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web