In the old times, the whole idle task was considered
as an RCU quiescent state. But as RCU became more and
more successful overtime, some RCU read side critical
section have been added even in the code of some
architectures idle tasks, for tracing for example.
So nowadays, rcu_idle_enter() and rcu_idle_exit() must
be called by the architecture to tell RCU about the part
in the idle loop that doesn't make use of rcu read side
critical sections, typically the part that puts the CPU
in low power mode.
This is necessary for RCU to find the quiescent states in
idle in order to complete grace periods.
Add this missing pair of calls in the Alpha's idle loop.
Reported-by: Paul E. McKenney <redacted>
Signed-off-by: Frederic Weisbecker <redacted>
Cc: Richard Henderson <redacted>
Cc: Ivan Kokshaysky <redacted>
Cc: Matt Turner <mattst88@gmail.com>
Cc: alpha <redacted>
Cc: Paul E. McKenney <redacted>
Cc: Michael Cree <redacted>
Cc: 3.2.x.. <redacted>
---
arch/alpha/kernel/process.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
@@ -54,9 +55,11 @@ cpu_idle(void)/* FIXME -- EV6 and LCA45 know how to power downtheCPU.*/+rcu_idle_enter();while(!need_resched())cpu_relax();+rcu_idle_exit();schedule_preempt_disabled();}}
cpu_idle() is called on the boot CPU by the init code with
preemption disabled. But the cpu_idle() function in alpha
doesn't handle this when it calls schedule() directly.
Fix it by converting it into schedule_preempt_disabled().
Also disable preemption before calling cpu_idle() from
secondary CPU entry code to stay consistent with this
state.
Signed-off-by: Frederic Weisbecker <redacted>
Cc: Richard Henderson<redacted>
Cc: Ivan Kokshaysky <redacted>
Cc: Matt Turner <mattst88@gmail.com>
Cc: alpha <redacted>
Cc: Paul E. McKenney <redacted>
Cc: Michael Cree <redacted>
---
arch/alpha/kernel/process.c | 3 ++-
arch/alpha/kernel/smp.c | 1 +
2 files changed, 3 insertions(+), 1 deletions(-)
@@ -166,6 +166,7 @@ smp_callin(void)DBGS(("smp_callin: commencing CPU %d current %p active_mm %p\n",cpuid,current,current->active_mm));+preempt_disable();/* Do nothing. */cpu_idle();}
From: Paul E. McKenney <hidden> Date: 2012-08-24 21:27:48
On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
Hi,
Changes since v1:
- Fixed preempt handling in alpha idle loop
- added ack from Geert
- fixed stable email address, sorry :-/
This time I built tested everywhere but: h8300 (compiler internal error),
and mn10300, parisc, score (cross compilers not available in
ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
For testing, you can pull from:
git://github.com/fweisbec/linux-dynticks.git
rcu/idle-fix-v2
Thanks.
I have queued these on -rcu branch rcu/idle:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
This problem has been in place since 3.3, so it is hard to argue that
it is a regression for this merge window. I have therefore queued it
for 3.7.
Thanx, Paul
From: Ben Hutchings <hidden> Date: 2012-08-25 01:20:14
On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
quoted
Hi,
Changes since v1:
- Fixed preempt handling in alpha idle loop
- added ack from Geert
- fixed stable email address, sorry :-/
This time I built tested everywhere but: h8300 (compiler internal error),
and mn10300, parisc, score (cross compilers not available in
ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
For testing, you can pull from:
git://github.com/fweisbec/linux-dynticks.git
rcu/idle-fix-v2
Thanks.
I have queued these on -rcu branch rcu/idle:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
This problem has been in place since 3.3, so it is hard to argue that
it is a regression for this merge window. I have therefore queued it
for 3.7.
I don't follow that; I would expect any serious bug fix (serious enough
for a stable update) to be acceptable for 3.6 at this point.
If the regression occurred in 3.3, then the cc lines should be something
like:
Cc: [off-list ref] # 3.3+
and not the current:
Cc: 3.2.x.. [off-list ref]
(Note, version annotations should be on the right of the address, not in
the 'real name' position on the left.)
Ben.
--
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones.
From: Michael Cree <hidden> Date: 2012-08-25 02:10:26
On 25/08/12 13:19, Ben Hutchings wrote:
On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
quoted
On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
quoted
Hi,
Changes since v1:
- Fixed preempt handling in alpha idle loop
- added ack from Geert
- fixed stable email address, sorry :-/
This time I built tested everywhere but: h8300 (compiler internal error),
and mn10300, parisc, score (cross compilers not available in
ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
For testing, you can pull from:
git://github.com/fweisbec/linux-dynticks.git
rcu/idle-fix-v2
Thanks.
I have queued these on -rcu branch rcu/idle:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
This problem has been in place since 3.3, so it is hard to argue that
it is a regression for this merge window. I have therefore queued it
for 3.7.
I don't follow that; I would expect any serious bug fix (serious enough
for a stable update) to be acceptable for 3.6 at this point.
If the regression occurred in 3.3, then the cc lines should be something
like:
Cc: [off-list ref] # 3.3+
and not the current:
Cc: 3.2.x.. [off-list ref]
The Alpha patches fix an even earlier regression resulting in RCU CPU
stalls on an SMP kernel built for generic Alpha (which includes the
current Debian 3.2-alpha-smp kernel) and renders the kernel pretty much
unuseable. I've only tested the two alpha patches together but maybe
just the first patch (1/11 alpha: Fix preemption handling in idle loop)
might be needed to fix the problem in 3.2. I'll test and let you know.
Cheers
Michael.
From: Paul E. McKenney <hidden> Date: 2012-08-25 03:51:31
On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote:
On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
quoted
On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
quoted
Hi,
Changes since v1:
- Fixed preempt handling in alpha idle loop
- added ack from Geert
- fixed stable email address, sorry :-/
This time I built tested everywhere but: h8300 (compiler internal error),
and mn10300, parisc, score (cross compilers not available in
ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
For testing, you can pull from:
git://github.com/fweisbec/linux-dynticks.git
rcu/idle-fix-v2
Thanks.
I have queued these on -rcu branch rcu/idle:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
This problem has been in place since 3.3, so it is hard to argue that
it is a regression for this merge window. I have therefore queued it
for 3.7.
I don't follow that; I would expect any serious bug fix (serious enough
for a stable update) to be acceptable for 3.6 at this point.
OK, if any of the arch maintainers wishes to submit the patch to 3.6,
they are free to do so -- just let me know and I will drop the patch from
my tree.
That said, all this does is cause spurious warnings to be printed, so
not sure it really qualifies as serious. But I am happy to leave that
decision with the individual arch maintainers -- it is their arch,
after all, so their decision.
Thanx, Paul
If the regression occurred in 3.3, then the cc lines should be something
like:
Cc: [off-list ref] # 3.3+
and not the current:
Cc: 3.2.x.. [off-list ref]
(Note, version annotations should be on the right of the address, not in
the 'real name' position on the left.)
On Fri, Aug 24, 2012 at 08:50:47PM -0700, Paul E. McKenney wrote:
On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote:
quoted
On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
quoted
On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
quoted
Hi,
Changes since v1:
- Fixed preempt handling in alpha idle loop
- added ack from Geert
- fixed stable email address, sorry :-/
This time I built tested everywhere but: h8300 (compiler internal error),
and mn10300, parisc, score (cross compilers not available in
ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
For testing, you can pull from:
git://github.com/fweisbec/linux-dynticks.git
rcu/idle-fix-v2
Thanks.
I have queued these on -rcu branch rcu/idle:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
This problem has been in place since 3.3, so it is hard to argue that
it is a regression for this merge window. I have therefore queued it
for 3.7.
I don't follow that; I would expect any serious bug fix (serious enough
for a stable update) to be acceptable for 3.6 at this point.
OK, if any of the arch maintainers wishes to submit the patch to 3.6,
they are free to do so -- just let me know and I will drop the patch from
my tree.
That said, all this does is cause spurious warnings to be printed, so
not sure it really qualifies as serious. But I am happy to leave that
decision with the individual arch maintainers -- it is their arch,
after all, so their decision.
Couldn't that cause hung tasks due to long lasting synchronize_rcu() ?
From: Paul E. McKenney <hidden> Date: 2012-08-25 16:18:36
On Sat, Aug 25, 2012 at 03:16:49PM +0200, Frederic Weisbecker wrote:
On Fri, Aug 24, 2012 at 08:50:47PM -0700, Paul E. McKenney wrote:
quoted
On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote:
quoted
On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
quoted
On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
quoted
Hi,
Changes since v1:
- Fixed preempt handling in alpha idle loop
- added ack from Geert
- fixed stable email address, sorry :-/
This time I built tested everywhere but: h8300 (compiler internal error),
and mn10300, parisc, score (cross compilers not available in
ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
For testing, you can pull from:
git://github.com/fweisbec/linux-dynticks.git
rcu/idle-fix-v2
Thanks.
I have queued these on -rcu branch rcu/idle:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
This problem has been in place since 3.3, so it is hard to argue that
it is a regression for this merge window. I have therefore queued it
for 3.7.
I don't follow that; I would expect any serious bug fix (serious enough
for a stable update) to be acceptable for 3.6 at this point.
OK, if any of the arch maintainers wishes to submit the patch to 3.6,
they are free to do so -- just let me know and I will drop the patch from
my tree.
That said, all this does is cause spurious warnings to be printed, so
not sure it really qualifies as serious. But I am happy to leave that
decision with the individual arch maintainers -- it is their arch,
after all, so their decision.
Couldn't that cause hung tasks due to long lasting synchronize_rcu() ?
In theory, definitely. In practice, they haven't been running into it,
or they would be reporting hangs.
Thanx, Paul
From: Michael Cree <hidden> Date: 2012-08-25 21:15:35
On 26/08/12 04:18, Paul E. McKenney wrote:
On Sat, Aug 25, 2012 at 03:16:49PM +0200, Frederic Weisbecker wrote:
quoted
On Fri, Aug 24, 2012 at 08:50:47PM -0700, Paul E. McKenney wrote:
quoted
On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote:
quoted
On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
quoted
On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
quoted
Hi,
Changes since v1:
- Fixed preempt handling in alpha idle loop
- added ack from Geert
- fixed stable email address, sorry :-/
This time I built tested everywhere but: h8300 (compiler internal error),
and mn10300, parisc, score (cross compilers not available in
ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
For testing, you can pull from:
git://github.com/fweisbec/linux-dynticks.git
rcu/idle-fix-v2
Thanks.
I have queued these on -rcu branch rcu/idle:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
This problem has been in place since 3.3, so it is hard to argue that
it is a regression for this merge window. I have therefore queued it
for 3.7.
I don't follow that; I would expect any serious bug fix (serious enough
for a stable update) to be acceptable for 3.6 at this point.
OK, if any of the arch maintainers wishes to submit the patch to 3.6,
they are free to do so -- just let me know and I will drop the patch from
my tree.
That said, all this does is cause spurious warnings to be printed, so
not sure it really qualifies as serious. But I am happy to leave that
decision with the individual arch maintainers -- it is their arch,
after all, so their decision.
Couldn't that cause hung tasks due to long lasting synchronize_rcu() ?
In theory, definitely. In practice, they haven't been running into it,
or they would be reporting hangs.
I am hereby reporting that RCU CPU stall warnings and hung tasks are
being experienced on SMP kernels built for generic Alpha. This problem
dates back quite a few kernel releases. The discussed patches appear to
fix the problem.
A backport to the 3.2 kernel, of at least the Alpha patches, would be
very much appreciated! :-)
Cheers
Michael.
From: Paul E. McKenney <hidden> Date: 2012-08-26 00:12:47
On Sun, Aug 26, 2012 at 09:15:27AM +1200, Michael Cree wrote:
On 26/08/12 04:18, Paul E. McKenney wrote:
quoted
On Sat, Aug 25, 2012 at 03:16:49PM +0200, Frederic Weisbecker wrote:
quoted
On Fri, Aug 24, 2012 at 08:50:47PM -0700, Paul E. McKenney wrote:
quoted
On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote:
quoted
On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
quoted
On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
quoted
Hi,
Changes since v1:
- Fixed preempt handling in alpha idle loop
- added ack from Geert
- fixed stable email address, sorry :-/
This time I built tested everywhere but: h8300 (compiler internal error),
and mn10300, parisc, score (cross compilers not available in
ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
For testing, you can pull from:
git://github.com/fweisbec/linux-dynticks.git
rcu/idle-fix-v2
Thanks.
I have queued these on -rcu branch rcu/idle:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
This problem has been in place since 3.3, so it is hard to argue that
it is a regression for this merge window. I have therefore queued it
for 3.7.
I don't follow that; I would expect any serious bug fix (serious enough
for a stable update) to be acceptable for 3.6 at this point.
OK, if any of the arch maintainers wishes to submit the patch to 3.6,
they are free to do so -- just let me know and I will drop the patch from
my tree.
That said, all this does is cause spurious warnings to be printed, so
not sure it really qualifies as serious. But I am happy to leave that
decision with the individual arch maintainers -- it is their arch,
after all, so their decision.
Couldn't that cause hung tasks due to long lasting synchronize_rcu() ?
In theory, definitely. In practice, they haven't been running into it,
or they would be reporting hangs.
I am hereby reporting that RCU CPU stall warnings and hung tasks are
being experienced on SMP kernels built for generic Alpha. This problem
dates back quite a few kernel releases. The discussed patches appear to
fix the problem.
OK, fair enough.
A backport to the 3.2 kernel, of at least the Alpha patches, would be
very much appreciated! :-)
Both Alpha patches should apply as-is back to 3.3, and should also fix
the problem. Could you please check this on the versions of interest?
If you are seeing something like this on 3.2 or earlier, you have some
other problem that needs to be tracked down separately.
Thanx, Paul
Both Alpha patches should apply as-is back to 3.3, and should also fix
the problem. Could you please check this on the versions of interest?
I just now tried them on top of 3.3.8 from linux-stable.git.
While they apply cleanly, I get a compile failure:
CC arch/alpha/kernel/process.o
arch/alpha/kernel/process.c: In function 'cpu_idle':
arch/alpha/kernel/process.c:64: error: implicit declaration of function 'schedule_preempt_disabled'
make[1]: *** [arch/alpha/kernel/process.o] Error 1
make: *** [arch/alpha/kernel] Error 2
AFAICT, schedule_preempt_disabled() was only introduced in 3.4
and thus needs to be backported for 3.3.
Regards,
Tobias
--
panic("%s: CORRUPTED BTREE OR SOMETHING", __FUNCTION__);
linux-2.6.6/fs/xfs/xfs_bmap.c
On Sun, Aug 26, 2012 at 11:21:37AM +0200, Tobias Klausmann wrote:
Hi!
On Sat, 25 Aug 2012, Paul E. McKenney wrote:
quoted
Both Alpha patches should apply as-is back to 3.3, and should also fix
the problem. Could you please check this on the versions of interest?
I just now tried them on top of 3.3.8 from linux-stable.git.
While they apply cleanly, I get a compile failure:
CC arch/alpha/kernel/process.o
arch/alpha/kernel/process.c: In function 'cpu_idle':
arch/alpha/kernel/process.c:64: error: implicit declaration of function 'schedule_preempt_disabled'
make[1]: *** [arch/alpha/kernel/process.o] Error 1
make: *** [arch/alpha/kernel] Error 2
AFAICT, schedule_preempt_disabled() was only introduced in 3.4
and thus needs to be backported for 3.3.
Please try with this instead:
preempt_enable_no_resched();
schedule();
preempt_disable();
Thanks.
Regards,
Tobias
--
panic("%s: CORRUPTED BTREE OR SOMETHING", __FUNCTION__);
linux-2.6.6/fs/xfs/xfs_bmap.c
On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote:
On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
quoted
On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
quoted
Hi,
Changes since v1:
- Fixed preempt handling in alpha idle loop
- added ack from Geert
- fixed stable email address, sorry :-/
This time I built tested everywhere but: h8300 (compiler internal error),
and mn10300, parisc, score (cross compilers not available in
ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
For testing, you can pull from:
git://github.com/fweisbec/linux-dynticks.git
rcu/idle-fix-v2
Thanks.
I have queued these on -rcu branch rcu/idle:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
This problem has been in place since 3.3, so it is hard to argue that
it is a regression for this merge window. I have therefore queued it
for 3.7.
I don't follow that; I would expect any serious bug fix (serious enough
for a stable update) to be acceptable for 3.6 at this point.
If the regression occurred in 3.3, then the cc lines should be something
like:
Cc: [off-list ref] # 3.3+
and not the current:
Cc: 3.2.x.. [off-list ref]
(Note, version annotations should be on the right of the address, not in
the 'real name' position on the left.)
Ah indeed.
Hmm, I don't understand why we took that convention while we can reuse the name
that precedes the email to put that information.
Anyway, should I resend the patchset with this thing fixed?
Thanks.
From: Paul E. McKenney <hidden> Date: 2012-09-10 22:59:12
On Mon, Sep 10, 2012 at 11:56:08PM +0200, Frederic Weisbecker wrote:
On Sat, Aug 25, 2012 at 02:19:14AM +0100, Ben Hutchings wrote:
quoted
On Fri, 2012-08-24 at 14:26 -0700, Paul E. McKenney wrote:
quoted
On Thu, Aug 23, 2012 at 04:58:24PM +0200, Frederic Weisbecker wrote:
quoted
Hi,
Changes since v1:
- Fixed preempt handling in alpha idle loop
- added ack from Geert
- fixed stable email address, sorry :-/
This time I built tested everywhere but: h8300 (compiler internal error),
and mn10300, parisc, score (cross compilers not available in
ftp://ftp.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/)
For testing, you can pull from:
git://github.com/fweisbec/linux-dynticks.git
rcu/idle-fix-v2
Thanks.
I have queued these on -rcu branch rcu/idle:
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
This problem has been in place since 3.3, so it is hard to argue that
it is a regression for this merge window. I have therefore queued it
for 3.7.
I don't follow that; I would expect any serious bug fix (serious enough
for a stable update) to be acceptable for 3.6 at this point.
If the regression occurred in 3.3, then the cc lines should be something
like:
Cc: [off-list ref] # 3.3+
and not the current:
Cc: 3.2.x.. [off-list ref]
(Note, version annotations should be on the right of the address, not in
the 'real name' position on the left.)
Ah indeed.
Hmm, I don't understand why we took that convention while we can reuse the name
that precedes the email to put that information.
Anyway, should I resend the patchset with this thing fixed?
On Mon, Sep 10, 2012 at 03:58:45PM -0700, Paul E. McKenney wrote:
quoted
Anyway, should I resend the patchset with this thing fixed?
Please feel free to do so. ;-)
Thanx, Paul
So here it is.
On the menu for the updated branch:
- fixed stable tags (use # 3.3+)
- not sure what to do with "alpha: Fix preemption handling in idle loop",
tag as stable or not?
- added tested-by Michael Cree [off-list ref] for alpha patches
- propagate rename to rcu_user_*_after_irq() in the commit changelog
- remove trailing #endif in "rcu: New rcu_user_enter_after_irq() and rcu_user_exit_after_irq() APIs"
and early rcu_user_hooks_switch() header as well (reported by WU Fenguang).
- add rcu_user_hooks_switch() header in "rcu: Switch task's syscall hooks on context switch"
I believe this all should also fix what WU Fenguang reported:
[rcu:rcu:next 54/82] include/linux/rcupdate.h:202:20: error: redefinition of 'rcu_user_exit'
[rcu:rcu:next 54/82] include/linux/rcupdate.h:401:19: error: redefinition of 'rcu_read_lock_bh_held'
[rcu:rcu:idle 2/27] include/linux/rcupdate.h:969:2: error: #endif without #if
I'm not reposting the patches because few things have actually changed, except a few neats and some stuff
that have been moved from a patch to another to unbreak bisection. But the end result is about the same.
You can check the difference with a git diff between our branches.
If you want to, though, I can repost the patches.
This is pullable from:
git://github.com/fweisbec/linux-dynticks.git
rcu/idle-for-v3.7
Thanks.
Hi!
On Mon, 10 Sep 2012, Frederic Weisbecker wrote:
quoted
AFAICT, schedule_preempt_disabled() was only introduced in 3.4
and thus needs to be backported for 3.3.
Please try with this instead:
preempt_enable_no_resched();
schedule();
preempt_disable();
Thanks.
While it does compile, it hits the usual Alpha snag (3.3 onwards)
on boot:
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffffffffff]
pci 0000:00:11.0: quirk: [io 0x4000-0x403f] claimed by ali7101 ACPI
pci 0000:00:11.0: quirk: [io 0x5000-0x501f] claimed by ali7101 SMB
Unable to handle kernel paging request at virtual address 0000000000000000
swapper(1): Oops 1
pc = [<fffffc00008667bc>] ra = [<fffffc0000866794>] ps = 0000 Not tainted
pc is at nautilus_init_pci+0xd4/0x218
ra is at nautilus_init_pci+0xac/0x218
v0 = 0000000000000001 t0 = 0000000000000000 t1 = 000000000000ffff
t2 = 00000000ffffffff t3 = fffffc0000896810 t4 = 0000000001000000
t5 = 0000000000080000 t6 = 000000000fffffff t7 = fffffc00bf890000
s0 = fffffc00bf8b4800 s1 = 0000000000ffffff s2 = 000000000007fffa
s3 = 0000000000000000 s4 = 0000000000000000 s5 = 0000000000002ab5
s6 = 5800000000000701
a0 = fffffc0000896b88 a1 = 0000000000000000 a2 = 0000000000000000
a3 = 000000000e000000 a4 = 0000000002000000 a5 = 0000000000000001
t8 = 0000000000000000 t9 = 0000000000000000 t10= 0000000000000001
t11= 0000000000000000 pv = fffffc000032bdc0 at = 000000000d0e4600
gp = fffffc00008e34a8 sp = fffffc00bf893e28
Disabling lock debugging due to kernel taint
Trace:
[<fffffc0000310088>] do_one_initcall+0x38/0x200
[<fffffc0000311338>] kernel_thread+0x28/0x90
This is not an RCU problem, though. AFAICT.
I tried the patches with 3.2.28 (the latest vanilla kernel that
works on this machine _at all_) but those don't have an RCU
implementation and thus, the compile fails:
CC arch/alpha/kernel/process.o
arch/alpha/kernel/process.c: In function 'cpu_idle':
arch/alpha/kernel/process.c:59: error: implicit declaration of function 'rcu_idle_enter'
arch/alpha/kernel/process.c:63: error: implicit declaration of function 'rcu_idle_exit'
make[1]: *** [arch/alpha/kernel/process.o] Error 1
make: *** [arch/alpha/kernel] Error 2
Regards,
Tobias