USB gadgets with configfs hang reboot

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.
Error on reboot after rmmod $udc_module:

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Hi,

Quoted 8 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff hang issue on N900. Also, g_nokia is not a module in the config I use, so I guess the problem is not related whether gadgets are modular or not. Unfortunately I was not able to test reboot, as rootfs became corrupted after the first poweroff :( . So it looks like my theory that onenand corruption on N900 is because poweroff/reboot hangs is wrong.

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

I think Felipe is offline for next few days, but anyways here are the error messages and a shells script to reproduce the issue.

Cheers,

Tony

Test script to reproduce the problem, need to uncomment the reboot part:

8< --------------------
#!/bin/bash

# Change for your UDC controller
udc_module=dwc3-omap
udc_name=4a030000.dwc3

#
# Calling this and then doing rmmod $udc_module

# followed by reboot seems to produce the follow:
# WARNING: CPU: 1 PID: 1617 at lib/debugobjects.c:263
#
start_usb_gadgets() {
	vendor=0x1d6b
	product=0x0106
	file=$1

	mount -t configfs none /sys/kernel/config
	mkdir /sys/kernel/config/usb_gadget/g1
	old_pwd=$(pwd)
	cd /sys/kernel/config/usb_gadget/g1

	echo $product > idProduct
	echo $vendor > idVendor
	mkdir strings/0x409
	echo 123456789 > strings/0x409/serialnumber
	echo foo > strings/0x409/manufacturer
	echo "Multi Gadget" > strings/0x409/product

	mkdir configs/c.1
	echo 120 > configs/c.1/MaxPower
	mkdir configs/c.1/strings/0x409
	echo "Conf 1" > configs/c.1/strings/0x409/configuration

	mkdir configs/c.2
	echo 500 > configs/c.2/MaxPower
	mkdir configs/c.2/strings/0x409
	echo "Conf 2" > configs/c.2/strings/0x409/configuration

	mkdir functions/mass_storage.0
	echo $file > functions/mass_storage.0/lun.0/file
	ln -s functions/mass_storage.0 configs/c.1
	ln -s functions/mass_storage.0 configs/c.2

	# Not configuring further here just produces

	# WARNING: CPU: 1 PID: 1609 at lib/debugobjects.c:263

	mkdir functions/acm.0
	ln -s functions/acm.0 configs/c.1
	ln -s functions/acm.0 configs/c.2

	mkdir functions/ecm.0
	ln -s functions/acm.0 configs/c.1

ln -s functions/acm.0 configs/c.2

# Adding rndis seems to cause alignment trap or some # random oops on reboot after rmmod $udc_module mkdir functions/rndis.0
ln -s functions/rndis.0 configs/c.1
ln -s functions/rndis.0 configs/c.2

echo $udc_name > /sys/kernel/config/usb_gadget/g1/UDC cd $old_pwd
}

function rmmod_and_shutdown() {
rmmod $udc_module
reboot
}

modprobe $udc_module

start_usb_gadgets ""

# uncomment this to reproduce bug
# rmmod_and_shutdown

Hi Tony,

W dniu 15.01.2016 o 23:48, Tony Lindgren pisze:

Quoted 8 lines

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

I can't reproduce your problem on 4.4-rc4 nor on 4.4 release with the script you provided

I'm using Odroid XU3, which has dwc3.

Quoted 2 lines

mkdir functions/ecm.0
ln -s functions/acm.0 configs/c.1

I assume you meant ecm.0 here and in the next line.

Quoted 1 line

ln -s functions/acm.0 configs/c.2

Hi,

Quoted 8 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff hang issue on N900. Also, g_nokia is not a module in the config I use, so I guess the problem is not related whether gadgets are modular or not. Unfortunately I was not able to test reboot, as rootfs became corrupted after the first poweroff :( . So it looks like my theory that onenand corruption on N900 is because poweroff/reboot hangs is wrong.

Ivo

Quoted 20 lines · Ivaylo Dimitrov

Hi,

Quoted 8 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff hang issue on N900. Also, g_nokia is not a module in the config I use, so I guess the problem is not related whether gadgets are modular or not. Unfortunately I was not able to test reboot, as rootfs became corrupted after the first poweroff :( . So it looks like my theory that onenand corruption on N900 is because poweroff/reboot hangs is wrong.

Quoted 1 line

Ivo

Is there any progress on the issue?

Hi,

Quoted 25 lines · Ivaylo Dimitrov

Quoted 20 lines · Ivaylo Dimitrov

Hi,

Quoted 8 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff hang issue on N900. Also, g_nokia is not a module in the config I use, so I guess the problem is not related whether gadgets are modular or not. Unfortunately I was not able to test reboot, as rootfs became corrupted after the first poweroff :( . So it looks like my theory that onenand corruption on N900 is because poweroff/reboot hangs is wrong.

Quoted 1 line

Ivo

Is there any progress on the issue?

Quoted 22 lines

Quoted 21 lines · Ivaylo Dimitrov

Quoted 20 lines · Ivaylo Dimitrov

Hi,

Quoted 8 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff hang issue on N900. Also, g_nokia is not a module in the config I use, so I guess the problem is not related whether gadgets are modular or not. Unfortunately I was not able to test reboot, as rootfs became corrupted after the first poweroff :( . So it looks like my theory that onenand corruption on N900 is because poweroff/reboot hangs is wrong.

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Ivo

Is there any progress on the issue?

Doing Nokia-N900:/sys/bus/platform/drivers/musb-hdrc# echo musb-hdrc.0.auto > unbind results in:

<1>[ 1418.511260] Unable to handle kernel paging request at virtual 
address 6c6c757a
<7>[ 1418.677215] pvr: Xorg: cleaning up 49 unfreed resources
<1>[ 1418.683349] pgd = c0004000
<1>[ 1418.739959] [6c6c757a] *pgd=00000000
<0>[ 1418.746307] Internal error: Oops: 5 [#1] PREEMPT ARM
<4>[ 1418.753997] Modules linked in: sha256_generic hmac drbg ansi_cprng 

ctr ccm vfat fat rfcomm sd_mod scsi_mod bnep bluetooth omaplfb pvrsrvkm ipv6 bq2415x_charger uinput radio_platform_si4713 joydev cmt_speech hsi_char video_bus_switch arc4 wl1251_spi wl1251 isp1704_charger gpio_keys mac80211 smc91x mii cfg80211 omap_wdt crc7 omap_sham tsc2005 tsc200x_core bq27xxx_battery_i2c si4713 adp1653 tsl2563 leds_lp5523 leds_lp55xx_common bq27xxx_battery rtc_twl twl4030_wdt et8ek8 ad5820 v4l2_common smiaregs twl4030_vibra videodev ff_memless lis3lv02d_i2c lis3lv02d media input_polldev omap_ssi_port ti_soc_thermal nokia_modem ssi_protocol omap_ssi hsi rx51_battery

<4>[ 1418.835906] CPU: 0 PID: 53 Comm: file-storage Not tainted 
4.5.0-rc5+ #59
<4>[ 1418.846130] Hardware name: Nokia RX-51 board
<4>[ 1418.853820] task: ceb8a300 ti: ce008000 task.ti: ce008000
<4>[ 1418.862792] PC is at handle_exception+0xa8/0x418
<4>[ 1418.871002] LR is at recalc_sigpending+0x18/0x7c
<4>[ 1418.879241] pc : [<c031d0e4>]    lr : [<c0037b84>]    psr: 80000013
<4>[ 1418.879241] sp : ce009ea0  ip : 00000000  fp : 00000000
<4>[ 1418.898284] r10: 00000000  r9 : 00000000  r8 : 00000000
<4>[ 1418.907287] r7 : c031d8d0  r6 : 6c6c7566  r5 : 00000000  r4 : cebe1600
<4>[ 1418.917663] r3 : 6f642820  r2 : 00000000  r1 : 00000000  r0 : 00000000
<4>[ 1418.928039] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM 
Segment none
<4>[ 1418.939025] Control: 10c5387d  Table: 8e244019  DAC: 00000051
<0>[ 1418.948516] Process file-storage (pid: 53, stack limit = 0xce008210)
<0>[ 1418.958679] Stack: (0xce009ea0 to 0xce00a000)
<0>[ 1418.966735] 9ea0: 0000000f 00000000 00000000 00000b07 00000000 
00000001 000003ff 00000001
<0>[ 1418.978973] 9ec0: ceb8a300 ceb8a300 00000000 c004841c 00000000 
00000002 ce888000 c0451a50
<0>[ 1418.991180] 9ee0: ffffffff 00000000 00000000 00000008 cebe1600 
00000001 c0717dd0 00000001
<0>[ 1419.003387] 9f00: 00000000 00000000 ce009f14 c044ddf4 00000000 
c031c020 00000042 ce009f30
<0>[ 1419.015686] 9f20: ce009f30 00000000 cebe1600 c031d958 00000000 
c044d864 a0000013 00000000
<0>[ 1419.027923] 9f40: cebe1600 c031d8d0 cebfa100 cebfa100 00000000 
cebe1600 c031d8d0 00000000
<0>[ 1419.040130] 9f60: 00000000 00000000 00000000 c00474e4 dc4d900d 
00000000 31bc92e7 cebe1600
<0>[ 1419.052429] 9f80: 00000000 ce009f84 ce009f84 00000000 ce009f90 
ce009f90 ce009fac cebfa100
<0>[ 1419.064697] 9fa0: c0047418 00000000 00000000 c000f218 00000000 
00000000 00000000 00000000
<0>[ 1419.076934] 9fc0: 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 00000000
<0>[ 1419.089050] 9fe0: 00000000 00000000 00000000 00000000 00000013 
00000000 00002000 30000891
<4>[ 1419.101043] [<c031d0e4>] (handle_exception) from [<c031d958>] 
(fsg_main_thread+0x88/0x13dc)
<4>[ 1419.113189] [<c031d958>] (fsg_main_thread) from [<c00474e4>] 
(kthread+0xcc/0xe0)
<4>[ 1419.124267] [<c00474e4>] (kthread) from [<c000f218>] 
(ret_from_fork+0x14/0x3c)
<0>[ 1419.135101] Code: 1a000015 ea000040 e5946038 e0866285 (e5963014)
<4>[ 1419.330841] ---[ end trace 3377457e25b0732c ]---
<0>[ 1419.340972] Kernel panic - not syncing: Fatal exception

weirdly, I have that log only in mtdoops, but not in dmesg. However, after that oops "reboot" command does not hang, but reboots the device.

Hi,

Quoted 95 lines · Ivaylo Dimitrov

Quoted 22 lines

Quoted 21 lines · Ivaylo Dimitrov

Quoted 20 lines · Ivaylo Dimitrov

Hi,

Quoted 8 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff hang issue on N900. Also, g_nokia is not a module in the config I use, so I guess the problem is not related whether gadgets are modular or not. Unfortunately I was not able to test reboot, as rootfs became corrupted after the first poweroff :( . So it looks like my theory that onenand corruption on N900 is because poweroff/reboot hangs is wrong.

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Ivo

Is there any progress on the issue?

Doing Nokia-N900:/sys/bus/platform/drivers/musb-hdrc# echo musb-hdrc.0.auto > unbind results in:

<1>[ 1418.511260] Unable to handle kernel paging request at virtual
address 6c6c757a
<7>[ 1418.677215] pvr: Xorg: cleaning up 49 unfreed resources
<1>[ 1418.683349] pgd = c0004000
<1>[ 1418.739959] [6c6c757a] *pgd=00000000
<0>[ 1418.746307] Internal error: Oops: 5 [#1] PREEMPT ARM
<4>[ 1418.753997] Modules linked in: sha256_generic hmac drbg ansi_cprng

ctr ccm vfat fat rfcomm sd_mod scsi_mod bnep bluetooth omaplfb pvrsrvkm ipv6 bq2415x_charger uinput radio_platform_si4713 joydev cmt_speech hsi_char video_bus_switch arc4 wl1251_spi wl1251 isp1704_charger gpio_keys mac80211 smc91x mii cfg80211 omap_wdt crc7 omap_sham tsc2005 tsc200x_core bq27xxx_battery_i2c si4713 adp1653 tsl2563 leds_lp5523 leds_lp55xx_common bq27xxx_battery rtc_twl twl4030_wdt et8ek8 ad5820 v4l2_common smiaregs twl4030_vibra videodev ff_memless lis3lv02d_i2c lis3lv02d media input_polldev omap_ssi_port ti_soc_thermal nokia_modem ssi_protocol omap_ssi hsi rx51_battery

<4>[ 1418.835906] CPU: 0 PID: 53 Comm: file-storage Not tainted
4.5.0-rc5+ #59
<4>[ 1418.846130] Hardware name: Nokia RX-51 board
<4>[ 1418.853820] task: ceb8a300 ti: ce008000 task.ti: ce008000
<4>[ 1418.862792] PC is at handle_exception+0xa8/0x418
<4>[ 1418.871002] LR is at recalc_sigpending+0x18/0x7c
<4>[ 1418.879241] pc : [<c031d0e4>]    lr : [<c0037b84>]    psr: 80000013
<4>[ 1418.879241] sp : ce009ea0  ip : 00000000  fp : 00000000
<4>[ 1418.898284] r10: 00000000  r9 : 00000000  r8 : 00000000
<4>[ 1418.907287] r7 : c031d8d0  r6 : 6c6c7566  r5 : 00000000  r4 : cebe1600
<4>[ 1418.917663] r3 : 6f642820  r2 : 00000000  r1 : 00000000  r0 : 00000000
<4>[ 1418.928039] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment none
<4>[ 1418.939025] Control: 10c5387d  Table: 8e244019  DAC: 00000051
<0>[ 1418.948516] Process file-storage (pid: 53, stack limit = 0xce008210)
<0>[ 1418.958679] Stack: (0xce009ea0 to 0xce00a000)
<0>[ 1418.966735] 9ea0: 0000000f 00000000 00000000 00000b07 00000000
00000001 000003ff 00000001
<0>[ 1418.978973] 9ec0: ceb8a300 ceb8a300 00000000 c004841c 00000000
00000002 ce888000 c0451a50
<0>[ 1418.991180] 9ee0: ffffffff 00000000 00000000 00000008 cebe1600
00000001 c0717dd0 00000001
<0>[ 1419.003387] 9f00: 00000000 00000000 ce009f14 c044ddf4 00000000
c031c020 00000042 ce009f30
<0>[ 1419.015686] 9f20: ce009f30 00000000 cebe1600 c031d958 00000000
c044d864 a0000013 00000000
<0>[ 1419.027923] 9f40: cebe1600 c031d8d0 cebfa100 cebfa100 00000000
cebe1600 c031d8d0 00000000
<0>[ 1419.040130] 9f60: 00000000 00000000 00000000 c00474e4 dc4d900d
00000000 31bc92e7 cebe1600
<0>[ 1419.052429] 9f80: 00000000 ce009f84 ce009f84 00000000 ce009f90
ce009f90 ce009fac cebfa100
<0>[ 1419.064697] 9fa0: c0047418 00000000 00000000 c000f218 00000000
00000000 00000000 00000000
<0>[ 1419.076934] 9fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
<0>[ 1419.089050] 9fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00002000 30000891
<4>[ 1419.101043] [<c031d0e4>] (handle_exception) from [<c031d958>]
(fsg_main_thread+0x88/0x13dc)
<4>[ 1419.113189] [<c031d958>] (fsg_main_thread) from [<c00474e4>]
(kthread+0xcc/0xe0)
<4>[ 1419.124267] [<c00474e4>] (kthread) from [<c000f218>]
(ret_from_fork+0x14/0x3c)
<0>[ 1419.135101] Code: 1a000015 ea000040 e5946038 e0866285 (e5963014)
<4>[ 1419.330841] ---[ end trace 3377457e25b0732c ]---
<0>[ 1419.340972] Kernel panic - not syncing: Fatal exception

Quoted 2 lines

weirdly, I have that log only in mtdoops, but not in dmesg. However, after that oops "reboot" command does not hang, but reboots the device.

So, what is handle_exception + 0xa8 ? You can figure that out either with gdb or addr2line assuming your vmlinux has dbg symbols.

For gdb you would:

gdb vmlinux
(gdb) l *(handle_exception + 0xa8)

Quoted 100 lines

Quoted 95 lines · Ivaylo Dimitrov

Quoted 22 lines

Quoted 21 lines · Ivaylo Dimitrov

Quoted 20 lines · Ivaylo Dimitrov

Hi,

Quoted 8 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff hang issue on N900. Also, g_nokia is not a module in the config I use, so I guess the problem is not related whether gadgets are modular or not. Unfortunately I was not able to test reboot, as rootfs became corrupted after the first poweroff :( . So it looks like my theory that onenand corruption on N900 is because poweroff/reboot hangs is wrong.

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Ivo

Is there any progress on the issue?

Doing Nokia-N900:/sys/bus/platform/drivers/musb-hdrc# echo musb-hdrc.0.auto > unbind results in:

<1>[ 1418.511260] Unable to handle kernel paging request at virtual
address 6c6c757a
<7>[ 1418.677215] pvr: Xorg: cleaning up 49 unfreed resources
<1>[ 1418.683349] pgd = c0004000
<1>[ 1418.739959] [6c6c757a] *pgd=00000000
<0>[ 1418.746307] Internal error: Oops: 5 [#1] PREEMPT ARM
<4>[ 1418.753997] Modules linked in: sha256_generic hmac drbg ansi_cprng

ctr ccm vfat fat rfcomm sd_mod scsi_mod bnep bluetooth omaplfb pvrsrvkm ipv6 bq2415x_charger uinput radio_platform_si4713 joydev cmt_speech hsi_char video_bus_switch arc4 wl1251_spi wl1251 isp1704_charger gpio_keys mac80211 smc91x mii cfg80211 omap_wdt crc7 omap_sham tsc2005 tsc200x_core bq27xxx_battery_i2c si4713 adp1653 tsl2563 leds_lp5523 leds_lp55xx_common bq27xxx_battery rtc_twl twl4030_wdt et8ek8 ad5820 v4l2_common smiaregs twl4030_vibra videodev ff_memless lis3lv02d_i2c lis3lv02d media input_polldev omap_ssi_port ti_soc_thermal nokia_modem ssi_protocol omap_ssi hsi rx51_battery

<4>[ 1418.835906] CPU: 0 PID: 53 Comm: file-storage Not tainted
4.5.0-rc5+ #59
<4>[ 1418.846130] Hardware name: Nokia RX-51 board
<4>[ 1418.853820] task: ceb8a300 ti: ce008000 task.ti: ce008000
<4>[ 1418.862792] PC is at handle_exception+0xa8/0x418
<4>[ 1418.871002] LR is at recalc_sigpending+0x18/0x7c
<4>[ 1418.879241] pc : [<c031d0e4>]    lr : [<c0037b84>]    psr: 80000013
<4>[ 1418.879241] sp : ce009ea0  ip : 00000000  fp : 00000000
<4>[ 1418.898284] r10: 00000000  r9 : 00000000  r8 : 00000000
<4>[ 1418.907287] r7 : c031d8d0  r6 : 6c6c7566  r5 : 00000000  r4 : cebe1600
<4>[ 1418.917663] r3 : 6f642820  r2 : 00000000  r1 : 00000000  r0 : 00000000
<4>[ 1418.928039] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment none
<4>[ 1418.939025] Control: 10c5387d  Table: 8e244019  DAC: 00000051
<0>[ 1418.948516] Process file-storage (pid: 53, stack limit = 0xce008210)
<0>[ 1418.958679] Stack: (0xce009ea0 to 0xce00a000)
<0>[ 1418.966735] 9ea0: 0000000f 00000000 00000000 00000b07 00000000
00000001 000003ff 00000001
<0>[ 1418.978973] 9ec0: ceb8a300 ceb8a300 00000000 c004841c 00000000
00000002 ce888000 c0451a50
<0>[ 1418.991180] 9ee0: ffffffff 00000000 00000000 00000008 cebe1600
00000001 c0717dd0 00000001
<0>[ 1419.003387] 9f00: 00000000 00000000 ce009f14 c044ddf4 00000000
c031c020 00000042 ce009f30
<0>[ 1419.015686] 9f20: ce009f30 00000000 cebe1600 c031d958 00000000
c044d864 a0000013 00000000
<0>[ 1419.027923] 9f40: cebe1600 c031d8d0 cebfa100 cebfa100 00000000
cebe1600 c031d8d0 00000000
<0>[ 1419.040130] 9f60: 00000000 00000000 00000000 c00474e4 dc4d900d
00000000 31bc92e7 cebe1600
<0>[ 1419.052429] 9f80: 00000000 ce009f84 ce009f84 00000000 ce009f90
ce009f90 ce009fac cebfa100
<0>[ 1419.064697] 9fa0: c0047418 00000000 00000000 c000f218 00000000
00000000 00000000 00000000
<0>[ 1419.076934] 9fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
<0>[ 1419.089050] 9fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00002000 30000891
<4>[ 1419.101043] [<c031d0e4>] (handle_exception) from [<c031d958>]
(fsg_main_thread+0x88/0x13dc)
<4>[ 1419.113189] [<c031d958>] (fsg_main_thread) from [<c00474e4>]
(kthread+0xcc/0xe0)
<4>[ 1419.124267] [<c00474e4>] (kthread) from [<c000f218>]
(ret_from_fork+0x14/0x3c)
<0>[ 1419.135101] Code: 1a000015 ea000040 e5946038 e0866285 (e5963014)
<4>[ 1419.330841] ---[ end trace 3377457e25b0732c ]---
<0>[ 1419.340972] Kernel panic - not syncing: Fatal exception

Quoted 2 lines

weirdly, I have that log only in mtdoops, but not in dmesg. However, after that oops "reboot" command does not hang, but reboots the device.

Quoted 8 lines

So, what is handle_exception + 0xa8 ? You can figure that out either with gdb or addr2line assuming your vmlinux has dbg symbols.

For gdb you would:

gdb vmlinux
(gdb) l *(handle_exception + 0xa8)

Yeah, sorry I didn't do it with the previous mail.

Reading symbols from /home/ivo/workspace/linux-upstream/github/fmg/linux-n900/vmlinux...done. (gdb) l *(handle_exception + 0xa8)
0xc031d0e4 is in handle_exception (drivers/usb/gadget/function/f_mass_storage.c:2373).
2368
2369 /* Cancel all the pending transfers */
2370 if (likely(common->fsg)) {
2371 for (i = 0; i < common->fsg_num_buffers; ++i) {
2372 bh = &common->buffhds[i];
2373 if (bh->inreq_busy)

Hi,

Quoted 111 lines · Ivaylo Dimitrov

Quoted 100 lines

Quoted 95 lines · Ivaylo Dimitrov

Quoted 22 lines

Quoted 21 lines · Ivaylo Dimitrov

Quoted 20 lines · Ivaylo Dimitrov

Hi,

Quoted 8 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff hang issue on N900. Also, g_nokia is not a module in the config I use, so I guess the problem is not related whether gadgets are modular or not. Unfortunately I was not able to test reboot, as rootfs became corrupted after the first poweroff :( . So it looks like my theory that onenand corruption on N900 is because poweroff/reboot hangs is wrong.

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Ivo

Is there any progress on the issue?

Doing Nokia-N900:/sys/bus/platform/drivers/musb-hdrc# echo musb-hdrc.0.auto > unbind results in:

<1>[ 1418.511260] Unable to handle kernel paging request at virtual
address 6c6c757a
<7>[ 1418.677215] pvr: Xorg: cleaning up 49 unfreed resources
<1>[ 1418.683349] pgd = c0004000
<1>[ 1418.739959] [6c6c757a] *pgd=00000000
<0>[ 1418.746307] Internal error: Oops: 5 [#1] PREEMPT ARM
<4>[ 1418.753997] Modules linked in: sha256_generic hmac drbg ansi_cprng

ctr ccm vfat fat rfcomm sd_mod scsi_mod bnep bluetooth omaplfb pvrsrvkm ipv6 bq2415x_charger uinput radio_platform_si4713 joydev cmt_speech hsi_char video_bus_switch arc4 wl1251_spi wl1251 isp1704_charger gpio_keys mac80211 smc91x mii cfg80211 omap_wdt crc7 omap_sham tsc2005 tsc200x_core bq27xxx_battery_i2c si4713 adp1653 tsl2563 leds_lp5523 leds_lp55xx_common bq27xxx_battery rtc_twl twl4030_wdt et8ek8 ad5820 v4l2_common smiaregs twl4030_vibra videodev ff_memless lis3lv02d_i2c lis3lv02d media input_polldev omap_ssi_port ti_soc_thermal nokia_modem ssi_protocol omap_ssi hsi rx51_battery

<4>[ 1418.835906] CPU: 0 PID: 53 Comm: file-storage Not tainted
4.5.0-rc5+ #59
<4>[ 1418.846130] Hardware name: Nokia RX-51 board
<4>[ 1418.853820] task: ceb8a300 ti: ce008000 task.ti: ce008000
<4>[ 1418.862792] PC is at handle_exception+0xa8/0x418
<4>[ 1418.871002] LR is at recalc_sigpending+0x18/0x7c
<4>[ 1418.879241] pc : [<c031d0e4>]    lr : [<c0037b84>]    psr: 80000013
<4>[ 1418.879241] sp : ce009ea0  ip : 00000000  fp : 00000000
<4>[ 1418.898284] r10: 00000000  r9 : 00000000  r8 : 00000000
<4>[ 1418.907287] r7 : c031d8d0  r6 : 6c6c7566  r5 : 00000000  r4 : cebe1600
<4>[ 1418.917663] r3 : 6f642820  r2 : 00000000  r1 : 00000000  r0 : 00000000
<4>[ 1418.928039] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment none
<4>[ 1418.939025] Control: 10c5387d  Table: 8e244019  DAC: 00000051
<0>[ 1418.948516] Process file-storage (pid: 53, stack limit = 0xce008210)
<0>[ 1418.958679] Stack: (0xce009ea0 to 0xce00a000)
<0>[ 1418.966735] 9ea0: 0000000f 00000000 00000000 00000b07 00000000
00000001 000003ff 00000001
<0>[ 1418.978973] 9ec0: ceb8a300 ceb8a300 00000000 c004841c 00000000
00000002 ce888000 c0451a50
<0>[ 1418.991180] 9ee0: ffffffff 00000000 00000000 00000008 cebe1600
00000001 c0717dd0 00000001
<0>[ 1419.003387] 9f00: 00000000 00000000 ce009f14 c044ddf4 00000000
c031c020 00000042 ce009f30
<0>[ 1419.015686] 9f20: ce009f30 00000000 cebe1600 c031d958 00000000
c044d864 a0000013 00000000
<0>[ 1419.027923] 9f40: cebe1600 c031d8d0 cebfa100 cebfa100 00000000
cebe1600 c031d8d0 00000000
<0>[ 1419.040130] 9f60: 00000000 00000000 00000000 c00474e4 dc4d900d
00000000 31bc92e7 cebe1600
<0>[ 1419.052429] 9f80: 00000000 ce009f84 ce009f84 00000000 ce009f90
ce009f90 ce009fac cebfa100
<0>[ 1419.064697] 9fa0: c0047418 00000000 00000000 c000f218 00000000
00000000 00000000 00000000
<0>[ 1419.076934] 9fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
<0>[ 1419.089050] 9fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00002000 30000891
<4>[ 1419.101043] [<c031d0e4>] (handle_exception) from [<c031d958>]
(fsg_main_thread+0x88/0x13dc)
<4>[ 1419.113189] [<c031d958>] (fsg_main_thread) from [<c00474e4>]
(kthread+0xcc/0xe0)
<4>[ 1419.124267] [<c00474e4>] (kthread) from [<c000f218>]
(ret_from_fork+0x14/0x3c)
<0>[ 1419.135101] Code: 1a000015 ea000040 e5946038 e0866285 (e5963014)
<4>[ 1419.330841] ---[ end trace 3377457e25b0732c ]---
<0>[ 1419.340972] Kernel panic - not syncing: Fatal exception

Quoted 2 lines

weirdly, I have that log only in mtdoops, but not in dmesg. However, after that oops "reboot" command does not hang, but reboots the device.

Quoted 8 lines

So, what is handle_exception + 0xa8 ? You can figure that out either with gdb or addr2line assuming your vmlinux has dbg symbols.

For gdb you would:

gdb vmlinux
(gdb) l *(handle_exception + 0xa8)

Yeah, sorry I didn't do it with the previous mail.

Quoted 11 lines

Reading symbols from /home/ivo/workspace/linux-upstream/github/fmg/linux-n900/vmlinux...done. (gdb) l *(handle_exception + 0xa8)
0xc031d0e4 is in handle_exception (drivers/usb/gadget/function/f_mass_storage.c:2373).
2368
2369 /* Cancel all the pending transfers */
2370 if (likely(common->fsg)) {
2371 for (i = 0; i < common->fsg_num_buffers; ++i) {
2372 bh = &common->buffhds[i];
2373 if (bh->inreq_busy)

so this would mean we have a race here where bh->inreq_busy is still set while bh->inreq was already freed, right ? I'll try to reproduce this with dwc3 and let you know.

Quoted 124 lines

Quoted 111 lines · Ivaylo Dimitrov

Quoted 100 lines

Quoted 95 lines · Ivaylo Dimitrov

Quoted 22 lines

Quoted 21 lines · Ivaylo Dimitrov

Quoted 20 lines · Ivaylo Dimitrov

Hi,

Quoted 8 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff hang issue on N900. Also, g_nokia is not a module in the config I use, so I guess the problem is not related whether gadgets are modular or not. Unfortunately I was not able to test reboot, as rootfs became corrupted after the first poweroff :( . So it looks like my theory that onenand corruption on N900 is because poweroff/reboot hangs is wrong.

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Ivo

Is there any progress on the issue?

Doing Nokia-N900:/sys/bus/platform/drivers/musb-hdrc# echo musb-hdrc.0.auto > unbind results in:

<1>[ 1418.511260] Unable to handle kernel paging request at virtual
address 6c6c757a
<7>[ 1418.677215] pvr: Xorg: cleaning up 49 unfreed resources
<1>[ 1418.683349] pgd = c0004000
<1>[ 1418.739959] [6c6c757a] *pgd=00000000
<0>[ 1418.746307] Internal error: Oops: 5 [#1] PREEMPT ARM
<4>[ 1418.753997] Modules linked in: sha256_generic hmac drbg ansi_cprng

ctr ccm vfat fat rfcomm sd_mod scsi_mod bnep bluetooth omaplfb pvrsrvkm ipv6 bq2415x_charger uinput radio_platform_si4713 joydev cmt_speech hsi_char video_bus_switch arc4 wl1251_spi wl1251 isp1704_charger gpio_keys mac80211 smc91x mii cfg80211 omap_wdt crc7 omap_sham tsc2005 tsc200x_core bq27xxx_battery_i2c si4713 adp1653 tsl2563 leds_lp5523 leds_lp55xx_common bq27xxx_battery rtc_twl twl4030_wdt et8ek8 ad5820 v4l2_common smiaregs twl4030_vibra videodev ff_memless lis3lv02d_i2c lis3lv02d media input_polldev omap_ssi_port ti_soc_thermal nokia_modem ssi_protocol omap_ssi hsi rx51_battery

<4>[ 1418.835906] CPU: 0 PID: 53 Comm: file-storage Not tainted
4.5.0-rc5+ #59
<4>[ 1418.846130] Hardware name: Nokia RX-51 board
<4>[ 1418.853820] task: ceb8a300 ti: ce008000 task.ti: ce008000
<4>[ 1418.862792] PC is at handle_exception+0xa8/0x418
<4>[ 1418.871002] LR is at recalc_sigpending+0x18/0x7c
<4>[ 1418.879241] pc : [<c031d0e4>]    lr : [<c0037b84>]    psr: 80000013
<4>[ 1418.879241] sp : ce009ea0  ip : 00000000  fp : 00000000
<4>[ 1418.898284] r10: 00000000  r9 : 00000000  r8 : 00000000
<4>[ 1418.907287] r7 : c031d8d0  r6 : 6c6c7566  r5 : 00000000  r4 : cebe1600
<4>[ 1418.917663] r3 : 6f642820  r2 : 00000000  r1 : 00000000  r0 : 00000000
<4>[ 1418.928039] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment none
<4>[ 1418.939025] Control: 10c5387d  Table: 8e244019  DAC: 00000051
<0>[ 1418.948516] Process file-storage (pid: 53, stack limit = 0xce008210)
<0>[ 1418.958679] Stack: (0xce009ea0 to 0xce00a000)
<0>[ 1418.966735] 9ea0: 0000000f 00000000 00000000 00000b07 00000000
00000001 000003ff 00000001
<0>[ 1418.978973] 9ec0: ceb8a300 ceb8a300 00000000 c004841c 00000000
00000002 ce888000 c0451a50
<0>[ 1418.991180] 9ee0: ffffffff 00000000 00000000 00000008 cebe1600
00000001 c0717dd0 00000001
<0>[ 1419.003387] 9f00: 00000000 00000000 ce009f14 c044ddf4 00000000
c031c020 00000042 ce009f30
<0>[ 1419.015686] 9f20: ce009f30 00000000 cebe1600 c031d958 00000000
c044d864 a0000013 00000000
<0>[ 1419.027923] 9f40: cebe1600 c031d8d0 cebfa100 cebfa100 00000000
cebe1600 c031d8d0 00000000
<0>[ 1419.040130] 9f60: 00000000 00000000 00000000 c00474e4 dc4d900d
00000000 31bc92e7 cebe1600
<0>[ 1419.052429] 9f80: 00000000 ce009f84 ce009f84 00000000 ce009f90
ce009f90 ce009fac cebfa100
<0>[ 1419.064697] 9fa0: c0047418 00000000 00000000 c000f218 00000000
00000000 00000000 00000000
<0>[ 1419.076934] 9fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
<0>[ 1419.089050] 9fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00002000 30000891
<4>[ 1419.101043] [<c031d0e4>] (handle_exception) from [<c031d958>]
(fsg_main_thread+0x88/0x13dc)
<4>[ 1419.113189] [<c031d958>] (fsg_main_thread) from [<c00474e4>]
(kthread+0xcc/0xe0)
<4>[ 1419.124267] [<c00474e4>] (kthread) from [<c000f218>]
(ret_from_fork+0x14/0x3c)
<0>[ 1419.135101] Code: 1a000015 ea000040 e5946038 e0866285 (e5963014)
<4>[ 1419.330841] ---[ end trace 3377457e25b0732c ]---
<0>[ 1419.340972] Kernel panic - not syncing: Fatal exception

Quoted 2 lines

weirdly, I have that log only in mtdoops, but not in dmesg. However, after that oops "reboot" command does not hang, but reboots the device.

Quoted 8 lines

So, what is handle_exception + 0xa8 ? You can figure that out either with gdb or addr2line assuming your vmlinux has dbg symbols.

For gdb you would:

gdb vmlinux
(gdb) l *(handle_exception + 0xa8)

Yeah, sorry I didn't do it with the previous mail.

Quoted 11 lines

Reading symbols from /home/ivo/workspace/linux-upstream/github/fmg/linux-n900/vmlinux...done. (gdb) l *(handle_exception + 0xa8)
0xc031d0e4 is in handle_exception (drivers/usb/gadget/function/f_mass_storage.c:2373).
2368
2369 /* Cancel all the pending transfers */
2370 if (likely(common->fsg)) {
2371 for (i = 0; i < common->fsg_num_buffers; ++i) {
2372 bh = &common->buffhds[i];
2373 if (bh->inreq_busy)

Quoted 4 lines

so this would mean we have a race here where bh->inreq_busy is still set while bh->inreq was already freed, right ? I'll try to reproduce this with dwc3 and let you know.

I am not sure this is the case, what I see here is fsg_bind() and fsg_unbind() called twice - "musb-hdrc loaded" -> fsg_bind() -> fsg_bind(), "musb-hdrc unbind through sysfs" -> fsg_unbind() -> fsg_unbind(). That seems to come from g_nokia being probed (successfully) twice. No idea if this is normal - IIUC fsg main thread

seems to be created twice :). Maybe the problem is that the first time musb-hdrc is probed it fails with -EPROBE_DEFER, however that failure is after gadget drivers got loaded and noone unloads them.

Just some wild guesses based on my memories as I've lost the logs (power outage). For sure I can recreate them if needed.

Hi,

Quoted 129 lines · Ivaylo Dimitrov

Quoted 128 lines

Quoted 111 lines · Ivaylo Dimitrov

Quoted 100 lines

Quoted 95 lines · Ivaylo Dimitrov

Quoted 22 lines

Quoted 21 lines · Ivaylo Dimitrov

Quoted 20 lines · Ivaylo Dimitrov

Hi,

Quoted 8 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff hang issue on N900. Also, g_nokia is not a module in the config I use, so I guess the problem is not related whether gadgets are modular or not. Unfortunately I was not able to test reboot, as rootfs became corrupted after the first poweroff :( . So it looks like my theory that onenand corruption on N900 is because poweroff/reboot hangs is wrong.

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Ivo

Is there any progress on the issue?

Doing Nokia-N900:/sys/bus/platform/drivers/musb-hdrc# echo musb-hdrc.0.auto > unbind results in:

<1>[ 1418.511260] Unable to handle kernel paging request at virtual
address 6c6c757a
<7>[ 1418.677215] pvr: Xorg: cleaning up 49 unfreed resources
<1>[ 1418.683349] pgd = c0004000
<1>[ 1418.739959] [6c6c757a] *pgd=00000000
<0>[ 1418.746307] Internal error: Oops: 5 [#1] PREEMPT ARM
<4>[ 1418.753997] Modules linked in: sha256_generic hmac drbg ansi_cprng

ctr ccm vfat fat rfcomm sd_mod scsi_mod bnep bluetooth omaplfb pvrsrvkm ipv6 bq2415x_charger uinput radio_platform_si4713 joydev cmt_speech hsi_char video_bus_switch arc4 wl1251_spi wl1251 isp1704_charger gpio_keys mac80211 smc91x mii cfg80211 omap_wdt crc7 omap_sham tsc2005 tsc200x_core bq27xxx_battery_i2c si4713 adp1653 tsl2563 leds_lp5523 leds_lp55xx_common bq27xxx_battery rtc_twl twl4030_wdt et8ek8 ad5820 v4l2_common smiaregs twl4030_vibra videodev ff_memless lis3lv02d_i2c lis3lv02d media input_polldev omap_ssi_port ti_soc_thermal nokia_modem ssi_protocol omap_ssi hsi rx51_battery

<4>[ 1418.835906] CPU: 0 PID: 53 Comm: file-storage Not tainted
4.5.0-rc5+ #59
<4>[ 1418.846130] Hardware name: Nokia RX-51 board
<4>[ 1418.853820] task: ceb8a300 ti: ce008000 task.ti: ce008000
<4>[ 1418.862792] PC is at handle_exception+0xa8/0x418
<4>[ 1418.871002] LR is at recalc_sigpending+0x18/0x7c
<4>[ 1418.879241] pc : [<c031d0e4>]    lr : [<c0037b84>]    psr: 80000013
<4>[ 1418.879241] sp : ce009ea0  ip : 00000000  fp : 00000000
<4>[ 1418.898284] r10: 00000000  r9 : 00000000  r8 : 00000000
<4>[ 1418.907287] r7 : c031d8d0  r6 : 6c6c7566  r5 : 00000000  r4 : cebe1600
<4>[ 1418.917663] r3 : 6f642820  r2 : 00000000  r1 : 00000000  r0 : 00000000
<4>[ 1418.928039] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment none
<4>[ 1418.939025] Control: 10c5387d  Table: 8e244019  DAC: 00000051
<0>[ 1418.948516] Process file-storage (pid: 53, stack limit = 0xce008210)
<0>[ 1418.958679] Stack: (0xce009ea0 to 0xce00a000)
<0>[ 1418.966735] 9ea0: 0000000f 00000000 00000000 00000b07 00000000
00000001 000003ff 00000001
<0>[ 1418.978973] 9ec0: ceb8a300 ceb8a300 00000000 c004841c 00000000
00000002 ce888000 c0451a50
<0>[ 1418.991180] 9ee0: ffffffff 00000000 00000000 00000008 cebe1600
00000001 c0717dd0 00000001
<0>[ 1419.003387] 9f00: 00000000 00000000 ce009f14 c044ddf4 00000000
c031c020 00000042 ce009f30
<0>[ 1419.015686] 9f20: ce009f30 00000000 cebe1600 c031d958 00000000
c044d864 a0000013 00000000
<0>[ 1419.027923] 9f40: cebe1600 c031d8d0 cebfa100 cebfa100 00000000
cebe1600 c031d8d0 00000000
<0>[ 1419.040130] 9f60: 00000000 00000000 00000000 c00474e4 dc4d900d
00000000 31bc92e7 cebe1600
<0>[ 1419.052429] 9f80: 00000000 ce009f84 ce009f84 00000000 ce009f90
ce009f90 ce009fac cebfa100
<0>[ 1419.064697] 9fa0: c0047418 00000000 00000000 c000f218 00000000
00000000 00000000 00000000
<0>[ 1419.076934] 9fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
<0>[ 1419.089050] 9fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00002000 30000891
<4>[ 1419.101043] [<c031d0e4>] (handle_exception) from [<c031d958>]
(fsg_main_thread+0x88/0x13dc)
<4>[ 1419.113189] [<c031d958>] (fsg_main_thread) from [<c00474e4>]
(kthread+0xcc/0xe0)
<4>[ 1419.124267] [<c00474e4>] (kthread) from [<c000f218>]
(ret_from_fork+0x14/0x3c)
<0>[ 1419.135101] Code: 1a000015 ea000040 e5946038 e0866285 (e5963014)
<4>[ 1419.330841] ---[ end trace 3377457e25b0732c ]---
<0>[ 1419.340972] Kernel panic - not syncing: Fatal exception

Quoted 2 lines

weirdly, I have that log only in mtdoops, but not in dmesg. However, after that oops "reboot" command does not hang, but reboots the device.

Quoted 8 lines

So, what is handle_exception + 0xa8 ? You can figure that out either with gdb or addr2line assuming your vmlinux has dbg symbols.

For gdb you would:

gdb vmlinux
(gdb) l *(handle_exception + 0xa8)

Yeah, sorry I didn't do it with the previous mail.

Quoted 11 lines

Reading symbols from /home/ivo/workspace/linux-upstream/github/fmg/linux-n900/vmlinux...done. (gdb) l *(handle_exception + 0xa8)
0xc031d0e4 is in handle_exception (drivers/usb/gadget/function/f_mass_storage.c:2373).
2368
2369 /* Cancel all the pending transfers */
2370 if (likely(common->fsg)) {
2371 for (i = 0; i < common->fsg_num_buffers; ++i) {
2372 bh = &common->buffhds[i];
2373 if (bh->inreq_busy)

so this would mean we have a race here where bh->inreq_busy is still set while bh->inreq was already freed, right ? I'll try to reproduce this with dwc3 and let you know.

Quoted 5 lines

I am not sure this is the case, what I see here is fsg_bind() and fsg_unbind() called twice - "musb-hdrc loaded" -> fsg_bind() -> fsg_bind(), "musb-hdrc unbind through sysfs" -> fsg_unbind() -> fsg_unbind(). That seems to come from g_nokia being probed (successfully) twice. No idea if this is normal - IIUC fsg main thread

do you have two interfaces with mass storage ?

Quoted 3 lines

seems to be created twice :). Maybe the problem is that the first time musb-hdrc is probed it fails with -EPROBE_DEFER, however that failure is after gadget drivers got loaded and noone unloads them.

gadget drivers will get added to a pending list, then later they'll bind. But they shouldn't bind() twice, unless there are multiple interfaces for them.

Quoted 2 lines

Just some wild guesses based on my memories as I've lost the logs (power outage). For sure I can recreate them if needed.

okay.

Quoted 144 lines · Felipe Balbi

Hi,

Quoted 140 lines · Ivaylo Dimitrov

Quoted 130 lines

Quoted 117 lines · Ivaylo Dimitrov

Quoted 106 lines

Quoted 97 lines · Ivaylo Dimitrov

Quoted 25 lines

Quoted 24 lines · Ivaylo Dimitrov

Quoted 23 lines · Ivaylo Dimitrov

Hi,

Quoted 9 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff hang issue on N900. Also, g_nokia is not a module in the config I use, so I guess the problem is not related whether gadgets are modular or not. Unfortunately I was not able to test reboot, as rootfs became corrupted after the first poweroff :( . So it looks like my theory that onenand corruption on N900 is because poweroff/reboot hangs is wrong.

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

Ivo

Is there any progress on the issue?

Doing Nokia-N900:/sys/bus/platform/drivers/musb-hdrc# echo musb-hdrc.0.auto > unbind results in:

<1>[ 1418.511260] Unable to handle kernel paging request at
virtual address 6c6c757a
<7>[ 1418.677215] pvr: Xorg: cleaning up 49 unfreed resources
<1>[ 1418.683349] pgd = c0004000
<1>[ 1418.739959] [6c6c757a] *pgd=00000000
<0>[ 1418.746307] Internal error: Oops: 5 [#1] PREEMPT ARM
<4>[ 1418.753997] Modules linked in: sha256_generic hmac drbg

ansi_cprng ctr ccm vfat fat rfcomm sd_mod scsi_mod bnep bluetooth omaplfb pvrsrvkm ipv6 bq2415x_charger uinput radio_platform_si4713 joydev cmt_speech hsi_char video_bus_switch arc4 wl1251_spi wl1251 isp1704_charger gpio_keys mac80211 smc91x mii cfg80211 omap_wdt crc7 omap_sham tsc2005 tsc200x_core bq27xxx_battery_i2c si4713 adp1653 tsl2563 leds_lp5523 leds_lp55xx_common bq27xxx_battery rtc_twl twl4030_wdt et8ek8 ad5820 v4l2_common smiaregs twl4030_vibra videodev ff_memless lis3lv02d_i2c lis3lv02d media input_polldev omap_ssi_port ti_soc_thermal nokia_modem ssi_protocol omap_ssi hsi rx51_battery

<4>[ 1418.835906] CPU: 0 PID: 53 Comm: file-storage Not
tainted 4.5.0-rc5+ #59
<4>[ 1418.846130] Hardware name: Nokia RX-51 board
<4>[ 1418.853820] task: ceb8a300 ti: ce008000 task.ti:
ce008000 <4>[ 1418.862792] PC is at
handle_exception+0xa8/0x418 <4>[ 1418.871002] LR is at
recalc_sigpending+0x18/0x7c <4>[ 1418.879241] pc :
[<c031d0e4>]    lr : [<c0037b84>]    psr: 80000013 <4>[
1418.879241] sp : ce009ea0  ip : 00000000  fp : 00000000 <4>[
1418.898284] r10: 00000000  r9 : 00000000  r8 : 00000000 <4>[
1418.907287] r7 : c031d8d0  r6 : 6c6c7566  r5 : 00000000  r4
: cebe1600 <4>[ 1418.917663] r3 : 6f642820  r2 : 00000000  r1
: 00000000  r0 : 00000000 <4>[ 1418.928039] Flags: Nzcv  IRQs
on  FIQs on  Mode SVC_32  ISA ARM Segment none
<4>[ 1418.939025] Control: 10c5387d  Table: 8e244019  DAC:
00000051 <0>[ 1418.948516] Process file-storage (pid: 53,
stack limit = 0xce008210) <0>[ 1418.958679] Stack:
(0xce009ea0 to 0xce00a000)
<0>[ 1418.966735] 9ea0: 0000000f 00000000 00000000 00000b07
00000000 00000001 000003ff 00000001
<0>[ 1418.978973] 9ec0: ceb8a300 ceb8a300 00000000 c004841c
00000000 00000002 ce888000 c0451a50
<0>[ 1418.991180] 9ee0: ffffffff 00000000 00000000 00000008
cebe1600 00000001 c0717dd0 00000001
<0>[ 1419.003387] 9f00: 00000000 00000000 ce009f14 c044ddf4
00000000 c031c020 00000042 ce009f30
<0>[ 1419.015686] 9f20: ce009f30 00000000 cebe1600 c031d958
00000000 c044d864 a0000013 00000000
<0>[ 1419.027923] 9f40: cebe1600 c031d8d0 cebfa100 cebfa100
00000000 cebe1600 c031d8d0 00000000
<0>[ 1419.040130] 9f60: 00000000 00000000 00000000 c00474e4
dc4d900d 00000000 31bc92e7 cebe1600
<0>[ 1419.052429] 9f80: 00000000 ce009f84 ce009f84 00000000
ce009f90 ce009f90 ce009fac cebfa100
<0>[ 1419.064697] 9fa0: c0047418 00000000 00000000 c000f218
00000000 00000000 00000000 00000000
<0>[ 1419.076934] 9fc0: 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
<0>[ 1419.089050] 9fe0: 00000000 00000000 00000000 00000000
00000013 00000000 00002000 30000891
<4>[ 1419.101043] [<c031d0e4>] (handle_exception) from
[<c031d958>] (fsg_main_thread+0x88/0x13dc)
<4>[ 1419.113189] [<c031d958>] (fsg_main_thread) from
[<c00474e4>] (kthread+0xcc/0xe0)
<4>[ 1419.124267] [<c00474e4>] (kthread) from [<c000f218>]
(ret_from_fork+0x14/0x3c)
<0>[ 1419.135101] Code: 1a000015 ea000040 e5946038 e0866285

Quoted 7 lines

(e5963014) <4>[ 1419.330841] ---[ end trace 3377457e25b0732c ]--- <0>[ 1419.340972] Kernel panic - not syncing: Fatal exception

weirdly, I have that log only in mtdoops, but not in dmesg. However, after that oops "reboot" command does not hang, but reboots the device.

Quoted 8 lines

So, what is handle_exception + 0xa8 ? You can figure that out either with gdb or addr2line assuming your vmlinux has dbg symbols.

For gdb you would:

gdb vmlinux
(gdb) l *(handle_exception + 0xa8)

Yeah, sorry I didn't do it with the previous mail.

Quoted 11 lines

Reading symbols from /home/ivo/workspace/linux-upstream/github/fmg/linux-n900/vmlinux ...done. (gdb) l *(handle_exception + 0xa8)
0xc031d0e4 is in handle_exception (drivers/usb/gadget/function/f_mass_storage.c:2373). 2368
2369 /* Cancel all the pending transfers */
2370 if (likely(common->fsg)) {
2371 for (i = 0; i < common->fsg_num_buffers; ++i) {
2372 bh = &common->buffhds[i];
2373 if (bh->inreq_busy)

Quoted 3 lines

so this would mean we have a race here where bh->inreq_busy is still set while bh->inreq was already freed, right ? I'll try to reproduce this with dwc3 and let you know.

I am not sure this is the case, what I see here is fsg_bind() and fsg_unbind() called twice - "musb-hdrc loaded" -> fsg_bind() -> fsg_bind(), "musb-hdrc unbind through sysfs" -> fsg_unbind() -> fsg_unbind(). That seems to come from g_nokia being probed (successfully) twice. No idea if this is normal - IIUC fsg main thread

Quoted 1 line

do you have two interfaces with mass storage ?

There are 2 LUNs, not sure what you mean by 2 interfaces.

Pali ^^^ ?

Quoted 154 lines · Felipe Balbi

Hi,

Quoted 150 lines · Ivaylo Dimitrov

Quoted 149 lines

Quoted 133 lines · Ivaylo Dimitrov

Quoted 119 lines

Quoted 113 lines · Ivaylo Dimitrov

Quoted 30 lines

Quoted 29 lines · Ivaylo Dimitrov

Quoted 28 lines · Ivaylo Dimitrov

Hi,

Quoted 10 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot
hangs the system. This happens at least with v4.4, and I've reproduced
it with dwc3 and musb so it seems to be generic.

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff
hang issue on N900. Also, g_nokia is not a module in the config I use,
so I guess the problem is not related whether gadgets are modular or
not. Unfortunately I was not able to test reboot, as rootfs became
corrupted after the first poweroff :( . So it looks like my theory that
onenand corruption on N900 is because poweroff/reboot hangs is wrong.

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Ivo

Is there any progress on the issue?

Doing Nokia-N900:/sys/bus/platform/drivers/musb-hdrc# echo musb-hdrc.0.auto > unbind results in:

<1>[ 1418.511260] Unable to handle kernel paging request at virtual
address 6c6c757a
<7>[ 1418.677215] pvr: Xorg: cleaning up 49 unfreed resources
<1>[ 1418.683349] pgd = c0004000
<1>[ 1418.739959] [6c6c757a] *pgd=00000000
<0>[ 1418.746307] Internal error: Oops: 5 [#1] PREEMPT ARM
<4>[ 1418.753997] Modules linked in: sha256_generic hmac drbg

ansi_cprng
ctr ccm vfat fat rfcomm sd_mod scsi_mod bnep bluetooth omaplfb pvrsrvkm
ipv6 bq2415x_charger uinput radio_platform_si4713 joydev cmt_speech hsi_char video_bus_switch arc4 wl1251_spi wl1251 isp1704_charger gpio_keys mac80211 smc91x mii cfg80211 omap_wdt crc7 omap_sham tsc2005
tsc200x_core bq27xxx_battery_i2c si4713 adp1653 tsl2563 leds_lp5523 leds_lp55xx_common bq27xxx_battery rtc_twl twl4030_wdt et8ek8 ad5820 v4l2_common smiaregs twl4030_vibra videodev ff_memless lis3lv02d_i2c lis3lv02d media input_polldev omap_ssi_port ti_soc_thermal nokia_modem
ssi_protocol omap_ssi hsi rx51_battery

<4>[ 1418.835906] CPU: 0 PID: 53 Comm: file-storage Not tainted
4.5.0-rc5+ #59
<4>[ 1418.846130] Hardware name: Nokia RX-51 board
<4>[ 1418.853820] task: ceb8a300 ti: ce008000 task.ti: ce008000
<4>[ 1418.862792] PC is at handle_exception+0xa8/0x418
<4>[ 1418.871002] LR is at recalc_sigpending+0x18/0x7c
<4>[ 1418.879241] pc : [<c031d0e4>]    lr : [<c0037b84>]    psr:
80000013
<4>[ 1418.879241] sp : ce009ea0  ip : 00000000  fp : 00000000
<4>[ 1418.898284] r10: 00000000  r9 : 00000000  r8 : 00000000
<4>[ 1418.907287] r7 : c031d8d0  r6 : 6c6c7566  r5 : 00000000  r4
: cebe1600
<4>[ 1418.917663] r3 : 6f642820  r2 : 00000000  r1 : 00000000  r0
: 00000000
<4>[ 1418.928039] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA
ARM
Segment none
<4>[ 1418.939025] Control: 10c5387d  Table: 8e244019  DAC: 00000051
<0>[ 1418.948516] Process file-storage (pid: 53, stack limit =
0xce008210)
<0>[ 1418.958679] Stack: (0xce009ea0 to 0xce00a000)
<0>[ 1418.966735] 9ea0: 0000000f 00000000 00000000 00000b07 00000000
00000001 000003ff 00000001
<0>[ 1418.978973] 9ec0: ceb8a300 ceb8a300 00000000 c004841c 00000000
00000002 ce888000 c0451a50
<0>[ 1418.991180] 9ee0: ffffffff 00000000 00000000 00000008 cebe1600
00000001 c0717dd0 00000001
<0>[ 1419.003387] 9f00: 00000000 00000000 ce009f14 c044ddf4 00000000
c031c020 00000042 ce009f30
<0>[ 1419.015686] 9f20: ce009f30 00000000 cebe1600 c031d958 00000000
c044d864 a0000013 00000000
<0>[ 1419.027923] 9f40: cebe1600 c031d8d0 cebfa100 cebfa100 00000000
cebe1600 c031d8d0 00000000
<0>[ 1419.040130] 9f60: 00000000 00000000 00000000 c00474e4 dc4d900d
00000000 31bc92e7 cebe1600
<0>[ 1419.052429] 9f80: 00000000 ce009f84 ce009f84 00000000 ce009f90
ce009f90 ce009fac cebfa100
<0>[ 1419.064697] 9fa0: c0047418 00000000 00000000 c000f218 00000000
00000000 00000000 00000000
<0>[ 1419.076934] 9fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
<0>[ 1419.089050] 9fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00002000 30000891
<4>[ 1419.101043] [<c031d0e4>] (handle_exception) from [<c031d958>]
(fsg_main_thread+0x88/0x13dc)
<4>[ 1419.113189] [<c031d958>] (fsg_main_thread) from [<c00474e4>]
(kthread+0xcc/0xe0)
<4>[ 1419.124267] [<c00474e4>] (kthread) from [<c000f218>]
(ret_from_fork+0x14/0x3c)
<0>[ 1419.135101] Code: 1a000015 ea000040 e5946038 e0866285
(e5963014)
<4>[ 1419.330841] ---[ end trace 3377457e25b0732c ]---
<0>[ 1419.340972] Kernel panic - not syncing: Fatal exception

Quoted 3 lines

weirdly, I have that log only in mtdoops, but not in dmesg. However, after that oops "reboot" command does not hang, but reboots the device.

Quoted 8 lines

So, what is handle_exception + 0xa8 ? You can figure that out either with gdb or addr2line assuming your vmlinux has dbg symbols.

For gdb you would:

gdb vmlinux
(gdb) l *(handle_exception + 0xa8)

Yeah, sorry I didn't do it with the previous mail.

Reading symbols from /home/ivo/workspace/linux-upstream/github/fmg/linux-n900/vmlinux...done.

Quoted 9 lines

(gdb) l *(handle_exception + 0xa8) 0xc031d0e4 is in handle_exception (drivers/usb/gadget/function/f_mass_storage.c:2373). 2368
2369 /* Cancel all the pending transfers */
2370 if (likely(common->fsg)) {
2371 for (i = 0; i < common->fsg_num_buffers; ++i) {
2372 bh = &common->buffhds[i];
2373 if (bh->inreq_busy)

so this would mean we have a race here where bh->inreq_busy is still set
while bh->inreq was already freed, right ? I'll try to reproduce this with dwc3 and let you know.

Quoted 8 lines

Quoted 5 lines

I am not sure this is the case, what I see here is fsg_bind() and fsg_unbind() called twice - "musb-hdrc loaded" -> fsg_bind() -> fsg_bind(), "musb-hdrc unbind through sysfs" -> fsg_unbind() -> fsg_unbind(). That seems to come from g_nokia being probed (successfully) twice. No idea if this is normal - IIUC fsg main thread

do you have two interfaces with mass storage ?

There are 2 LUNs, not sure what you mean by 2 interfaces.

Pali ^^^ ?

Quoted 8 lines

Quoted 3 lines

seems to be created twice :). Maybe the problem is that the first time musb-hdrc is probed it fails with -EPROBE_DEFER, however that failure is after gadget drivers got loaded and noone unloads them.

gadget drivers will get added to a pending list, then later they'll bind. But they shouldn't bind() twice, unless there are multiple interfaces for them.

Well, then it seems we have problem, as the 2 unbind() calls are with one and the same "common" pointer (again, from memory).

Quoted 4 lines

Quoted 2 lines

Just some wild guesses based on my memories as I've lost the logs (power outage). For sure I can recreate them if needed.

okay.

I will redo dump_stack() and printks and will provide logs as soon as I have some time, so to stop counting on my memories.

Quoted 199 lines · Ivaylo Dimitrov

Quoted 170 lines · Felipe Balbi

Hi,

Quoted 166 lines · Ivaylo Dimitrov

Quoted 165 lines

Quoted 149 lines · Ivaylo Dimitrov

Quoted 134 lines

Quoted 127 lines · Ivaylo Dimitrov

Quoted 31 lines

Quoted 30 lines · Ivaylo Dimitrov

Quoted 29 lines · Ivaylo Dimitrov

Hi,

Quoted 11 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot
hangs the system. This happens at least with v4.4, and I've reproduced
it with dwc3 and musb so it seems to be generic.

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff
hang issue on N900. Also, g_nokia is not a module in the config I use,
so I guess the problem is not related whether gadgets are modular or
not. Unfortunately I was not able to test reboot, as rootfs became
corrupted after the first poweroff :( . So it looks like my theory that
onenand corruption on N900 is because poweroff/reboot hangs is wrong.

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Ivo

Is there any progress on the issue?

Doing Nokia-N900:/sys/bus/platform/drivers/musb-hdrc# echo musb-hdrc.0.auto > unbind results in:

<1>[ 1418.511260] Unable to handle kernel paging request at virtual
address 6c6c757a
<7>[ 1418.677215] pvr: Xorg: cleaning up 49 unfreed resources
<1>[ 1418.683349] pgd = c0004000
<1>[ 1418.739959] [6c6c757a] *pgd=00000000
<0>[ 1418.746307] Internal error: Oops: 5 [#1] PREEMPT ARM
<4>[ 1418.753997] Modules linked in: sha256_generic hmac drbg

ansi_cprng
ctr ccm vfat fat rfcomm sd_mod scsi_mod bnep bluetooth omaplfb pvrsrvkm
ipv6 bq2415x_charger uinput radio_platform_si4713 joydev cmt_speech hsi_char video_bus_switch arc4 wl1251_spi wl1251 isp1704_charger gpio_keys mac80211 smc91x mii cfg80211 omap_wdt crc7 omap_sham tsc2005
tsc200x_core bq27xxx_battery_i2c si4713 adp1653 tsl2563 leds_lp5523 leds_lp55xx_common bq27xxx_battery rtc_twl twl4030_wdt et8ek8 ad5820
v4l2_common smiaregs twl4030_vibra videodev ff_memless lis3lv02d_i2c
lis3lv02d media input_polldev omap_ssi_port ti_soc_thermal nokia_modem
ssi_protocol omap_ssi hsi rx51_battery

<4>[ 1418.835906] CPU: 0 PID: 53 Comm: file-storage Not tainted
4.5.0-rc5+ #59
<4>[ 1418.846130] Hardware name: Nokia RX-51 board
<4>[ 1418.853820] task: ceb8a300 ti: ce008000 task.ti: ce008000
<4>[ 1418.862792] PC is at handle_exception+0xa8/0x418
<4>[ 1418.871002] LR is at recalc_sigpending+0x18/0x7c
<4>[ 1418.879241] pc : [<c031d0e4>]    lr : [<c0037b84>]    psr:
80000013
<4>[ 1418.879241] sp : ce009ea0  ip : 00000000  fp : 00000000
<4>[ 1418.898284] r10: 00000000  r9 : 00000000  r8 : 00000000
<4>[ 1418.907287] r7 : c031d8d0  r6 : 6c6c7566  r5 : 00000000  r4
: cebe1600
<4>[ 1418.917663] r3 : 6f642820  r2 : 00000000  r1 : 00000000  r0
: 00000000
<4>[ 1418.928039] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA
ARM
Segment none
<4>[ 1418.939025] Control: 10c5387d  Table: 8e244019  DAC: 00000051
<0>[ 1418.948516] Process file-storage (pid: 53, stack limit =
0xce008210)
<0>[ 1418.958679] Stack: (0xce009ea0 to 0xce00a000)
<0>[ 1418.966735] 9ea0: 0000000f 00000000 00000000 00000b07
00000000
00000001 000003ff 00000001
<0>[ 1418.978973] 9ec0: ceb8a300 ceb8a300 00000000 c004841c
00000000
00000002 ce888000 c0451a50
<0>[ 1418.991180] 9ee0: ffffffff 00000000 00000000 00000008
cebe1600
00000001 c0717dd0 00000001
<0>[ 1419.003387] 9f00: 00000000 00000000 ce009f14 c044ddf4
00000000
c031c020 00000042 ce009f30
<0>[ 1419.015686] 9f20: ce009f30 00000000 cebe1600 c031d958
00000000
c044d864 a0000013 00000000
<0>[ 1419.027923] 9f40: cebe1600 c031d8d0 cebfa100 cebfa100
00000000
cebe1600 c031d8d0 00000000
<0>[ 1419.040130] 9f60: 00000000 00000000 00000000 c00474e4
dc4d900d
00000000 31bc92e7 cebe1600
<0>[ 1419.052429] 9f80: 00000000 ce009f84 ce009f84 00000000
ce009f90
ce009f90 ce009fac cebfa100
<0>[ 1419.064697] 9fa0: c0047418 00000000 00000000 c000f218
00000000
00000000 00000000 00000000
<0>[ 1419.076934] 9fc0: 00000000 00000000 00000000 00000000
00000000
00000000 00000000 00000000
<0>[ 1419.089050] 9fe0: 00000000 00000000 00000000 00000000
00000013
00000000 00002000 30000891
<4>[ 1419.101043] [<c031d0e4>] (handle_exception) from [<c031d958>]
(fsg_main_thread+0x88/0x13dc)
<4>[ 1419.113189] [<c031d958>] (fsg_main_thread) from [<c00474e4>]
(kthread+0xcc/0xe0)
<4>[ 1419.124267] [<c00474e4>] (kthread) from [<c000f218>]
(ret_from_fork+0x14/0x3c)
<0>[ 1419.135101] Code: 1a000015 ea000040 e5946038 e0866285
(e5963014)
<4>[ 1419.330841] ---[ end trace 3377457e25b0732c ]---
<0>[ 1419.340972] Kernel panic - not syncing: Fatal exception

Quoted 4 lines

weirdly, I have that log only in mtdoops, but not in dmesg. However,
after that oops "reboot" command does not hang, but reboots the device.

Quoted 8 lines

So, what is handle_exception + 0xa8 ? You can figure that out either with gdb or addr2line assuming your vmlinux has dbg symbols.

For gdb you would:

gdb vmlinux
(gdb) l *(handle_exception + 0xa8)

Yeah, sorry I didn't do it with the previous mail.

Reading symbols from /home/ivo/workspace/linux-upstream/github/fmg/linux-n900/vmlinux...done.

Quoted 9 lines

(gdb) l *(handle_exception + 0xa8) 0xc031d0e4 is in handle_exception (drivers/usb/gadget/function/f_mass_storage.c:2373). 2368
2369 /* Cancel all the pending transfers */
2370 if (likely(common->fsg)) {
2371 for (i = 0; i < common->fsg_num_buffers; ++i) {
2372 bh = &common->buffhds[i];
2373 if (bh->inreq_busy)

so this would mean we have a race here where bh->inreq_busy is still set
while bh->inreq was already freed, right ? I'll try to reproduce this with dwc3 and let you know.

Quoted 8 lines

Quoted 5 lines

I am not sure this is the case, what I see here is fsg_bind() and fsg_unbind() called twice - "musb-hdrc loaded" -> fsg_bind() -> fsg_bind(), "musb-hdrc unbind through sysfs" -> fsg_unbind() -> fsg_unbind(). That seems to come from g_nokia being probed (successfully) twice. No idea if this is normal - IIUC fsg main thread

do you have two interfaces with mass storage ?

There are 2 LUNs, not sure what you mean by 2 interfaces.

Pali ^^^ ?

Quoted 9 lines

Quoted 4 lines

seems to be created twice :). Maybe the problem is that the first time musb-hdrc is probed it fails with -EPROBE_DEFER, however that failure is
after gadget drivers got loaded and noone unloads them.

gadget drivers will get added to a pending list, then later they'll bind. But they shouldn't bind() twice, unless there are multiple interfaces for them.

Well, then it seems we have problem, as the 2 unbind() calls are with one and the same "common" pointer (again, from memory).

Quoted 9 lines

Quoted 5 lines

Quoted 3 lines

Just some wild guesses based on my memories as I've lost the logs (power
outage). For sure I can recreate them if needed.

okay.

I will redo dump_stack() and printks and will provide logs as soon as I have some time, so to stop counting on my memories.

Please find attached the relevant logs. It really seems that g_nokia is probed twice, with all the gadgets in it created two times. I am starting to suspect 855ed04a3758b205e84b269f92d26ab36ed8e2f7 ("usb:
gadget: udc-core: independent registration of gadgets and gadget drivers") has something to do with the problem, though reverting it resulted in g_nokia not being probed at all :)

Ivo

Quoted 12 lines

Quoted 8 lines

Quoted 3 lines

seems to be created twice :). Maybe the problem is that the first time musb-hdrc is probed it fails with -EPROBE_DEFER, however that failure is after gadget drivers got loaded and noone unloads them.

gadget drivers will get added to a pending list, then later they'll bind. But they shouldn't bind() twice, unless there are multiple interfaces for them.

Well, then it seems we have problem, as the 2 unbind() calls are with one and the same "common" pointer (again, from memory).

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

Just some wild guesses based on my memories as I've lost the logs (power outage). For sure I can recreate them if needed.

okay.

I will redo dump_stack() and printks and will provide logs as soon as I have some time, so to stop counting on my memories.

Please find attached the relevant logs. It really seems that g_nokia is probed twice, with all the gadgets in it created two times. I am starting to suspect 855ed04a3758b205e84b269f92d26ab36ed8e2f7 ("usb:
gadget: udc-core: independent registration of gadgets and gadget drivers") has something to do with the problem, though reverting it resulted in g_nokia not being probed at all :)

Quoted 21 lines · Ivaylo Dimitrov

Quoted 12 lines

Quoted 8 lines

Quoted 3 lines

seems to be created twice :). Maybe the problem is that the first time musb-hdrc is probed it fails with -EPROBE_DEFER, however that failure is after gadget drivers got loaded and noone unloads them.

gadget drivers will get added to a pending list, then later they'll bind. But they shouldn't bind() twice, unless there are multiple interfaces for them.

Well, then it seems we have problem, as the 2 unbind() calls are with one and the same "common" pointer (again, from memory).

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

Just some wild guesses based on my memories as I've lost the logs (power outage). For sure I can recreate them if needed.

okay.

I will redo dump_stack() and printks and will provide logs as soon as I have some time, so to stop counting on my memories.

Quoted 6 lines

Please find attached the relevant logs. It really seems that g_nokia is probed twice, with all the gadgets in it created two times. I am starting to suspect 855ed04a3758b205e84b269f92d26ab36ed8e2f7 ("usb:
gadget: udc-core: independent registration of gadgets and gadget drivers") has something to do with the problem, though reverting it resulted in g_nokia not being probed at all :)

The problem is not caused by nokia_bind() getting called twice. The log clearly shows that nokia_bind() is called only once, but it calls usb_add_config() from two different places:

Jan  1 02:00:10 Nokia-N900 kernel: [    8.002838] [<c040c5b4>] (usb_add_config) from [<c041b274>] (nokia_bind+0x160/0x2f0)
Jan  1 02:00:10 Nokia-N900 kernel: [    8.014526] [<c041b274>] (nokia_bind) from [<c040e128>] (composite_bind+0x68/0x1a0)
...
Jan  1 02:00:10 Nokia-N900 kernel: [    8.381286] [<c040c5b4>] (usb_add_config) from [<c041b28c>] (nokia_bind+0x178/0x2f0)
Jan  1 02:00:10 Nokia-N900 kernel: [    8.394348] [<c041b28c>] (nokia_bind) from [<c040e128>] (composite_bind+0x68/0x1a0)

Everything else along the two pathways is the same, so this is where the multiple binds come from. And indeed, looking at the code in nokia_bind() you can see the two calls:

        /* finally register the configuration */
        status = usb_add_config(cdev, &nokia_config_500ma_driver,
                        nokia_bind_config);
        if (status < 0)
                goto err_msg_luns;

        status = usb_add_config(cdev, &nokia_config_100ma_driver,
                        nokia_bind_config);

This isn't supposed to cause any problems. The two instances should never run at the same time, because they belong to different configs.

Quoted 21 lines · Ivaylo Dimitrov

Quoted 12 lines

Quoted 8 lines

Quoted 3 lines

seems to be created twice :). Maybe the problem is that the first time musb-hdrc is probed it fails with -EPROBE_DEFER, however that failure is after gadget drivers got loaded and noone unloads them.

gadget drivers will get added to a pending list, then later they'll bind. But they shouldn't bind() twice, unless there are multiple interfaces for them.

Well, then it seems we have problem, as the 2 unbind() calls are with one and the same "common" pointer (again, from memory).

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

Just some wild guesses based on my memories as I've lost the logs (power outage). For sure I can recreate them if needed.

okay.

I will redo dump_stack() and printks and will provide logs as soon as I have some time, so to stop counting on my memories.

Quoted 6 lines

Please find attached the relevant logs. It really seems that g_nokia is probed twice, with all the gadgets in it created two times. I am starting to suspect 855ed04a3758b205e84b269f92d26ab36ed8e2f7 ("usb:
gadget: udc-core: independent registration of gadgets and gadget drivers") has something to do with the problem, though reverting it resulted in g_nokia not being probed at all :)

The problem is not caused by nokia_bind() getting called twice. The log clearly shows that nokia_bind() is called only once, but it calls usb_add_config() from two different places:

Jan  1 02:00:10 Nokia-N900 kernel: [    8.002838] [<c040c5b4>] (usb_add_config) from [<c041b274>] (nokia_bind+0x160/0x2f0)
Jan  1 02:00:10 Nokia-N900 kernel: [    8.014526] [<c041b274>] (nokia_bind) from [<c040e128>] (composite_bind+0x68/0x1a0)
...
Jan  1 02:00:10 Nokia-N900 kernel: [    8.381286] [<c040c5b4>] (usb_add_config) from [<c041b28c>] (nokia_bind+0x178/0x2f0)
Jan  1 02:00:10 Nokia-N900 kernel: [    8.394348] [<c041b28c>] (nokia_bind) from [<c040e128>] (composite_bind+0x68/0x1a0)

Everything else along the two pathways is the same, so this is where the multiple binds come from. And indeed, looking at the code in nokia_bind() you can see the two calls:

         /* finally register the configuration */
         status = usb_add_config(cdev, &nokia_config_500ma_driver,
                         nokia_bind_config);
         if (status < 0)
                 goto err_msg_luns;

         status = usb_add_config(cdev, &nokia_config_100ma_driver,
                         nokia_bind_config);

This isn't supposed to cause any problems. The two instances should never run at the same time, because they belong to different configs.

Quoted 3 lines

This isn't supposed to cause any problems. The two instances should never run at the same time, because they belong to different configs.

The problem seems to be that fsg driver creates a thread for every fsg_bind() call, which overwrites common->thread_task without first checking if a thread is already created. I don't know the idea behind - should it have only one thread for all instances, or there should be a thread per instance, but anyway the current implementation looks wrong.

Michal, I'm not sure how you intended to handle this.

Quoted 1 line · Alan Stern

Michal, I'm not sure how you intended to handle this.

For legacy/nokia setting no_configfs should be a valid solution:

---- >8 ----------------------------------------------------------------

drivers/usb/gadget/legacy/nokia.c +1 -1

index 0997504..e4bc607 100644
@@ -223,6 +223,7 @@ static int nokia_bind_config(struct usb_configuration *c)
        }
 
        fsg_opts = fsg_opts_from_func_inst(fi_msg);
+       fsg_opts->no_configfs = true;
 
        status = fsg_common_run_thread(fsg_opts->common);
        if (status)
---- >8 ----------------------------------------------------------------

This is what other legacy gadgets do after all.

For configfs, why not simply check if the thread has already been started:

---- >8 ----------------------------------------------------------------

drivers/usb/gadget/function/f_mass_storage.c +4 -1

index acf210f..62854b6 100644
@@ -2984,8 +2984,10 @@ int fsg_common_run_thread(struct fsg_common *common)
        common->thread_task =
                kthread_create(fsg_main_thread, common, "file-storage");
        if (IS_ERR(common->thread_task)) {
+               int ret = PTR_ERR(common->thread_task);
+               common->thread_task = NULL;
                common->state = FSG_STATE_TERMINATED;
-               return PTR_ERR(common->thread_task);
+               return ret;
        }
 
        DBG(common, "I/O thread pid: %d\n", task_pid_nr(common->thread_task));

@@ -3005,6 +3007,7 @@ static void fsg_common_release(struct kref *ref)
        if (common->state != FSG_STATE_TERMINATED) {
                raise_exception(common, FSG_STATE_EXIT);
                wait_for_completion(&common->thread_notifier);
+               common->thread_task = NULL;
        }
 
        for (i = 0; i < ARRAY_SIZE(common->luns); ++i) {

drivers/usb/gadget/function/f_mass_storage.c +4 -1

+                       ret = fsg_common_run_thread(fsg->common);
+                       if (ret)
+                               return ret;
+               }
        }
 
        fsg->gadget = gadget;
---- >8 ----------------------------------------------------------------

With that, the whole fsg_common_run_thread call should be moved outside of the if (!no_configfs) and legacy should no longer call it IMO.

Quoted 8 lines

drivers/usb/gadget/function/f_mass_storage.c +1 -3

@@ -3050,9 +3053,11 @@ static int fsg_bind(struct usb_configuration *c, struct usb_function *f)
                if (ret)
                        return ret;
                fsg_common_set_inquiry_string(fsg->common, NULL, NULL);
-               ret = fsg_common_run_thread(fsg->common);
-               if (ret)
-                       return ret;
+               if (common->thread_task) {

Do you mean: if (!common->thread_task)?

Quoted 11 lines

drivers/usb/gadget/function/f_mass_storage.c +4 -1

+                       ret = fsg_common_run_thread(fsg->common);
+                       if (ret)
+                               return ret;
+               }
        }
 
        fsg->gadget = gadget;
---- >8 ----------------------------------------------------------------

With that, the whole fsg_common_run_thread call should be moved outside of the if (!no_configfs) and legacy should no longer call it IMO.

I'm not so sure about this. Earlier I was undecided about what to do if there are multiple mass-storage interfaces in the same config, but now I realize that one thread won't work in that situation. The difficulty is exception handling. If an error occurs in one of the interfaces, it shouldn't affect the others -- but with only one thread you can't make that work.

I don't know the details of how the composite core works (I don't even remember the difference between a usb_function and
a usb_function_instance).

Suppose there are several interfaces in one config, each bound to the mass-storage driver. Then won't the driver's bind routine get called several times whenever the config is installed?

If so, then each of those calls should create a new thread. There's no need to check if the thread has already been started.

If not, then there's no way to use f_mass_storage on multiple interfaces in a single config. The driver should refuse to run on more than one interface at a time.

Quoted 7 lines

I'm not so sure about this. Earlier I was undecided about what to do if there are multiple mass-storage interfaces in the same config, but now I realize that one thread won't work in that situation. The difficulty is exception handling. If an error occurs in one of the interfaces, it shouldn't affect the others -- but with only one thread you can't make that work.

Quoted 3 lines

I don't know the details of how the composite core works (I don't even remember the difference between a usb_function and
a usb_function_instance).

configfs made things quite confusing, yes. IIRC, usb_function roughly corresponds to an interface while usb_function_instance corresponds to a module/function driver, except you can easily create multiple instances.

Quoted 10 lines

Suppose there are several interfaces in one config, each bound to the mass-storage driver. Then won't the driver's bind routine get called several times whenever the config is installed?

If so, then each of those calls should create a new thread. There's no need to check if the thread has already been started.

If not, then there's no way to use f_mass_storage on multiple interfaces in a single config. The driver should refuse to run on more than one interface at a time.

Right, but that’s not what is happening. We have a situation where single mass storage instance is bound to two interfaces on two different configs:

mkdir functions/mass_storage.0
echo $file > functions/mass_storage.0/lun.0/file ln -s functions/mass_storage.0 configs/c.1 ln -s functions/mass_storage.0 configs/c.2

configfs doesn’t even allows to express situation where a single instance of a function is bound to multiple interfaces in a single configuration (IIRC).

At the same time, mass storage should work fine if it’s bound to multiple configurations. Only one configuration can be active at any given time so interfaces on different configurations cannot interfere with each other.

The problem we are having is that when mass storage is added to a configuration, fsg_bind is called and it starts the thread.

If someone wanted to have two mass storage interfaces on a single configuration they would have to create two mass storage instances and each instance has it’s own fsg_common struct (see fsg_alloc_inst function).

PS. It seems that legacy/multi is broken because it calls
fsg_common_run_thread twice.

Quoted 126 lines

Quoted 125 lines

Quoted 115 lines

Quoted 103 lines

Quoted 92 lines

Quoted 88 lines

Quoted 15 lines

Quoted 15 lines

Quoted 15 lines

Quoted 6 lines

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff hang issue on N900. Also, g_nokia is not a module in the config I use, so I guess the problem is not related whether gadgets are modular or not. Unfortunately I was not able to test reboot, as rootfs became corrupted after the first poweroff :( . So it looks like my theory that onenand corruption on N900 is because poweroff/reboot hangs is wrong.

Quoted 5 lines

Quoted 4 lines

Quoted 1 line

Ivo

Is there any progress on the issue?

Doing Nokia-N900:/sys/bus/platform/drivers/musb-hdrc# echo musb-hdrc.0.auto > unbind results in:

<1>[ 1418.511260] Unable to handle kernel paging request at virtual
address 6c6c757a
<7>[ 1418.677215] pvr: Xorg: cleaning up 49 unfreed resources
<1>[ 1418.683349] pgd = c0004000
<1>[ 1418.739959] [6c6c757a] *pgd=00000000
<0>[ 1418.746307] Internal error: Oops: 5 [#1] PREEMPT ARM
<4>[ 1418.753997] Modules linked in: sha256_generic hmac drbg ansi_cprng

ctr ccm vfat fat rfcomm sd_mod scsi_mod bnep bluetooth omaplfb pvrsrvkm ipv6 bq2415x_charger uinput radio_platform_si4713 joydev cmt_speech hsi_char video_bus_switch arc4 wl1251_spi wl1251 isp1704_charger gpio_keys mac80211 smc91x mii cfg80211 omap_wdt crc7 omap_sham tsc2005 tsc200x_core bq27xxx_battery_i2c si4713 adp1653 tsl2563 leds_lp5523 leds_lp55xx_common bq27xxx_battery rtc_twl twl4030_wdt et8ek8 ad5820 v4l2_common smiaregs twl4030_vibra videodev ff_memless lis3lv02d_i2c lis3lv02d media input_polldev omap_ssi_port ti_soc_thermal nokia_modem ssi_protocol omap_ssi hsi rx51_battery

<4>[ 1418.835906] CPU: 0 PID: 53 Comm: file-storage Not tainted
4.5.0-rc5+ #59
<4>[ 1418.846130] Hardware name: Nokia RX-51 board
<4>[ 1418.853820] task: ceb8a300 ti: ce008000 task.ti: ce008000
<4>[ 1418.862792] PC is at handle_exception+0xa8/0x418
<4>[ 1418.871002] LR is at recalc_sigpending+0x18/0x7c
<4>[ 1418.879241] pc : [<c031d0e4>]    lr : [<c0037b84>]    psr: 80000013
<4>[ 1418.879241] sp : ce009ea0  ip : 00000000  fp : 00000000
<4>[ 1418.898284] r10: 00000000  r9 : 00000000  r8 : 00000000
<4>[ 1418.907287] r7 : c031d8d0  r6 : 6c6c7566  r5 : 00000000  r4 : cebe1600
<4>[ 1418.917663] r3 : 6f642820  r2 : 00000000  r1 : 00000000  r0 : 00000000
<4>[ 1418.928039] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
Segment none
<4>[ 1418.939025] Control: 10c5387d  Table: 8e244019  DAC: 00000051
<0>[ 1418.948516] Process file-storage (pid: 53, stack limit = 0xce008210)
<0>[ 1418.958679] Stack: (0xce009ea0 to 0xce00a000)
<0>[ 1418.966735] 9ea0: 0000000f 00000000 00000000 00000b07 00000000
00000001 000003ff 00000001
<0>[ 1418.978973] 9ec0: ceb8a300 ceb8a300 00000000 c004841c 00000000
00000002 ce888000 c0451a50
<0>[ 1418.991180] 9ee0: ffffffff 00000000 00000000 00000008 cebe1600
00000001 c0717dd0 00000001
<0>[ 1419.003387] 9f00: 00000000 00000000 ce009f14 c044ddf4 00000000
c031c020 00000042 ce009f30
<0>[ 1419.015686] 9f20: ce009f30 00000000 cebe1600 c031d958 00000000
c044d864 a0000013 00000000
<0>[ 1419.027923] 9f40: cebe1600 c031d8d0 cebfa100 cebfa100 00000000
cebe1600 c031d8d0 00000000
<0>[ 1419.040130] 9f60: 00000000 00000000 00000000 c00474e4 dc4d900d
00000000 31bc92e7 cebe1600
<0>[ 1419.052429] 9f80: 00000000 ce009f84 ce009f84 00000000 ce009f90
ce009f90 ce009fac cebfa100
<0>[ 1419.064697] 9fa0: c0047418 00000000 00000000 c000f218 00000000
00000000 00000000 00000000
<0>[ 1419.076934] 9fc0: 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000
<0>[ 1419.089050] 9fe0: 00000000 00000000 00000000 00000000 00000013
00000000 00002000 30000891
<4>[ 1419.101043] [<c031d0e4>] (handle_exception) from [<c031d958>]
(fsg_main_thread+0x88/0x13dc)
<4>[ 1419.113189] [<c031d958>] (fsg_main_thread) from [<c00474e4>]
(kthread+0xcc/0xe0)
<4>[ 1419.124267] [<c00474e4>] (kthread) from [<c000f218>]
(ret_from_fork+0x14/0x3c)
<0>[ 1419.135101] Code: 1a000015 ea000040 e5946038 e0866285 (e5963014)
<4>[ 1419.330841] ---[ end trace 3377457e25b0732c ]---
<0>[ 1419.340972] Kernel panic - not syncing: Fatal exception

Quoted 2 lines

weirdly, I have that log only in mtdoops, but not in dmesg. However, after that oops "reboot" command does not hang, but reboots the device.

Quoted 8 lines

So, what is handle_exception + 0xa8 ? You can figure that out either with gdb or addr2line assuming your vmlinux has dbg symbols.

For gdb you would:

gdb vmlinux
(gdb) l *(handle_exception + 0xa8)

Yeah, sorry I didn't do it with the previous mail.

Quoted 11 lines

Reading symbols from /home/ivo/workspace/linux-upstream/github/fmg/linux-n900/vmlinux...done. (gdb) l *(handle_exception + 0xa8)
0xc031d0e4 is in handle_exception (drivers/usb/gadget/function/f_mass_storage.c:2373).
2368
2369 /* Cancel all the pending transfers */
2370 if (likely(common->fsg)) {
2371 for (i = 0; i < common->fsg_num_buffers; ++i) {
2372 bh = &common->buffhds[i];
2373 if (bh->inreq_busy)

Quoted 4 lines

so this would mean we have a race here where bh->inreq_busy is still set while bh->inreq was already freed, right ? I'll try to reproduce this with dwc3 and let you know.

I am not sure this is the case, what I see here is fsg_bind() and fsg_unbind() called twice - "musb-hdrc loaded" -> fsg_bind() -> fsg_bind(), "musb-hdrc unbind through sysfs" -> fsg_unbind() -> fsg_unbind(). That seems to come from g_nokia being probed (successfully) twice. No idea if this is normal - IIUC fsg main thread

Quoted 2 lines

do you have two interfaces with mass storage ?

There are 2 LUNs, not sure what you mean by 2 interfaces.

Quoted 8 lines

Quoted 3 lines

seems to be created twice :). Maybe the problem is that the first time musb-hdrc is probed it fails with -EPROBE_DEFER, however that failure is after gadget drivers got loaded and noone unloads them.

gadget drivers will get added to a pending list, then later they'll bind. But they shouldn't bind() twice, unless there are multiple interfaces for them.

Well, then it seems we have problem, as the 2 unbind() calls are with one and the same "common" pointer (again, from memory).

Quoted 4 lines

Quoted 2 lines

Just some wild guesses based on my memories as I've lost the logs (power outage). For sure I can recreate them if needed.

okay.

I will redo dump_stack() and printks and will provide logs as soon as I have some time, so to stop counting on my memories.

Quoted 9 lines · Ivaylo Dimitrov

Quoted 3 lines

This isn't supposed to cause any problems. The two instances should never run at the same time, because they belong to different configs.

The problem seems to be that fsg driver creates a thread for every fsg_bind() call, which overwrites common->thread_task without first checking if a thread is already created. I don't know the idea behind - should it have only one thread for all instances, or there should be a thread per instance, but anyway the current implementation looks wrong.

You've put your finger on the problem.

Michal, I'm not sure how you intended to handle this. We only need to have one thread per interface (even if there's more than one LUN), but if there are multiple mass-storage interfaces in one configuration then you might want to have multiple threads. Of course, then you would have to handle cases where one config has one mass-storage interface and another config has two...

It's your decision, but clearly the driver needs to be fixed.

Quoted 4 lines · Michal Nazarewicz

At the same time, mass storage should work fine if it’s bound to multiple configurations. Only one configuration can be active at any given time so interfaces on different configurations cannot interfere with each other.

Yes, it _should_. But it doesn't with the nokia legacy driver. I don't know if this has any connection with configfs; it could be a problem with the way f_mass_storage interacts with the composite core.

Quoted 2 lines

The problem we are having is that when mass storage is added to a configuration, fsg_bind is called and it starts the thread.

This is what I'm not sure about. Which callbacks does the composite core invoke when a config is installed or uninstalled?

Those callbacks should be where the thread is started and stopped.

Quoted 5 lines · Alan Stern

Quoted 4 lines · Michal Nazarewicz

At the same time, mass storage should work fine if it’s bound to multiple configurations. Only one configuration can be active at any given time so interfaces on different configurations cannot interfere with each other.

Quoted 4 lines

Yes, it _should_. But it doesn't with the nokia legacy driver. I don't know if this has any connection with configfs; it could be a problem with the way f_mass_storage interacts with the composite core.

I believe the failure is related to the thread being started twice where it indeed shouldn’t.

Quoted 5 lines

Quoted 2 lines

The problem we are having is that when mass storage is added to a configuration, fsg_bind is called and it starts the thread.

This is what I'm not sure about. Which callbacks does the composite core invoke when a config is installed or uninstalled?

usb_add_config is what is called to create a usb_configuration. It initialises the structure and passes it to a callback bind function (most code removed for brevity):

int usb_add_config(struct usb_composite_dev *cdev,
struct usb_configuration *config, int (*bind)(struct usb_configuration *))

{
	usb_add_config_only(cdev, config);
	bind(config);
	/* set_alt(), or next bind(), sets up ep->claimed as needed */
	usb_ep_autoconfig_reset(cdev->gadget);
	return 0;
}

The bind callback calls usb_add_function to add usb_function to a newly created usb_configuration (again, most code removed for brevity):

int usb_add_function(struct usb_configuration *config,
struct usb_function *function)

{
	function->config = config;
	value = function->bind(config, function);
	return 0;
}

For mass_storage, function->bind is fsg_bind (ditto):

static struct usb_function *fsg_alloc(struct usb_function_instance *fi)

{
	struct fsg_dev *fsg kzalloc(sizeof(*fsg), GFP_KERNEL);
	fsg->function.name	= FSG_DRIVER_DESC;
	fsg->function.bind	= fsg_bind;	/* !!! */
	fsg->function.unbind	= fsg_unbind;
	fsg->function.setup	= fsg_setup;
	fsg->function.set_alt	= fsg_set_alt;
	fsg->function.disable	= fsg_disable;
	fsg->function.free_func	= fsg_free;
	fsg->common               = common;
	return &fsg->function;
}

Quoted 1 line

Those callbacks should be where the thread is started and stopped.

Starting thread in that callback is what is happening right now and because single usb_function_instance can have multiple usb_function structures each binding to separate usb_configuration, this causes problem where the thread is started multiple times.

This is also why the thread is not stopped in fsg_unbind but only once fsg_common structure is released.

Conceptually, the thread should be started when fsg_common structure is created (which is at the same time when usb_function_instance is created) and stopped when fsg_common is released.

At this point, I’m not entirely sure if there is a reason why this isn’t the case. The only reason I can think of is that starting the thread right away may be considered wasteful since the thread won’t have anything to do until the function is bound to a configuration. In the current code, there may also be issues where perhaps the thread would not get stopped if fsg_bind has never been called.

Because of all that, I think the best course of action is to just check whether the thread is running and conditionally start it in fsg_bind, i.e.:

This should get rid of all the confusion and just do the right thing.

Quoted 1 line · Alan Stern

On Sat, 2 Apr 2016, Michal Nazarewicz wrote:

Because of all that, I think the best course of action is to just check whether the thread is running and conditionally start it in fsg_bind, i.e.:

drivers/usb/gadget/function/f_mass_storage.c +16 -16

@@ -2979,20 +2979,7 @@ EXPORT_SYMBOL_GPL(fsg_common_set_inquiry_string);
 
  int fsg_common_run_thread(struct fsg_common *common)
  {
-       common->state = FSG_STATE_IDLE;
-       /* Tell the thread to start working */
-       common->thread_task =
-               kthread_create(fsg_main_thread, common, "file-storage");
-       if (IS_ERR(common->thread_task)) {
-               common->state = FSG_STATE_TERMINATED;
-               return PTR_ERR(common->thread_task);
-       }
-
-       DBG(common, "I/O thread pid: %d\n", task_pid_nr(common->thread_task));
-
-       wake_up_process(common->thread_task);
-
-       return 0;
+       /* kill this function and all call sites */
  }
  EXPORT_SYMBOL_GPL(fsg_common_run_thread);
 

@@ -3005,6 +2992,7 @@ static void fsg_common_release(struct kref *ref)
         if (common->state != FSG_STATE_TERMINATED) {
                 raise_exception(common, FSG_STATE_EXIT);
                 wait_for_completion(&common->thread_notifier);
+               common->thread_task = NULL;
         }
 
         for (i = 0; i < ARRAY_SIZE(common->luns); ++i) {

@@ -3050,9 +3038,21 @@ static int fsg_bind(struct usb_configuration *c, struct usb_function *f)
                 if (ret)
                         return ret;
                 fsg_common_set_inquiry_string(fsg->common, NULL, NULL);
-               ret = fsg_common_run_thread(fsg->common);
-               if (ret)
+       }
+
+       if (!common->thread_task) {
+               common->state = FSG_STATE_IDLE;
+               common->thread_task =
+                       kthread_create(fsg_main_thread, common, "file-storage");
+               if (IS_ERR(common->thread_task)) {
+                       int ret = PTR_ERR(common->thread_task);
+                       common->thread_task = NULL;
+                       common->state = FSG_STATE_TERMINATED;
                         return ret;
+               }
+               DBG(common, "I/O thread pid: %d\n",
+                   task_pid_nr(common->thread_task));
+               wake_up_process(common->thread_task);
         }
 
         fsg->gadget = gadget;

This should get rid of all the confusion and just do the right thing.

So there is no way to add a single function to several configurations?

It sounds like there are two problems then. The first problem is that struct usb_function has a ->disable() callback but no ->enable() callback. The set_config() routine in composite.c should invoke the ->enable() callback for each function in the config when the config is installed.

The second problem is that f_mass_storage should start the thread in the enable callback and stop the thread in the disable callback, rather than in fsg_bind() and fsg_free_inst() (or wherever).

Even after the function is bound to a configuration, the thread won't have anything to do until the configuration is installed by the host.

Except that you'll have a bunch of threads hanging around with nothing to do. They shouldn't be created until it is known that they will be needed, and they should be destroyed when it is known that they won't have any more work to do.

Who and when is going to destroy the thread if one does "/sys/bus/platform/drivers/musb-hdrc# echo musb-hdrc.0.auto > unbind"? Wouldn't some kind of refcounting make sense here?

Quoted 1 line · Alan Stern

So there is no way to add a single function to several configurations?

There is. f_mass_storage (and any other usb_function_instance) simply has to have multiple usb_function structures.

Quoted 5 lines

It sounds like there are two problems then. The first problem is that struct usb_function has a ->disable() callback but no ->enable() callback. The set_config() routine in composite.c should invoke the ->enable() callback for each function in the config when the config is installed.

Well, there is set_alt which is called when configuration is chosen (as well as when interface’s alternative is chosen). It’s not ideal but if we had to we could work with that.

Quoted 4 lines

Except that you'll have a bunch of threads hanging around with nothing to do. They shouldn't be created until it is known that they will be needed, and they should be destroyed when it is known that they won't have any more work to do.

I’m not sure how big of a deal that is. The flip side is that equating thread’s lifetime to the lifetime of the function instance is conceptually easier. Even with thread started in fsg_bind this is still less complex than having the thread pop in and out of existence.

Furthermore, having it start and stop may lead to unnecessary delays when host switches configurations. This may be an esoteric problem though.

I’m not married to any either idea, but right now my patch is a better course of action because it brings a quick fix to the bug. More dramatic changes to thread’s lifetime should be handled by separate patches.

For legacy/nokia setting no_configfs should be a valid solution:

---- >8 ----------------------------------------------------------------

drivers/usb/gadget/legacy/nokia.c +1 -1

index 0997504..e4bc607 100644
@@ -223,6 +223,7 @@ static int nokia_bind_config(struct usb_configuration *c)
        }
 
        fsg_opts = fsg_opts_from_func_inst(fi_msg);
+       fsg_opts->no_configfs = true;
 
        status = fsg_common_run_thread(fsg_opts->common);
        if (status)
---- >8 ----------------------------------------------------------------

This is what other legacy gadgets do after all.

Hi,

Quoted 8 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff hang issue on N900. Also, g_nokia is not a module in the config I use, so I guess the problem is not related whether gadgets are modular or not. Unfortunately I was not able to test reboot, as rootfs became corrupted after the first poweroff :( . So it looks like my theory that onenand corruption on N900 is because poweroff/reboot hangs is wrong.

Hi,

Quoted 7 lines · Ivaylo Dimitrov

Hi,

Quoted 4 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

(copied from "Re: [PATCH] usb: f_mass_storage: test whether thread is running before starting another" thread)

Yet another problem with USB gadget, this time with f_acm - if there is an open /dev/ttyGSn device, it is impossible to reboot/power down the device.

My investigation shown that there is a process(pnatd) that opens /dev/ttyGSn devices, so gserial_free_port() hangs on wait_event(port->close_wait, gs_closed(port)); if I do "cd /sys/bus/platform/drivers/musb-hdrc && echo musb-hdrc.0.auto > unbind".

Unfortunately I don't have serial debug port connector on my N900, so I can't capture logs after the reboot command, however, I suspect it hangs on the same place as with unbind.

That looks weird, as one would expect that close() is called when the kernel kills user processes on reboot/powerdown.

Ivo

Hi,

Quoted 12 lines · Ivaylo Dimitrov

Hi,

Quoted 8 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Quoted 7 lines

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff hang issue on N900. Also, g_nokia is not a module in the config I use, so I guess the problem is not related whether gadgets are modular or not. Unfortunately I was not able to test reboot, as rootfs became corrupted after the first poweroff :( . So it looks like my theory that onenand corruption on N900 is because poweroff/reboot hangs is wrong.

(copied from "Re: [PATCH] usb: f_mass_storage: test whether thread is running before starting another" thread)

Yet another problem with USB gadget, this time with f_acm - if there is an open /dev/ttyGSn device, it is impossible to reboot/power down the device.

My investigation shown that there is a process(pnatd) that opens /dev/ttyGSn devices, so gserial_free_port() hangs on wait_event(port->close_wait, gs_closed(port)); if I do "cd /sys/bus/platform/drivers/musb-hdrc && echo musb-hdrc.0.auto > unbind".

Unfortunately I don't have serial debug port connector on my N900, so I can't capture logs after the reboot command, however, I suspect it hangs on the same place as with unbind.

That looks weird, as one would expect that close() is called when the kernel kills user processes on reboot/powerdown.

Hi,

Quoted 39 lines · Ivaylo Dimitrov

Hi,

Quoted 12 lines · Ivaylo Dimitrov

Hi,

Quoted 8 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Quoted 7 lines

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff hang issue on N900. Also, g_nokia is not a module in the config I use, so I guess the problem is not related whether gadgets are modular or not. Unfortunately I was not able to test reboot, as rootfs became corrupted after the first poweroff :( . So it looks like my theory that onenand corruption on N900 is because poweroff/reboot hangs is wrong.

(copied from "Re: [PATCH] usb: f_mass_storage: test whether thread is running before starting another" thread)

Yet another problem with USB gadget, this time with f_acm - if there is an open /dev/ttyGSn device, it is impossible to reboot/power down the device.

My investigation shown that there is a process(pnatd) that opens /dev/ttyGSn devices, so gserial_free_port() hangs on wait_event(port->close_wait, gs_closed(port)); if I do "cd /sys/bus/platform/drivers/musb-hdrc && echo musb-hdrc.0.auto > unbind".

Unfortunately I don't have serial debug port connector on my N900, so I can't capture logs after the reboot command, however, I suspect it hangs on the same place as with unbind.

Quoted 2 lines

That looks weird, as one would expect that close() is called when the kernel kills user processes on reboot/powerdown.

right, care to enable lockup detection and see if you can get more info out of it ?

Quoted 34 lines

Quoted 33 lines

Quoted 7 lines

Quoted 6 lines

Looks like there's some issue with the USB gadgets and configfs.

I'm seeing rmmod of the UDC driver cause a warning and then reboot hangs the system. This happens at least with v4.4, and I've reproduced it with dwc3 and musb so it seems to be generic.

Quoted 7 lines

Having configfs is not needed, disabling usb gadgets (# CONFIG_USB_MUSB_GADGET is not set) seems to solved at least poweroff hang issue on N900. Also, g_nokia is not a module in the config I use, so I guess the problem is not related whether gadgets are modular or not. Unfortunately I was not able to test reboot, as rootfs became corrupted after the first poweroff :( . So it looks like my theory that onenand corruption on N900 is because poweroff/reboot hangs is wrong.

(copied from "Re: [PATCH] usb: f_mass_storage: test whether thread is running before starting another" thread)

Yet another problem with USB gadget, this time with f_acm - if there is an open /dev/ttyGSn device, it is impossible to reboot/power down the device.

My investigation shown that there is a process(pnatd) that opens /dev/ttyGSn devices, so gserial_free_port() hangs on wait_event(port->close_wait, gs_closed(port)); if I do "cd /sys/bus/platform/drivers/musb-hdrc && echo musb-hdrc.0.auto > unbind".

Unfortunately I don't have serial debug port connector on my N900, so I can't capture logs after the reboot command, however, I suspect it hangs on the same place as with unbind.

That looks weird, as one would expect that close() is called when the kernel kills user processes on reboot/powerdown.

Quoted 3 lines

right, care to enable lockup detection and see if you can get more info out of it ?

Nothing interesting, besides that screen does not work :(. However, the device boots, I can connect through wifi and reboot still hangs. Also, I don't see that port->close_wait in /proc/lockdep. Is that expected?

Is there a reason why a process (pnatd in this particular case) doesn't get killed on reboot?

Quoted 2 lines

Is there a reason why a process (pnatd in this particular case) doesn't get killed on reboot?

there might be, and that's probably the bug we're trying to figure out. But so far, no idea.

Quoted 3 lines · Felipe Balbi

Quoted 2 lines

Is there a reason why a process (pnatd in this particular case) doesn't get killed on reboot?

Quoted 2 lines

there might be, and that's probably the bug we're trying to figure out. But so far, no idea.

One possible reason is that the process is in an uninterruptible wait inside the kernel, waiting for something that isn't going to happen.

Alan Stern

Quoted 5 lines · Alan Stern

Quoted 3 lines · Felipe Balbi

Quoted 2 lines

Is there a reason why a process (pnatd in this particular case) doesn't get killed on reboot?

Quoted 5 lines

Quoted 2 lines

there might be, and that's probably the bug we're trying to figure out. But so far, no idea.

One possible reason is that the process is in an uninterruptible wait inside the kernel, waiting for something that isn't going to happen.

The process waits in poll(&fds, 1u, -1), where fds contains only the fd of /dev/ttyGS2. Nothing suspicious I can see here.

Quoted 11 lines · Ivaylo Dimitrov

Quoted 8 lines · Alan Stern

Quoted 5 lines · Felipe Balbi

Quoted 2 lines

Is there a reason why a process (pnatd in this particular case) doesn't get killed on reboot?

there might be, and that's probably the bug we're trying to figure out. But so far, no idea.

Quoted 5 lines

Quoted 2 lines

One possible reason is that the process is in an uninterruptible wait inside the kernel, waiting for something that isn't going to happen.

The process waits in poll(&fds, 1u, -1), where fds contains only the fd of /dev/ttyGS2. Nothing suspicious I can see here.

I think the easy way to reproduce this is to start getty or minicom on /dev/ttyG* and disconnect the USB cable.

Quoted 10 lines · Ivaylo Dimitrov

Hi,

Quoted 7 lines · Ivaylo Dimitrov

Hi,

Quoted 4 lines · Tony Lindgren

Hi all,

Looks like there's some issue with the USB gadgets and configfs.

...

Quoted 17 lines

(copied from "Re: [PATCH] usb: f_mass_storage: test whether thread is running before starting another" thread)

Yet another problem with USB gadget, this time with f_acm - if there is an open /dev/ttyGSn device, it is impossible to reboot/power down the device.

My investigation shown that there is a process(pnatd) that opens /dev/ttyGSn devices, so gserial_free_port() hangs on wait_event(port->close_wait, gs_closed(port)); if I do "cd /sys/bus/platform/drivers/musb-hdrc && echo musb-hdrc.0.auto > unbind".

Unfortunately I don't have serial debug port connector on my N900, so I can't capture logs after the reboot command, however, I suspect it hangs on the same place as with unbind.

Quoted 4 lines

That looks weird, as one would expect that close() is called when the kernel kills user processes on reboot/powerdown.

Ivo

Anyone?