[opensuse] Hpet issues again
This morning I opened the laptop lid to start work, and it was sooooooooo sloooooow it took 10 minutes to open a menu. Had to reboot. After reboot I used Journalctl to view the prior boot and noticed that there was a kernel oops just after resume, (nul pointer dereference at ~00001, followed by an abbreviated stack, and call trace etc. DWARF2 Unwinder stuck at some syscall-yada-fastpath And finally hpet increased min_delta_ns to 152745, which is higher than I've ever seen it set. I haven't had hpet issues on this machine for over 5 years. Opensuse 42.2, 4.4.62-18.6-default #1 SMP x86_64. Completely up to date. What would cause such a thing? -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/07/2017 07:13 PM, John Andersen wrote:
What would cause such a thing?
This looks like an actual bug in the resume (or sleep) code:
nul pointer dereference at ~00001
Yikes. That's way down at the bottom of the system reserved memory range. It looks like something is getting passed as a value (1 or some uninitialized value) where an address was expected and then whatever variable holds the value is dereferenced. (essentially evaluating something like *(int *)1; or (on x86) int a, *b = (int *)a; if(*b){}, or something similar) Something is off somewhere, by either a level of indirection or is uninitialized altogether... The only thing you can do (absent some function name following in journalctl after the oops) is file a bug with what you describe in your e-mail and provide what log you were able to find. I don't have a clue what part of the kernel or X code provides or interfaces with the sleep/hibernate functions. I'm not even sure your hpet relation is more a cause or a symptom in this case. Unless the timer code is actually to blame, it is probably just an innocent bystander. Hopefully somebody else here knows better and can help narrow down what else to check or include in the bug report. Good luck with this one buddy.... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/07/2017 09:21 PM, David C. Rankin wrote:
On 06/07/2017 07:13 PM, John Andersen wrote:
What would cause such a thing?
This looks like an actual bug in the resume (or sleep) code:
nul pointer dereference at ~00001
Yikes. That's way down at the bottom of the system reserved memory range. It looks like something is getting passed as a value (1 or some uninitialized value) where an address was expected and then whatever variable holds the value is dereferenced. (essentially evaluating something like *(int *)1; or (on x86) int a, *b = (int *)a; if(*b){}, or something similar) Something is off somewhere, by either a level of indirection or is uninitialized altogether...
The only thing you can do (absent some function name following in journalctl after the oops) is file a bug with what you describe in your e-mail and provide what log you were able to find.
I don't have a clue what part of the kernel or X code provides or interfaces with the sleep/hibernate functions. I'm not even sure your hpet relation is more a cause or a symptom in this case. Unless the timer code is actually to blame, it is probably just an innocent bystander.
Hopefully somebody else here knows better and can help narrow down what else to check or include in the bug report.
Good luck with this one buddy....
I did save the journatctl segment that included all the details, the back trace and the name of the module involved. I've put the machine through several suspend / resume cycles since and have not had any re-occurrence of the slow down. However I did notice an Oops this morning which occurred after I open the lid. The only symptom is in Journalctl, no outward indication that it had happened. The RIP was in a different module I think I will run some memory tests and suspend resume sequences and watch this for a while before I start submitting it. Also, are there any Official kernels for 42.2 other than 4.4.62-18.6-default? It seems a tad long in the tooth. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* John Andersen <jsamyth@gmail.com> [06-08-17 14:01]: [...]
I think I will run some memory tests and suspend resume sequences and watch this for a while before I start submitting it.
Also, are there any Official kernels for 42.2 other than 4.4.62-18.6-default? It seems a tad long in the tooth.
zypper se -sx kernel-default -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/08/2017 01:01 PM, John Andersen wrote:
I did save the journatctl segment that included all the details, the back trace and the name of the module involved.
I've put the machine through several suspend / resume cycles since and have not had any re-occurrence of the slow down.
However I did notice an Oops this morning which occurred after I open the lid. The only symptom is in Journalctl, no outward indication that it had happened. The RIP was in a different module
I think I will run some memory tests and suspend resume sequences and watch this for a while before I start submitting it.
You know, This could be something as wonky as a 'processor state' -- as the processor itself wakes up. You would think that hardware is bullet-proof, but with that many transistors crammed onto a piece of silicon, there is a chance something isn't waking up correctly from a low-power state (or whatever they are technically called). If there is something that expects to read a value from the processor that isn't behaving correctly, that may play into it as well. (Recall how well the new Pentium did math?) It may be worth a couple of processor model-specific searches to see if anything pops up. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
David C. Rankin -
John Andersen -
Patrick Shanahan