On 10/25/2012 03:40 AM, Bjørn Mork wrote:
"Shawn J. Goff" <shawn.goff@xxxxxxxxxxxxx> writes:
On 10/24/2012 05:19 PM, Bjørn Mork wrote:
"Shawn J. Goff" <shawn.goff@xxxxxxxxxxxxx> wrote:
I've only made it happen on my kernel - I
tried
on 3.6.2, but it seems to not happen there.
Good. But I have a feeling that you switched more than just the
kernel. Do you see the issue if you run your backport on the same
hardware you tested 3.6.2 on?
I just tested my 2.6.39 kernel on the same hardware that had 3.6.2;
the problem is absent there.
As I suspected. Then I believe this issue is more likely related to
your hardware platform and/or its other lower layer drivers, and not to
the backported qmi_wwan driver directly.
Maybe an obscure firmware issue related to timing or other differences?
That is going to be difficult to track down, if it really is the cause.
> I've also tried using a
similar modem that uses a different driver (sierra-net) and that
doesn't
have the same problem.
Well, that is an entirely different firmware application and driver,
even if the hardware is similar or even identical.
Yes - I wanted to eliminate anything lower (such as usb-net? not sure
if qmi-wwan uses that) from being a suspect contributor to the
problem.
Yes, that is useful. You are perfectly right that most of the host side
drivers are common. Both sierra_net and qmi_wwan are usbnet minidrivers,
and almost all network device functionality is served by the shared
usbnet framework. So this test pretty much eliminates the host USB
stack.
Which IMHO points to the firmware implementation as the major
difference.
Just to be sure: are you talking about the modem's firmware?
When it is in failure, if I try to ping an address, the system sends
out
several an ARP requests but gets no response. To get the device to
respond again, I have to administratively set the wwan interface down,
then up, use libqmi to get the connection going again, then dhcp to get
an address.
Which sounds like the connection died. Does QMI work at this point, or is that dead too?
Looks like qmi works. I can do --nas-get-signal-strength and it gives
me good numbers. --wds-get-packet-service-status returns "Connection
status: '2'"
Ah, interesting. Then we only need to find out where the bulk URBs end
up.
After the failure happens, I can see from USB traces (and this is with
an external USB sniffer) ARP requests going out and nothing coming in -
so it seems like it's not a case of dropping URBs. At the point when
things stall out, I don't see anything special happening - there's a
large file that is downloading (lots of IN packets) that suddenly stops
while the tty port keeps chatting normally. I can also provide a trace
from the external sniffer if it's interesting, but here is a usbmon
trace of the failure: http://sprunge.us/ORQE . The last incoming message
from the wwan endpoint (2:8) is at 1555583640.
I would have tried to enable what I could of USB and usbnet debugging to
see if there are any hints there. A usbmon trace may also show the
problem. I don't know. But in any case, I believe this is a USB
problem and probably not too interesting for netdev...
Bjørn
I've turned on DEBUG_KERNEL and uncommented #define DEBUG and #define
VERBOSE in usbnet.c and turned up kernel logging to 7. There is nothing
helpful so far: there are no messages when it fails, and the most recent
message before the failure is from when I brought up the interface.
--
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
