AHCI not detecting disks properly on x86 PAE (x64 is fine)

[LSS37040]

This issue was discovered after #19117 has been fixed to the point that both x86 and x64 can be booted out-of-box (with x86 using PAE) as of hrev58265.

The AHCI driver appears to have issues when booting x86 with PAE addressing, with partitions not being detected correctly, appearing as "raw" and in some cases showing garbled characters in DriveSetup.

NVMe and USB drivers do not have issues with x86 PAE, as they were correctly detected there.

When booting x86 without PAE (by enabling "Ignore memory beyond 4GB"), or booting x64, the AHCI driver is working properly.

[LSS37040]

hrev58265 x86 boot log (without PAE), AHCI working

[LSS37040]

hrev58265 x86 boot log (with PAE), AHCI not working (reuploaded, from #19117)

[waddlesplash]

It seems odd that x86_64 would work here and x86 without PAE does, but x86 with PAE doesn't. I'm not sure what could cause that. If it were related to the use of 64-bit physical memory, I'd expect x86_64 to be broken also.

[waddlesplash]

Can you show some of the garbled characters, please?

[LSS37040]

device 2: /dev/disk/scsi/0/0/0/raw

media status: No error device flags: 2 offset: 0 size: 0 (0 MB) content size: 0 block size: 512 physical block size: 512 child count: 0 index: -1 status: 2 flags: 1 volume: -1 disk system: <NULL> name: 4., content name: <NULL> type: <NULL> content type: <NULL> params: <NULL> content params: <NULL>

device 3: /dev/disk/scsi/0/1/0/raw

media status: No error device flags: 2 offset: 0 size: 0 (0 MB) content size: 0 block size: 512 physical block size: 512 child count: 0 index: -1 status: 2 flags: 1 volume: -1 disk system: <NULL> name: content name: <NULL> type: <NULL> content type: <NULL> params: <NULL> content params: <NULL>

device 4: /dev/disk/scsi/0/2/0/raw

media status: No error device flags: 2 offset: 0 size: 0 (0 MB) content size: 0 block size: 512 physical block size: 512 child count: 0 index: -1 status: 2 flags: 1 volume: -1 disk system: <NULL> name: content name: <NULL> type: <NULL> content type: <NULL> params: <NULL> content params: <NULL>

device 5: /dev/disk/scsi/0/3/0/raw

media status: No error device flags: 2 offset: 0 size: 0 (0 MB) content size: 0 block size: 512 physical block size: 512 child count: 0 index: -1 status: 2 flags: 1 volume: -1 disk system: <NULL> name: content name: <NULL> type: <NULL> content type: <NULL> params: <NULL> content params: <NULL>

This is from the bootlog. All AHCI disks appear as 0 MB. The first disk's name shows " 4.," in the printed log, though I suspect a good amount of characters were simply not printable...

In DriveSetup they appear as a bunch of tofu marks (used for printing any invalid Unicode chars).

I'm using moserial to capture the serial log output on a Linux system... sadly the tool doesn't have a good option to reveal the details of unprintable characters... I need to look for a way to dump serial output as-is...

[waddlesplash]

I've posted ​https://review.haiku-os.org/c/haiku/+/8472, once there are test builds available it will be interesting to see if this fixes the problem.

[waddlesplash]

Test builds: ​https://haiku.movingborders.es/testbuild/Iee5e585a0e6f40c66f2a9b380603dd5e557aaa51/1/hrev58270/

[LSS37040]

Just tested... No difference from hrev58265.

Additionally, I used another tool to capture serial output, and it seems I've captured what exactly was in the "name" field of the first AHCI drive, when booting with x86 using PAE:

C8 20 F5 97 34 82 80 A8 D8 82 B5 AE 2C 81 80 A7 F0 82

Do these (mostly unprintable) characters contain anything that could point to where the problem is?

[waddlesplash]

Looks like #19011 may be related here, it's got similar symptoms. According to that ticket disabling IO-APIC fixes the problem, can you test?

[waddlesplash]

Looking at the syslogs more closely, I see the ones that work (including from x86_64 on #19117) have physical addresses (passed to sg_memcpy) in the 32-bit range, while the ones that don't from this ticket have ones in the 64-bit range. So, it seems this is still a 32/64 problem after all. (I wonder why or how we wind up with 64-bit addresses only on the PAE build?)

[waddlesplash]

Found another addressing issue, please retest after hrev58277.

[LSS37040]

Can confirm it's been fixed as of hrev58278.

On x86gcc2h without any safe mode option, AHCI disks are now properly detected. I just installed it to the partition on the AHCI disk where my original R1 Beta5 install was, overwriting the old install.

The installation succeeded without any issue, and I'm able to boot the installation without issues as well. Will be testing a bit further, but for this issue, everything's good.

I also tested booting x86_64 and it's working fine as well. I did not notice any regression there.

Thanks for fixing the issue. :-)

[korli]

thanks for testing. waddlesplash, might be a good idea to backport hrev58277 to r1beta5.

[waddlesplash]

I don't know if that would make much difference, considering most users will try to install from the beta build itself, which of course won't have the fix.

I applied another fix in hrev58280 to the SCSI bus manager, to make it respect the "high address" for requests besides DMA I/O. This should fix the addresses being passed to the driver being above the 32-bit boundary, and may be important for any hardware that really needs 32-bit addresses.

[korli]

It's common to install on NVME disks, and access AHCI disks...

[waddlesplash]

OK, backported.