FAT-fs (sda1): unable to read boot sector to mark fs as dirtyĪ side note on USB ID follows, and may not be particularly relevant, but could be of interest to some since it relates to how mature the driver detection might be:įYI, product ID 0bda is “Realtek” (not a surprise), and within Realtek, device 8156 is not fully described. This is likely unrelated, but is the system being shut down cleanly? I see this: Sudo lsusb -vvv -d 0bda:8156 2>&1 | tee log_verbose.txt I’d like to see a verbose “ lsusb” for this device in the case where it runs at the full USB3.1 speed (you’ll have to use or ignore the HUB based on whichever log shows “ 5000M” at the end of its description under “ lsusb -t”, but I don’t know yet what the HUB setup was): The log does not indicate how or why the device is continuously dropping and reconnecting (there is no disconnect log, only repeated connects). I’m not sure if signal actually contributes to that repeated line in dmesg logs, but it seems unlikely to be the primary cause. 1 speeds, while the tree view without underscore “ _” loses signal quality and drops back to USB2 speeds. The “log_lsusb_.txt” (with “ _” underscore) shows one fewer device than the other log, that being:īus 002 Device 004: ID 0bda:8156 Realtek Semiconductor Corp.Ĭan I verify which HUB is used for the “ lsusb” case with or without the underscore “ _”? The tree view with “ _” runs at USB3.1 gen. (but the second “dmesg_.txt” does seem to get further) What condition is different between the two dmesg logs? Can you describe what differs for the two log files? Both do show the same repeating (and definite error, despite not calling it an error) log line: cdc_ncm 1-2.3.1:2.0 usb0: 1000 mbit/s downlink 1000 mbit/s uplink Of “dmesg.txt” (no underscore “ _”) and “dmesg_.txt” (an underscore “ _” in log name) it looks like both show a difference in HUBs, so I’m not sure which one is which of those.
0 kommentar(er)
