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:
quoted text
> 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
>>>
>>
>