https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244356
--- Comment #41 from Olivier Certner <olivier.free...@free.fr> --- Created attachment 214464 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=214464&action=edit Stick SD_64G: 3rd output of (multiple) `usbtest` (In reply to Hans Petter Selasky from comment #40) I tried various combinations. The first that seemed to work was indeed with negative tests off, including last HBA access. Unfortunately, I did it again immediately and it failed, so the choice of options alone does not guarantee success. I managed to get one read-only test to work correctly. And also, one Write Once, Read Only, just before the last test, seemed to have worked partially. Next, I'm going to test one of the other sticks I mentioned earlier, KT_32G, from another manufacturer, to see if I get such inconsistent behavior. While I can understand your advice, I will not buy that easily that so many different sticks with so many boards can fail in apparently the same way, especially given that: 1. As far as I remember, they work very well with other OSes (Windows, Linux). 2. Also, even when writing them with FreeBSD, how inconvenient it is because of the stalls, I never experienced any form of data corruption. 3. They are from different mainstream vendors with generally good reputation. (Yes, I know what reputation is worth, and that hardware manufacturers love not to follow standard exactly, even when they are arguably ambiguous.) 4. They were relatively expensive, at least not toy crap sometimes distributed at events. (Obviously, this is not a strong argument in itself, but adds to the rest.) Now, you're free to challenge that, in which case I'll be happy to prove additional points 1 & 2 by doing serious tests on different OSes, and also checksumming copied files, so that we can swap bad remembrance and impressions for hard facts. The apparently random nature of results with `usbtest` so far, assuming that I ran them correctly (don't see how I could not), could indicate that initialization at plug is not performed correctly. Which could be caused by a race of some sort at initialization, or some expected interaction simply missing, causing wild controller behavior on the stick. Yes, this is speculative, but maybe this will ring a bell to you if, e.g., you stumbled on such problems in the past. Even if general USB and umass are flawlessly implemented and following the standard, lots of manufacturers may not completely abide by that, and apparently other OSes are somewhat aware of this (again, to be confirmed with hard facts). Some months ago, I tried every possible USB quirk with `usbconfig`, but could not obtain any reliable improvement. I'm open to suggestions to redo some tests and log results. Finally, I noticed several backports to USB to 12 after r355888. Do you think that any of them could have an influence on the results? I'm in particular wondering about r358873. I plan to test the latest stable/12, but this probably won't happen before next week. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
