Opened 11 years ago

Closed 8 years ago

Last modified 8 years ago

#9098 closed bug (fixed)

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

Reported by: mpxlbs Owned by: marcusoverhagen
Priority: high Milestone: R1/beta1
Component: Drivers/Disk Version: R1/Development
Keywords: Cc: grg.gdsr@…
Blocked By: Blocking:
Platform: x86

Description

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

Change History (15)

comment:1 by anevilyak, 11 years ago

Component: SystemDrivers/Disk
Owner: changed from nobody to marcusoverhagen

Syslogs for both cases would be helpful.

comment:2 by kallisti5, 11 years ago

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!

comment:3 by kallisti5, 11 years ago

Milestone: R1R1/alpha4
Priority: normalhigh

comment:4 by kallisti5, 11 years ago

Milestone: R1/alpha4R1/beta1

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

comment:5 by mpxlbs, 11 years ago

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.

comment:6 by HAL, 10 years ago

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.

comment:7 by HAL, 10 years ago

Cc: grg.gdsr@… added

comment:8 by richienyhus, 9 years ago

Is this still happening in post-PM Haiku ?

comment:9 by mpxlbs, 9 years ago

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

comment:10 by mpxlbs, 9 years ago

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

comment:11 by pulkomandy, 9 years ago

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.

comment:12 by pulkomandy, 9 years ago

Milestone: R1/beta1Unscheduled

comment:13 by kallisti5, 8 years ago

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.

comment:14 by kallisti5, 8 years ago

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.

Last edited 8 years ago by kallisti5 (previous) (diff)

comment:15 by kallisti5, 8 years ago

Milestone: UnscheduledR1/beta1
Resolution: fixed
Status: newclosed

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.

Last edited 8 years ago by kallisti5 (previous) (diff)
Note: See TracTickets for help on using tickets.