5

So the basic issue is this: once the Pi Zero with g_mass_storage is booted up, as long as there is a power source for it (like a battery, so it won't shut off) I can plug it into any windows machine (or another Pi) and the volume pops right up. But on one computer, just one so far, it won't see the device unless it had been connected to and recognized by one other device previously. It seems as if some part of connecting the Pi to another computer changes... something, and lets the finicky machine see it.

Background:

My goal here is to create a gadget that connects to a network drive on my NAS, syncs it to the backing store for g_mass_storage, and then presents that file to a device as a USB drive. This works more or less fine for any windows computer I try it with (I am having some weirdness with copying files, but that's a matter for another question) but not for the important one.

I want this to make it easier to transfer files to a CNC Lathe (HAAS ST20SS), but the control unit is acting differently than any other computer I have tried, including another HAAS machine with a newer control system (DT2 CNC Mill). The "next gen" control on the Mill has no issue seeing the Pi as a storage device. None of the windows computers in the shop have any problems, and neither does another Pi.

I'm fairly sure the lathe controller is running some variant of Linux, but I'm not sure.

If I plug the Pi Zero into the lathe, it boots up fine, connects to Wi-Fi, and I can SSH into it. If I connect a power supply or battery to the power USB port, I can disconnect it from the lathe and it remain powered. I can boot up the lathe with it plugged in, I can unplug it and plug it back in, whatever. The lathe will not see it.

However, if I take it (without powering it off) and plug it into a PC or another Pi, or even the mill, it works perfectly. Then, if I bring it back to the lathe... no problem. It sees it, browses the file system, no problem. As long as the Pi is connected to any other computer (even tried it with a micro to USB-C cable to my Phone) once, that computer will see the drive, and it will work fine with the lathe until the Pi is rebooted.

Weirder still, my script that handles syncing files modprobe's g_mass_storage and removes it before mounting the file system internally to do the copy, then unmounts and modprobe's it back again to avoid corrupting anything by mounting the FS in two places at once. Resyncing will not break the lathes ability to see the drive, it will simply disappear momentarily and pop back up without issue. I would totally blame the lathe controller if it just couldn't figure out how to connect to a drive that was unmounted without being physically unplugged, but that isn't a problem, and mere physical unplugging doesn't solve the issue anyway.

Basically, once something recognizes the mass storage device, I can do anything I want with it with the lathe or any other computer and no problems. Until the Pi is restarted that is, at which point it loses something and won't work with the lathe again.

So what happens when I plug the Pi into a computer? What changes? It's as if the Pi isn't presenting itself as a mass storage device until after it connects to a regular computer, and whatever those computers do, the lathe doesn't.

[Edit: 1] More info:

I have been searching around for information, and found a few things that seem useful. First, if I run:

cat /sys/class/udc/20980000.usb/state

It returns not attached until I have modprobe'ed g_mass_storage and connected it to one of the working devices. After that, it reads configured until I remove the g_mass_storage mod, which returns it to not attached - connecting it to the Lathe before any other device doesn't change its state (still not attached).

The other thing I have found, is some odd log entries in /var/log/messages.

If I run:

sudo modprobe g_mass_storage file=/piusb.bin stall=0

The log gains the entries:

Jun 12 11:43:58 PiZERO kernel: [ 2224.624959] Mass Storage Function, version: 2009/09/11
Jun 12 11:43:58 PiZERO kernel: [ 2224.625003] LUN: removable file: (no medium)
Jun 12 11:43:58 PiZERO kernel: [ 2224.635460] LUN: file: /piusb.bin
Jun 12 11:43:58 PiZERO kernel: [ 2224.635500] Number of LUNs=1
Jun 12 11:43:58 PiZERO kernel: [ 2224.635778] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11
Jun 12 11:43:58 PiZERO kernel: [ 2224.635808] g_mass_storage gadget: userspace failed to provide iSerialNumber
Jun 12 11:43:58 PiZERO kernel: [ 2224.635822] g_mass_storage gadget: g_mass_storage ready
Jun 12 11:43:58 PiZERO kernel: [ 2224.638901] dwc2 20980000.usb: bound driver g_mass_storage

If I then connect a computer, it gains:

Jun 12 11:46:24 PiZERO kernel: [ 2370.203320] dwc2 20980000.usb: new device is high-speed
Jun 12 11:46:24 PiZERO kernel: [ 2370.283379] dwc2 20980000.usb: new device is high-speed
Jun 12 11:46:24 PiZERO kernel: [ 2370.348503] dwc2 20980000.usb: new address 5
Jun 12 11:46:24 PiZERO kernel: [ 2370.369774] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage

But after that, if I connected it again to another computer I get:

Jun 12 11:48:11 PiZERO kernel: [ 2477.974985] ------------[ cut here ]------------
Jun 12 11:48:11 PiZERO kernel: [ 2477.975182] WARNING: CPU: 0 PID: 0 at drivers/usb/dwc2/gadget.c:176 dwc2_hsotg_init_fifo+0x188/0x1a8 [dwc2]()
Jun 12 11:48:11 PiZERO kernel: [ 2477.975198] Modules linked in: g_mass_storage usb_f_mass_storage libcomposite arc4 ecb md4 md5 hmac nls_utf8 cifs bnep hci_uart btbcm bluetooth brcmfmac brcmutil cfg80211 snd_bcm2835 rfkill snd_pcm snd_timer snd dwc2 udc_core bcm2835_gpiomem bcm2835_wdt uio_pdrv_genirq uio fuse ipv6 [last unloaded: libcomposite]
Jun 12 11:48:11 PiZERO kernel: [ 2477.975334] CPU: 0 PID: 0 Comm: swapper Tainted: G        W       4.4.50+ #970
Jun 12 11:48:11 PiZERO kernel: [ 2477.975346] Hardware name: BCM2708
Jun 12 11:48:11 PiZERO kernel: [ 2477.975413] [<c0016d18>] (unwind_backtrace) from [<c0013c3c>] (show_stack+0x20/0x24)
Jun 12 11:48:11 PiZERO kernel: [ 2477.975452] [<c0013c3c>] (show_stack) from [<c02e49dc>] (dump_stack+0x20/0x28)
Jun 12 11:48:11 PiZERO kernel: [ 2477.975488] [<c02e49dc>] (dump_stack) from [<c0021f2c>] (warn_slowpath_common+0x8c/0xc4)
Jun 12 11:48:11 PiZERO kernel: [ 2477.975517] [<c0021f2c>] (warn_slowpath_common) from [<c0022020>] (warn_slowpath_null+0x2c/0x34)
Jun 12 11:48:11 PiZERO kernel: [ 2477.975630] [<c0022020>] (warn_slowpath_null) from [<bf0c7938>] (dwc2_hsotg_init_fifo+0x188/0x1a8 [dwc2])
Jun 12 11:48:11 PiZERO kernel: [ 2477.975796] [<bf0c7938>] (dwc2_hsotg_init_fifo [dwc2]) from [<bf0c94cc>] (dwc2_hsotg_core_init_disconnected+0x60/0x308 [dwc2])
Jun 12 11:48:11 PiZERO kernel: [ 2477.975952] [<bf0c94cc>] (dwc2_hsotg_core_init_disconnected [dwc2]) from [<bf0c9c74>] (dwc2_hsotg_irq+0x500/0x6dc [dwc2])
Jun 12 11:48:11 PiZERO kernel: [ 2477.976059] [<bf0c9c74>] (dwc2_hsotg_irq [dwc2]) from [<c005acf4>] (handle_irq_event_percpu+0x94/0x1f0)
Jun 12 11:48:11 PiZERO kernel: [ 2477.976092] [<c005acf4>] (handle_irq_event_percpu) from [<c005ae88>] (handle_irq_event+0x38/0x4c)
Jun 12 11:48:11 PiZERO kernel: [ 2477.976126] [<c005ae88>] (handle_irq_event) from [<c005dc14>] (handle_level_irq+0x9c/0x134)
Jun 12 11:48:11 PiZERO kernel: [ 2477.976154] [<c005dc14>] (handle_level_irq) from [<c005a368>] (generic_handle_irq+0x30/0x44)
Jun 12 11:48:11 PiZERO kernel: [ 2477.976182] [<c005a368>] (generic_handle_irq) from [<c005a600>] (__handle_domain_irq+0x58/0xb8)
Jun 12 11:48:11 PiZERO kernel: [ 2477.976216] [<c005a600>] (__handle_domain_irq) from [<c0010748>] (handle_IRQ+0x2c/0x30)
Jun 12 11:48:11 PiZERO kernel: [ 2477.976246] [<c0010748>] (handle_IRQ) from [<c000940c>] (bcm2835_handle_irq+0x3c/0x58)
Jun 12 11:48:11 PiZERO kernel: [ 2477.976281] [<c000940c>] (bcm2835_handle_irq) from [<c05768e4>] (__irq_svc+0x44/0x5c)
Jun 12 11:48:11 PiZERO kernel: [ 2477.976295] Exception stack(0xc0821f18 to 0xc0821f60)
Jun 12 11:48:11 PiZERO kernel: [ 2477.976311] 1f00:                                                       00000000 00000000
Jun 12 11:48:11 PiZERO kernel: [ 2477.976333] 1f20: 00000000 c0822f74 c088d5f0 c0820000 c08220ac 00000000 c0887d04 c0887268
Jun 12 11:48:11 PiZERO kernel: [ 2477.976355] 1f40: c0887268 c0821f74 c0821f68 c0821f68 c0010804 c0010808 60000013 ffffffff
Jun 12 11:48:11 PiZERO kernel: [ 2477.976385] [<c05768e4>] (__irq_svc) from [<c0010808>] (arch_cpu_idle+0x30/0x40)
Jun 12 11:48:11 PiZERO kernel: [ 2477.976425] [<c0010808>] (arch_cpu_idle) from [<c004d7ec>] (default_idle_call+0x34/0x48)
Jun 12 11:48:11 PiZERO kernel: [ 2477.976455] [<c004d7ec>] (default_idle_call) from [<c004d930>] (cpu_startup_entry+0x130/0x17c)
Jun 12 11:48:11 PiZERO kernel: [ 2477.976483] [<c004d930>] (cpu_startup_entry) from [<c05722e0>] (rest_init+0x6c/0x84)
Jun 12 11:48:11 PiZERO kernel: [ 2477.976521] [<c05722e0>] (rest_init) from [<c07c2ca0>] (start_kernel+0x358/0x3cc)
Jun 12 11:48:11 PiZERO kernel: [ 2477.976537] ---[ end trace f3f094dda548745c ]---
Jun 12 11:48:11 PiZERO kernel: [ 2477.989720] dwc2 20980000.usb: new device is high-speed
Jun 12 11:48:12 PiZERO kernel: [ 2478.069784] dwc2 20980000.usb: new device is high-speed
Jun 12 11:48:12 PiZERO kernel: [ 2478.134876] dwc2 20980000.usb: new address 6
Jun 12 11:48:12 PiZERO kernel: [ 2478.156147] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage

I also see a line like:

Jun 12 11:48:11 PiZERO rsyslogd-2007: action 'action 17' suspended, next retry is Mon Jun 12 11:48:41 2017 [try http://www.rsyslog.com/e/2007 ]

Every so often.

The other interesting thing of note, is that all the devices that work are being called "high speed" but if I connect the Lathe controller, it's "low speed" instead. I'm guessing that the port on the controller is USB 1.0, and this may be causing an issue. But it will work, after the Pi has gotten a chance to connect to another device.

Improve this question
10
  • Seeing as the issue only occurs with one PC opposed to all of them I'm inclined to believe the issue lies with that one PC. Some details of the exact Linux distribution it is running could be really useful to know. Also, does this issue happen with other USB devices?
    – Darth Vader ♦
    Jun 7, 2017 at 18:03
  • Not that I can tell, though this is the only USB device I have that needs to boot up before it works. The unfortunate thing, is that I can't do anything to change the lathe controller. So if at all possible, changing something on the Pi is necessary. Further, since the current way to make it work involves using a third machine, it seems likely that a solution could be found, by somehow emulating whatever the third machine is doing.
    – zeel
    Jun 7, 2017 at 18:07
  • Did you ever resolve this? I've got a very similiar issue connecting the PI to a digital picture frame via USB. The PI looks like a USB thumbdrive to every PC I connect it to, but the frame won't see it at all.
    – DarinH
    Jan 6, 2018 at 16:12
  • Ah... Looks like the trick was 1) use g_mass_storage and NOT g_multi 2) include the stall=0 arg 3) use this in your /etc/rc.local file (after creating the mountable Fat32 volume file, or course) /bin/sleep 5 /sbin/modprobe g_mass_storage file=/piusb.bin stall=0
    – DarinH
    Jan 6, 2018 at 16:16
  • hi, did anyone get a chance to figure this out?
    – kaushalop
    Apr 4, 2019 at 0:33

