Hi,
I was able to try the 5.3.0 kernel from the PPA as stated above. It was a bit complicated, as I had to disable secure boot first, so it was good that I did not try it from remote (my wife would have killed me!).
In short: The problem persists. The ums-realtek driver does not work with this device ID. Same kernel messages, 3 retries to find the phantom device (sdb in my case) and always it gave up after timeout. After 3 tries the device is blocked completely.
This happened also after completely switching of system and disconnecting from power coord.
In short: The device ID added in the latest commit to ums-realtek does not work, so please revert it and also tell this upstream.
@Kai-Heng: When you committed that to upstream kernel, did you test this on a real device? To me it's completely un-understandable why to forcefully switch a device which works perfectly well with the default USB storage driver to a custom vendor-specific driver without any reason!
Hi,
I was able to try the 5.3.0 kernel from the PPA as stated above. It was a bit complicated, as I had to disable secure boot first, so it was good that I did not try it from remote (my wife would have killed me!).
In short: The problem persists. The ums-realtek driver does not work with this device ID. Same kernel messages, 3 retries to find the phantom device (sdb in my case) and always it gave up after timeout. After 3 tries the device is blocked completely.
This happened also after completely switching of system and disconnecting from power coord.
In short: The device ID added in the latest commit to ums-realtek does not work, so please revert it and also tell this upstream.
@Kai-Heng: When you committed that to upstream kernel, did you test this on a real device? To me it's completely un-understandable why to forcefully switch a device which works perfectly well with the default USB storage driver to a custom vendor-specific driver without any reason!