subject:"\[Kernel\-packages\] \[Bug 1484587\] Re\: CPU frequency management fails to re\-engage on resume from suspend"

[Kernel-packages] [Bug 1484587] Re: CPU frequency management fails to re-engage on resume from suspend

2016-02-26 Thread Adam Colligan

I have not noticed this problem on later kernels; I'm going to mark it
as "fix released" for Linux and "invalid" for pm-utils. I hope that's
the right course of action.

** Changed in: linux (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: pm-utils (Ubuntu)
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1484587

Title:
  CPU frequency management fails to re-engage on resume from suspend

Status in linux package in Ubuntu:
  Fix Released
Status in pm-utils package in Ubuntu:
  Invalid

Bug description:
  Behavior:

  CPU frequency management fails to re-engage on resume from suspend. On
  resume, the CPUs are stuck around a single frequency (usually a low
  idle frequency).

  I use indicator-cpufreq for manual governor control. On resume,
  indicator-cpufreq indicates the low frequency state in its live cpu
  performance display in the icon. However, in its governor menu, it
  still shows as in use whichever governor was selected before suspend,
  even though that governor is not actually or properly controlling the
  CPU state.

  Upon manually switching to the unused governor in indicator-cpufreq,
  this behavior resolves, and the newly-chosen governor begins
  performing its duties. I can then immediately switch back to the
  desired (pre-suspend) governor with no issues.

  PM logs appear to show a successful resume of cpu frequency
  management, even though the modules did not actually gain effective
  control of the processor frequencies.

  
  Expected behavior:

  On resume, the CPU frequencies should continue being managed as they
  were before suspend without the need for manual user input.  Also, in
  the event that they do not, an error/warning should appear -- if not
  to the user, then in the pm suspend/resume logs.

  
  Other information that may or may not be relevant:

  On this system, the "powersave" governor is always automatically
  chosen at startup, although not until a minute or so after session
  login. The choice of an alternate governor "performance" from
  indicator-cpufreq is not persistent across reboots. Further, if I
  manually toggle the governors at the beginning of my first session
  after boot, and I settle on "performance", some automated script will
  force it back to "powersave" at the usual time about a minute after
  login. To use the "performance" governor, I must select it after
  waiting an interval following login, and I must always switch to
  powersave and back to performance after each resume from suspend.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: linux-image-3.19.0-25-generic 3.19.0-25.26
  ProcVersionSignature: Ubuntu 3.19.0-25.26-generic 3.19.8-ckt2
  Uname: Linux 3.19.0-25-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1.2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  adam   3887 F pulseaudio
   /dev/snd/controlC1:  adam   3887 F pulseaudio
  CurrentDesktop: Unity
  Date: Thu Aug 13 11:41:27 2015
  InstallationDate: Installed on 2014-08-10 (368 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  MachineType: Hewlett-Packard HP ENVY 15 x360 PC
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-25-generic.efi.signed 
root=UUID=5ad8035a-f2a4-4334-84d8-e2a8a7396bf8 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-3.19.0-25-generic N/A
   linux-backports-modules-3.19.0-25-generic  N/A
   linux-firmware 1.143.3
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/19/2015
  dmi.bios.vendor: Insyde
  dmi.bios.version: F.26
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: 22D6
  dmi.board.vendor: Hewlett-Packard
  dmi.board.version: 89.23
  dmi.chassis.type: 10
  dmi.chassis.vendor: Hewlett-Packard
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnInsyde:bvrF.26:bd01/19/2015:svnHewlett-Packard:pnHPENVY15x360PC:pvr0974100022405F0420180:rvnHewlett-Packard:rn22D6:rvr89.23:cvnHewlett-Packard:ct10:cvrChassisVersion:
  dmi.product.name: HP ENVY 15 x360 PC
  dmi.product.version: 0974100022405F0420180
  dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1484587/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1484587] Re: CPU frequency management fails to re-engage on resume from suspend

2015-09-06 Thread Doug Smythies

When a user is using the intel_pstate driver in performance mode, then
yes, prior to Kernel 4.2RC1 the CPU frequency will be typically be stuck
after resume from suspend.

This is not a pm-ultils issue (which is how I stumbled across this bug
report).

To test that the issue is fixed on kernel 4.2, just use primitive
commands and not these higher level utilities (that I neither use or
know anything about). For example use:

grep MHz /proc/cpuinfo

to observe CPU frequencies.

The commit that, I think, fixes this issue is:

commit 6c1e45917dec5e7c99ba8125fd8cc50f6e482a21
Author: Doug Smythies 
Date:   Mon Jun 1 21:12:34 2015 -0700

intel_pstate: Force setting target pstate when required

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1484587

Title:
  CPU frequency management fails to re-engage on resume from suspend

Status in linux package in Ubuntu:
  Confirmed
Status in pm-utils package in Ubuntu:
  Confirmed

Bug description:
  Behavior:

  CPU frequency management fails to re-engage on resume from suspend. On
  resume, the CPUs are stuck around a single frequency (usually a low
  idle frequency).

  I use indicator-cpufreq for manual governor control. On resume,
  indicator-cpufreq indicates the low frequency state in its live cpu
  performance display in the icon. However, in its governor menu, it
  still shows as in use whichever governor was selected before suspend,
  even though that governor is not actually or properly controlling the
  CPU state.

  Upon manually switching to the unused governor in indicator-cpufreq,
  this behavior resolves, and the newly-chosen governor begins
  performing its duties. I can then immediately switch back to the
  desired (pre-suspend) governor with no issues.

  PM logs appear to show a successful resume of cpu frequency
  management, even though the modules did not actually gain effective
  control of the processor frequencies.

  
  Expected behavior:

  On resume, the CPU frequencies should continue being managed as they
  were before suspend without the need for manual user input.  Also, in
  the event that they do not, an error/warning should appear -- if not
  to the user, then in the pm suspend/resume logs.

  
  Other information that may or may not be relevant:

  On this system, the "powersave" governor is always automatically
  chosen at startup, although not until a minute or so after session
  login. The choice of an alternate governor "performance" from
  indicator-cpufreq is not persistent across reboots. Further, if I
  manually toggle the governors at the beginning of my first session
  after boot, and I settle on "performance", some automated script will
  force it back to "powersave" at the usual time about a minute after
  login. To use the "performance" governor, I must select it after
  waiting an interval following login, and I must always switch to
  powersave and back to performance after each resume from suspend.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: linux-image-3.19.0-25-generic 3.19.0-25.26
  ProcVersionSignature: Ubuntu 3.19.0-25.26-generic 3.19.8-ckt2
  Uname: Linux 3.19.0-25-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1.2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  adam   3887 F pulseaudio
   /dev/snd/controlC1:  adam   3887 F pulseaudio
  CurrentDesktop: Unity
  Date: Thu Aug 13 11:41:27 2015
  InstallationDate: Installed on 2014-08-10 (368 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  MachineType: Hewlett-Packard HP ENVY 15 x360 PC
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-25-generic.efi.signed 
root=UUID=5ad8035a-f2a4-4334-84d8-e2a8a7396bf8 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-3.19.0-25-generic N/A
   linux-backports-modules-3.19.0-25-generic  N/A
   linux-firmware 1.143.3
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/19/2015
  dmi.bios.vendor: Insyde
  dmi.bios.version: F.26
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: 22D6
  dmi.board.vendor: Hewlett-Packard
  dmi.board.version: 89.23
  dmi.chassis.type: 10
  dmi.chassis.vendor: Hewlett-Packard
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnInsyde:bvrF.26:bd01/19/2015:svnHewlett-Packard:pnHPENVY15x360PC:pvr0974100022405F0420180:rvnHewlett-Packard:rn22D6:rvr89.23:cvnHewlett-Packard:ct10:cvrChassisVersion:
  dmi.product.name: HP ENVY 15 x360 PC
  dmi.product.version: 0974100022405F0420180
  dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1484587/+subscriptions

-- 
Mailing list:

[Kernel-packages] [Bug 1484587] Re: CPU frequency management fails to re-engage on resume from suspend

2015-08-13 Thread Adam Colligan

I have tried to recreate this with the following two mainline kernels:

v4.2-rc6-unstable
v4.2.0-999 (201508130157)

However, it is somewhat difficult to compare the behavior apples-to-
apples the way I normally do, as cpupower is not available for those
kernels (no linux-tools packages installed for them).  I would
appreciate any advice on the best way to show the problem's
presence/absence in an objective or definitive way across kernels.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1484587

Title:
  CPU frequency management fails to re-engage on resume from suspend

Status in linux package in Ubuntu:
  Confirmed
Status in pm-utils package in Ubuntu:
  New

Bug description:
  Behavior:

  CPU frequency management fails to re-engage on resume from suspend. On
  resume, the CPUs are stuck around a single frequency (usually a low
  idle frequency).

  I use indicator-cpufreq for manual governor control. On resume,
  indicator-cpufreq indicates the low frequency state in its live cpu
  performance display in the icon. However, in its governor menu, it
  still shows as in use whichever governor was selected before suspend,
  even though that governor is not actually or properly controlling the
  CPU state.

  Upon manually switching to the unused governor in indicator-cpufreq,
  this behavior resolves, and the newly-chosen governor begins
  performing its duties. I can then immediately switch back to the
  desired (pre-suspend) governor with no issues.

  PM logs appear to show a successful resume of cpu frequency
  management, even though the modules did not actually gain effective
  control of the processor frequencies.

  
  Expected behavior:

  On resume, the CPU frequencies should continue being managed as they
  were before suspend without the need for manual user input.  Also, in
  the event that they do not, an error/warning should appear -- if not
  to the user, then in the pm suspend/resume logs.

  
  Other information that may or may not be relevant:

  On this system, the powersave governor is always automatically
  chosen at startup, although not until a minute or so after session
  login. The choice of an alternate governor performance from
  indicator-cpufreq is not persistent across reboots. Further, if I
  manually toggle the governors at the beginning of my first session
  after boot, and I settle on performance, some automated script will
  force it back to powersave at the usual time about a minute after
  login. To use the performance governor, I must select it after
  waiting an interval following login, and I must always switch to
  powersave and back to performance after each resume from suspend.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: linux-image-3.19.0-25-generic 3.19.0-25.26
  ProcVersionSignature: Ubuntu 3.19.0-25.26-generic 3.19.8-ckt2
  Uname: Linux 3.19.0-25-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1.2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  adam   3887 F pulseaudio
   /dev/snd/controlC1:  adam   3887 F pulseaudio
  CurrentDesktop: Unity
  Date: Thu Aug 13 11:41:27 2015
  InstallationDate: Installed on 2014-08-10 (368 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS Trusty Tahr - Release amd64 
(20140722.2)
  MachineType: Hewlett-Packard HP ENVY 15 x360 PC
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-25-generic.efi.signed 
root=UUID=5ad8035a-f2a4-4334-84d8-e2a8a7396bf8 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-3.19.0-25-generic N/A
   linux-backports-modules-3.19.0-25-generic  N/A
   linux-firmware 1.143.3
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/19/2015
  dmi.bios.vendor: Insyde
  dmi.bios.version: F.26
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: 22D6
  dmi.board.vendor: Hewlett-Packard
  dmi.board.version: 89.23
  dmi.chassis.type: 10
  dmi.chassis.vendor: Hewlett-Packard
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnInsyde:bvrF.26:bd01/19/2015:svnHewlett-Packard:pnHPENVY15x360PC:pvr0974100022405F0420180:rvnHewlett-Packard:rn22D6:rvr89.23:cvnHewlett-Packard:ct10:cvrChassisVersion:
  dmi.product.name: HP ENVY 15 x360 PC
  dmi.product.version: 0974100022405F0420180
  dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1484587/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1484587] Re: CPU frequency management fails to re-engage on resume from suspend

2015-08-13 Thread Alberto Salvia Novella

** Changed in: pm-utils (Ubuntu)
   Status: New = Confirmed

** Changed in: linux (Ubuntu)
   Importance: Undecided = High

** Changed in: pm-utils (Ubuntu)
   Importance: Undecided = High

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1484587

Title:
  CPU frequency management fails to re-engage on resume from suspend

Status in linux package in Ubuntu:
  Confirmed
Status in pm-utils package in Ubuntu:
  Confirmed

Bug description:
  Behavior:

  CPU frequency management fails to re-engage on resume from suspend. On
  resume, the CPUs are stuck around a single frequency (usually a low
  idle frequency).

  I use indicator-cpufreq for manual governor control. On resume,
  indicator-cpufreq indicates the low frequency state in its live cpu
  performance display in the icon. However, in its governor menu, it
  still shows as in use whichever governor was selected before suspend,
  even though that governor is not actually or properly controlling the
  CPU state.

  Upon manually switching to the unused governor in indicator-cpufreq,
  this behavior resolves, and the newly-chosen governor begins
  performing its duties. I can then immediately switch back to the
  desired (pre-suspend) governor with no issues.

  PM logs appear to show a successful resume of cpu frequency
  management, even though the modules did not actually gain effective
  control of the processor frequencies.

  
  Expected behavior:

  On resume, the CPU frequencies should continue being managed as they
  were before suspend without the need for manual user input.  Also, in
  the event that they do not, an error/warning should appear -- if not
  to the user, then in the pm suspend/resume logs.

  
  Other information that may or may not be relevant:

  On this system, the powersave governor is always automatically
  chosen at startup, although not until a minute or so after session
  login. The choice of an alternate governor performance from
  indicator-cpufreq is not persistent across reboots. Further, if I
  manually toggle the governors at the beginning of my first session
  after boot, and I settle on performance, some automated script will
  force it back to powersave at the usual time about a minute after
  login. To use the performance governor, I must select it after
  waiting an interval following login, and I must always switch to
  powersave and back to performance after each resume from suspend.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: linux-image-3.19.0-25-generic 3.19.0-25.26
  ProcVersionSignature: Ubuntu 3.19.0-25.26-generic 3.19.8-ckt2
  Uname: Linux 3.19.0-25-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1.2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  adam   3887 F pulseaudio
   /dev/snd/controlC1:  adam   3887 F pulseaudio
  CurrentDesktop: Unity
  Date: Thu Aug 13 11:41:27 2015
  InstallationDate: Installed on 2014-08-10 (368 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS Trusty Tahr - Release amd64 
(20140722.2)
  MachineType: Hewlett-Packard HP ENVY 15 x360 PC
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-25-generic.efi.signed 
root=UUID=5ad8035a-f2a4-4334-84d8-e2a8a7396bf8 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-3.19.0-25-generic N/A
   linux-backports-modules-3.19.0-25-generic  N/A
   linux-firmware 1.143.3
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/19/2015
  dmi.bios.vendor: Insyde
  dmi.bios.version: F.26
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: 22D6
  dmi.board.vendor: Hewlett-Packard
  dmi.board.version: 89.23
  dmi.chassis.type: 10
  dmi.chassis.vendor: Hewlett-Packard
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnInsyde:bvrF.26:bd01/19/2015:svnHewlett-Packard:pnHPENVY15x360PC:pvr0974100022405F0420180:rvnHewlett-Packard:rn22D6:rvr89.23:cvnHewlett-Packard:ct10:cvrChassisVersion:
  dmi.product.name: HP ENVY 15 x360 PC
  dmi.product.version: 0974100022405F0420180
  dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1484587/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1484587] Re: CPU frequency management fails to re-engage on resume from suspend

2015-08-13 Thread Adam Colligan

** Attachment added: kern.log from session in which cpu freq control failed on 
resume from suspend
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1484587/+attachment/227/+files/kern_log_cpu_resume_bug.txt

** Also affects: pm-utils (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1484587

Title:
  CPU frequency management fails to re-engage on resume from suspend

Status in linux package in Ubuntu:
  Confirmed
Status in pm-utils package in Ubuntu:
  New

Bug description:
  Behavior:

  CPU frequency management fails to re-engage on resume from suspend. On
  resume, the CPUs are stuck around a single frequency (usually a low
  idle frequency).

  I use indicator-cpufreq for manual governor control. On resume,
  indicator-cpufreq indicates the low frequency state in its live cpu
  performance display in the icon. However, in its governor menu, it
  still shows as in use whichever governor was selected before suspend,
  even though that governor is not actually or properly controlling the
  CPU state.

  Upon manually switching to the unused governor in indicator-cpufreq,
  this behavior resolves, and the newly-chosen governor begins
  performing its duties. I can then immediately switch back to the
  desired (pre-suspend) governor with no issues.

  PM logs appear to show a successful resume of cpu frequency
  management, even though the modules did not actually gain effective
  control of the processor frequencies.

  
  Expected behavior:

  On resume, the CPU frequencies should continue being managed as they
  were before suspend without the need for manual user input.  Also, in
  the event that they do not, an error/warning should appear -- if not
  to the user, then in the pm suspend/resume logs.

  
  Other information that may or may not be relevant:

  On this system, the powersave governor is always automatically
  chosen at startup, although not until a minute or so after session
  login. The choice of an alternate governor performance from
  indicator-cpufreq is not persistent across reboots. Further, if I
  manually toggle the governors at the beginning of my first session
  after boot, and I settle on performance, some automated script will
  force it back to powersave at the usual time about a minute after
  login. To use the performance governor, I must select it after
  waiting an interval following login, and I must always switch to
  powersave and back to performance after each resume from suspend.

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: linux-image-3.19.0-25-generic 3.19.0-25.26
  ProcVersionSignature: Ubuntu 3.19.0-25.26-generic 3.19.8-ckt2
  Uname: Linux 3.19.0-25-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1.2
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  adam   3887 F pulseaudio
   /dev/snd/controlC1:  adam   3887 F pulseaudio
  CurrentDesktop: Unity
  Date: Thu Aug 13 11:41:27 2015
  InstallationDate: Installed on 2014-08-10 (368 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS Trusty Tahr - Release amd64 
(20140722.2)
  MachineType: Hewlett-Packard HP ENVY 15 x360 PC
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-25-generic.efi.signed 
root=UUID=5ad8035a-f2a4-4334-84d8-e2a8a7396bf8 ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-3.19.0-25-generic N/A
   linux-backports-modules-3.19.0-25-generic  N/A
   linux-firmware 1.143.3
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 01/19/2015
  dmi.bios.vendor: Insyde
  dmi.bios.version: F.26
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: 22D6
  dmi.board.vendor: Hewlett-Packard
  dmi.board.version: 89.23
  dmi.chassis.type: 10
  dmi.chassis.vendor: Hewlett-Packard
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnInsyde:bvrF.26:bd01/19/2015:svnHewlett-Packard:pnHPENVY15x360PC:pvr0974100022405F0420180:rvnHewlett-Packard:rn22D6:rvr89.23:cvnHewlett-Packard:ct10:cvrChassisVersion:
  dmi.product.name: HP ENVY 15 x360 PC
  dmi.product.version: 0974100022405F0420180
  dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1484587/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1484587] Re: CPU frequency management fails to re-engage on resume from suspend

[Kernel-packages] [Bug 1484587] Re: CPU frequency management fails to re-engage on resume from suspend

[Kernel-packages] [Bug 1484587] Re: CPU frequency management fails to re-engage on resume from suspend

[Kernel-packages] [Bug 1484587] Re: CPU frequency management fails to re-engage on resume from suspend

[Kernel-packages] [Bug 1484587] Re: CPU frequency management fails to re-engage on resume from suspend

5 matches

Site Navigation

Mail list logo

Footer information