Haiku Alpha/Nightlies fails to show slave drives on Asus 990FX with AHCI enabled.

[mpxlbs]

Workaround is using IDE mode. It will only show the primary drive which Haiku is installed on.

[anevilyak]

Syslogs for both cases would be helpful.

[kallisti5]

which R1A4 nightly did you use? I recently cherry-picked some AHCI changes. We need to know if the image was before or after these changes.

Thanks!

[kallisti5]

bumping to post-R1A4 as we are out of time.

[mpxlbs]

Hello and sorry for the late reply. It still will not work in AHCI mode on the latest build, however all my disks show up now when entering haiku through IDE mode. AHCI mode still stops midway through the bootup process.

[HAL]

This bug might be similar or same as this #8647. On my system with motherboard ASUS M5A97 R2.0, it paused for about 2 minutes at center boot icon until finally lighting up the rest and booting. No problems booting in IDE mode. Also if I boot with only the boot drive in IDE mode and other drives in AHCI; it will boot but the other drives will not show up.

[richienyhus]

Is this still happening in post-PM Haiku ?

[mpxlbs]

As of hrev48659, Haiku still refuses to boot with AHCI mode enabled. Same issue.

[mpxlbs]

As of hrev49112, Haiku still refuses to boot with AHCI mode enabled. Same issue.

[pulkomandy]

As requested 3 years ago: "Syslogs for both cases would be helpful.".

You can use on-screen debug and take pictures if any other way of extracting the syslog fails (through serial ports or saving to an USB disk after reboot).

Without a syslog we won't be able to do much to fix the problem.

[kallisti5]

Same issue here on Gigabyte GA-990FXA-UD5 under latest x86_64 nightly hrev50036

The problem is a infinite loop of "Port connect change" events. Pretty similar to the AHCI cdrom issue, except it occurs on an attached sata disk.

ahci: AHCIPort::InterruptErrorHandler port 0, fCommandsActive 0x00000000, is 0x0000040, ci 0x00000000
ahci: ssts 0x00000001         << alternate
ahci: sctl 0x00000301
ahci: sact 0x00000000
ahci: Port Connect Change
.
.
ahci:ahci: AHCIPort::InterruptErrorHandler port 0, fCommandsActive 0x00000000, is 0x0000040, ci 0x00000000Port Connect Change
ahci: ssts 0x00000000         << alternate
ahci: sctl 0x00000301
ahci: sact 0x00000000
ahci: Port Connect Change

Fix which others have said is to enable IDE mode. I should note that is event occurs even booting from a usb drive. The stack gets stuck in this loop and continues infinitely.

[kallisti5]

I wonder if this is related to FIS Based Switching? It looks like some modern AHCI controllers only use one port and have multiple devices switched between them... might explain the random "single drive" issues as well.

​https://www.chipestimate.com/tech-talks/2013/01/22/Synopsys-Understanding-SATA-FIS-Based-Switching

Our AHCI driver has almost 0 FBS related code. I added a FBS cap check via hrev50038. It would be interesting to compare that state on non-working vs working AHCI implementations.

[kallisti5]

This issue appears to be resolved after my previous AHCI changes (tested via hrev50383) x86_64. (I'm having other issues now like SMP reboots and deadlocks however #12671)

mpxlbs: I'm going to flag this one as resolved. Feel free to re-open if it is still an issue.