linux-kernel - Re: Boot failure on gru-scarlet-inx with 5.9-rc2

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <65d88bdd0888a69849327501a2aad186@kernel.org>
Date:   Sun, 30 Aug 2020 10:41:42 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Samuel Dionne-Riel <samuel@...nne-riel.com>
Cc:     devicetree@...r.kernel.org, Frank Rowand <frowand.list@...il.com>,
        Rob Herring <robh+dt@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: Boot failure on gru-scarlet-inx with 5.9-rc2

Hi Samuel,

On 2020-08-29 21:54, Samuel Dionne-Riel wrote:
> Hi,
> 
> The patch "of: address: Work around missing device_type property in
> pcie nodes" by Marc Zyngier, d1ac0002dd297069bb8448c2764c9c31c4668441,
> causes the "DUMO" variant of the gru-scarlet-inx, at the very least,
> to not boot. A gru-kevin reportedly had no issues booting (further),
> though it most likely had a different kernel configuration.

Do you have a pointer to the device-tree for this system? I couldn't
spot anything amiss in the scarlet-inx DT, but I'm not sure the
system you have is that exact one. Even a DTB would help.

The fact that Kevin still boots is a good indication that the issue
could be with with the board-specific changes layered on top of the
GRU base. My own rk3399 systems are running with this patch.

> Using a SuzyQ cable, there is absolutely no serial output at boot,
> while reverting the commit (and this commit alone) on top of v5.9-rc2
> works just as it did with v5.9-rc1.

Do you have "earlycon" on the kernel command-line?

> From this point on, I don't know what's the usual process, so bear with
> me if I forgot to provide relevant information, or made a faux-pas by
> CC-ing too many people or not enough.

No need to worry, and thank you for reporting the issue.

Could you try replacing the problematic patch with [1], and let me
know whether this changes anything on your end? This patch probably
isn't the right approach, but it would certainly help pointing me
in the right direction.

Thanks,

         M.

[1] https://lore.kernel.org/lkml/20200815125112.462652-2-maz@kernel.org/
-- 
Jazz is not dead. It just smells funny...