3 ms·

> SATA driver init takes 100 to 200 ms even without a real disk That's pretty interesting. Wonder what it is doing?

mises 7y ago
Probably checking for a real disk? I guess it's got to check all the bus nodes for a disk, even if there's not one.
ComputerGuru 7y ago
SATA controller firmware has a hard-coded “drive predelay” that waits before enumerating attached devices, a relic from the days long before SSDs. Even when an option to set a custom amount is available in the BIOS, it is in addition to and not instead of, as there’s no bus master to tell it all attached disks have init and the controller may speak to them. It wouldn’t necessarily have to be done synchronously up front at all, except when the BIOS hands off control of the system to the SATA controller it expects that afterward it has a definitive list of available boot devices and their properties, for selection/display in the boot menu and BIOS configuration. Theoretically with UEFI and it’s NVRAM-resident settings, a boot device could be expressed as a namespace and path, and the firmware need not enumerate devices until it has determined that there’s a need to search for alternative/fallback boot devices, but the stack hasn’t been updated with that in mind.
- wtallis 7y ago
  The delay in question is in initializing the Linux driver, not in the system firmware scanning for bootable devices before running Linux. The Linux driver may be taking a while for similar reasons as the firmware delay you describe. The hard drive predelay is also not as obsolete as you may think; I've encountered high-capacity SATA SSDs that take a surprisingly long time to come up after being hotplugged, to the point that Linux doesn't always succeed in bringing up the link on the first try.
  - ComputerGuru 7y ago
    Sorry, I missed that in the discussion. Thanks. I’m willing to bet if the stack enforced tighter tolerances for modern non-rotating disks, manufacturers wouldn’t be able to slip such shoddy firmwares into production.

Probably checking for a real disk? I guess it's got to check all the bus nodes for a disk, even if there's not one.

SATA controller firmware has a hard-coded “drive predelay” that waits before enumerating attached devices, a relic from the days long before SSDs. Even when an option to set a custom amount is available in the BIOS, it is in addition to and not instead of, as there’s no bus master to tell it all attached disks have init and the controller may speak to them. It wouldn’t necessarily have to be done synchronously up front at all, except when the BIOS hands off control of the system to the SATA controller it expects that afterward it has a definitive list of available boot devices and their properties, for selection/display in the boot menu and BIOS configuration. Theoretically with UEFI and it’s NVRAM-resident settings, a boot device could be expressed as a namespace and path, and the firmware need not enumerate devices until it has determined that there’s a need to search for alternative/fallback boot devices, but the stack hasn’t been updated with that in mind.

wtallis 7y ago
The delay in question is in initializing the Linux driver, not in the system firmware scanning for bootable devices before running Linux. The Linux driver may be taking a while for similar reasons as the firmware delay you describe. The hard drive predelay is also not as obsolete as you may think; I've encountered high-capacity SATA SSDs that take a surprisingly long time to come up after being hotplugged, to the point that Linux doesn't always succeed in bringing up the link on the first try.
- ComputerGuru 7y ago
  Sorry, I missed that in the discussion. Thanks. I’m willing to bet if the stack enforced tighter tolerances for modern non-rotating disks, manufacturers wouldn’t be able to slip such shoddy firmwares into production.