Disconnect usb device linux

How to disconnect a specific USB device using musb_hdrc Linux driver?

First, i am new to the Linux USB stack and i am trying to understand it a little bit more in order to achieve the following result : i need to reconnect/disconnect a specific USB device because sometimes, tough not often, this device does not respond anymore and the only solution is to physically disconnect/reconnect the USB cable from the device.

On my board (AM33x Sitara), there are 2 usb controllers with musb-hdrc drivers bind to them :

From dmesg, i can see that my device is using driver musb-hdrc :

But looking at the device node, i cannot find this driver :

According to https://www.kernel.org/doc/Documentation/usb/power-management.txt, it is possible to suspend usb devices by doing : echo «auto» > /sys/bus/usb/devices/2-1.4/power/control and echo 0 > /sys/bus/usb/devices/2-1.4/power/autosuspend_delay_ms , plus unbinding the driver with echo «2-1.4:1.0» > /sys/bus/usb/devices/2-1.4:1.0/driver/unbind

I can see in dmesg that the device is disconnected, but for some reason the device is automatically bind just after that.

However, when i do the same procedure using musb-hdrc driver on musb-hdrc.1.auto and musb-hdrc.0.auto devices, it works well except that all my usb devices are turned off/on. and i would like to be more specific about the 2-1.4:1.0 usb devices interface.

An idea is to use the musb-hdrc driver to unbind the 2-1.4:1.0 usb device interface but it says that there is no such device.

I am a bit confused about that because i can see that the device is inside the device tree of musb-hdrc.1.auto :

Why the unbind command say that the device does not exist then ? Maybe there is a way to indicate, a kind of path inside the device tree to indicate to the driver that i want to unbind to this specific device interface 2-1.4:1.0 ?

Источник

Disconnect and reconnect ttyUSB0 programmatically in Linux

Trying to solve this problem (ttyUSB0 that works properly than stop working after about 1hr)I’m thinking on if disconnecting and reconnecting the usb device could be a good fix.

So, it is possibile to cut down power to the USB device and repower it programmatically (bash)?

On am335x, kernel 3.2.0, ubuntu core armhf.

At the moment I need a complete power cycle to have ttyUSB0 back.

2 Answers 2

This is the solution:

Find the identity of your usb device.

So 1-1:1.1 is the identifier of my ttyUSB0 (it can be discovered also via dmesg ).

Then, disconnect the device (as root):

At this point I had the same device but with a different name, it was now ttyUSB1 instead of ttyUSB0. — To avoid this I added a new rule in /etc/udev/rules.d/ by creating a new file named 99-usb-serial.rules with this line:

where idVendor , idProduct and serial must be the values of your device. This rule will create a new device called sameName linked to the ttyUSB* device normally generated from the OS.

As @Robert Harvey Said,

You first need to find our driver that will help you ‘unplug and plug’ the usb. Type: ls /sys/bus/usb/drivers which should print something like this: btusb ftdi_sio hub usb usbfs usbhid usbserial_generic uvcvideo . These, are all the drivers for each usb device. Now, lets say mine is ftdi_sio , which is a device i use to program my arduino (atmega328p chip). I am not sure how Your/other usb devices name themselves there. Like, i dont know which of these is my mouse. Now, you can see the driver’s commands using: ls /sys/bus/usb/drivers/ftdi_sio/ , which will print something like: 1-4:1.0 bind module uevent unbind , Where 1-4:1.0 is the device’s characteristic code, and the bind and unbind command, which are the ‘plug’ and ‘unplug’ command respectively.

Now, if i want to unplug programatically the ftdi usb port, i will type: echo -n «1-4:1.0» > /sys/bus/usb/drivers/ftdi_sio/unbind and, to plug it again: echo -n «1-4:1.0» > /sys/bus/usb/drivers/ftdi_sio/bind

Now, we can combine all the commands together, with a ‘;’:

