linux-kernel - Re: [PATCHv4] drm/amdgpu: disable ASPM on Intel Alder Lake based systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5a530210-2c22-d8e6-02e0-f321ba5e0e60@molgen.mpg.de>
Date:   Tue, 3 May 2022 14:44:56 +0200
From:   Paul Menzel <pmenzel@...gen.mpg.de>
To:     Daniel Stone <daniel@...ishbar.org>
Cc:     Dave Airlie <airlied@...ux.ie>,
        Richard Gong <richard.gong@....com>,
        Xinhui Pan <xinhui.pan@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
        Alexander Deucher <alexander.deucher@....com>,
        Christian König <christian.koenig@....com>,
        Mario Limonciello <mario.limonciello@....com>
Subject: Re: [PATCHv4] drm/amdgpu: disable ASPM on Intel Alder Lake based
 systems

Dear Daniel,


Am 03.05.22 um 14:25 schrieb Daniel Stone:
> On Sun, 1 May 2022 at 08:08, Paul Menzel <pmenzel@...gen.mpg.de> wrote:
>> Am 26.04.22 um 15:53 schrieb Gong, Richard:
>>> I think so. We captured dmesg log.
>>
>> Then the (whole) system did *not* freeze, if you could still log in
>> (maybe over network) and execute `dmesg`. Please also paste the
>> amdgpu(?) error logs in the commit message.
>>
>>> As mentioned early we need support from Intel on how to get ASPM working
>>> for VI generation on Intel Alder Lake, but we don't know where things
>>> currently stand.
>>
>> Who is working on this, and knows?
> 
> This has gone beyond the point of a reasonable request. The amount of
> detail you're demanding is completely unnecessary.

If a quirk is introduced possibly leading to higher power consumption, 
especially on systems nobody has access to yet, then the detail, where 
the system hangs/freezes is not unreasonable at all.

In the Linux logs from the issue there are messages like

     [   58.101385] Freezing of tasks failed after 20.003 seconds (4 
tasks refusing to freeze, wq_busy=0):

     [   78.278403] Freezing of tasks failed after 20.008 seconds (4 
tasks refusing to freeze, wq_busy=0):

and it looks like several suspend/resume cycles were done.

I see a lot of commit messages over the whole Linux kernel, where this 
level of detail is provided (by default), and

The second question was not for the commit message, but just for 
documentation purpose when the problem is going to be fixed properly. 
And it looks like (at least publicly) analyzing the root cause is not 
happening, and once the quirk lands, nobody is going to feel the 
pressure to work on it, as everyone’s plates are full.


Kind regards,

Paul