search for: 206837

Displaying 7 results from an estimated 7 matches for "206837".

Did you mean: 20637
2020 Jul 17
4
nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
...gain, but that's better than having > GPUs completely broken. > > Could you and Patrick open bugzilla.kernel.org reports, attach dmesg > logs and "sudo lspci -vv" output, and add the URLs to Kai-Heng's > original report at https://bugzilla.kernel.org/show_bug.cgi?id=206837 > and to this thread? > > There must be a way to fix the slow resume problem without breaking > the GPUs. > I wouldn't be surprised if this is related to the Intel bridge we check against for Nouveau.. I still have to check on another laptop with the same bridge our workaround w...
2020 Jul 16
3
nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst <kherbst at redhat.com> wrote: > > Hi everybody, > > with the mentioned commit Nouveau isn't able to load firmware onto the > GPU on one of my systems here. Even though the issue doesn't always > happen I am quite confident this is the commit breaking it. > > I am still digging into the issue and trying to figure out
2011 Jul 01
0
stringr 0.5
# stringr Strings are not glamorous, high-profile components of R, but they do play a big role in many data cleaning and preparations tasks. R provides a solid set of string operations, but because they have grown organically over time, they can be inconsistent and a little hard to learn. Additionally, they lag behind the string operations in other programming languages, so that some things that
2020 Jul 16
0
nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
...bolt-connected devices again, but that's better than having GPUs completely broken. Could you and Patrick open bugzilla.kernel.org reports, attach dmesg logs and "sudo lspci -vv" output, and add the URLs to Kai-Heng's original report at https://bugzilla.kernel.org/show_bug.cgi?id=206837 and to this thread? There must be a way to fix the slow resume problem without breaking the GPUs. Bjorn
2020 Jul 17
0
nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
...better than having >> GPUs completely broken. >> >> Could you and Patrick open bugzilla.kernel.org reports, attach dmesg >> logs and "sudo lspci -vv" output, and add the URLs to Kai-Heng's >> original report at https://bugzilla.kernel.org/show_bug.cgi?id=206837 >> and to this thread? >> >> There must be a way to fix the slow resume problem without breaking >> the GPUs. >> > >I wouldn't be surprised if this is related to the Intel bridge we >check against for Nouveau.. I still have to check on another laptop >w...
2020 Jul 17
0
nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
...er than having > > GPUs completely broken. > > > > Could you and Patrick open bugzilla.kernel.org reports, attach dmesg > > logs and "sudo lspci -vv" output, and add the URLs to Kai-Heng's > > original report at https://bugzilla.kernel.org/show_bug.cgi?id=206837 > > and to this thread? > > > > There must be a way to fix the slow resume problem without breaking > > the GPUs. > > > > I wouldn't be surprised if this is related to the Intel bridge we > check against for Nouveau.. I still have to check on another lapto...
2020 Jul 17
2
nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
...ain, but that's better than having > GPUs completely broken. > > Could you and Patrick open bugzilla.kernel.org reports, attach dmesg > logs and "sudo lspci -vv" output, and add the URLs to Kai-Heng's > original report at https://bugzilla.kernel.org/show_bug.cgi?id=206837 > and to this thread? > > There must be a way to fix the slow resume problem without breaking > the GPUs. Isn't it possible to tell whether a PCI device is connected through thunderbolt or not? We could probably get away with just defaulting to 100ms for thunderbolt devices withou...