On Wed, Mar 13, 2019 at 10:31:11AM +0100, Lorenzo Bianconi wrote: > > > > On Tue, Mar 12, 2019 at 05:48:14PM +0100, Lorenzo Bianconi wrote: > > > > > > > > On Mon, Mar 11, 2019 at 02:24:35PM +0100, Lorenzo Bianconi wrote: > > > > > Fix following schedule while atomic in mt76x02_reset_state > > > > > since synchronize_rcu is run inside a RCU section > > > > > > > > > > [44036.944222] mt76x2e 0000:06:00.0: MCU message 31 (seq 3) timed out > > > > > [44036.944281] BUG: sleeping function called from invalid context at kernel/rcu/tree_exp.h:818 > > > > > [44036.944284] in_atomic(): 1, irqs_disabled(): 0, pid: 28066, name: kworker/u4:1 > > > > > [44036.944287] INFO: lockdep is turned off. > > > > > [44036.944292] CPU: 1 PID: 28066 Comm: kworker/u4:1 Tainted: G W 5.0.0-rc7-wdn-t1+ #7 > > > > > [44036.944294] Hardware name: Dell Inc. Studio XPS 1340/0K183D, BIOS A11 09/08/2009 > > > > > [44036.944305] Workqueue: phy1 mt76x02_wdt_work [mt76x02_lib] > > > > > [44036.944308] Call Trace: > > > > > [44036.944317] dump_stack+0x67/0x90 > > > > > [44036.944322] ___might_sleep.cold.88+0x9f/0xaf > > > > > [44036.944327] rcu_blocking_is_gp+0x13/0x50 > > > > > [44036.944330] synchronize_rcu+0x17/0x80 > > > > > [44036.944337] mt76_sta_state+0x138/0x1d0 [mt76] > > > > > [44036.944349] mt76x02_wdt_work+0x1c9/0x610 [mt76x02_lib] > > > > > [44036.944355] process_one_work+0x2a5/0x620 > > > > > [44036.944361] worker_thread+0x35/0x3e0 > > > > > [44036.944368] kthread+0x11c/0x140 > > > > > [44036.944376] ret_from_fork+0x3a/0x50 > > > > > [44036.944384] BUG: scheduling while atomic: kworker/u4:1/28066/0x00000002 > > > > > [44036.944387] INFO: lockdep is turned off. > > > > > [44036.944389] Modules linked in: cmac ctr ccm af_packet snd_hda_codec_hdmi > > > > > > > > Does the patch fix the issue for you ? For me on my MT7612E device it > > > > make the BUG warning gone, but instead of that I have total system hung > > > > without any error message except information about hw restart. > > The system hang is not related to the 'schedule while atomic'. > If you look at the code we run synchronize_rcu() inside a rcu section > and this is not allowed. > I just run it outside of the rcu section protecting it with the mutex, > the reset is performed even with > this patch (just look at syslog). The system hang is related to this > particular card since other devices > work properly. Ok, so it works for you. That I wanted to know. Stanislaw
