On Mon, 10 Jan 2011, Dan Williams wrote: > Hi, > > Upon booting 2.6.37 for the first time any open(2) request for the TTY > port of my Pantech UML290 (new Verizon LTE dongle) returned EAGAIN. > (lsusb for the device at the bottom) This did not happen with 2.6.36. > > The USB interface in question is #2, the QCDM DIAG port of the device. > The other ports are standard CDC-ACM for minimal AT commands, and > vendor-specific ports for RmNet (Qualcomm pseudo-ethernet protocol), > another proprietary control protocol, and a GPS port. > > The callpath below is what I believe is happening to return EAGAIN to > open() of the DIAG tty: > > tty_open > tty_init_dev > tty_driver_install_tty > driver->ops->install > serial_install > usb_autopm_get_interface (returns -EAGAIN) Did you verified that it really does return -EAGAIN? > pm_runtime_get_sync > __pm_runtime_resume > rpm_resume > > rpm_resume() executes this code: > > else if (dev->power.disable_depth > 0) > retval = -EAGAIN; > > which I think is the culprit, since not much else below > usb_autopm_get_interface() returns EAGAIN. > Here's /sys/class/tty/ttyUSB0/power: That's the wrong directory. You need to look in /sys/class/tty/ttyUSB0/device/../../power (the device's directory) and /sys/class/tty/ttyUSB0/device/../power (the interface's directory). > [dcbw@dcbw power]$ ls > async runtime_active_kids runtime_status wakeup wakeup_count wakeup_max_time_ms > autosuspend_delay_ms runtime_active_time runtime_suspended_time wakeup_active wakeup_hit_count wakeup_total_time_ms > control runtime_enabled runtime_usage wakeup_active_count wakeup_last_time_ms > [dcbw@dcbw power]$ cat runtime_enabled > disabled > [dcbw@dcbw power]$ cat runtime_status > unsupported > > which seems to corroborate that disable_depth > 0 for this device. No, it's meaningless because that's a class device directory, not the directory for the real device. > The > hunk in question is from: > > 1bfee5bc Alan Stern 2010-09-25 Linus has asked people to include the commit name in parenthesis along with the hash value; otherwise there's no easy way to tell what the commit is. However I looked it up, and it's not obvious how it relates to your problem. Maybe things will become clearer when we see the power info for the real device. > Does anyone have ideas how to debug further? Clearly for this device > pm_runtime_enable() isn't getting called, and thus rpm_resume() is > bailing out early. Perhaps the device doesn't actually support > autosuspend or something, but that shouldn't cause open(2) to fail... > Do other USB serial devices that don't support autosuspend work with > 2.6.37? It's not a question of what the device supports; it's a question of what the software is doing. What serial driver is getting bound to your interface? Is it cdc-acm? 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
