All of lore.kernel.org
 help / color / mirror / Atom feed
* BUG: sleeping function called from invalid context
@ 2011-05-10  5:38 ` Amit Virdi
  0 siblings, 0 replies; 28+ 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] 28+ messages in thread
* BUG: sleeping function called from invalid context
@ 2011-11-23 11:36 Peter Rusko
  2011-11-23 12:44 ` Fabio Estevam
  0 siblings, 1 reply; 28+ messages in thread
From: Peter Rusko @ 2011-11-23 11:36 UTC (permalink / raw)
  To: linux-arm-kernel

Hi all,

While trying to use the LRADC and touchscreen functionality on imx28,
I've run into this problem:

udevd[523]: starting version 171
BUG: sleeping function called from invalid context at kernel/mutex.c:271
in_atomic(): 1, irqs_disabled(): 128, pid: 523, name: udevd
no locks held by udevd/523.
irq event stamp: 956
hardirqs last  enabled at (956): [<c032e56c>] 
_raw_write_unlock_irqrestore+0x3c/0x68
hardirqs last disabled at (955): [<c032e6ec>] 
_raw_write_lock_irqsave+0x1c/0x58
softirqs last  enabled at (843): [<c0025c78>] irq_exit+0x54/0xb0
softirqs last disabled at (792): [<c0025c78>] irq_exit+0x54/0xb0
[<c0013238>] (unwind_backtrace+0x0/0xe0) from [<c032d198>] 
(mutex_lock_nested+0x24/0x31c)
[<c032d198>] (mutex_lock_nested+0x24/0x31c) from [<c0017570>] 
(clk_enable+0x20/0x48)
[<c0017570>] (clk_enable+0x20/0x48) from [<c023173c>] 
(pl011_console_write+0x20/0x78)
[<c023173c>] (pl011_console_write+0x20/0x78) from [<c0020780>] 
(__call_console_drivers+0x84/0x9c)
[<c0020780>] (__call_console_drivers+0x84/0x9c) from [<c0020ba0>] 
(console_unlock+0xfc/0x1ec)
[<c0020ba0>] (console_unlock+0xfc/0x1ec) from [<c0021150>] 
(vprintk+0x3b0/0x440)
[<c0021150>] (vprintk+0x3b0/0x440) from [<c032b4d4>] (printk+0x18/0x24)
[<c032b4d4>] (printk+0x18/0x24) from [<c0233a5c>] (kmsg_writev+0xd8/0xfc)
[<c0233a5c>] (kmsg_writev+0xd8/0xfc) from [<c008f58c>] 
(do_sync_write+0x98/0xd4)
[<c008f58c>] (do_sync_write+0x98/0xd4) from [<c008fe98>] 
(vfs_write+0xc8/0x138)
[<c008fe98>] (vfs_write+0xc8/0x138) from [<c00900e0>] (sys_write+0x3c/0x68)
[<c00900e0>] (sys_write+0x3c/0x68) from [<c000e180>] 
(ret_fast_syscall+0x0/0x38)

It seems that the printk calls cause the problem (it's not just with 
udev, seems to have the problem with all printk calls). The touchscreen
works perfectly and I'd like to submit a patch which supports it, but I
keep getting the same messages. What can cause the problem, why is it an
atomic context within the udevd?

Regards,
-- 
Rusk? P?ter
Fejleszt?m?rn?k

Prolan Zrt. / Prolan Co.
Hungary 2011 Budakal?sz, Szentendrei ?t 1-3.
Tel./Phone: +36 20 954 3118
Fax: +36 26 540 420
E-mail: rusko.peter at prolan.hu
Web: www.prolan.hu
Timezone:CET

