Hot answers tagged

20

For some reason this is not documented on the Qemu 2.12.50 User Doc and I had to learn what I learned from this guy They mention -device usb-host,hostbus=bus,hostaddr=addr Pass through the host device identified by bus and addr -device usb-host,vendorid=vendor,productid=product Pass through the host device identified by vendor and product ID But they don'...


5

If I read correctly https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/usb/core/hub.c#n2030 (code for a function called choose_devnum), it may wrap far earlier than that, at value 127 in fact, and then going back to 1: /* Try to allocate the next devnum beginning at * bus->devnum_next. */ devnum = ...


4

The important part of your logs is Oct 11 04:36:07 username kernel: [355197.644022] usb 1-4: reset high-speed USB device number 20 using ehci-pci Oct 11 04:36:22 username kernel: [355212.730110] usb 1-4: device descriptor read/64, error -110 Oct 11 04:36:37 username kernel: [355227.919922] usb 1-4: device descriptor read/64, error -110 The communication ...


4

The line is disappearing because of the read line invocation, not AWK. I would go about this differently: lsusb -d 1234:a1b1 | while read _ bus _ device _; do sudo ./usbreset "/dev/bus/usb/${bus}/${device%:}" done This uses lsusb’s own ability to filter devices, then reads the bus and device identifiers into the corresponding variables, and gives the ...


3

The answer to your question depends somewhat on what mechanism will be used to trigger the script. Assuming that the script is called from some kind of backup program which is not immediately called when the USB device is attached (as would be the case if you trigger it from a udev rule, for example), then you can use udevadm info to gather all information ...


3

You can use udev: # /etc/udev/rules.d/<priority>-<name>.rules ACTION=="add", BUS="usb", SYSFS{serial}="<serial-number>", NAME="<name>", RUN="/your/xrandr/script" (e.g. <priority> might be 50 and <name> docked-monitor) Where the SYSFS and NAME settings come from lsusb. Other options to target the particular device (your ...


3

Running update-usbids by default isn’t an option because users don’t necessarily want their systems to “phone home” in any way (which update-usbids does, even if the download URL is currently trustworthy), and Debian avoids configuring them to do so. I imagine the package maintainer didn’t think of uploading a package with an updated list of ids before the ...


3

This drive isn't a USB device, but a SATA device which is accessed via the Genesys bridge (which is a USB device). Since it isn't itself a USB device, it doesn't show up in lsusb's output. USB thumb drives are USB devices without bridges (well, usually), so they do show up as-is on the USB bus and in lsusb's output.


2

lsusb may try to open the USB device as O_RDWR (read/write mode) and your user might not have the rights to do this (some error message "Couldn't open device, some information will be missing" should be inbetween the output, if so). Started as root lsusb should also be able to output the whole iSerial value.


2

After a bit more testing, I found that any USB 3 device plugged into a USB 3 slot was mapped to BUS 4. Any USB 2 device plugged into any USB 3 slot was mapped to BUS 3. However any USB 3 device plugged into a USB 2 slot was mapped to BUS 3. Seems that the LCD determines the BUS.


2

The USB3 standard brought the SuperSpeed mode, with new cables and connectors. Your bus 4 covers the SuperSpeed mode, which uses an entirely different set of wires in the USB cables. So as the higher-speed mode is physically separate from the old USB wiring, it makes sense for it to appear as a separate bus altogether. That leaves buses 1 and 2. They are ...


1

One of possible causes of this behavior is corrupted USB drive firmware. I have one such device (with Chipsbank controller) and it can be hard to recover – the drive essentially stops working and needs reflashing the firmware. Tools for doing that can be usually obtained only from some dubious sources.


1

Go back from number encoding of the device tree. For example, my webcam is at /sys/bus/usb/devices/3-1.1.2, which means it sits on bus 3, port 1 of the root hub of thus bus, port 1 of a hub below the root hub, and port of another hub of the last one. Or with lsusb -t: $ lsusb -t /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M /: Bus 03....


1

