<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Nouveau not working on second monitor" href="https://bugs.freedesktop.org/show_bug.cgi?id=61731#c16">Comment # 16</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Nouveau not working on second monitor" href="https://bugs.freedesktop.org/show_bug.cgi?id=61731">bug 61731</a> from <a class="email" href="mailto:kyle.auble@zoho.com" title="Kyle Auble <kyle.auble@zoho.com>"> Kyle Auble</a> <pre>(In reply to Tobias Klausmann from <a href="show_bug.cgi?id=61731#c15">comment #15</a>) > Is this still a problem with a recent kernel? (3.17/3.18) I was actually trying to debug this driver-loading problem on & off for a while, and while I won't be running any more tests, I'd still like to see it resolved, if only for a sense of closure. The last test I ran was with v3.17-rc2 of the PAE kernel on Ubuntu 12.04, and the problem was still there at that point in time. I can't vouch for more recent changes though. One thing I eventually found out is that there's an even simpler workaround than unplugging the laptop during boot: try passing the "pci=bios" boot parameter to the kernel. I was keeping track of the tests at a Launchpad account, and I eventually sent a couple emails to the linux-pci mail list. You can tell I'm an amateur at systems debugging, especially in the beginning, but all those records are here: <a href="https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1009312">https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1009312</a> <a href="http://thread.gmane.org/gmane.linux.kernel.pci/33181">http://thread.gmane.org/gmane.linux.kernel.pci/33181</a> <a href="http://thread.gmane.org/gmane.linux.kernel.pci/34437">http://thread.gmane.org/gmane.linux.kernel.pci/34437</a> As for what causes it, I made several guesses that all eventually turned out wrong. It's just one more guess, but based on everything I figured out through the tests, I think there's some kind of race happening in or between the kernel & the BIOS pci initialization code. The earliest symptom in the logs is that there will be a ~30 ms gap between these two lines in dmesg (from the original reporter's in this thread): > [ 0.379459] pci 0000:01:00.0: reg 30: [mem 0x00000000-0x0001ffff pref] > [ 0.408041] pci 0000:00:01.0: PCI bridge to [bus 01-01] I think that's due to a timeout in pci link-retraining, but using an initscript to dump the GPU's pci config, I was able to find out that something is accidentally resetting or turning off the GPU prior to that. A race condition in the pci initialization might explain why the bug is intermittent and also why it's much more common in the x32 kernel (the smaller word length leading to more machine instructions something could wedge between?) I think the unplugging trick works by putting the PCI bus into a power-saving mode, which slows down the initialization enough to avoid a race.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>