Bug 77361 - [nve7] nouveau not working on 3.13 linux kernel
Summary: [nve7] nouveau not working on 3.13 linux kernel
Status: RESOLVED WORKSFORME
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-12 10:22 UTC by sam.halliday
Modified: 2015-06-14 12:19 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
config (1.26 KB, text/plain)
2014-04-12 10:22 UTC, sam.halliday
no flags Details
error (5.93 KB, text/plain)
2014-04-12 10:23 UTC, sam.halliday
no flags Details
parameter=0 (88.51 KB, text/plain)
2014-04-13 00:00 UTC, sam.halliday
no flags Details
parameter=-1 (88.77 KB, text/plain)
2014-04-13 00:00 UTC, sam.halliday
no flags Details
X11 log, no xorg.conf (7.37 KB, text/plain)
2014-04-13 10:30 UTC, sam.halliday
no flags Details
dmesg when no xorg.conf used (88.70 KB, text/plain)
2014-04-13 10:30 UTC, sam.halliday
no flags Details
attachment-10557-0.html (2.39 KB, text/html)
2015-06-14 12:19 UTC, sam.halliday
no flags Details

Description sam.halliday 2014-04-12 10:22:45 UTC
Created attachment 97252 [details]
config

I tried raising this on the debian forum, but nobody had any ideas: http://forums.debian.net/viewtopic.php?f=6&t=112741

nouveau was working for me (but was fairly unstable) on a 3.12 Linux kernel (Debian Jessie). However, when I upgraded to 3.13 X11 failed to start.

My config file and the error log are attached.
Comment 1 sam.halliday 2014-04-12 10:23:13 UTC
Created attachment 97253 [details]
error
Comment 2 sam.halliday 2014-04-12 10:23:54 UTC
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)
Comment 3 Emil Velikov 2014-04-12 22:28:51 UTC
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.
Comment 4 sam.halliday 2014-04-12 22:49:24 UTC
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)
Comment 5 sam.halliday 2014-04-12 23:31:32 UTC
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.
Comment 6 sam.halliday 2014-04-12 23:34:36 UTC
(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)
Comment 7 Emil Velikov 2014-04-12 23:44:55 UTC
(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.
Comment 8 sam.halliday 2014-04-13 00:00:09 UTC
Created attachment 97288 [details]
parameter=0
Comment 9 sam.halliday 2014-04-13 00:00:26 UTC
Created attachment 97289 [details]
parameter=-1
Comment 10 sam.halliday 2014-04-13 00:00:53 UTC
cool, thanks. Turns out it was setting the flag correctly. dmesg files attached for both boots.
Comment 11 Emil Velikov 2014-04-13 00:05:18 UTC
(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
Comment 12 sam.halliday 2014-04-13 00:11:31 UTC
oh, sorry. that will take a little longer to sort out... debian jessie seems to no longer really support it.
Comment 13 Emil Velikov 2014-04-13 00:54:08 UTC
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.
Comment 14 sam.halliday 2014-04-13 10:30:14 UTC
Created attachment 97300 [details]
X11 log, no xorg.conf
Comment 15 sam.halliday 2014-04-13 10:30:41 UTC
Created attachment 97301 [details]
dmesg when no xorg.conf used
Comment 16 sam.halliday 2014-04-13 10:32:46 UTC
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.
Comment 17 sam.halliday 2014-04-13 10:44:28 UTC
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!
Comment 18 Emil Velikov 2014-04-13 11:07:20 UTC
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
Comment 19 sam.halliday 2014-04-13 11:23:33 UTC
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?
Comment 20 Emil Velikov 2014-04-13 12:04:38 UTC
(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.
Comment 21 Sven Joachim 2014-04-13 12:46:24 UTC
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.
Comment 22 Emil Velikov 2014-04-13 13:10:43 UTC
(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
Comment 23 Samuel Pitoiset 2015-06-03 13:25:50 UTC
Can you reproduce this issue with a more recent kernel?
If you no longer have the problem, this issue should be closed.
Comment 24 Samuel Pitoiset 2015-06-14 12:04:00 UTC
Feel free to re-open the issue if the bug still occurs.
Comment 25 sam.halliday 2015-06-14 12:19:34 UTC
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.