Modem no longer working


Silent-Hunter

Hardcore Member
Joined
May 29, 2010
Messages
3,485
So I'm not sure when this started, but my modem no longer works. When I boot the Pyra up, and do lsusb, it shows up, and ls /dev shows the ttyACM1 through 4 devices, but mmcli -L says there are no modems, and after a while the ttyACMs disappear, and lsusb shows one less entry. This is different than the USB devices missing on boot issue, as it's consistent and persistent. If I do sudo rfkill block 0 and then sudo rfkill unblock 0 the ttyACMs come back, along with the lsusb entry, but then it vanishes again later.
 
Damn I hope there's some other solution. I have everything all set up how I like it. Maybe I can try booting from a freshly made boot SD?
 
I've seen, on my Pandora, something similar, where a supposed directory suddenly was a file, and that prevented the directory to be created (same name). So if you reflash, copy all files over to a big USB stick and diff it later.
You can then also diff the flashed filesystem and the one on the USB stick, which you can then copy back. Just be casreful to not copy the /dev/ directory.
So that means that if you can find another Pyrian who can run:
Code:
find / |sort |while read f;do ls -lad $f|awk '{print $1,$2,$3,$4,$5,$9}';done
you can diff that file with one of yours and see if you have a difference. (granted, the other also needs your packages and have done an apt-get update && apt-get upgrade
 
Last edited:
I tried rfkill unblock 0 again to see if I could to anything with it in cutecom, and then the Pyra did this. The nubs and dpad immediately stopped working at the same time, and then not long after, the enter key did as well. Very strange.
IMG_20210405_153639_DRO.jpg
 
Looks like a crash report including a stack trace from the kernel itself. Presumably the kernel reinited giving you that prompt afterwards, and it's perhaps not surprising after an event like that that things are misconfigured. But I've never actually seen a kernel panic on my x86 boxen or my Pandora, so that seems strange to me.
 
Looks like a crash report including a stack trace from the kernel itself. Presumably the kernel reinited giving you that prompt afterwards, and it's perhaps not surprising after an event like that that things are misconfigured. But I've never actually seen a kernel panic on my x86 boxen or my Pandora, so that seems strange to me.
Not an expert by any stretch but I have "successfully" caused kernel panics on my various x86 and x86_64 boxes over the years (including one where a hard drive head strike erased init. Surprisingly it was able to self recover that time with a fsck) and in my experience the kernel panics always dropped to single user mode and had "Kernel Panic" as the final line so I think this might be some sort of lesser severity crash. Either that or Ubuntu treats kernel panics differently than Debian.
 
Yes, there is a Image, but I don’t know where, but it should be in one of the help threads I used..
In my first few weeks I wanted to take a boot flag from my SD Card, so the Pyra would also boot up whit SD Card insert, otherwise the Pyra would try to boot from SD because it’s thought there is an image..
unfortunately I took the boot flag from the false drive, it was the internal storage, so I had to put this Reflash Image to a different SD Card, and had to make everything again ..
since then I don’t touch my SD Cards, but just push them out for booting..
 
It may be that the modem is not reliable on the unit you have. Perhaps if you write out your reproducability instrictions in the first place with clearer steps and more exact timings, perhaps other users reading this can also try this out and observe how it works on their units. I'd imagine ED's testing script just tests for the presence of the modem fairly directly and simply, so it may not pick up your situation where it seems to disappear after you do something, or you wait after doing something.
 
It may be that the modem is not reliable on the unit you have. Perhaps if you write out your reproducability instrictions in the first place with clearer steps and more exact timings, perhaps other users reading this can also try this out and observe how it works on their units. I'd imagine ED's testing script just tests for the presence of the modem fairly directly and simply, so it may not pick up your situation where it seems to disappear after you do something, or you wait after doing something.
It's consistently not working at all. It used to only occasionally not work, when the USB ports didn't initialize correctly. Now even when those work, the modem itself doesn't. It appears for a few minutes and then vanishes from lsusb and /dev
 
It's consistently not working at all. It used to only occasionally not work, when the USB ports didn't initialize correctly. Now even when those work, the modem itself doesn't. It appears for a few minutes and then vanishes from lsusb and /dev
Ah, so it's just the timing that kicks it off? I guess that could be measured and then reproduced. I wonder now exactly what ED's testing scripts do with respect of the modem.

It's probably worth checking 'dmesg' and 'journalctl -b 0' to see if there's anything logged when it drops off.
 
It's consistently not working at all. It used to only occasionally not work, when the USB ports didn't initialize correctly. Now even when those work, the modem itself doesn't. It appears for a few minutes and then vanishes from lsusb and /dev
On the schematics there is a INA231YFF chip to monitor the current going into the modem with I2C address 0x4F.
This can give you the current used by the modem by typing "sensors" at the terminal. Maybe that can give some clues?
Bash:
@pyra:~$ sensors
ina231-i2c-1-4f
Adapter: OMAP I2C adapter
in0:          +0.00 V
in1:          +3.68 V
power1:      300.00 mW
curr1:        +0.08 A

I see between 0.02 and 0.09A with the modem on and 0A with it off (/usr/share/pyra/scripts/letux/wwan-off or on).

More detail:
  • In the letux kernel, I see the INA231 is registered in the device tree. Its on the 2nd I2C bus and uses the ina2xx (see also ina2xx.c) for the ina2xx driver
  • The ina2xx driver provides a hwmon sysfs interface which means you can interact with the driver from the /sys folder
  • On my pyra, I can see
    • the I2C driver at /sys/class/i2c-dev/i2c-1/device/1-004f
    • or by the driver module name at :/sys/module/ina2xx/drivers/i2c:ina2xx/1-004f
  • sensors finds the sysfs values and formats the values
 
Last edited:
I reset the modem with rfkill, and it says:
Code:
in0:         +0.00 V
in1:         +3.72 V
power1:      34.38 mW
curr1:       +0.01 A

Then after a while when the modem interfaces have disappeared, it says:
Code:
in0:         +0.00 V
in1:         +3.72 V
power1:       6.25 mW
curr1:       -0.00 A
Post automatically merged:

Could that be a kernel version issue ?
I don't think so, as there have been no updates since when it was working.
 
Hmm... Well it's happening at any battery level and without charger plugged in. But it's worth a look. I'll check!
 
Back
Top