USB re-scan
 

I have an embedded Linux system with a 4TB USB SSD attached. When the drive is plugged in while the system is running, everything is fine. The drive shows up in lsusb and fdisk -l, and I can mount it and write to it without issue.

When the drive is plugged in before the system is turned on, however, about 80% of the time it just vanishes when the system boots up. No trace of it in fdisk, lsusb, or /sys/bus/usb/devices. If I physically un/re-plug it, it's recognized and everything is fine.

I'm trying to figure out if there's a command I can run that will re-scan the USB bus to detect the drive without having to physically un/re-plug it, since that's not a realistic long-term solution.

I've tried lsusb, udevadm trigger, and unbind/rebinding the USB controller in /sys/bus/usb/drivers/usb, with no success.

I had usb weirdness years ago and eventually traced it to the chipset. Does it happen in all the usb ports or only particular ones? what is your chipset? Can you compare syslog or dmesg logs from a boot where the thing mounted successfully, and one where it didn't?

In my case, btw, 2 ports just didn't respond to the signals they received correctly. They had been quietly disabled in later chips, but I had an early version and had these 2 extra crazy ports. I was actually glad when that motherboard blew.

Moderator response
 

Moved: This thread is more suitable in <Linux - Embedded & Single-board computer> and has been moved accordingly to help your thread/question get the exposure it deserves.

It's an embedded system, so the USB controller is built into the CPU. I've only tried one of the USB ports because it's the only one that can handle a 1A draw, the others are limited to the standard USB 2.0 0.5A which doesn't work well for external drives. The CPU has a single USB 2.0 host port, the SBC has a built-in hub which splits it out to the 3 available host ports, so they should all be equivalent (other than one of them allowing up to 1.0A while the others cut off at 0.5A). I'll work on getting dmesg/syslog output for a successful vs an unsuccessful boot.

Today I did some experimentation though. When the system booted up with the drive attached, it didn't recognize it. I then soft rebooted 5 times (sudo reboot), and it didn't see the drive on any of them. I then pulled the power lead to the board to shut it off hard, then re-applied power, and on that boot the drive did show up properly. I can't help but think it might be some oddity in the USB->SATA bridge that's switching to low power/sleep mode when it's not mounted in a certain time window after power on. That could lead to intermittent behavior from a cold start, and consistent failure from a warm start, which is what we're seeing. Again that brings me back to some kind of USB re-scan command which might wake up any attached devices and get them talking.

Right, if you're into embedded, the chipset is a definite suspect, but you are probably able to work around the inadequacies.

I gather a reboot (No power removal) works, and power off doesn't. I don't like using a 1 amp usb port - I feel the standard 100mA should be sufficient and the drive might need it's own supply. Motherboards don't make good devices to have in your power supply.

There is usually a different bios behaviour for the poweroff & reboot scenarios, and it sounds like you're not rebooting the motherboard, and that's losing your disk. This can be traced to a signal in the usb registers for a new device not being inserted. I think you're into kernel patching to get around it. Are you sure the device is given sufficient time to unmount & degister before the reboot?

On reboots abd restarts:

I had this in detail on an electronics hardware mailing list years ago, where you could pick the brains of hardware experts and believe them, a startup is very different to a reboot, as everything is initiated fully, whereas a reboot might not even cycle the power to the usb drive.

I have 2 usb disk drives (not pen drives) and they have independent power supplies. One is 2A, one is 3A. Where are you going with 1A powering the drive and port? That will be dropping excess voltage across pcb traces, and you have so many possible hardware issues that could go wrong that you should get a separate psu.

Sorry for the lack of updates...

1A is not the problem. This is not an HDD, it's an SSD, there is no port for an external supply, just USB. If it can't run off of 1A, then it can't run off of USB 3, as USB 3 is limited at 0.9A. That also wouldn't explain why it works every time when hot-plugging it into the device, it only fails to come up on the occasional power cycle.

You have the reboot/poweroff behavior backwards. A reboot does not work, if it doesn't come up on power-on, a soft reboot does not bring it up either. If it does come up on power-on, a soft reboot also doesn't change anything, it still works after the reboot. It just seems to be hit or miss whether it shows up after a cold boot or not, but whether or not it does, a soft reboot doesn't change things.

I ended up running out of time diagnosing the problem, and I just got it running and then stuck the system on a large UPS to prevent power cycling. That held it for the ~3 weeks I needed it to run, and it's since been dismantled.

Member response
 

Hi,

You could get a powered Hub to source the drives so it does not load the systems USB.

Hope this helps.
Have fun & enjoy!
:hattip:

The 5V rail on that system is powered by a dedicated 4A supply. All it does is feed the USB rail, nothing else, so a <1A draw is fine. The 1A limit is a dedicated per-port current limiter to protect the system if a USB device short outs or otherwise misbehaves. Unless something draws >1A, it won't kick in and everything is nominal. As it's a USB 3 SSD with no auxiliary power supply, it has to draw <0.9A or it violates the spec and wouldn't work correctly on most/any host. I measured the draw anyway and it peaks around 0.5A with a steady-state draw of <0.1A.

Does anything show up in /var/log/kern.log or dmesg when there's a reboot? I had a udev issue like this for keyboard/mice on avlinux back when it was based on debian squeeze. Slapping on parts of udev from the next version (wheezy) seemed to make it work without replugging the USB. Probably not related, but something to look at. Not sure if it was udev, but udev (/lib/udev/) and stuff under /etc/X11/ was most of what I fiddled with when it "fixed" on me. You could also try unloading / reloading usb-storage, assuming nothing else is dependent on it like the boot drive. But something that could be used, if it works, via a script after a boot in terms of an automated work around.