All of lore.kernel.org
 help / color / mirror / Atom feed
* sleeping function called from invalid context
@ 2003-09-09 15:03 Samuel Flory
  2003-09-09 19:47 ` Matt Mackall
  0 siblings, 1 reply; 7+ messages in thread
From: Samuel Flory @ 2003-09-09 15:03 UTC (permalink / raw)
  To: linux-kernel

  I'm seeing this on arjanv's 2.6.0-0.test4.1.33 kernel.

Debug: sleeping function called from invalid context at 
include/asm/uaccess.h:473
Call Trace:
 [<c011b7dd>] __might_sleep+0x5d/0x70
 [<c010d0ea>] save_v86_state+0x6a/0x200
 [<c010c8b5>] do_IRQ+0xd5/0x110
 [<c010acd2>] work_notifysig_v86+0x6/0x14
 [<c010ac7f>] syscall_call+0x7/0xb

Debug: sleeping function called from invalid context at 
include/asm/uaccess.h:473
Call Trace:
 [<c011b7dd>] __might_sleep+0x5d/0x70
 [<c010d0ea>] save_v86_state+0x6a/0x200
 [<c010bba0>] do_general_protection+0x0/0xb0
 [<c010acd2>] work_notifysig_v86+0x6/0x14
 [<c010ac7f>] syscall_call+0x7/0xb


  Any thoughts.  The system seems to function despite the issue.  It 
seems to have also occurred under 2.6.0-0.test3.1.31:
Aug 25 16:28:49 goblin kernel: Call Trace:
Aug 25 16:28:49 goblin kernel:  [<c011af2d>] __might_sleep+0x5d/0x70
Aug 25 16:28:49 goblin kernel:  [<c010d06a>] save_v86_state+0x6a/0x200
Aug 25 16:28:49 goblin kernel:  [<c010bb50>] do_general_protection+0x0/0xb0
Aug 25 16:28:49 goblin kernel:  [<c010ac82>] work_notifysig_v86+0x6/0x14
Aug 25 16:28:49 goblin kernel:  [<c010ac2f>] syscall_call+0x7/0xb
Aug 25 16:28:49 goblin kernel:
Aug 25 16:28:50 goblin kernel: Debug: sleeping function called from 
invalid cont
ext at include/asm/uaccess.h:473
Aug 25 16:28:50 goblin kernel: Call Trace:
Aug 25 16:28:50 goblin kernel:  [<c011af2d>] __might_sleep+0x5d/0x70
Aug 25 16:28:50 goblin kernel:  [<c010d06a>] save_v86_state+0x6a/0x200
Aug 25 16:28:50 goblin kernel:  [<c010bb50>] do_general_protection+0x0/0xb0
Aug 25 16:28:50 goblin kernel:  [<c010ac82>] work_notifysig_v86+0x6/0x14
Aug 25 16:28:50 goblin kernel:  [<c010ac2f>] syscall_call+0x7/0xb
Aug 25 16:28:50 goblin kernel:
Aug 25 16:28:51 goblin kernel: Debug: sleeping function called from 
invalid cont
ext at include/asm/uaccess.h:473
Aug 25 16:28:51 goblin kernel: Call Trace:
Aug 25 16:28:51 goblin kernel:  [<c011af2d>] __might_sleep+0x5d/0x70
Aug 25 16:28:51 goblin kernel:  [<c010d06a>] save_v86_state+0x6a/0x200
Aug 25 16:28:51 goblin kernel:  [<c010c865>] do_IRQ+0xd5/0x110
Aug 25 16:28:51 goblin kernel:  [<c010ac82>] work_notifysig_v86+0x6/0x14
Aug 25 16:28:51 goblin kernel:  [<c010ac2f>] syscall_call+0x7/0xb

-- 
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory  <sflory@rackable.com>



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: sleeping function called from invalid context
  2003-09-09 15:03 Samuel Flory
@ 2003-09-09 19:47 ` Matt Mackall
  2003-09-09 20:10   ` Samuel Flory
  0 siblings, 1 reply; 7+ messages in thread
From: Matt Mackall @ 2003-09-09 19:47 UTC (permalink / raw)
  To: Samuel Flory; +Cc: linux-kernel

On Tue, Sep 09, 2003 at 08:03:01AM -0700, Samuel Flory wrote:
>  I'm seeing this on arjanv's 2.6.0-0.test4.1.33 kernel.

> Debug: sleeping function called from invalid context at 
> include/asm/uaccess.h:473
> Call Trace:
> [<c011b7dd>] __might_sleep+0x5d/0x70
> [<c010d0ea>] save_v86_state+0x6a/0x200

It's a warning about the possibility of hitting a very old but rarely
hit bug, system should work the same as it always has despite the
warning. I'm working on this, but it's ugly. Hope to post a patch in
the next week or so.

-- 
Matt Mackall : http://www.selenic.com : of or relating to the moon

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: sleeping function called from invalid context
  2003-09-09 19:47 ` Matt Mackall
