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

[+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 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 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

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 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]

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 >

From: Lukas Wunner <lukas at wunner.de> The integrated HDA controller on Nvidia GPUs can be hidden with a bit in the GPU's config space. Information about this scheme was provided by NVIDIA on their forums. Many laptops now ship with this device hidden, meaning that Linux users of affected platforms (where the HDMI connector comes off the NVIDIA GPU) cannot use HDMI audio

From: Lukas Wunner <lukas at wunner.de> The integrated HDA controller on Nvidia GPUs can be hidden with a bit in the GPU's config space. Information about this scheme was provided by NVIDIA on their forums. Many laptops now ship with this device hidden, meaning that Linux users of affected platforms (where the HDMI connector comes off the NVIDIA GPU) cannot use HDMI audio

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

This reverts commit b516ea586d717472178e6ef1c152e85608b0ce32. While this fixes audio for a number of users, this commit has the sideaffect of breaking the BIOS workaround that's required to make the GPU on the nvidia P50 work, by causing the GPU's PCI device function to stop working after it's been set to multifunction mode. Signed-off-by: Lyude Paul <lyude at redhat.com>

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

Since quirk_nvidia_hda() was added there's now two nvidia device functions on any laptops with nvidia GPUs: the HDA controller, and the GPU itself. Unfortunately this has the sideaffect of breaking quirk_reset_lenovo_thinkpad_50_nvgpu() since pci_reset_function() was using pci_parent_bus_reset() to reset the GPU's respective PCI bus, and pci_parent_bus_reset() does not work on busses which

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

From: Chris Chiu <chiu at endlessm.com> This new graphics card was failing to initialize with nouveau due to an "unknown chipset" error. Copy the GP106 configuration and rename for GP107/NV137. We don't know for certain that this is fully correct, but brief desktop testing suggests this is working fine. Signed-off-by: Chris Chiu <chiu at endlessm.com> Signed-off-by:

On Fri, Aug 24, 2018 at 11:42 PM, Peter Wu <peter at lekensteyn.nl> wrote: > Are these systems also affected through runtime power management? For > example: > > modprobe nouveau # should enable runtime PM > sleep 6 # wait for runtime suspend to kick in > lspci -s1: # runtime resume by reading PCI config space > > On laptops from

[+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 over 40 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]

I am trying to transport a dd image between to hosts over a cross linked gigabit connection. Both hosts have an eth1 configured to a non routable ip addr on a shared network. No other devices exist on this link. When transferring via sftp I received a stall warning. Checking the logs I see this: dmesg | grep eth e1000e 0000:00:19.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:1c:c0:f2:1f:bb