sudo systemctl restart network-manager.service restores wireless after coming out of suspend. Ideas here on how to automate this? I guess I could make a macro so doing it manually would be simple, but it would be nice to make it automatic on restore from suspend.
Still no recurrence of the lockup. -Denis On Wed, Jun 22, 2016 at 6:21 PM, Denis Heidtmann <denis.heidtm...@gmail.com> wrote: > I ran glmark2 for 4 hours 15 minutes w/o lockup or any failure. Going > into suspend and back out shows the network problem. My understanding is > that network manager comes out of suspend trying to connect to the wireless > as if it were wired. (the symbol on the task bar changes from the wireless > icon (concentric arcs moving toward a vertex) to the wired icon (fat up and > down arrows). There are discussions on the web that say sudo systemctl > restart network-manager-service will restore the wireless. sudo service > network-manager restart is also listed. I should think that the former > would be the command of choice since ubuntu 16.04 is supposed to be using > systemd. Have yet to try either. > > -Denis > > On Tue, Jun 21, 2016 at 8:07 PM, Denis Heidtmann < > denis.heidtm...@gmail.com> wrote: > >> More on wireless w/suspend. I see that coming out of suspend wireless >> did not reconnect. I do not know if that is related to my failures, but >> it is something to watch for. Thanks for pointing the issue out to me. >> >> >> On Mon, Jun 20, 2016 at 11:43 AM, Denis Heidtmann < >> denis.heidtm...@gmail.com> wrote: >> >>> I have heard about that before, but I believe I had been using the >>> machine for a while immediately before the lockup, so I do not think the >>> wireless driver would have just started (or anything else associated with >>> waking after sleep). But I will keep the idea in mind if/when I have >>> another lockup. In the meantime I have run memory check (12 passes, no >>> errors). Next will be e2fsck--I did that already but I think I did not run >>> it on the main part of the drive. >>> >>> I did notice that upon booting after the forced shutdown there were a >>> number of lines of messages which appeared prior to the login dialog, but >>> were too brief to read. On normal boot, i.e., not following a forced >>> shutdown, two lines of messages appear. I took a video to capture what >>> they said: >>> lvmetad is not active yet, using direct action during system init. >>> /dev/mapper/ubuntu--vg-root: clean, 238556/753... files, ....(more >>> numbers) blocks. >>> >>> I will keep the video handy for the next incident to capture the >>> messages. >>> >>> Need to have some routine to exercise the graphics to see if I can cause >>> the failure. If I cannot predict/reproduce the failure it seems that it >>> will be nearly impossible to pin down. >>> >>> Thanks for your suggestion. >>> >>> -Denis >>> >>> >>> >>> On Sat, Jun 18, 2016 at 6:14 PM, Nat Taylor <biob...@gmail.com> wrote: >>> >>>> Do you think it could have something to do with trying to go to sleep or >>>> and then having some sort of problem with the wifi driver? I've seen >>>> that >>>> and the solution is to have the wireless driver disabled before sleep? >>>> I >>>> think power management is always a good place to start looking when a >>>> laptop locks up. Upstart takes care of stuff while going to sleep on >>>> Ubuntu: >>>> >>>> http://askubuntu.com/questions/441748/where-are-upstart-log-messages-on-ubuntu-13-x >>>> --- ^if you enable upstart log messages you'll get more detail >>>> http://upstart.ubuntu.com/ >>>> >>>> On Fri, Jun 17, 2016 at 6:13 PM, David <dafr+p...@dafr.us> wrote: >>>> >>>> > On 06/17/2016 04:45 PM, Denis Heidtmann wrote: >>>> > > I have had about 3 lockups on my new (used) Lenovo L420. The >>>> symptoms >>>> > are >>>> > > that the system freezes with no responses to either the mouse or the >>>> > > keyboard. >>>> > >>>> > <clip> >>>> > >>>> > I have an aging T61 that exhibited random lockup / reboot cycles as >>>> > well. I found that removing the generic nouveau video driver for the >>>> > proprietary nvidia driver resolved my issue. >>>> > >>>> > The other thing that happened with this was a reduction of memory >>>> usage, >>>> > a slightly cooler running machine, and a cessation of kernel panics. >>>> > >>>> > Your situation seems to be slightly different and logging in remotely >>>> > during a lockup, or better still before, from another system may glean >>>> > some useful information as I found that my log files simply didn't >>>> > contain anything useful. >>>> > >>>> > dafr >>>> > _______________________________________________ >>>> > PLUG mailing list >>>> > PLUG@lists.pdxlinux.org >>>> > http://lists.pdxlinux.org/mailman/listinfo/plug >>>> > >>>> _______________________________________________ >>>> PLUG mailing list >>>> PLUG@lists.pdxlinux.org >>>> http://lists.pdxlinux.org/mailman/listinfo/plug >>>> >>> >>> >> > _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