@ 2003-09-09 20:10   ` Samuel Flory
  0 siblings, 0 replies; 7+ messages in thread
From: Samuel Flory @ 2003-09-09 20:10 UTC (permalink / raw)
  To: Matt Mackall; +Cc: linux-kernel

Matt Mackall wrote:

>On Tue, Sep 09, 2003 at 08:03:01AM -0700, Samuel Flory wrote:
>  
>
>> I'm seeing this on arjanv's 2.6.0-0.test4.1.33 kernel.
>>    
>>
>
>  
>
>>Debug: sleeping function called from invalid context at 
>>include/asm/uaccess.h:473
>>Call Trace:
>>[<c011b7dd>] __might_sleep+0x5d/0x70
>>[<c010d0ea>] save_v86_state+0x6a/0x200
>>    
>>
>
>It's a warning about the possibility of hitting a very old but rarely
>hit bug, system should work the same as it always has despite the
>warning. I'm working on this, but it's ugly. Hope to post a patch in
>the next week or so.
>
>  
>

  That's good to know.  I was actually running for at least a on an 
older kernel before i noticed in in dmesg.

-- 
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory  <sflory@rackable.com>



^ permalink raw reply	[flat|nested] 7+ messages in thread

* sleeping function called from invalid context
@ 2006-09-11  8:50 Neil Bird
  0 siblings, 0 replies; 7+ messages in thread
From: Neil Bird @ 2006-09-11  8:50 UTC (permalink / raw)
  To: linux-acpi


   Not entirely sure this is the correct place for this, but Google didn't 
show up anything obviously better.


   I'm trying to add functionality to a kernel module which processes 
various input from Sony Vaio laptops (brightness and the Fn keys) by reading 
from ACPI.  This originally did the ACPI reads during a /proc entry read 
(user driven).

   I'm now trying to drive this read automatically by catching key press 
events and using that as a trigger.

   However, in the input event callback, and also (as another attempt) in a 
tasklet process/callback the necessary call 'acpi_evaluate_object()' fails 
with an error “sleeping function called from invalid context”.

   The kernel trace suggests this is something to do with a kmalloc() under 
a variant of the acpi read that involves having a 'relative ACPI path' (the 
string names of the registers (?) are 4-chars, not fully qualified†);  I'm 
afraid I forget the exact function called by acpi_evaluate_object() that's 
listed.


   Does anyone know the rules for when acpi_evaluate_object() can be called, 
or maybe suggest another way of getting the data?  (please bear in mind I 
know little of ACPI!).  I tried to determine the full path in case the call 
worked in that context;  it looked like it ought to be something like 
_SB.xxx.xxx.GBRT instead of GBRT, and I can find this sort of hierarchy 
under acpi under /sys but I *can't* find the actual fields I want (e.g., 
GBRT) listed, even though they work (I may well be mis-interpreting this 
/sys tree).

   This is on Fedora Core 5, kernel 2.6.17-1.2174_FC5.

-- 
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: sleeping function called from invalid context
  2011-05-10  9:32 ` Alan Cox
  2011-05-11  8:43     ` Amit Virdi
@ 2011-05-11  8:43     ` Amit Virdi
  0 siblings, 0 replies; 7+ messages in thread
From: Amit Virdi @ 2011-05-11  8:43 UTC (permalink / raw)
  To: Alan Cox
  Cc: samuel@sortiz.org, Armando VISCONTI, linux-kernel@vger.kernel.org,
	Shiraz HASHIM, linux-input@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org

Hey Alan,

