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: <ZS6ncZeNaen13s1b@lizhi-Precision-Tower-5810>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