On Fri, Oct 25, 2019 at 04:06:22PM -0700, Matt Roper wrote:
> We're seeing some failures where an aux transaction still shows as
> 'busy' well after the timeout limit that the hardware is supposed to
> enforce. Improve the error message so that we can see exactly which aux
> channel this error hap
On Fri, Oct 25, 2019 at 04:25:47PM -0700, Matt Roper wrote:
On Fri, Oct 25, 2019 at 04:19:33PM -0700, Lucas De Marchi wrote:
On Fri, Oct 25, 2019 at 04:06:22PM -0700, Matt Roper wrote:
> We're seeing some failures where an aux transaction still shows as
> 'busy' well after the timeout limit that
On Fri, Oct 25, 2019 at 04:19:33PM -0700, Lucas De Marchi wrote:
> On Fri, Oct 25, 2019 at 04:06:22PM -0700, Matt Roper wrote:
> > We're seeing some failures where an aux transaction still shows as
> > 'busy' well after the timeout limit that the hardware is supposed to
> > enforce. Improve the er
On Fri, Oct 25, 2019 at 04:06:22PM -0700, Matt Roper wrote:
We're seeing some failures where an aux transaction still shows as
'busy' well after the timeout limit that the hardware is supposed to
enforce. Improve the error message so that we can see exactly which aux
channel this error happened
We're seeing some failures where an aux transaction still shows as
'busy' well after the timeout limit that the hardware is supposed to
enforce. Improve the error message so that we can see exactly which aux
channel this error happened on and what the status bits were during this
case that isn't s
