public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
* RE: 2.6.17-mm1 - possible recursive locking detected
@ 2006-06-22  4:28 Brown, Len
  2006-06-22  4:59 ` Andrew Morton
  0 siblings, 1 reply; 11+ messages in thread
From: Brown, Len @ 2006-06-22  4:28 UTC (permalink / raw)
  To: Michal Piotrowski, Andrew Morton, Ingo Molnar, Arjan van de Ven
  Cc: linux-kernel, linux-acpi, Moore, Robert

>It looks like an ACPI problem.

Thanks for the note, and the .config, I reproduced it here.

CONFIG_LOCKDEP complains about this sequence:

...
	<presumed previous acquire/release acpi_gbl_hardware_lock>
...
acpi_ev_gpe_detect()
	spin_lock_irqsave(acpi_gbl_gpe_lock,)

	spin_lock_irqsave(acpi_gbl_hardware_lock,) <stack trace is on
this acquire>
	spin_lock_irqrestore(acpi_gbl_hardware_lock,)

	...

	spin_lock_irqrestore(acpi_gbl_gpe_lock)

It complains about this only the 1st time, even though
this same code sequence runs for every (subsequent) ACPI interrupt.

The intent of the arrangement is that acpi_gbl_hardware_lock is for very
small critical sections around RMW hardware register access.
It can be acquired with or without other locks held, but
nothing else is acquired when it is held.

Nothing jumps out at me as incorrect above, so 
at this point it looks like a CONFIG_LOCKDEP artifact --
but lets ask the experts:-)

-Len


>Setting up standard PCI resources
>=============================================
>[ INFO: possible recursive locking detected ]
>---------------------------------------------
>idle/1 is trying to acquire lock:
> (lock_ptr){....}, at: [<c021cbd2>] acpi_os_acquire_lock+0x8/0xa
>
>but task is already holding lock:
> (lock_ptr){....}, at: [<c021cbd2>] acpi_os_acquire_lock+0x8/0xa
>
>other info that might help us debug this:
>1 lock held by idle/1:
> #0:  (lock_ptr){....}, at: [<c021cbd2>] acpi_os_acquire_lock+0x8/0xa
>
>stack backtrace:
> [<c0103e89>] show_trace+0xd/0x10
> [<c0104483>] dump_stack+0x19/0x1b
> [<c01395fa>] __lock_acquire+0x7d9/0xa50
> [<c0139a98>] lock_acquire+0x71/0x91
> [<c02f0beb>] _spin_lock_irqsave+0x2c/0x3c
> [<c021cbd2>] acpi_os_acquire_lock+0x8/0xa
> [<c0222d95>] acpi_ev_gpe_detect+0x4d/0x10e
> [<c02215c3>] acpi_ev_sci_xrupt_handler+0x15/0x1d
> [<c021c8b1>] acpi_irq+0xe/0x18
> [<c014d36e>] request_irq+0xbe/0x10c
> [<c021cf33>] acpi_os_install_interrupt_handler+0x59/0x87
> [<c02215e7>] acpi_ev_install_sci_handler+0x1c/0x21
> [<c0220d41>] acpi_ev_install_xrupt_handlers+0x9/0x50
> [<c0231772>] acpi_enable_subsystem+0x7d/0x9a
> [<c0416656>] acpi_init+0x3f/0x170
> [<c01003ae>] _stext+0x116/0x26c
> [<c0101005>] kernel_thread_helper+0x5/0xb
>ACPI: Interpreter enabled
>
>Here is a dmesg log 
>http://www.stardust.webpages.pl/files/mm/2.6.17-mm1/mm-dmesg
>Here is a config file
>http://www.stardust.webpages.pl/files/mm/2.6.17-mm1/mm-config
>
>Regards,
>Michal
>
>-- 
>Michal K. K. Piotrowski
>LTG - Linux Testers Group
>(http://www.stardust.webpages.pl/ltg/wiki/)
>

^ permalink raw reply	[flat|nested] 11+ messages in thread
* RE: [patch] ACPI: reduce code size, clean up, fix validator message
@ 2006-06-22  8:00 Brown, Len
  2006-06-25 19:54 ` Ingo Molnar
  2006-06-26 16:35 ` Pavel Machek
  0 siblings, 2 replies; 11+ messages in thread
From: Brown, Len @ 2006-06-22  8:00 UTC (permalink / raw)
  To: Ingo Molnar, Andrew Morton
  Cc: michal.k.k.piotrowski, arjan, linux-kernel, linux-acpi,
	Moore, Robert, Arjan van de Ven

Ingo,
Thanks for the quick reply.

An Andrew's advice a while back, Bob already got rid
of the allocate part -- it just isn't upstream yet.

Re: changing ACPICA code (sub-directories of drivers/acpi/) like this:

>-	flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
>+	spin_lock_irqsave(&acpi_gbl_gpe_lock, flags);

I can't do that without either
1. diverging between Linux and ACPICA
or
2. getting a license back from you to Intel such that Intel can
   re-distrubute such a change under the Intel license on the file
   and
   inventing spin_lock_irqsave() on about 9 other operating systems.

#1 is all pain and no gain, unless the 244 net fewer bytes counts as
gain.
#2 wouldn't make sense either.

If this code were performance or size critical, I would still delete
acpi_os_acquire_lock from osl.c, but would inline it in aclinux.h.

thanks,
-Len

^ permalink raw reply	[flat|nested] 11+ messages in thread
* RE: [patch] ACPI: reduce code size, clean up, fix validator message
@ 2006-06-26 17:39 Brown, Len
  2006-06-26 19:59 ` Ingo Molnar
  0 siblings, 1 reply; 11+ messages in thread
