On 2015-12-22 01:07, Tejun Heo wrote:
Hello, Artem. Can you please apply the following patch on top and see whether anything changes? If it does make the issue go away, can you please revert the ".can_queue" part and test again? Thanks. --- drivers/ata/ahci.h | 2 +- drivers/ata/libahci.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/drivers/ata/ahci.h +++ b/drivers/ata/ahci.h @@ -365,7 +365,7 @@ extern struct device_attribute *ahci_sde */ #define AHCI_SHT(drv_name) \ ATA_NCQ_SHT(drv_name), \ - .can_queue = AHCI_MAX_CMDS - 1, \ + .can_queue = 1/*AHCI_MAX_CMDS - 1*/, \ .sg_tablesize = AHCI_MAX_SG, \ .dma_boundary = AHCI_DMA_BOUNDARY, \ .shost_attrs = ahci_shost_attrs, \ --- a/drivers/ata/libahci.c +++ b/drivers/ata/libahci.c @@ -420,7 +420,7 @@ void ahci_save_initial_config(struct dev hpriv->saved_cap2 = cap2 = 0; /* some chips have errata preventing 64bit use */ - if ((cap & HOST_CAP_64) && (hpriv->flags & AHCI_HFLAG_32BIT_ONLY)) {+ if ((cap & HOST_CAP_64)/* && (hpriv->flags & AHCI_HFLAG_32BIT_ONLY)*/) {dev_info(dev, "controller can't do 64bit DMA, forcing 32bit\n"); cap &= ~HOST_CAP_64; }
With the ".can_queue" part left intact the bug resurfaced. Full dmesg output is attached.
Attachment:
dmesg.xz
Description: application/xz
