On 14-09-09 11:55 PM, Douglas Gilbert wrote:
A few days ago I was trying to create a large file
(say 16 GB) of zeros on an ext4 file system:
dd if=/dev/zero bs=64k count=256k of=zero_16g.bin
After about 5 seconds there was a NULL de-reference that
crashed the machine (shown below). This was
Doug,
can you test the latest for-linus branch in Jens' tree
(git://git.kernel.dk/linux-block). It has a fix for the infinite
recursion with the FUA flag, and a lot of timeout handling fixes.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to maj
development list
Subject: Re: lk 3.17-rc4 blk_mq large write problems
On 2014-09-10 18:58, Douglas Gilbert wrote:
On 14-09-10 11:41 AM, Christoph Hellwig wrote:
While it might not help with a blown stack, can you give the patch
below
a try? I tries to solve a problem where the timeout handler
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Jens Axboe
> Sent: Wednesday, September 10, 2014 9:00 PM
> To: dgilb...@interlog.com; Christoph Hellwig
> Cc: SCSI development list
> Subject: R
On 2014-09-10 18:58, Douglas Gilbert wrote:
On 14-09-10 11:41 AM, Christoph Hellwig wrote:
While it might not help with a blown stack, can you give the patch below
a try? I tries to solve a problem where the timeout handler hits
before we've fully set up a command. While I'd like to understand
On 14-09-10 11:41 AM, Christoph Hellwig wrote:
While it might not help with a blown stack, can you give the patch below
a try? I tries to solve a problem where the timeout handler hits
before we've fully set up a command. While I'd like to understand the
root cause of why we're hitting it as we
On 09/10/2014 12:40 PM, Christoph Hellwig wrote:
> On Wed, Sep 10, 2014 at 12:26:57PM -0600, Jens Axboe wrote:
>>> I have to. It's set by start_request, so we need to pass down the last
>>> argument to keep the old behavior. And once we pass the argument we
>>> can just it directly.
>>
>> It coul
On Wed, Sep 10, 2014 at 12:26:57PM -0600, Jens Axboe wrote:
> > I have to. It's set by start_request, so we need to pass down the last
> > argument to keep the old behavior. And once we pass the argument we
> > can just it directly.
>
> It could still be done in the caller, but arguably, you'd h
On 09/10/2014 12:09 PM, Christoph Hellwig wrote:
> On Wed, Sep 10, 2014 at 10:47:49AM -0600, Jens Axboe wrote:
>> BTW, please don't mix up the REQ_END and ->queue_rq() changes with the
>> changed start_request API.
>
> I have to. It's set by start_request, so we need to pass down the last
> argum
On Wed, Sep 10, 2014 at 10:47:49AM -0600, Jens Axboe wrote:
> BTW, please don't mix up the REQ_END and ->queue_rq() changes with the
> changed start_request API.
I have to. It's set by start_request, so we need to pass down the last
argument to keep the old behavior. And once we pass the argumen
On 2014-09-10 09:41, Christoph Hellwig wrote:
While it might not help with a blown stack, can you give the patch below
a try? I tries to solve a problem where the timeout handler hits
before we've fully set up a command. While I'd like to understand the
root cause of why we're hitting it as wel
While it might not help with a blown stack, can you give the patch below
a try? I tries to solve a problem where the timeout handler hits
before we've fully set up a command. While I'd like to understand the
root cause of why we're hitting it as well, I'd also really to fix that
race. It would al
12 matches
Mail list logo
