Re: qcom-rng is broken for acpi

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/16/2024 1:40 PM, Brian Masney wrote:
On Mon, Sep 16, 2024 at 1:42 PM Jeffrey Hugo <quic_jhugo@xxxxxxxxxxx> wrote:
Bisect pointed to the following which makes zero sense -
[snip]
I wonder if bisect-ability got broken somehow.

I'm going to try to do a bit of a manual bisect to see if I can avoid
whatever glitch (possibly self induced) I seem to have hit.

I've seen this happen if the error is due to a race condition and only
happens part of the time. When you are testing a kernel, try booting
the system up to 3 times before you run 'git bisect good' against a
particular iteration.

Found some issues with my initial bisect effort.

New run points to:

commit 1b0e3ea9301a422003d385cda8f8dee6c878ad05
Author: Yicong Yang <yangyicong@xxxxxxxxxxxxx>
Date:   Mon Aug 14 21:16:42 2023 +0800

    perf/smmuv3: Add MODULE_ALIAS for module auto loading

    On my ACPI based arm64 server, if the SMMUv3 PMU is configured as
    module it won't be loaded automatically after booting even if the
    device has already been scanned and added. It's because the module
    lacks a platform alias, the uevent mechanism and userspace tools
    like udevd make use of this to find the target driver module of the
    device. This patch adds the missing platform alias of the module,
    then module will be loaded automatically if device exists.

    Before this patch:
    [root@localhost tmp]# modinfo arm_smmuv3_pmu | grep alias
    alias:          of:N*T*Carm,smmu-v3-pmcgC*
    alias:          of:N*T*Carm,smmu-v3-pmcg

    After this patch:
    [root@localhost tmp]# modinfo arm_smmuv3_pmu | grep alias
    alias:          platform:arm-smmu-v3-pmcg
    alias:          of:N*T*Carm,smmu-v3-pmcgC*
    alias:          of:N*T*Carm,smmu-v3-pmcg

    Signed-off-by: Yicong Yang <yangyicong@xxxxxxxxxxxxx>
Link: https://lore.kernel.org/r/20230814131642.65263-1-yangyicong@xxxxxxxxxx
    Signed-off-by: Will Deacon <will@xxxxxxxxxx>

 drivers/perf/arm_smmuv3_pmu.c | 1 +
 1 file changed, 1 insertion(+)


This one seems to make a bit more sense, and reverting it does make the prints go away. Feels like either the driver is getting triggered earlier, or wasn't getting triggered before at all.

I plan to come back to this later in the week to dig more.

-Jeff




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux