Re: [GIT PULL] time.c - respin

[Glauber Costa]

On Thu, Aug 21, 2008 at 12:22:22PM +0200, Ingo Molnar wrote:
> 
> * Glauber Costa <gcosta@xxxxxxxxxx> wrote:
> 
> > Ingo, please pull the latest master git tree from:
> > 
> >    git://git.kernel.org/pub/scm/linux/kernel/git/glommer/linux-2.6-x86-integration.git master
> > 
> > into your tree. It solves a bisectability issue, but I can't, 
> > unfortunately, reproduce the problem you report. So hopefuly you'll 
> > now be able to bisect your problems to a point we can find out what's 
> > going on
> 
> i've tried it, and -tip testing found a hang on 64-bit x86.
> 
> It hangs here:
> 
> [    0.340029] calling  tc_filter_init+0x0/0x4c
> [    0.340029] initcall tc_filter_init+0x0/0x4c returned 0 after 0 msecs
> [    0.340029] calling  genl_init+0x0/0xd8
> [ hard hang ]
> 
> it should have continued with:
> 
> [    2.976346] initcall genl_init+0x0/0xd8 returned 0 after 15 msecs
> [    2.982303] calling  cipso_v4_init+0x0/0x88
> [ ... etc ... ]
> 
> i've bisected the hang back to:
> 
> 0de577d0dd2d1101431d3438d0880fa32a6188d6 is first bad commit
> commit 0de577d0dd2d1101431d3438d0880fa32a6188d6
> Author: Glauber Costa <gcosta@xxxxxxxxxx>
> Date:   Fri Jul 11 15:43:19 2008 -0300
> 
>     x86: use generic intr_init call
> 
>     Replace apic initialization code with generic intr_init_hook().
> 
>     Signed-off-by: Glauber Costa <gcosta@xxxxxxxxxx>
> 
> the config is at:
> 
>  http://redhat.com/~mingo/misc/config-Thu_Aug_21_11_14_36_CEST_2008.bad
> 
> but the bug is rather obvious:
> 
> -       apic_intr_init();
> -
> -       if (!acpi_ioapic)
> -               setup_irq(2, &irq2);
> +       intr_init_hook();
> 
> why exactly did you remove the cascade IRQ registration? If it remains 
> unallocated and a driver happens to use it funny things might occur.
> 
> Also, the commit log does not declare why it's removed.

Because it's not (was not supposed to be) removed. It used to be done by
intr_init_hook(), so we're just using the same function for both architectures.
Commit 2ae111cdd8d83ebf9de72e36e68a8c84b6ebbeea changed this behaviour without
me noticing (and my tests didn't hit it)

It this is the way things gonna stay, so we'd probably want to drop this patch
completely. Can you remove it cleanly, or it triggers dependency problems?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/