linux-kernel - Re: [PATCH 6/6] i3c: master: svc: fix random hot join failure since timeout error

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]

Date:   Tue, 17 Oct 2023 11:25:37 -0400
From:   Frank Li <Frank.li@....com>
To:     Miquel Raynal <miquel.raynal@...tlin.com>
Cc:     conor.culhane@...vaco.com, alexandre.belloni@...tlin.com,
        joe@...ches.com, linux-i3c@...ts.infradead.org,
        linux-kernel@...r.kernel.org, imx@...ts.linux.dev
Subject: Re: [PATCH 6/6] i3c: master: svc: fix random hot join failure since
 timeout error

On Tue, Oct 17, 2023 at 05:06:03PM +0200, Miquel Raynal wrote:
> Hi Frank,
> 
> Frank.li@....com wrote on Tue, 17 Oct 2023 10:45:14 -0400:
> 
> > On Tue, Oct 17, 2023 at 04:33:35PM +0200, Miquel Raynal wrote:
> > > Hi Frank,
> > > 
> > > Frank.Li@....com wrote on Mon, 16 Oct 2023 11:32:32 -0400:
> > >   
> > > > master side report:
> > > >   silvaco-i3c-master 44330000.i3c-master: Error condition: MSTATUS 0x020090c7, MERRWARN 0x00100000
> > > > 
> > > > BIT 20: TIMEOUT error
> > > >   The module has stalled too long in a frame. This happens when:
> > > >   - The TX FIFO or RX FIFO is not handled and the bus is stuck in the
> > > > middle of a message,
> > > >   - No STOP was issued and between messages,
> > > >   - IBI manual is used and no decision was made.
> > > >   The maximum stall period is 10 KHz or 100 μs.
> > > > 
> > > > This is a just warning. System irq thread schedule latency is possible  
> > > 
> > > 							can be bigger  
> > > > bigger than 100us. Just omit this waring.  
> > > 
> > > I'm not sure this is the correct approach. It's a real issue but there
> > > is not much we can do about it. Perhaps dev_err is too high, but I
> > > would not entirely drop this message. Maybe a comment and turning the
> > > message into a dbg printk would be more appropriate?  
> > 
> > The key is not message. It return true, means IBI/HJ thread will not run.
> 
> But why should the workers run if it's too late?

IBI ACK already sent, target think master already accepted IBI. then master
driver check TIMEOUT, 

If without run IBI thread, target's driver will wait target sent IBI. And
target wait for driver handle IBI. 

So the whole system may lock or wait for long time out.

Hardware check TIMEOUT and software send ACK is totally async.

> 
> Thanks,
> Miquèl