SATA disks not found after reboot into linux (ICH9 only)

[Mike Musterd]

Situation:

• I have a IDE hdd with a linux installation on it, as well as grub.
• I have a IDE cdrom with an image of windows XP on it.
• I have a SATA hdd with windows XP on it, or nothing

I want to boot the linux OS, which will determine if the windows XP partition is available and has booted correctly. If this is the case, a grub-reboot is issued to boot into windows XP once, otherwise the image is restored onto the HDD. If I reboot from windows XP, the linux OS should do the above again.

On an actual machine, the procedure works without a hitch.

However after a reboot from windows XP to linux (Start | Shut Down... | Restart) the linux suddenly can't find the SATA disks. dmesg has the following lines:

[    6.166426] ata1.00: qc timeout (cmd 0xec)
[    6.166426] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[    6.516437] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   16.517619] ata1.00: qc timeout (cmd 0xec)
[   16.517619] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[   16.517619] ata1: limiting SATA link speed to 1.5 Gbps
[   16.866406] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   46.866424] ata1.00: qc timeout (cmd 0xec)
[   46.866424] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[   47.216399] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   47.566424] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   52.566425] ata2.00: qc timeout (cmd 0xec)
[   52.566425] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[   52.916425] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[   62.916398] ata2.00: qc timeout (cmd 0xec)
[   62.916398] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[   62.916398] ata2: limiting SATA link speed to 1.5 Gbps
[   63.266424] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   93.266437] ata2.00: qc timeout (cmd 0xec)
[   93.266437] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[   93.616439] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)

Attached is the full vbox.log and the full dmesg as I have it.

[Mike Musterd]

vbox log

[Mike Musterd]

dmesg log

[Frank Mehnert]

Still relevant with VBox 4.0.6?

[Frank Mehnert]

No response, closing.

[Stefan de Konink]

This still happens in 4.1.6.

I am currently observing it using a 32bit kernel under a 64bit host system. Tried the variants such as smp kernel, no apic etc.

[Stefan de Konink]

Maybe good to mention, the system doesn't even (cold) boot up.

[Frank Mehnert]

Which host and which guest is that? Do you think this is a regression (did it work with older VirtualBox releases)?

[Stefan de Konink]

Host is amd64. Guest is a Linux 3.1.0 system. I first attemped the install with 4.1.4 which als resulted in this crash.

The strangest thing is that, it think it might be related to the Linux kernel itself. Because an older kernel is in fact booting.

[Stefan de Konink]

Guest is a 32bit system.

[Stefan de Konink]

Ok this is an interesting situation.

I have just found out that booting an SMP kernel with nosmp basically triggers this. My guess is that any non-smp kernel breaks.

[Stefan de Konink]

Klaus told me on IRC that an image would really help. I have put the OVA file online:

​http://stefan.konink.de/contrib/vbox/SATA%20Failure%20with%20nosmp.ova

It is really easy to see, just watch grub.

[michaln]

Don't use the ICH9 chipset. It is currently not compatible with the nosmp option. More specifically, if a guest doesn't use the I/O APIC, it's not going to work with ICH9.

[Stefan de Konink]

I am pretty sure I have tried to switch to the other chipset and see the same thing. Are you sure about this?

[Stefan de Konink]

Never mind, I just checked it. Switching Chipset works.

Could you please add a feature requests that explicitly notes the host system should user I/O APIC (and thus SMP) for Linux hosts to run this?

[michaln]

Not really... It's a bug in our ICH9 implementation. And the workaround is extremely simple - don't use the ICH9 emulation unless you know for a fact that you need it. There's a reason why it's marked as such in the GUI.

[michaln]

This same problem also affects OS/2 guests in a different and perhaps even less obvious manner (see #13562 for details).