From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail2.candelatech.com ([208.74.158.173]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1XYdXs-0005ph-2o for ath10k@lists.infradead.org; Mon, 29 Sep 2014 16:11:28 +0000 Message-ID: <5429848D.6000706@candelatech.com> Date: Mon, 29 Sep 2014 09:10:53 -0700 From: Ben Greear MIME-Version: 1.0 Subject: Re: Possible issue with firmware crash reporting. References: <5421B67D.8060508@candelatech.com> <87wq8m1ydg.fsf@kamboji.qca.qualcomm.com> In-Reply-To: <87wq8m1ydg.fsf@kamboji.qca.qualcomm.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: Kalle Valo Cc: ath10k On 09/29/2014 04:04 AM, Kalle Valo wrote: > Ben Greear writes: > >> This kernel is basically linux-ath from a few days ago >> plus a bunch of my patches, including my versions of the firmware >> BSS and stack dump patches. >> Problem could be mine alone, but likely the patches Kalle >> is working on would be susceptible to the same sort of problem. >> >> I produced this by purposefully crashing the firmware during >> station registration while debugging some firmware issues. >> >> This is just FYI, but if someone cares to do similar >> testing, I can build a special firmware that crashes >> in the same way and make it available. >> >> >> ================================= >> [ INFO: inconsistent lock state ] >> 3.17.0-rc6+ #3 Not tainted >> --------------------------------- >> inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. >> swapper/2/0 [HC0[0]:SC1[1]:HE1:SE0] takes: >> (uevent_sock_mutex){+.?.+.}, at: [] >> kobject_uevent_env+0x2b8/0x5d7 > > [...] > >> {SOFTIRQ-ON-W} state was registered at: >> [] __lock_acquire+0x352/0xe48 >> [] lock_acquire+0xd2/0x120 >> [] mutex_lock_nested+0x4f/0x3c7 >> [] kobject_uevent_env+0x2b8/0x5d7 >> [] kobject_uevent+0xb/0xd >> [] kset_register+0x30/0x3e >> [] bus_register+0xae/0x292 >> [] platform_bus_init+0x29/0x41 >> [] driver_init+0x27/0x33 >> [] kernel_init_freeable+0x155/0x263 >> [] kernel_init+0x9/0xda >> [] ret_from_fork+0x7c/0xb0 > > [...] > >> [] dump_stack+0x4e/0x71 >> [] print_usage_bug+0x1ec/0x1fd >> [] ? save_stack_trace+0x27/0x44 >> [] ? check_usage_backwards+0xa0/0xa0 >> [] mark_lock+0x11b/0x212 >> [] __lock_acquire+0x2dc/0xe48 >> [] ? mark_held_locks+0x54/0x76 >> [] ? __free_pages_ok+0xb3/0xca >> [] ? trace_hardirqs_on_caller+0x192/0x1a1 >> [] lock_acquire+0xd2/0x120 >> [] ? kobject_uevent_env+0x2b8/0x5d7 >> [] mutex_lock_nested+0x4f/0x3c7 >> [] ? kobject_uevent_env+0x2b8/0x5d7 >> [] ? kobject_uevent_env+0x2b8/0x5d7 >> [] ? dev_uevent+0x1d4/0x274 >> [] ? kobject_get_path+0x8c/0xdb >> [] kobject_uevent_env+0x2b8/0x5d7 >> [] ? trace_hardirqs_on_caller+0x192/0x1a1 >> [] ath10k_pci_fw_crashed_dump+0x456/0x535 [ath10k_pci] >> [] ? xen_set_domain_pte+0x37/0xe1 >> [] ath10k_pci_tasklet+0x27/0x5a [ath10k_pci] >> [] tasklet_action+0xcb/0xdd > > If I'm reading this right, uevent_sock_mutex is by both > platform_bus_init() and and ath10k tasklet in > ath10k_pci_fw_crashed_dump() tries to acquire the same lock via > kobject_uevent_evn(). But I don't understand is how > ath10k_pci_fw_crashed_dump() ends up calling kobject_uevent_env(), I > just can't find a code path to do that. > > Are you sure you don't have some custom patches which cause this, like > sending a uevent whenever firmware crashes? Well yes, I do have that patch in this kernel I think. I'll remove it, I can key off of the ethtool stats for firmware crash counts instead. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k