[-mmotm] BUG: scheduling while atomic: swapper

[-mmotm] BUG: scheduling while atomic: swapper

[Ryan Hope]

BUG: scheduling while atomic: swapper/1/0x00000002
Modules linked in:
Pid: 1, comm: swapper Tainted: G        W 2.6.27-rc4-zenmmotm1 #4
 [<c057a0c7>] schedule+0x287/0x6d0
 [<c03672e6>] vsnprintf+0x3a6/0x6c0
 [<c057a92d>] schedule_timeout+0x7d/0xb0
 [<c021e0c8>] __wake_up+0x38/0x50
 [<c057a74a>] wait_for_common+0x8a/0x130
 [<c0220ab0>] default_wake_function+0x0/0x10
 [<c0237743>] call_usermodehelper_exec+0xc3/0xf0
 [<c0362ede>] kobject_uevent_env+0x37e/0x3a0
 [<c03d5921>] device_add+0x551/0x630
 [<c03d5ac3>] device_create_vargs+0xb3/0xd0
 [<c06ccc47>] microcode_intel_module_init+0x0/0x39
 [<c03d5b0b>] device_create+0x2b/0x30
 [<c0385f2e>] misc_register+0xbe/0x170
 [<c02137d1>] microcode_init+0x21/0xf0
 [<c0201336>] do_one_initcall+0x26/0x170
 [<c021e0c8>] __wake_up+0x38/0x50
 [<c0237c98>] insert_work+0x48/0x50
 [<c02380a5>] __queue_work+0x25/0x40
 [<c023812a>] queue_work_on+0x3a/0x50
 [<c06c29bf>] kernel_init+0x170/0x251
 [<c06c284f>] kernel_init+0x0/0x251
 [<c0204157>] kernel_thread_helper+0x7/0x10
 =======================

Re: [-mmotm] BUG: scheduling while atomic: swapper

[Andrew Morton]

On Mon, 25 Aug 2008 22:09:25 -0400 "Ryan Hope" <rmh3093@gmail.com> wrote:

> BUG: scheduling while atomic: swapper/1/0x00000002
> Modules linked in:
> Pid: 1, comm: swapper Tainted: G        W 2.6.27-rc4-zenmmotm1 #4
>  [<c057a0c7>] schedule+0x287/0x6d0
>  [<c03672e6>] vsnprintf+0x3a6/0x6c0
>  [<c057a92d>] schedule_timeout+0x7d/0xb0
>  [<c021e0c8>] __wake_up+0x38/0x50
>  [<c057a74a>] wait_for_common+0x8a/0x130
>  [<c0220ab0>] default_wake_function+0x0/0x10
>  [<c0237743>] call_usermodehelper_exec+0xc3/0xf0
>  [<c0362ede>] kobject_uevent_env+0x37e/0x3a0
>  [<c03d5921>] device_add+0x551/0x630
>  [<c03d5ac3>] device_create_vargs+0xb3/0xd0
>  [<c06ccc47>] microcode_intel_module_init+0x0/0x39
>  [<c03d5b0b>] device_create+0x2b/0x30
>  [<c0385f2e>] misc_register+0xbe/0x170
>  [<c02137d1>] microcode_init+0x21/0xf0
>  [<c0201336>] do_one_initcall+0x26/0x170
>  [<c021e0c8>] __wake_up+0x38/0x50
>  [<c0237c98>] insert_work+0x48/0x50
>  [<c02380a5>] __queue_work+0x25/0x40
>  [<c023812a>] queue_work_on+0x3a/0x50
>  [<c06c29bf>] kernel_init+0x170/0x251
>  [<c06c284f>] kernel_init+0x0/0x251
>  [<c0204157>] kernel_thread_helper+0x7/0x10
>  =======================

As a mad guess, I'd guess that someone changed get_online_cpus() so
that disables preemption (with a suitable config combination, perhaps).
Which would cause microcode_init()'s sysdev_driver_register() to run
in atomic context.

But that's just a guess - I can't immediately see any change in there
which does this.  Ingo, any theories?

Re: [-mmotm] BUG: scheduling while atomic: swapper

[Vegard Nossum]

