AHCI Port Reset Without Clear Reason

[henky.ac]

Dear VBox Team.
We have problem VirtualBox do AHCI Port Reset per 60-62 days. The AHCI Port Reset does not preceded by any warnings nor errors.
The reset causes guest system cannot write to guest disk (VDI), and cannot recovered until we restart the VBox. So we do not have /var/log/messages after AHCI Port reset. Both our Guest and Host are Linux kernel 3.0.7.

Here are excerpt from guest /var/log/messages:
Apr 3 14:16:30 xts1 syslog-ng[1534]: Log statistics; .....
Apr 5 12:01:10 xts1 syslog-ng[1519]: syslog-ng starting up; version='2.0.9'

The guest does not write to system message until vbox restart on Apr 5th.

VBoxLog.3 is where AHCI port reset occurs after 1503 hours.
VBoxLog.2 is where we run our machine for 1380 hours without port reset.
VBoxLog.1 is AHCI port reset occurs after 41 hours , so if you accumulate from VBoxLog.2 starts it is about 1500 hours.

Does anybody can help?

Thank you all in advance.

[aeichner]

Hard to tell what might be going wrong from the available data. The log message about resetting a port can only mean that the guest tries to reset the port because it thinks that something has gone wrong and the port is in an unusable state. Normally this kind of behavior is triggered by I/O requests taking too much time because the host can't handle the I/O load but there are no additional entries in the log which indicate such a problem.
The only thing which might help to debug this issue further is to get the guests kernel log. You can configure a serial port for the VM to dump everything into a file and redirect the kernel messages to the virtual serial port so the guests kernel log is saved even if the virtual disk is not available.

[henky.ac]

Hi aiechner.
Thank you for your quick reply.
This thing happen again and we manage to redirect guest /var/log/message to another syslog server.
Here is the excerpt:

May 4 19:39:59 xts1 kernel: [1253246.812797] ata2.00: exception Emask 0x0 SAct 0x7fffffff SErr 0x0 action 0x6 frozen
May 4 19:39:59 xts1 kernel: [1253246.812811] ata2.00: failed command: WRITE FPDMA QUEUED
May 4 19:39:59 xts1 kernel: [1253246.812826] ata2.00: cmd 61/08:00:90:b9:29/00:00:02:00:00/40 tag 0 ncq 4096 out
May 4 19:39:59 xts1 kernel: [1253246.812833] res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
May 4 19:39:59 xts1 kernel: [1253246.812842] ata2.00: status: { DRDY }
May 4 19:39:59 xts1 kernel: [1253246.812850] ata2.00: failed command: WRITE FPDMA QUEUED
May 4 19:39:59 xts1 kernel: [1253246.812863] ata2.00: cmd 61/08:08:70:76:2c/00:00:02:00:00/40 tag 1 ncq 4096 out
May 4 19:39:59 xts1 kernel: [1253246.812869] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
May 4 19:39:59 xts1 kernel: [1253246.812878] ata2.00: status: { DRDY }
May 4 19:39:59 xts1 kernel: [1253246.812886] ata2.00: failed command: WRITE FPDMA QUEUED
May 4 21:32:25 xts1 syslog-ng[2283]: syslog-ng starting up; version='2.0.9'

From what I learn in linux 3.0.7 libata - ata_eh_link_report, this shows that there are 4096 bytes command wait in
in 2 ata queues that now frozen.

Do you have any further clue?

best regards,
henky

[_sly_]

Hi,

Looks like I'm facing the exact same problem.
I have opened this ticket on trac :
https://www.virtualbox.org/ticket/15374

Last "hung" occured a few days ago with virtualbox 5.0.20 on a guest with kernel 3.2.0-4-amd64 (debian 7.x's default)

If that's guest dependant, henky.ac did you found a guest kernel setting that would help mitigate/resolve this issue ?