Summary: | [nve7] nouveau not working on 3.13 linux kernel | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | sam.halliday | ||||||||||||||||
Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> | ||||||||||||||||
Status: | RESOLVED WORKSFORME | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||||||
Severity: | normal | ||||||||||||||||||
Priority: | medium | CC: | alexngould | ||||||||||||||||
Version: | unspecified | ||||||||||||||||||
Hardware: | Other | ||||||||||||||||||
OS: | All | ||||||||||||||||||
See Also: | http://bugs.debian.org/740953 | ||||||||||||||||||
Whiteboard: | |||||||||||||||||||
i915 platform: | i915 features: | ||||||||||||||||||
Attachments: |
|
Description
sam.halliday
2014-04-12 10:22:45 UTC
Created attachment 97253 [details]
error
you probably want an lspci, so here you go: 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09) 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) 00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4) 00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 (rev c4) 00:1c.4 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 (rev c4) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a4) 00:1f.0 ISA bridge: Intel Corporation Z77 Express Chipset LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) 01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 640M Mac Edition] (rev a1) 01:00.1 Audio device: NVIDIA Corporation GK107 HDMI Audio Controller (rev a1) 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM57766 Gigabit Ethernet PCIe (rev 01) 03:00.1 SD Host controller: Broadcom Corporation NetXtreme BCM57765 Memory Card Reader (rev 01) 04:00.0 Network controller: Broadcom Corporation BCM4331 802.11a/b/g/n (rev 02) AFAICS this is a one of the MBP machines with dual gpu/optimus. Does booting with nouveau.runpm=0 help ? Please you attach the output of dmesg for both kernels. I thought optimus was a laptop thing? The hardware is a 2013 iMac and I'm booting up in EFI mode. I'm not entirely sure how to add kernel options, as it is slightly convoluted on the mac (no grub) Hi Emil, is there a command I can put in an /etc/modprobe.d config file to enable this? Passing boot parameters is going to be extremely difficult on this machine. (I should note that I tried the obvious "options nouveau runpm=0" in /etc/modprobe.d/nouveau.conf and rebooted, but I'm not sure it was picked up) (In reply to comment #6) > (I should note that I tried the obvious "options nouveau runpm=0" in > /etc/modprobe.d/nouveau.conf and rebooted, but I'm not sure it was picked up) cat /sys/module/nouveau/parameters/runpm will help out (In reply to comment #3) > Please you attach the output of dmesg for both kernels. Even if the option module parameter does not help, the output of dmesg is essential. Created attachment 97288 [details]
parameter=0
Created attachment 97289 [details]
parameter=-1
cool, thanks. Turns out it was setting the flag correctly. dmesg files attached for both boots. (In reply to comment #10) > cool, thanks. Turns out it was setting the flag correctly. dmesg files > attached for both boots. So I take it that the options did not help ? NB: Both _kernels_ - the good (working) vs the bad (non working) one. Thanks oh, sorry. that will take a little longer to sort out... debian jessie seems to no longer really support it. Taking a closer look, it's almost impossible that the kernel is to blame here (esp considering the dmesg you've provided). The message "No devices detected" comes from the server whenever no screen are created (xf86NumScreens == 0). The latter is incremented when the xf86AllocateScreen(drv, flags ~XF86_ALLOCATE_GPU_SCREEN) helper is called, which is executed by the driver depending on the path chosen in xf86platformProbeDev(). Long story short, drop the xorg.conf, and double check what exactly did you update when the issue occurred. The Xorg.log you've attached here differs from the one in the debian forum, so I'm guessing something else got updated silently and you may have missed it. Created attachment 97300 [details]
X11 log, no xorg.conf
Created attachment 97301 [details]
dmesg when no xorg.conf used
Hi Emil, Yes the logs are probably different because I have done an apt-get upgrade since the last run. I'm not actively using that root mount, so I don't think I could have changed anything (but of course, all it takes is one unwitting package removal). I've attached the logs for when I don't have an xorg.conf. BTW, the xorg.conf was working for me before the kernel upgrade... and I can no longer use the older kernel as Jessie now only distributes the 13 line of kernels. I added all the X11 drivers back in and it still failed to start up. However, I was inspired to use the fbdev driver and it works... so at least I have a workaround to use Debian instead of the unmaintained Ubuntu that supports the NVIDIA drivers for this card! Hi Sam, If you're certain that the only thing that changed is the kernel then kernel bisection would our next step. The following command will start bisecting between 3.12 (good) and 3.13 (bad), for commits touch nouveau. $ git bisect v3.13 v3.12 -- drivers/gpu/drm/nouveau uugh, yeah that sounds nasty. I think I'll stick with the fbdev driver until I have some time do this. Thanks so much for your help so far. BTW, on both the nouveau and fbdev drivers, I get occassional horizontal lines flickering on the screen... is that a known glitch? (In reply to comment #19) > uugh, yeah that sounds nasty. > It sounds nastier than what it really is. All you need is "how to compile a kernel the debian way", and and to record the result after boot/testing the respective kernel - $ git bisect {good,bad}. Afaics it should take ~8 steps (reboots) to isolate the commit. > I think I'll stick with the fbdev driver until I have some time do this. > Btw. if you're betting on someone else to do the bisection you're in for some tough time. I've been using 3.13 kernel since 3.13.1 came out and I've never had such a problem. I'm betting that there is something subtle is your setup that is causing this. > Thanks so much for your help so far. > > BTW, on both the nouveau and fbdev drivers, I get occassional horizontal > lines flickering on the screen... is that a known glitch? Not entirely sure what you mean with the flicker there. If you're talking about tearing, yes that is kind of expected. The same problem has also been reported in the Debian BTS, one of the people who saw it claimed that unsetting CONFIG_X86_SYSFB when building the kernel helps: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740953#40 Note that Debian enabled CONFIG_X86_SYSFB in 3.13, in their 3.12 kernel it is not set. (In reply to comment #21) > The same problem has also been reported in the Debian BTS, one of the people > who saw it claimed that unsetting CONFIG_X86_SYSFB when building the kernel > helps: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740953#40 > > Note that Debian enabled CONFIG_X86_SYSFB in 3.13, in their 3.12 kernel it > is not set. Nice one Sven, I knew I've seen a similar issue but did not manage to find anything before. AFAIK some fb drivers have a quirk (pci_fixup_video) that sets up boot_vga=1, which is required by X. The sysfb is not aware about pci_fixup_video thus the issue. There is some more information in the patch [1] by Bruno. Feel free to give it a try. [1] http://lists.freedesktop.org/archives/dri-devel/2014-March/055798.html Can you reproduce this issue with a more recent kernel? If you no longer have the problem, this issue should be closed. Feel free to re-open the issue if the bug still occurs. Created attachment 116487 [details] attachment-10557-0.html Hi, I got the NVIDIA drivers to work so I haven't looked back. Good luck with the project, I really wish I could use it instead of the proprietary drivers. I'm never buying an NVIDIA card by choice. On 14 June 2015 at 13:04, <bugzilla-daemon@freedesktop.org> wrote: > Samuel Pitoiset <samuel.pitoiset@gmail.com> changed bug 77361 > <https://bugs.freedesktop.org/show_bug.cgi?id=77361> > What Removed Added Status NEW RESOLVED Resolution --- WORKSFORME > > *Comment # 24 <https://bugs.freedesktop.org/show_bug.cgi?id=77361#c24> > on bug 77361 <https://bugs.freedesktop.org/show_bug.cgi?id=77361> from > Samuel Pitoiset <samuel.pitoiset@gmail.com> * > > Feel free to re-open the issue if the bug still occurs. > > ------------------------------ > You are receiving this mail because: > > - You reported the bug. > > |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.