On Fri, Dec 18, 2015 at 08:12:22PM +0000, edward wandasiewicz wrote:
As requested.
Thanks. It appears this particular device is being fully detected as a USB2 device (connection is detected, address is assigned, drive configuration is downloaded, and the drive is registered internally) before the controller/device negotiate a USB3 connection. Once the device is recognized as USB3, the controller disconnects it from USB2, but by that point SeaBIOS has already fully registered it and isn't even checking the connection status. The device is then fully detected as a USB3 device, which is why the duplicate shows up.
I don't have a good way to fix that. It's possible to add a delay to USB2 device detection on XHCI controllers to try and make sure they are really USB2 devices, but that isn't a great solution as it adds an unnecessary delay to all other drives (that behave properly).
In some of your other emails, you mention type-c cables and different behavior with different cables. The cabling choice has no impact on the software, so I wonder if one of the cables you have (or combination of cables) isn't fully insulated and if it could be causing a delay in USB3 negotiation. If it's possible to fix this with a different cable, that may be the easiest solution.
-Kevin
Kevin O'Connor wrote:
Once the device is recognized as USB3, the controller disconnects it from USB2, but by that point SeaBIOS has already fully registered it and isn't even checking the connection status. The device is then fully detected as a USB3 device, which is why the duplicate shows up.
I don't have a good way to fix that.
Would checking the connection status for each device after all devices have been registered be able to filter the USB2 device out?
//Peter
On Sat, Dec 19, 2015 at 12:11:59AM +0100, Peter Stuge wrote:
Kevin O'Connor wrote:
Once the device is recognized as USB3, the controller disconnects it from USB2, but by that point SeaBIOS has already fully registered it and isn't even checking the connection status. The device is then fully detected as a USB3 device, which is why the duplicate shows up.
I don't have a good way to fix that.
Would checking the connection status for each device after all devices have been registered be able to filter the USB2 device out?
Yes, but there isn't a way to "unregister" the drive once it's been registered. The alternative (and equivalent) is to not register the USB2 device until all other devices have been detected - this adds a delay to USB2 device detection and I'm leery of doing that.
-Kevin
Kevin O'Connor wrote:
Would checking the connection status for each device after all devices have been registered be able to filter the USB2 device out?
Yes, but there isn't a way to "unregister" the drive once it's been registered.
Oh - why not?
If this has to do with e.g. BBS then maybe first register internally during probing, then filter disconnected devices out, *then* register "for real" ?
//Peter
On Sat, Dec 19, 2015 at 12:52:15AM +0100, Peter Stuge wrote:
Kevin O'Connor wrote:
Would checking the connection status for each device after all devices have been registered be able to filter the USB2 device out?
Yes, but there isn't a way to "unregister" the drive once it's been registered.
Oh - why not?
If this has to do with e.g. BBS then maybe first register internally during probing, then filter disconnected devices out, *then* register "for real" ?
Doing that is equivalent (unless I've missed something) to delaying registration until detection completes on all other ports on that controller. That's the delay I'm leery of adding.
-Kevin
Kevin O'Connor wrote:
Would checking the connection status for each device after all devices have been registered be able to filter the USB2 device out?
Yes, but there isn't a way to "unregister" the drive once it's been registered.
Oh - why not?
If this has to do with e.g. BBS then maybe first register internally during probing, then filter disconnected devices out, *then* register "for real" ?
Doing that is equivalent (unless I've missed something) to delaying registration until detection completes on all other ports on that controller. That's the delay I'm leery of adding.
Hm - maybe I'm missing something?
Doesn't it effectively take the same amount of wall clock time?
Is your worry that by postponing registration some oddities could come up e.g. in option ROMs that also parse the boot device list?
I looked at the code - technically it seems straightforward to implement a boot_remove_hd(). Is that disallowed by the BBS?
//Peter
On Sat, Dec 19, 2015 at 01:11:34AM +0100, Peter Stuge wrote:
Kevin O'Connor wrote:
Would checking the connection status for each device after all devices have been registered be able to filter the USB2 device out?
Yes, but there isn't a way to "unregister" the drive once it's been registered.
Oh - why not?
If this has to do with e.g. BBS then maybe first register internally during probing, then filter disconnected devices out, *then* register "for real" ?
Doing that is equivalent (unless I've missed something) to delaying registration until detection completes on all other ports on that controller. That's the delay I'm leery of adding.
Hm - maybe I'm missing something?
Doesn't it effectively take the same amount of wall clock time?
Delaying registration vs unregistering would (I believe) take the same wall clock time.
If you're asking if current state vs unregistering/delaying would take the same wall time - thinking about that now, it might be true. I guess the implementaiton and how things like CONFIG_THREADS=n are handled would determine that.
Is your worry that by postponing registration some oddities could come up e.g. in option ROMs that also parse the boot device list?
No.
I looked at the code - technically it seems straightforward to implement a boot_remove_hd(). Is that disallowed by the BBS?
That's not my concern. I think it would be confusing to add and then remove. Simpler to only add when we know it's real.
-Kevin
Kevin O'Connor wrote:
Doesn't it effectively take the same amount of wall clock time?
..
If you're asking if current state vs unregistering/delaying would take the same wall time - thinking about that now, it might be true.
Right - that's what I meant. I think it will, because ..
I guess the implementaiton and how things like CONFIG_THREADS=n are handled would determine that.
.. by the time the menu is shown and/or SeaBIOS boots automatically there is only one thread running anyway, right?
(Or is this where I am missing something?)
Thanks
//Peter
On Sat, Dec 19, 2015 at 01:51:15AM +0100, Peter Stuge wrote:
Kevin O'Connor wrote:
Doesn't it effectively take the same amount of wall clock time?
..
If you're asking if current state vs unregistering/delaying would take the same wall time - thinking about that now, it might be true.
Right - that's what I meant. I think it will, because ..
I guess the implementaiton and how things like CONFIG_THREADS=n are handled would determine that.
.. by the time the menu is shown and/or SeaBIOS boots automatically there is only one thread running anyway, right?
(Or is this where I am missing something?)
Thinking about this further, USB hubs are the real issue. In theory, a hub could have the same issue of being detected initially as USB2 and then later as USB3. In this situation, delaying does fix the issue, but it adds more wall time as then one can't query the devices downstream of the hub until after the delay. Unregistration doesn't work well with hubs, because it's complicated to determine connectivity for devices downstream of a hub that's been removed, and because it would require different code for unregistration of mice and keyboards.
-Kevin
-
Kevin O'Connor -
Peter Stuge