From: Brown, Len @ 2006-06-26 17:39 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Ingo Molnar, Andrew Morton, michal.k.k.piotrowski, arjan,
	linux-kernel, linux-acpi, Moore, Robert, Arjan van de Ven

 
>Well, gain here is that code actually becomes readable/linux
>like/something.
>
>Feel free to put GPL/BSD license in ACPICA code, saying that by
>default contributed code is under both licenses.... or something, but
>having linux-like code under drivers/acpi would be great.

There is drivers/acpi/*.c
This is pure GPL and can be as "Linux like" as any purist wants it to
be.
Indeed, we have several patches in the queue to do just that in 2.6.18.

and there is drivers/acpi/*/*.c, which is from ACPICA.
Linux, along with a bunch of other OS's, is downstream.

The license on ACPICA is not the issue.   
The issue is when we make a syntax change to ACPICA in Linux,
then it adds to (my) workload to keep Linux up to date with the upstream
ACPICA.

(note that the previous Linux/ACPI maintainer dealt with this issue
 by simply over-writing the ACPICA files in Linux upon every update.
 I allow divergence, but I have to track it, it causes merge conflicts,
 and Bob and I actively work to change ACPICA upstream to minimize it.)

If you have specific feedback on what can be improved,
I'm certainly willing to listen.  As you may be aware,
I translate every ACPICA change into Linux format, and
it is possible that this process can be enhanced.

Keep in perspective, however, that we have over 200
functional issues unresolved in bugzilla.kernel.org,
and spending time on syntax changes is generally
a lower priority.

-Len

^ permalink raw reply	[flat|nested] 11+ messages in thread
* RE: [patch] ACPI: reduce code size, clean up, fix validator message
@ 2006-06-26 20:42 Moore, Robert
  0 siblings, 0 replies; 11+ messages in thread
From: Moore, Robert @ 2006-06-26 20:42 UTC (permalink / raw)
  To: Brown, Len, Pavel Machek
  Cc: Ingo Molnar, Andrew Morton, michal.k.k.piotrowski, arjan,
	linux-kernel, linux-acpi, Arjan van de Ven

Everyone should keep in mind that eventually, the ACPICA code can be
fully integrated into each host operating system and then maintained by
the individual OS projects.

