On Sat, 8 Jul 2017, Alan Robertson wrote: > On Sat, Jul 8, 2017 at 2:04 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 7 Jul 2017, Alan Robertson wrote: > > > >> Sorry to return to this topic & appreciate it might be either specific > >> to either the Pi or the system(s) I'm connecting it to, but have now > >> had time to try a few more combinations out and would appreciate any > >> thoughts from the experts here. > >> > >> To give some extra background - I've got the Pi configured to > >> automatically overwrite the mass storage device filestore upon boot, > >> so it is always presenting a fresh filesystem. Each system below is > >> made by a different manufacturer and is a closed system, so I have no > >> ability to perform any diagnostics at that end. > >> > >> System 1 - Always works > >> System 2 - Shows no USB stick connected > >> System 3 - Gives error when trying to save (memory error) > >> System 4 - Says unidentified USB > >> (Windows PC - Always works) > >> (Linux PC - Always works) > >> > >> At first I thought this was due to minor subtleties of how the > >> g_mass_storage device was being presented as a standard Sandisk USB > >> memory stick works fine in all systems. > >> > >> However I then started to notice some unusual behaviour, if rather > >> than doing a reboot (and wiping it fresh), I kept the power running > >> and moved it between machines. > >> > >> If I started with System 1 first, then systems 2, 3, 4 would all > >> recognise/write to it OK. > >> > >> I then copied a backup of the filesystem after it had been in System 1 > >> - however that still didn't seem to solve the problem after a reboot. > >> What I did then notice though was that if I powered the Pi up and then > >> first connected it to a Windows system it then worked fine when > >> plugged in to the others. To be clear I didn't read/write any files > >> to the device, just started it up, then plugged it into Windows, saw > >> the home directory on the USB open, then unplugged it and plugged it > >> into one of the other systems - they all now recognised it. > >> > >> I tried starting/stopping g_mass_storage but that in itself didn't > >> seem to do it. > > > > Sorry, this is unclear. > > > > 1. By starting/stopping g_mass_storage, do you mean doing: > > > > rmmod g_mass_storage > > modprobe g_mass_storage file=... > > Yes - at least I believe I've effectively been doing the same albeit a > slightly different version of stopping... > sudo modprobe -rv g_mass_storage That's basically the same as rmmod g_mass_storage. > and then to start... > sudo modprobe g_mass_storage file=/home/pi/piusb.bin stall=0 > removable=1 idVendor=0x0781 idProduct=0x5572 bcdDevice=0x0126 > iManufacturer="SanDisk" iProduct="Cruzer Switch" > iSerialNumber="4C597515973308202393" > > > > 2. Did you start/stop g_mass_storage after plugging the device > > into a Windows system or System 1? Or did you do this after > > booting the device but not plugging it into anything? > > Upon startup it mounts the filesystem as read-only: > sudo losetup -o 1048576 /dev/loop0 /home/pi/piusb.bin > sudo mount -t vfat -r /dev/loop0 /mnt > > Then copies contents off, unmounts it, overwrites pisub.bin with > backup blank filesystem, then remounts the filesystem read-only again > and starts USB. This does not answer the question I asked. Had you plugged the device into a Windows system or System 1 before you stopped/started g_mass_storage? > I didn't do anything when plugging into Windows system or System 1 - > just started up, plugged into one of those, unplugged and then plugged > into one of the other systems. What happens if you plug the device into either a Windows system or System 1, then unplug it, then stop/start g_mass_storage, and then plug the device into one of systems 2-4? > > 3. By "that in itself didn't seem to do it", do you mean that > > starting/stopping g_mass_storage resulted in no change to the > > behavior? Or did it always lead to a failure when the device > > was attached to systems 2 - 4, even if it had been plugged into > > System 1 before the start/stop? > > Correct I don't understand this answer. I asked which of two possible behaviors you observed, and you replied "Correct". What does that mean? > - the only way I could get it to work with systems 2-4 was if > it had been initially started up then plugged into PC or system 1. > Obviously not ideal given I was hopeful a unit could remain plugged > into each system, just starting up whenever the system booted. > > >> To be honest I'm now a bit flummoxed! It is clearly able to work with > >> all 4 systems (I've been able to save files from them), but it seems > >> to want to be plugged into either a PC or System 1 first before then > >> working with the others. Can anyone think of anything that is > >> happening when I do this? Unfortunately the idea of doing it this way > >> is just not workable for what I'm wanting to do. Ideally I would have > >> 1 Pi for each system, plugged into it just by the one USB data/power > >> cable such that when the system powered on the Pi booted and then the > >> USB was available to it to read/write. > > > > Did you try enabling verbose debugging in g_mass_storage? This > > requires setting CONFIG_USB_GADGET_DEBUG and CONFIG_USB_GADGET_VERBOSE > > in the kernel configuration and then rebuilding g_mass_storage.ko. > > And at runtime you may need to enable dynamic debugging by doing > > > > echo 'module g_mass_storage =p' >/sys/kernel/dynamic_debug/control > > > > before plugging the device into anything. Then compare the contents of > > the dmesg log for the different scenarios. In particular, look for > > differences between plugging it into System 2 (say) right after boot > > vs. after plugging it into System 1. > > OK interesting - I'll need to do some searching to understand how to > change that and rebuild g_mass_storage.ko but I like the idea of > seeing more detail about what is happening as the systems are closed > so I'm unable to do any troubleshooting at that end. Do you have any experience in building a kernel for the Raspberry Pi? The procedure is explained on several web sites, but you have to know what you're doing. Alan Stern > My alternate backup plan isn't ideal, but would involve connecting an > actual flash drive (via USB cable) to the system, then using a button > attached to the Pi to register a user request for upload, then > triggering relays to switch a connection from the flash drive to the > system to the flash drive to the Pi so it could then download contents > of the drive before switching it back to being connected to the > system. All seems a bit inelegant compared to being able to use > g_mass_storage though! > > Thanks again for replying. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
