* USB gadgets with configfs hang reboot
@ 2016-01-15 22:48 Tony Lindgren
[not found] ` <20160115224839.GA19432-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Tony Lindgren @ 2016-01-15 22:48 UTC (permalink / raw)
To: Felipe Balbi
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
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
Warning on rmmod $udc_module after gadgets are configured:
kobject: 'udc' (c202f700): kobject_release, parent c20ab818 (delayed 400)
kobject: '4a030000.dwc3' (c21b7c10): kobject_release, parent (null) (delayed 200)
kobject: 'gadget' (c21911c0): kobject_release, parent (null) (delayed 200)
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1609 at lib/debugobjects.c:263 debug_print_object+0x8c/0xb8()
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x10
Modules linked in: bluetooth cpufreq_dt leds_gpio led_class omap4_keypad matrix_keymap omap_wdt evdev ti_soc_thermal thermal_sys hwmon snd_soc_omap_mcbsp wlcore_sdio wl18xx wl12xx wlcore mac80211 cfg80211 omapfb connector_hdmi encoder_tpds
CPU: 1 PID: 1609 Comm: rmmod Not tainted 4.4.0-00009-g37797bf #228
Hardware name: Generic OMAP5 (Flattened Device Tree)
[<c0017c08>] (unwind_backtrace) from [<c0013f60>] (show_stack+0x10/0x14)
[<c0013f60>] (show_stack) from [<c034f180>] (dump_stack+0x84/0x9c)
[<c034f180>] (dump_stack) from [<c003cb64>] (warn_slowpath_common+0x78/0xb4)
[<c003cb64>] (warn_slowpath_common) from [<c003cbd0>] (warn_slowpath_fmt+0x30/0x40)
[<c003cbd0>] (warn_slowpath_fmt) from [<c0368e6c>] (debug_print_object+0x8c/0xb8)
[<c0368e6c>] (debug_print_object) from [<c036960c>] (__debug_check_no_obj_freed+0x1a0/0x228)
[<c036960c>] (__debug_check_no_obj_freed) from [<c0166080>] (kfree+0x80/0x1bc)
[<c0166080>] (kfree) from [<c03ed13c>] (release_nodes+0x164/0x1c8)
[<c03ed13c>] (release_nodes) from [<c03e9dc0>] (__device_release_driver+0x90/0x114)
[<c03e9dc0>] (__device_release_driver) from [<c03e9e64>] (device_release_driver+0x20/0x2c)
[<c03e9e64>] (device_release_driver) from [<c03e96b0>] (bus_remove_device+0xd8/0x108)
[<c03e96b0>] (bus_remove_device) from [<c03e69b0>] (device_del+0x10c/0x210)
[<c03e69b0>] (device_del) from [<c03eba8c>] (platform_device_del+0x18/0x88)
[<c03eba8c>] (platform_device_del) from [<c03ebb08>] (platform_device_unregister+0xc/0x20)
[<c03ebb08>] (platform_device_unregister) from [<c04e0e10>] (of_platform_device_destroy+0x8c/0x98)
[<c04e0e10>] (of_platform_device_destroy) from [<c03e6554>] (device_for_each_child+0x50/0x7c)
[<c03e6554>] (device_for_each_child) from [<c04e0d6c>] (of_platform_depopulate+0x2c/0x44)
[<c04e0d6c>] (of_platform_depopulate) from [<bf176208>] (dwc3_omap_remove+0x3c/0x5c [dwc3_omap])
[<bf176208>] (dwc3_omap_remove [dwc3_omap]) from [<c03ebbb4>] (platform_drv_remove+0x24/0x3c)
[<c03ebbb4>] (platform_drv_remove) from [<c03e9db8>] (__device_release_driver+0x88/0x114)
[<c03e9db8>] (__device_release_driver) from [<c03ea5d4>] (driver_detach+0xb4/0xb8)
[<c03ea5d4>] (driver_detach) from [<c03e9940>] (bus_remove_driver+0x4c/0xa0)
[<c03e9940>] (bus_remove_driver) from [<c00cb574>] (SyS_delete_module+0x11c/0x1e4)
[<c00cb574>] (SyS_delete_module) from [<c000f740>] (ret_fast_syscall+0x0/0x1c)
---[ end trace 3d4a0455591ff9ed ]---
Error on reboot after rmmod $udc_module:
Alignment trap: not handling instruction e1932f9f at [<c009168c>]
Unhandled fault: alignment exception (0x001) at 0x6b6b6c6f
pgd = c27b0000
[6b6b6c6f] *pgd=00000000
Internal error: : 1 [#1] SMP ARM
Modules linked in: usb_f_rndis usb_f_ecm bluetooth leds_gpio led_class cpufreq_dt omap4_keypad omap_wdt matrix_keymap ti_soc_thermal evdev thermal_sys hwmon snd_soc_omap_mcbsp wlcore_sdio wl18xx wl12xx wlcore mac80211 cfg80211 omapfb conn]
CPU: 1 PID: 1935 Comm: reboot Not tainted 4.4.0-00009-g37797bf #228
Hardware name: Generic OMAP5 (Flattened Device Tree)
task: c27a6340 ti: c2502000 task.ti: c2502000
PC is at __lock_acquire+0x25c/0x148c
LR is at 0x1
pc : [<c0091690>] lr : [<00000001>] psr: 20080093
sp : c2503d88 ip : c2502000 fp : c096db04
r10: c11ac224 r9 : c27a6340 r8 : c09a54e0
r7 : 00000000 r6 : 00000000 r5 : 00000000 r4 : 6b6b6b6b
r3 : 6b6b6c6f r2 : 6b6b6b6b r1 : 00000001 r0 : ee4e828c
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 827b006a DAC: 00000051
Process reboot (pid: 1935, stack limit = 0xc2502218)
Stack: (0xc2503d88 to 0xc2504000)
3d80: ee4e828c c27a6898 c27a6898 00000000 c27a6340 c0b504e8
3da0: 00000000 c27a6898 c27a6898 00000000 ee4e81b8 ee4e828c 00000000 00000000
3dc0: 00000000 c09e5294 60080013 c0093140 00000001 00000000 00000000 c03e826c
3de0: 00000000 00000000 01234567 ee08bdd8 00000000 ee4e8258 ee4e81b8 c23f6330
3e00: c127002c c11ac224 c27a6340 00000000 00000001 c0653250 00000001 00000000
3e20: c03e826c c27a6870 c27a6340 60080013 00000001 c27a6870 c127002c ee08bdc8
3e40: ee4e81b8 c23f633c ee4e81b8 c23f6330 c127002c cc5b4b00 c09ea020 00000000
3e60: 00000001 c03e826c 00000000 01234567 c096b1b4 fee1dead cc5b4b00 c2502000
3e80: 00000000 c005fc54 00000000 c005ff1c c22c4ec0 c22c4ed0 00000000 00000000
3ea0: 00000000 c09e5294 0000005c 00000002 c27a6878 00000000 c09a54e0 c27a6340
3ec0: c11ac224 c00918a8 0000005c 00000000 c27a6878 c27a6870 00000001 c27a6870
3ee0: c09e497a c22c4ec0 c22c4ec0 00000000 c005bb4c c096e6e8 00000000 00000000
3f00: 00000002 c09e5294 600f0013 c0093140 00000000 00000000 00000000 c0199274
3f20: 00000000 00000000 c018f378 ede1e4a0 ed137018 ee11a900 c005bb4c 00000000
3f40: c27a6340 00000000 c27a6340 600f0013 00000000 c27a6870 00000000 c27a67c4
3f60: c09ebd48 00000000 c27a6340 00000000 c2502000 00000000 00000001 c005bb50
3f80: 00000000 c2502000 00000001 00000004 00000001 00000004 00000000 00000058
3fa0: c000f8e4 c000f740 00000001 00000004 fee1dead 28121969 01234567 cc5b4b00
3fc0: 00000001 00000004 00000000 00000058 00000000 00000000 00000000 00000001
3fe0: 00000058 bebfcc84 b6ed9ec5 b6e61966 80080030 fee1dead afffd861 afffdc61
[<c0091690>] (__lock_acquire) from [<c0093140>] (lock_acquire+0xac/0x12c)
[<c0093140>] (lock_acquire) from [<c0653250>] (mutex_lock_nested+0x38/0x3c8)
[<c0653250>] (mutex_lock_nested) from [<c03e826c>] (device_shutdown+0xcc/0x1bc)
[<c03e826c>] (device_shutdown) from [<c005fc54>] (kernel_restart+0xc/0x50)
[<c005fc54>] (kernel_restart) from [<c005ff1c>] (SyS_reboot+0x138/0x1f4)
[<c005ff1c>] (SyS_reboot) from [<c000f740>] (ret_fast_syscall+0x0/0x1c)
Code: 0affff87 e2843f41 f5d3f000 e1932f9f (e2822001)
---[ end trace f16e89fb774cf929 ]---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <20160115224839.GA19432-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
@ 2016-01-16 0:09 ` Tony Lindgren
2016-01-16 10:40 ` Ivaylo Dimitrov
2016-01-22 10:35 ` Andrzej Pietrasiewicz
2 siblings, 0 replies; 45+ messages in thread
From: Tony Lindgren @ 2016-01-16 0:09 UTC (permalink / raw)
To: Felipe Balbi
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [160115 14:49]:
>
> 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:
Here's what CONFIG_DEBUG_KOBJECT gives for the reboot hang. At address
ee79b1c0 we have 'gadget' and that's the null kobject at the WARNING.
Regards,
Tony
...
udc 4a030000.dwc3: releasing '4a030000.dwc3'
kobject: '4a030000.dwc3': free name
kobject: 'gadget' (ee79b1c0): kobject_uevent_env
kobject: 'gadget' (ee79b1c0): kobject_uevent_env: filter function caused the event to drop!
kobject: 'dwc3' (ee76e040): kobject_cleanup, parent ee0edb68
kobject: 'dwc3' (ee76e040): auto cleanup 'remove' event
...
Broadcast message from root@armhf (ttyO2) (Fri Jan 15 23:49:15 2016):
The system is going down for reboot NOW!
...
restart.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1949 at lib/kobject.c:597 kobject_get+0x70/0xb0()
kobject: '(null)' (ee79b1c0): is not initialized, yet kobject_get() is being called.
Modules linked in: usb_f_rndis usb_f_ecm bluetooth leds_gpio led_class cpufreq_dt ti_soc_thermal omap4_keypad thermal_sys omap_wdt matrix_keymap evdev hwmon snd_soc_omap_mcbsp wlcore_sdio wl18xx wl12xx wlcore mac80211 cfg80211 omapfb connector_hdmi encoder_tpd12s015 omapdss cfbimgblt cfbfillrect cfbcopyarea gpio_pca953x hid_generic usbhid smsc95xx smsc75xx usbnet usb_f_acm u_ether usb_f_mass_storage usb_f_serial u_serial xhci_plat_hcd xhci_hcd dwc3_omap ohci_omap3 ohci_hcd ehci_omap ehci_hcd phy_omap_usb2 libcomposite udc_core usbcore usb_common snd_soc_omap_abe_twl6040 snd_soc_omap_mcpdm snd_soc_twl6040 snd_soc_omap snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore rtc_ds1307 rtc_palmas rtc_twl palmas_pwrbutton extcon_palmas extcon clk_palmas [last unloaded: dwc3]
CPU: 0 PID: 1949 Comm: reboot Not tainted 4.4.0-00009-g37797bf #231
Hardware name: Generic OMAP5 (Flattened Device Tree)
[<c0017c08>] (unwind_backtrace) from [<c0013f60>] (show_stack+0x10/0x14)
[<c0013f60>] (show_stack) from [<c034cbe0>] (dump_stack+0x84/0x9c)
[<c034cbe0>] (dump_stack) from [<c003cb64>] (warn_slowpath_common+0x78/0xb4)
[<c003cb64>] (warn_slowpath_common) from [<c003cbd0>] (warn_slowpath_fmt+0x30/0x40)
[<c003cbd0>] (warn_slowpath_fmt) from [<c034f1d0>] (kobject_get+0x70/0xb0)
[<c034f1d0>] (kobject_get) from [<c03e4b04>] (device_shutdown+0x84/0x1bc)
[<c03e4b04>] (device_shutdown) from [<c005f9a8>] (kernel_restart+0xc/0x50)
[<c005f9a8>] (kernel_restart) from [<c005fc70>] (SyS_reboot+0x138/0x1f4)
[<c005fc70>] (SyS_reboot) from [<c000f740>] (ret_fast_syscall+0x0/0x1c)
---[ end trace 3ccd9ca0c720ba01 ]---
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1949 at include/linux/kref.h:46 kobject_get+0x90/0xb0()
Modules linked in: usb_f_rndis usb_f_ecm bluetooth leds_gpio led_class cpufreq_dt ti_soc_thermal omap4_keypad thermal_sys omap_wdt matrix_keymap evdev hwmon snd_soc_omap_mcbsp wlcore_sdio wl18xx wl12xx wlcore mac80211 cfg80211 omapfb connector_hdmi encoder_tpd12s015 omapdss cfbimgblt cfbfillrect cfbcopyarea gpio_pca953x hid_generic usbhid smsc95xx smsc75xx usbnet usb_f_acm u_ether usb_f_mass_storage usb_f_serial u_serial xhci_plat_hcd xhci_hcd dwc3_omap ohci_omap3 ohci_hcd ehci_omap ehci_hcd phy_omap_usb2 libcomposite udc_core usbcore usb_common snd_soc_omap_abe_twl6040 snd_soc_omap_mcpdm snd_soc_twl6040 snd_soc_omap snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore rtc_ds1307 rtc_palmas rtc_twl palmas_pwrbutton extcon_palmas extcon clk_palmas [last unloaded: dwc3]
CPU: 0 PID: 1949 Comm: reboot Tainted: G W 4.4.0-00009-g37797bf #231
Hardware name: Generic OMAP5 (Flattened Device Tree)
[<c0017c08>] (unwind_backtrace) from [<c0013f60>] (show_stack+0x10/0x14)
[<c0013f60>] (show_stack) from [<c034cbe0>] (dump_stack+0x84/0x9c)
[<c034cbe0>] (dump_stack) from [<c003cb64>] (warn_slowpath_common+0x78/0xb4)
[<c003cb64>] (warn_slowpath_common) from [<c003cc3c>] (warn_slowpath_null+0x1c/0x24)
[<c003cc3c>] (warn_slowpath_null) from [<c034f1f0>] (kobject_get+0x90/0xb0)
[<c034f1f0>] (kobject_get) from [<c03e4b04>] (device_shutdown+0x84/0x1bc)
[<c03e4b04>] (device_shutdown) from [<c005f9a8>] (kernel_restart+0xc/0x50)
[<c005f9a8>] (kernel_restart) from [<c005fc70>] (SyS_reboot+0x138/0x1f4)
[<c005fc70>] (SyS_reboot) from [<c000f740>] (ret_fast_syscall+0x0/0x1c)
---[ end trace 3ccd9ca0c720ba02 ]---
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 1949 Comm: reboot Tainted: G W 4.4.0-00009-g37797bf #231
Hardware name: Generic OMAP5 (Flattened Device Tree)
[<c0017c08>] (unwind_backtrace) from [<c0013f60>] (show_stack+0x10/0x14)
[<c0013f60>] (show_stack) from [<c034cbe0>] (dump_stack+0x84/0x9c)
[<c034cbe0>] (dump_stack) from [<c0092524>] (__lock_acquire+0x13b0/0x148c)
[<c0092524>] (__lock_acquire) from [<c0092e80>] (lock_acquire+0xac/0x12c)
[<c0092e80>] (lock_acquire) from [<c064f680>] (mutex_lock_nested+0x38/0x3c8)
[<c064f680>] (mutex_lock_nested) from [<c03e4b4c>] (device_shutdown+0xcc/0x1bc)
[<c03e4b4c>] (device_shutdown) from [<c005f9a8>] (kernel_restart+0xc/0x50)
[<c005f9a8>] (kernel_restart) from [<c005fc70>] (SyS_reboot+0x138/0x1f4)
[<c005fc70>] (SyS_reboot) from [<c000f740>] (ret_fast_syscall+0x0/0x1c)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <20160115224839.GA19432-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2016-01-16 0:09 ` Tony Lindgren
@ 2016-01-16 10:40 ` Ivaylo Dimitrov
[not found] ` <569A1E32.1020502-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-01-22 10:35 ` Andrzej Pietrasiewicz
2 siblings, 1 reply; 45+ messages in thread
From: Ivaylo Dimitrov @ 2016-01-16 10:40 UTC (permalink / raw)
To: Tony Lindgren, Felipe Balbi
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
Hi,
On 16.01.2016 00:48, Tony Lindgren wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <569A1E32.1020502-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-01-18 16:16 ` Tony Lindgren
2016-03-23 18:24 ` Ivaylo Dimitrov
2016-04-08 20:13 ` Ivaylo Dimitrov
2 siblings, 0 replies; 45+ messages in thread
From: Tony Lindgren @ 2016-01-18 16:16 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
* Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [160116 02:41]:
> Hi,
>
> On 16.01.2016 00:48, Tony Lindgren wrote:
> >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.
Oh OK so this is the same reboot bug you mentioned earlier. And yes
this $subject bug should not be related to the n900 legacy userspace
onenand corruption you're seeing.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <20160115224839.GA19432-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2016-01-16 0:09 ` Tony Lindgren
2016-01-16 10:40 ` Ivaylo Dimitrov
@ 2016-01-22 10:35 ` Andrzej Pietrasiewicz
[not found] ` <56A205E4.6050305-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2 siblings, 1 reply; 45+ messages in thread
From: Andrzej Pietrasiewicz @ 2016-01-22 10:35 UTC (permalink / raw)
To: Tony Lindgren, Felipe Balbi
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga
Hi Tony,
W dniu 15.01.2016 o 23:48, Tony Lindgren pisze:
> 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.
> 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
<snip>
>
> 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
for me these are:
udc_module=dwc3-exynos
udc_name=12400000.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
I assume you meant ecm.0 here and in the next line.
> 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
I have it uncommented, no problems.
But before I run this script I need to modprobe libcomposite,
though.
AP
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <56A205E4.6050305-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
@ 2016-01-22 18:28 ` Tony Lindgren
0 siblings, 0 replies; 45+ messages in thread
From: Tony Lindgren @ 2016-01-22 18:28 UTC (permalink / raw)
To: Andrzej Pietrasiewicz
Cc: Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga
* Andrzej Pietrasiewicz <andrzej.p-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> [160122 02:36]:
> Hi Tony,
>
> W dniu 15.01.2016 o 23:48, Tony Lindgren pisze:
> >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.
Well thanks for trying. Probably the difference is that
dwc3-exynos.c remove is calling platform_device_unregister()
while dwc3-omap.c remove is calling of_platform_depopulate()?
> > mkdir functions/ecm.0
> > ln -s functions/acm.0 configs/c.1
>
> I assume you meant ecm.0 here and in the next line.
>
> > ln -s functions/acm.0 configs/c.2
OK, yes you're right. That does not affect the outcome though.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <569A1E32.1020502-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-01-18 16:16 ` Tony Lindgren
@ 2016-03-23 18:24 ` Ivaylo Dimitrov
[not found] ` <56F2DF79.6010903-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-08 20:13 ` Ivaylo Dimitrov
2 siblings, 1 reply; 45+ messages in thread
From: Ivaylo Dimitrov @ 2016-03-23 18:24 UTC (permalink / raw)
To: Tony Lindgren, Felipe Balbi
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
Hi
On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
> Hi,
>
> On 16.01.2016 00:48, Tony Lindgren wrote:
>> 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
Is there any progress on the issue?
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <56F2DF79.6010903-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-03-24 6:50 ` Felipe Balbi
[not found] ` <87fuvgxtc3.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Felipe Balbi @ 2016-03-24 6:50 UTC (permalink / raw)
To: Ivaylo Dimitrov, Tony Lindgren
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]
Hi,
Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
>> Hi,
>>
>> On 16.01.2016 00:48, Tony Lindgren wrote:
>>> 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
>
>
> Is there any progress on the issue?
I don't have any DT-based system anymore, so there's very little I can
do to help. That being said, it's not the first time
of_platform_depopulate() causes problems.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <87fuvgxtc3.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
@ 2016-03-24 7:03 ` Ivaylo Dimitrov
[not found] ` <56F3914B.4010206-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Ivaylo Dimitrov @ 2016-03-24 7:03 UTC (permalink / raw)
To: Felipe Balbi, Tony Lindgren
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
Hi,
On 24.03.2016 08:50, Felipe Balbi wrote:
>
> Hi,
>
> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
>>> Hi,
>>>
>>> On 16.01.2016 00:48, Tony Lindgren wrote:
>>>> 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
>>
>>
>> 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.
Regards,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <56F3914B.4010206-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-03-24 7:11 ` Felipe Balbi
[not found] ` <87a8loxsdm.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Felipe Balbi @ 2016-03-24 7:11 UTC (permalink / raw)
To: Ivaylo Dimitrov, Tony Lindgren, Bin Liu
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
[-- Attachment #1: Type: text/plain, Size: 5308 bytes --]
Hi,
Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>> On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
>>>> Hi,
>>>>
>>>> On 16.01.2016 00:48, Tony Lindgren wrote:
>>>>> 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
>>>
>>>
>>> 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.
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)
cheers
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <87a8loxsdm.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
@ 2016-03-24 18:46 ` Ivaylo Dimitrov
[not found] ` <56F4361C.9040907-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Ivaylo Dimitrov @ 2016-03-24 18:46 UTC (permalink / raw)
To: Felipe Balbi, Tony Lindgren, Bin Liu
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
Hi,
On 24.03.2016 09:11, Felipe Balbi wrote:
>
> Hi,
>
> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>> On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
>>>>> Hi,
>>>>>
>>>>> On 16.01.2016 00:48, Tony Lindgren wrote:
>>>>>> 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
>>>>
>>>>
>>>> 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.
>
>
> 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)
2374 usb_ep_dequeue(common->fsg->bulk_in, bh->inreq);
2375 if (bh->outreq_busy)
2376 usb_ep_dequeue(common->fsg->bulk_out,
2377 bh->outreq);
(gdb)
Thanks,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <56F4361C.9040907-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-03-30 10:22 ` Felipe Balbi
[not found] ` <877fgkqn8c.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Felipe Balbi @ 2016-03-30 10:22 UTC (permalink / raw)
To: Ivaylo Dimitrov, Tony Lindgren, Bin Liu
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
[-- Attachment #1: Type: text/plain, Size: 6267 bytes --]
Hi,
Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>> On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 16.01.2016 00:48, Tony Lindgren wrote:
>>>>>>> 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
>>>>>
>>>>>
>>>>> 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.
>>
>>
>> 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)
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.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <877fgkqn8c.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
@ 2016-03-30 13:29 ` Ivaylo Dimitrov
[not found] ` <56FBD4BF.6090905-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Ivaylo Dimitrov @ 2016-03-30 13:29 UTC (permalink / raw)
To: Felipe Balbi, Tony Lindgren, Bin Liu
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
Hi,
On 30.03.2016 13:22, Felipe Balbi wrote:
>
> Hi,
>
> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>> On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 16.01.2016 00:48, Tony Lindgren wrote:
>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>> 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.
>>>
>>>
>>> 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)
>
> 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.
Thanks,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <56FBD4BF.6090905-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-03-30 13:38 ` Felipe Balbi
[not found] ` <87h9fohyr1.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Felipe Balbi @ 2016-03-30 13:38 UTC (permalink / raw)
To: Ivaylo Dimitrov, Tony Lindgren, Bin Liu
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
[-- Attachment #1: Type: text/plain, Size: 7521 bytes --]
Hi,
Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>>> On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 16.01.2016 00:48, Tony Lindgren wrote:
>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> 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.
>>>>
>>>>
>>>> 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)
>>
>> 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
do you have two interfaces with mass storage ?
> 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.
> 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.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <87h9fohyr1.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
@ 2016-03-30 14:01 ` Ivaylo Dimitrov
[not found] ` <56FBDC51.9020602-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Ivaylo Dimitrov @ 2016-03-30 14:01 UTC (permalink / raw)
To: Felipe Balbi, Tony Lindgren, Bin Liu, pali Rohár
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
On 30.03.2016 16:38, Felipe Balbi wrote:
>
> Hi,
>
> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>>>> On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 16.01.2016 00:48, Tony Lindgren wrote:
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>
>>>>>
>>>>> 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)
>>>
>>> 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
>
> do you have two interfaces with mass storage ?
>
There are 2 LUNs, not sure what you mean by 2 interfaces.
Pali ^^^ ?
>> 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).
>> 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.
Thanks,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <56FBDC51.9020602-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-03-30 14:33 ` Pali Rohár
2016-03-30 18:50 ` Ivaylo Dimitrov
2016-04-04 4:41 ` Felipe Balbi
2 siblings, 0 replies; 45+ messages in thread
From: Pali Rohár @ 2016-03-30 14:33 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: Felipe Balbi, Tony Lindgren, Bin Liu,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
[-- Attachment #1: Type: Text/Plain, Size: 7865 bytes --]
On Wednesday 30 March 2016 16:01:53 Ivaylo Dimitrov wrote:
> On 30.03.2016 16:38, Felipe Balbi wrote:
> > Hi,
> >
> > Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> >>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> >>>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> >>>>>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> >>>>>>>> On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> On 16.01.2016 00:48, Tony Lindgren wrote:
> >>>>>>>>>> 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
> >>>>>>>>
> >>>>>>>> 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.
> >>>>>
> >>>>> 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)
> >>>
> >>> 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
> >
> > do you have two interfaces with mass storage ?
>
> There are 2 LUNs, not sure what you mean by 2 interfaces.
>
> Pali ^^^ ?
Yes, there should be one interface with two luns. Same as if you
modprobe g_mass_storage with param luns=2.
--
Pali Rohár
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <56FBDC51.9020602-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-03-30 14:33 ` Pali Rohár
@ 2016-03-30 18:50 ` Ivaylo Dimitrov
[not found] ` <56FC1FD8.6090003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-04 4:41 ` Felipe Balbi
2 siblings, 1 reply; 45+ messages in thread
From: Ivaylo Dimitrov @ 2016-03-30 18:50 UTC (permalink / raw)
To: Felipe Balbi, Tony Lindgren, Bin Liu, pali Rohár
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
[-- Attachment #1: Type: text/plain, Size: 8726 bytes --]
On 30.03.2016 17:01, Ivaylo Dimitrov wrote:
>
>
> On 30.03.2016 16:38, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>>>>> On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On 16.01.2016 00:48, Tony Lindgren wrote:
>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> 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)
>>>>
>>>> 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
>>
>> do you have two interfaces with mass storage ?
>>
>
> There are 2 LUNs, not sure what you mean by 2 interfaces.
>
> Pali ^^^ ?
>
>>> 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).
>
>>> 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
[-- Attachment #2: fsg.txt --]
[-- Type: text/plain, Size: 19050 bytes --]
************ boot log **********************
Jan 1 02:00:10 Nokia-N900 kernel: [ 1.152130] HS USB OTG: no transceiver configured
Jan 1 02:00:10 Nokia-N900 kernel: [ 1.157135] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
Jan 1 02:00:10 Nokia-N900 kernel: [ 1.165771] udc-core: couldn't find an available UDC - added [g_nokia] to list of pending drivers
Jan 1 02:00:10 Nokia-N900 kernel: [ 2.281066] twl 1-0048: PIH (irq 23) chaining IRQs 340..348
Jan 1 02:00:10 Nokia-N900 kernel: [ 2.287109] twl 1-0048: power (irq 345) chaining IRQs 348..355
Jan 1 02:00:10 Nokia-N900 kernel: [ 2.931243] twl4030_gpio twl4030-gpio: gpio (irq 340) chaining IRQs 356..373
Jan 1 02:00:10 Nokia-N900 kernel: [ 3.291046] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: Initialized TWL4030 USB module
Jan 1 02:00:10 Nokia-N900 kernel: [ 3.302307] input: twl4030_pwrbutton as /devices/platform/68000000.ocp/48070000.i2c/i2c-1/1-0048/48070000.i2c:twl@48:pwrbutton/input/input0
Jan 1 02:00:10 Nokia-N900 kernel: [ 3.317077] input: TWL4030 Keypad as /devices/platform/68000000.ocp/48070000.i2c/i2c-1/1-0048/48070000.i2c:twl@48:keypad/input/input1
Jan 1 02:00:10 Nokia-N900 kernel: [ 3.570678] 48070000.i2c:twl@48:madc supply vusb3v1 not found, using dummy regulator
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.802825] using random self ethernet address
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.811431] using random host ethernet address
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.819793] Mass Storage Function, version: 2009/09/11
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.828918] LUN: removable file: (no medium)
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.837249] LUN: removable file: (no medium)
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.845367] LUN: removable file: (no medium)
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.853271] Number of LUNs=2
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.860839] g_nokia gadget: USB CDC Phonet function
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.869323] g_nokia gadget: using musb-hdrc, OUT ep1out, IN ep1in
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.880096] usb0: HOST MAC de:00:11:fa:e2:ea
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.888153] usb0: MAC 86:7b:b1:f2:e1:40
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.895629] fsg_common_run_thread 3003 common->state 7 common->thread_task (null)
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.907501] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 4.6.0-rc1+ #6
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.917999] fsg_main_thread 2532 current ceb22d00
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.926544] Hardware name: Nokia RX-51 board
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.934631] Workqueue: deferwq deferred_probe_work_func
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.943756] [<c010bc18>] (unwind_backtrace) from [<c0109f38>] (show_stack+0x10/0x14)
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.955505] [<c0109f38>] (show_stack) from [<c041a4b4>] (fsg_bind+0x1c/0x200)
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.966552] [<c041a4b4>] (fsg_bind) from [<c040bef0>] (usb_add_function+0x84/0x130)
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.978149] [<c040bef0>] (usb_add_function) from [<c041b5d0>] (nokia_bind_config+0x1cc/0x328)
Jan 1 02:00:10 Nokia-N900 kernel: [ 7.990692] [<c041b5d0>] (nokia_bind_config) from [<c040c5b4>] (usb_add_config+0x28/0xbc)
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.026092] [<c040e128>] (composite_bind) from [<c0410cc8>] (udc_bind_to_driver+0x2c/0xb8)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.038330] [<c0410cc8>] (udc_bind_to_driver) from [<c0410fe4>] (usb_add_gadget_udc_release+0x16c/0x268)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.055603] [<c0410fe4>] (usb_add_gadget_udc_release) from [<c0409610>] (musb_gadget_setup+0x138/0x168)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.073242] [<c0409610>] (musb_gadget_setup) from [<c04029b8>] (musb_probe+0x560/0x750)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.085754] [<c04029b8>] (musb_probe) from [<c03a3090>] (platform_drv_probe+0x58/0xa0)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.098266] [<c03a3090>] (platform_drv_probe) from [<c03a187c>] (driver_probe_device+0x120/0x2b0)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.111938] [<c03a187c>] (driver_probe_device) from [<c039ff58>] (bus_for_each_drv+0x48/0x8c)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.125335] [<c039ff58>] (bus_for_each_drv) from [<c03a16c8>] (__device_attach+0x88/0xf8)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.138336] [<c03a16c8>] (__device_attach) from [<c03a0d58>] (bus_probe_device+0x28/0x80)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.151519] [<c03a0d58>] (bus_probe_device) from [<c03a11b0>] (deferred_probe_work_func+0x58/0x84)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.170257] [<c03a11b0>] (deferred_probe_work_func) from [<c013b3c8>] (process_one_work+0x1c4/0x324)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.189514] [<c013b3c8>] (process_one_work) from [<c013b86c>] (worker_thread+0x314/0x4a8)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.203186] [<c013b86c>] (worker_thread) from [<c013fe5c>] (kthread+0xcc/0xe0)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.216003] [<c013fe5c>] (kthread) from [<c0107218>] (ret_from_fork+0x14/0x3c)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.228729] fsg_bind 3062 common ce000000
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.238067] g_nokia gadget: USB CDC Phonet function
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.248199] g_nokia gadget: using musb-hdrc, OUT ep1out, IN ep1in
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.259735] fsg_common_run_thread 3003 common->state 0 common->thread_task ceb22d00
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.273040] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 4.6.0-rc1+ #6
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.284973] fsg_main_thread 2532 current ceb23200
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.294952] Hardware name: Nokia RX-51 board
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.304412] Workqueue: deferwq deferred_probe_work_func
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.315002] [<c010bc18>] (unwind_backtrace) from [<c0109f38>] (show_stack+0x10/0x14)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.328155] [<c0109f38>] (show_stack) from [<c041a4b4>] (fsg_bind+0x1c/0x200)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.340606] [<c041a4b4>] (fsg_bind) from [<c040bef0>] (usb_add_function+0x84/0x130)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.353668] [<c040bef0>] (usb_add_function) from [<c041b5d0>] (nokia_bind_config+0x1cc/0x328)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.367706] [<c041b5d0>] (nokia_bind_config) from [<c040c5b4>] (usb_add_config+0x28/0xbc)
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)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.407257] [<c040e128>] (composite_bind) from [<c0410cc8>] (udc_bind_to_driver+0x2c/0xb8)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.420776] [<c0410cc8>] (udc_bind_to_driver) from [<c0410fe4>] (usb_add_gadget_udc_release+0x16c/0x268)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.440185] [<c0410fe4>] (usb_add_gadget_udc_release) from [<c0409610>] (musb_gadget_setup+0x138/0x168)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.459686] [<c0409610>] (musb_gadget_setup) from [<c04029b8>] (musb_probe+0x560/0x750)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.473083] [<c04029b8>] (musb_probe) from [<c03a3090>] (platform_drv_probe+0x58/0xa0)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.486358] [<c03a3090>] (platform_drv_probe) from [<c03a187c>] (driver_probe_device+0x120/0x2b0)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.500671] [<c03a187c>] (driver_probe_device) from [<c039ff58>] (bus_for_each_drv+0x48/0x8c)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.514709] [<c039ff58>] (bus_for_each_drv) from [<c03a16c8>] (__device_attach+0x88/0xf8)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.528259] [<c03a16c8>] (__device_attach) from [<c03a0d58>] (bus_probe_device+0x28/0x80)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.541778] [<c03a0d58>] (bus_probe_device) from [<c03a11b0>] (deferred_probe_work_func+0x58/0x84)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.560760] [<c03a11b0>] (deferred_probe_work_func) from [<c013b3c8>] (process_one_work+0x1c4/0x324)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.580139] [<c013b3c8>] (process_one_work) from [<c013b86c>] (worker_thread+0x314/0x4a8)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.593933] [<c013b86c>] (worker_thread) from [<c013fe5c>] (kthread+0xcc/0xe0)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.606719] [<c013fe5c>] (kthread) from [<c0107218>] (ret_from_fork+0x14/0x3c)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.619415] fsg_bind 3062 common ce000000
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.628662] g_nokia gadget: N900 (PC-Suite Mode)
Jan 1 02:00:10 Nokia-N900 kernel: [ 8.638488] g_nokia gadget: g_nokia ready
*********** unbind ***********
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.511474] CPU: 0 PID: 3241 Comm: sh Not tainted 4.6.0-rc1+ #6
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.517944] Hardware name: Nokia RX-51 board
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.534576] [<c010bc18>] (unwind_backtrace) from [<c0109f38>] (show_stack+0x10/0x14)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.561431] [<c0109f38>] (show_stack) from [<c0417310>] (fsg_unbind+0x14/0xc0)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.572906] [<c0417310>] (fsg_unbind) from [<c040b94c>] (remove_config+0x44/0x88)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.583038] [<c040b94c>] (remove_config) from [<c040e05c>] (__composite_unbind+0x3c/0x98)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.594787] [<c040e05c>] (__composite_unbind) from [<c04102c4>] (usb_gadget_remove_driver+0x7c/0xa4)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.607330] [<c04102c4>] (usb_gadget_remove_driver) from [<c0410388>] (usb_del_gadget_udc+0x54/0xa4)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.619812] [<c0410388>] (usb_del_gadget_udc) from [<c0401c1c>] (musb_shutdown+0x24/0xdc)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.630096] [<c0401c1c>] (musb_shutdown) from [<c0402160>] (musb_remove+0x20/0x80)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.640960] [<c0402160>] (musb_remove) from [<c03a301c>] (platform_drv_remove+0x24/0x40)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.649780] [<c03a301c>] (platform_drv_remove) from [<c03a1b80>] (__device_release_driver+0x94/0x108)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.661956] [<c03a1b80>] (__device_release_driver) from [<c03a1c10>] (device_release_driver+0x1c/0x28)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.674468] [<c03a1c10>] (device_release_driver) from [<c03a04e0>] (unbind_store+0x58/0x8c)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.686157] [<c03a04e0>] (unbind_store) from [<c039fd74>] (drv_attr_store+0x20/0x2c)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.697113] [<c039fd74>] (drv_attr_store) from [<c0242e10>] (sysfs_kf_write+0x3c/0x48)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.708251] [<c0242e10>] (sysfs_kf_write) from [<c0242038>] (kernfs_fop_write+0x134/0x198)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.718597] [<c0242038>] (kernfs_fop_write) from [<c01dbca4>] (__vfs_write+0x2c/0xd4)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.728759] [<c01dbca4>] (__vfs_write) from [<c01dd28c>] (vfs_write+0xa0/0x18c)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.738006] [<c01dd28c>] (vfs_write) from [<c01dd570>] (SyS_write+0x3c/0x78)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.747650] [<c01dd570>] (SyS_write) from [<c0107160>] (ret_fast_syscall+0x0/0x3c)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.757141] fsg_unbind 3147 common ce000000 common->fsg (null) fsg cebc4b40
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.768341] CPU: 0 PID: 3241 Comm: sh Not tainted 4.6.0-rc1+ #6
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.777221] Hardware name: Nokia RX-51 board
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.783477] [<c010bc18>] (unwind_backtrace) from [<c0109f38>] (show_stack+0x10/0x14)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.793243] [<c0109f38>] (show_stack) from [<c0417310>] (fsg_unbind+0x14/0xc0)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.802398] [<c0417310>] (fsg_unbind) from [<c040b94c>] (remove_config+0x44/0x88)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.811828] [<c040b94c>] (remove_config) from [<c040e05c>] (__composite_unbind+0x3c/0x98)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.821990] [<c040e05c>] (__composite_unbind) from [<c04102c4>] (usb_gadget_remove_driver+0x7c/0xa4)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.833190] [<c04102c4>] (usb_gadget_remove_driver) from [<c0410388>] (usb_del_gadget_udc+0x54/0xa4)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.845916] [<c0410388>] (usb_del_gadget_udc) from [<c0401c1c>] (musb_shutdown+0x24/0xdc)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.856445] [<c0401c1c>] (musb_shutdown) from [<c0402160>] (musb_remove+0x20/0x80)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.865997] [<c0402160>] (musb_remove) from [<c03a301c>] (platform_drv_remove+0x24/0x40)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.877380] [<c03a301c>] (platform_drv_remove) from [<c03a1b80>] (__device_release_driver+0x94/0x108)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.888977] [<c03a1b80>] (__device_release_driver) from [<c03a1c10>] (device_release_driver+0x1c/0x28)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.901336] [<c03a1c10>] (device_release_driver) from [<c03a04e0>] (unbind_store+0x58/0x8c)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.910308] [<c03a04e0>] (unbind_store) from [<c039fd74>] (drv_attr_store+0x20/0x2c)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.921081] [<c039fd74>] (drv_attr_store) from [<c0242e10>] (sysfs_kf_write+0x3c/0x48)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.929595] [<c0242e10>] (sysfs_kf_write) from [<c0242038>] (kernfs_fop_write+0x134/0x198)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.941925] [<c0242038>] (kernfs_fop_write) from [<c01dbca4>] (__vfs_write+0x2c/0xd4)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.951721] [<c01dbca4>] (__vfs_write) from [<c01dd28c>] (vfs_write+0xa0/0x18c)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.959686] [<c01dd28c>] (vfs_write) from [<c01dd570>] (SyS_write+0x3c/0x78)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.969329] [<c01dd570>] (SyS_write) from [<c0107160>] (ret_fast_syscall+0x0/0x3c)
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.978790] fsg_unbind 3147 common ce000000 common->fsg (null) fsg ce006180
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.987823] handle_exception 2354 current ceb23200
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.994323] handle_exception 2408 current ceb23200
Jan 1 06:02:14 Nokia-N900 kernel: [ 194.999542] handle_exception 2502 current ceb23200 common->state 7
Jan 1 06:02:14 Nokia-N900 kernel: [ 195.008117] fsg_main_thread 2593 current ceb23200
******************* /dev/mtd2ro ******************************************
<7>[ 3141.642486] pvr: hildon-desktop: cleaning up 366 unfreed resources
<6>[ 3146.602142] wlan0: deauthenticating from 10:fe:ed:dd:f7:61 by local choice (Reason: 3=DEAUTH_LEAVING)
<4>[ 3147.980529] sched: RT throttling activated
<7>[ 3149.357116] wl1251: down
<7>[ 3150.421325] wl1251: 151 tx blocks at 0x3b788, 35 rx blocks at 0x3a780
<7>[ 3150.444519] wl1251: firmware booted (Rev 4.0.4.3.7)
<6>[ 3150.722106] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
<1>[ 3154.986114] Unable to handle kernel paging request at virtual address 6c6c757a
<1>[ 3155.123931] pgd = c0004000
<1>[ 3155.187896] [6c6c757a] *pgd=00000000
<0>[ 3155.226989] Internal error: Oops: 5 [#1] PREEMPT ARM
<4>[ 3155.227020] Modules linked in: smiapp smiapp_pll 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 isp1704_charger wl1251_spi gpio_keys wl1251 smc91x mii mac80211 omap3_isp cfg80211 omap_wdt videobuf2_v4l2 videobuf2_dma_contig videobuf2_memops videobuf2_core omap_sham crc7 tsc2005 tsc200x_core bq27xxx_battery_i2c bq27xxx_battery leds_lp5523 leds_lp55xx_common adp1653 si4713 et8ek8 tsl2563 smiaregs ad5820 v4l2_common videodev twl4030_wdt rtc_twl twl4030_vibra ff_memless lis3lv02d_i2c lis3lv02d media input_polldev omap_ssi_port ti_soc_thermal nokia_modem ssi_protocol omap_ssi hsi rx51_battery
<4>[ 3155.227264] CPU: 0 PID: 55 Comm: file-storage Not tainted 4.6.0-rc1+ #2
<4>[ 3155.227264] Hardware name: Nokia RX-51 board
<4>[ 3155.227294] task: ceb22d00 ti: ce00a000 task.ti: ce00a000
<4>[ 3155.227325] PC is at handle_exception+0xa8/0x418
<4>[ 3155.227325] LR is at recalc_sigpending+0x18/0x7c
<4>[ 3155.227355] pc : [<c0418a94>] lr : [<c0130484>] psr: 80000013
<4>[ 3155.227355] sp : ce00bea0 ip : 00000000 fp : 00000000
<4>[ 3155.227355] r10: 00000000 r9 : 00000000 r8 : 00000000
<4>[ 3155.227355] r7 : c0419280 r6 : 6c6c7566 r5 : 00000000 r4 : ce000000
<4>[ 3155.227355] r3 : 6f642820 r2 : 00000000 r1 : 00000000 r0 : 00000000
<4>[ 3155.227386] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
<4>[ 3155.227386] Control: 10c5387d Table: 8e270019 DAC: 00000051
<0>[ 3155.227386] Process file-storage (pid: 55, stack limit = 0xce00a210)
<0>[ 3155.227386] Stack: (0xce00bea0 to 0xce00c000)
<0>[ 3155.227416] bea0: 0000000f 00000000 00000000 00001123 00000000 00000001 000003ff 00000001
<0>[ 3155.227416] bec0: ceb22d00 ceb22d00 00000000 c0140e20 00000000 00000002 ce886000 c054ed90
<0>[ 3155.227447] bee0: ffffffff 00000000 00000000 00000008 ce000000 00000001 c09506e0 00000001
<0>[ 3155.227447] bf00: 00000000 00000000 ce00bf14 c054b230 00000000 c04179cc 00000042 ce00bf30
<0>[ 3155.227478] bf20: ce00bf30 00000000 ce000000 c0419308 00000000 c054aca4 a0000013 00000000
<0>[ 3155.227478] bf40: ce000000 c0419280 cebf6c40 cebf6c40 00000000 ce000000 c0419280 00000000
<0>[ 3155.227508] bf60: 00000000 00000000 00000000 c013fe5c 00000000 00000000 00000000 ce000000
<0>[ 3155.227508] bf80: 00000000 ce00bf84 ce00bf84 00000000 ce00bf90 ce00bf90 ce00bfac cebf6c40
<0>[ 3155.227539] bfa0: c013fd90 00000000 00000000 c0107218 00000000 00000000 00000000 00000000
<0>[ 3155.227539] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<0>[ 3155.227569] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
<4>[ 3155.227600] [<c0418a94>] (handle_exception) from [<c0419308>] (fsg_main_thread+0x88/0x13dc)
<4>[ 3155.227630] [<c0419308>] (fsg_main_thread) from [<c013fe5c>] (kthread+0xcc/0xe0)
<4>[ 3155.227661] [<c013fe5c>] (kthread) from [<c0107218>] (ret_from_fork+0x14/0x3c)
<0>[ 3155.227661] Code: 1a000015 ea000040 e5946038 e0866285 (e5963014)
<4>[ 3155.227691] ---[ end trace 13330bb6a6df861f ]---
<7>[ 3155.248535] pvr: Xorg: cleaning up 49 unfreed resources
<7>[ 3155.266998] mtdoops: ready 14, 15 (no erase)
<0>[ 3155.267089] Kernel panic - not syncing: Fatal exception
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <56FC1FD8.6090003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-03-30 18:54 ` Ivaylo Dimitrov
2016-03-30 19:25 ` Alan Stern
1 sibling, 0 replies; 45+ messages in thread
From: Ivaylo Dimitrov @ 2016-03-30 18:54 UTC (permalink / raw)
To: Felipe Balbi, Tony Lindgren, Bin Liu, pali Rohár
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
[-- Attachment #1: Type: text/plain, Size: 9192 bytes --]
On 30.03.2016 21:50, Ivaylo Dimitrov wrote:
>
>
> On 30.03.2016 17:01, Ivaylo Dimitrov wrote:
>>
>>
>> On 30.03.2016 16:38, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>>>>> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>>>>>> On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> On 16.01.2016 00:48, Tony Lindgren wrote:
>>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>> 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)
>>>>>
>>>>> 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
>>>
>>> do you have two interfaces with mass storage ?
>>>
>>
>> There are 2 LUNs, not sure what you mean by 2 interfaces.
>>
>> Pali ^^^ ?
>>
>>>> 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).
>>
>>>> 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
Sorry, forgot to attach the patch used to produce the log
[-- Attachment #2: fsg.diff --]
[-- Type: text/x-diff, Size: 3729 bytes --]
diff --git a/drivers/usb/gadget/function/f_mass_storage.c b/drivers/usb/gadget/function/f_mass_storage.c
index acf210f..0a29d84 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -2351,6 +2351,8 @@ static void handle_exception(struct fsg_common *common)
struct fsg_lun *curlun;
unsigned int exception_req_tag;
+ pr_err("%s %d current %p\n", __func__, __LINE__, current);
+
/*
* Clear the existing signals. Anything but SIGUSR1 is converted
* into a high-priority EXIT exception.
@@ -2368,8 +2370,12 @@ static void handle_exception(struct fsg_common *common)
/* Cancel all the pending transfers */
if (likely(common->fsg)) {
+ pr_err("%s %d current %p common->fsg_num_buffers %d\n",
+ __func__, __LINE__, current, common->fsg_num_buffers);
for (i = 0; i < common->fsg_num_buffers; ++i) {
bh = &common->buffhds[i];
+ pr_err("%s %d bh %p\n", __func__, __LINE__, bh);
+ msleep(2000);
if (bh->inreq_busy)
usb_ep_dequeue(common->fsg->bulk_in, bh->inreq);
if (bh->outreq_busy)
@@ -2377,6 +2383,8 @@ static void handle_exception(struct fsg_common *common)
bh->outreq);
}
+ pr_err("%s %d current %p\n", __func__, __LINE__, current);
+
/* Wait until everything is idle */
for (;;) {
int num_active = 0;
@@ -2397,6 +2405,8 @@ static void handle_exception(struct fsg_common *common)
usb_ep_fifo_flush(common->fsg->bulk_out);
}
+ pr_err("%s %d current %p\n", __func__, __LINE__, current);
+
/*
* Reset the I/O buffer states and pointers, the SCSI
* state, and the exception. Then invoke the handler.
@@ -2487,6 +2497,10 @@ static void handle_exception(struct fsg_common *common)
case FSG_STATE_IDLE:
break;
}
+
+ pr_err("%s %d current %p common->state %d\n", __func__, __LINE__,
+ current, common->state);
+
}
@@ -2515,6 +2529,8 @@ static int fsg_main_thread(void *common_)
*/
set_fs(get_ds());
+ pr_err("%s %d current %p\n", __func__, __LINE__, current);
+
/* The main loop */
while (common->state != FSG_STATE_TERMINATED) {
if (exception_in_progress(common) || signal_pending(current)) {
@@ -2527,6 +2543,8 @@ static int fsg_main_thread(void *common_)
continue;
}
+ pr_err("%s %d current %p\n", __func__, __LINE__, current);
+
if (get_next_command(common))
continue;
@@ -2572,6 +2590,8 @@ static int fsg_main_thread(void *common_)
up_write(&common->filesem);
}
+ pr_err("%s %d current %p\n", __func__, __LINE__, current);
+
/* Let fsg_unbind() know the thread has exited */
complete_and_exit(&common->thread_notifier, 0);
}
@@ -2979,6 +2999,8 @@ EXPORT_SYMBOL_GPL(fsg_common_set_inquiry_string);
int fsg_common_run_thread(struct fsg_common *common)
{
+ pr_err("%s %d common->state %d common->thread_task %p\n", __func__,
+ __LINE__, common->state, common->thread_task);
common->state = FSG_STATE_IDLE;
/* Tell the thread to start working */
common->thread_task =
@@ -3036,6 +3058,8 @@ static int fsg_bind(struct usb_configuration *c, struct usb_function *f)
int ret;
struct fsg_opts *opts;
+ dump_stack();
+ pr_err("%s %d common %p\n", __func__, __LINE__, common);
/* Don't allow to bind if we don't have at least one LUN */
ret = _fsg_common_get_max_lun(common);
if (ret < 0) {
@@ -3118,6 +3142,10 @@ static void fsg_unbind(struct usb_configuration *c, struct usb_function *f)
struct fsg_dev *fsg = fsg_from_func(f);
struct fsg_common *common = fsg->common;
+ dump_stack();
+ pr_err("%s %d common %p common->fsg %p fsg %p\n", __func__, __LINE__,
+ common, common->fsg, fsg);
+
DBG(fsg, "unbind\n");
if (fsg->common->fsg == fsg) {
fsg->common->new_fsg = NULL;
^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <56FC1FD8.6090003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-03-30 18:54 ` Ivaylo Dimitrov
@ 2016-03-30 19:25 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1603301509180.2194-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
1 sibling, 1 reply; 45+ messages in thread
From: Alan Stern @ 2016-03-30 19:25 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: Felipe Balbi, Tony Lindgren, Bin Liu, pali Rohár,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
On Wed, 30 Mar 2016, Ivaylo Dimitrov wrote:
> >>> 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).
> >
> >>> 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 :)
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.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <Pine.LNX.4.44L0.1603301509180.2194-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2016-03-30 19:41 ` Tony Lindgren
2016-03-31 16:32 ` Ivaylo Dimitrov
1 sibling, 0 replies; 45+ messages in thread
From: Tony Lindgren @ 2016-03-30 19:41 UTC (permalink / raw)
To: Alan Stern
Cc: Ivaylo Dimitrov, Felipe Balbi, Bin Liu, pali Rohár,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
* Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> [160330 12:26]:
> On Wed, 30 Mar 2016, Ivaylo Dimitrov wrote:
>
> > >>> 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).
> > >
> > >>> 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 :)
>
> 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.
Maybe drivers/usb/gadget/legacy/ether.c suffers from a similar issue
as that's what I noticed the $subject problem with.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <Pine.LNX.4.44L0.1603301509180.2194-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-03-30 19:41 ` Tony Lindgren
@ 2016-03-31 16:32 ` Ivaylo Dimitrov
[not found] ` <56FD512C.2070108-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
1 sibling, 1 reply; 45+ messages in thread
From: Ivaylo Dimitrov @ 2016-03-31 16:32 UTC (permalink / raw)
To: Alan Stern
Cc: Felipe Balbi, Tony Lindgren, Bin Liu, pali Rohár,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
On 30.03.2016 22:25, Alan Stern wrote:
> On Wed, 30 Mar 2016, Ivaylo Dimitrov wrote:
>
>>>>> 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).
>>>
>>>>> 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 :)
>
> 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);
>
Right, somehow I've overslept there are two different nokia_bind+XXX values.
> 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.
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <56FD512C.2070108-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-03-31 17:00 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1603311255560.1516-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Alan Stern @ 2016-03-31 17:00 UTC (permalink / raw)
To: Ivaylo Dimitrov, Michal Nazarewicz
Cc: Felipe Balbi, Tony Lindgren, Bin Liu, pali Rohár, USB list,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
On Thu, 31 Mar 2016, Ivaylo Dimitrov wrote:
> > 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.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <Pine.LNX.4.44L0.1603311255560.1516-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2016-04-01 17:02 ` Michal Nazarewicz
[not found] ` <xa1tmvpdz2h4.fsf-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
2016-04-04 4:45 ` Felipe Balbi
1 sibling, 1 reply; 45+ messages in thread
From: Michal Nazarewicz @ 2016-04-01 17:02 UTC (permalink / raw)
To: Alan Stern, Ivaylo Dimitrov
Cc: Felipe Balbi, Tony Lindgren, Bin Liu, pali Rohár, USB list,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
On Thu, Mar 31 2016, Alan Stern wrote:
> Michal, I'm not sure how you intended to handle this.
For legacy/nokia setting no_configfs should be a valid solution:
---- >8 ----------------------------------------------------------------
diff --git a/drivers/usb/gadget/legacy/nokia.c b/drivers/usb/gadget/legacy/nokia.c
index 0997504..e4bc607 100644
--- a/drivers/usb/gadget/legacy/nokia.c
+++ b/drivers/usb/gadget/legacy/nokia.c
@@ -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 ----------------------------------------------------------------
diff --git a/drivers/usb/gadget/function/f_mass_storage.c b/drivers/usb/gadget/function/f_mass_storage.c
index acf210f..62854b6 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -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) {
@@ -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) {
+ ret = fsg_common_run_thread(fsg->common);
+ if (ret)
+ return ret;
+ }
}
fsg->gadget = gadget;
---- >8 ---------------------------------------------------------------
^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <xa1tmvpdz2h4.fsf-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
@ 2016-04-01 19:18 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1604011452580.1957-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-04-05 15:18 ` Michal Nazarewicz
1 sibling, 1 reply; 45+ messages in thread
From: Alan Stern @ 2016-04-01 19:18 UTC (permalink / raw)
To: Michal Nazarewicz
Cc: Ivaylo Dimitrov, Felipe Balbi, Tony Lindgren, Bin Liu,
pali Rohár, USB list, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, Robert Baldyga, Andrzej Pietrasiewicz
On Fri, 1 Apr 2016, Michal Nazarewicz wrote:
> On Thu, Mar 31 2016, Alan Stern wrote:
> > Michal, I'm not sure how you intended to handle this.
>
> For legacy/nokia setting no_configfs should be a valid solution:
>
> ---- >8 ----------------------------------------------------------------
> diff --git a/drivers/usb/gadget/legacy/nokia.c b/drivers/usb/gadget/legacy/nokia.c
> index 0997504..e4bc607 100644
> --- a/drivers/usb/gadget/legacy/nokia.c
> +++ b/drivers/usb/gadget/legacy/nokia.c
> @@ -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.
Okay, that makes sense. Legacy gadgets aren't meant to be used with
configfs anyway.
> For configfs, why not simply check if the thread has already been
> started:
>
> ---- >8 ----------------------------------------------------------------
> diff --git a/drivers/usb/gadget/function/f_mass_storage.c b/drivers/usb/gadget/function/f_mass_storage.c
> index acf210f..62854b6 100644
> --- a/drivers/usb/gadget/function/f_mass_storage.c
> +++ b/drivers/usb/gadget/function/f_mass_storage.c
> @@ -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) {
> @@ -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)?
> + 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.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <Pine.LNX.4.44L0.1604011452580.1957-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2016-04-01 22:16 ` Michal Nazarewicz
[not found] ` <xa1tbn5tynyp.fsf-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Michal Nazarewicz @ 2016-04-01 22:16 UTC (permalink / raw)
To: Alan Stern
Cc: Ivaylo Dimitrov, Felipe Balbi, Tony Lindgren, Bin Liu,
pali Rohár, USB list, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, Robert Baldyga, Andrzej Pietrasiewicz
> On Fri, 1 Apr 2016, Michal Nazarewicz wrote:
>> @@ -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) {
>
On Fri, Apr 01 2016, Alan Stern wrote:
> Do you mean: if (!common->thread_task)?
Correct.
>> + 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).
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.
> 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.
--
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <xa1tbn5tynyp.fsf-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
@ 2016-04-02 14:55 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1604021031030.19366-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Alan Stern @ 2016-04-02 14:55 UTC (permalink / raw)
To: Michal Nazarewicz
Cc: Ivaylo Dimitrov, Felipe Balbi, Tony Lindgren, Bin Liu,
pali Rohár, USB list, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, Robert Baldyga, Andrzej Pietrasiewicz
On Sat, 2 Apr 2016, Michal Nazarewicz wrote:
> > 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).
>
> 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.
That sounds right. I vaguely remember when I did look at this stuff
years ago, the names were backward -- usb_function refers to an
instance while usb_function_instance refers to a driver (which
obviously doesn't have instances).
> > 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).
That doesn't matter for our purposes now.
> 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.
> 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.
> 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.
Perhaps because f_mass_storage calls fsg_common_run_thread from the
wrong place.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <56FBDC51.9020602-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-03-30 14:33 ` Pali Rohár
2016-03-30 18:50 ` Ivaylo Dimitrov
@ 2016-04-04 4:41 ` Felipe Balbi
2 siblings, 0 replies; 45+ messages in thread
From: Felipe Balbi @ 2016-04-04 4:41 UTC (permalink / raw)
To: Ivaylo Dimitrov, Tony Lindgren, Bin Liu, pali Rohár
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
[-- Attachment #1: Type: text/plain, Size: 7804 bytes --]
Hi,
Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> 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)
>>>>
>>>> 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
>>
>> do you have two interfaces with mass storage ?
>>
>
> There are 2 LUNs, not sure what you mean by 2 interfaces.
do you call fsg_bind() twice ?
>>> 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).
yeah, sounds like we have a problem indeed.
>>> 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.
cool, thanks
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <Pine.LNX.4.44L0.1603311255560.1516-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-04-01 17:02 ` Michal Nazarewicz
@ 2016-04-04 4:45 ` Felipe Balbi
1 sibling, 0 replies; 45+ messages in thread
From: Felipe Balbi @ 2016-04-04 4:45 UTC (permalink / raw)
To: Alan Stern, Ivaylo Dimitrov, Michal Nazarewicz
Cc: Tony Lindgren, Bin Liu, pali Rohár, USB list,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]
Hi,
Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> writes:
> On Thu, 31 Mar 2016, Ivaylo Dimitrov wrote:
>
>> > 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.
I agree, this is now very clear what the problem is.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <Pine.LNX.4.44L0.1604021031030.19366-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2016-04-04 12:57 ` Michal Nazarewicz
[not found] ` <xa1ty48tilai.fsf-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Michal Nazarewicz @ 2016-04-04 12:57 UTC (permalink / raw)
To: Alan Stern
Cc: Ivaylo Dimitrov, Felipe Balbi, Tony Lindgren, Bin Liu,
pali Rohár, USB list, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, Robert Baldyga, Andrzej Pietrasiewicz
On Sat, Apr 02 2016, Alan Stern wrote:
> On Sat, 2 Apr 2016, Michal Nazarewicz wrote:
>> 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.
I believe the failure is related to the thread being started twice where
it indeed shouldn’t.
>> 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;
}
> 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.:
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -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.
--
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <xa1ty48tilai.fsf-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
@ 2016-04-04 15:04 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1604041038510.1704-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-04-04 16:18 ` Ivaylo Dimitrov
1 sibling, 1 reply; 45+ messages in thread
From: Alan Stern @ 2016-04-04 15:04 UTC (permalink / raw)
To: Michal Nazarewicz
Cc: Ivaylo Dimitrov, Felipe Balbi, Tony Lindgren, Bin Liu,
pali Rohár, USB list, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, Robert Baldyga, Andrzej Pietrasiewicz
On Mon, 4 Apr 2016, Michal Nazarewicz wrote:
> On Sat, Apr 02 2016, Alan Stern wrote:
> > On Sat, 2 Apr 2016, Michal Nazarewicz wrote:
> >> 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.
>
> I believe the failure is related to the thread being started twice where
> it indeed shouldn’t.
Yes, of course. The questions we need to answer are: Why is the thread
being started twice, and how can we fix it?
> >> 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):
Note: I did not ask what happens when a configuration is _created_; I
asked what happens when a configuration is _installed_ -- that is, when
the host sends a Set-Config request.
> 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;
> }
So there is no way to add a single function to several configurations?
> 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;
> }
>
> > 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.
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).
> This is also why the thread is not stopped in fsg_unbind but only once
> fsg_common structure is released.
This design is a holdover from the days before the composite core
existed and g_file_storage was a standalone gadget driver. It could
stand to be updated.
> 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.
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.
> 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.
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.
That's my opinion; you may disagree.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <xa1ty48tilai.fsf-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
2016-04-04 15:04 ` Alan Stern
@ 2016-04-04 16:18 ` Ivaylo Dimitrov
[not found] ` <570293E8.2060406-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
1 sibling, 1 reply; 45+ messages in thread
From: Ivaylo Dimitrov @ 2016-04-04 16:18 UTC (permalink / raw)
To: Michal Nazarewicz, Alan Stern
Cc: Felipe Balbi, Tony Lindgren, Bin Liu, pali Rohár, USB list,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
Hi,
On 4.04.2016 15:57, Michal Nazarewicz wrote:
> On Sat, Apr 02 2016, Alan Stern wrote:
>> 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.:
>
> --- a/drivers/usb/gadget/function/f_mass_storage.c
> +++ b/drivers/usb/gadget/function/f_mass_storage.c
> @@ -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.
>
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?
Regards,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <Pine.LNX.4.44L0.1604041038510.1704-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2016-04-04 18:18 ` Michal Nazarewicz
[not found] ` <xa1ttwjhi6fo.fsf-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Michal Nazarewicz @ 2016-04-04 18:18 UTC (permalink / raw)
To: Alan Stern
Cc: Ivaylo Dimitrov, Felipe Balbi, Tony Lindgren, Bin Liu,
pali Rohár, USB list, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, Robert Baldyga, Andrzej Pietrasiewicz
On Mon, Apr 04 2016, Alan Stern wrote:
> 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.
> 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.
> 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.
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.
--
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <570293E8.2060406-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-04-04 18:48 ` Michal Nazarewicz
0 siblings, 0 replies; 45+ messages in thread
From: Michal Nazarewicz @ 2016-04-04 18:48 UTC (permalink / raw)
To: Ivaylo Dimitrov, Alan Stern
Cc: Felipe Balbi, Tony Lindgren, Bin Liu, pali Rohár, USB list,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
On Mon, Apr 04 2016, Ivaylo Dimitrov wrote:
> 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?
Currently the thread is killed when fsg_common structure is released and
that structure has a reference counter.
--
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <xa1ttwjhi6fo.fsf-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
@ 2016-04-04 19:37 ` Alan Stern
0 siblings, 0 replies; 45+ messages in thread
From: Alan Stern @ 2016-04-04 19:37 UTC (permalink / raw)
To: Michal Nazarewicz
Cc: Ivaylo Dimitrov, Felipe Balbi, Tony Lindgren, Bin Liu,
pali Rohár, USB list, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, Robert Baldyga, Andrzej Pietrasiewicz
On Mon, 4 Apr 2016, Michal Nazarewicz wrote:
> On Mon, Apr 04 2016, Alan Stern wrote:
> > 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.
>
> > 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.
I suppose so.
> > 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.
True. (Provided one understands that a function instance corresponds
to the usb_function structure, not the usb_function_instance
structure.)
> 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.
Okay. However, I noticed your patch does:
> + if (!common->thread_task) {
> + common->state = FSG_STATE_IDLE;
> + common->thread_task =
> + kthread_create(fsg_main_thread, common,
in fsg_bind(). How could thread_task ever be non-NULL at this point?
Wouldn't that mean the usb_function structure was registered twice?
Which brings us back to the nokia driver. Apparently it _does_ manage
to create the thread twice. How can this happen? The function that
nokia_bind_config() registers is created dynamically:
f_msg = usb_get_function(fi_msg);
which goes through fsg_alloc().
Aha, and now I see the problem. fsg_alloc() shares opts->common among
all the fsg structures it creates. This means all the function
instances will share common->thread_task, because they all share
common. The same goes for common->state and a bunch of other fields.
It looks like a lot of stuff has to move out of fsg->common and into
fsg.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <xa1tmvpdz2h4.fsf-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
2016-04-01 19:18 ` Alan Stern
@ 2016-04-05 15:18 ` Michal Nazarewicz
1 sibling, 0 replies; 45+ messages in thread
From: Michal Nazarewicz @ 2016-04-05 15:18 UTC (permalink / raw)
To: Alan Stern, Ivaylo Dimitrov
Cc: Felipe Balbi, Tony Lindgren, Bin Liu, pali Rohár, USB list,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz
On Fri, Apr 01 2016, Michal Nazarewicz wrote:
> For legacy/nokia setting no_configfs should be a valid solution:
>
> ---- >8 ----------------------------------------------------------------
> diff --git a/drivers/usb/gadget/legacy/nokia.c b/drivers/usb/gadget/legacy/nokia.c
> index 0997504..e4bc607 100644
> --- a/drivers/usb/gadget/legacy/nokia.c
> +++ b/drivers/usb/gadget/legacy/nokia.c
> @@ -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.
Scratch that. legacy/nokia sets no_configfs in nokia_bind so
legacy/nokia appears to be a different issue all together.
--
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <569A1E32.1020502-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-01-18 16:16 ` Tony Lindgren
2016-03-23 18:24 ` Ivaylo Dimitrov
@ 2016-04-08 20:13 ` Ivaylo Dimitrov
[not found] ` <57081105.2050206-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2 siblings, 1 reply; 45+ messages in thread
From: Ivaylo Dimitrov @ 2016-04-08 20:13 UTC (permalink / raw)
To: Tony Lindgren, Felipe Balbi
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz, Alan Stern,
Michal Nazarewicz
Hi,
On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
> Hi,
>
> On 16.01.2016 00:48, Tony Lindgren wrote:
>> 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.
(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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <57081105.2050206-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-04-18 7:02 ` Ivaylo Dimitrov
[not found] ` <571486A1.2060006-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-18 7:55 ` Felipe Balbi
1 sibling, 1 reply; 45+ messages in thread
From: Ivaylo Dimitrov @ 2016-04-18 7:02 UTC (permalink / raw)
To: Tony Lindgren, Felipe Balbi
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz, Alan Stern,
Michal Nazarewicz, Pali Rohár, Sebastian Reichel,
Pavel Machek
On 8.04.2016 23:13, Ivaylo Dimitrov wrote:
> Hi,
>
> On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
>> Hi,
>>
>> On 16.01.2016 00:48, Tony Lindgren wrote:
>>> 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
Anyone?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <57081105.2050206-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-18 7:02 ` Ivaylo Dimitrov
@ 2016-04-18 7:55 ` Felipe Balbi
[not found] ` <87oa97gxkw.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
1 sibling, 1 reply; 45+ messages in thread
From: Felipe Balbi @ 2016-04-18 7:55 UTC (permalink / raw)
To: Ivaylo Dimitrov, Tony Lindgren
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz, Alan Stern,
Michal Nazarewicz
[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]
Hi,
Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> Hi,
>
> On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
>> Hi,
>>
>> On 16.01.2016 00:48, Tony Lindgren wrote:
>>> 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.
>
> (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.
right, care to enable lockup detection and see if you can get more info
out of it ?
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <87oa97gxkw.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
@ 2016-04-25 19:00 ` Ivaylo Dimitrov
[not found] ` <571E6943.30305-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Ivaylo Dimitrov @ 2016-04-25 19:00 UTC (permalink / raw)
To: Felipe Balbi, Tony Lindgren
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz, Alan Stern,
Michal Nazarewicz
Hi,
On 18.04.2016 10:55, Felipe Balbi wrote:
>
> Hi,
>
> Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>> Hi,
>>
>> On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
>>> Hi,
>>>
>>> On 16.01.2016 00:48, Tony Lindgren wrote:
>>>> 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.
>>
>> (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.
>
> 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?
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <571E6943.30305-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-04-26 6:22 ` Felipe Balbi
[not found] ` <87a8kgrisz.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Felipe Balbi @ 2016-04-26 6:22 UTC (permalink / raw)
To: Ivaylo Dimitrov, Tony Lindgren
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz, Alan Stern,
Michal Nazarewicz
[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]
Hi,
Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>> 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.
>>>
>>> (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.
>>
>> 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?
no idea what /proc/lockdep is supposed to show
> 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.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <87a8kgrisz.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
@ 2016-04-26 15:03 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1604261102000.2038-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Alan Stern @ 2016-04-26 15:03 UTC (permalink / raw)
To: Felipe Balbi
Cc: Ivaylo Dimitrov, Tony Lindgren, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz, Michal Nazarewicz
On Tue, 26 Apr 2016, Felipe Balbi wrote:
> > 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.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <Pine.LNX.4.44L0.1604261102000.2038-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
@ 2016-04-26 16:44 ` Ivaylo Dimitrov
[not found] ` <571F9AD4.8010900-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Ivaylo Dimitrov @ 2016-04-26 16:44 UTC (permalink / raw)
To: Alan Stern, Felipe Balbi
Cc: Tony Lindgren, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz, Michal Nazarewicz
On 26.04.2016 18:03, Alan Stern wrote:
> On Tue, 26 Apr 2016, Felipe Balbi wrote:
>
>>> 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.
>
> 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
>
The process waits in poll(&fds, 1u, -1), where fds contains only the fd
of /dev/ttyGS2. Nothing suspicious I can see here.
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <571F9AD4.8010900-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-04-26 16:49 ` Tony Lindgren
[not found] ` <20160426164918.GA5995-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Tony Lindgren @ 2016-04-26 16:49 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: Alan Stern, Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz, Michal Nazarewicz
* Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [160426 09:46]:
>
>
> On 26.04.2016 18:03, Alan Stern wrote:
> >On Tue, 26 Apr 2016, Felipe Balbi wrote:
> >
> >>>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.
> >
> >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.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <20160426164918.GA5995-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
@ 2016-04-26 18:13 ` Ivaylo Dimitrov
0 siblings, 0 replies; 45+ messages in thread
From: Ivaylo Dimitrov @ 2016-04-26 18:13 UTC (permalink / raw)
To: Tony Lindgren
Cc: Alan Stern, Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz, Michal Nazarewicz
On 26.04.2016 19:49, Tony Lindgren wrote:
> * Ivaylo Dimitrov <ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [160426 09:46]:
>>
>>
>> On 26.04.2016 18:03, Alan Stern wrote:
>>> On Tue, 26 Apr 2016, Felipe Balbi wrote:
>>>
>>>>> 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.
>>>
>>> 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.
>
At least here, it is not needed to have USB cable connected, as soon as
/dev/ttyG* is open()-ed, it is not possible to reboot/powerdown the device.
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: USB gadgets with configfs hang reboot
[not found] ` <571486A1.2060006-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2016-05-06 12:32 ` Pali Rohár
0 siblings, 0 replies; 45+ messages in thread
From: Pali Rohár @ 2016-05-06 12:32 UTC (permalink / raw)
To: Ivaylo Dimitrov
Cc: Tony Lindgren, Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
Robert Baldyga, Andrzej Pietrasiewicz, Alan Stern,
Michal Nazarewicz, Sebastian Reichel, Pavel Machek
On Monday 18 April 2016 10:02:57 Ivaylo Dimitrov wrote:
>
>
> On 8.04.2016 23:13, Ivaylo Dimitrov wrote:
> >Hi,
> >
> >On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
> >>Hi,
> >>
> >>On 16.01.2016 00:48, Tony Lindgren wrote:
> >>>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
>
>
> Anyone?
PING?
--
Pali Rohár
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2016-05-06 12:32 UTC | newest]
Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-15 22:48 USB gadgets with configfs hang reboot Tony Lindgren
[not found] ` <20160115224839.GA19432-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2016-01-16 0:09 ` Tony Lindgren
2016-01-16 10:40 ` Ivaylo Dimitrov
[not found] ` <569A1E32.1020502-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-01-18 16:16 ` Tony Lindgren
2016-03-23 18:24 ` Ivaylo Dimitrov
[not found] ` <56F2DF79.6010903-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-03-24 6:50 ` Felipe Balbi
[not found] ` <87fuvgxtc3.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-03-24 7:03 ` Ivaylo Dimitrov
[not found] ` <56F3914B.4010206-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-03-24 7:11 ` Felipe Balbi
[not found] ` <87a8loxsdm.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-03-24 18:46 ` Ivaylo Dimitrov
[not found] ` <56F4361C.9040907-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-03-30 10:22 ` Felipe Balbi
[not found] ` <877fgkqn8c.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-03-30 13:29 ` Ivaylo Dimitrov
[not found] ` <56FBD4BF.6090905-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-03-30 13:38 ` Felipe Balbi
[not found] ` <87h9fohyr1.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-03-30 14:01 ` Ivaylo Dimitrov
[not found] ` <56FBDC51.9020602-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-03-30 14:33 ` Pali Rohár
2016-03-30 18:50 ` Ivaylo Dimitrov
[not found] ` <56FC1FD8.6090003-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-03-30 18:54 ` Ivaylo Dimitrov
2016-03-30 19:25 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1603301509180.2194-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-03-30 19:41 ` Tony Lindgren
2016-03-31 16:32 ` Ivaylo Dimitrov
[not found] ` <56FD512C.2070108-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-03-31 17:00 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1603311255560.1516-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-04-01 17:02 ` Michal Nazarewicz
[not found] ` <xa1tmvpdz2h4.fsf-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
2016-04-01 19:18 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1604011452580.1957-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-04-01 22:16 ` Michal Nazarewicz
[not found] ` <xa1tbn5tynyp.fsf-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
2016-04-02 14:55 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1604021031030.19366-100000-pYrvlCTfrz9XsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-04-04 12:57 ` Michal Nazarewicz
[not found] ` <xa1ty48tilai.fsf-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
2016-04-04 15:04 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1604041038510.1704-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-04-04 18:18 ` Michal Nazarewicz
[not found] ` <xa1ttwjhi6fo.fsf-deATy8a+UHjQT0dZR+AlfA@public.gmane.org>
2016-04-04 19:37 ` Alan Stern
2016-04-04 16:18 ` Ivaylo Dimitrov
[not found] ` <570293E8.2060406-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-04 18:48 ` Michal Nazarewicz
2016-04-05 15:18 ` Michal Nazarewicz
2016-04-04 4:45 ` Felipe Balbi
2016-04-04 4:41 ` Felipe Balbi
2016-04-08 20:13 ` Ivaylo Dimitrov
[not found] ` <57081105.2050206-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-18 7:02 ` Ivaylo Dimitrov
[not found] ` <571486A1.2060006-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-05-06 12:32 ` Pali Rohár
2016-04-18 7:55 ` Felipe Balbi
[not found] ` <87oa97gxkw.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-04-25 19:00 ` Ivaylo Dimitrov
[not found] ` <571E6943.30305-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-26 6:22 ` Felipe Balbi
[not found] ` <87a8kgrisz.fsf-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2016-04-26 15:03 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1604261102000.2038-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2016-04-26 16:44 ` Ivaylo Dimitrov
[not found] ` <571F9AD4.8010900-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-26 16:49 ` Tony Lindgren
[not found] ` <20160426164918.GA5995-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2016-04-26 18:13 ` Ivaylo Dimitrov
2016-01-22 10:35 ` Andrzej Pietrasiewicz
[not found] ` <56A205E4.6050305-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-01-22 18:28 ` Tony Lindgren
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.