qemu -M 35 and ahci

[rlfnb]

Tried to start current master via qemu with -M q35 option.

`

`

First failure was at_wini not found, which is fine as Q35 does not longer use at_wini. Added as a boot parameter ahci=yes to make sure ahci driver takes over solves the first failure. But now, it fails after

Root device name is /dev/c0d0p0 /dev/c0d0p0: Device is not configured could not open device to fsck

Update:

I thought, I made some mistake with the qemu options and tried it with FreeBSD as well:

qemu-system-i386 -M q35 -m 512M -drive if=none,file=test.img,id=disk -device ide-hd,drive=disk -cdrom FreeBSD-11.0-RELEASE-i386-bootonly.iso Everything's working like expected, so I tried:

qemu-system-i386 -M q35 -m 512M -drive if=none,file=test.img,id=disk -device ide-hd,drive=disk -cdrom minix_R3.4.0rc6-d5e4fc0.iso and after selecting the AHCI option in boot menu it fails with:

Trying /dev/c1d4 Not found. No CD found

Any idea, why it fails with qemu and the Q35 chipset?

[boricj]

Try booting with ahci_verbose=n (1 <= n <= 4) on the kernel command line so that debugging information for AHCI is printed.

If there's too much data, try also console=tty00 on the kernel command line and -serial stdio on the QEMU command line to print it on the terminal.

Regarding your update: while MINIX can use multiple controllers at the same time, the boot menu won't start both ATA and AHCI drivers. Thus, you need to boot the CD as usual and then start the AHCI driver to perform the installation (minix-service -c up /service/ahci -dev /dev/c1d0 -label ahci_0 -args instance=0 or something like that).

[rlfnb]

from my POV, AHCI should be already started, if im selecting (AHCI) as the second option when im booting the ISO?

[boricj]

Right now I don't have access to QEMU to check this, but taking a closer look at the command line it seems that:

• the ISO is attached to an AHCI controller (by default) ;
• the hard disk is attached to an IDE (ATA) controller.

So supposing I got it right this time and MINIX managed to boot in AHCI mode, then you'd need to start the at_wini driver by hand to access the hard disk.

However MINIX does not boot, so we need to look into that booting issue first before I confuse myself with ATA/AHCI any further.

[dcvmoole]

My first assessment is that qemu doesn't implement the AHCI spec properly (surprise..), in particular by not generating the PCS interrupt on which our driver implementation relies. If this is indeed the case, then it is likely possible to change the driver's current similar VirtualBox workaround (in port_timeout) to cover qemu's poor behavior as well, eg by checking the port signature for a value other than 0xFFFFFFFF instead of checking the PCS interrupt status.