^ permalink raw reply	[flat|nested] 28+ messages in thread
* BUG: sleeping function called from invalid context
@ 2011-10-11 17:13 Dario Faggioli
  2011-10-11 17:32 ` Konrad Rzeszutek Wilk
  0 siblings, 1 reply; 28+ messages in thread
From: Dario Faggioli @ 2011-10-11 17:13 UTC (permalink / raw)
  To: xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 2756 bytes --]

Hello everyone,

Since I really plan to spend some time here, let me introduce myself
first. My name is Dario Faggioli and I just joined the Citrix Platform
Team in Cambridge (although I'll be working from Italy). I've some
experience in Linux kernel (mainly scheduling) and not that much
experience in Xen or virtualization in general, but I really want to
learn and be able to contribute ASAP!

In fact, while "doing my homework", I stumbled against the following
BUG(). I'm able to reproduce it with xen-unstable and by just by
enabling spinlock and mutex debug checks in linus' Linux
(65112dccf8a113737684366349d7f9ec373ddc47) _iff_ using 'tap:qcow2' disk
image, while no such thing happens with 'phy:'.

[  996.282544] BUG: sleeping function called from invalid context at /local/scratch/dariof/linux/kernel/mutex.c:271
[  996.282570] in_atomic(): 1, irqs_disabled(): 0, pid: 3256, name: qemu-dm
[  996.282581] 1 lock held by qemu-dm/3256:
[  996.282589]  #0:  (&(&priv->lock)->rlock){......}, at: [<ffffffff813223da>] gntdev_ioctl+0x2bd/0x4d5
[  996.282628] Pid: 3256, comm: qemu-dm Tainted: G        W   3.1.0-rc8+ #5
[  996.282638] Call Trace:
[  996.282687]  [<ffffffff81054594>] __might_sleep+0x131/0x135
[  996.282704]  [<ffffffff816bd64f>] mutex_lock_nested+0x25/0x45
[  996.282721]  [<ffffffff8131c7c8>] free_xenballooned_pages+0x20/0xb1
[  996.282735]  [<ffffffff8132194d>] gntdev_put_map+0xa8/0xdb
[  996.282749]  [<ffffffff816be546>] ? _raw_spin_lock+0x71/0x7a
[  996.282763]  [<ffffffff813223da>] ? gntdev_ioctl+0x2bd/0x4d5
[  996.282776]  [<ffffffff8132243c>] gntdev_ioctl+0x31f/0x4d5
[  996.282790]  [<ffffffff81007d62>] ? check_events+0x12/0x20
[  996.282804]  [<ffffffff811433bc>] do_vfs_ioctl+0x488/0x4d7
[  996.282818]  [<ffffffff81007d4f>] ? xen_restore_fl_direct_reloc+0x4/0x4
[  996.282832]  [<ffffffff8109168b>] ? lock_release+0x21c/0x229
[  996.282847]  [<ffffffff81135cdd>] ? rcu_read_unlock+0x21/0x32
[  996.282860]  [<ffffffff81143452>] sys_ioctl+0x47/0x6a
[  996.282873]  [<ffffffff816bfd82>] system_call_fastpath+0x16/0x1b

This seems to be due to free_xenballooned_pages(), called by
gntdev_put_map(), taking balloon_mutex, with the latter that can be
called within a spin_lock() (e.g., in gntdev_release()).

I'm not enough confident with the code do attempt fixing it, but I
thought it was worth to at least point it out!

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 28+ messages in thread
* BUG: sleeping function called from invalid context
@ 2011-08-30 13:28 sandeep kumar
  2011-08-30 15:14 ` Dave Hylands
  0 siblings, 1 reply; 28+ messages in thread
From: sandeep kumar @ 2011-08-30 13:28 UTC (permalink / raw)
  To: kernelnewbies

Hi all,
I am working on android, linux kernel version: 2.6.35.11

I am getting this following error message. I know it occurs when u call a
sleeping function in atomic context.
As far as i knew the entire stack of functions,nothing is atomic
context(these are standard platform dev add functions...)

Now i want to know these things..
1) Is there any method to know, when and where this atomic context started?
           (i put a log in the "msm_bus_fabric_probe" function, to check
whether it is atomic or not using "in_atomic()"..it is giving '0', and also
i read that in_atomic wont always work well in all cases in the header file)

2) Can we neglect this warning, is it very important? because lot of similer
cases,(where "clk_get_sys" is called)
are working fine. only this thing is showing warning message. can we
overlook this?

pls tell me



