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:
quoted text
> 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
>>
>
--
unsubscribe notice
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/