I checked all the comments and duplicate bugs, and I saw several other occurrendes of 152d:2329. I did not see any of the other JMicron product IDs.
However, there are a fair number of reporters who didn't submit lsusb -v, thus were I can't say for sure whether it's the same piece of hardware. I have the feeling that there is another affected controller here, since Scott's original report didn't mention a JMicron controller anywhere.
To keep things in a manageable state, I dedicate this bug to the 152d:2329 device, where we have clear evidence and confirmation. Robert mentioned a workaround in comment 59 (blacklisting the controller in /lib/udev/rules.d/95-devkit-disks.rules and adding a check_sat_end label).
If you still have the resets even with that blacklisting (which will soon be the default), please open a new bug and include the output of "lsusb -vv". Thanks!
I checked all the comments and duplicate bugs, and I saw several other occurrendes of 152d:2329. I did not see any of the other JMicron product IDs.
However, there are a fair number of reporters who didn't submit lsusb -v, thus were I can't say for sure whether it's the same piece of hardware. I have the feeling that there is another affected controller here, since Scott's original report didn't mention a JMicron controller anywhere.
To keep things in a manageable state, I dedicate this bug to the 152d:2329 device, where we have clear evidence and confirmation. Robert mentioned a workaround in comment 59 (blacklisting the controller in /lib/udev/ rules.d/ 95-devkit- disks.rules and adding a check_sat_end label).
If you still have the resets even with that blacklisting (which will soon be the default), please open a new bug and include the output of "lsusb -vv". Thanks!