[    0.267394] BUG: sleeping function called from invalid context at
/home/sandeep_CELOX_NTT/android/kernel/kernel/mutex.c:94
<3>[    0.267455] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper
<4>[    0.267517] [<c01076a0>] (unwind_backtrace+0x0/0x164) from
[<c07233f0>] (mutex_lock+0x18/0x38)
<4>[    0.267578] [<c07233f0>] (mutex_lock+0x18/0x38) from [<c010e5dc>]
(clk_get_sys+0x2c/0xe4)
<4>[    0.267608] [<c010e5dc>] (clk_get_sys+0x2c/0xe4) from [<c01869b4>]
(msm_bus_fabric_probe+0x630/0x818)
<4>[    0.267639] [<c01869b4>] (msm_bus_fabric_probe+0x630/0x818) from
[<c0417b2c>] (platform_drv_probe+0x18/0x1c)
<4>[    0.267669] [<c0417b2c>] (platform_drv_probe+0x18/0x1c) from
[<c0416788>] (driver_probe_device+0x19c/0x34c)
<4>[    0.267730] [<c0416788>] (driver_probe_device+0x19c/0x34c) from
[<c04159c0>] (bus_for_each_drv+0x48/0x84)
<4>[    0.267761] [<c04159c0>] (bus_for_each_drv+0x48/0x84) from
[<c0416a84>] (device_attach+0x64/0x88)
<4>[    0.267791] [<c0416a84>] (device_attach+0x64/0x88) from [<c0415788>]
(bus_probe_device+0x24/0x40)
<4>[    0.267822] [<c0415788>] (bus_probe_device+0x24/0x40) from
[<c04139a0>] (device_add+0x39c/0x52c)
<4>[    0.267852] [<c04139a0>] (device_add+0x39c/0x52c) from [<c0418158>]
(platform_device_add+0x16c/0x1e8)
<4>[    0.267883] [<c0418158>] (platform_device_add+0x16c/0x1e8) from
[<c0418498>] (platform_add_devices+0x1c/0x60)
<4>[    0.267913] [<c0418498>] (platform_add_devices+0x1c/0x60) from
[<c00147d4>] (msm8x60_init+0x378/0x14a4)

-- 
With regards,
Sandeep Kumar Anantapalli,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110830/c249636f/attachment.html 

^ permalink raw reply	[flat|nested] 28+ messages in thread
* BUG: sleeping function called from invalid context
@ 2009-11-28 13:24 Ilpo Järvinen
  0 siblings, 0 replies; 28+ messages in thread
From: Ilpo Järvinen @ 2009-11-28 13:24 UTC (permalink / raw)
  To: Netdev

I booted up net-next-2.6 based kernel under kvm and keep getting this one:

BUG: sleeping function called from invalid context at mm/slub.c:1719
in_atomic(): 1, irqs_disabled(): 0, pid: 2847, name: dhclient3
1 lock held by dhclient3/2847:
 #0:  (rcu_read_lock){.+.+.+}, at: [<ffffffff813bf681>] packet_sendmsg_spkt+0x56/0x28b
Pid: 2847, comm: dhclient3 Not tainted 2.6.32-rc7-03467-g5e75659 #51
Call Trace:
 [<ffffffff8106a926>] ? __debug_show_held_locks+0x22/0x24
 [<ffffffff8103b405>] __might_sleep+0x126/0x12b
 [<ffffffff810d4b25>] kmem_cache_alloc+0x46/0x14e
 [<ffffffff812f9e7a>] __alloc_skb+0x3c/0x15b
 [<ffffffff812f4ffe>] sock_wmalloc+0x31/0x78
 [<ffffffff813bf732>] packet_sendmsg_spkt+0x107/0x28b
 [<ffffffff813bf681>] ? packet_sendmsg_spkt+0x56/0x28b
 [<ffffffff812f1c37>] sock_sendmsg+0xdf/0xf8
 [<ffffffff810d2389>] ? add_partial+0x1a/0x69
 [<ffffffff8105cd8e>] ? autoremove_wake_function+0x0/0x38
 [<ffffffff813e86d1>] ? _spin_unlock+0x30/0x4b
 [<ffffffff810d2389>] ? add_partial+0x1a/0x69
 [<ffffffff810d23d0>] ? add_partial+0x61/0x69
 [<ffffffff810d679b>] ? kmem_cache_free+0xcb/0x138
 [<ffffffff8106b539>] ? trace_hardirqs_on+0xd/0xf
 [<ffffffff812f34f8>] ? move_addr_to_kernel+0x40/0x49
 [<ffffffff812f35e0>] sys_sendto+0xdf/0x107
 [<ffffffff810f031c>] ? mntput_no_expire+0x24/0xf0
 [<ffffffff8100bbc2>] system_call_fastpath+0x16/0x1b