On Tue, Aug 26, 2008 at 8:37 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Mon, 25 Aug 2008 22:09:25 -0400 "Ryan Hope" <rmh3093@gmail.com> wrote:
>
>> BUG: scheduling while atomic: swapper/1/0x00000002
>> Modules linked in:
>> Pid: 1, comm: swapper Tainted: G        W 2.6.27-rc4-zenmmotm1 #4
>>  [<c057a0c7>] schedule+0x287/0x6d0
>>  [<c03672e6>] vsnprintf+0x3a6/0x6c0
>>  [<c057a92d>] schedule_timeout+0x7d/0xb0
>>  [<c021e0c8>] __wake_up+0x38/0x50
>>  [<c057a74a>] wait_for_common+0x8a/0x130
>>  [<c0220ab0>] default_wake_function+0x0/0x10
>>  [<c0237743>] call_usermodehelper_exec+0xc3/0xf0
>>  [<c0362ede>] kobject_uevent_env+0x37e/0x3a0
>>  [<c03d5921>] device_add+0x551/0x630
>>  [<c03d5ac3>] device_create_vargs+0xb3/0xd0
>>  [<c06ccc47>] microcode_intel_module_init+0x0/0x39
>>  [<c03d5b0b>] device_create+0x2b/0x30
>>  [<c0385f2e>] misc_register+0xbe/0x170
>>  [<c02137d1>] microcode_init+0x21/0xf0
>>  [<c0201336>] do_one_initcall+0x26/0x170
>>  [<c021e0c8>] __wake_up+0x38/0x50
>>  [<c0237c98>] insert_work+0x48/0x50
>>  [<c02380a5>] __queue_work+0x25/0x40
>>  [<c023812a>] queue_work_on+0x3a/0x50
>>  [<c06c29bf>] kernel_init+0x170/0x251
>>  [<c06c284f>] kernel_init+0x0/0x251
>>  [<c0204157>] kernel_thread_helper+0x7/0x10
>>  =======================
>
> As a mad guess, I'd guess that someone changed get_online_cpus() so
> that disables preemption (with a suitable config combination, perhaps).
> Which would cause microcode_init()'s sysdev_driver_register() to run
> in atomic context.
>
> But that's just a guess - I can't immediately see any change in there
> which does this.  Ingo, any theories?

Looks like the kernel was W-tainted already... so likely there was a
BUG or a WARNING even before this. And I think this sort of warning
can happen if a(nother) process was killed while preemption was off
(e.g. a BUG() at the wrong moment). Ryan?


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036

Re: [-mmotm] BUG: scheduling while atomic: swapper

[Dmitry Adamushko]

2008/8/26 Ryan Hope <rmh3093@gmail.com>:
> BUG: scheduling while atomic: swapper/1/0x00000002
> Modules linked in:
> Pid: 1, comm: swapper Tainted: G        W 2.6.27-rc4-zenmmotm1 #4
>  [<c057a0c7>] schedule+0x287/0x6d0
>  [<c03672e6>] vsnprintf+0x3a6/0x6c0
>  [<c057a92d>] schedule_timeout+0x7d/0xb0
>  [<c021e0c8>] __wake_up+0x38/0x50
>  [<c057a74a>] wait_for_common+0x8a/0x130
>  [<c0220ab0>] default_wake_function+0x0/0x10
>  [<c0237743>] call_usermodehelper_exec+0xc3/0xf0
>  [<c0362ede>] kobject_uevent_env+0x37e/0x3a0
>  [<c03d5921>] device_add+0x551/0x630
>  [<c03d5ac3>] device_create_vargs+0xb3/0xd0
>  [<c06ccc47>] microcode_intel_module_init+0x0/0x39

It doesn't look like Linus's tree... there is no
microcode_intel_module_init() in .27+. So what is it?

Anyway, your trace might be explained by a bug that has been already
fixed in Ingo's -tip.

Here is the commit:
http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commit;h=8343ef2437c599d30568e6b5a257a40bf2f4902b


-- 
Best regards,
Dmitry Adamushko

Re: [-mmotm] BUG: scheduling while atomic: swapper

[Andrew Morton]