echo -n «1-4:1.0» > /sys/bus/usb/drivers/ftdi_sio/unbind ; echo -n «1-4:1.0» > /sys/bus/usb/drivers/ftdi_sio/bind

Linked

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

Site design / logo © 2022 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2022.11.3.43005

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

Eject USB drives / eject command

I know that the eject command can be used to eject almost any hardware component attached, but can it be used to eject USB drives?

Is it possible to eject USB drives and external HDD’s with the eject command?

11 Answers 11

Yes. For example:

Other answers here that indicate that you require mechanical ejection hardware are incorrect.

Unmounting is not the same thing as ejecting.

1. If you unmount a volume, you can immediately mount it back, because the underlying device is still available. In some situations, this could present a security risk. By ejecting the device, only a reset of the USB subsystem (e.g. a reboot) will reload the device.
2. By ejecting the device, you effectively disable any further access to the device. Only a reset of the USB subsystem (e.g. a reboot) will reload the device. Otherwise, you must physically disconnect the USB device and reconnect it in order to access it again.
3. Before ejecting, this command will unmount all volumes on the device that were mounted.
4. If volumes are in use, this command will fail as with unmount, except that some volumes might be unmounted and some volumes might remain mounted.

On Linux, eject will work, but will not really «finish the job» regarding USB rotating drives.

So first, you eject /dev/sdb (or umount everything).

And then, after proper unmounting, the best way to unplug a USB external hard-drive is:

This usually causes the drive to spin down gracefully.

Note: udisksctl might be a more «mainstream» tool, compared to udisks (the former is already installed on my Debian, the latter isn’t & has been criticised for unnecessary spin up/down).

Some details

udisksctl

The documentation states (about the power-off option):

Arranges for the drive to be safely removed and powered off. On the OS side this includes ensuring that no process is using the drive, then requesting that in-flight buffers and caches are committed to stable storage. The exact steps for powering off the drive depends on the drive itself and the interconnect used. For drives connected through USB, the effect is that the USB device will be deconfigured followed by disabling the upstream hub port it is connected to.

Note that as some physical devices contain multiple drives (for example 4-in-1 flash card reader USB devices) powering off one drive may affect other drives. As such there are not a lot of guarantees associated with performing this action. Usually the effect is that the drive disappears as if it was unplugged.

udisks (deprecated?)

• sends SCSI sync-cache command,
• sends SCSI stop command,
• unbinds the usb-storage kernel driver,
• suspends the USB device (power),
• logically disables/removes it from its USB port.

This process is close to the manual procedure that is suggested here. Initial answer was on askubuntu.

Источник

Thread: Disconnect USB device (or disable USB) before shut down/power off

Thread Tools

Display

Disconnect USB device (or disable USB) before shut down/power off

I’m completely new to Ubuntu/Linux, but after using XP (workstation), Vista (business notebook) and Mac OS X (private notebook) I thought it would be nice to have a media center PC with Ubuntu/XBMC
So I bought a Antec Case with integrated Soundgraph iMON LCD/IR device, an nVidia ION 330 mb, a harddrive and some memory and started to install Ubuntu 9.04 Desktop with XBMC-standalone.

After I spend the weekend with the terminal window, my big three problems (alsa, lirc, lcdproc) a solved — except one issue:
The Soundgraph LCD is connected directly to the computers power supply (to turn it on via IR, i think) which means the backlight is also on when the computer is turned off.
When you use the iMON Software under Windows, the software will switch off the backlight before windows is shutting down. It stays off until you power on the computer again.

So I tried the same with the LCD server. you have the option to turn the backlight off when LCDd is not running — and this works. So if I use «/etc/init.d/lcdd stop» the backlight switches off. The same will happen when you shut down the computer — BUT: approx. 1 second before the computer is powering down, the backlight will be switched on. I figured out that this will not occur when I unplug the USB cable after the backlight has been switched off — and it will not turn on again if I plug it in again (until I start the computer — which is good!)

