n0bel / PiClock

A Fancy Clock built around a monitor and a Raspberry Pi
MIT License
566 stars 182 forks source link

Using WiFi causes hard lockup #148

Closed w4lks closed 5 years ago

w4lks commented 5 years ago

On my RPi3B+, when I use wired Ethernet, PiClock works great. When I unplug the Ethernet cable and start PiClock, it locks up hard. Have to pull the power recover from hard lockup. WX data never gets populated on the clock screen.

WiFi is confirmed working before starting PiClock. Logs indicate nothing unusual..stops while getting radar from darksky.

After I plug the power back in and reboot. I plug in the Ethernet cable and now PIClock work normal again. I wanna hang the PiClock on the wall, don't wanna use wired Ethernet.

This is fresh install of stretch. All updates done. No additional hardware (sensors, LEDs, ets) used.

BertLindeman commented 5 years ago

Hi (how should I call you?),

Is it the RPI that freezes or just the PiClock?

Trying to separate the two:

In a terminal session (e.g. via ssh) at the moment you pull the ethernet cable: Do you see the wifi connection come up? Look using ifconfig

In your PiClock log there are lines starting with: "https://api.darksky.net/forecast"

While you have a wifi connection in your terminal session, does wget the-complete-darksky-forecast-line work? It should download the forecast data.

Just trying to get more info about your situation. Bert

w4lks commented 5 years ago

Hi Bert...Thanks. My name is Randy. Located in Spokane, WA

If I start PiClock while having a working WiFi network connection, No weather data populates the screen, only the working analog clock. I can hit F4 and PiClock GUI screen will terminate and I see the terminal window, although PiClock appears to still be running, it has not given me a new command prompt. Hitting CTRL-C does not stop PiClock and give a new command prompt. I can close that terminal window and open a new one. But by then the networking is fowled up and no longer works. If I type ifconfig, or try to ping a host on the Internet, the pi becomes locked up. I cannot SSH into the pi at that point either. You also cannot type reboot, or even choose shutdown|reboot from the GUI menus, It get stuck and says "plymouth.reboot service" It has to have the power cable unplugged to reboot. It appears that something that PiClock is doing corrupts the TCPIP networking stack.

If I start PiClock with the Ethernet cable plugged in (doesn't matter if Wifi is configured to connect to my access point or not) Everything works OK. I get the maps and weather, I can hit F4 to exit and I can do other networking commands after that, restart PiClock, etc. All is good.

I have started fresh with a newly built jessie image twice. Followed the instructions carefully. No Joy.

Here is the log file if I try to start using a WiFi connection:

libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile map base url: https://api.mapbox.com/styles/v1/mapbox/satellite-streets-v10/static/-117.5887,47.5648,6,0,0/333x275?access_token=[snip] map base url: https://api.mapbox.com/styles/v1/mapbox/satellite-streets-v10/static/-117.5887,47.5648,10,0,0/333x275?access_token=[snip] map base url: https://api.mapbox.com/styles/v1/mapbox/satellite-streets-v10/static/-117.5887,47.5648,6,0,0/777x700?access_token=[snip] map base url: https://api.mapbox.com/styles/v1/mapbox/satellite-streets-v10/static/-117.5887,47.5648,10,0,0/777x700?access_token=[snip] getting current and forecast:Sat Mar 16 20:40:39 2019 https://api.darksky.net/forecast/[snip]/47.5648,-117.5887?units=us&lang=en&r=0.552051291372 wxstart for radar1 wxstart for radar2 get... 1552765800 radar2 radar2 0 https://tilecache.rainviewer.com/v2/radar/1552765800//256/11/354/715/6/1_1.png get... 1552765800 radar1 radar1 0 https://tilecache.rainviewer.com/v2/radar/1552765800//256/7/21/44/6/1_1.png

Yes...typing wget the-complete-darksky-forecast-line does download and index.html file. But only after I have rebooted with the ethernet cable unplugged, and have not attempted to start PiClock. If I type that wget command after I have attempted to start PiClock, It becomes locked up...I have to yank the power cable.

Really, I'm the only one who has this problem? The is the latest PiClock from this github site.

Hope you can help...Thanks for asking. Randy

BertLindeman commented 5 years ago

Hi Randy, Thanks, So much better to "talk" to a name.

Using the powercable as powerswitch is indeed a bad thing. May damage the sd-card. :-(

Minor thing, you can ignore these messages: libpng warning: iCCP: known incorrect sRGB

Let me see if I understand the situation well enough:

  1. No problem if eth-cable connected
  2. Using wifi connection before PiClock started no problem
  3. Looking at the log you show (api-keys snipped - GOOD) the last thing we see is getting the radar tiles
  4. you "switch" from eth to wifi by pulling the eth-cable.

Looking at my log at the start, I see

Your log is a bit hard to read due to it's format (Did you use 3 backticks to format it?) For what I see your log is similar to mine. There are a number of accesses to rainviewer depending in the zoomfactors used.

I am a bit out of suggestions. So tried to mimick your situation. My PiClick is a RPI2 desktop thinghy with touchscreen and uses the eth-cable as I want to minimize wifi usage for devices that need it. Added and setup a wifi dongle. Kept the PiClock running.

There should not be any impact on the clock if a network interface is switched. As long as internet traffic is not blocked. The clock justs accesses the internet addresses. And internet access is only needed for radar and weather refreshes. (Not so often)

If you could access the PI from a remote PC or such via ssh and run htop or top to see what task is running or dominates the system at the moment you pull the eth-plug.

In some cases the advise may be: did you try another sd-card?

Maybe @n0bel has a debugging idea?

w4lks commented 5 years ago

I started over again from scratch. Using an RPi2B, a USB WiFi dongle and a different SDHC card. This time it worked OK. PiClock works OK over WiFi. I can start it, stop it over and over. The TCPIP stack does not freeze up.

I don't know what happened when I tried to install on an RPi3B+ using the internal WiFi adapter. Since there are no others having problems like this, it must be a isolated problem on my end.

Maybe this can be here to be a record in case someone else bumps into a similar issue. I'll close this issue since it is now resolved for me and I don't have any more time to figure out what went wrong.