Is anybody observing lockups on Raspberry Pi 3 with chromium? It seems to happen most often when dragging maps or images. The machine is at
4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l (latest Stretch available via apt-get).
On a few occasions the machine has crashed out of X and shown an out of memory error, but most of the time it simply stops responding. I am using the experimental GL desktop, the standard one is too slow to be useful. The problem appeared a couple of months ago and shows no sign of abating.
My first itch would be the pi is suffering under-voltage when it is very busy. Check with: vcgencmd get_throttled or keep an eye on the yellow lightning bolt.
Hmmmm, that sounds a little familiar--_if_ Chromium is the default browser in Raspian. Monday evening, while watching an online video on a Pi 3B+ with a 1920x1080 TV via the HDMI port. After about an hour, the picture froze a few times but the sound kept going for a few minutes. Eventually, everything locked up. Alt-Ctrl-F(n) got a text console, and "sudo reboot" took a few minutes before it succeeded. I had figured it was likely heat, so I aimed a fan at the heatsink and watched another 45 minutes without difficulty. A memory leak in Chromium, the X server, or the graphics driver might be consistent with both sets of symptoms.
Thanks,
--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)
On Thu, 12 Sep 2019 02:07:01 +0000 (UTC), bob prohaska declaimed the following:
I'd recommend opening a console and running some memory monitor program ("top", configured to sort by memory [the default, I think, is CPU -- check "man top"). Check the values shown periodically, and especially when the system hangs.
Many graphical web browsers tend to be memory hogs.
Might also want to try configuring a small USB hard-drive with a swap file/partition (file is probably easier, since it doesn't require making partitions on the drive -- though you may want to format the drive with EXT3 or EXT4). You do NOT want to create a swap file on the SD card -- swapping will kill an SD card rapidly (besides being rather slow).
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
Many web sites are memory hogs: Oh for basic HTML., Now its all frameworks and json and shit like that.
My computer here slowed to a crawl. Firefox had eaten 8GB of RAM just looking at a newspaper.
And that is WITH adblocking
Ive got a swap file on my SD card. Never gets used .
--
Of what good are dead warriors? ? Warriors are those who desire battle
more than peace. Those who seek battle despite peace. Those who thump
their spears on the ground and talk of honor. Those who leap high the
battle dance and dream of glory ? The good of dead warriors, Mother, is
that they are dead.
Sheri S Tepper: The Awakeners.
That sounds like it is running out of memory, browsers are absolute memory hogs, especially when dealing with complex javascript you find on maps. Its probably slowing down when its starts to swap to SD card, and then eventually crashes out when swap is exhausted too.
If you have the CPU monitor widgit on your toolbar, configure it to show green for user, red for system, blue for nice and orange for IO wait. When it starts to swap and slow down you'll see a lot of orange appearing.
You should keep as few applications running as possible, as 1GB isn't really enough for run many desktop applications at once. If it still happens, get some decent storage (USB3 stick or a SSD) and configure more swap. Although my recommendation would be to get a Pi4, as 4GB removes most of the memory worries on the desktop.
The machine has an 8GB usb flash drive for swap. It probably can't use the whole thing, but some is better than none. Without hardware swap Chromium is totally unusable. With it, usually Chromium works fairly well. The issue surfaced after an upgrade about three months ago.
When it did report an error the whole GUI was gone, so there wasn't an easy way to capture the message. Maybe it's time to use macPencil next time it occurs.
I'll try that next. In the meantime here's another observation:
I started a firefox session on a remote host (via ssh -X) from the Pi. Once the X window opened up the Pi slowed to an unusable crawl, but the load notation in the top-right menu bar stayed under 25%, a top window reported less than 200 MB of swap in use. In this case the machine didn't lock up but was basically useless. It took a few minutes to bring a window to the foreground. The page I opened was
formatting link
which is a single frame of weather satellite imagery. No animation.
That seems to point toward a problem with the X server on the Pi. BTW, I'm using the "experimental GL desktop".
On Sun, 15 Sep 2019 16:35:14 +0000 (UTC), bob prohaska declaimed the following:
What model R-Pi? Quad-cores could either be reporting 0-400% (each core being 100%) or 0-100% (where 25% implies a single fully loaded core)
Well I did manage to lock up a 3B+ -- but I had asked it to load a 144 frame animation. That used up all the RAM available (I don't have a configured swap drive) while trying to load the 38th or so image.
A bit tedious to do this testing -- I have to use my monitor controls to switch from DisplayPort (Windows computer) to HDMI port (R-Pi), along with remember which keyboard/mouse to grab.
Output from "top -B" filtered for the chromium browser entries. Over the period I went from single frame to, I think, 8 frames, and then changed settings to whole disk (earth). I also configured the top panel to display CPU % -- based on having seen a few at 190%, it is reporting each core as
100%.
pi@raspberrypi:~$ cat load2.txt PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1284 pi 20 0 475164 114324 80900 S 0.0 12.1 0:27.04 chromium-browse 1306 pi 20 0 198328 34588 28916 S 0.0 3.6 0:00.23 chromium-browse 1317 pi 20 0 198328 9076 3364 S 0.0 1.0 0:00.02 chromium-browse 1341 pi 20 0 336720 84388 69556 S 0.0 8.9 0:11.10 chromium-browse 1347 pi 20 0 256212 47480 38396 S 0.0 5.0 0:02.98 chromium-browse 1522 pi 20 0 354564 86728 49804 S 0.0 9.1 0:15.61 chromium-browse 1653 pi 20 0 386936 116192 81504 S 0.0 12.3 0:35.81 chromium-browse 1653 pi 20 0 386936 115980 81504 S 13.2 12.2 0:36.21 chromium-browse 1341 pi 20 0 336720 84388 69556 S 3.3 8.9 0:11.20 chromium-browse
Hard to track -- there are 7 distinct threads being reported for just one instance of Chromium, and a few of them are reporting 12% of memory used...
1284 pi 20 0 475164 114324 80900 S 1.0 12.1 0:27.07 chromium-browse 1347 pi 20 0 256212 47480 38396 S 0.3 5.0 0:02.99 chromium-browse 1306 pi 20 0 198328 34588 28916 S 0.0 3.6 0:00.23 chromium-browse 1317 pi 20 0 198328 9076 3364 S 0.0 1.0 0:00.02 chromium-browse 1522 pi 20 0 354564 86728 49804 S 0.0 9.1 0:15.61 chromium-browse 1653 pi 20 0 386936 116040 81504 S 18.1 12.2 0:36.76 chromium-browse 1284 pi 20 0 476524 115624 82200 R 14.1 12.2 0:27.50 chromium-browse 1341 pi 20 0 338080 84528 69696 S 6.9 8.9 0:11.41 chromium-browse 1347 pi 20 0 256724 47480 38396 S 1.0 5.0 0:03.02 chromium-browse 1306 pi 20 0 198328 34588 28916 S 0.0 3.6 0:00.23 chromium-browse 1317 pi 20 0 198328 9076 3364 S 0.0 1.0 0:00.02 chromium-browse 1522 pi 20 0 354564 86728 49804 S 0.0 9.1 0:15.61 chromium-browse 1653 pi 20 0 408252 140784 90884 S 80.1 14.8 0:39.18 chromium-browse
There's a burst that used 80% of (a) CPU, and 15% of memory... Filtering for just that thread.
pi@raspberrypi:~$ grep "1653" load2.txt 1653 pi 20 0 386936 116192 81504 S 0.0 12.3 0:35.81 chromium-browse 1653 pi 20 0 386936 115980 81504 S 13.2 12.2 0:36.21 chromium-browse 1653 pi 20 0 386936 116040 81504 S 18.1 12.2 0:36.76 chromium-browse 1653 pi 20 0 408252 140784 90884 S 80.1 14.8 0:39.18 chromium-browse 1653 pi 20 0 408508 141172 91152 S 32.5 14.9 0:40.50 chromium-browse 1653 pi 20 0 408508 141708 91368 S 21.7 14.9 0:41.16 chromium-browse 1653 pi 20 0 397368 128960 91432 R 33.4 13.6 0:42.17 chromium-browse 1653 pi 20 0 412652 141388 91560 S 32.5 14.9 0:43.15 chromium-browse 1653 pi 20 0 562496 290220 138076 R 41.3 30.6 0:44.63 chromium-browse 1653 pi 20 0 581256 310012 156836 S 36.0 32.7 0:46.82 chromium-browse 1653 pi 20 0 578468 307180 156836 S 28.2 32.4 0:47.68 chromium-browse 1653 pi 20 0 582564 311084 160492 S 34.2 32.8 0:48.72 chromium-browse 1653 pi 20 0 535224 262184 156396 S 41.9 27.6 0:49.99 chromium-browse 1653 pi 20 0 535224 262304 156396 S 40.4 27.7 0:51.21 chromium-browse 1653 pi 20 0 458032 186452 156460 S 47.4 19.7 0:52.64 chromium-browse 1653 pi 20 0 491640 220372 156652 S 9.2 23.2 0:52.92 chromium-browse 1653 pi 20 0 569596 297956 194316 S 47.4 31.4 0:54.35 chromium-browse 1653 pi 20 0 569596 297880 194316 S 35.2 31.4 0:55.42 chromium-browse 1653 pi 20 0 569596 298184 194316 S 30.8 31.4 0:56.35 chromium-browse 1653 pi 20 0 569676 298380 194316 S 33.2 31.5 0:59.08 chromium-browse 1653 pi 20 0 569676 298304 194316 S 27.0 31.5 0:59.90 chromium-browse 1653 pi 20 0 572464 301068 194316 R 26.2 31.7 1:00.69 chromium-browse pi@raspberrypi:~$
It was using upwards of 50% of (a) CPU at times, and a third of the memory. Remember, this is on a 3B+ 1.4GHz quad-core processor. Straight Raspbian install (2019-07-10 as I recall -- aka: NOOBS_v3_2_0.zip). No experimental graphics drivers.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
Sorry, it's a 3B+ with an 8GB usb flash swap device. Raspbian was up to date as of a few days ago.
Ok, seem like you had no problem at all, _with_ the browser running on the same machine that was displaying it. The test case I described had firefox running on a second host and only _displaying_ on the Pi3B+ I gather you were testing chromium, which in my case would lock up immediately on the page at ssec.wisc.edu.
It sounds like my problems don't replicate on your machine. I must be doing something wrong.....
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.