On Tue, 14 Jul 2009, Yang Fei-AFY095 wrote: > Hello All, > > We had a discussion couple of weeks ago about a kernel panic caused by > ehci->watchdog timer, details were posted at > http://thread.gmane.org/gmane.linux.usb.general/19472/focus=19484 > > Now we observed a similar issue caused by the rh_timer. As we need to How does this happen? ehci-hcd doesn't use the rh_timer. It sets hcd->poll_rh to 0. > disbale clocks and power-down the USBHOST to conserve power when > suspending the bus, accessing the peripheral registers after bus > suspended would cause CPU data abort, thus trigger a kernel panic. We > saw occasionally this rh_timer gets enabled before ehci_bus_suspend is > called, and by the time the timer fires (256ms later), the bus has been Is the timer getting enabled by usb_bus_start_enum? That has a delay of 10 ms, not 256 ms. (Not that the actual delay time matters...) > suspended already and kernel panic happens when rh_timer_func -> > usb_hcd_poll_rh_status -> ehci_hub_status_data, which needs to access > hub port status register. > > Here are the questions I wanted to ask, > 1. Should the host driver prevent rh_timer from being enabled when > trying to suspend the bus? No. > 2. If scheduling rh_timer and suspending the bus are not even related to > each other, should we simply del_timer_sync(&hcd->rh_timer) in > ehci_bus_suspend? No. I don't know why you're experiencing any problems. The first statement in ehci_hub_status_data() is this: if (!HC_IS_RUNNING(hcd->state)) return 0; That should prevent the routine from accessing any controller registers if it is called after the root hub has been suspended. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
