Bug 868449 - Gobi 2000 Modem connection problem with recent kernels
Gobi 2000 Modem connection problem with recent kernels
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-19 17:59 EDT by davidgf
Modified: 2013-07-31 22:19 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-31 22:18:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Logs for 3.3 and 3.6 kernels. (8.74 KB, application/x-gzip)
2012-10-19 17:59 EDT, davidgf
no flags Details

  None (edit)
Description davidgf 2012-10-19 17:59:56 EDT
Created attachment 630265 [details]
Logs for 3.3 and 3.6 kernels.

Description of problem:

The modem won't connect using NetworkManager when using kernel 3.6.2-4.fc17.i686 (and lower 3.5.x). If use kernel-3.3.4-1.fc16.i686.rpm (with the same modem-manager and software) the modem connects promptly. I debuged the modem-manager output and it seems to be a mismatch with the outputs.

I attach the two logs, the one with 3.6 and the one with 3.3. As you can see there are several commands which fail with version 3.6 and work with 3.3. I see that the reboot command (the first one to fail) might the key.
Comment 1 davidgf 2012-10-19 19:02:01 EDT
I found the commit which broke the kernel for my modem. Was this one:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blobdiff;f=drivers/net/usb/qmi_wwan.c;h=3767a122586043512cd6ded88b562fd9b97df88f;hp=3b206786b5e7d8196d2fd1e63060f17cd7101c6e;hb=b9f90eb2740203ff2592efe640409ad48335d1c2;hpb=4e42200cafe0c7a90fc26b82b2088c4f2bcb007a

I tried some kernels and found that 3.5 is not working but 3.4.2 is. Having a look at qmi_wwan.ko I found out that the pre-commit version connects ok while the post-commit version does not.

Hope someone can tell why or rollback the changes.

Thank you
Comment 2 Bjørn Mork 2012-10-27 15:39:14 EDT
This is strange.  modem-manager is ignoring the yet unsupported QMI WWAN port, like it should, and end up using the exact same serial ports.  So far, so good.

But then you get to

"(ttyUSB1): --> 'AT+CFUN=1<CR>'"

and the two versions diverge.  3.3 get OK as expected, while 3.6 get ERROR. I do note that modem-manager seems to ignore this and just continues.  That seems wrong in any case...

It is not completely clear to me which power state the modem is in, but if the radio is disabled then that would explain why the modem cannot register like the end of the log shows.  I guess that is the case, and the real issue is to make AT+CFUN work.

But what I do not understand at all is the connection between qmi_wwan loading and the AT+CFUN error. And certainly not how things could be *better* with the referenced commit reverted. AFAICS that commit prevents qmi_wwan from stealing serial functions from the qcserial driver, something which would make ttyUSB0 and ttyUSB1 not show up at all.

Does "rmmod qmi_wwan" help?  Can you use minicom or similar to check the output of "AT+CFUN?" And verify that "AT+CFUN=1" actually behaves differently in these two kernel versions?  Does it really return ERROR in 3.6, and does that really depend on qmi_wwan being loaded?
Comment 3 Bjørn Mork 2013-01-16 11:29:56 EST
Just FYI: More information is required if this bug is going to be resolved.

The different replies to AT+CFUN=1 from the firmware may explain the observed modemmanager failure if the radio is off, but how this possibly can be related to kernel or driver versions is all but clear.  So we do need to look at as much information as possible.

I'd like to see at least a dmesg output from both kernels showing exactly which drivers are bound to which USB interfaces.  And if anyone experiencing the bug could take the time to run a terminal application (minicom or whatever) on /dev/ttyUSB1 (or whatever port ModemManager uses as primary), and try a few commands like

AT+CFUN?
AT+CFUN=?
AT+CFUN=1

and maybe

AT+CGREG?
AT+CPIN?

then that would be useful.  You'll have to stop ModemManager while doing this.  The output of rfkill list, as well as full details of any laptop platform driver would also be interesting
Comment 4 davidgf 2013-01-16 14:10:24 EST
Sorry for not saying anything.
I downloaded and compiled a kernel but I had some problems in the process and I just forgot (the Atom is damn slow).

Just to make it clear, do you want a dmesg, rfkill and modem manager of the two kernels (working and non-working), right?
And playing with the terminal I can try to reproduce the same behaviour which modem-manager is triggering.

In any case it's clear that the modem is sending a different response. I played with gobi_loader to load some firmwares found in the windows msi installer and I remember that I managed to make it work once, but I could not reproduce the sequence, sorry.

I'll find some time this weekend and I'll upload the info you need. In any case, if you could help me to compile the 3.6 kernel with the old driver I could try if that works or not.

