Cross-posting from kernel bugzilla:
===
Definitely not a kernel bug.
I've replaced RAM module with another one and the issue went away.
No idea why oopses refered to ACPI, but they seem to be the result of simple
hardware incompatibility.
===
On Tuesday 18 November 2014 21:07:51 Oleksandr Nata
Hmmm, weird, acpi=off as well as disabling ASPM and NMI watchdog didn't help :
(.
Now trying to update BIOS.
P.S. Still affected while using 3.17.2 kernel.
On Tuesday 11 November 2014 12:41:18 Oleksandr Natalenko wrote:
> It seems that this bug has nothing to do with acpi-cpufreq code but with
>
It seems that this bug has nothing to do with acpi-cpufreq code but with
another ACPI area.
With ACPI enabled kernel may hang in a day or in a week (never survived more
than approx. 2 weeks). With acpi=off it seems to work OK. For instance, I had
to boot Ubuntu installer with acpi disabled to f
Also I've found similar oops report with upstreamed fix (commit
46a310b80bc2c9ccc019649c9da91194cbc10944).
On Wednesday 13 August 2014 08:56:02 Oleksandr Natalenko wrote:
> On Wednesday 13 August 2014 10:02:26 Viresh Kumar wrote:
> > That's why you should have copied the diff here, so that I coul
On Wednesday 13 August 2014 10:02:26 Viresh Kumar wrote:
> That's why you should have copied the diff here, so that I could have
> confirmed if what you have done is correct or not.
You may check my modifications here [1] or attached to this email.
[1] https://gist.github.com/bdcc7d41883b5e077974
On Wednesday 13 August 2014 10:12:06 Viresh Kumar wrote:
> Also will it be possible for you to find the last working kernel after
> which this
> happened?
I'll try to reproduce the issue with older kernels, but that could be
problematic and may take some time. So far, I can say that 3.13 and 3.1
On 13 August 2014 00:24, Oleksandr Natalenko wrote:
> Updated logs.
Also will it be possible for you to find the last working kernel after
which this
happened?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More maj
On 13 August 2014 00:24, Oleksandr Natalenko wrote:
> Updated logs.
>
> Registered notifiers:
>
> ===
> pf@defiant:~$ cat /var/log/kern.log | grep "Registered transition notifier"
> Aug 12 21:50:13 defiant kernel: [3.081759] cpufreq: Registered transition
> notifier: 81590378, (fff
On 12 August 2014 23:48, Oleksandr Natalenko wrote:
> Hmm, looks like I've put pr_info to policy notifier instead of transition
> notifier. Will fix it now and post new logs.
That's why you should have copied the diff here, so that I could have
confirmed if what you have done is correct or not.
-
Updated logs.
Registered notifiers:
===
pf@defiant:~$ cat /var/log/kern.log | grep "Registered transition notifier"
Aug 12 21:50:13 defiant kernel: [3.081759] cpufreq: Registered transition
notifier: 81590378, (81cb0ba0)
===
Triggered notifiers:
===
pf@defiant:~$ dmesg | gr
Hmm, looks like I've put pr_info to policy notifier instead of transition
notifier. Will fix it now and post new logs.
On Tuesday 12 August 2014 21:04:30 Oleksandr Natalenko wrote:
> Well, I've added the following code to cpufreq_register_notifier()
> (drivers/cpufreq/cpufreq.c) to CPUFREQ_TRANSI
Well, I've added the following code to cpufreq_register_notifier()
(drivers/cpufreq/cpufreq.c) to CPUFREQ_TRANSITION_NOTIFIER case:
===
pr_info("Registered transition notifier: %p, (%p)\n", nb->notifier_call, &nb-
>notifier_call);
===
And got the following in my dmesg (only 1 line):
===
$ cat /
On Tue, Aug 12, 2014 at 12:56 PM, Oleksandr Natalenko
wrote:
> Got that and will try to investigate ASAP.
>
> Just to note: I tried to use powersave governor and got the same result. I
> believe notifiers are used with powersave governor as well. Am I wrong?
Notifiers are used from the cpufreq c
Got that and will try to investigate ASAP.
Just to note: I tried to use powersave governor and got the same result. I
believe notifiers are used with powersave governor as well. Am I wrong?
On August 12, 2014 9:16:21 AM EEST, Viresh Kumar
wrote:
>On Tue, Aug 12, 2014 at 11:25 AM, Oleksandr Nat
On Tue, Aug 12, 2014 at 11:25 AM, Oleksandr Natalenko
wrote:
> What should I do to debug it? Is that necessary to recompile kernel with full
> debug?
Yeah, you need to recompile the kernel for sure but not necessarily with debug
support..
Some background:
In cpufreq framework, we manage a CPUs
On Tuesday 12 August 2014 11:22:28 Viresh Kumar wrote:
> Yeah, because this is happening while the notifiers are being served.
> Can you debug it a bit to go to the exact notifier routine where this
> crashes?
What should I do to debug it? Is that necessary to recompile kernel with full
debug?
>
On Fri, Aug 8, 2014 at 2:23 AM, Oleksandr Natalenko
wrote:
> Disabling cpufreq code in kernel config works around this issue.
Yeah, because this is happening while the notifiers are being served.
Can you debug it a bit to go to the exact notifier routine where this crashes?
> Is this bug related
Filled up detailed bugreport on bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=81701
On Thursday 07 August 2014 23:53:17 Oleksandr Natalenko wrote:
> Disabling cpufreq code in kernel config works around this issue.
>
> Is this bug related to sleeping in atomic context, which is caused by
Disabling cpufreq code in kernel config works around this issue.
Is this bug related to sleeping in atomic context, which is caused by improper
GFP_KERNEL usage instead of GFP_ATOMIC? Should I test tat patch, or there will
be another fix?
On Tuesday 05 August 2014 00:39:11 Oleksandr Natalenko w
19 matches
Mail list logo
