#5949: KDL: Could not read block 18110: bytesRead: -1, error: Operation timed out -----------------------------+---------------------------- Reporter: stippi | Owner: axeld Type: bug | Status: new Priority: normal | Milestone: R1 Component: System/Kernel | Version: R1/Development Resolution: | Keywords: Blocked By: | Blocking: Has a Patch: 0 | Platform: All -----------------------------+---------------------------- Comment (by mmlr): The updated log actually does bring news. The error that is printed is the status code returned from the USB stack. This is "No error" and means that from the USB stack side of things worked out well, i.e. the transfer did not fail per se. The other condition to trigger the error code path is that the reported transfer length does not match the scheduled/expected transfer length. This can be a problem on many levels. The actual length is the sum of all the lengths of each indivial packet sent/received by the USB bus driver, so it is possible that there is a bug causing this to be miscalculated, or USB packets might indeed not be scheduled properly at all. It is also possible that this is a defect in VirtualBox. It is common for emulated hardware to sometimes take shortcuts and not fully emulate a certain device which might lead to problems with "by the book" drivers like our EHCI one. It might also just be a bug that is only triggered by the pattern in which our EHCI driver does things that hasn't been uncovered yet due to other systems working differently. Since I have seen this particular combination of errors only reported with VirtualBox I tend in that direction. Generally the issues reported here are two different ones. The timeout is usually really just that, a timeout. It is usually caused by transfers being so large that they simply have to exceed the relatively short timeout. The timeout is static and doesn't take bus speed or bandwidth constraints into account. Hence you are almost guaranteed to run into it when transferring large files with USB 1.1 as it simply is too slow to ever make it within that timeout. It is also possible that if the bus is busy due to other devices, the transfer doesn't complete quickly enough. The issue of "sending or receiving of the data failed" as explained above, is different from the timeout. I would suggest opening a new ticket for that issue. Please attach the VirtualBox log files to that new ticket, they might indicate what's going on from the VirtualBox side. For example the EHCI driver might try something VirtualBox doesn't expect or it might do something plain buggy that hardware EHCI implementations just handle silently. -- Ticket URL: <http://dev.haiku-os.org/ticket/5949#comment:7> Haiku <http://dev.haiku-os.org> Haiku - the operating system.