g_mass_storage gadget exception

[cgalpin]

Describe the bug
g_mass_storage gadget stops working with this trace (or one very much like it)

Jan 6 04:53:33 teslaCamBuddy kernel: [51206.259389] ------------[ cut here ]------------
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.259579] WARNING: CPU: 0 PID: 0 at drivers/usb/dwc2/gadget.c:300 dwc2_hsotg_init_fifo+0x1ac/0x1d0 [dwc2]
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.259589] Modules linked in: cmac bnep hci_uart btbcm serdev bluetooth ecdh_generic g_mass_storage usb_f_mass_storage libcomposite brcmfmac brcmutil snd_bcm2835(C) snd_pcm snd_timer snd cfg80211 rfkill fixed uio_pdrv_genirq uio dwc2 udc_core ip_tables x_tables ipv6
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.259706] CPU: 0 PID: 0 Comm: swapper Tainted: G WC 4.14.71+ #1145
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.259711] Hardware name: BCM2835
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.259772] [] (unwind_backtrace) from [] (show_stack+0x20/0x24)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.259806] [] (show_stack) from [] (dump_stack+0x20/0x28)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.259834] [] (dump_stack) from [] (__warn+0xe4/0x10c)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.259855] [] (__warn) from [] (warn_slowpath_null+0x30/0x38)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.259966] [] (warn_slowpath_null) from [] (dwc2_hsotg_init_fifo+0x1ac/0x1d0 [dwc2])
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260140] [] (dwc2_hsotg_init_fifo [dwc2]) from [] (dwc2_hsotg_core_init_disconnected+0x88/0x3ec [dwc2])
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260307] [] (dwc2_hsotg_core_init_disconnected [dwc2]) from [] (dwc2_hsotg_irq+0x6f4/0x7c8 [dwc2])
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260408] [] (dwc2_hsotg_irq [dwc2]) from [] (__handle_irq_event_percpu+0x94/0x1c8)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260430] [] (__handle_irq_event_percpu) from [] (handle_irq_event_percpu+0x2c/0x68)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260447] [] (handle_irq_event_percpu) from [] (handle_irq_event+0x38/0x4c)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260470] [] (handle_irq_event) from [] (handle_level_irq+0xa0/0x114)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260503] [] (handle_level_irq) from [] (generic_handle_irq+0x30/0x44)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260528] [] (generic_handle_irq) from [] (__handle_domain_irq+0x58/0xb8)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260550] [] (__handle_domain_irq) from [] (bcm2835_handle_irq+0x28/0x48)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260574] [] (bcm2835_handle_irq) from [] (__irq_svc+0x5c/0x7c)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260585] Exception stack(0xc093bef8 to 0xc093bf40)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260595] bee0: 00000000 00000000
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260611] bf00: ffffffff c093d414 c093a000 c093d0a4 c09c58e6 c093d020 c09d2900 c0916a28
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260628] bf20: dbfffa80 c093bf54 c093bf48 c093bf48 c001079c c00107a0 60000013 ffffffff
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260654] [] (__irq_svc) from [] (arch_cpu_idle+0x30/0x40)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260675] [] (arch_cpu_idle) from [] (default_idle_call+0x34/0x48)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260692] [] (default_idle_call) from [] (do_idle+0x8c/0xec)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260711] [] (do_idle) from [] (cpu_startup_entry+0x1c/0x20)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260741] [] (cpu_startup_entry) from [] (rest_init+0x7c/0x9c)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260766] [] (rest_init) from [] (start_kernel+0x358/0x3c8)
Jan 6 04:53:33 teslaCamBuddy kernel: [51206.260779] ---[ end trace ca848eeb67cc612c ]---

To reproduce
Setup pi as mass storage gadget, plug into host. Host writes to gadget every minute (around 30 Mb file), and pi mounts same disk read only and copies files from the disk via rysnc every minute. I get this on two different pis, so do not suspect hardware at this time. I get this using both a partition as well as a file image (formatted as vfat) for the disk exposed.

Expected behaviour
Keep running indefinitely

Actual behaviour
After a while (hour or two) I get this exception and the mass storage device stops working.

System
Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:

• Which model of Raspberry Pi?

PiZeroW

• Which OS and version (cat /etc/rpi-issue)?

Raspberry Pi reference 2018-11-13
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 7e0c786c641ba15990b5662f092c106beed40c9f, stage2

and

Raspberry Pi reference 2018-10-09
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 7b40fd11bc13d6496bb6bd1bc02f946b7e0ac7cb, stage2

• Which firmware version (vcgencmd version)?

Nov 4 2018 16:31:07
Copyright (c) 2012 Broadcom
version ed5baf9520a3c4ca82ba38594b898f0c0446da66 (clean) (release)

and

Sep 21 2018 15:43:17
Copyright (c) 2012 Broadcom
version 07f57128b8491ffdefcdfd13f7b4961b3006d9a9 (clean) (release)

• Which kernel version (uname -a)?

Linux pi1 4.14.79+ #1159 Sun Nov 4 17:28:08 GMT 2018 armv6l GNU/Linux

and

Linux pi2 4.14.71+ #1145 Fri Sep 21 15:06:38 BST 2018 armv6l GNU/Linux

[ED6E0F17]

This may be fixed on Linux 5.0 if it is related to the upstream fix:
dccf1ba
which was then reverted and fixed with 4fe4f9f

[cgalpin]

Thanks a lot. I built and ran the rip-5.0.y branch kernel and it seems to work fine.

I am a bit out of the loop - do you have any idea when this will get promoted to release version?

[pelwell]

4.19 will be the next released kernel version, and I expect us to switch over within the next few weeks.

[cgalpin]

Thanks. And just to be clear - 4.19 will contain these fixes?

[pelwell]

Currently no - dccf1ba was added in 4.20, and 4fe4f9f in 5.0 - but we usually accept back-ports when requested.

[cgalpin]

Ok, I'd like to request back-porting these. How do I go about doing that?

[pelwell]

Ordinarily you'd open an issue or, if you were keen, a pull request. But since you've already asked I'm not going to ask you to jump through those hoops. What would be useful is for you to:

$ git checkout rpi-4.19.y
$ git cherry-pick dccf1ba
$ git cherry-pick 4fe4f9f

Then build your kernel and verify that the exception no longer occurs.

[cgalpin]

Will do, thanks!

[cgalpin]

My use case only runs for about 13-15 hours at a time before intentionally stopping sharing, but these commits applied to rip-4.19.y are working well. I have not had the exception after a few iterations.

[pelwell]

Thanks for the update - those commits are now in rpi-4.19.y.

[cgalpin]

Awesome, thanks so much.

[JamesH65]

Please update to the latest kernel which may contain a fix for this issue.