2 Answers 2

Reset to default
1

Sounds like you've got quite the project!! 😆

If my understanding is correct, the RPi zero isn't reliably recognized across all your host computers (Windows, CNC Lathe linux flavor, etc.)

This isn't a "solution" per-se given the complexity and ambiguity of your goal, but I hope that these tips will resolve your issues to some degree. 🙏

  1. Compared to most other Raspberry Pi models, the Zero is less power hungry, but like all others it can't provide too much power for external peripherals, like USB HDDs, USB Hubs w/o dedicated power supplies, giant LED strip, etc.

Opt to provide ample input power to the Pi Zero. If any external peripherals accept separate power inputs, provide it. The Zero may not have enough power for nominal operation and operation for the externally attached device.

Setting your lathe computer aside, PCs USB ports provide very stable, regulated power. - USB 2.0 - 5V @ 0.5A (max) - USB 3.0 - 5V @ 0.9A (max)

However, if your zero is only powered by a PC USB 2.0 port, then I'd be a little concerned because from personal experience insufficient power = weird behavior. Personally, I'd start with ample power for the Pi and external peripherals, and after achieving a desired outcome / goal, only then optimize the power supply / consumption.

This blog post by Jeff Geerling provides more detail. For example, WiFi is a hungry, hungry beast. The USB WiFi adapter adds 40ma alone to power consumption.

