[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080319200931.GA1525@linux-os.sc.intel.com>
Date: Wed, 19 Mar 2008 13:09:31 -0700
From: Venki Pallipadi <venkatesh.pallipadi@...el.com>
To: Pavel Machek <pavel@....cz>
Cc: Venki Pallipadi <venkatesh.pallipadi@...el.com>,
Len Brown <lenb@...nel.org>, "Rafael J. Wysocki" <rjw@...k.pl>,
Miklos Szeredi <miklos@...redi.hu>, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: ACPI lockdep warning on boot, 2.6.25-rc5
On Sat, Mar 15, 2008 at 02:16:11PM +0100, Pavel Machek wrote:
> Hi!
>
> > @@ -421,7 +423,9 @@
> > else
> > acpi_safe_halt();
> >
> > - local_irq_enable();
> > + if (irqs_disabled())
> > + local_irq_enable();
> > +
> > return;
> > }
> >
> > @@ -530,7 +534,9 @@
> > * skew otherwise.
> > */
> > sleep_ticks = 0xFFFFFFFF;
> > - local_irq_enable();
> > + if (irqs_disabled())
> > + local_irq_enable();
> > +
> > break;
> >
> > case ACPI_STATE_C2:
>
> That's pretty ugly. Could the code be modified to have interrupt
> consistent at this point?
>
Agreed that this is not very clean. The problem is that we cannot be sure
about the interrupt state at this point as the low level idle handlers at
this point can come from variety of different places like safe_halt, arch
dependent pm_idle code (which is different for (32 and 64 bit at this point)
and also pm_idle can be somewhere outside the kernel in some module as it is
a function pointer.
Thanks,
Venki
--
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