From: Daniel Drake <drake-6IF/jdPJHihWk0Htik3J/w@public.gmane.org> To: Sinan Kaya <okaya-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: Mika Westerberg <mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>, Linux PM <linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Wysocki, Rafael J" <rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org, Keith Busch <keith.busch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>, Linux Upstreaming Team <linux-6IF/jdPJHihWk0Htik3J/w@public.gmane.org>, davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org, Jon Derrick <jonathan.derrick-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org Subject: Re: [PATCH] PCI: Reprogram bridge prefetch registers on resume Date: Fri, 7 Sep 2018 16:06:19 +0800 [thread overview] Message-ID: <CAD8Lp466EffdgL5zVZi-L+s78Yxa9+FryB8ch1=UAwwCPqu9Ag@mail.gmail.com> (raw) In-Reply-To: <3b37e4fd-c793-bd52-7d70-950f846a7d5a-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> On Fri, Sep 7, 2018 at 2:40 PM, Sinan Kaya <okaya@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 dealing with > broken hardware. With that approach there's a sizeable list that your quirk list is incomplete or out of date. And when the bug bites, it's extremely cryptic. We've spent months working on this issue and only found this magic register write mostly through a stroke of good luck. Separately there's been a flurry of mails around the r8169 MSI-X problem but as far as I can see nobody suggested even looking at the values of the parent bridge prefetch registers. And even if they did, they'd probably have said "values are fine, nothing to see here" (exactly as we did 4 months ago when Nvidia mentioned these registers as a possible cause - oops!). So here I'm instead following a suggestion from Bjorn, after also having confirmed the windows behaviour: https://marc.info/?l=linux-pci&m=153574276126484&w=2 > Can we tell whether Windows rewrites this register unconditionally at > resume-time? If so, it may be more robust for Linux to do the same. > The whole thing is black magic, which I hate, but if it's our only > choice, it may be better to have this applied everywhere so we don't > keep stubbing our toes on new systems that require the quirk. Also, we just spoke to Asus BIOS engineers who told us that the BIOS does already restore the PCI bridge prefetch registers on resume. I guess this is why the other registers like the (non-zero) prefetch base address lower 32 bits do have the right value on resume even before my patch. It sounds like a more subtle bug related to register write timing or sequence, in that case it will be harder to define who is responsible for the breakage and hence under which conditions the quirk should apply. Daniel _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Drake <drake@endlessm.com> To: Sinan Kaya <okaya@kernel.org> Cc: Bjorn Helgaas <bhelgaas@google.com>, linux-pci@vger.kernel.org, Linux Upstreaming Team <linux@endlessm.com>, nouveau@lists.freedesktop.org, Linux PM <linux-pm@vger.kernel.org>, Peter Wu <peter@lekensteyn.nl>, kherbst@redhat.com, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, "Wysocki, Rafael J" <rafael.j.wysocki@intel.com>, Keith Busch <keith.busch@intel.com>, Mika Westerberg <mika.westerberg@linux.intel.com>, Jon Derrick <jonathan.derrick@intel.com>, Thomas Martitz <kugel@rockbox.org>, davem@davemloft.net, hkallweit1@gmail.com, netdev@vger.kernel.org, nic_swsd@realtek.com Subject: Re: [PATCH] PCI: Reprogram bridge prefetch registers on resume Date: Fri, 7 Sep 2018 16:06:19 +0800 [thread overview] Message-ID: <CAD8Lp466EffdgL5zVZi-L+s78Yxa9+FryB8ch1=UAwwCPqu9Ag@mail.gmail.com> (raw) In-Reply-To: <3b37e4fd-c793-bd52-7d70-950f846a7d5a@kernel.org> On Fri, Sep 7, 2018 at 2:40 PM, Sinan Kaya <okaya@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 dealing with > broken hardware. With that approach there's a sizeable list that your quirk list is incomplete or out of date. And when the bug bites, it's extremely cryptic. We've spent months working on this issue and only found this magic register write mostly through a stroke of good luck. Separately there's been a flurry of mails around the r8169 MSI-X problem but as far as I can see nobody suggested even looking at the values of the parent bridge prefetch registers. And even if they did, they'd probably have said "values are fine, nothing to see here" (exactly as we did 4 months ago when Nvidia mentioned these registers as a possible cause - oops!). So here I'm instead following a suggestion from Bjorn, after also having confirmed the windows behaviour: https://marc.info/?l=linux-pci&m=153574276126484&w=2 > Can we tell whether Windows rewrites this register unconditionally at > resume-time? If so, it may be more robust for Linux to do the same. > The whole thing is black magic, which I hate, but if it's our only > choice, it may be better to have this applied everywhere so we don't > keep stubbing our toes on new systems that require the quirk. Also, we just spoke to Asus BIOS engineers who told us that the BIOS does already restore the PCI bridge prefetch registers on resume. I guess this is why the other registers like the (non-zero) prefetch base address lower 32 bits do have the right value on resume even before my patch. It sounds like a more subtle bug related to register write timing or sequence, in that case it will be harder to define who is responsible for the breakage and hence under which conditions the quirk should apply. Daniel
next prev parent reply other threads:[~2018-09-07 8:06 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-07 5:36 [PATCH] PCI: Reprogram bridge prefetch registers on resume Daniel Drake 2018-09-07 5:36 ` Daniel Drake 2018-09-07 5:49 ` [Nouveau] " Lukas Wunner 2018-09-07 6:40 ` Sinan Kaya [not found] ` <3b37e4fd-c793-bd52-7d70-950f846a7d5a-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 2018-09-07 8:06 ` Daniel Drake [this message] 2018-09-07 8:06 ` Daniel Drake [not found] ` <20180907053614.6540-1-drake-6IF/jdPJHihWk0Htik3J/w@public.gmane.org> 2018-09-07 15:05 ` Peter Wu 2018-09-07 15:05 ` Peter Wu 2018-09-07 22:26 ` Bjorn Helgaas 2018-09-08 12:14 ` Peter Wu 2018-09-08 11:05 ` Thomas Martitz 2018-09-08 11:05 ` Thomas Martitz 2018-09-11 3:35 ` Daniel Drake 2018-09-11 3:35 ` Daniel Drake 2018-09-11 9:08 ` Rafael J. Wysocki 2018-09-10 19:57 ` Thomas Martitz 2018-09-10 19:57 ` Thomas Martitz 2018-09-07 21:48 ` Bjorn Helgaas
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='CAD8Lp466EffdgL5zVZi-L+s78Yxa9+FryB8ch1=UAwwCPqu9Ag@mail.gmail.com' \ --to=drake-6if/jdpjhihwk0htik3j/w@public.gmane.org \ --cc=andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \ --cc=bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \ --cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \ --cc=hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=jonathan.derrick-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \ --cc=keith.busch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \ --cc=linux-6IF/jdPJHihWk0Htik3J/w@public.gmane.org \ --cc=linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \ --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org \ --cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \ --cc=okaya-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \ --cc=rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.