From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: Reboot/shutdown failure due to "USB: EHCI: work around silicon bug in Intel's EHCI" Date: Tue, 19 Mar 2013 12:49:28 -0600 Message-ID: <5148B338.6070001@wwwdotorg.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Alan Stern Cc: "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , USB list , Greg Kroah-Hartman List-Id: linux-tegra@vger.kernel.org On 03/19/2013 12:34 PM, Alan Stern wrote: > On Mon, 18 Mar 2013, Stephen Warren wrote: > >> Alan, >> >> In v3.9-rc3, I find that "reboot" and "shutdown" hang on Tegra. I >> bisected it to commit 6402c79 "USB: EHCI: work around silicon bug in >> Intel's EHCI controllers", and confirmed that running v3.9-rc3 with just >> that one patch reverted does solve the problem. >> >> Do you have any idea what the problem might be, or is there anything I >> can do to help debug this? Thanks. > > Is there any way to find out where the hangup occurs? For example, can > you get anything from Alt-SysRq-W? > > Failing that, can you put some printk statements in > drivers/usb/host/ehci-hcd.c, in the ehci_halt(), > ehci_silence_controller(), and ehci_shutdown() routines? (Although I > suspect this may not help because the hangup occurs somewhere else...) Yes, sysrq seems to work over the serial console:-) > * Will now restart > > *** break sent *** > [ 180.765213] SysRq : Show Blocked State > [ 180.768963] task PC stack pid father > [ 180.774182] khubd D c0517678 0 21 2 0x00000000 > [ 180.780559] [] (__schedule+0x348/0x6dc) from [] (usb_kill_urb+0x88/0xd4) > [ 180.788984] [] (usb_kill_urb+0x88/0xd4) from [] (usb_start_wait_urb+0xa4/0x13c) > [ 180.798012] [] (usb_start_wait_urb+0xa4/0x13c) from [] (usb_control_msg+0x98/0xcc) > [ 180.807301] [] (usb_control_msg+0x98/0xcc) from [] (hub_port_init+0x5e0/0x9d0) > [ 180.816242] [] (hub_port_init+0x5e0/0x9d0) from [] (hub_port_connect_change+0x1f4/0x970) > [ 180.826050] [] (hub_port_connect_change+0x1f4/0x970) from [] (hub_events+0x340/0x8c4) > [ 180.835598] [] (hub_events+0x340/0x8c4) from [] (hub_thread+0x28/0x1b8) > [ 180.843941] [] (hub_thread+0x28/0x1b8) from [] (kthread+0xa4/0xb0) > [ 180.851851] [] (kthread+0xa4/0xb0) from [] (ret_from_fork+0x14/0x3c) > [ 180.859929] udevd D c0517678 0 167 1 0x00000001 > [ 180.866285] [] (__schedule+0x348/0x6dc) from [] (schedule_preempt_disabled+0x24/0x34) > [ 180.875834] [] (schedule_preempt_disabled+0x24/0x34) from [] (__mutex_lock_slowpath+0x15c/0x354) > [ 180.886336] [] (__mutex_lock_slowpath+0x15c/0x354) from [] (mutex_lock+0xc/0x24) > [ 180.895455] [] (mutex_lock+0xc/0x24) from [] (show_manufacturer+0x18/0x40) > [ 180.904059] [] (show_manufacturer+0x18/0x40) from [] (dev_attr_show+0x1c/0x48) > [ 180.913007] [] (dev_attr_show+0x1c/0x48) from [] (sysfs_read_file+0x90/0x16c) > [ 180.921870] [] (sysfs_read_file+0x90/0x16c) from [] (vfs_read+0x98/0x13c) > [ 180.930379] [] (vfs_read+0x98/0x13c) from [] (SyS_read+0x3c/0x70) > [ 180.938196] [] (SyS_read+0x3c/0x70) from [] (ret_fast_syscall+0x0/0x30) > [ 180.946527] reboot D c0517678 0 877 876 0x00000000 > [ 180.952883] [] (__schedule+0x348/0x6dc) from [] (schedule_preempt_disabled+0x24/0x34) > [ 180.962432] [] (schedule_preempt_disabled+0x24/0x34) from [] (__mutex_lock_slowpath+0x15c/0x354) > [ 180.972934] [] (__mutex_lock_slowpath+0x15c/0x354) from [] (mutex_lock+0xc/0x24) > [ 180.982050] [] (mutex_lock+0xc/0x24) from [] (device_shutdown+0xc8/0x188) > [ 180.990566] [] (device_shutdown+0xc8/0x188) from [] (kernel_restart_prepare+0x34/0x3c) > [ 181.000202] [] (kernel_restart_prepare+0x34/0x3c) from [] (kernel_restart+0xc/0x4c) > [ 181.009578] [] (kernel_restart+0xc/0x4c) from [] (SyS_reboot+0x1ac/0x1d8) > [ 181.018086] [] (SyS_reboot+0x1ac/0x1d8) from [] (ret_fast_syscall+0x0/0x30) I assume you only want the back-traces, not the reset of the sysrq spew? BTW, I have also occasionally noticed some either hung task or RCU spew related to usb_kill_urb at other times (i.e. when not rebooting), IIRC (which I may not; I may be remembering what happens if I just leave the reboot hung for a few minutes, as shown below): > [ 240.670335] INFO: task khubd:21 blocked for more than 120 seconds. > [ 240.676516] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 240.684336] khubd D c0517678 0 21 2 0x00000000 > [ 240.690706] [] (__schedule+0x348/0x6dc) from [] (usb_kill_urb+0x88/0xd4) > [ 240.699140] [] (usb_kill_urb+0x88/0xd4) from [] (usb_start_wait_urb+0xa4/0x13c) > [ 240.708181] [] (usb_start_wait_urb+0xa4/0x13c) from [] (usb_control_msg+0x98/0xcc) > [ 240.717481] [] (usb_control_msg+0x98/0xcc) from [] (hub_port_init+0x5e0/0x9d0) > [ 240.726433] [] (hub_port_init+0x5e0/0x9d0) from [] (hub_port_connect_change+0x1f4/0x970) > [ 240.736251] [] (hub_port_connect_change+0x1f4/0x970) from [] (hub_events+0x340/0x8c4) > [ 240.745809] [] (hub_events+0x340/0x8c4) from [] (hub_thread+0x28/0x1b8) > [ 240.754160] [] (hub_thread+0x28/0x1b8) from [] (kthread+0xa4/0xb0) > [ 240.762067] [] (kthread+0xa4/0xb0) from [] (ret_from_fork+0x14/0x3c) > [ 240.770153] INFO: task udevd:167 blocked for more than 120 seconds. > [ 240.776410] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 240.784228] udevd D c0517678 0 167 1 0x00000001 > [ 240.790586] [] (__schedule+0x348/0x6dc) from [] (schedule_preempt_disabled+0x24/0x34) > [ 240.800145] [] (schedule_preempt_disabled+0x24/0x34) from [] (__mutex_lock_slowpath+0x15c/0x354) > [ 240.810659] [] (__mutex_lock_slowpath+0x15c/0x354) from [] (mutex_lock+0xc/0x24) > [ 240.819787] [] (mutex_lock+0xc/0x24) from [] (show_manufacturer+0x18/0x40) > [ 240.828397] [] (show_manufacturer+0x18/0x40) from [] (dev_attr_show+0x1c/0x48) > [ 240.837353] [] (dev_attr_show+0x1c/0x48) from [] (sysfs_read_file+0x90/0x16c) > [ 240.846227] [] (sysfs_read_file+0x90/0x16c) from [] (vfs_read+0x98/0x13c) > [ 240.854747] [] (vfs_read+0x98/0x13c) from [] (SyS_read+0x3c/0x70) > [ 240.862565] [] (SyS_read+0x3c/0x70) from [] (ret_fast_syscall+0x0/0x30) -- 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