Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261885AbVC3NFR (ORCPT ); Wed, 30 Mar 2005 08:05:17 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261887AbVC3NFR (ORCPT ); Wed, 30 Mar 2005 08:05:17 -0500 Received: from main.gmane.org ([80.91.229.2]:1211 "EHLO ciao.gmane.org") by vger.kernel.org with ESMTP id S261885AbVC3NFK (ORCPT ); Wed, 30 Mar 2005 08:05:10 -0500 X-Injected-Via-Gmane: http://gmane.org/ To: linux-kernel@vger.kernel.org From: Matthias Urlichs Subject: Call chain analysis Date: Wed, 30 Mar 2005 15:04:28 +0200 Organization: {M:U} IT-Consulting Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: run.smurf.noris.de User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) X-Face: '&-&kxR\8+Pqalw@VzN\p?]]eIYwRDxvrwEM hcd_buffer_destroy -> dma_pool_destroy -> pool_free_page -> free_hot_cold_page -> IRQ -> usb_hcd_irq results in a crash. That's not the immediate problem, though. The problem is that wrapping usb_hcd_pci_remove() in a local_irq_save/ /restore *still* allows that interrupt to happen. I suspect that something in that call chain sometimes calls the scheduler ..? I assume that there are nice tools which find that call for me, and save me from plowing through a lot of kernel code ..? I've never needed one of those before. :-/ -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/