The thing that gave me pause until I investigated more carefully was whether this was a real problem with the modem/driver or if it was a noisy warning for no good reason. After digging into it, I'm confident it's the latter!
Now we have other logs that filling up the logs:
14939.209314] mhi-pci-generic 0000:01:00.0: PME# enabled
[14942.520132] mhi-pci-generic 0000:01:00.0: PME# disabled
[14942.525386] mhi-pci-generic 0000:01:00.0: enabling bus mastering
[14951.652052] mhi-pci-generic 0000:01:00.0: save config 0x00: 0x030817cb
[14951.658588] mhi-pci-generic 0000:01:00.0: save config 0x04: 0x00100402
[14951.665131] mhi-pci-generic 0000:01:00.0: save config 0x08: 0xff000000
[14951.671666] mhi-pci-generic 0000:01:00.0: save config 0x0c: 0x00000010
[14951.678182] mhi-pci-generic 0000:01:00.0: save config 0x10: 0x20000004
[14951.684708] mhi-pci-generic 0000:01:00.0: save config 0x14: 0x00000000
[14951.691246] mhi-pci-generic 0000:01:00.0: save config 0x18: 0x20001004
[14951.697763] mhi-pci-generic 0000:01:00.0: save config 0x1c: 0x00000000
[14951.704296] mhi-pci-generic 0000:01:00.0: save config 0x20: 0x00000000
[14951.710842] mhi-pci-generic 0000:01:00.0: save config 0x24: 0x00000000
[14951.717358] mhi-pci-generic 0000:01:00.0: save config 0x28: 0x00000000
[14951.723886] mhi-pci-generic 0000:01:00.0: save config 0x2c: 0x520117cb
[14951.730428] mhi-pci-generic 0000:01:00.0: save config 0x30: 0x00000000
[14951.736957] mhi-pci-generic 0000:01:00.0: save config 0x34: 0x00000040
[14951.743487] mhi-pci-generic 0000:01:00.0: save config 0x38: 0x00000000
[14951.750024] mhi-pci-generic 0000:01:00.0: save config 0x3c: 0x00000000
[14951.756621] mhi-pci-generic 0000:01:00.0: PME# enabled
[14954.017142] mhi-pci-generic 0000:01:00.0: PME# disabled
[14954.022394] mhi-pci-generic 0000:01:00.0: enabling bus mastering
[14959.517236] mhi-pci-generic 0000:01:00.0: save config 0x00: 0x030817cb
[14959.523770] mhi-pci-generic 0000:01:00.0: save config 0x04: 0x00100402
[14959.530305] mhi-pci-generic 0000:01:00.0: save config 0x08: 0xff000000
[14959.536825] mhi-pci-generic 0000:01:00.0: save config 0x0c: 0x00000010
[14959.543352] mhi-pci-generic 0000:01:00.0: save config 0x10: 0x20000004
[14959.549879] mhi-pci-generic 0000:01:00.0: save config 0x14: 0x00000000
[14959.556395] mhi-pci-generic 0000:01:00.0: save config 0x18: 0x20001004
[14959.562921] mhi-pci-generic 0000:01:00.0: save config 0x1c: 0x00000000
[14959.569475] mhi-pci-generic 0000:01:00.0: save config 0x20: 0x00000000
[14959.576000] mhi-pci-generic 0000:01:00.0: save config 0x24: 0x00000000
[14959.582537] mhi-pci-generic 0000:01:00.0: save config 0x28: 0x00000000
[14959.589068] mhi-pci-generic 0000:01:00.0: save config 0x2c: 0x520117cb
[14959.595591] mhi-pci-generic 0000:01:00.0: save config 0x30: 0x00000000
[14959.602122] mhi-pci-generic 0000:01:00.0: save config 0x34: 0x00000040
[14959.608650] mhi-pci-generic 0000:01:00.0: save config 0x38: 0x00000000
[14959.615168] mhi-pci-generic 0000:01:00.0: save config 0x3c: 0x00000000
[14959.621769] mhi-pci-generic 0000:01:00.0: PME# enabled
[14959.657187] mhi-pci-generic 0000:01:00.0: PME# disabled
[14959.662422] mhi-pci-generic 0000:01:00.0: enabling bus mastering
root@microwave:~# dmesg | grep mhi-pci-generic | wc -l
1732
1 Like
Interesting! I don't see any of these. Potentially something that's been fixed between 6.6.x in openwrt and mainline 6.10.x?
I really don’t know, I solved it by changing the power control of the Pcie interface:
echo 'on' > /sys/devices/platform/soc/11280000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/power/control
And then lowering the kernel log level to warning.
After one day of operation I got only 16 of these noisy messages which is good.
dmesg |grep save|wc -l
16
Glad you've worked around it. For what it's worth, they don't happen on 6.10.x so they should be gone for you completely when openwrt catches up.
I downloaded the latest snapshot of openwrt but it is still on kernel 6.6.45. How did you get 6.10?
I'm not using openwrt: I'm running mainline linux (e.g. from kernel.org) on my device. To work, it needs a small handful of tiny patches that you see in my build tree, but nothing like the number of patches openwrt apply... and some of my patches are for cosmetic issues in the kernel unrelated to the router so you don't really need them.
Part of this is that up-to-date kernels tend to have more up-to-date hardware support, part is that openwrt have to fix problems for every device and every use of that device rather than one in particular. They're solving a hard problem; I'm solving an easy one!
The catch is that you're much more on your own with putting together a kernel, userspace, bootloader, etc. than you would be building openwrt from source. It's much more like installing a custom linux on a x86-64 machine, except that arm tf-a and u-boot are much nicer to deal with than uefi.
1 Like
So, when do you expect OpenWRT to include the patch you did for the mhi generic driver?
I might resend my patch to the linux-mhi list as the first thread seems to have gone to /dev/null. I think getting patches backported to openwrt is much easier once they're accepted upstream, although I confess I don't really know the process. I mostly send the stuff to openwrt as a way of contributing back, given that I don't use it directly myself.
Similarly, I've been holding off on updating the gl-x3000 u-boot PR on github because really it wants a backport of [PATCH] pinctrl: mediatek: Bind gpio while binding pinctrl - Chris Webb for initialising the modem power neatly - but unfortunately after agreeing on the form of that patch with one of the u-boot maintainers, it now seems to be in limbo rather than merged.
We're really lucky here in the forum to have you! Otherwise, I would be using the Quectel's driver, which as you emphasized before that it contains bad quality codes.
For now, I am very happy with your fix since I do not need to use anymore Quectel's QConnect Manager or thier MHI driver.
@SpitzAX3000
A new firmware was released for RM520N-GL:
RM520NGLAAR03A04M4G_01.202.01.202.zip
Can you please test with it?
After a reboot today, the interface started coming up as wwan0. I had to add another device rule for wwan0, rather than rmnet_mhi0.1. Not sure why.
Which openwrt version are you running ? Kernel version ? Have you updated the packages recently?
Test what ? I think this module firmware has nothing to do with the MHI drivers.
The speed issue, QC usually improve stuff between major releases
I haven't updated anything as far as I am aware since my last post about rc.local.
6.6.45
OpenWrt SNAPSHOT r27137-f51cb74473 / LuCI Master 24.212.79282~65b8002
Got it. I will test later this weekend. But I am not expecting increase in the speed as the changlogs of these releases only mention additional support for newer hardware.
Once I have tested it, I will definitely update this post.
Wired ! How did this interface then came up? Are you using the Quectel MHI driver or the stock one patched by Chris ?
Can you run please
lsmod | grep ‘mhi\|wwan’
I thought I was running the patched modules through your guide... unless OpenWrt automatically updated or did something to remove them...
root@OpenWrt:~# lsmod | grep -E 'wwan|mhi'
cdc_wdm 20480 4 cdc_mbim,qmi_wwan,huawei_cdc_ncm
pcie_mhi 155648 0
qmi_wwan 28672 0
usb_wwan 16384 2 qcserial,option
usbcore 192512 29 qcserial,option,cdc_mbim,usb_wwan,rndis_host,qmi_wwan,huawei_cdc_ncm,ch348,ch341,cdc_ncm,cdc_ether,usbserial,usbnet,ipheth,cdc_wdm,cdc_acm,uas,usb_storage,xhci_plat_hcd,xhci_pci,xhci_mtk_hcd,xhci_hcd,uhci_hcd,ohci_platform,ohci_hcd,ehci_platform,ehci_fsl,ehci_hcd
usbnet 24576 6 cdc_mbim,rndis_host,qmi_wwan,huawei_cdc_ncm,cdc_ncm,cdc_ether
usbserial 24576 7 qcserial,option,usb_wwan,ch348,ch341
Yes you seem to be running the Quectel MHI driver from my guide - not the stock MHI Openwrt driver. However the Quectel driver should not create wwan0 unless I believe if you switched from PCIe mode to USB?