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.
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
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?
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
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.
(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 :-)
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.
I tried, but it seems the interface has changed quite a bit and it does not compile. What else should I try?
(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.
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.
Are you still seeing this with 3.7.9 or 3.8.2 in updates-testing?
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.
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.
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.