Changes between Initial Version and Version 1 of Ticket #11207, comment 6
- Timestamp:
- Feb 20, 2013 9:37:31 AM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #11207, comment 6
initial v1 3 3 Please don't hit me too hard if I get any of the following wrong. ;) 4 4 5 1)that (the pUrbLnx pointer being NULL) happens when resetting multiple bluetooth devices concurrently via hciconfig hci# reset. I've never seen it occur when not deliberately trying to break it. As I can't do this test without the patch, it's hard to determine if I've introduced a new problem or exposed a previously hidden one. :/5 1. that (the pUrbLnx pointer being NULL) happens when resetting multiple bluetooth devices concurrently via hciconfig hci# reset. I've never seen it occur when not deliberately trying to break it. As I can't do this test without the patch, it's hard to determine if I've introduced a new problem or exposed a previously hidden one. :/ 6 6 7 2) As far as I can tell, the existing cancellation code is called: 8 when the controller is disabled but there are outstanding requests 7 2. As far as I can tell, the existing cancellation code is called: 8 * when the controller is disabled but there are outstanding requests 9 * when a BULK endpoint is set ED_HWINFO_SKIP 9 10 10 when a BULK endpoint is set ED_HWINFO_SKIP11 The first condition won't occur very often at all if there are multiple devices plugged into the virtual controller, since if one device is up and running the controller won't be disabled in response to bringing another device down. 11 12 12 the first condition won't occur very often at all if there are multiple devices plugged into the virtual controller, since if one device is up and running the controller won't be disabled in response to bringing another device down.13 The second condition is extremely timing dependent as explained in 4 below. 13 14 14 the second condition is extremely timing dependent as explained in 4 below.15 I had thought by performing my cancellations before either of these conditions are tested that ohciTdInFlightUrb(pOhci, TdAddr) would return NULL, because the cancelled URBs are no longer in flight... I could be wrong. 15 16 16 I had thought by performing my cancellations before either of these conditions are tested that ohciTdInFlightUrb(pOhci, TdAddr) would return NULL, because the cancelled URBs are no longer in flight... I could be wrong.17 3. It's not just interrupt URBs that aren't properly cancelled. Bulk ones aren't always cancelled correctly as well. If two devices are connected and one is brought down, the bulk URB cancellation code doesn't trigger. 17 18 18 3) It's not just interrupt URBs that aren't properly cancelled. Bulk ones aren't always cancelled correctly as well. If two devices are connected and one is brought down, the bulk URB cancellation code doesn't trigger. 19 20 4) If I understand correctly how this stuff works (in a linux guest OS), ED_HWINFO_SKIP bit is set for the endpoint, but the OHCI emulator doesn't usually see it. It's set on an endpoint just prior to removing it from shared memory with the device. Once it's actually removed, it's simply not there anymore, and the emulator doesn't notice that it's missing. 21 19 4. If I understand correctly how this stuff works (in a linux guest OS), ED_HWINFO_SKIP bit is set for the endpoint, but the OHCI emulator doesn't usually see it. It's set on an endpoint just prior to removing it from shared memory with the device. Once it's actually removed, it's simply not there anymore, and the emulator doesn't notice that it's missing. 22 20 23 21 So I think the root problem is that there are still orphaned URBs that have been sent by vbox to the host usbdevfs driver, but they don't have associated endpoint descriptors attached to an OHCI device on the guest OS anymore.