-- 
 i.

^ permalink raw reply	[flat|nested] 28+ messages in thread
* BUG: sleeping function called from invalid context
@ 2008-05-06  9:04 Holger Schurig
  2008-05-06  9:22 ` Holger Schurig
  0 siblings, 1 reply; 28+ messages in thread
From: Holger Schurig @ 2008-05-06  9:04 UTC (permalink / raw)
  To: libertas-dev; +Cc: Linux Wireless

Here is something I haven't yet debugged and where I am a little 
bit clueless.

Situation: libertas has associated to an AP successfully and I 
run "iwconfig eth1 essid BLAHLABER". Everything is o.k. when I 
run the same command while not associated.

What I don't know is why something is calling 
get_wireless_stats() when setting the essid. This happens way 
before a call into lbs_set_essid() (the WEXT handler), as can be 
seen from the log below.


libertas enter: lbs_ret_80211_associate()
libertas assoc: associated to 00:13:19:80:da:30
##HS iwconfig eth1 essid BLAHLABER
libertas enter: lbs_get_wireless_stats()
libertas wext: signal level 0xd2
libertas wext: noise 0xa8
BUG: sleeping function called from invalid context at 
drivers/net/wireless/libertas/cmd.c:2013
in_atomic():1, irqs_disabled():0
2 locks held by iwconfig/16494:
 #0:  (&p->lock){--..}, at: [<c016d856>] seq_read+0x25/0x267
 #1:  (dev_base_lock){-.--}, at: [<c02bf6f6>] 
dev_seq_start+0x1d/0x7f
Pid: 16494, comm: iwconfig Not tainted 2.6.25-wl #33
 [<c0114e77>] __might_sleep+0xb3/0xb8
 [<f8837d9f>] __lbs_cmd+0x8b/0x175 [libertas]
 [<c0119477>] ? printk+0x15/0x17
 [<f883452a>] lbs_get_wireless_stats+0x17e/0x2d4 [libertas]
 [<f88392a7>] ? lbs_cmd_copyback+0x0/0x2d [libertas]
 [<c030464a>] get_wireless_stats+0x16/0x1c
 [<c03050ff>] wireless_seq_show+0x2f/0xcf
 [<c016d880>] ? seq_read+0x4f/0x267
 [<c016d9c1>] seq_read+0x190/0x267
 [<c016d831>] ? seq_read+0x0/0x267
 [<c0181376>] proc_reg_read+0x60/0x74
 [<c0181316>] ? proc_reg_read+0x0/0x74
 [<c01580ed>] vfs_read+0x8a/0x106
 [<c015845b>] sys_read+0x3b/0x60
 [<c010384a>] sysenter_past_esp+0x5f/0xa5
 =======================
BUG: scheduling while atomic: iwconfig/16494/0x00000002
2 locks held by iwconfig/16494:
 #0:  (&p->lock){--..}, at: [<c016d856>] seq_read+0x25/0x267
 #1:  (dev_base_lock){-.--}, at: [<c02bf6f6>] 
dev_seq_start+0x1d/0x7f
Pid: 16494, comm: iwconfig Not tainted 2.6.25-wl #33
 [<c0115d6b>] __schedule_bug+0x58/0x5f
 [<c032a863>] schedule+0x5b/0x2d1
 [<c0127d82>] ? prepare_to_wait+0x4d/0x53
 [<f8837df5>] __lbs_cmd+0xe1/0x175 [libertas]
 [<c0127c25>] ? autoremove_wake_function+0x0/0x33
 [<f883452a>] lbs_get_wireless_stats+0x17e/0x2d4 [libertas]
 [<f88392a7>] ? lbs_cmd_copyback+0x0/0x2d [libertas]
 [<c030464a>] get_wireless_stats+0x16/0x1c
 [<c03050ff>] wireless_seq_show+0x2f/0xcf
 [<c016d880>] ? seq_read+0x4f/0x267
 [<c016d9c1>] seq_read+0x190/0x267
 [<c016d831>] ? seq_read+0x0/0x267
 [<c0181376>] proc_reg_read+0x60/0x74
 [<c0181316>] ? proc_reg_read+0x0/0x74
 [<c01580ed>] vfs_read+0x8a/0x106
 [<c015845b>] sys_read+0x3b/0x60
 [<c010384a>] sysenter_past_esp+0x5f/0xa5
 =======================
BUG: scheduling while atomic: iwconfig/16494/0x00000002
2 locks held by iwconfig/16494:
 #0:  (&p->lock){--..}, at: [<c016d856>] seq_read+0x25/0x267
 #1:  (dev_base_lock){-.--}, at: [<c02bf6f6>] 
dev_seq_start+0x1d/0x7f
Pid: 16494, comm: iwconfig Not tainted 2.6.25-wl #33
 [<c0115d6b>] __schedule_bug+0x58/0x5f
 [<c032a863>] schedule+0x5b/0x2d1
 [<c0127d82>] ? prepare_to_wait+0x4d/0x53
 [<f8837df5>] __lbs_cmd+0xe1/0x175 [libertas]
 [<c0127c25>] ? autoremove_wake_function+0x0/0x33
 [<f883452a>] lbs_get_wireless_stats+0x17e/0x2d4 [libertas]
 [<f88392a7>] ? lbs_cmd_copyback+0x0/0x2d [libertas]
 [<c030464a>] get_wireless_stats+0x16/0x1c
 [<c03050ff>] wireless_seq_show+0x2f/0xcf
 [<c016d880>] ? seq_read+0x4f/0x267
 [<c016d9c1>] seq_read+0x190/0x267
 [<c016d831>] ? seq_read+0x0/0x267
 [<c0181376>] proc_reg_read+0x60/0x74
 [<c0181316>] ? proc_reg_read+0x0/0x74
 [<c01580ed>] vfs_read+0x8a/0x106
 [<c015845b>] sys_read+0x3b/0x60
 [<c010384a>] sysenter_past_esp+0x5f/0xa5
 =======================
libertas enter: lbs_set_essid()
libertas wext: requested SSID 'MNHS'

This happens with libertas from wireless-testing 
v2.6.25-6933-g0bacadf.


^ permalink raw reply	[flat|nested] 28+ messages in thread
end of thread, other threads:[~2011-11-24 14:16 UTC | newest]

Thread overview: 28+ 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 --
2011-11-23 11:36 BUG: " Peter Rusko
2011-11-23 12:44 ` Fabio Estevam
2011-11-23 13:05   ` Fabio Estevam
2011-11-23 18:36   ` Uwe Kleine-König
2011-11-23 22:51     ` Russell King - ARM Linux
2011-11-24  6:32       ` Shawn Guo
2011-11-24  7:14       ` Uwe Kleine-König
2011-11-24  9:01         ` Russell King - ARM Linux
2011-11-24  9:05           ` Uwe Kleine-König
2011-11-24 10:29             ` Russell King - ARM Linux
2011-11-24 14:16               ` Uwe Kleine-König
2011-10-11 17:13 Dario Faggioli
2011-10-11 17:32 ` Konrad Rzeszutek Wilk
2011-08-30 13:28 sandeep kumar
2011-08-30 15:14 ` Dave Hylands
     [not found]   ` <CAL7WMDf-VEOBs6o-hup-qP17AYfp+=Eb1E9w=33d93GWYa=fBw@mail.gmail.com>
     [not found]     ` <CABi1daHSEegXLr4MyK0xkTKxwEwwc-8bNc8jkWrpUN=ujbj_9Q@mail.gmail.com>
2011-08-31  8:15       ` sandeep kumar
2009-11-28 13:24 Ilpo Järvinen
2008-05-06  9:04 Holger Schurig
2008-05-06  9:22 ` Holger Schurig

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.