mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Matthew Garrett <mjg@redhat.com>
Cc: Khalid Aziz <khalid.aziz@hp.com>,
	linux-kernel@vger.kernel.org, bhelgaas@google.com,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH] Disable Bus Master on PCI device shutdown
Date: Wed, 6 Jun 2012 21:50:34 +0100	[thread overview]
Message-ID: <20120606215034.257d7549@pyramind.ukuu.org.uk> (raw)
In-Reply-To: <20120606135009.GB1517@srcf.ucam.org>

> This protects against the case where a piece of hardware is continuing 
> to DMA even after the driver shutdown method has been called? I'm not 

It doesn't. We also have hardware which craps itself if you clear the bus
mastering bit and we have platforms where the BIOS gets most upset if you
do that on suspend paths. There are also lots of devices that simply
ignore the bus mastering bit !

> convinced this is safe. Some Broadcom parts will crash if busmastering 
> is disabled while they're still performing DMA, and they'll then hang 
> the bus if reenabled.

This is very common, disabling the bus master bit isn't exactly a
tested or well defined pathway. A lot of device FIFOs will also happily
belch out their queue when you flip the bit. So it might look like
progress but it probably isn't.

Unfortunately if you've got a device peeing into memory you need to fix
the driver, or sometimes the firmware. You can probably use the IOMMU for
some protection on newer systems.

And then you get things like the CS5520 where disabling bus mastering on
the IDE controller crashes the machine, and some UMA video devices that
honour the bit for video fetch.

>From the IDE experience you really need to be careful here. Changing the
default is asking for nasty and weird regressions.

This isn't a fix, its a band aid to cover over broken driver shutdown
methods. Those driver shutdown methods need fixing.

Alan

  parent reply	other threads:[~2012-06-06 20:47 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-27 19:00 Khalid Aziz
2012-05-03 23:52 ` Bjorn Helgaas
2012-05-04 17:15   ` Bjorn Helgaas
2012-06-06 13:50 ` Matthew Garrett
2012-06-06 16:17   ` Khalid Aziz
2012-06-06 16:27     ` Matthew Garrett
2012-06-06 17:32       ` Khalid Aziz
2012-06-06 17:42         ` Matthew Garrett
2012-06-06 18:07           ` Khalid Aziz
2012-06-06 19:42             ` Eric W. Biederman
2012-06-06 20:09               ` Matthew Garrett
2012-06-07 17:43                 ` Khalid Aziz
2012-06-07 14:21               ` Khalid Aziz
2012-06-06 20:16             ` Myron Stowe
2012-06-06 23:03               ` Khalid Aziz
2012-06-06 23:18                 ` Myron Stowe
2012-06-06 20:50   ` Alan Cox [this message]
2012-06-07 17:07     ` Andi Kleen
2012-06-07 17:13       ` Alan Cox
2012-06-07 17:36       ` Khalid Aziz
2012-06-07 17:08   ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120606215034.257d7549@pyramind.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=bhelgaas@google.com \
    --cc=khalid.aziz@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mjg@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®