* BUG: sleeping function called from invalid context
@ 2011-05-10 5:38 ` Amit Virdi
0 siblings, 0 replies; 13+ messages in thread
From: Amit Virdi @ 2011-05-10 5:38 UTC (permalink / raw)
To: linux-input, samuel, alan
Cc: linux-arm-kernel, linux-kernel, Shiraz HASHIM, Armando VISCONTI,
Viresh KUMAR
Hi
I'm testing the driver, based on Linux Kernel 2.6.37, for DICE's Fast
IrDA controller device. I'm using IrCOMM as the upper IrDA layer and
using PPP over it.
While testing, I'm getting the following backtrace repeatedly:
=====================================
BUG: sleeping function called from invalid context at
/data/csd_sw/spear/drives_os/amitvi/spear/kernel/linux-2.6/kernel/mutex.c:85
in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
Backtrace:
[<c0030b48>] (dump_backtrace+0x0/0x110) from [<c0030c8c>]
(dump_stack+0x18/0x1c)
r6:00000000 r5:c725a038 r4:c042c000
[<c0030c74>] (dump_stack+0x0/0x1c) from [<c003b8b4>]
(__might_sleep+0xc8/0xe8)
[<c003b7ec>] (__might_sleep+0x0/0xe8) from [<c0332bec>]
(mutex_lock+0x24/0x44)
r4:c725a038
[<c0332bc8>] (mutex_lock+0x0/0x44) from [<c019f348>]
(tty_unthrottle+0x1c/0x64)
r4:c725a000
[<c019f32c>] (tty_unthrottle+0x0/0x64) from [<c0225b08>]
(ppp_asynctty_receive+0x484/0x4a4)
r5:c7816000 r4:c726a180
[<c0225684>] (ppp_asynctty_receive+0x0/0x4a4) from [<c030f944>]
(ircomm_tty_data_indication+0x138/0x184)
[<c030f80c>] (ircomm_tty_data_indication+0x0/0x184) from [<c030c8e8>]
(ircomm_data_indication+0x7c/0xb4)
r6:c7011300 r5:c726a900 r4:c7011300
[<c030c86c>] (ircomm_data_indication+0x0/0xb4) from [<c030d31c>]
(ircomm_process_data+0x110/0x160)
r5:c726a900 r4:c7011300
[<c030d20c>] (ircomm_process_data+0x0/0x160) from [<c030d6e0>]
(ircomm_state_conn+0x60/0xec)
r7:00000000 r6:00000000 r5:c726a900 r4:c7011300
[<c030d680>] (ircomm_state_conn+0x0/0xec) from [<c030d664>]
(ircomm_do_event+0x6c/0x88)
r6:c726a900 r5:00000009 r4:00000003
[<c030d5f8>] (ircomm_do_event+0x0/0x88) from [<c030e850>]
(ircomm_ttp_data_indication+0xbc/0xf4)
r7:00000002 r6:00000000 r5:c726a900 r4:c7011300
[<c030e794>] (ircomm_ttp_data_indication+0x0/0xf4) from [<c03048c0>]
(irttp_do_data_indication+0x44/0x8c)
r5:c726a900 r4:c79f3200
[<c030487c>] (irttp_do_data_indication+0x0/0x8c) from [<c03049b4>]
(irttp_run_rx_queue+0xac/0x318)
r6:c726a900 r5:00000000 r4:c79f3200
[<c0304908>] (irttp_run_rx_queue+0x0/0x318) from [<c0306194>]
(irttp_data_indication+0x90/0xac)
[<c0306104>] (irttp_data_indication+0x0/0xac) from [<c02f8158>]
(irlmp_data_indication+0x5c/0x60)
r7:c726a900 r6:c7120022 r5:c71cb300 r4:c726a900
[<c02f80fc>] (irlmp_data_indication+0x0/0x60) from [<c02fad20>]
(irlmp_link_data_indication+0x2fc/0x35c)
r5:c72c2280 r4:c71cb300
[<c02faa24>] (irlmp_link_data_indication+0x0/0x35c) from [<c02fc0d4>]
(irlap_data_indication+0x38/0x3c)
[<c02fc09c>] (irlap_data_indication+0x0/0x3c) from [<c02ff434>]
(irlap_state_nrm_s+0x208/0x7e0)
r6:c7214400 r5:00000001 r4:00000010
[<c02ff22c>] (irlap_state_nrm_s+0x0/0x7e0) from [<c02fced8>]
(irlap_do_event+0x84/0x17c)
[<c02fce54>] (irlap_do_event+0x0/0x17c) from [<c02ffeb0>]
(irlap_driver_rcv+0x178/0xc34)
r8:c7214400 r7:c726a900 r6:c78e7800 r5:00000001 r4:00000000
[<c02ffd38>] (irlap_driver_rcv+0x0/0xc34) from [<c0287a3c>]
(__netif_receive_skb+0x348/0x39c)
r8:00000000 r7:00001700 r6:c78e7800 r5:c05ee8c4 r4:c726a900
[<c02876f4>] (__netif_receive_skb+0x0/0x39c) from [<c028aec4>]
(process_backlog+0x8c/0x154)
[<c028ae38>] (process_backlog+0x0/0x154) from [<c028aff8>]
(net_rx_action+0x6c/0x188)
[<c028af8c>] (net_rx_action+0x0/0x188) from [<c0046f94>]
(__do_softirq+0x84/0x118)
[<c0046f10>] (__do_softirq+0x0/0x118) from [<c00472a8>] (irq_exit+0x44/0x4c)
[<c0047264>] (irq_exit+0x0/0x4c) from [<c002c080>] (asm_do_IRQ+0x80/0xa0)
[<c002c000>] (asm_do_IRQ+0x0/0xa0) from [<c002cb50>] (__irq_svc+0x30/0x80)
Exception stack(0xc042df40 to 0xc042df88)
df40: 00000000 0005317f 0005217f 60000013 c042c000 c042fcdc c046418c
c042fcd0
df60: 0002661c 41069265 00026580 c042df94 600000d3 c042df88 c002e694
c002e6a0
df80: 60000013 ffffffff
r5:f1100000 r4:ffffffff
[<c002e670>] (default_idle+0x0/0x34) from [<c002e458>] (cpu_idle+0x60/0xa4)
[<c002e3f8>] (cpu_idle+0x0/0xa4) from [<c032d5c4>] (rest_init+0x5c/0x74)
r6:c0027e60 r5:c046415c r4:c0488aa4
[<c032d568>] (rest_init+0x0/0x74) from [<c0008a8c>]
(start_kernel+0x278/0x2e0)
[<c0008814>] (start_kernel+0x0/0x2e0) from [<00008034>] (0x8034)
=====================================
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?
Thanks
~Amit Virdi
^ permalink raw reply [flat|nested] 13+ messages in thread
* BUG: sleeping function called from invalid context
@ 2011-05-10 5:38 ` Amit Virdi
0 siblings, 0 replies; 13+ messages in thread
From: Amit Virdi @ 2011-05-10 5:38 UTC (permalink / raw)
To: linux-input, samuel, alan
Cc: linux-arm-kernel, linux-kernel, Shiraz HASHIM, Armando VISCONTI,
Viresh KUMAR
Hi
I'm testing the driver, based on Linux Kernel 2.6.37, for DICE's Fast
IrDA controller device. I'm using IrCOMM as the upper IrDA layer and
using PPP over it.
While testing, I'm getting the following backtrace repeatedly:
=====================================
BUG: sleeping function called from invalid context at
/data/csd_sw/spear/drives_os/amitvi/spear/kernel/linux-2.6/kernel/mutex.c:85
in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
Backtrace:
[<c0030b48>] (dump_backtrace+0x0/0x110) from [<c0030c8c>]
(dump_stack+0x18/0x1c)
r6:00000000 r5:c725a038 r4:c042c000
[<c0030c74>] (dump_stack+0x0/0x1c) from [<c003b8b4>]
(__might_sleep+0xc8/0xe8)
[<c003b7ec>] (__might_sleep+0x0/0xe8) from [<c0332bec>]
(mutex_lock+0x24/0x44)
r4:c725a038
[<c0332bc8>] (mutex_lock+0x0/0x44) from [<c019f348>]
(tty_unthrottle+0x1c/0x64)
r4:c725a000
[<c019f32c>] (tty_unthrottle+0x0/0x64) from [<c0225b08>]
(ppp_asynctty_receive+0x484/0x4a4)
r5:c7816000 r4:c726a180
[<c0225684>] (ppp_asynctty_receive+0x0/0x4a4) from [<c030f944>]
(ircomm_tty_data_indication+0x138/0x184)
[<c030f80c>] (ircomm_tty_data_indication+0x0/0x184) from [<c030c8e8>]
(ircomm_data_indication+0x7c/0xb4)
r6:c7011300 r5:c726a900 r4:c7011300
[<c030c86c>] (ircomm_data_indication+0x0/0xb4) from [<c030d31c>]
(ircomm_process_data+0x110/0x160)
r5:c726a900 r4:c7011300
[<c030d20c>] (ircomm_process_data+0x0/0x160) from [<c030d6e0>]
(ircomm_state_conn+0x60/0xec)
r7:00000000 r6:00000000 r5:c726a900 r4:c7011300
[<c030d680>] (ircomm_state_conn+0x0/0xec) from [<c030d664>]
(ircomm_do_event+0x6c/0x88)
r6:c726a900 r5:00000009 r4:00000003
[<c030d5f8>] (ircomm_do_event+0x0/0x88) from [<c030e850>]
(ircomm_ttp_data_indication+0xbc/0xf4)
r7:00000002 r6:00000000 r5:c726a900 r4:c7011300
[<c030e794>] (ircomm_ttp_data_indication+0x0/0xf4) from [<c03048c0>]
(irttp_do_data_indication+0x44/0x8c)
r5:c726a900 r4:c79f3200
[<c030487c>] (irttp_do_data_indication+0x0/0x8c) from [<c03049b4>]
(irttp_run_rx_queue+0xac/0x318)
r6:c726a900 r5:00000000 r4:c79f3200
[<c0304908>] (irttp_run_rx_queue+0x0/0x318) from [<c0306194>]
(irttp_data_indication+0x90/0xac)
[<c0306104>] (irttp_data_indication+0x0/0xac) from [<c02f8158>]
(irlmp_data_indication+0x5c/0x60)
r7:c726a900 r6:c7120022 r5:c71cb300 r4:c726a900
[<c02f80fc>] (irlmp_data_indication+0x0/0x60) from [<c02fad20>]
(irlmp_link_data_indication+0x2fc/0x35c)
r5:c72c2280 r4:c71cb300
[<c02faa24>] (irlmp_link_data_indication+0x0/0x35c) from [<c02fc0d4>]
(irlap_data_indication+0x38/0x3c)
[<c02fc09c>] (irlap_data_indication+0x0/0x3c) from [<c02ff434>]
(irlap_state_nrm_s+0x208/0x7e0)
r6:c7214400 r5:00000001 r4:00000010
[<c02ff22c>] (irlap_state_nrm_s+0x0/0x7e0) from [<c02fced8>]
(irlap_do_event+0x84/0x17c)
[<c02fce54>] (irlap_do_event+0x0/0x17c) from [<c02ffeb0>]
(irlap_driver_rcv+0x178/0xc34)
r8:c7214400 r7:c726a900 r6:c78e7800 r5:00000001 r4:00000000
[<c02ffd38>] (irlap_driver_rcv+0x0/0xc34) from [<c0287a3c>]
(__netif_receive_skb+0x348/0x39c)
r8:00000000 r7:00001700 r6:c78e7800 r5:c05ee8c4 r4:c726a900
[<c02876f4>] (__netif_receive_skb+0x0/0x39c) from [<c028aec4>]
(process_backlog+0x8c/0x154)
[<c028ae38>] (process_backlog+0x0/0x154) from [<c028aff8>]
(net_rx_action+0x6c/0x188)
[<c028af8c>] (net_rx_action+0x0/0x188) from [<c0046f94>]
(__do_softirq+0x84/0x118)
[<c0046f10>] (__do_softirq+0x0/0x118) from [<c00472a8>] (irq_exit+0x44/0x4c)
[<c0047264>] (irq_exit+0x0/0x4c) from [<c002c080>] (asm_do_IRQ+0x80/0xa0)
[<c002c000>] (asm_do_IRQ+0x0/0xa0) from [<c002cb50>] (__irq_svc+0x30/0x80)
Exception stack(0xc042df40 to 0xc042df88)
df40: 00000000 0005317f 0005217f 60000013 c042c000 c042fcdc c046418c
c042fcd0
df60: 0002661c 41069265 00026580 c042df94 600000d3 c042df88 c002e694
c002e6a0
df80: 60000013 ffffffff
r5:f1100000 r4:ffffffff
[<c002e670>] (default_idle+0x0/0x34) from [<c002e458>] (cpu_idle+0x60/0xa4)
[<c002e3f8>] (cpu_idle+0x0/0xa4) from [<c032d5c4>] (rest_init+0x5c/0x74)
r6:c0027e60 r5:c046415c r4:c0488aa4
[<c032d568>] (rest_init+0x0/0x74) from [<c0008a8c>]
(start_kernel+0x278/0x2e0)
[<c0008814>] (start_kernel+0x0/0x2e0) from [<00008034>] (0x8034)
=====================================
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?
Thanks
~Amit Virdi
^ permalink raw reply [flat|nested] 13+ messages in thread
* BUG: sleeping function called from invalid context
@ 2011-05-10 5:38 ` Amit Virdi
0 siblings, 0 replies; 13+ messages in thread
From: Amit Virdi @ 2011-05-10 5:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi
I'm testing the driver, based on Linux Kernel 2.6.37, for DICE's Fast
IrDA controller device. I'm using IrCOMM as the upper IrDA layer and
using PPP over it.
While testing, I'm getting the following backtrace repeatedly:
=====================================
BUG: sleeping function called from invalid context at
/data/csd_sw/spear/drives_os/amitvi/spear/kernel/linux-2.6/kernel/mutex.c:85
in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
Backtrace:
[<c0030b48>] (dump_backtrace+0x0/0x110) from [<c0030c8c>]
(dump_stack+0x18/0x1c)
r6:00000000 r5:c725a038 r4:c042c000
[<c0030c74>] (dump_stack+0x0/0x1c) from [<c003b8b4>]
(__might_sleep+0xc8/0xe8)
[<c003b7ec>] (__might_sleep+0x0/0xe8) from [<c0332bec>]
(mutex_lock+0x24/0x44)
r4:c725a038
[<c0332bc8>] (mutex_lock+0x0/0x44) from [<c019f348>]
(tty_unthrottle+0x1c/0x64)
r4:c725a000
[<c019f32c>] (tty_unthrottle+0x0/0x64) from [<c0225b08>]
(ppp_asynctty_receive+0x484/0x4a4)
r5:c7816000 r4:c726a180
[<c0225684>] (ppp_asynctty_receive+0x0/0x4a4) from [<c030f944>]
(ircomm_tty_data_indication+0x138/0x184)
[<c030f80c>] (ircomm_tty_data_indication+0x0/0x184) from [<c030c8e8>]
(ircomm_data_indication+0x7c/0xb4)
r6:c7011300 r5:c726a900 r4:c7011300
[<c030c86c>] (ircomm_data_indication+0x0/0xb4) from [<c030d31c>]
(ircomm_process_data+0x110/0x160)
r5:c726a900 r4:c7011300
[<c030d20c>] (ircomm_process_data+0x0/0x160) from [<c030d6e0>]
(ircomm_state_conn+0x60/0xec)
r7:00000000 r6:00000000 r5:c726a900 r4:c7011300
[<c030d680>] (ircomm_state_conn+0x0/0xec) from [<c030d664>]
(ircomm_do_event+0x6c/0x88)
r6:c726a900 r5:00000009 r4:00000003
[<c030d5f8>] (ircomm_do_event+0x0/0x88) from [<c030e850>]
(ircomm_ttp_data_indication+0xbc/0xf4)
r7:00000002 r6:00000000 r5:c726a900 r4:c7011300
[<c030e794>] (ircomm_ttp_data_indication+0x0/0xf4) from [<c03048c0>]
(irttp_do_data_indication+0x44/0x8c)
r5:c726a900 r4:c79f3200
[<c030487c>] (irttp_do_data_indication+0x0/0x8c) from [<c03049b4>]
(irttp_run_rx_queue+0xac/0x318)
r6:c726a900 r5:00000000 r4:c79f3200
[<c0304908>] (irttp_run_rx_queue+0x0/0x318) from [<c0306194>]
(irttp_data_indication+0x90/0xac)
[<c0306104>] (irttp_data_indication+0x0/0xac) from [<c02f8158>]
(irlmp_data_indication+0x5c/0x60)
r7:c726a900 r6:c7120022 r5:c71cb300 r4:c726a900
[<c02f80fc>] (irlmp_data_indication+0x0/0x60) from [<c02fad20>]
(irlmp_link_data_indication+0x2fc/0x35c)
r5:c72c2280 r4:c71cb300
[<c02faa24>] (irlmp_link_data_indication+0x0/0x35c) from [<c02fc0d4>]
(irlap_data_indication+0x38/0x3c)
[<c02fc09c>] (irlap_data_indication+0x0/0x3c) from [<c02ff434>]
(irlap_state_nrm_s+0x208/0x7e0)
r6:c7214400 r5:00000001 r4:00000010
[<c02ff22c>] (irlap_state_nrm_s+0x0/0x7e0) from [<c02fced8>]
(irlap_do_event+0x84/0x17c)
[<c02fce54>] (irlap_do_event+0x0/0x17c) from [<c02ffeb0>]
(irlap_driver_rcv+0x178/0xc34)
r8:c7214400 r7:c726a900 r6:c78e7800 r5:00000001 r4:00000000
[<c02ffd38>] (irlap_driver_rcv+0x0/0xc34) from [<c0287a3c>]
(__netif_receive_skb+0x348/0x39c)
r8:00000000 r7:00001700 r6:c78e7800 r5:c05ee8c4 r4:c726a900
[<c02876f4>] (__netif_receive_skb+0x0/0x39c) from [<c028aec4>]
(process_backlog+0x8c/0x154)
[<c028ae38>] (process_backlog+0x0/0x154) from [<c028aff8>]
(net_rx_action+0x6c/0x188)
[<c028af8c>] (net_rx_action+0x0/0x188) from [<c0046f94>]
(__do_softirq+0x84/0x118)
[<c0046f10>] (__do_softirq+0x0/0x118) from [<c00472a8>] (irq_exit+0x44/0x4c)
[<c0047264>] (irq_exit+0x0/0x4c) from [<c002c080>] (asm_do_IRQ+0x80/0xa0)
[<c002c000>] (asm_do_IRQ+0x0/0xa0) from [<c002cb50>] (__irq_svc+0x30/0x80)
Exception stack(0xc042df40 to 0xc042df88)
df40: 00000000 0005317f 0005217f 60000013 c042c000 c042fcdc c046418c
c042fcd0
df60: 0002661c 41069265 00026580 c042df94 600000d3 c042df88 c002e694
c002e6a0
df80: 60000013 ffffffff
r5:f1100000 r4:ffffffff
[<c002e670>] (default_idle+0x0/0x34) from [<c002e458>] (cpu_idle+0x60/0xa4)
[<c002e3f8>] (cpu_idle+0x0/0xa4) from [<c032d5c4>] (rest_init+0x5c/0x74)
r6:c0027e60 r5:c046415c r4:c0488aa4
[<c032d568>] (rest_init+0x0/0x74) from [<c0008a8c>]
(start_kernel+0x278/0x2e0)
[<c0008814>] (start_kernel+0x0/0x2e0) from [<00008034>] (0x8034)
=====================================
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?
Thanks
~Amit Virdi
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: BUG: sleeping function called from invalid context
2011-05-10 5:38 ` Amit Virdi
(?)
@ 2011-05-10 9:32 ` Alan Cox
-1 siblings, 0 replies; 13+ messages in thread
From: Alan Cox @ 2011-05-10 9:32 UTC (permalink / raw)
To: Amit Virdi
Cc: linux-input, samuel, linux-arm-kernel, linux-kernel,
Shiraz HASHIM, Armando VISCONTI, Viresh KUMAR
> 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);
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: BUG: sleeping function called from invalid context
@ 2011-05-10 9:32 ` Alan Cox
0 siblings, 0 replies; 13+ messages in thread
From: Alan Cox @ 2011-05-10 9:32 UTC (permalink / raw)
To: Amit Virdi
Cc: linux-input, samuel, linux-arm-kernel, linux-kernel,
Shiraz HASHIM, Armando VISCONTI, Viresh KUMAR
> 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);
^ permalink raw reply [flat|nested] 13+ messages in thread
* BUG: sleeping function called from invalid context
@ 2011-05-10 9:32 ` Alan Cox
0 siblings, 0 replies; 13+ messages in thread
From: Alan Cox @ 2011-05-10 9:32 UTC (permalink / raw)
To: linux-arm-kernel
> 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);
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: sleeping function called from invalid context
2011-05-10 9:32 ` Alan Cox
(?)
@ 2011-05-11 8:43 ` Amit Virdi
-1 siblings, 0 replies; 13+ messages in thread
From: Amit Virdi @ 2011-05-11 8:43 UTC (permalink / raw)
To: Alan Cox
Cc: linux-input, samuel, linux-arm-kernel, linux-kernel,
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] 13+ messages in thread
* Re: sleeping function called from invalid context
@ 2011-05-11 8:43 ` Amit Virdi
0 siblings, 0 replies; 13+ messages in thread
From: Amit Virdi @ 2011-05-11 8:43 UTC (permalink / raw)
To: Alan Cox
Cc: samuel, Armando VISCONTI, linux-kernel, Shiraz HASHIM,
linux-input, 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] 13+ messages in thread
* sleeping function called from invalid context
@ 2011-05-11 8:43 ` Amit Virdi
0 siblings, 0 replies; 13+ 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] 13+ messages in thread
* sleeping function called from invalid context
@ 2006-09-11 8:50 Neil Bird
0 siblings, 0 replies; 13+ 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] 13+ 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; 13+ 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] 13+ 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; 13+ 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] 13+ messages in thread
* sleeping function called from invalid context
@ 2003-09-09 15:03 Samuel Flory
2003-09-09 19:47 ` Matt Mackall
0 siblings, 1 reply; 13+ 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] 13+ messages in thread
end of thread, other threads:[~2011-05-11 16:18 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-10 5:38 BUG: sleeping function called from invalid context Amit Virdi
2011-05-10 5:38 ` Amit Virdi
2011-05-10 5:38 ` Amit Virdi
2011-05-10 9:32 ` Alan Cox
2011-05-10 9:32 ` Alan Cox
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
-- strict thread matches above, loose matches on Subject: below --
2006-09-11 8:50 Neil Bird
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.