> "James" == James Bottomley writes:
>> Below is James' patch with a trivial comment fix and a proper
>> changelog. James, can I get your signoff for this one? I'll throw
>> it into the core-for-3.16 tree then.
James> OK, here it is. I tweaked the comment to be accurate.
Reviewed-by: Mart
On Wed, Jul 09, 2014 at 03:38:18PM -0700, James Bottomley wrote:
> On Thu, 2014-07-03 at 10:18 -0700, Christoph Hellwig wrote:
> > On Thu, Jul 03, 2014 at 09:57:32AM -0700, Steven Haber wrote:
> > > Both patches work fine -- zero uncommitted writes over several hundred
> > > power cycles.
> >
> >
On Thu, 2014-07-03 at 10:18 -0700, Christoph Hellwig wrote:
> On Thu, Jul 03, 2014 at 09:57:32AM -0700, Steven Haber wrote:
> > Both patches work fine -- zero uncommitted writes over several hundred
> > power cycles.
>
> Thanks for the testing.
>
> Below is James' patch with a trivial comment fix
On Thu, Jul 03, 2014 at 09:57:32AM -0700, Steven Haber wrote:
> Both patches work fine -- zero uncommitted writes over several hundred
> power cycles.
Thanks for the testing.
Below is James' patch with a trivial comment fix and a proper changelog.
James, can I get your signoff for this one? I'll
Both patches work fine -- zero uncommitted writes over several hundred
power cycles.
On Tue, Jul 1, 2014 at 1:15 AM, Christoph Hellwig wrote:
> On Mon, Jun 30, 2014 at 11:45:31AM -0700, Steven Haber wrote:
>> Our qual rig is having some woes. I'll let you know how the test works
>> out after I fi
On Mon, Jun 30, 2014 at 11:45:31AM -0700, Steven Haber wrote:
> Our qual rig is having some woes. I'll let you know how the test works
> out after I finish resuscitating it.
Might be worth to test that patch James send in reply then. They should
have an identical effect and James seems to prefer
Our qual rig is having some woes. I'll let you know how the test works
out after I finish resuscitating it.
On Mon, Jun 30, 2014 at 11:44 AM, Steven Haber wrote:
> Our qual rig is having some woes. I'll let you know how the test works out
> after I finish resuscitating it.
>
>
> On Fri, Jun 27, 2
On Thu, Jun 26, 2014 at 02:52:14PM -0400, James Bottomley wrote:
> > + } else if (req->cmd_flags & REQ_FLUSH) {
> > + /*
> > +* Flush request don't transfer data, so we can't try
> > +* to complete the good bytes first before checking
> > +* the error
On Thu, Jun 26, 2014 at 02:52:56PM -0400, James Bottomley wrote:
> OK, I give up, what memory leak (you don't actually mention it in your
> emails)? All memory handling is correctly done in unprep as far as I
> can tell.
To quote my earlier mail:
> - scsi_unprep_fn: calls ->uninit_command only
On Thu, 2014-06-26 at 08:08 -0700, Christoph Hellwig wrote:
> On Thu, Jun 26, 2014 at 11:04:56AM -0400, James Bottomley wrote:
> > Right, but look what we do for the specials. The only difference is the
> > ULD has a hook to generate the CDB. For everything else we follow the
> > BLOCK_PC path, i
On Thu, 2014-06-26 at 08:02 -0700, Christoph Hellwig wrote:
> Hi Steven,
>
> can you test the patch below?
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index f7e3163..9b56e48 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -733,6 +733,14 @@ void
Sure, I'll run it overnight.
On Thu, Jun 26, 2014 at 8:02 AM, Christoph Hellwig wrote:
> Hi Steven,
>
> can you test the patch below?
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index f7e3163..9b56e48 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
On Thu, Jun 26, 2014 at 11:04:56AM -0400, James Bottomley wrote:
> Right, but look what we do for the specials. The only difference is the
> ULD has a hook to generate the CDB. For everything else we follow the
> BLOCK_PC path, including error handling and sense data processing.
No, we don't use
On Thu, 2014-06-26 at 08:00 -0700, Christoph Hellwig wrote:
> On Thu, Jun 26, 2014 at 10:02:47AM -0400, James Bottomley wrote:
> > Yes, but think what you're proposing. Every block command with a
> > special setup goes via scsi_setup_blk_pc_cmnd() because they usually
> > have to translate to some
Hi Steven,
can you test the patch below?
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index f7e3163..9b56e48 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -733,6 +733,14 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned
int good_bytes)
On Thu, Jun 26, 2014 at 10:02:47AM -0400, James Bottomley wrote:
> Yes, but think what you're proposing. Every block command with a
> special setup goes via scsi_setup_blk_pc_cmnd() because they usually
> have to translate to something special.
That logic is backwards. The "special" commands use
On Wed, 2014-06-25 at 06:13 -0700, Christoph Hellwig wrote:
> On Thu, Jun 19, 2014 at 11:05:59AM -0700, James Bottomley wrote:
> > That's not really a good idea either ... I did think of it. We'll end
> > up with a cmd_type of REQ_TYPE_FS which because of REQ_FLUSH (or REQ_FUA
> > or REQ_DISCARD
On Thu, Jun 19, 2014 at 11:05:59AM -0700, James Bottomley wrote:
> That's not really a good idea either ... I did think of it. We'll end
> up with a cmd_type of REQ_TYPE_FS which because of REQ_FLUSH (or REQ_FUA
> or REQ_DISCARD or any number of other things) we have to treat as though
> it were R
On Wed, 2014-06-11 at 06:37 -0700, Christoph Hellwig wrote:
> On Mon, Jun 09, 2014 at 10:29:06AM -0700, James Bottomley wrote:
> > I'll do it as a bug fix, but I do need Jens to make sure nothing else
> > breaks first. Best I can tell, the state model for compound commands
> > like flush doesn't e
On Mon, Jun 09, 2014 at 10:29:06AM -0700, James Bottomley wrote:
> I'll do it as a bug fix, but I do need Jens to make sure nothing else
> breaks first. Best I can tell, the state model for compound commands
> like flush doesn't expect us to change the request type ... nothing puts
> it back to RE
On Mon, 2014-06-09 at 10:21 -0700, Steven Haber wrote:
> Thanks a bunch James! I patched and ran our suite over the weekend and
> didn't see any failures at all. I also didn't notice any side effects.
> I poked through the kernel logs and everything looked like it did
> before. I'll let you know if
Thanks a bunch James! I patched and ran our suite over the weekend and
didn't see any failures at all. I also didn't notice any side effects.
I poked through the kernel logs and everything looked like it did
before. I'll let you know if anything else weird crops up. Any idea
when this will get chec
On Thu, 2014-06-05 at 16:52 -0700, Steven Haber wrote:
> Hello,
>
> I am testing ATA device durability during hot unplug. I have a power
> fault test suite that has turned up issues with the fsync->SCSI->ATA
> codepath. If a device is unplugged while an fsync is in progress, ATA
> returns a flush
Hello,
I am testing ATA device durability during hot unplug. I have a power
fault test suite that has turned up issues with the fsync->SCSI->ATA
codepath. If a device is unplugged while an fsync is in progress, ATA
returns a flush error to the SCSI driver but scsi_io_completion()
seems to disregar
24 matches
Mail list logo
