On Mon, Jul 10, 2017 at 5:43 PM, Alan Robertson <clinicalitltd@xxxxxxxxx> wrote: > On Mon, Jul 10, 2017 at 3:46 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >> On Mon, 10 Jul 2017, Alan Robertson wrote: >> >>> On Sat, Jul 8, 2017 at 5:26 PM, Alan Robertson <clinicalitltd@xxxxxxxxx> wrote: >>> > On Sat, Jul 8, 2017 at 4:52 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: >>> >> 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. >> >> ... >> >>> OK I've had another play about with things this afternoon and >>> annotated the dmesg outputs to describe what I was doing at each >>> point. >>> >>> I haven't yet tried to recompile the kernel as that seems a slightly >>> slow process on the Pi (due to processing speed) and it make take me a >>> few goes to get it right - I thought I'd just check back initially in >>> case these logs provide sufficient clues! Obviously if not then I'll >>> look into that more. >>> >>> The key bit to my untrained eye seemed to be that until the line >>> 'g_mass_storage gadget: high-speed config #1: Linux File-Backed >>> Storage' appears, the Pi is unreadable by Systems 2-4. After that has >>> appeared in then appears to be readable, even though when connecting >>> to System 2 it (understandably and correctly) shows as low-speed >>> instead. Stop/start g_mass_storage doesn't appear to make a >>> difference. >> >> I agree. In fact, your logs seem to indicate pretty clearly that the >> problem doesn't lie in g_mass_storage at all, but rather in the dwc2 >> USB Device Controller driver. I have CC'ed the maintainer of the dwc2 >> driver. >> >> Here's the first log: >> >>> [ 15.891896] Mass Storage Function, version: 2009/09/11 >>> [ 15.891929] LUN: removable file: (no medium) >>> [ 15.892120] LUN: removable file: /home/pi/piusb.bin >>> [ 15.892135] Number of LUNs=1 >>> [ 15.894168] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11 >>> [ 15.894200] g_mass_storage gadget: g_mass_storage ready >>> [ 15.894245] dwc2 20980000.usb: dwc2_hsotg_enqueue_setup: failed queue (-11) >>> [ 15.897276] dwc2 20980000.usb: bound driver g_mass_storage >>> CONNECTED TO SYSTEM 2 >>> [ 263.798965] dwc2 20980000.usb: new device is low-speed >>> [ 269.497623] dwc2 20980000.usb: new device is low-speed >>> [ 275.115548] dwc2 20980000.usb: new device is low-speed >>> STILL NOT SHOWING UP ON SYSTEM 2 SO UNPLUGGED >>> (no extra message) >> >> Connecting at low speed is definitely a bug. The UDC driver should >> have connected at full speed. (It's possible that the log message is >> wrong, and the device really did connect at full speed. But if that >> were so, more log messages would have shown up.) >> >>> NOW PLUGGED IN TO WINDOWS 10 LAPTOP >>> (after a second, file browser opened showing root folder of memory storage) >>> [ 446.454380] dwc2 20980000.usb: new device is high-speed >>> [ 452.045884] dwc2 20980000.usb: new device is high-speed >>> [ 452.204357] dwc2 20980000.usb: new device is high-speed >>> [ 452.305171] dwc2 20980000.usb: new address 7 >>> [ 452.402701] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage >> >> High speed would also be correct. I assume that your System 2 doesn't >> support high speed, however. > > Yes, I wouldn't be surprised if that is the case - I think they're at > least 12 years old and imagine they were slow to implement new > developments. > >>> DISCONNECTED AND RECONNECTED TO SYSTEM 2 >>> [ 522.097785] WARNING: CPU: 0 PID: 0 at drivers/usb/dwc2/gadget.c:176 dwc2_hsotg_init_fifo+0x188/0x1a8 [dwc2]() >>> [ 522.097802] Modules linked in: g_mass_storage bnep hci_uart btbcm bluetooth brcmfmac brcmutil snd_bcm2835 cfg80211 rfkill snd_pcm snd_timer snd dwc2 bcm2835_gpiomem bcm2835_wdt uio_pdrv_genirq uio usb_f_mass_storage libcomposite udc_core ipv6 >>> [ 522.097906] CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.50+ #970 >>> [ 522.097918] Hardware name: BCM2708 >>> [ 522.097986] [<c0016d18>] (unwind_backtrace) from [<c0013c3c>] (show_stack+0x20/0x24) >>> [ 522.098025] [<c0013c3c>] (show_stack) from [<c02e49dc>] (dump_stack+0x20/0x28) >>> [ 522.098062] [<c02e49dc>] (dump_stack) from [<c0021f2c>] (warn_slowpath_common+0x8c/0xc4) >>> [ 522.098094] [<c0021f2c>] (warn_slowpath_common) from [<c0022020>] (warn_slowpath_null+0x2c/0x34) >>> [ 522.098207] [<c0022020>] (warn_slowpath_null) from [<bf0d3938>] (dwc2_hsotg_init_fifo+0x188/0x1a8 [dwc2]) >>> [ 522.098382] [<bf0d3938>] (dwc2_hsotg_init_fifo [dwc2]) from [<bf0d54cc>] (dwc2_hsotg_core_init_disconnected+0x60/0x308 [dwc2]) >>> [ 522.098538] [<bf0d54cc>] (dwc2_hsotg_core_init_disconnected [dwc2]) from [<bf0d5c74>] (dwc2_hsotg_irq+0x500/0x6dc [dwc2]) >>> [ 522.098645] [<bf0d5c74>] (dwc2_hsotg_irq [dwc2]) from [<c005acf4>] (handle_irq_event_percpu+0x94/0x1f0) >>> [ 522.098679] [<c005acf4>] (handle_irq_event_percpu) from [<c005ae88>] (handle_irq_event+0x38/0x4c) >>> [ 522.098712] [<c005ae88>] (handle_irq_event) from [<c005dc14>] (handle_level_irq+0x9c/0x134) >>> [ 522.098741] [<c005dc14>] (handle_level_irq) from [<c005a368>] (generic_handle_irq+0x30/0x44) >>> [ 522.098769] [<c005a368>] (generic_handle_irq) from [<c005a600>] (__handle_domain_irq+0x58/0xb8) >>> [ 522.098803] [<c005a600>] (__handle_domain_irq) from [<c0010748>] (handle_IRQ+0x2c/0x30) >>> [ 522.098832] [<c0010748>] (handle_IRQ) from [<c000940c>] (bcm2835_handle_irq+0x3c/0x58) >>> [ 522.098868] [<c000940c>] (bcm2835_handle_irq) from [<c05768e4>] (__irq_svc+0x44/0x5c) >>> [ 522.098883] Exception stack(0xc0821f18 to 0xc0821f60) >>> [ 522.098900] 1f00: 00000000 00000000 >>> [ 522.098922] 1f20: 00000000 c0822f74 c088d5f0 c0820000 c08220ac 00000000 c0887d04 c0887268 >>> [ 522.098944] 1f40: c0887268 c0821f74 c0821f68 c0821f68 c0010804 c0010808 60000013 ffffffff >>> [ 522.098975] [<c05768e4>] (__irq_svc) from [<c0010808>] (arch_cpu_idle+0x30/0x40) >>> [ 522.099016] [<c0010808>] (arch_cpu_idle) from [<c004d7ec>] (default_idle_call+0x34/0x48) >>> [ 522.099046] [<c004d7ec>] (default_idle_call) from [<c004d930>] (cpu_startup_entry+0x130/0x17c) >>> [ 522.099074] [<c004d930>] (cpu_startup_entry) from [<c05722e0>] (rest_init+0x6c/0x84) >>> [ 522.099112] [<c05722e0>] (rest_init) from [<c07c2ca0>] (start_kernel+0x358/0x3cc) >>> [ 522.099128] ---[ end trace ff12c3310899125d ]--- >> >> That certainly indicates something went wrong. > > Ah OK I wasn't sure if that was because I had pulled it out without > properly ejecting it > >>> [ 522.117486] dwc2 20980000.usb: new device is low-speed >>> [ 522.177563] dwc2 20980000.usb: new device is low-speed >>> [ 522.199215] dwc2 20980000.usb: new address 1 >>> [ 522.723225] g_mass_storage gadget: low-speed config #1: Linux File-Backed Storage >>> IS SHOWING UP CORRECTLY ON SYSTEM 2 >> >> That fact that it works here indicates that it isn't really connecting >> at low speed. g_mass_storage doesn't work at all in low speed. >> >> It's possible that the problem has already been fixed. You are using >> version 4.4.50 of the kernel, and version 4.12 was just released last >> week. > > I can certainly try an update to the latest version - last time I > tried that it seemed to break the g_mass_storage functionality for > some reason, but I've now got an image of this semi-working > configuration so could flash back if it stops working. OK have now updated to kernel 4.9.36+, unfortunately g_mass_storage isn't working at all in that! apt-get upgrade gave me 4.9.35+ then rpi-update got me to 4.9.36+. Unfortunately getting a kernel panic on boot (even on fresh install) when g_mass_storage trying to load (have posted about it at https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=188046). It looks like only 4.9.36+ is available on rpi-update, so will need to look into how to compile a newer kernel to see if that helps, although frustrating it's not even working on this version. AJR -- 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
