So the (not so) recent bump of BLK_DEF_MAX_SECTORS from 1024 to 2560 (commit d2be537c3ba3) seemed to have caused trouble to some of the ATA devices, which were then worked around with ATA_HORKAGE_MAX_SEC_1024. However, I am suspecting that the bump of BLK_DEF_MAX_SECTORS is not the "real" cause of the trouble, but the fact that AHCI_MAX_SG has been set to a weird value of 168 (with a comment "hardware max is 64K", which neither seem to make any sense). AHCI_MAX_SG is used to set the sg_tablesize (i.e. max_segments, apparently), which is apparently used to derive the actual "request size" (that is, if it is lower than max_sectors(_kb), it will be the limiting factor instead). For example, no matter if the drive has max_sectors set to 2560, or to 65535 (by adding it as the Optimal Transfer Length to libata's SATL, which is also max_hw_sectors that is set from ATA_MAX_SECTORS_LBA48), "avgrq-sz" in `iostat` will be capped at 1344 (168 * 8). However, if I change AHCI_MAX_SG to 128 (which is also the sg_tablesize set in libata.h from LIBATA_MAX_PRD), "avgrq-sz" in `iostat` will be capped at 1024 (128 * 8), which should make ATA_HORKAGE_MAX_SEC_1024 unnecessary. So why has AHCI_MAX_SG been set to 168 anyway? -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