@StephenKitt's shell loop is fine in this case since efficiency probably isn't an issue and the input format is well known and simple and you're not just manipulating text (see why-is-using-a-shell-loop-to-process-text-considered-bad-practice) but another option without writing a loop would presumably be: lsusb -d '1234:a1b1' | awk -F'[ :]' '{printf "/...


1

The error message you're seeing is from a low-level USB failure, the basic USB protocol hasn't been completed — so Linux probably doesn't even know the idVendor/idProduct yet. That's also why lsusb isn't showing it, it hasn't really connected yet. The first odd thing here is that it has a USB A port, normally that's on the computer/"host" side (and B is on ...


1

yes This is a limitation of the Intel xHCI chipset used on the motherboard. Specifically, most of these chips limit the number of "devices" to 32. But a single physical thing like a camera may appear to the USB controller chip as multiple "devices". Plus each hub counts as at least 1 "device" so you can easily run into this limit much earlier than you ...


1

You would have to program the ATSAMD21G18 chip on the board to actually present a valid USB ACM interface, with all the necessary USB descriptors to identify it as such. Then it would be automatically identified as a /dev/ttyACM* device. Note that the ACM interface was originally designed for PSTN modems, and operating systems and modem configuration tools ...


1

Yes, see for example the output from lsusb -t on my system: /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=...


1

Each USB bus has a certain transport bandwidth, and if you max out that bandwidth, two devices on the same bus will have to share it, slowing down each of them, while two devices on different busses with separate root controllers won't have to share it. So the answer is: it depends. Do you ever use both HDDs at once? What's the maximum I/O speed of the ...


1

The xHCI controller has actually two buses in one. The superspeed bus: /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M ... and the traditional USB2 one: /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M Note that both are using the xhci_hcd driver. This is probably to minimize the interference of older, slower ...


1

There are lots of different USB devices in general (keyboard, mice, webcams, ...). lsusb deals with the connected devices on the USB protocol level. Some USB device are storage devices (USB sticks, USB harddisks, ...). They understand a different protocol (more or less SCSI) on top of the USB protocol. Within this protocol, an USB storage device has a ...


1

You can try USBdetach : ./usbdetach -v -p /dev/ttyUSBx There is brief explanation given on this blog you can refer to that page for more information.


1

If you are on a distribution using BusyBox, this can be caused by that you are using Busybox' lsusb rather than the one from usbutils (or at least so it was on my Alpine/postmarketOS installation). In such cases you can resolve this by installing usbutils and using its lsusb instead of the one from BusyBox.


1

It's probably a hardware issue on the machine, especially if this intermittent behavior was seen on it with Windows installed. Here's a few things you could try: Try some other USB devices, particularly flash drives while doing some file transfers. The keyboard is probably fine, but this would be another confirmation. When you plug in a usb device, you can ...


1

Kernel does not decide the bInterfaceProtocol. The value is received from the connected USB device. A variety of protocols are supported HID devices. The bInterfaceProtocol member of an Interface descriptor only has meaning if the bInterfaceSubClass member declares that the device supports a boot interface, otherwise it is 0. Check USB Device Class ...


1

The label is user set, or can be when the filesystem on the USB drive is formatted or after the fact. Use the lsusb -v ....


1

I had a similar problem but my usb hardware was a USB external hard drive (Eagle Consus with a Western Digital PATA hard drive). To resolve, I changed the hard drive's jumper setting to slave. In my case the jumper setting was set to master. Good luck.


1

If you use the dmesg command, it will show you where (dev/sda, dev/sdb etcetera) the device "is". There is a pretty decent guide here. It is for SUSE, but should apply to all distributions.


1

Try creating a UDEV rule under /etc/udev/rules.d/ So create a rules file /etc/udev/rules.d/test.rules then add this in there: ACTION=="add", ATTRS{idVendor}=="0951", ATTRS{idProduct}=="1666", SYMLINK+="Earls-Kingston-Thumbdrive" Restart UDEV by running sudo /etc/init.d/udev restart Remove and plug in the thumb drive and now you should have UDEV detect ...


1

According to strace lsof opens device files with read and write permissions: open("/dev/bus/usb/003/001", O_RDWR) = -1 EACCES (Permission denied) You can use capability CAP_DAC_OVERRIDE to give root's power to read and write any file in a system only to lsusb utility runned by specific user. This answer provides general instructions how to set up ...


Only top voted, non community-wiki answers of a minimum length are eligible