search for: x542uq

...ub seems to have quite some > patches, one of them explicitly disable runtime PM: > https://github.com/endlessm/linux/commit/8b128b50cd6725eee2ae9025a1510a221d9b42f2 Yes, I checked for this issue in the past and I'm certain that nouveau runtime pm works fine. I also checked again now on X542UQ and the results are the same. nouveau can do runtime suspend/resume (confirmed by reading runtime_status) and then render 3D graphics OK. lspci is fine too. It is just S3 suspend that is affected. This was testing on Linux 4.18 unmodified. I had to set nouveau runpm parameter to 1 for it to use run...

...t; patches, one of them explicitly disable runtime PM: > > https://github.com/endlessm/linux/commit/8b128b50cd6725eee2ae9025a1510a221d9b42f2 > > Yes, I checked for this issue in the past and I'm certain that nouveau > runtime pm works fine. > > I also checked again now on X542UQ and the results are the same. > nouveau can do runtime suspend/resume (confirmed by reading > runtime_status) and then render 3D graphics OK. lspci is fine too. It > is just S3 suspend that is affected. This was testing on Linux 4.18 > unmodified. I had to set nouveau runpm parameter to...

...sly acknowledged this behaviour and the requirement to rewrite this register. https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23 Based on that, rewrite the prefetch register values even when that appears unnecessary. We have confirmed this solution on all the affected models we have in-hands (X542UQ, UX533FD, X530UN, V272UN). Additionally, this solves an issue where r8169 MSI-X interrupts were broken after S3 suspend/resume on Asus X441UAR. This issue was recently worked around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e"). It also fixes the same issue on RTL6186...

...sly acknowledged this behaviour and the requirement to rewrite this register. https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23 Based on that, rewrite the prefetch register values even when that appears unnecessary. We have confirmed this solution on all the affected models we have in-hands (X542UQ, UX533FD, X530UN, V272UN). Additionally, this solves an issue where r8169 MSI-X interrupts were broken after S3 suspend/resume on Asus X441UAR. This issue was recently worked around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e"). It also fixes the same issue on RTL6186...

..., but it definitely makes the issue go away. It's not just acting as some kind of memory barrier, because rewriting other bridge registers does not work around the issue. There's something magic in this particular register. We have confirmed this on all the affected models we have in-hands (X542UQ, UX533FD, X530UN, V272UN). Additionally, this workaround solves an issue where r8169 MSI-X interrupts were broken after S3 suspend/resume on Asus X441UAR. This issue was recently worked around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e"). It also fixes the same issue...

...n that works backwards from the > end of the PCI config space to the beginning, see > pci_restore_config_space. Do you have a dmesg where you see the > "restoring config space at offset" messages? Interesting, I had not spotted this code. The logs for the affected bridge on Asus X542UQ: 0000:00:1c.0: restoring config space at offset 0x3c (was 0x100, writing 0x1001ff) 0000:00:1c.0: restoring config space at offset 0x24 (was 0x10001, writing 0xe1f1d001) 0000:00:1c.0: restoring config space at offset 0x20 (was 0x0, writing 0xef00ee00) 0000:00:1c.0: restoring config space at off...

...5 Intel PCI bridges need quirking as below. > The quirk will run on bridges even where no nvidia GPU is connected, > but it should be harmless, and we at least limit it to only running > on Asus products. > > This fix was tested on all the affected models that we have in hands > (X542UQ, UX533FD, X530UN, V272UN). > > Signed-off-by: Daniel Drake <drake at endlessm.com> > --- > > Notes: > If anyone has ideas for why writing this register makes a difference, or > suggestions for other approaches then I'm all ears... > > Here is...

...gister. > > https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23 > > > > Based on that, rewrite the prefetch register values even when that > > appears unnecessary. > > > > We have confirmed this solution on all the affected models we have > > in-hands (X542UQ, UX533FD, X530UN, V272UN). > > > > Additionally, this solves an issue where r8169 MSI-X interrupts were > > broken after S3 suspend/resume on Asus X441UAR. This issue was recently > > worked around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on > > RTL810...