TL;DR Insufficient power can lead to unexpected, undesired behavior. Always be generous with how much power you're providing your Zero and if possible separately power (power hungry) external peripherals. For the Zero, 5V 1A is "okay," but your mileage may vary especially given what external peripherals you're adding.

  1. Stack trace was very informative! Thanks for posting it!

This is pure speculation, but my guess is that "unsafely ejecting" the Zero from a PC (presumably by USB) led to the kernel raising an exception and setting a 'tainted state.'

... PiZERO kernel: ... CPU: 0 PID: 0 Comm: swapper Tainted: G        W       4.4.50+ #970

In the line above, the G and W flags denote some kind of warning raised by the kernel. I'm guessing that the g_mass_storage library was doing something in swap memory and raised an exception when some g_mass_storage operation was abruptly stopped due to disconnecting the Pi from a host computer.

According to this document...

Once the tainted state of a running kernel has been set, it cannot be unset other than by reloading the kernel, that is by shutting down and then restarting the system.

More guesses here, but a tainted state could mean whatever programs or modules utilized by the g_mass_storage library have crashed or stopped due to some exception raised by the kernel.

This would explain why other computers aren't normally recognizing the Zero, while being independently powered (say a battery), after disconnection with another computer.

In a contrived example, imagine that you are driving a car and all of a sudden the engine completely stalls, shutting down general functionals like acceleration and power steering.

