Red Hat Bugzilla – Bug 237903
BUG: using smp_processor_id() in vprintk control path
Last modified: 2008-02-27 14:57:28 EST
Found the following in dmesg:
BUG: using smp_processor_id() in preemptible  code: insmod/405
caller is vprintk+0x284/0x30e
| preempt count: 00000001 ]
| 1-level deep critical section nesting:
.. [<ffffffff803516c1>] .... debug_smp_processor_id+0x90/0xf1
.....[<ffffffff80294315>] .. ( <= vprintk+0x284/0x30e)
If this is a customer issue, please indicate the impact to the customer:
Not yet :)
Provide output from "uname -a", if possible:
Linux llm38.in.ibm.com 2.6.19-rt8 #1 SMP PREEMPT Sun Apr 15 17:11:13 IST 2007
x86_64 x86_64 x86_64 GNU/Linux
Machine type (p650, x235, SF2, etc.): LS20
Cpu type (Power4, Power5, IA-64, etc.): Dual Core AMD Opteron(tm) Processor 275
Is this reproducible? Yes
If so, how long does it (did it) take to reproduce it? the bootlog has the
Describe the steps: No steps needed
Is the system (not just the application) hung? No
This issue has been fixed in 2.6.20-rt8. Trying with
kernel-rt-2.6.21-0143.rc6rt0.x86_64.rpm to confirm.
I have verified that kernel kernel-rt-2.6.21-0143.rc6rt0.x86_64.rpm does not
have this BUG. the bug was initially reported on
Raising mirror request to track back porting the change from
kernel-rt-2.6.21-0143.rc6rt0.x86_64.rpm to kernel-rt-2.6.20-0119.rt8.x86_64.rpm
We are likely to soon be rebasing to 2.6.21. So no need to knock ourselves out
with the backport. For this reason, not currently assigning and intending to
close when we shift over to 21.
----- Additional Comments From firstname.lastname@example.org (prefers email at email@example.com) 2007-04-30 03:12 EDT -------
So, we will close this bug once the rebase to 2.6.21 is done!
ok, just for book-keeping purposes, I'm setting this to NEEDINFO state, just to
mark that we will wait for your confirmation that its addressed in the .21
kernel and you'll close then.
----- Additional Comments From firstname.lastname@example.org (prefers email at email@example.com) 2007-05-14 03:58 EDT -------
Checked the dmesg from a 2.6.21 rt kernel and did not find this issue. This has
been fixed in this kernel and guess this bug can be closed now.