During the time that Intel is actively developing and supporting the
ACPICA code, we need the OS-independent interfaces to provide
portability across the dozen or so host operating systems that are
currently supported.

Yes, of course there is some inefficiency in not using the native OS
interfaces. However, this is really the only sane way to support so many
different hosts, and all OS projects get the benefit of debugging help
and feedback from the many different operating systems.

Bob


> -----Original Message-----
> From: Brown, Len
> Sent: Monday, June 26, 2006 10:40 AM
> To: Pavel Machek
> Cc: Ingo Molnar; Andrew Morton; michal.k.k.piotrowski@gmail.com;
> arjan@linux.intel.com; linux-kernel@vger.kernel.org; linux-
> acpi@vger.kernel.org; Moore, Robert; Arjan van de Ven
> Subject: RE: [patch] ACPI: reduce code size, clean up, fix validator
> message
> 
> 
> >Well, gain here is that code actually becomes readable/linux
> >like/something.
> >
> >Feel free to put GPL/BSD license in ACPICA code, saying that by
> >default contributed code is under both licenses.... or something, but
> >having linux-like code under drivers/acpi would be great.
> 
> There is drivers/acpi/*.c
> This is pure GPL and can be as "Linux like" as any purist wants it to
be.
> Indeed, we have several patches in the queue to do just that in
2.6.18.
> 
> and there is drivers/acpi/*/*.c, which is from ACPICA.
> Linux, along with a bunch of other OS's, is downstream.
> 
> The license on ACPICA is not the issue.
> The issue is when we make a syntax change to ACPICA in Linux,
> then it adds to (my) workload to keep Linux up to date with the
upstream
> ACPICA.
> 
> (note that the previous Linux/ACPI maintainer dealt with this issue
>  by simply over-writing the ACPICA files in Linux upon every update.
>  I allow divergence, but I have to track it, it causes merge
conflicts,
>  and Bob and I actively work to change ACPICA upstream to minimize
it.)
> 
> If you have specific feedback on what can be improved,
> I'm certainly willing to listen.  As you may be aware,
> I translate every ACPICA change into Linux format, and
> it is possible that this process can be enhanced.
> 
> Keep in perspective, however, that we have over 200
> functional issues unresolved in bugzilla.kernel.org,
> and spending time on syntax changes is generally
> a lower priority.
> 
> -Len

^ permalink raw reply	[flat|nested] 11+ messages in thread
* RE: [patch] ACPI: reduce code size, clean up, fix validator message
@ 2006-06-26 21:58 Brown, Len
  0 siblings, 0 replies; 11+ messages in thread
From: Brown, Len @ 2006-06-26 21:58 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Pavel Machek, Andrew Morton, michal.k.k.piotrowski, arjan,
	linux-kernel, linux-acpi, Moore, Robert, Arjan van de Ven

 
>( for example the ACPI practice of allocating opaque 'handler' 
> pointers that carry no type at [they are void *] is playing with fire.
It in 
> essence disables the remaining little bit of type-safety 
> that C has. )

I agree 100%.

-Len

^ permalink raw reply	[flat|nested] 11+ messages in thread
end of thread, other threads:[~2006-06-26 22:02 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-22  4:28 2.6.17-mm1 - possible recursive locking detected Brown, Len
2006-06-22  4:59 ` Andrew Morton
2006-06-22  7:20   ` [patch] ACPI: reduce code size, clean up, fix validator message Ingo Molnar
2006-06-22 14:31     ` Michal Piotrowski
  -- strict thread matches above, loose matches on Subject: below --
2006-06-22  8:00 Brown, Len
2006-06-25 19:54 ` Ingo Molnar
2006-06-26 16:35 ` Pavel Machek
2006-06-26 17:39 Brown, Len
2006-06-26 19:59 ` Ingo Molnar
2006-06-26 20:42 Moore, Robert
2006-06-26 21:58 Brown, Len

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox