https://bugzilla.kernel.org/show_bug.cgi?id=220491 --- Comment #26 from Paul Ausbeck (paula@xxxxxxxxxxxxxxxxxxx) --- Perhaps I should further explain another point. On the Samsung machine, when the disconnect/reconnect does not happen, which is most of the time, the device continues to function properly. Further, since the device number does not change, upstream actors continue to function without knowledge of resets and what not occurring down lower in the stack, so the associated filesystem does not have to be remounted and any userland applications with open file handles for the device do not have to be restarted. This situation where the disconnect/reconnect does not happen could be viewed as a success of the current usb_persist mechanism. What would be nice would be to extend the usb_persist mechanism so that the connection could be persisted across pseudo disconnect/reconnect. I think it would be a good idea to find out if a delay of some sort would have some utility against the problem on either or both of these machines. If someone would post and/or email me a code snippet that accomplishes such a delay and suggest where to place such a snippet, I have source build trees on both of these machines and could relatively easily test. A patch would also do but since the delay may need to be moved around to find the right location, we may as well start with the most portable delay code possible. I don't have much experience with linux kernel code but I do have significant software experience, including Microsoft Windows driver experience. I also think it may be useful to say again that the emb-qm77 machine may be the better machine serve canonically and therefore to focus on initially. I say this because the problem there is repeatable, the problem trace has the same form on every suspend/resume. The Samsung machine has an asynchronous character, the disconnect/reconnect may or may not happen, when it does happen the exact point in the trace where it happens may differ from one occurrence to another. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
