Some more information: When I initially noticed the problem on December 31, it showed up in the journal as being unable to upload the GNSS data to the modem. (Unfortunately, the journal logs are not kept that long, so I cannot paste the exact log messages.) Well, actually, it was more like that the modem kept going down during the upload, getting restarted, and the upload failing again. So disabling GNSS uploads through /etc/eg25-manager/pine64,pinephone-1.2.toml was the first thing I tried. That showed pretty quickly that the GNSS issue was only a symptom rather than the cause. Still, I kept GNSS uploads disabled because I had the impression that that increased the likelihood of the modem resetting successfully.
Then I have had phases with the modem getting restarted very frequently, but being mostly up, and phases with the modem being mostly down.
Now, for 2 days or so, I have not seen the modem up at all anymore. And no, the replacement battery that I tried cannot be the cause, because the modem was already down for hours when I tried that yesterday evening.
The strange thing is, eg25-manager claims to be able to communicate with the modem, and even that it is "fully ready":
but I do not see the device actually showing up anywhere else, even the device node seems AWOL (at least I cannot find it under /dev).
systemctl restart eg25-manager can be used to trigger a reset attempt. It has sometimes helped, but not anymore, it seems. (It just gets stuck the same way again.)
Sometimes, eg25-manager also tries to reset the modem on its own. Then I can also see errors such as:
or
(I guess the latter is when the USB device node has never come up since bootup, the former seems to mean that the USB connection was lost somehow.)
I have now also tried the /lib/udev/rules.d/98-prevent-bugs.rules snippet (and of course I have rebooted the phone after creating the file, so that the rules are actually applied), it does not seem to make any difference either.
So the modem chip seems pretty FUBAR at this point.
Upgrading the firmware is something I have thought of as well, but if the modem goes down while flashing, it is going to be pretty much bricked. Also, I think I need the device node to flash anything to the modem, do I not?
I have not yet tried booting another OS on the main CPU. I will do so ASAP. (I need a suitable MicroSD card, as I do not really wish to overwrite the Jumpdrive I have on the one SD card I have at hand.) But at this point, I am not positive it will help. But of course it is worth trying.
Then I have had phases with the modem getting restarted very frequently, but being mostly up, and phases with the modem being mostly down.
Now, for 2 days or so, I have not seen the modem up at all anymore. And no, the replacement battery that I tried cannot be the cause, because the modem was already down for hours when I tried that yesterday evening.
The strange thing is, eg25-manager claims to be able to communicate with the modem, and even that it is "fully ready":
Code:
Jan 18 15:55:41 plasma-mobile eg25-manager[4496]: Opening config file: /usr/share/eg25-manager/pine64,pinephone-1.2.toml
Jan 18 15:55:41 plasma-mobile eg25-manager[4496]: Opening config file: /etc/eg25-manager/pine64,pinephone-1.2.toml
Jan 18 15:55:41 plasma-mobile eg25-manager[4496]: GNSS assistance is disabled!
Jan 18 15:55:41 plasma-mobile eg25-manager[4496]: Starting modem...
Jan 18 15:55:43 plasma-mobile eg25-manager[4496]: Executed power-on/off sequence
Jan 18 15:55:43 plasma-mobile eg25-manager[4496]: taking systemd sleep inhibitor
Jan 18 15:55:43 plasma-mobile eg25-manager[4496]: ModemManager appeared on D-Bus
Jan 18 15:55:43 plasma-mobile eg25-manager[4496]: oFono vanished from D-Bus
Jan 18 15:55:43 plasma-mobile eg25-manager[4496]: inhibitor sleep fd is 21
Jan 18 15:55:53 plasma-mobile eg25-manager[4496]: Response: [RDY]
Jan 18 15:55:53 plasma-mobile eg25-manager[4496]: taking systemd sleep inhibitor (blocking)
Jan 18 15:55:53 plasma-mobile eg25-manager[4496]: Response: [+CPIN: READY]
Jan 18 15:55:53 plasma-mobile eg25-manager[4496]: Executed soft sleep sequence
Jan 18 15:55:53 plasma-mobile eg25-manager[4496]: inhibitor block fd is 20
Jan 18 15:55:53 plasma-mobile eg25-manager[4496]: Response: [+QUSIM: 1]
Jan 18 15:55:53 plasma-mobile eg25-manager[4496]: Executed soft sleep sequence
Jan 18 15:55:53 plasma-mobile eg25-manager[4496]: Response: [+CFUN: 1]
Jan 18 15:55:53 plasma-mobile eg25-manager[4496]: Executed soft sleep sequence
Jan 18 15:55:53 plasma-mobile eg25-manager[4496]: Response: [+QIND: SMS DONE]
Jan 18 15:55:53 plasma-mobile eg25-manager[4496]: Executed soft sleep sequence
Jan 18 15:55:54 plasma-mobile eg25-manager[4496]: Response: [+QIND: PB DONE]
Jan 18 15:55:54 plasma-mobile eg25-manager[4496]: Executed soft sleep sequence
Jan 18 15:57:53 plasma-mobile eg25-manager[4496]: Modem is up for 120 seconds and fully ready
Jan 18 15:57:53 plasma-mobile eg25-manager[4496]: dropping systemd sleep block inhibitor
systemctl restart eg25-manager can be used to trigger a reset attempt. It has sometimes helped, but not anymore, it seems. (It just gets stuck the same way again.)
Sometimes, eg25-manager also tries to reset the modem on its own. Then I can also see errors such as:
Code:
Jan 17 16:17:01 plasma-mobile eg25-manager[3024]: Modem wasn't probed in time, restart it!
Jan 17 16:17:01 plasma-mobile eg25-manager[3024]: Trying to reset modem with USB ID '3-1'
Jan 17 16:17:01 plasma-mobile eg25-manager[3024]: Couldn't unbind modem: wrote -1/3 bytes
Jan 17 16:17:01 plasma-mobile eg25-manager[3024]: USB reset failed, falling back to AT command
Code:
Jan 18 11:09:47 plasma-mobile eg25-manager[15692]: Modem wasn't probed in time, restart it!
Jan 18 11:09:47 plasma-mobile eg25-manager[15692]: Empty modem USB ID
Jan 18 11:09:47 plasma-mobile eg25-manager[15692]: USB reset failed, falling back to AT command
I have now also tried the /lib/udev/rules.d/98-prevent-bugs.rules snippet (and of course I have rebooted the phone after creating the file, so that the rules are actually applied), it does not seem to make any difference either.
So the modem chip seems pretty FUBAR at this point.
Upgrading the firmware is something I have thought of as well, but if the modem goes down while flashing, it is going to be pretty much bricked. Also, I think I need the device node to flash anything to the modem, do I not?
I have not yet tried booting another OS on the main CPU. I will do so ASAP. (I need a suitable MicroSD card, as I do not really wish to overwrite the Jumpdrive I have on the one SD card I have at hand.) But at this point, I am not positive it will help. But of course it is worth trying.