On Tue, 26 Aug 2008 10:11:24 +0200 "Dmitry Adamushko" <dmitry.adamushko@gmail.com> wrote:

> 2008/8/26 Ryan Hope <rmh3093@gmail.com>:
> > BUG: scheduling while atomic: swapper/1/0x00000002
> > Modules linked in:
> > Pid: 1, comm: swapper Tainted: G        W 2.6.27-rc4-zenmmotm1 #4
> >  [<c057a0c7>] schedule+0x287/0x6d0
> >  [<c03672e6>] vsnprintf+0x3a6/0x6c0
> >  [<c057a92d>] schedule_timeout+0x7d/0xb0
> >  [<c021e0c8>] __wake_up+0x38/0x50
> >  [<c057a74a>] wait_for_common+0x8a/0x130
> >  [<c0220ab0>] default_wake_function+0x0/0x10
> >  [<c0237743>] call_usermodehelper_exec+0xc3/0xf0
> >  [<c0362ede>] kobject_uevent_env+0x37e/0x3a0
> >  [<c03d5921>] device_add+0x551/0x630
> >  [<c03d5ac3>] device_create_vargs+0xb3/0xd0
> >  [<c06ccc47>] microcode_intel_module_init+0x0/0x39
> 
> It doesn't look like Linus's tree... there is no
> microcode_intel_module_init() in .27+. So what is it?

mmotm is linux-next plus -mm stuff

> Anyway, your trace might be explained by a bug that has been already
> fixed in Ingo's -tip.
> 
> Here is the commit:
> http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commit;h=8343ef2437c599d30568e6b5a257a40bf2f4902b

Yes, an unbalanced get_cpu() would explain it.

However that patch is already in current -mm.  Ryan, can you please
check to see if it's in the version you tested?  The "fixed" version
looks like this:

static int __init microcode_intel_module_init(void)
{
	struct cpuinfo_x86 *c = &cpu_data(get_cpu());

	if (c->x86_vendor == X86_VENDOR_INTEL)
		return microcode_init(&microcode_intel_ops, THIS_MODULE);
	else
		return -ENODEV;
}

[-mmotm] BUG: scheduling while atomic: swapper

[james toy]

Andrew,

Yes, ours does look like this -- however when i checked the git diff
on git web i found:

