I did set the scsi_logging_level as you wrote, but it still resulted
into exactly the same dmesg (resp. sudo journalctl -b 0) output with the
entire patchset (including the scmd-eh_eflags = 0;). Except for the
reverted do nothings, for course.
However, I did miss to mention the following
That patch appears to work in preventing the crashes, judged on one
repeated appearance of the bug.
dmesg had the usual
[ 215.229903] usb 4-2: usb_disable_lpm called, do nothing
[ 215.336941] usb 4-2: reset SuperSpeed USB device number 3 using xhci_hcd
[ 215.350296] xhci_hcd :00:14.0:
Only your 0/3 patch to which Alan linked, along with two other patches
by Mathias Nyman (disable usb3 on intel hosts and disable all lpm
related control transfers, one of which is the source of the do
nothings).
I'll revert the latter two and apply the rest of the set. Which I'm
guessing
On Thu, 10 Apr 2014, Hannes Reinecke wrote:
On 04/10/2014 12:58 PM, Andreas Reis wrote:
That patch appears to work in preventing the crashes, judged on one
repeated appearance of the bug.
dmesg had the usual
[ 215.229903] usb 4-2: usb_disable_lpm called, do nothing
[ 215.336941]
On 04/10/2014 05:31 PM, Alan Stern wrote:
On Thu, 10 Apr 2014, Hannes Reinecke wrote:
On 04/10/2014 12:58 PM, Andreas Reis wrote:
That patch appears to work in preventing the crashes, judged on one
repeated appearance of the bug.
dmesg had the usual
[ 215.229903] usb 4-2: usb_disable_lpm
On Thu, 2014-04-10 at 19:52 +0200, Hannes Reinecke wrote:
On 04/10/2014 05:31 PM, Alan Stern wrote:
On Thu, 10 Apr 2014, Hannes Reinecke wrote:
On 04/10/2014 12:58 PM, Andreas Reis wrote:
That patch appears to work in preventing the crashes, judged on one
repeated appearance of the bug.
On 04/10/2014 10:36 PM, James Bottomley wrote:
On Thu, 2014-04-10 at 19:52 +0200, Hannes Reinecke wrote:
On 04/10/2014 05:31 PM, Alan Stern wrote:
On Thu, 10 Apr 2014, Hannes Reinecke wrote:
On 04/10/2014 12:58 PM, Andreas Reis wrote:
That patch appears to work in preventing the crashes,
On 04/07/2014 05:26 PM, Alan Stern wrote:
On Wed, 2 Apr 2014, Hannes Reinecke wrote:
On 04/01/2014 11:28 PM, Alan Stern wrote:
On Tue, 1 Apr 2014, Hannes Reinecke wrote:
So if the above reasoning is okay then this patch should be doing
the trick:
diff --git a/drivers/scsi/scsi_error.c
On Wed, 9 Apr 2014, Hannes Reinecke wrote:
I finally got a chance to try it out. It does seem to do what we want.
I didn't track the flow of control in complete detail, but the command
definitely got aborted both times it was issued.
Good, so it is as I thought. James, can we include
On Wed, 2 Apr 2014, Hannes Reinecke wrote:
On 04/01/2014 11:28 PM, Alan Stern wrote:
On Tue, 1 Apr 2014, Hannes Reinecke wrote:
So if the above reasoning is okay then this patch should be doing
the trick:
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index
On 04/01/2014 11:28 PM, Alan Stern wrote:
On Tue, 1 Apr 2014, Hannes Reinecke wrote:
So if the above reasoning is okay then this patch should be doing
the trick:
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 771c16b..0e72374 100644
---
On 03/31/2014 05:03 PM, James Bottomley wrote:
[lets split the thread]
On Mon, 2014-03-31 at 16:37 +0200, Hannes Reinecke wrote:
On 03/31/2014 03:33 PM, Alan Stern wrote:
On Mon, 31 Mar 2014, Hannes Reinecke wrote:
On 03/28/2014 08:29 PM, Alan Stern wrote:
On Fri, 28 Mar 2014, James
On 04/01/2014 12:29 AM, Alan Stern wrote:
On Mon, 31 Mar 2014, Hannes Reinecke wrote:
Ah. Correct. But that's due to the first patch being incorrect.
Cf my response to the original first patch.
See my response to your response. :-)
Okay, So I probably should refrain from issueing a
On Tue, 1 Apr 2014, Hannes Reinecke wrote:
So if the above reasoning is okay then this patch should be doing
the trick:
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 771c16b..0e72374 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
On 03/28/2014 08:29 PM, Alan Stern wrote:
On Fri, 28 Mar 2014, James Bottomley wrote:
This is a set of three patches we agreed to a while ago to eliminate a
USB deadlock. I did rewrite the first patch, if it could be reviewed
and tested.
I tested all three patches under the same
On Mon, 31 Mar 2014, Hannes Reinecke wrote:
On 03/28/2014 08:29 PM, Alan Stern wrote:
On Fri, 28 Mar 2014, James Bottomley wrote:
This is a set of three patches we agreed to a while ago to eliminate a
USB deadlock. I did rewrite the first patch, if it could be reviewed
and tested.
On 03/31/2014 03:33 PM, Alan Stern wrote:
On Mon, 31 Mar 2014, Hannes Reinecke wrote:
On 03/28/2014 08:29 PM, Alan Stern wrote:
On Fri, 28 Mar 2014, James Bottomley wrote:
This is a set of three patches we agreed to a while ago to eliminate a
USB deadlock. I did rewrite the first patch,
[lets split the thread]
On Mon, 2014-03-31 at 16:37 +0200, Hannes Reinecke wrote:
On 03/31/2014 03:33 PM, Alan Stern wrote:
On Mon, 31 Mar 2014, Hannes Reinecke wrote:
On 03/28/2014 08:29 PM, Alan Stern wrote:
On Fri, 28 Mar 2014, James Bottomley wrote:
Maybe scmd_eh_abort_handler()
On Mon, 31 Mar 2014, Hannes Reinecke wrote:
Ah. Correct. But that's due to the first patch being incorrect.
Cf my response to the original first patch.
See my response to your response. :-)
Okay, So I probably should refrain from issueing a response to
your response to my response
On Mon, 31 Mar 2014, James Bottomley wrote:
The actual question is whether it's worth aborting the same command
a second time.
In principle any reset (like LUN reset etc) should clear the
command, too.
And the EH abort functionality is geared around this.
If, for some reason, the
This is a set of three patches we agreed to a while ago to eliminate a
USB deadlock. I did rewrite the first patch, if it could be reviewed
and tested.
Thanks,
James
---
Alan Stern (1):
[SCSI] Fix command result state propagation
James Bottomley (2):
[SCSI] Fix abort state memory problem
On Fri, 28 Mar 2014, James Bottomley wrote:
This is a set of three patches we agreed to a while ago to eliminate a
USB deadlock. I did rewrite the first patch, if it could be reviewed
and tested.
I tested all three patches under the same conditions as before, and
they all worked correctly.
22 matches
Mail list logo