Thank you very much for your patience.
Comment 5 Bjørn Mork 2013-02-07 04:29:14 EST
(In reply to comment #4)
> Sorry for not saying anything.
> I downloaded and compiled a kernel but I had some problems in the process
> and I just forgot (the Atom is damn slow).
> 
> Just to make it clear, do you want a dmesg, rfkill and modem manager of the
> two kernels (working and non-working), right?
> And playing with the terminal I can try to reproduce the same behaviour
> which modem-manager is triggering.

Yes, but only if it isn't too inconvenient.  You shouldn't need to compile anything.
 
> In any case it's clear that the modem is sending a different response. I
> played with gobi_loader to load some firmwares found in the windows msi
> installer and I remember that I managed to make it work once, but I could
> not reproduce the sequence, sorry.

Right.  Is it possible that the two logs you posted were using different firmwares? That could explain the otherwise unexplainable difference.

> I'll find some time this weekend and I'll upload the info you need. In any
> case, if you could help me to compile the 3.6 kernel with the old driver I
> could try if that works or not.

I must admit that I am not too familiar with Redhat/Fedora packaging, but I assume they provide everything you need to build out-of-tree drivers for their distro kernels.  You can use the same infrastructure to build in-kernel drivers from other kernel versions as well.  No need to build a whole kernel, unless of course some API the driver is using has changed significantly.

For example (you will have to adapt this according to where you find the kernel headers for your kernel):

make -C /lib/modules/`uname -r`/build SUBDIRS=/old/kernel/source/drivers/net/usb CONFIG_USB_NET_QMI_WWAN=m qmi_wwan.ko

In my case, /lib/modules/`uname -r`/build is a symlink to where the headers and build scripts for my running distro kernel is installed.

> Thank you very much for your patience.

Well, I am in no hurry if you ain't :-)
Comment 6 davidgf 2013-02-07 17:37:01 EST
Hi again.

I checked but I see that the moudle qmi_wwan is not in use. The modem is only using qcserial and usb_wwan so the bug must be there right?
Modemmanager and other stuff are binaries, the only thing that changes is the kernel which I boot.

I'll try to compile the 3.4 modules for the 3.7 kernel and (if it works) use them to see if the problem disappears.
Comment 7 davidgf 2013-02-07 17:47:29 EST
I tried, but it seems the interface has changed quite a bit and it does not compile.
What else should I try?
Comment 8 Bjørn Mork 2013-02-08 02:44:23 EST
(In reply to comment #6)
> Hi again.
> 
> I checked but I see that the moudle qmi_wwan is not in use. The modem is
> only using qcserial and usb_wwan so the bug must be there right?

Well, I guess we can rule out the commit you found in qmi_wwan at least. That's good, because there really wasn't any way that could have affected the modems behaviour like this.

Having said that, I don't see how any other driver can cause thise either.  So I believe the best (and easiest) way to procede is to use e.g. minicom and verify that the firmware actually behaves differently.

Thinking about it, qcserial is involved when loading the firmware.  I would expect any errors to cause a checksum mismatch and hence complete failure to load anything at all.  But this could in theory open the possibility for a driver affecting modem firmware.

In any case:  Please verify that the behaviour *is* different and that this isn't just some subtle timing issue we are hitting.


> Modemmanager and other stuff are binaries, the only thing that changes is
> the kernel which I boot.
> 
> I'll try to compile the 3.4 modules for the 3.7 kernel and (if it works) use
> them to see if the problem disappears.

OK, I should have known that I guess... But if the qmi_wwan driver isn't loaded, then you can just drop this.
Comment 9 davidgf 2013-02-16 13:41:24 EST
Something weird is happening here.
After an update to kernel 3.7.3 now qmi_wwan IS loaded and being used!
And I discovered by chance that the modem works after putting the laptop in suspend mode.

So in order to reproduce it I have to:

 - Boot the computer
 - Put it into suspend to RAM mode and wake it
 - Click NetworkManager connect and it will connect!

Any idea? It sounds something related to radio, like you said before.
I'll try to play a little bit in order to discover what the recovery from suspend does and why it works after it.
Comment 10 Josh Boyer 2013-03-12 15:11:48 EDT
Are you still seeing this with 3.7.9 or 3.8.2 in updates-testing?
Comment 11 davidgf 2013-03-17 07:23:08 EDT
I booted F18 on a usb and I still see this.
I couldn't connect out of the box and even using the suspend trick.
Comment 12 Fedora End Of Life 2013-07-03 19:32:37 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 13 Fedora End Of Life 2013-07-31 22:19:07 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.