On Mon, 2011-01-10 at 15:38 -0600, Dan Williams wrote: > On Mon, 2011-01-10 at 16:08 -0500, Alan Stern wrote: > > 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? > > Yes, I have; that call in serial_install() in > drivers/usb/serial/usb-serial.c is definitely returning EAGAIN, which is > how I composed the above call stack. [14838.543659] cdc_acm 2-6:1.0: ttyACM3: USB ACM device [14838.545061] /home/dcbw/Development/linux-2.6/drivers/usb/serial/usb-serial.c: static descriptor matches [14838.545072] /home/dcbw/Development/linux-2.6/drivers/usb/serial/usb-serial.c: found bulk in on endpoint 0 [14838.545079] /home/dcbw/Development/linux-2.6/drivers/usb/serial/usb-serial.c: found bulk out on endpoint 1 [14838.545087] qcaux 2-6:1.2: qcaux converter detected [14838.545093] /home/dcbw/Development/linux-2.6/drivers/usb/serial/usb-serial.c: usb_serial_probe - setting up 1 port structures for this device [14838.545109] /home/dcbw/Development/linux-2.6/drivers/usb/serial/usb-serial.c: get_free_serial 1 [14838.545116] /home/dcbw/Development/linux-2.6/drivers/usb/serial/usb-serial.c: get_free_serial - minor base = 0 [14838.545125] /home/dcbw/Development/linux-2.6/drivers/usb/serial/usb-serial.c: usb_serial_probe - registering ttyUSB0 [14838.545315] usb 2-6: qcaux converter now attached to ttyUSB0 [14859.362338] /home/dcbw/Development/linux-2.6/drivers/usb/serial/usb-serial.c: serial_install [14859.362353] serial_install: usb_autopm_get_interface() ret -11 Dan > > > 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). > > Ah, good to know. > > [dcbw@dcbw ~]$ cd -P /sys/class/tty/ttyUSB0/device/../../power > [dcbw@dcbw power]$ ls > active_duration connected_duration runtime_active_kids runtime_suspended_time wakeup_active_count wakeup_max_time_ms > async control runtime_active_time runtime_usage wakeup_count wakeup_total_time_ms > autosuspend level runtime_enabled wakeup wakeup_hit_count > autosuspend_delay_ms persist runtime_status wakeup_active wakeup_last_time_ms > [dcbw@dcbw power]$ cat runtime_enabled > forbidden > [dcbw@dcbw power]$ cat runtime_status > active > [dcbw@dcbw power]$ cd -P /sys/class/tty/ttyUSB0/device/../power > [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 > > so yeah, that invalidates my original hypothesis about disable_depth; > what does the new info mean then? For the device itself, 'forbidden' > means disable_depth == 0, but runtime_status == RPM_ACTIVE. For the > interface of course the results mean disabled_depth > 0. But since I > assume the tty is pulling from the *interface*, not the device, we still > get EAGAIN... or? > > > > [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? > > qcaux, which is a thin shim driver over usbserial, much like moto_modem. > It's basically a driver to expose the Qualcomm DIAG protocol ports on > devices that present a CDC-ACM interface (for standard AT commands) and > then a separate Qualcomm DIAG interface. Thus more than one driver gets > bound to the device; CDC-ACM for the actual CDC-ACM interface, and qcaux > for the DIAG interface, and possibly another driver for other protocols > the device may support on the other interfaces. > > We do have devices that expose DIAG ports already driven by > 'option' (Huawei EC168C for example), but adding the IDs for the DIAG > interfaces for devices not primarily driven by option was vetoed long > ago, thus I proposed qcaux. > > Dan > -- 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
