This Motherboard with a triple boot setup, booting in AHCI mode

Here is the relevant message (pulled from dmesg), note the long delay in timestamp between them:

[ 6.528119] ata2: link is slow to respond, please be patient (ready=-19)
[ 11.028120] ata2: SRST failed (errno=-16)
[ 16.540117] ata2: link is slow to respond, please be patient (ready=-19)
[ 21.040117] ata2: SRST failed (errno=-16)
[ 26.552117] ata2: link is slow to respond, please be patient (ready=-19)
[ 56.072118] ata2: SRST failed (errno=-16)
[ 56.072125] ata2: limiting SATA link speed to 1.5 Gbps
[ 61.104117] ata2: SRST failed (errno=-16)
[ 61.104142] ata2: reset failed, giving up

Seems to work fine on Windows. It's just an Ubuntu issue.

All my drives seem firmly connected, with no jumpers, most are SSD but some are IDE. I have like 6 drives. One is a Hackintosh (Mac GPT drive) and another is Windows. One SSD is connected via eSATA

I don't know if ata2 is the same as /dev/sdb but if it is, this may be interesting:

$ sudo fsck /dev/sdb 
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
 e2fsck -b 8193 <device>
 or
 e2fsck -b 32768 <device>

Found a gpt partition table in /dev/sdb

A commentary on the cause: https://www.redhat.com/archives/rhl-list/2006-October/msg03892.html

Because it's a GPT hackintosh drive:

$ sudo gdisk /dev/sdb -l
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
 MBR: protective
 BSD: not present
 APM: not present
 GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 1953525168 sectors, 931.5 GiB
Model: ST31000524AS 
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 384E6D96-A1EE-4D32-8FE5-14B63E4BF049
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 8-sector boundaries
Total free space is 262157 sectors (128.0 MiB)

Verify disk passes:

$ sudo gdisk /dev/sdb
$ v
No problems found. 262157 free sectors (128.0 MiB) available in 2
segments, the largest of which is 262151 (128.0 MiB) in size.

Step 1 - Identify ATA2

It's a guess that ATA2 references /dev/sdb. The way to find out for sure is using:

$ ll /sys/block/
total 0
drwxr-xr-x 2 root root 0 Apr 10 16:46 ./
dr-xr-xr-x 13 root root 0 Apr 4 21:05 ../
lrwxrwxrwx 1 root root 0 Apr 10 16:46 loop0 -> ../devices/virtual/block/loop0/
lrwxrwxrwx 1 root root 0 Apr 10 16:46 loop1 -> ../devices/virtual/block/loop1/
lrwxrwxrwx 1 root root 0 Apr 10 16:46 loop2 -> ../devices/virtual/block/loop2/
lrwxrwxrwx 1 root root 0 Apr 10 16:46 loop3 -> ../devices/virtual/block/loop3/
lrwxrwxrwx 1 root root 0 Apr 10 16:46 loop4 -> ../devices/virtual/block/loop4/
lrwxrwxrwx 1 root root 0 Apr 10 16:46 loop5 -> ../devices/virtual/block/loop5/
lrwxrwxrwx 1 root root 0 Apr 10 16:46 loop6 -> ../devices/virtual/block/loop6/
lrwxrwxrwx 1 root root 0 Apr 10 16:46 loop7 -> ../devices/virtual/block/loop7/
lrwxrwxrwx 1 root root 0 Apr 10 16:46 nvme0n1 -> ../devices/pci0000:00/0000:00:1d.0/0000:3e:00.0/nvme/nvme0/nvme0n1/
lrwxrwxrwx 1 root root 0 Apr 10 16:46 sda -> ../devices/pci0000:00/0000:00:17.0/ata2/host1/target1:0:0/1:0:0:0/block/sda/
lrwxrwxrwx 1 root root 0 Apr 10 16:46 sr0 -> ../devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.3/1-1.3:1.0/host2/target2:0:0/2:0:0:0/block/sr0/

Ignore the loop1 through loop7 entries.

• 
  sda (a hard drive) is on channel ata2
  


• 
  nvme0n1 (an SSD) is on 0000:3e:00.0 (actually hardwired to the CPU @ 40 GB/s)


• 
  sr0 is on usb1
  

So your first step is to discover which devices are on ata2

Step 2 - Check devices

ide devices can be chained with master/slave arrangement and if on ata2 you might need to check their settings whilst removing them one by one to ascertain which is defective.

Someone with same error discovered their DVD/CD drive on ata2 was the culprit and defective: "ata2: link is slow to respond, please be patient" during boot

Another person found a defective SSD was the problem: ata1: link is slow to respond, please be patient (ready=0)

By all means run fsck or whatever drive testing utilities at your disposal too.