Modem no longer working

[Silent-Hunter]

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.

 

[FBnil]

reflash?

 

[Silent-Hunter]

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?

 

[FBnil]

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:

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

 

[Silent-Hunter]

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.

 

[levi]

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.

 

[MTPDA]

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.

 

[Silent-Hunter]

Well, it says Oops on it, so it may be a kernel oops.

 

[ingoreis]

I would recommend a Reflash.
Is there any Howto for reflashing a Pyra?

 

[matzesu]

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..

 

[Silent-Hunter]

I made a Pyra OS SD card and it's doing the same thing there. Something is definitely wrong. I think.

 

[levi]

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.

 

[Silent-Hunter]

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

 

[Linux-SWAT]

Could that be a kernel version issue ?

 

[levi]

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.

 

[ouzle]

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?

@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

 

[Silent-Hunter]

I reset the modem with rfkill, and it says:

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:

in0:         +0.00 V
in1:         +3.72 V
power1:       6.25 mW
curr1:       -0.00 A

Post automatically merged: Apr 11, 2021

Could that be a kernel version issue ?

I don't think so, as there have been no updates since when it was working.

 

[ouzle]

Did you see hns' kernel discussion from 2018 about how over-voltage can cause the modem to power off?

Keep an eye on the VSYS voltage with the /usr/share/pyra/letux/charger script. If VSYS exceeds 4.2V then the previous kernel fix has stopped working. Was your battery fully charged when the modem disappears?

 

[Silent-Hunter]

Hmm... Well it's happening at any battery level and without charger plugged in. But it's worth a look. I'll check!

 

[Silent-Hunter]

It's 3667mV and it's still not working.