Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2776365imm; Thu, 24 May 2018 16:01:03 -0700 (PDT) X-Google-Smtp-Source: AB8JxZriFRwGqmCa56vFZwpGK3SsSmigkqLLpqaxIr/SkPnIFr3niksW4ArfvUPpKcAUxQIK4PVe X-Received: by 2002:a17:902:205:: with SMTP id 5-v6mr9101872plc.301.1527202863581; Thu, 24 May 2018 16:01:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527202863; cv=none; d=google.com; s=arc-20160816; b=dTWkwMUw5YBdx35shGKhBANxf2Wq28wWTo0jOcpXBO/mdESzK8gZLHSSqaOgblVmHI K+l5tf+ggP3JUgGbkKyVcGcRX0SxRnsM5cxGnrzFxNjFmCc8i9/7NePxTA2dHWEwQqbD vmQh5pRQEv1Zcr+THlVBpmLYGsU0mcjkU7wimcFdChzE2mzJeghHTKgnZ0VKmOiFdDbe K8LWAznXSZtT7aTnEWysc5pZ2a89vYA9hCKsJpRb8hhrKqTMSKnID2e4ZuSvN1z0ClRH ZoY/LAaTnpXrW9XmkloKXu7FDlH2WDi9XGWGrl4FVeMaOT5M4pFasRoAl3XpeBiErnJ6 VR8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=ovHdnV3NtaR5CprTp41AvD527DJi+Nt9JIyUD5r27ts=; b=hjLGT47WdtRAgJSbsnGY1GXkT7sGIjvbYUCtwpVrwWyXp2xN5ulU4xbK8tseaUhOfb dC67nMx4NXNO3n+VL+1oQ+iIiTODzfjB+gAVzJltUhABixjUpfjCFH1/9MW6MEqW6sFC /R8tq8zh3ks++mRSHXaL01ucgXucXlRrRabrnGwXO3Y6Y2u/j0NJmq2ytTxT3lLeUrVf LZYMIRQuuWoTFiFFAy23w1OGEXygjoR1KOMd03Hx6mS7MxQ54vUL3gY6lMirlosLjELW 42+oFwHltxYwlCE0NwunsRC2SYMZi2ndi3qb5aCOpaEL83OQg1rP7aCDY+nPjQwAK7z5 2eoQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=OPx33pY/; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f8-v6si15864460pgn.567.2018.05.24.16.00.47; Thu, 24 May 2018 16:01:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=OPx33pY/; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S968554AbeEXNHb (ORCPT + 99 others); Thu, 24 May 2018 09:07:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:53072 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935598AbeEXNH3 (ORCPT ); Thu, 24 May 2018 09:07:29 -0400 Received: from localhost (173-25-171-118.client.mchsi.com [173.25.171.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 62C3E20894; Thu, 24 May 2018 13:07:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1527167248; bh=kjPpZcb82jlORKMPoSx8oc3V9p7G+HpcsGOkIlppuFI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OPx33pY/R3mbV58eXAVGtd4UsUtIUWLoLbk+6wWMqQjNqh0KwRvjl+tN6q8Szak0h CCbTl/SDpV2aVjf5nX7wbtd4C/ekSy8+Nk9heKpbY6KjWEiHnvPREHr1xrugeVVr8N pTZA+AI3c8I/+OVtD5UycnDdMqdvI7f0gKcMdxyw= Date: Thu, 24 May 2018 08:07:27 -0500 From: Bjorn Helgaas To: Sinan Kaya Cc: linux-pci@vger.kernel.org, timur@codeaurora.org, ryan@finnie.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org, Bjorn Helgaas , "Rafael J. Wysocki" , Greg Kroah-Hartman , Thomas Gleixner , Kate Stewart , Frederick Lawler , Dongdong Liu , Mika Westerberg , open list , Don Brace , esc.storagedev@microsemi.com, linux-scsi@vger.kernel.org Subject: Re: [PATCH V2] PCI/portdrv: do not disable device on reboot/shutdown Message-ID: <20180524130727.GA85822@bhelgaas-glaptop.roam.corp.google.com> References: <1527043490-17268-1-git-send-email-okaya@codeaurora.org> <20180523213249.GD150632@bhelgaas-glaptop.roam.corp.google.com> <61f70fd6-52fd-da07-ce73-303f95132131@codeaurora.org> <82656e20-e821-1944-3399-1667ceb27719@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82656e20-e821-1944-3399-1667ceb27719@codeaurora.org> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 24, 2018 at 07:43:05AM -0400, Sinan Kaya wrote: > On 5/23/2018 6:57 PM, Sinan Kaya wrote: > >> The crash seems to indicate that the hpsa device attempted a DMA after > >> we cleared the Root Port's PCI_COMMAND_MASTER, which means > >> hpsa_shutdown() didn't stop DMA from the device (it looks like *most* > >> shutdown methods don't disable device DMA, so it's in good company). > > All drivers are expected to shutdown DMA and interrupts in their shutdown() > > routines. They can skip removing threads, data structures etc. but DMA and > > interrupt disabling are required. This is the difference between shutdown() > > and remove() callbacks. > > I found this note yesterday to see why we are not disabling the > devices in the PCI core itself. > > pci_device_remove() > > /* > * We would love to complain here if pci_dev->is_enabled is set, that > * the driver should have called pci_disable_device(), but the > * unfortunate fact is there are too many odd BIOS and bridge setups > * that don't like drivers doing that all of the time. > * Oh well, we can dream of sane hardware when we sleep, no matter how > * horrible the crap we have to deal with is when we are awake... > */ > > Ryan, can you discard the previous patch and test this one instead? > remove() path in hpsa driver seems to call pci_disable_device() via > > hpsa_remove_one() > hpsa_free_pci_init() > > but nothing on the shutdown path. > > diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c > index 4ed3d26..3823f04 100644 > --- a/drivers/scsi/hpsa.c > +++ b/drivers/scsi/hpsa.c > @@ -8651,6 +8651,7 @@ static void hpsa_shutdown(struct pci_dev *pdev) > h->access.set_intr_mask(h, HPSA_INTR_OFF); > hpsa_free_irqs(h); /* init_one 4 */ > hpsa_disable_interrupt_mode(h); /* pci_init 2 */ > + pci_disable_device(h->pdev); > } I suspect this will make things "work" (if the device can't attempt DMA, no Unsupported Request error will occur). But I'm concerned that the reason for the DMA might that hpsa is transferring buffers from system memory to the hpsa device, and if we arbitrarily terminate those transfers with pci_disable_device(), we may leave the hpsa device in an inconsistent state, e.g., with a dirty filesystem. But we really need guidance from an hpsa expert. I don't know the filesystem/SCSI/hpsa details. Bjorn