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 <dmilb...@redhat.com> 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_S

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

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

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: ata: BUG in ata_sff_hsm_move

Hi Tejun, Can ata_sff_hsm_move grab the lock and save off the task_state, like this patch? Thanks, David On Fri, Jan 29, 2016 at 02:40:33PM +0100, Dmitry Vyukov wrote: > On Fri, Jan 29, 2016 at 2:18 PM, Dmitry Vyukov wrote: > > On Fri, Jan 29, 2016 at 1:23 PM, Tejun Heo wrote: > >> Hello,

Re: ata: BUG in ata_sff_hsm_move

Hi Tejun, Can ata_sff_hsm_move grab the lock and save off the task_state, like this patch? Thanks, David On Fri, Jan 29, 2016 at 02:40:33PM +0100, Dmitry Vyukov wrote: > On Fri, Jan 29, 2016 at 2:18 PM, Dmitry Vyukov wrote: > > On Fri, Jan 29, 2016 at 1:23 PM, Tejun Heo

Re: BUG v3.19: reference count warning when removing scsi_debug device

On 02/18/2015 07:22 AM, Tomas Winkler wrote: reference count warning when removing scsi_debug device ARNING: CPU: 2 PID: 16732 at kernel/module.c:954 module_put+0xc9/0xd0() [150550.918033] Modules linked in: scsi_debug(-) pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) nfsv3 rfcomm

Re: BUG v3.19: reference count warning when removing scsi_debug device

On 02/18/2015 07:22 AM, Tomas Winkler wrote: reference count warning when removing scsi_debug device ARNING: CPU: 2 PID: 16732 at kernel/module.c:954 module_put+0xc9/0xd0() [150550.918033] Modules linked in: scsi_debug(-) pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) nfsv3 rfcomm

Re: [PATCH 1/1] ata: Check and set 64-bit DMA mask for platform AHCI driver

On 05/23/2014 12:35 PM, suravee.suthikulpa...@amd.com wrote: From: Suravee Suthikulpanit The current platform AHCI drier does not set the dma_mask correctly for 64-bit DMA capable AHCI controller. This patch checks the AHCI capability bit and set the dma_mask and coherent_dma_mask

Re: [PATCH 1/1] ata: Check and set 64-bit DMA mask for platform AHCI driver

On 05/23/2014 12:35 PM, suravee.suthikulpa...@amd.com wrote: From: Suravee Suthikulpanit suravee.suthikulpa...@amd.com The current platform AHCI drier does not set the dma_mask correctly for 64-bit DMA capable AHCI controller. This patch checks the AHCI capability bit and set the dma_mask and

Re: [PATCH 1/1] ahci: Do not receive interrupts sent by dummy ports

the way from the PCI device to the kernel, causing unnecessary overhead. This update disables IRQs for dummy ports and prevents the described issue. Signed-off-by: Alexander Gordeev Cc: Tejun Heo Cc: David Milburn Cc: linux-...@vger.kernel.org David, can you please test the patch? Hi, I have

Re: [PATCH 1/1] ahci: Do not receive interrupts sent by dummy ports

the way from the PCI device to the kernel, causing unnecessary overhead. This update disables IRQs for dummy ports and prevents the described issue. Signed-off-by: Alexander Gordeev agord...@redhat.com Cc: Tejun Heo t...@kernel.org Cc: David Milburn dmilb...@redhat.com Cc: linux-...@vger.kernel.org

Re: [PATCH] bio_integrity_add_page: check for BIO_POOL_NONE before determining nr_vecs on slab

On 02/03/2014 09:55 PM, Martin K. Petersen wrote: "David" == David Milburn writes: David> When enabling DIX T10-DIF-TYPE1-IP protection you can hit the David> bip_vec full condition which fails to attach the integrity David> metadata and returns 0 back to bio_integrity_prep

Re: [PATCH] bio_integrity_add_page: check for BIO_POOL_NONE before determining nr_vecs on slab

On 02/03/2014 09:55 PM, Martin K. Petersen wrote: David == David Milburn dmilb...@redhat.com writes: David When enabling DIX T10-DIF-TYPE1-IP protection you can hit the David bip_vec full condition which fails to attach the integrity David metadata and returns 0 back to bio_integrity_prep

[PATCH] bio_integrity_add_page: check for BIO_POOL_NONE before determining nr_vecs on slab

or FUA [ 198.485850] sda: sda1 [ 198.485926] sd 0:0:24:1089486880: [sda] Enabling DIX T10-DIF-TYPE1-IP protection [ 198.487652] sd 0:0:24:1089486880: [sda] Attached SCSI disk [ 276.566682] XFS (sda1): Mounting Filesystem [ 276.576558] XFS (sda1): Ending clean mount Signed-off-by: David Milburn ---