On 5/10/2011 3:02 PM, Alan Cox wrote:
>> On analysis, I found that this is due to the change introduced in
>> tty_ioctl.c where the termios mutex is taken to protect against
>> parallel throttle/unthrottle. Probably IrCOMM stack code wasn't
>> tested before merging this patch.
>>
>> Please suggest what should be done with the IrCOMM protocol stack
>> code to resolve this problem?
>
> It looks like the comments are wrong
>
>          /*
>           * Just give it over to the line discipline. There is no need to
>           * involve the flip buffers, since we are not running in an
>          interrupt
>           * handler
>           */
>
>
> appears to be completely untrue
>
> I suspect it just needs to use the tty_flip_buffer functions properly
> instead of trying to do clever shortcuts
>
>
> 	tty_insert_flip_string(self->tty, skb->data, skb->len);
> 	tty_flip_buffer_push(self->tty);
>
> .
>

I incorporated the change suggested by you and tested the stack again. 
It is working perfectly fine - no stack trace is printed now. I'll be 
sending the patch soon.

Thanks n Regards
Amit Virdi

^ permalink raw reply	[flat|nested] 7+ messages in thread

* sleeping function called from invalid context
@ 2011-05-11  8:43     ` Amit Virdi
  0 siblings, 0 replies; 7+ messages in thread
From: Amit Virdi @ 2011-05-11  8:43 UTC (permalink / raw)
  To: linux-arm-kernel

Hey Alan,

On 5/10/2011 3:02 PM, Alan Cox wrote:
>> On analysis, I found that this is due to the change introduced in
>> tty_ioctl.c where the termios mutex is taken to protect against
>> parallel throttle/unthrottle. Probably IrCOMM stack code wasn't
>> tested before merging this patch.
>>
>> Please suggest what should be done with the IrCOMM protocol stack
>> code to resolve this problem?
>
> It looks like the comments are wrong
>
>          /*
>           * Just give it over to the line discipline. There is no need to
>           * involve the flip buffers, since we are not running in an
>          interrupt
>           * handler
>           */
>
>
> appears to be completely untrue
>
> I suspect it just needs to use the tty_flip_buffer functions properly
> instead of trying to do clever shortcuts
>
>
> 	tty_insert_flip_string(self->tty, skb->data, skb->len);
> 	tty_flip_buffer_push(self->tty);
>
> .
>

I incorporated the change suggested by you and tested the stack again. 
It is working perfectly fine - no stack trace is printed now. I'll be 
sending the patch soon.

Thanks n Regards
Amit Virdi

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: sleeping function called from invalid context
@ 2011-05-11  8:43     ` Amit Virdi
  0 siblings, 0 replies; 7+ messages in thread
From: Amit Virdi @ 2011-05-11  8:43 UTC (permalink / raw)
  To: Alan Cox
  Cc: linux-input@vger.kernel.org, samuel@sortiz.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Shiraz HASHIM, Armando VISCONTI,
	Viresh KUMAR

Hey Alan,

On 5/10/2011 3:02 PM, Alan Cox wrote:
>> On analysis, I found that this is due to the change introduced in
>> tty_ioctl.c where the termios mutex is taken to protect against
>> parallel throttle/unthrottle. Probably IrCOMM stack code wasn't
>> tested before merging this patch.
>>
>> Please suggest what should be done with the IrCOMM protocol stack
>> code to resolve this problem?
>
> It looks like the comments are wrong
>
>          /*
>           * Just give it over to the line discipline. There is no need to
>           * involve the flip buffers, since we are not running in an
>          interrupt
>           * handler
>           */
>
>
> appears to be completely untrue
>
> I suspect it just needs to use the tty_flip_buffer functions properly
> instead of trying to do clever shortcuts
>
>
> 	tty_insert_flip_string(self->tty, skb->data, skb->len);
> 	tty_flip_buffer_push(self->tty);
>
> .
>

I incorporated the change suggested by you and tested the stack again. 
It is working perfectly fine - no stack trace is printed now. I'll be 
sending the patch soon.

Thanks n Regards
Amit Virdi

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2011-05-11 16:18 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-11  8:50 sleeping function called from invalid context Neil Bird
  -- strict thread matches above, loose matches on Subject: below --
2011-05-10  5:38 BUG: " Amit Virdi
2011-05-10  9:32 ` Alan Cox
2011-05-11  8:43   ` Amit Virdi
2011-05-11  8:43     ` Amit Virdi
2011-05-11  8:43     ` Amit Virdi
2003-09-09 15:03 Samuel Flory
2003-09-09 19:47 ` Matt Mackall
2003-09-09 20:10   ` Samuel Flory

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.