Bug#945055: marked as done (linux: CPU runs at considerably higher temperatures)

2020-03-14 Thread Debian Bug Tracking System 
Your message dated Sun, 15 Mar 2020 05:58:00 +0100
with message-id <4824251cc563e97e7642310adcd09bfe61f7e91c.ca...@scientia.net>
and subject line linux: CPU runs at considerably higher temperatures
has caused the Debian Bug report #945055,
regarding linux: CPU runs at considerably higher temperatures
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
945055: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945055
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: intel-microcode
Version: 3.20191115.1
Severity: important


Hi.

With the most recent upgrade, the CPU seems to run at considerably
higher temperatures.


Shortly after a fresh boot, but long enough so that everything has
started up, and the system being basically idle it looks like this:

microcode updated early to revision 0xca, date = 2019-09-26

iwlwifi-virtual-0
Adapter: Virtual device
temp1:N/A  

coretemp-isa-
Adapter: ISA adapter
Package id 0:  +58.0°C  (high = +100.0°C, crit = +100.0°C)
Core 0:+57.0°C  (high = +100.0°C, crit = +100.0°C)
Core 1:+57.0°C  (high = +100.0°C, crit = +100.0°C)

CMB1-acpi-0
Adapter: ACPI interface
in0:  16.60 V  
curr1: 0.00 A  




And with the same kernel but older microcode:

microcode updated early to revision 0xc6, date = 2019-08-14

iwlwifi-virtual-0
Adapter: Virtual device
temp1:N/A  

coretemp-isa-
Adapter: ISA adapter
Package id 0:  +55.0°C  (high = +100.0°C, crit = +100.0°C)
Core 0:+53.0°C  (high = +100.0°C, crit = +100.0°C)
Core 1:+54.0°C  (high = +100.0°C, crit = +100.0°C)

CMB1-acpi-0
Adapter: ACPI interface
in0:  16.60 V  
curr1: 0.00 A  



top shows basically no CPU utilisation (in both cases) but the fan
goes up and the CPU is constantly notacibly hot, which both wasn't
the case previously when the system was idle.




Now another strange thing:
With the NEW microcode, once some load was put on the system, even when
this is gone and the CPU back to basically no utilisation, the temperatures
are at a *much* higher level and stay there, for whichever reason:

iwlwifi-virtual-0
Adapter: Virtual device
temp1:+34.0°C  

coretemp-isa-
Adapter: ISA adapter
Package id 0:  +76.0°C  (high = +100.0°C, crit = +100.0°C)
Core 0:+70.0°C  (high = +100.0°C, crit = +100.0°C)
Core 1:+69.0°C  (high = +100.0°C, crit = +100.0°C)

CMB1-acpi-0
Adapter: ACPI interface
in0:  16.59 V  
curr1: 0.00 A  



Is this a problem with the microcode or a kinda expected side-effect
of the security workarounds?



Cheers,
Chris.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages intel-microcode depends on:
ii  iucode-tool  2.3.1-1

Versions of packages intel-microcode recommends:
ii  initramfs-tools  0.135

intel-microcode suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Control: tags -1 + wontfix

Guess that issue can be closed as wontfix.
Despite a patch being available for nearly two months no in an issue
that causes complete breakage of affected systems, there seems to be no
intentions to pick it up or release a recent enough kernel which would
contain it already.

Upstream's apparently also unwilling to submit this to -stable kernels
so yeah... people affected to it should probably switch hardware or OS.


Cheers,
Chris.--- End Message ---

Bug#939170: linux: does not suspend completely, locks up

2020-03-14 Thread Daniel M. 
On Sun, 26 Jan 2020 18:03:23 +0100 Felix Rublack  wrote:
> Hi everyone,
>
> I have the same issue on a ThinkPad T460s (suspend works only half way,
> reboot and poweroff stop just short before actual shutdown).
>
> I bisected the problem to the TPM driver. Blacklisting the module in
> modprobe.d fixed the problem for me.
>
> Sample configuration: /etc/modprobe.d/blacklist-tpm.conf
>
> # Prevent TPM from loading. It breaks suspend and power cycle.
> blacklist tpm
> blacklist tpm_crb
> blacklist tpm_tis
> blacklist tpm_tis_core
>
> Greetings
> Felix Rublack

Hi, thanks a lot! I can confirm that this works also on my Thinkpad
E460. Since you can probably provide more details, could you forward
this to kernel.org?

Cheers,
Daniel

Re: Dropping haveged from the installer

2020-03-14 Thread Cyril Brulebois 
Hey,

Ben Hutchings  (2019-11-09):
> > Ben Hutchings  (2019-11-07):
> > > Linux 5.4 introduces an in-kernel jitter-entropy implementation
> > > for systems without a usable hardware RNG, which should remove the
> > > need for haveged.
> > > 
> > > We could possibly cherry-pick that change on to 5.3, to avoid the
> > > need for further changes to haveged packaging.
> > 
> > Oh, great.
> > 
> > Feel free to either follow-up on this bug report once you have
> > backported it to 5.3, or alternatively once 5.4 trunk has reached
> > experimental, so that the switch away from haveged can be tested.
> 
> This is included in 5.3.9-1, which is currently building.

I know it's been available for a while, but merging this right before
D-I Bullseye Alpha 2 feels a little wrong.

Anyway, to get the ball rolling, I've performed some tests to see how it
would go. I've tried dropping haveged-udeb from pkg-lists and that seems
to be working fine: there are no obvious delays with either the
all-HTTPS scenario or the encrypted LVM one. I'm seeing the “random:
crng init done” message after 23 or 52 seconds respectively, likely when
the first entropy-needing operations are happening. Can you confirm this
is the expected behaviour?

Next, I might try disabling the fc-cache trick at build time to see if
the kernel-level mechanism makes that a moot point as well (I would
assume it does, but I'd like to double check: this is happening rather
early in the boot sequence).

  
https://debamax.com/blog/2018/05/25/debugging-black-screen-in-debian-installer/
  
https://salsa.debian.org/installer-team/debian-installer/commit/59e1a9af0ce29da7afb55aecce6d54094c3f214f


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature