Cannot find disk in AHCI mode

[dsjonny]

I have Intel DH61AG board with Kingston mSATA SSD drive. Haiku can find this drive only if I change the SATA mode to IDE. In AHCI mode it cannot find the disk.

The chipset is H61. I do not know what information need to provide in this case. I checked the tickets, and I did not found a ticket width "disk not found in AHCI mode". Not some partition not found, and not a boot problem. Primary I use USB drive for Haiku, and the SATA SSD disk drive is only visible in IDE mode (as SCSI disk).

[anevilyak]

Duplicate of #8241.

[anevilyak]

Erm, misread that one. Looks possibly related to #8533 though.

[dsjonny]

I got some new info (I have booted Haiku from USB, and set the SATA mode in BIOS to AHCI):

device Mass storage controller (SATA controller, AHCI 1.0) [1|6|1]
  vendor 8086: Intel Corporation
  device 1c02: 6 Series/C200 Series Chipset Family SATA AHCI Controller

[dsjonny]

It's strange (for me): in AHCI mode when I boot Haiku from USB, I enter the boot menu and I see the Haiku installed to the SSD. I can select it, and when I continue the boot process, than at the 4th icon I got Kernel panic: boot disk not found, and some other lines. I tried to use my keyboard, but that not works in KDL (USB), so I cannot provide detailed info, but I will try to take a photo, and I will attach here...

[dsjonny]

I have attached the images:

• BIOS.jpg > the BIOS settings
• boot.jpg > selecting between USB and installed Haiku
• KDL.jpg > what's the kernel output
• logo.jpg > here stop the boot

And it is not clear for me why the keyboard not works, because the USB is usable: the USB drive looks like working. And before I got this KDL message, the USB looks like "reset".

I hope this info may help something...

[axeld]

The boot loader does use the BIOS to locate and load from the drive. However, the OS cannot do this anymore: it actually has to find out from which BIOS drive the boot loader booted in order to be able to load the correct installation. Maybe the AHCI driver does not work on your hardware for whatever reason (or does not detect it correctly).

USB does not work in the kernel debugger in general, as it is interrupt driven. There actually is code to make it work in the KDL via polling instead of using interrupts, but this will only work if you enter KDL deliberately once -- and you do not have the possibility to do so.

You may want to check the boot loader if it can find the logs from a previous boot in RAM (ie. directly after reboot); it can write them to a USB stick (it must be FAT formatted). Please refer to ​http://dev.haiku-os.org/wiki/ReportingBugs#Syslog.

[dsjonny]

I have attached 2 syslog output to the ticket. The SYSLOG00.TXT is the output when I want to boot from the installed Haiku on SSD, and the SYSLOG01.TXT is when I boot from USB (with the same SATA mode). I hope the second may contains more information, because in the first case (when boot from SSD) there is info only until the system try to find AHCI devices (as I understand). In the SYSLOG01.TXT this is at the line 544.

I hope you will find something useful info in the logs.

[marcusoverhagen]

please test hrev44627

[dsjonny]

Maybe I cannot test it:

"Since we're in release mode, the @nightly-* images from "master" are

suspended. In their place are the @alpha-* images from the r1alpha4 branch. This is how it was handled in the previous releases."

(Info from mmadia)

[dsjonny]

Can you add this update to the aplha images too?

[leavengood]

I will add it to the alpha branch tonight.

[anevilyak]

Just FYI, since Marcus was worried about this, the changes don't seem to cause any regressions on my previously working AHCI controller.

[leavengood]

I'm sorry but I did not yet find the time to boot up my Linux machine to merge this into the alpha branch. Haiku does not yet build on my MacBook (where I spend most of my computer time currently), so I did not want to merge this on it since I can't properly test.

I will try to find time for this in the next 24 hours but I have work projects and my wife is off work tomorrow, and both of those tend to keep me busy!

[anevilyak]

Replying to dsjonny:

Can you add this update to the aplha images too?

The changes have been added as of hrevr1alpha4-44600. Please retest with that one or newer.

[dsjonny]

Thank you! It is perfect now. And much more faster in this way the Haiku (in AHCI mode) than in IDE mode :) After the boot screen disappeared I got the complete desktop with Tracker, Deskbar loaded. (In IDE mode: I got the Desktop first, and than loaded the Tracker, and than the Deskbar).

So; Thank you again!

[dsjonny]

I found a strange thing: the device name looks like shuffled in the Device application. A also found it in the system log:

Here it is good... (KINGSTON SSM100S264G)

KERN: ahci: ahci_scan_bus, cookie 0x8280aa80
KERN: ahci: AHCIPort::ScsiTestUnitReady port 5
KERN: ahci: AHCIPort::ScsiInquiry port 5
KERN: ahci: lba 1, lba48 1, fUse48BitCommands 1, sectors 125045424, sectors48 125045424, size 64023257088
KERN: ahci: model number: KINGSTON SMS100S264G                    
KERN: ahci: serial number: 50026B721A122935    
KERN: ahci: firmware rev.: S5FAM011
KERN: ahci: trim support: yes
KERN: ahci: sg_memcpy phyAddr 0x6f5314, size 96
KERN: ahci: ahci_get_restrictions, cookie 0x8280aa80
KERN: ahci: AHCIPort::ScsiGetRestrictions port 5: isATAPI 0, noAutoSense 0, maxBlocks 65536

...

After some lines we got this: (IKGNTSNO S SM01S062G4)

KERN: device 0: /dev/disk/scsi/0/5/0/raw
KERN:   media status:      No error
KERN:   device flags:      2
KERN:   offset:            0
KERN:   size:          KERN:     64023257088 (61057.335 MB)
KERN:   content size:      64023257088
KERN:   block size:        512
KERN:   child count:       3
KERN:   index:             -1
KERN:   status:            0
KERN:   flags:             5
KERN:   volume:            -1
KERN:   disk system:       partitioning_systems/intel/map/v1
KERN:   name:              IKGNTSNO S SM01S062G4
KERN:   content name:      <NULL>
KERN:   type:              <NULL>
KERN:   content type:      Intel Partition Map
KERN:   params:            <NULL>
KERN:   content params:    <NULL>

[korli]

Replying to dsjonny:

I found a strange thing: the device name looks like shuffled in the Device application. A also found it in the system log:

This is another bug, probably related to #7926