...bridge on each one, in total 5 Intel PCI bridges need quirking as below. The quirk will run on bridges even where no nvidia GPU is connected, but it should be harmless, and we at least limit it to only running on Asus products. This fix was tested on all the affected models that we have in hands (X542UQ, UX533FD, X530UN, V272UN). Signed-off-by: Daniel Drake <drake at endlessm.com> --- Notes: If anyone has ideas for why writing this register makes a difference, or suggestions for other approaches then I'm all ears... Here is some basic info of the 43 products believed t...

...ly kills the nvidia card in some way. After a lot of experimentation I found a workaround: during resume, set the value of PCI_PREF_BASE_UPPER32 to 0 on the parent PCI bridge. Easily done in drivers/pci/quirks.c. Now all nvidia stuff works fine. As an example of an affected product, take the Asus X542UQ (Intel KabyLake i7-7500U with Nvidia GeForce 940MX). The PCI bridge is: 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI Express Root Port [8086:9d10] (rev f1) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 120 Bus: primary=00, secondary=01, su...

...e > requirement to rewrite this register. > https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23 > > Based on that, rewrite the prefetch register values even when that > appears unnecessary. > > We have confirmed this solution on all the affected models we have > in-hands (X542UQ, UX533FD, X530UN, V272UN). > > Additionally, this solves an issue where r8169 MSI-X interrupts were > broken after S3 suspend/resume on Asus X441UAR. This issue was recently > worked around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on > RTL8106e"). It also fixes t...

...> requirement to rewrite this register. > https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23 > > Based on that, rewrite the prefetch register values even when that > appears unnecessary. > > We have confirmed this solution on all the affected models we have > in-hands (X542UQ, UX533FD, X530UN, V272UN). > > Additionally, this solves an issue where r8169 MSI-X interrupts were > broken after S3 suspend/resume on Asus X441UAR. This issue was recently > worked around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on > RTL8106e"). It also fixes...

...e > requirement to rewrite this register. > https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23 > > Based on that, rewrite the prefetch register values even when that > appears unnecessary. > > We have confirmed this solution on all the affected models we have > in-hands (X542UQ, UX533FD, X530UN, V272UN). > > Additionally, this solves an issue where r8169 MSI-X interrupts were > broken after S3 suspend/resume on Asus X441UAR. This issue was recently > worked around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on > RTL8106e"). It also fixes t...

On Sat, Sep 1, 2018 at 3:12 AM, Bjorn Helgaas <helgaas at kernel.org> wrote: > If true, this sounds like some sort of erratum, so it would be good to > get some input from Intel, and I cc'd a few Intel folks. Yes, it would be great to get their input. > It's interesting that all the systems below are from Asus. That makes > me think there's some BIOS or SMM

...0.0 NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 05) Under 00:1c.0, there is a wireless adapter. > As an example of an affected product, take the Asus X542UQ (Intel > KabyLake i7-7500U with Nvidia GeForce 940MX). The PCI bridge is: > > 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-LP PCI > Express Root Port [8086:9d10] (rev f1) (prog-if 00 [Normal decode]) > Flags: bus master, fast devsel, latency 0, IRQ 120 > Bus...

...; https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23 >>> >>> Based on that, rewrite the prefetch register values even when that >>> appears unnecessary. >>> >>> We have confirmed this solution on all the affected models we have >>> in-hands (X542UQ, UX533FD, X530UN, V272UN). >>> >>> Additionally, this solves an issue where r8169 MSI-X interrupts were >>> broken after S3 suspend/resume on Asus X441UAR. This issue was recently >>> worked around in commit 7bb05b85bc2d ("r8169: don't use MSI-X on >&...

...t; be misconfigured MTRR register or something like that. It may not be > related at all but it could be worth a try to dump out MTRR registers of > one of the affected systems and see if the memory areas are listed there > (and if the attributes are somehow wrong if found). >From Asus X542UQ: # cat /proc/mtrr reg00: base=0x0c0000000 ( 3072MB), size= 1024MB, count=1: uncachable reg01: base=0x0a0000000 ( 2560MB), size= 512MB, count=1: uncachable reg02: base=0x090000000 ( 2304MB), size= 256MB, count=1: uncachable reg03: base=0x08c000000 ( 2240MB), size= 64MB, count=1: uncachable reg0...

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