I think it could be a possible solution to disconnect the USB LCD device in ubuntu right after the LCDd has been killed by /etc/init.d/lcdd stop command. Or, if this does not work, to disable the USB (ports) completly when shutting down (and enabling it again when booting).
If this would be possible it could be easily added to the stop script (I think. ). Any suggestions?

And in addition (or as a workaround):
Is it possible to stop LCDd for suspend/hibernation? (As the LCD will have the backlight on in this modes — because LCDd is not stopped)
Of course LCDd has then to be started again when the computer is powered on.

Источник

Linux Mint Forums

Welcome to the Linux Mint forums!

[SOLVED] USB ports randomly disconnecting until reboot on Linux Mint 20.1

[SOLVED] USB ports randomly disconnecting until reboot on Linux Mint 20.1

Post by togamid » Mon Mar 15, 2021 3:24 am

Hello,
on my Tuxedo Pulse 15 with Linux Mint 20.1, the whole USB2.0 branch randomly disconnects every few hours to a day, including the internal camera and the to USB2.0 ports. The USB3.0 port continues to work fine when that happens.I’ve already tried disabling autosuspend as suggested in viewtopic.php?f=49&t=287775&p=1593287, which seems to have prolonged the time it takes for the problem to appear, but didn’t get rid of it.
The problem has previously occurred under Ubuntu, but seems to happen at a much lower rate if it still happens at all (didn’t occur during 3 days under Ubuntu).
The USB ports work fine again after a reboot.

Thanks for your help.
togamid

Re: USB ports randomly disconnecting until reboot on Linux Mint 20.1

Post by SMG » Mon Mar 15, 2021 7:09 pm

You are not the only one seeing this issue Bluetooth and Webcam problem. That person is running Pop!OS 20.04 on an ASUS laptop and the messages are almost exactly the same as yours.

Does this seem to happen more often after using the webcam for extended periods? Maybe a heat related issue?

Re: USB ports randomly disconnecting until reboot on Linux Mint 20.1

Post by absque fenestris » Mon Mar 15, 2021 10:16 pm

Re: USB ports randomly disconnecting until reboot on Linux Mint 20.1

Post by togamid » Tue Mar 16, 2021 5:35 am

You are not the only one seeing this issue Bluetooth and Webcam problem. That person is running Pop!OS 20.04 on an ASUS laptop and the messages are almost exactly the same as yours.

Does this seem to happen more often after using the webcam for extended periods? Maybe a heat related issue?

Re: USB ports randomly disconnecting until reboot on Linux Mint 20.1

Post by SMG » Tue Mar 16, 2021 9:11 am

Yours has AMD Ryzen 7 4800H, ThinkPad L15 Gen1 has AMD Ryzen 7 PRO 4750U, Asus UM425I has an AMD Ryzen 4000 series processor, and I’m going to take a wild guess and say the ThinkPad E15 Gen 2 probably also has a Ryzen 4000 series, so I would consider the hardware to be similar rather than different.

Was your test with Ubuntu using the same exact kernel you were using with Mint?

Does your BIOS/UEFI have any settings available for xhci_hcd? I’m guessing it may not, but it’s worth a check.

Re: USB ports randomly disconnecting until reboot on Linux Mint 20.1

Post by togamid » Tue Mar 16, 2021 12:37 pm

Re: USB ports randomly disconnecting until reboot on Linux Mint 20.1

Post by SMG » Tue Mar 16, 2021 1:03 pm

Yes, it is possible to install a 5.6-oem kernel on Linux Mint. I know of at least one person using that kernel because of some hardware issues, but I was not on the thread where he installed it. Here is the portion of that other thread where they discuss how to install the 5.6-oem kernel.

Keep in mind that is a lower number kernel than your current one, so Mint will automatically boot into 5.8. To boot into the 5.6, you will need to boot into grub and then go to Advanced Options to select the 5.6 kernel for booting.

