Opened 14 years ago
Closed 14 years ago
#8809 closed defect (worksforme)
SATA AHCI broken in windows XP in 4.0.6
Reported by: | cschmidt | Owned by: | |
---|---|---|---|
Component: | virtual disk | Version: | VirtualBox 4.0.6 |
Keywords: | Cc: | ||
Guest type: | Windows | Host type: | Linux |
Description
After upgrading from VirtualBox 4.0.4 to 4.0.6 a Windows XP VM is unable to access a secondary drive (pops up the error message "S:\ is not accessible The Semaphore timeout period has expired"). The SATA driver used is Intel 82801HEM/HBM version 7.0.0.1020 from 12.0.2.2007.
A second disk seems to be affected worse than the primary, since I didn't encounter the Semaphore timeouts on C:, just on the second drive. However, accessing the c: drive also has latencies of minutes when e.g. starting a cmd window.
Attachments (1)
Change History (7)
by , 14 years ago
Attachment: | VBox.log.1 added |
---|
comment:1 by , 14 years ago
Component: | other → virtual disk |
---|
comment:2 by , 14 years ago
Are you 100% sure that this bug is related to upgrading from VBox 4.0.4 to VBox 4.0.6? I can't see any changes in the AHCI emulation which would explain this behavior.
follow-up: 4 comment:3 by , 14 years ago
Yes, after downgrading back to 4.0.4 the timeouts were gone. At the same time, there were no noticeable performance issues with linux guests using AHCI. Just that Windows XP.
comment:4 by , 14 years ago
Replying to cschmidt:
Yes, after downgrading back to 4.0.4 the timeouts were gone. At the same time, there were no noticeable performance issues with linux guests using AHCI. Just that Windows XP.
Would you mind trying again with VBox 4.0.6 to rule out any coincidence?
comment:5 by , 14 years ago
I'm sorry, I completely migrated away from virtualbox. I encountered a severe memory leak in this VM as well (700-800MB/day) which caused a kernel panic on the host once the VM hit 4GB, or every 2-3 days. This was completely impossible to sustain in a production environment.
comment:6 by , 14 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Already tried to reproduce this memory leak (copying files on shared folders, right?) but without success. Without a testcase we can't do much. Actually 4.0.6 fixed a memory leak.
Logfile for the problematic VM