I will pull out that patch from the drivers queue, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jun 02, 2014 at 07:22:07PM +, James Bottomley wrote:
Actually, can you really pull it out, not just revert it? Reverts cause
problems with bisection and are unnecessary before the tree goes to
Linus.
If preserving history becomes a real goal, we'd have to move to a tip
like
On Mon, 2014-06-02 at 12:33 -0700, h...@infradead.org wrote:
On Mon, Jun 02, 2014 at 07:22:07PM +, James Bottomley wrote:
Actually, can you really pull it out, not just revert it? Reverts cause
problems with bisection and are unnecessary before the tree goes to
Linus.
If
On Mon, Jun 2, 2014 at 12:33 PM, h...@infradead.org h...@infradead.org wrote:
Linus has been very unappy about rebasing close to or in the merge
window, and other subsystems generally revert patches that late in the
cycle as well. I'd prefer to stick to that model, but if you and Linus
On Mon, Jun 02, 2014 at 01:05:38PM -0700, Linus Torvalds wrote:
I would indeed prefer to avoid rebases, _unless_ the tree is a real
mess without it.
Now, what constitues real mess can vary. It can be just really ugly
history, and part of that can be it doesn't build or work at all
partway
On Mon, Jun 2, 2014 at 1:08 PM, h...@infradead.org h...@infradead.org wrote:
It's reverting a patch that just doesn't fix a problem fully, so the
prime reviewer and the patch author decided to withdraw it. It won't
cause any kind of problem during bisection.
If it isn't a particularly large
On Mon, Jun 02, 2014 at 01:24:22PM -0700, Linus Torvalds wrote:
If it isn't a particularly large patch and doesn't have any other
issues, I'd suggest just reverting it.
Particularly large patches can be worth undoing just to avoid
unnecessary noise in git blame etc, but that's an issue
] be2iscsi: Fix processing cqe for cxn whose endpoint is freed.
What command/function tells the card to stop sending the driver
events/notifications/ios for that connection? Is it beiscsi_close_conn or
mgmt_invalidate_connection?
Mgmt_invalidate_connection tell card to stop sending events
On Wed, May 07, 2014 at 05:18:38PM -0500, Mike Christie wrote:
It looks like if that race is possible then we could also free the ep
while you are accessing right? I think you would need to get a ref to
the ep.
What command/function tells the card to stop sending the driver
On 05/05/2014 08:41 PM, Jay Kallickal wrote:
From: Jayamohan Kallickal jayamohan.kallic...@emulex.com
During heavy IO in multipath environment with many active sessions
and port-bouncing happening, there is a race condition because of
which beiscsi_prcess_cqe() gets called for a
From: Jayamohan Kallickal jayamohan.kallic...@emulex.com
During heavy IO in multipath environment with many active sessions
and port-bouncing happening, there is a race condition because of
which beiscsi_prcess_cqe() gets called for a connection whose
endpoint is freed.
Checking endpoint
11 matches
Mail list logo
