Hi,
We're seeing a problem upon resume on OLPC and some help would be
appreciated.
When the OLPC suspends, it tells the wireless interface to enter a mode
where it knows the CPU is asleep, so in case of communication directed
to the machine's address it can wakeup the CPU via a special GPIO pin on
the embedded controller.
The CONFIG_USB_PERSIST facility is being used for this purpose to avoid
a unload/probe sequence upon resume.
So on suspend we:
- stop traffic on the interfaces
netif_device_detach(cardp->eth_dev);
netif_device_detach(priv->mesh_dev);
- send commands down to firmware for it to enter "suspend" mode (then it
knows it should wakeup the CPU on traffic)
- kills the URB's:
/* Unlink tx & rx urb */
usb_kill_urb(cardp->tx_urb);
usb_kill_urb(cardp->rx_urb);
And on resume we do:
if_usb_submit_rx_urb(cardp->priv);
netif_device_attach(cardp->eth_dev);
netif_device_attach(priv->mesh_dev);
This all works very well except when you have high traffic going on the
interface. The testcase we are using for this is "ping -f".
After resume, the configuration process works normally on endpoint 0, but
as soon as communication is restarted on ep2 we get:
[ 1.045207] devpath 1 ep2out 3strikes
[ 1.048888] usb8xxx: URB in failure status: -71
And this is due to:
3 Transaction Error (XactErr). Set to a one by the Host Controller
during status update in the case where the host did not receive a valid
response from the device (Timeout, CRC, Bad PID, etc.). Refer to Section
4.15.1.1 for summary of the conditions that affect this bit. If the
host controller sets this bit to a one, then it remains a one for the
duration of the transfer.
Please refer to the EHCI spec section 4.15.1.1 for more details.
The Linux driver sets the EHCI CERR register to 3. Accordingly to the
documentation:
Error Counter (CERR). This field is a 2-bit down counter that keeps
track of the number of consecutive Errors detected while executing this
qTD. If this field is programmed with a non zero value during setup,
the Host Controller decrements the count and writes it back to the qTD
if the transaction fails. If the counter counts from one to zero, the
Host Controller marks the qTD inactive, sets the Halted bit to a one and
error status bit for the error that caused CERR to decrement to zero.
An interrupt will be generated if the USB Error Interrupt Enable bit in
the USBINTR register is set to a one. If HCD programs this field to zero
during setup, the Host Controller will not count errors for this qTD and
there will be no limit on the retries of this qTD. Note that write-backs
of intermediate execution state are to the queue head overlay area, not
the qTD.
Setting CERR to 0 on driver initialization does not help. We never see
a "devpath 3strikes" error because presumably the host controller is
retrying.
What was attempted on the CPU side to recover this:
- Killing the URB's and submitting them again.
- A delay to restart communication on ep2 after 1 second didnt help at all.
- usb_clear_halt() at the host side, this tells the device to clear endpoint
halt/stall
conditions.
- usb_reset_configuration:
* usb_reset_configuration - lightweight device reset
* @dev: the device whose configuration is being reset
*
* This issues a standard SET_CONFIGURATION request to the device using
* the current configuration. The effect is to reset most USB-related
* state in the device, including interface altsettings (reset to zero),
* endpoint halts (cleared), and data toggle (only for bulk and interrupt
* endpoints). Other usbcore state is unchanged, including bindings of
* usb device drivers to interfaces.
Resetting the EHCI host controller does not seem to help, a EC GPIO
(rmmod usb8xxx; modprobe usb8xxx) sequence recovers it.
Any help is appreciated, we're running out of ideas.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