The kernel is the engine. The crashed, stopped, or the tainted state is the engine stall. The shutdown of general operations prevents potential, further engine damage just as a program stops execution (mostly) when encountering an error.

TL;DR Problem: The kernel has set a tainted state.

Short-Term Solution: Reboot to clear tainted state and resume nominal operation.

Long-Term Solution: Explore how to safely eject the Zero from a host computer from the g_mass_storage library. Without knowing anything else about your situation, I'd probably add some kind of external indicator to the Zero ( LED or buzzer ) that would signal when the Zero is busy or idle so that you can safely yank it out.

Hope this helps! Good luck and Godspeed!! 🖖

Improve this answer
11
  • Unfortunately, this would help more if I were having the opposite problem. In all tests thus far, power to the Pi has been provided by a battery, and no other devices are involved (nothing else drawing power). The issue is that there isn't a "tainted" state, so much as a "cured" state that only some hosts can provide. When the Pi starts up, the problem computer (CNC control) can't see it, unless some other device sees it first. In other words, if it's entering a tainted state, I want to know how to force that state without plugging it into a different host.
    – zeel
    Apr 6, 2019 at 22:24
  • Alright!! A couple of things. 1. Instead of a battery, could you power it with a 5V power supply with a minimum of 1A to the zero and trying again? Ruling out power supply issues would be the first step. Not sure what your battery specs are. 2. Do you have a model number for the control unit? Additionally, could you elaborate how you're connecting the zero to the control unit? 3. Lastly, when you're connecting the zero to the control unit, could you run lsusb or dmesg and provide the relevant output?
    – jhlink
    Apr 6, 2019 at 22:49
  • Heads up, btw. More info can be found here! raspberrypi.org/documentation/hardware/raspberrypi/usb/…
    – jhlink
    Apr 6, 2019 at 22:50
  • See, the big issue is that nothing about gadget mode works anything like connecting a USB device to the Pi. It's completely the opposite. The Pi isthe USB device. In my case, the CNC control unit is the host device, akin to a PC desktop. And the Pi is pretending to be a mass storage device. In this configuration, none of the typical troubleshooting for USB issues actually works. The weird thing, is that there is only a problem for certain hosts, not for all. Furthermore, it's strange that connecting to a host that doesn't have the issue temporarily fixes the issue for the problem hosts.
    – zeel
    Apr 7, 2019 at 2:17
  • Basically, the Pi is a flash drive, with its own fully functioning power supply. If I turn the power on (and allow time to boot) I can plug it into any PC I have and it will be recognized, the PC will think a flash drive has been plugged in, or an external HDD. I can manipulate and save files, and whether or not it is correctly ejected, I can unplug it, plug it into another PC, and it will also work.
    – zeel
    Apr 7, 2019 at 2:22
0

I had a similar issue when trying to use a SATA drive for use on my pi for use on a project I was working on. I was using a USB to SATA to connect but the one stupid thing I never thought of was, does the SATA have enough power from the pi to run... well It did not. on my USB to SATA cable there was two ends on the adapter. I ran the main to the pi and the other i ran to a 4 port USB hub and then connected the hub to a PC I had sitting close... well the one to the PC worked.It was up and running and reading the SATA drive. Its been working flawlessly ever since. I'm new here but I thought I would throw it out there because if anyone here is like me,I sometimes over think things and lose sight of the simpler answer right in front of me. thanks again and I hope this helps.

Improve this answer
1
  • 1
    Hey there, welcome to Stack Exchange. Your comment is appreciated, but it doesn't really answer the question. Do you have any experience or insight into using the gadget features of the Pi zero? This issue seems to be somewhat opposite of your situation, here the Pi itself is acting as the storage device.
    – zeel
    Apr 5, 2019 at 15:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.