[PATCH] bio_integrity_add_page: check for BIO_POOL_NONE before determining nr_vecs on slab

or FUA [ 198.485850] sda: sda1 [ 198.485926] sd 0:0:24:1089486880: [sda] Enabling DIX T10-DIF-TYPE1-IP protection [ 198.487652] sd 0:0:24:1089486880: [sda] Attached SCSI disk [ 276.566682] XFS (sda1): Mounting Filesystem [ 276.576558] XFS (sda1): Ending clean mount dmesg Signed-off-by: David

Re: [PATCH] mtip32xx: Add SRSI support

Asai Thambi S P wrote: This patch add support for SRSI(Surprise Removal Surprise Insertion). Approach: - Surprise Removal: - On surprise removal of the device, gendisk, request queue, device index, sysfs entries, etc are retained as long as device is in use - mounted

Re: [PATCH] mtip32xx: Add SRSI support

Asai Thambi S P wrote: This patch add support for SRSI(Surprise Removal Surprise Insertion). Approach: - Surprise Removal: - On surprise removal of the device, gendisk, request queue, device index, sysfs entries, etc are retained as long as device is in use - mounted

Re: [PATCH v2] [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal

Roland Dreier wrote: On Wed, Aug 7, 2013 at 7:38 AM, David Milburn wrote: I was able to succesfully test this patch overnight, I had been experimenting with the sg driver setting the BIO_NULL_MAPPED flag in sg_rq_end_io_usercontext for a orphan process which prevented the corruption

Re: [PATCH v2] [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal

Roland Dreier wrote: From: Roland Dreier There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances leads to one process writing data into the address space of some other random unrelated process if the ioctl is interrupted by a signal. What happens is the following: - A process

Re: [PATCH v2] [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal

Roland Dreier wrote: From: Roland Dreier rol...@purestorage.com There is a nasty bug in the SCSI SG_IO ioctl that in some circumstances leads to one process writing data into the address space of some other random unrelated process if the ioctl is interrupted by a signal. What happens is the

Re: [PATCH v2] [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal

Roland Dreier wrote: On Wed, Aug 7, 2013 at 7:38 AM, David Milburn dmilb...@redhat.com wrote: I was able to succesfully test this patch overnight, I had been experimenting with the sg driver setting the BIO_NULL_MAPPED flag in sg_rq_end_io_usercontext for a orphan process which prevented

[PATCH] mtip32xx: dynamically allocate buffer in debugfs functions

-by: David Milburn --- drivers/block/mtip32xx/mtip32xx.c | 47 + 1 files changed, 37 insertions(+), 10 deletions(-) diff --git a/drivers/block/mtip32xx/mtip32xx.c b/drivers/block/mtip32xx/mtip32xx.c index 847107e..baa0996 100644 --- a/drivers/block/mtip32xx

[PATCH] mtip32xx: dynamically allocate buffer in debugfs functions

-by: David Milburn dmilb...@redhat.com --- drivers/block/mtip32xx/mtip32xx.c | 47 + 1 files changed, 37 insertions(+), 10 deletions(-) diff --git a/drivers/block/mtip32xx/mtip32xx.c b/drivers/block/mtip32xx/mtip32xx.c index 847107e..baa0996 100644 --- a/drivers

[PATCH] mtip32xx: fix user_buffer check in exec_drive_command

: DELL_P320h-MTFDGAL350SAH Serial Number: 121302025F01 Firmware Revision: B1442808 Reported-by: Tomas Henzl Signed-off-by: David Milburn --- drivers/block/mtip32xx/mtip32xx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff

[PATCH] mtip32xx: fix user_buffer check in exec_drive_command

: DELL_P320h-MTFDGAL350SAH Serial Number: 121302025F01 Firmware Revision: B1442808 snip Reported-by: Tomas Henzl the...@redhat.com Signed-off-by: David Milburn dmilb...@redhat.com --- drivers/block/mtip32xx/mtip32xx.c |2 +- 1 files changed

[PATCH] libata-scsi: ata_task_ioctl should return ATA registers from sense data

User applications using the HDIO_DRIVE_TASK ioctl through libata expect specific ATA registers to be returned to userspace. Verified that ata_task_ioctl correctly returns register values to the smartctl application. Signed-off-by: David Milburn <[EMAIL PROTECTED]> --- diff --git a/drive

[PATCH] libata-scsi: ata_task_ioctl should return ATA registers from sense data

User applications using the HDIO_DRIVE_TASK ioctl through libata expect specific ATA registers to be returned to userspace. Verified that ata_task_ioctl correctly returns register values to the smartctl application. Signed-off-by: David Milburn [EMAIL PROTECTED] --- diff --git a/drivers/ata