The other thing to keep in mind is that it’s my understanding that at least kernel 5.7.1 is needed in order to get the necessary graphics driver for Renoir. I do not know if there is something special about the 5.6-oem kernel that it has the driver. Were you running in software rendering mode when using Ubuntu?

Re: USB ports randomly disconnecting until reboot on Linux Mint 20.1

Post by bodge99 » Tue Mar 16, 2021 1:43 pm

I’m seeing something similar with multiple systemd distros (including Mint) on the same hardware. Intel i5 CPU and the same 5.11.4 kernel.

USB3 ports disappearing during large file transfers (multiple

File copies are perfectly fine using Slackware, Devuan and Artix Linux.

Re: USB ports randomly disconnecting until reboot on Linux Mint 20.1

Post by SMG » Tue Mar 16, 2021 1:48 pm

The issues seen here are on AMD Ryzen 4000 series and the OP is running the 5.8 kernel. That’s not the same hardware or the same kernel as what you posted.

Additionally, the issue is with USB 2.0 ports disappearing. The 3.0 ports are fine.

Re: USB ports randomly disconnecting until reboot on Linux Mint 20.1

Post by hglee » Tue Mar 16, 2021 3:01 pm

There’s no need to regress to kernel 5.6 in order to gain the benefits of the OEM kernel. (That OEM kernel 5.6 was needed for special audio firmware.)

Install the Hardware Enablement (HWE) extension. You’ll keep kernel 5.8, which is a definite benefit to your Ryzen / Renoir GPU.

Open a Terminal (Ctrl-Alt-T), then copy-and-paste the following command.

The HWE stack pulls in new hardware support that gets added to more recent and future releases of the kernel. It’s intended to prevent the LTS (Long Term Support) editions of the kernel from falling too far behind the most recent releases for new hardware platforms.

PS: Confirm that Secure Boot is disabled in your BIOS.

Re: USB ports randomly disconnecting until reboot on Linux Mint 20.1

Post by SMG » Tue Mar 16, 2021 3:20 pm

The point of using the 5.6-oem kernel was because that was what the OP was using with Ubuntu when not experiencing these issues. The idea was to do an apples-to-apples comparison between Ubuntu and Mint by using the same kernel in both. That would determine if the difference was the kernel or some difference between the two operating systems. Tuxedo supports Ubuntu (and probably with the 5.6-oem kernel) and not Mint.

Having explained the philosophy behind the suggestion, it is possible your suggestion might help with the issue.

Re: USB ports randomly disconnecting until reboot on Linux Mint 20.1

Post by JeffF73 » Wed Mar 17, 2021 2:58 pm

I have had and am now facing this issue with the USB’s randomly disonnecting again. I had my system working great for many months without seeing any of this until last week with a possible update and etc. This issue with the USB’s has been around since Ryzen and isn’t on any specific version CPU and etc of Ryzen.

I am trying out the disabling autosuspend as well as I am now in the process of retracing my steps to prevent the USB disconnects and etc. Here is were I am now. I always follow ‘Easy Linux Tips Project’ pages and I came across this which is a step I remember following in the past few months (Especially Step 1 ‘PSU Idle Control’). https://easylinuxtipsproject.blogspot.c . .html#ID27 Step 1 in their ‘Fix system freezing trouble with AMD Ryzen CPU’s’ doesn’t just pertain to CPU’s and Freezes as it states. This can also prevent other issue across the system. It’s your choice if you wish to do Step II in their guide. but be sure to backup/timeshift prior.

I am now in the waiting stage to see how this pans out as a solution. I will update as soon I see any results.

Update: So far since I posted the above I decided to remove the disable ‘autosuspend’ and test out the PSU Idle Control on it’s own and allow the system to go idle and etc. Since then I haven’t seen any usb disconnects after performing the PSU Idle Control changes in the BIOS. My system has been running straight for 9 hours and 21 minutes. I have been working with my system as well as allow it to be idle. I will continue to test this and see if this continues to be true.

Источник