Re: Fibocom L850-GL / Intel XMM7360 support
On Wed, 2020-01-08 at 10:00 +0100, Bjørn Mork wrote: > James Wah writes: > > > Hi gang, > > > > I've been working on a PCI driver for the Fibocom L850-GL, and > > while > > it's very rough at this point, it sure does transfer data. > > > > If anyone is interested in developing support in MM, or in shaping > > the kernel driver into something people might actually want to use, > > now > > would be a good time to get involved. MM integration is well beyond > > my > > available time & expertise - I've just been doing this reverse > > engineering for fun - but I'd be very happy to contribute what I > > can. > > > > The modem does not speak MBIM over PCI, though it does expose some > > AT > > ports. Most tasks eg. PIN management can be done via AT commands. > > > > In order to initialise the modem, though, or to bring up a raw IP > > interface, it's necessary to speak a custom RPC protocol. This is > > unpleasant, but not unpossible; the driver I have uses a Python > > userspace component to do so. The protocol is ugly but not > > complicated, > > so a C port wouldn't be too involved. > > > > The driver, and associated RPC tooling, are currently available > > here: > > > > https://github.com/xmm7360/xmm7360-pci > > > > A little documentation on the RPC protocol is also available: > > > > https://github.com/xmm7360/xmm7360-pci > > Great stuff! Almost makes me want to buy a device to play with ;-) > > Being responsible for a number of historical userspace API mistakes I > should probably just shut up now But just in case you haven't > been > following this discussion: > > https://www.spinics.net/lists/linux-wireless/msg186483.html > > I have no idea where this has led. But you should probably discuss > the > userspace API with Johannes and Marcel (I assume Dan and Aleksander > is > already on the task) before introducing the new driver. Johannes says the Intel folks will be submitting drivers to staging "any time now" for that family of devices (7360, 7460, 7560). What the actual architecture of those drivers is and how you communicate with them, I don't recall. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Fibocom L850-GL / Intel XMM7360 support
On Wed, Jan 08, 2020 at 10:29:11AM +0100, Aleksander Morgado wrote: > Is that the correct link? Don't see anything regarding the RPC protocol > there Whoops, my apologies for the sloppy paste. Correct link: https://github.com/xmm7360/reversing This is more in the vein of "things that might not be obvious from reading the code", as opposed to a clean freestanding documentation of the protocol, for now. Cheerio, James ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Huawei ME909s-120 modem goes offline and disappears
Hey, > > > Would you be able to test these two patches in the following MR? > > I follow your gitlab-ci.yml in order to build for RPi. > > While building libmbim I get the following error. This alignment issue (cast > increases required alignment of target type) seems to occur often in > projects built on ARM while building them on AMD64 is no problem. Any > suggestions? > > Will take a look at that. > Other than that I need to figure out how to install MM on the target > device where MM is already installed. Can I install MM and its libraries in > a different location and run from there? How would I have to parametrize > .configure etc.? > > You could be brave and just install on top of the already available MM :) Otherwise, yes, you can install libs and daemons in a different location, and as long as e.g. the DBus service files are the same, there should be no problem. In order to do that, you need to run configure with a custom --prefix and with a custom PKG_CONFIG_PATH, e.g.: Run this for libmbim, libqmi and ModemManager, in that order: $ PKG_CONFIG_PATH=/opt/test/lib/pkgconfig ./configure --prefix=/opt/test $ make && sudo make install And in order to run the MM daemon, you need to provide a custom LD_LIBRARY_PATH so that the correct libs are found, e.g.: $ LD_LIBRARY_PATH=/opt/test/lib/ /opt/test/sbin/ModemManager --debug -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Fibocom L850-GL / Intel XMM7360 support
> > A little documentation on the RPC protocol is also available: > > https://github.com/xmm7360/xmm7360-pci > > Is that the correct link? Don't see anything regarding the RPC protocol there -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Fibocom L850-GL / Intel XMM7360 support
James Wah writes: > Hi gang, > > I've been working on a PCI driver for the Fibocom L850-GL, and while > it's very rough at this point, it sure does transfer data. > > If anyone is interested in developing support in MM, or in shaping > the kernel driver into something people might actually want to use, now > would be a good time to get involved. MM integration is well beyond my > available time & expertise - I've just been doing this reverse > engineering for fun - but I'd be very happy to contribute what I can. > > The modem does not speak MBIM over PCI, though it does expose some AT > ports. Most tasks eg. PIN management can be done via AT commands. > > In order to initialise the modem, though, or to bring up a raw IP > interface, it's necessary to speak a custom RPC protocol. This is > unpleasant, but not unpossible; the driver I have uses a Python > userspace component to do so. The protocol is ugly but not complicated, > so a C port wouldn't be too involved. > > The driver, and associated RPC tooling, are currently available here: > > https://github.com/xmm7360/xmm7360-pci > > A little documentation on the RPC protocol is also available: > > https://github.com/xmm7360/xmm7360-pci Great stuff! Almost makes me want to buy a device to play with ;-) Being responsible for a number of historical userspace API mistakes I should probably just shut up now But just in case you haven't been following this discussion: https://www.spinics.net/lists/linux-wireless/msg186483.html I have no idea where this has led. But you should probably discuss the userspace API with Johannes and Marcel (I assume Dan and Aleksander is already on the task) before introducing the new driver. Bjørn ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: High memory usage by ModemManager
Hey > > 1. We are not actively resetting the modem anymore. We found that this > only made matters worse. Essentially the kernel was not releasing the USB > interfaces of the modem completely, which results in ModemManager not > acquiring the right ports. > Hummm... did you have custom rules as MM port type hints? MM doesn't rely on interface names for its hints, so it shouldn't matter when grabbing ports. > 2. We are now using mmcli to turn on the GPS. This works without any > issues. > Good! > 3. As you said, it is only possible to have 1 instance of ModemManager, I > thought there were 3 separate instances, but this is not the case. > Yes. > 4. We are not using qmicli ourselves to communicate with the modem via the > QMI interface, all interactions are done by ModemManager. > Ok. > 5. We have updated ModemManager to 1.12.2 and libqmi to 1.24.2 > > The problem we see with ModemManager is that it is slowly using more and > more memory while using the QMI interface of our Quectel BG96 modem. > I have another report from a company that I work with that shows the same symptoms. I don't have any clear picture yet of what the issue could be, because none of my valgrind tests have shown any relevant memory leak. If you could get a proper valgrind log we could give it a look. > We have done some more research and found the following things: > > Our system has 512MB RAM. The OOM killer kills ModemManager after 12 hours > because at that time, it is using half of the memory available: > > Ouch!!! Really? > *[43036.640048] kworker/u2:1 invoked oom-killer: > gfp_mask=0x14082c2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_NOWARN|__GFP_ZERO), > nodemask=(null), order=0, oom_score_adj=0* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *[43036.697846] kworker/u2:1 cpuset=/ mems_allowed=0[43036.701205] CPU: 0 > PID: 18834 Comm: kworker/u2:1 Not tainted 4.14.78 #1[43036.706521] Hardware > name: Freescale i.MX6 UltraLite (Device Tree)[43036.711544] Workqueue: > brcmf_wq/mmc0:0001:1 brcmf_sdio_dataworker [brcmfmac][43036.717326] > [<8010f7b0>] (unwind_backtrace) from [<8010b2bc>] > (show_stack+0x10/0x14)[43036.723780] [<8010b2bc>] (show_stack) from > [<80a2cf5c>] (dump_stack+0x78/0x8c)[43036.729713] [<80a2cf5c>] (dump_stack) > from [<801ceee8>] (dump_header+0xa0/0x230)[43036.735819] [<801ceee8>] > (dump_header) from [<801ce1f8>] (oom_kill_process+0xb0/0x514)[43036.742444] > [<801ce1f8>] (oom_kill_process) from [<801cec2c>] > (out_of_memory+0x15c/0x31c)[43036.749329] [<801cec2c>] (out_of_memory) from > [<801d3884>] (__alloc_pages_nodemask+0xd14/0xf34)[43036.756739] > [<801d3884>] (__alloc_pages_nodemask) from [<802054a0>] > (__vmalloc_node_range+0x114/0x230)[43036.764757] [<802054a0>] > (__vmalloc_node_range) from [<80205858>] > (__vmalloc_node.constprop.11+0x48/0x50)[43036.773030] [<80205858>] > (__vmalloc_node.constprop.11) from [<802058c0>] > (vzalloc+0x2c/0x34)[43036.780267] [<802058c0>] (vzalloc) from [<7f0369f0>] > (brcmf_sdio_dataworker+0x1cbc/0x216c [brcmfmac])[43036.788286] [<7f0369f0>] > (brcmf_sdio_dataworker [brcmfmac]) from [<80141298>] > (process_one_work+0x1d8/0x410)[43036.796825] [<80141298>] > (process_one_work) from [<80141f2c>] > (worker_thread+0x50/0x598)[43036.803623] [<80141f2c>] (worker_thread) from > [<80146d90>] (kthread+0x14c/0x154)[43036.809728] [<80146d90>] (kthread) > from [<80107a48>] (ret_from_fork+0x14/0x2c)[43037.167843] > Mem-Info:[43037.168859] active_anon:98149 inactive_anon:17916 > isolated_anon:0active_file:12 inactive_file:25 > isolated_file:0unevictable:0 dirty:0 writeback:0 > unstable:0slab_reclaimable:1741 slab_unreclaimable:4386 > mapped:14080 shmem:33723 pagetables:936 bounce:0 > free:650 free_pcp:45 free_cma:0[43037.277821] Node 0 active_anon:392596kB > inactive_anon:71664kB active_file:48kB inactive_file:52kB unevictable:0kB > isolated(anon):0kB isolated(file):0kB mapped:56320kB dirty:0kB > writeback:0kB shmem:134892kB writeback_tmp:0kB unstable:0kB > all_unreclaimable? no[43037.367828] Normal free:2680kB min:2704kB > low:3380kB high:4056kB active_anon:392596kB inactive_anon:71664kB > active_file:48kB inactive_file:52kB unevictable:0kB writepending:0kB > present:524288kB managed:503600kB mlocked:0kB kernel_stack:1696kB > pagetables:3744kB bounce:0kB free_pcp:120kB local_pcp:120kB > free_cma:0kB[43037.477797] lowmem_reserve[]: 0 0 0[43037.480024] Normal: > 82*4kB (UME) 72*8kB (UME) 31*16kB (UM) 16*32kB (UM) 6*64kB (U) 3*128kB (U) > 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = > 2680kB[43037.541295] 33751 total pagecache pages[43037.543847] 0 pages in > swap cache[43037.545863] Swap cache stats: add 0, delete 0, find > 0/0[43037.587944] Free swap = 0kB[43037.589582] Total swap = > 0kB[43037.591169] 131072 pages RAM[43037.592750] 0 pages > HighMem/MovableOnly[43037.595286]
