Re: [PATCH] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev

On Wed, 10 Aug 2016, Eric Wheeler wrote: > On Sun, 10 Apr 2016 20:01:30 +0200, Sebastian Roesner wrote: > > Am 01.04.2016 um 20:14 schrieb Eric Wheeler: > > > On Mon, 28 Mar 2016, Shaohua Li wrote: > > > > On Sat, Mar 26, 2016 at 05:46:16PM +0100, Sebastian Roesner wrote: > > > > > Hello Ming, Eri

Re: [PATCH v2] block: make sure big bio is splitted into at most 256 bvecs

On Fri, 10 Jun 2016, Christoph Hellwig wrote: > On Wed, 6 Apr 2016, Ming Lei wrote: > > > > After arbitrary bio size is supported, the incoming bio may > > be very big. We have to split the bio into small bios so that > > each holds at most BIO_MAX_PAGES bvecs for safety reason, such > > as bio_cl

Re: [PATCH] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev

Hi Eric, [auto build test ERROR on linus/master] [also build test ERROR on v4.8-rc1 next-20160811] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Eric-Wheeler/NULL-pointer-in-raid1_make_request-

Re: [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion

On Tue, 19 Jul 2016, Lars Ellenberg wrote: > On Tue, Jul 12, 2016 at 10:32:33PM -0400, Mike Snitzer wrote: > > On Tue, Jul 12 2016 at 10:18pm -0400, > > Eric Wheeler wrote: > > > > > On Tue, 12 Jul 2016, NeilBrown wrote: > > > > > > > On Tue, Jul 12 2016, Lars Ellenberg wrote: > > > > > > >

[PATCH] NULL pointer in raid1_make_request passed to bio_trim when adding md as bcache caching dev

On Sun, 10 Apr 2016 20:01:30 +0200, Sebastian Roesner wrote: > Am 01.04.2016 um 20:14 schrieb Eric Wheeler: > > On Mon, 28 Mar 2016, Shaohua Li wrote: > > > On Sat, Mar 26, 2016 at 05:46:16PM +0100, Sebastian Roesner wrote: > > > > Hello Ming, Eric, > > > > > > > > Am 26.03.2016 um 16:40 schrieb M

Re: [PATCH v2 2/2] libata-core: do not set dev->max_sectors for LBA48 devices

> "Tom" == Tom Yan writes: Tom, Tom> Now let's just come back to libata. I've thought of reporting dev-> Tom> max_sectors as Optimal Transfer Length in the SATL. However, I am Tom> not sure if it is a safe thing to do, because we set it as high as Tom> 65535 for devices with LBA48 devices. D

Re: Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)

Hi, On 08/10/2016 10:14 AM, Tejun Heo wrote: Hello, Tom. On Wed, Aug 10, 2016 at 06:04:10PM +0800, Tom Yan wrote: On 10 August 2016 at 11:26, Tejun Heo wrote: Hmmm.. why not? The hardware limit is 64k and the driver is using a Is that referring to the maximum number of entries allowed in

Re: [PATCH v2 2/2] libata-core: do not set dev->max_sectors for LBA48 devices

I have to admit that libata may not be the right place to deal with my concern over the current BLK_DEF_MAX_SECTORS, which seems non-sensical to me. In the original commit message: (d2be537c3ba3, "block: bump BLK_DEF_MAX_SECTORS to 2560") "A value of 2560 (1280k) will accommodate a 10-data-disk st

Re: Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)

On 10 August 2016 at 15:41, David Milburn wrote: > Hi, > > The 168 makes AHCI_CMD_TBL_SZ equal to 2816 > > AHCI_CMD_TBL_SZ = AHCI_CMD_TBL_HDR_SZ + (AHCI_MAX_SG * 16) > AHCI_CMD_TBL_SZ = 128 + (168 * 16) > > I think if you add in AHCI_CMD_SLOT_SZ (1024) and AHCI_RX_FIS_SZ (256) > the DMA is 4K alig

Re: [PATCH v2 1/1] blk-mq: fix hang caused by freeze/unfreeze sequence

Hi, On Wed, Aug 10, 2016 at 5:55 AM, Tejun Heo wrote: > Hello, > > On Mon, Aug 08, 2016 at 01:39:08PM +0200, Roman Pen wrote: >> Long time ago there was a similar fix proposed by Akinobu Mita[1], >> but it seems that time everyone decided to fix this subtle race in >> percpu-refcount and Tejun He

Re: Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)

On 08/10/2016 12:19 PM, Tom Yan wrote: On 10 August 2016 at 15:41, David Milburn wrote: Hi, The 168 makes AHCI_CMD_TBL_SZ equal to 2816 AHCI_CMD_TBL_SZ = AHCI_CMD_TBL_HDR_SZ + (AHCI_MAX_SG * 16) AHCI_CMD_TBL_SZ = 128 + (168 * 16) I think if you add in AHCI_CMD_SLOT_SZ (1024) and AHCI_RX_FIS_

Re: Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)

On 10 August 2016 at 11:26, Tejun Heo wrote: > Hmmm.. why not? The hardware limit is 64k and the driver is using a Is that referring to the maximum number of entries allowed in the PRDT, Physical Region Descriptor Table (which is, more precisely, 65535)? > lower limit of 168 most likely because

Re: Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)

Hello, Tom. On Wed, Aug 10, 2016 at 06:04:10PM +0800, Tom Yan wrote: > On 10 August 2016 at 11:26, Tejun Heo wrote: > > Hmmm.. why not? The hardware limit is 64k and the driver is using a > > Is that referring to the maximum number of entries allowed in the > PRDT, Physical Region Descriptor Ta

Re: [PATCH v2 2/2] libata-core: do not set dev->max_sectors for LBA48 devices

Hello, Tom. On Wed, Aug 10, 2016 at 04:32:39PM +0800, Tom Yan wrote: > I have to admit that libata may not be the right place to deal with my > concern over the current BLK_DEF_MAX_SECTORS, which seems non-sensical > to me. In the original commit message: > > (d2be537c3ba3, "block: bump BLK_DEF_M

Re: [PATCH v2 1/1] blk-mq: fix hang caused by freeze/unfreeze sequence

On Wed, Aug 10, 2016 at 10:42:09AM +0200, Roman Penyaev wrote: > Hi, > > On Wed, Aug 10, 2016 at 5:55 AM, Tejun Heo wrote: > > Hello, > > > > On Mon, Aug 08, 2016 at 01:39:08PM +0200, Roman Pen wrote: > >> Long time ago there was a similar fix proposed by Akinobu Mita[1], > >> but it seems that t

Re: [PATCH v2 1/1] blk-mq: fix hang caused by freeze/unfreeze sequence

On Wed, Aug 10, 2016 at 10:42 AM, Roman Penyaev wrote: > Hi, > > On Wed, Aug 10, 2016 at 5:55 AM, Tejun Heo wrote: >> Hello, >> >> On Mon, Aug 08, 2016 at 01:39:08PM +0200, Roman Pen wrote: >>> Long time ago there was a similar fix proposed by Akinobu Mita[1], >>> but it seems that time everyone