linux-kernel - Re: Errant readings on LM81 with T2080 SoC

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: <d5045879-45aa-db38-e6aa-4c8ea3e62f6c@roeck-us.net>
Date:   Tue, 9 Mar 2021 21:06:46 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Chris Packham <Chris.Packham@...iedtelesis.co.nz>,
        "jdelvare@...e.com" <jdelvare@...e.com>
Cc:     "linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: Errant readings on LM81 with T2080 SoC

On 3/9/21 6:19 PM, Chris Packham wrote:
> On 9/03/21 9:27 am, Chris Packham wrote:
>> On 8/03/21 5:59 pm, Guenter Roeck wrote:
>>> Other than that, the only other real idea I have would be to monitor
>>> the i2c bus.
>> I am in the fortunate position of being able to go into the office and 
>> even happen to have the expensive scope at the moment. Now I just need 
>> to find a tame HW engineer so I don't burn myself trying to attach the 
>> probes.
> One thing I see on the scope is that when there is a CPU load there 
> appears to be some clock stretching going on (SCL is held low some 
> times). I don't see it without the CPU load. It's hard to correlate a 
> clock stretching event with a bad read or error but it is one area where 
> the SMBUS spec has a maximum that might cause the device to give up waiting.
> 
Do you have CONFIG_PREEMPT enabled in your kernel ? But even without
that it is possible that the hot loops at the beginning and end of
each operation mess up the driver and cause it to sleep longer
than intended. Did you try usleep_range() ?

On a side note, can you send me a register dump for the lm81 ?
It would be useful for my module test code.

Thanks,
Guenter