On 2021-04-22 19:26, Rick Lindsley wrote:
On 4/22/21 10:21 AM, Michal Suchánek wrote:
Merging do_reset and do_hard_reset might be a good code cleanup which
is
out of the scope of this fix.
I agree, on both points. Accepting the patch, and improving the reset
path are not in conflict with
On 4/22/21 10:21 AM, Michal Suchánek wrote:
Merging do_reset and do_hard_reset might be a good code cleanup which is
out of the scope of this fix.
I agree, on both points. Accepting the patch, and improving the reset
path are not in conflict with each other.
My position is that improving the
On Thu, Apr 22, 2021 at 12:21 PM Michal Suchánek wrote:
>
> Hello,
>
> On Thu, Apr 22, 2021 at 12:06:45AM -0500, Lijun Pan wrote:
> > On Wed, Apr 21, 2021 at 2:25 AM Sukadev Bhattiprolu
> > wrote:
> > >
> > > Lijun Pan [l...@linux.vnet.ibm.com] wrote:
> > > >
> > > >
> > > > > On Apr 20, 2021,
Hello,
On Thu, Apr 22, 2021 at 12:06:45AM -0500, Lijun Pan wrote:
> On Wed, Apr 21, 2021 at 2:25 AM Sukadev Bhattiprolu
> wrote:
> >
> > Lijun Pan [l...@linux.vnet.ibm.com] wrote:
> > >
> > >
> > > > On Apr 20, 2021, at 4:35 PM, Dany Madden wrote:
> > > >
> > > > When ibmvnic gets a FATAL error
On Thu, Apr 22, 2021 at 2:07 AM Rick Lindsley
wrote:
>
> On 4/21/21 10:30 PM, Lijun Pan wrote:
> >> Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
> >> Signed-off-by: Dany Madden
> >> Reviewed-by: Rick Lindsley
> >> Reviewed-by: Sukadev Bhattiprolu
> >
> > One thing I would like to
On 4/21/21 10:30 PM, Lijun Pan wrote:
Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
Signed-off-by: Dany Madden
Reviewed-by: Rick Lindsley
Reviewed-by: Sukadev Bhattiprolu
One thing I would like to point out as already pointed out by Nathan Lynch is
that those review-by tags given
On 4/21/21 10:06 PM, Lijun Pan wrote:
No real customer runs the system under that heavy load created by
HTX stress test, which can tear down any working system.
So, are you saying the bugs that HTX uncovers are not worth fixing?
There's a fair number of individuals and teams out there that
On Wed, Apr 21, 2021 at 3:06 AM Rick Lindsley
wrote:
Please describe the advantage in deferring it further by routing it through
do_hard_reset(). I don't see one.
On 4/21/21 10:12 PM, Lijun Pan replied:
It is not deferred. It exits with error and calls do_hard_reset.
See my reply to
Lijun Pan [lijunp...@gmail.com] wrote:
> > Now, sure we can attempt a "thorough hard reset" which also does
> > the same hcalls to reestablish the connection. Is there any
> > other magic in do_hard_reset()? But in addition, it also frees lot
> > more Linux kernel buffers and reallocates them for
On Tue, Apr 20, 2021 at 4:37 PM Dany Madden wrote:
>
> When ibmvnic gets a FATAL error message from the vnicserver, it marks
> the Command Respond Queue (CRQ) inactive and resets the adapter. If this
> FATAL reset fails and a transmission timeout reset follows, the CRQ is
> still inactive,
On Wed, Apr 21, 2021 at 3:06 AM Rick Lindsley
wrote:
>
> On 4/20/21 2:42 PM, Lijun Pan wrote:
> >
> > This v2 does not adddress the concerns mentioned in v1.
> > And I think it is better to exit with error from do_reset, and schedule a
> > thorough
> > do_hard_reset if the the adapter is already
On Wed, Apr 21, 2021 at 2:25 AM Sukadev Bhattiprolu
wrote:
>
> Lijun Pan [l...@linux.vnet.ibm.com] wrote:
> >
> >
> > > On Apr 20, 2021, at 4:35 PM, Dany Madden wrote:
> > >
> > > When ibmvnic gets a FATAL error message from the vnicserver, it marks
> > > the Command Respond Queue (CRQ) inactive
On 4/20/21 2:42 PM, Lijun Pan wrote:
This v2 does not adddress the concerns mentioned in v1.
And I think it is better to exit with error from do_reset, and schedule a
thorough
do_hard_reset if the the adapter is already in unstable state.
But the point is that the testing and analysis has
Lijun Pan [l...@linux.vnet.ibm.com] wrote:
>
>
> > On Apr 20, 2021, at 4:35 PM, Dany Madden wrote:
> >
> > When ibmvnic gets a FATAL error message from the vnicserver, it marks
> > the Command Respond Queue (CRQ) inactive and resets the adapter. If this
> > FATAL reset fails and a transmission
> On Apr 20, 2021, at 4:35 PM, Dany Madden wrote:
>
> When ibmvnic gets a FATAL error message from the vnicserver, it marks
> the Command Respond Queue (CRQ) inactive and resets the adapter. If this
> FATAL reset fails and a transmission timeout reset follows, the CRQ is
> still inactive,
15 matches
Mail list logo