index d2d9d74..6dd8907 100644 (file)
--- a/arch/x86/kernel/microcode_intel.c
+++ b/arch/x86/kernel/microcode_intel.c
@@ -531,12 +531,14 @@ static struct microcode_ops microcode_intel_ops = {

 static int __init microcode_intel_module_init(void)
 {
-       struct cpuinfo_x86 *c = &cpu_data(get_cpu());
+       struct cpuinfo_x86 *c = &cpu_data(0);

-       if (c->x86_vendor == X86_VENDOR_INTEL)
-               return microcode_init(&microcode_intel_ops, THIS_MODULE);
-       else
+       if (c->x86_vendor != X86_VENDOR_INTEL) {
+                printk(KERN_ERR "microcode: CPU platform is not
Intel-capable\n");
                return -ENODEV;
+       }
+
+       return microcode_init(&microcode_intel_ops, THIS_MODULE);
 }

 static void __exit microcode_intel_module_exit(void)

am I missing something?  It seems that the code you requested to be
checked is being nixed in the diff (i could be wrong it is 0500 EST
here)

again to confirm -- we have what you initially posted if that _is_ the
fixed version.

respectfully,

/jT


On Tue, Aug 26, 2008 at 4:24 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> On Tue, 26 Aug 2008 10:11:24 +0200 "Dmitry Adamushko" <dmitry.adamushko@gmail.com> wrote:
>
> > 2008/8/26 Ryan Hope <rmh3093@gmail.com>:
> > > BUG: scheduling while atomic: swapper/1/0x00000002
> > > Modules linked in:
> > > Pid: 1, comm: swapper Tainted: G        W 2.6.27-rc4-zenmmotm1 #4
> > >  [<c057a0c7>] schedule+0x287/0x6d0
> > >  [<c03672e6>] vsnprintf+0x3a6/0x6c0
> > >  [<c057a92d>] schedule_timeout+0x7d/0xb0
> > >  [<c021e0c8>] __wake_up+0x38/0x50
> > >  [<c057a74a>] wait_for_common+0x8a/0x130
> > >  [<c0220ab0>] default_wake_function+0x0/0x10
> > >  [<c0237743>] call_usermodehelper_exec+0xc3/0xf0
> > >  [<c0362ede>] kobject_uevent_env+0x37e/0x3a0
> > >  [<c03d5921>] device_add+0x551/0x630
> > >  [<c03d5ac3>] device_create_vargs+0xb3/0xd0
> > >  [<c06ccc47>] microcode_intel_module_init+0x0/0x39
> >
> > It doesn't look like Linus's tree... there is no
> > microcode_intel_module_init() in .27+. So what is it?
>
> mmotm is linux-next plus -mm stuff
>
> > Anyway, your trace might be explained by a bug that has been already
> > fixed in Ingo's -tip.
> >
> > Here is the commit:
> > http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commit;h=8343ef2437c599d30568e6b5a257a40bf2f4902b
>
> Yes, an unbalanced get_cpu() would explain it.
>
> However that patch is already in current -mm.  Ryan, can you please
> check to see if it's in the version you tested?  The "fixed" version
> looks like this:
>
> static int __init microcode_intel_module_init(void)
> {
>        struct cpuinfo_x86 *c = &cpu_data(get_cpu());
>
>        if (c->x86_vendor == X86_VENDOR_INTEL)
>                return microcode_init(&microcode_intel_ops, THIS_MODULE);
>        else
>                return -ENODEV;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mmotm] BUG: scheduling while atomic: swapper

[Dmitry Adamushko]

2008/8/26 james toy <unk.nown@unix.net>:
> Andrew,
>
> Yes, ours does look like this -- however when i checked the git diff on git
> web i found:
>
> index d2d9d74..6dd8907 100644 (file)
> --- a/arch/x86/kernel/microcode_intel.c
> +++ b/arch/x86/kernel/microcode_intel.c
> @@ -531,12 +531,14 @@ static struct microcode_ops microcode_intel_ops = {
>
>  static int __init microcode_intel_module_init(void)
>  {
> -       struct cpuinfo_x86 *c = &cpu_data(get_cpu());
> +       struct cpuinfo_x86 *c = &cpu_data(0);

(err... I'm a bit confused by the use of "fixed" here. The snippet
posted by Andrew illustrates how it was _before_ the fix,
i.e. it's the version that causes the "scheduling while atomic" bug).

IOW, If your local version has cpu_data(get_cpu()) in
microcode_intel_module_init(), then it explains the trace you have
observed. That also means you are not up-to-date with -next.


-- 
Best regards,
Dmitry Adamushko

Re: [-mmotm] BUG: scheduling while atomic: swapper

[Ryan Hope]

Thanks for getting back to me on this guys.  Yes I am using mmotm, the
daily -mm broken out tree... THe bug happens while booting, and it
shows up many times. Anyway I checked microcode_intel.c and the
function in question looks like this:

static int __init microcode_intel_module_init(void)
{
       struct cpuinfo_x86 *c = &cpu_data(get_cpu());

       if (c->x86_vendor == X86_VENDOR_INTEL)
               return microcode_init(&microcode_intel_ops, THIS_MODULE);
       else
               return -ENODEV;
}

I will try the changes in he patch in Jame's post.... and report back. THanks.

-Ryan

On Tue, Aug 26, 2008 at 6:02 AM, Dmitry Adamushko
<dmitry.adamushko@gmail.com> wrote:
> 2008/8/26 james toy <unk.nown@unix.net>:
>> Andrew,
>>
>> Yes, ours does look like this -- however when i checked the git diff on git
>> web i found:
>>
>> index d2d9d74..6dd8907 100644 (file)
>> --- a/arch/x86/kernel/microcode_intel.c
>> +++ b/arch/x86/kernel/microcode_intel.c
>> @@ -531,12 +531,14 @@ static struct microcode_ops microcode_intel_ops = {
>>
>>  static int __init microcode_intel_module_init(void)
>>  {
>> -       struct cpuinfo_x86 *c = &cpu_data(get_cpu());
>> +       struct cpuinfo_x86 *c = &cpu_data(0);
>
> (err... I'm a bit confused by the use of "fixed" here. The snippet
> posted by Andrew illustrates how it was _before_ the fix,
> i.e. it's the version that causes the "scheduling while atomic" bug).
>
> IOW, If your local version has cpu_data(get_cpu()) in
> microcode_intel_module_init(), then it explains the trace you have
> observed. That also means you are not up-to-date with -next.
>
>
> --
> Best regards,
> Dmitry Adamushko
>

Re: [-mmotm] BUG: scheduling while atomic: swapper

[Ryan Hope]

The patch from james fixes one of the issues, but who ever said my
kernel was already W tainted was right. I still have this other bug
showing in dmesg:

------------[ cut here ]------------
WARNING: at fs/sysfs/dir.c:465 sysfs_add_one+0x4a/0x50()
sysfs: duplicate filename 'acpi' can not be created
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.27-rc4-zenmmotm1 #8
 [<802277af>] warn_slowpath+0x6f/0xa0
 [<80579dd6>] schedule+0x256/0x6d0
 [<80361212>] idr_get_empty_slot+0xe2/0x260
 [<80361410>] ida_get_new_above+0x80/0x1c0
 [<802cd390>] sysfs_ilookup_test+0x0/0x10
 [<802cd6f1>] sysfs_find_dirent+0x21/0x30
 [<802cd7a0>] __sysfs_add_one+0x10/0x90
 [<802cd86a>] sysfs_add_one+0x4a/0x50
 [<802ce64c>] create_dir+0x4c/0xb0
 [<802ce6d9>] sysfs_create_dir+0x29/0x50
 [<80361e2f>] kobject_get+0xf/0x20
 [<80361f7d>] kobject_add_internal+0xcd/0x1c0
 [<803620fa>] kobject_set_name_vargs+0x3a/0x50
 [<80362309>] kobject_init_and_add+0x29/0x30
 [<806d235d>] kernel_param_sysfs_setup+0x5d/0xb8
 [<806d2525>] param_sysfs_init+0x16d/0x172
 [<806d23b8>] param_sysfs_init+0x0/0x172
 [<80201336>] do_one_initcall+0x26/0x170
 [<8021d87c>] activate_task+0x2c/0x50
 [<80220a00>] pre_schedule_rt+0x0/0x30
 [<80238547>] __create_workqueue_key+0x1a7/0x1f0
 [<80237c00>] worker_thread+0x0/0x100
 [<806c09bf>] kernel_init+0x170/0x251
 [<806c084f>] kernel_init+0x0/0x251
 [<80204157>] kernel_thread_helper+0x7/0x10
 =======================
---[ end trace 4eaa2a86a8e2da22 ]---
kobject_add_internal failed for acpi with -EEXIST, don't try to register things
with the same name in the same directory.
Pid: 1, comm: swapper Tainted: G        W 2.6.27-rc4-zenmmotm1 #8
 [<80361fc2>] kobject_add_internal+0x112/0x1c0
 [<80362309>] kobject_init_and_add+0x29/0x30
 [<806d235d>] kernel_param_sysfs_setup+0x5d/0xb8
 [<806d2525>] param_sysfs_init+0x16d/0x172
 [<806d23b8>] param_sysfs_init+0x0/0x172
 [<80201336>] do_one_initcall+0x26/0x170
 [<8021d87c>] activate_task+0x2c/0x50
 [<80220a00>] pre_schedule_rt+0x0/0x30
 [<80238547>] __create_workqueue_key+0x1a7/0x1f0
 [<80237c00>] worker_thread+0x0/0x100
 [<806c09bf>] kernel_init+0x170/0x251
 [<806c084f>] kernel_init+0x0/0x251
 [<80204157>] kernel_thread_helper+0x7/0x10
 =======================


On Tue, Aug 26, 2008 at 10:15 AM, Ryan Hope <rmh3093@gmail.com> wrote:
> Thanks for getting back to me on this guys.  Yes I am using mmotm, the
> daily -mm broken out tree... THe bug happens while booting, and it
> shows up many times. Anyway I checked microcode_intel.c and the
> function in question looks like this:
>
> static int __init microcode_intel_module_init(void)
> {
>       struct cpuinfo_x86 *c = &cpu_data(get_cpu());
>
>       if (c->x86_vendor == X86_VENDOR_INTEL)
>               return microcode_init(&microcode_intel_ops, THIS_MODULE);
>       else
>               return -ENODEV;
> }
>
> I will try the changes in he patch in Jame's post.... and report back. THanks.
>
> -Ryan
>
> On Tue, Aug 26, 2008 at 6:02 AM, Dmitry Adamushko
> <dmitry.adamushko@gmail.com> wrote:
>> 2008/8/26 james toy <unk.nown@unix.net>:
>>> Andrew,
>>>
>>> Yes, ours does look like this -- however when i checked the git diff on git
>>> web i found:
>>>
>>> index d2d9d74..6dd8907 100644 (file)
>>> --- a/arch/x86/kernel/microcode_intel.c
>>> +++ b/arch/x86/kernel/microcode_intel.c
>>> @@ -531,12 +531,14 @@ static struct microcode_ops microcode_intel_ops = {
>>>
>>>  static int __init microcode_intel_module_init(void)
>>>  {
>>> -       struct cpuinfo_x86 *c = &cpu_data(get_cpu());
>>> +       struct cpuinfo_x86 *c = &cpu_data(0);
>>
>> (err... I'm a bit confused by the use of "fixed" here. The snippet
>> posted by Andrew illustrates how it was _before_ the fix,
>> i.e. it's the version that causes the "scheduling while atomic" bug).
>>
>> IOW, If your local version has cpu_data(get_cpu()) in
>> microcode_intel_module_init(), then it explains the trace you have
>> observed. That also means you are not up-to-date with -next.
>>
>>
>> --
>> Best regards,
>> Dmitry Adamushko
>>
>

Re: [-mmotm] BUG: scheduling while atomic: swapper

[Ryan Hope]

[-- Attachment #1: Type: text/plain, Size: 4495 bytes --]

On a side note, if I have CONFIG_HIGHMEM4G=y my computer boots fine if
CONFIG_HIGHMEM4G=n I get the bugtrace shown in the attached photo
(sorry for the poor quality its the best i could do atm). The kernel
also hardlocks at this point.
-Ryan


On Tue, Aug 26, 2008 at 10:53 AM, Ryan Hope <rmh3093@gmail.com> wrote:
> The patch from james fixes one of the issues, but who ever said my
> kernel was already W tainted was right. I still have this other bug
> showing in dmesg:
>
> ------------[ cut here ]------------
> WARNING: at fs/sysfs/dir.c:465 sysfs_add_one+0x4a/0x50()
> sysfs: duplicate filename 'acpi' can not be created
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 2.6.27-rc4-zenmmotm1 #8
>  [<802277af>] warn_slowpath+0x6f/0xa0
>  [<80579dd6>] schedule+0x256/0x6d0
>  [<80361212>] idr_get_empty_slot+0xe2/0x260
>  [<80361410>] ida_get_new_above+0x80/0x1c0
>  [<802cd390>] sysfs_ilookup_test+0x0/0x10
>  [<802cd6f1>] sysfs_find_dirent+0x21/0x30
>  [<802cd7a0>] __sysfs_add_one+0x10/0x90
>  [<802cd86a>] sysfs_add_one+0x4a/0x50
>  [<802ce64c>] create_dir+0x4c/0xb0
>  [<802ce6d9>] sysfs_create_dir+0x29/0x50
>  [<80361e2f>] kobject_get+0xf/0x20
>  [<80361f7d>] kobject_add_internal+0xcd/0x1c0
>  [<803620fa>] kobject_set_name_vargs+0x3a/0x50
>  [<80362309>] kobject_init_and_add+0x29/0x30
>  [<806d235d>] kernel_param_sysfs_setup+0x5d/0xb8
>  [<806d2525>] param_sysfs_init+0x16d/0x172
>  [<806d23b8>] param_sysfs_init+0x0/0x172
>  [<80201336>] do_one_initcall+0x26/0x170
>  [<8021d87c>] activate_task+0x2c/0x50
>  [<80220a00>] pre_schedule_rt+0x0/0x30
>  [<80238547>] __create_workqueue_key+0x1a7/0x1f0
>  [<80237c00>] worker_thread+0x0/0x100
>  [<806c09bf>] kernel_init+0x170/0x251
>  [<806c084f>] kernel_init+0x0/0x251
>  [<80204157>] kernel_thread_helper+0x7/0x10
>  =======================
> ---[ end trace 4eaa2a86a8e2da22 ]---
> kobject_add_internal failed for acpi with -EEXIST, don't try to register things
> with the same name in the same directory.
> Pid: 1, comm: swapper Tainted: G        W 2.6.27-rc4-zenmmotm1 #8
>  [<80361fc2>] kobject_add_internal+0x112/0x1c0
>  [<80362309>] kobject_init_and_add+0x29/0x30
>  [<806d235d>] kernel_param_sysfs_setup+0x5d/0xb8
>  [<806d2525>] param_sysfs_init+0x16d/0x172
>  [<806d23b8>] param_sysfs_init+0x0/0x172
>  [<80201336>] do_one_initcall+0x26/0x170
>  [<8021d87c>] activate_task+0x2c/0x50
>  [<80220a00>] pre_schedule_rt+0x0/0x30
>  [<80238547>] __create_workqueue_key+0x1a7/0x1f0
>  [<80237c00>] worker_thread+0x0/0x100
>  [<806c09bf>] kernel_init+0x170/0x251
>  [<806c084f>] kernel_init+0x0/0x251
>  [<80204157>] kernel_thread_helper+0x7/0x10
>  =======================
>
>
> On Tue, Aug 26, 2008 at 10:15 AM, Ryan Hope <rmh3093@gmail.com> wrote:
>> Thanks for getting back to me on this guys.  Yes I am using mmotm, the
>> daily -mm broken out tree... THe bug happens while booting, and it
>> shows up many times. Anyway I checked microcode_intel.c and the
>> function in question looks like this:
>>
>> static int __init microcode_intel_module_init(void)
>> {
>>       struct cpuinfo_x86 *c = &cpu_data(get_cpu());
>>
>>       if (c->x86_vendor == X86_VENDOR_INTEL)
>>               return microcode_init(&microcode_intel_ops, THIS_MODULE);
>>       else
>>               return -ENODEV;
>> }
>>
>> I will try the changes in he patch in Jame's post.... and report back. THanks.
>>
>> -Ryan
>>
>> On Tue, Aug 26, 2008 at 6:02 AM, Dmitry Adamushko
>> <dmitry.adamushko@gmail.com> wrote:
>>> 2008/8/26 james toy <unk.nown@unix.net>:
>>>> Andrew,
>>>>
>>>> Yes, ours does look like this -- however when i checked the git diff on git
>>>> web i found:
>>>>
>>>> index d2d9d74..6dd8907 100644 (file)
>>>> --- a/arch/x86/kernel/microcode_intel.c
>>>> +++ b/arch/x86/kernel/microcode_intel.c
>>>> @@ -531,12 +531,14 @@ static struct microcode_ops microcode_intel_ops = {
>>>>
>>>>  static int __init microcode_intel_module_init(void)
>>>>  {
>>>> -       struct cpuinfo_x86 *c = &cpu_data(get_cpu());
>>>> +       struct cpuinfo_x86 *c = &cpu_data(0);
>>>
>>> (err... I'm a bit confused by the use of "fixed" here. The snippet
>>> posted by Andrew illustrates how it was _before_ the fix,
>>> i.e. it's the version that causes the "scheduling while atomic" bug).
>>>
>>> IOW, If your local version has cpu_data(get_cpu()) in
>>> microcode_intel_module_init(), then it explains the trace you have
>>> observed. That also means you are not up-to-date with -next.
>>>
>>>
>>> --
>>> Best regards,
>>> Dmitry Adamushko
>>>
>>
>

[-- Attachment #2: sspx0176.jpg --]
[-- Type: image/jpeg, Size: 183877 bytes --]