Sierra MC7354

[Robert Shade]

Did you ever investigate this further?  I'm seeing this same issue.

It seems to be related to autosuspend, because using
usbcore.autosuspend="-1" eliminates the issue.  I've also noticed that if
you close and then reopen the qmi socket, it will stop erroring.

Thanks!

On Tue, Mar 11, 2014 at 9:24 AM, Bjørn Mork <bjorn at mork.no> wrote:

> szlin <lin.sunze at gmail.com> writes:
>
> >>   mount -t debugfs none /sys/kernel/debug
> >>   echo 'file cdc-wdm.c +fp' > /sys/kernel/debug/dynamic_debug/control
> >>
> >> You should then see at least one "zero length - clearing WDM_READ"
> >> debug message after the error.  But since your system fails at this
> >> point, you might want to add more debug messages around the in callback
> >> and read functions first.
> >>
> >
> > I did some experiments according to your suggestion.
> >
> > *First time*:
> > I type "qmicli -d /dev/cdc-wdm0 --nas-get-system-info" I got the
> following
> > message.
> >
> > drivers/net/usb/usbnet.c:596 [usbnet]unlink_urbs - "unlink urb err,
> %d\012"
> > drivers/net/usb/usbnet.c:639 [usbnet]usbnet_terminate_urbs - "waited for
> %d
> > urb completions\012"
>
> Huh?  This looks more like the output of
>
>   cat /sys/kernel/debug/dynamic_debug/control
>
> except that the flag setting is replaced by '-'.  You should write the text
>
>    file cdc-wdm.c +fp
>
> to this file.  You will then see something like this when you read it
> back:
>
> # grep wdm /sys/kernel/debug/dynamic_debug/control
> drivers/usb/class/cdc-wdm.c:1047 [cdc_wdm]wdm_resume =pf "wdm%d_resume\012"
> drivers/usb/class/cdc-wdm.c:997 [cdc_wdm]wdm_suspend =pf
> "wdm%d_suspend\012"
> drivers/usb/class/cdc-wdm.c:987 [cdc_wdm]wdm_disconnect =pf "%s: %d open
> files - postponing cleanup\012"
> drivers/usb/class/cdc-wdm.c:673 [cdc_wdm]wdm_release =pf "wdm_release:
> cleanup"
> drivers/usb/class/cdc-wdm.c:681 [cdc_wdm]wdm_release =pf "cdc_wdm %s:
> device gone - cleaning up\012"
> drivers/usb/class/cdc-wdm.c:425 [cdc_wdm]wdm_write =pf "Tx URB has been
> submitted index=%d"
> drivers/usb/class/cdc-wdm.c:537 [cdc_wdm]wdm_read =pf "%s: zero length -
> clearing WDM_READ\012"
> drivers/usb/class/cdc-wdm.c:895 [cdc_wdm]wdm_probe =pf "Finding maximum
> buffer length: %d"
> drivers/usb/class/cdc-wdm.c:170 [cdc_wdm]wdm_in_callback =pf "nonzero urb
> status received: -ENOENT"
> drivers/usb/class/cdc-wdm.c:174 [cdc_wdm]wdm_in_callback =pf "nonzero urb
> status received: -ECONNRESET"
> drivers/usb/class/cdc-wdm.c:178 [cdc_wdm]wdm_in_callback =pf "nonzero urb
> status received: -ESHUTDOWN"
> drivers/usb/class/cdc-wdm.c:248 [cdc_wdm]wdm_int_callback =pf
> "NOTIFY_RESPONSE_AVAILABLE received: index %d len %d"
> drivers/usb/class/cdc-wdm.c:255 [cdc_wdm]wdm_int_callback =pf
> "NOTIFY_NETWORK_CONNECTION %s network"
> drivers/usb/class/cdc-wdm.c:259 [cdc_wdm]wdm_int_callback =pf
> "SPEED_CHANGE received (len %u)"
> drivers/usb/class/cdc-wdm.c:276 [cdc_wdm]wdm_int_callback =pf "%s:
> usb_submit_urb %d"
>
>
> and these messages will be logged when they appear in the code, prefixed
> with the name of the function.
>
> > I just got another sierra module - MC7304, which product id is the same
> as
> > the MC7354. Maybe I could do some experiments to clarify this issue.
>
> Yes, that's interesting to know.  These modules should be very similar
> so any difference would be unexpected and worth investigating further.
>
>
>
> Bjørn
> _______________________________________________
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libqmi-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20150512/66c2b1d2/attachment.html>