[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48f7fe350808260753v132fad91g6bd2e7b36f9bbcb6@mail.gmail.com>
Date: Tue, 26 Aug 2008 10:53:03 -0400
From: "Ryan Hope" <rmh3093@...il.com>
To: "Dmitry Adamushko" <dmitry.adamushko@...il.com>
Cc: "james toy" <unk.nown@...x.net>,
"Andrew Morton" <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
"Vegard Nossum" <vegard.nossum@...il.com>
Subject: Re: [-mmotm] BUG: scheduling while atomic: swapper
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@...il.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(µcode_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@...il.com> wrote:
>> 2008/8/26 james toy <unk.nown@...x.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
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists