similar to: [PATCH v2] PCI: Reprogram bridge prefetch registers on resume

On 38+ Intel-based Asus products, the nvidia GPU becomes unusable after S3 suspend/resume. The affected products include multiple generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs many errors such as: fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04 [HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown] DRM: failed to idle channel 0 [DRM]

[+cc LKML] On Tue, Sep 18, 2018 at 04:32:44PM -0500, Bjorn Helgaas wrote: > On Thu, Sep 13, 2018 at 11:37:45AM +0800, Daniel Drake wrote: > > On 38+ Intel-based Asus products, the nvidia GPU becomes unusable > > after S3 suspend/resume. The affected products include multiple > > generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs > > many errors such

On Wed, Sep 12, 2018 at 8:45 AM Daniel Drake <drake at endlessm.com> wrote: > > On 38+ Intel-based Asus products, the nvidia GPU becomes unusable > after S3 suspend/resume. The affected products include multiple > generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs > many errors such as: > > fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR]

On Thu, Sep 13, 2018 at 5:37 AM Daniel Drake <drake at endlessm.com> wrote: > > On 38+ Intel-based Asus products, the nvidia GPU becomes unusable > after S3 suspend/resume. The affected products include multiple > generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs > many errors such as: > > fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR]

On Thu, Sep 13, 2018 at 11:37:45AM +0800, Daniel Drake wrote: > On 38+ Intel-based Asus products, the nvidia GPU becomes unusable > after S3 suspend/resume. The affected products include multiple > generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs > many errors such as: > > fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04 >

Am 27.09.18 um 22:52 schrieb Bjorn Helgaas: > [+cc LKML] > > On Tue, Sep 18, 2018 at 04:32:44PM -0500, Bjorn Helgaas wrote: >> On Thu, Sep 13, 2018 at 11:37:45AM +0800, Daniel Drake wrote: >>> On 38+ Intel-based Asus products, the nvidia GPU becomes unusable >>> after S3 suspend/resume. The affected products include multiple >>> generations of nvidia GPUs

I have created https://bugzilla.kernel.org/show_bug.cgi?id=201069 to archive the research done so far. On Fri, Sep 7, 2018 at 11:05 PM, Peter Wu <peter at lekensteyn.nl> wrote: > Windows 10 unconditionally rewrites these registers (BAR, I/O Base + > Limit, Memory Base + Limit, etc. from top to bottom), see annotations: > https://www.spinics.net/lists/linux-pci/msg75856.html >

On 38+ Intel-based Asus products, the nvidia GPU becomes unusable after S3 suspend/resume. The affected products include multiple generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs many errors such as: fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04 [HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown] DRM: failed to idle channel 0 [DRM]

On Sun, Sep 30, 2018 at 5:07 AM Thomas Martitz <kugel at rockbox.org> wrote: > The latest iteration does not work on my HP system. The GPU fails to > power up just like the unpatched kernel. That's weird, I would not expect a behaviour change in the latest patch. pci_restore_config_dword() has some debug messages, could you please make them visible and show logs again? Also remind

Hi Thomas, On Mon, Oct 01, 2018 at 04:25:06PM +0200, Thomas Martitz wrote: > Am 01.10.18 um 06:57 schrieb Daniel Drake: > > On Sun, Sep 30, 2018 at 5:07 AM Thomas Martitz <kugel at rockbox.org> wrote: > > > The latest iteration does not work on my HP system. The GPU fails to > > > power up just like the unpatched kernel. > > > > That's weird, I

[+cc LKML, Dave, Luming] On Fri, Sep 07, 2018 at 05:05:15PM +0200, Peter Wu wrote: > On Fri, Sep 07, 2018 at 01:36:14PM +0800, Daniel Drake wrote: > <..> > > Thomas Martitz reports that this workaround also solves an issue where > > the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive > > after S3 suspend/resume. > > Where was this claimed? It

On Fri, Sep 07, 2018 at 01:36:14PM +0800, Daniel Drake wrote: <..> > Thomas Martitz reports that this workaround also solves an issue where > the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive > after S3 suspend/resume. Where was this claimed? It is not stated in the linked bug: (https://bugs.freedesktop.org/show_bug.cgi?id=105760 > On resume, reprogram the

Am 01.10.18 um 06:57 schrieb Daniel Drake: > On Sun, Sep 30, 2018 at 5:07 AM Thomas Martitz <kugel at rockbox.org> wrote: >> The latest iteration does not work on my HP system. The GPU fails to >> power up just like the unpatched kernel. > > That's weird, I would not expect a behaviour change in the latest > patch. pci_restore_config_dword() has some debug

Am 02.10.18 um 22:03 schrieb Bjorn Helgaas: > Hi Thomas, > > On Mon, Oct 01, 2018 at 04:25:06PM +0200, Thomas Martitz wrote: >> Am 01.10.18 um 06:57 schrieb Daniel Drake: >>> On Sun, Sep 30, 2018 at 5:07 AM Thomas Martitz <kugel at rockbox.org> wrote: >>>> The latest iteration does not work on my HP system. The GPU fails to >>>> power up just

hello, I''m running XEN 2.0 on IBM ThinkPad T23. Now the weird thing is that I get two different outputs from /sbin/lspci depending on whether I run 2.6.8.1-xen0 or 2.6.8.1-bproc. In particular the output from 2.6.8.1-xen0 seems to be missing those 4 lines 0000:00:01.0 PCI bridge: Intel Corp. 82830 830 Chipset AGP Bridge (rev 02) 0000:00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI

On Mon, 29 Aug 2016 21:52:20 -0600 Alex Williamson <alex.williamson at redhat.com> wrote: > On Mon, 29 Aug 2016 21:23:25 -0600 > Alex Williamson <alex.williamson at redhat.com> wrote: > > > On Tue, 30 Aug 2016 05:27:17 +0300 > > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > > > Modern virtio pci devices can set

On Mon, 29 Aug 2016 21:52:20 -0600 Alex Williamson <alex.williamson at redhat.com> wrote: > On Mon, 29 Aug 2016 21:23:25 -0600 > Alex Williamson <alex.williamson at redhat.com> wrote: > > > On Tue, 30 Aug 2016 05:27:17 +0300 > > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > > > Modern virtio pci devices can set

On Fri, Sep 7, 2018 at 2:40 PM, Sinan Kaya <okaya at kernel.org> wrote: > On 9/6/2018 10:36 PM, Daniel Drake wrote: >> >> + if (pci_dev->class == PCI_CLASS_BRIDGE_PCI << 8) >> + pci_setup_bridge_mmio_pref(pci_dev); > > > This should probably some kind of a quirk rather than default > for the listed card as it sounds like you are

Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone. This does that. Compile tested only, but I'd seriously wonder if this broke anything. Suggested-by: Dave Miller <davem at davemloft.net> Signed-off-by: Wilfried Klaebe <w-lkml at lebenslange-mailadresse.de> --- Applies against v3.15-rc4. diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c

Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone. This does that. Compile tested only, but I'd seriously wonder if this broke anything. Suggested-by: Dave Miller <davem at davemloft.net> Signed-off-by: Wilfried Klaebe <w-lkml at lebenslange-mailadresse.de> --- Applies against v3.15-rc4. diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c