Nouveau - Apr 2010 - [Bug 27501] New: nVidia 9600M GT (Macbook Pro current model) is unable to boot

https://bugs.freedesktop.org/show_bug.cgi?id=27501

           Summary: nVidia 9600M GT (Macbook Pro current model) is unable
                    to boot
           Product: xorg
           Version: unspecified
          Platform: x86-64 (AMD64)
        OS/Version: Linux (All)
            Status: NEW
          Severity: critical
          Priority: medium
         Component: Driver/nouveau
        AssignedTo: nouveau at lists.freedesktop.org
        ReportedBy: cdotv.mail at googlemail.com
         QAContact: xorg-team at lists.x.org


Hello, I like to raise attention on this very important bug over here:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/546393

The Ubuntu Lucid Beta 1 onwards is unable to boot into the desktop because the
nouveau driver has a "pramin flush timeout" (check the video in post
#12).

Since Ubuntu is the most popular Linux distribution, this bug is very
important, since all MacBook Pro 5,x Models are unable to boot into the desktop
because nouveau is unable to load.

Further testing found out that adding "nouveau.noaccel=1
blacklist=vga16fb" as
kernel options helps booting the system.

Maybe you could fix this bug and enable nouveau.noaccel=1 as a standard if the
9600M GT nVidia card is detected.

Any other fix would be nice too, this is very important.

Thanks.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

cdotv.mail at googlemail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|medium                      |highest

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #1 from Christopher James Halse Rogers <chalserogers at
gmail.com> 2010-04-06 21:21:31 PDT ---
It's worth noting that this does not seem to prevent all macbooks from
booting
- the last comment on https://bugs.freedesktop.org/show_bug.cgi?id=18638
suggests that nouveau works for at least one macbook user.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #2 from cdotv.mail at googlemail.com 2010-04-08 03:41:44 PDT ---
Yes that's cause he is using Fedora, I'm talking about Ubuntu.

I also had no problems on fedora half a year ago, they seem to use extra code
for MacBook Pro detection.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #3 from Ricardo Salveti de Araujo <rsalveti at gmail.com>
2010-04-10 02:10:47 PDT ---
Created an attachment (id=34863)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=34863)
PRAMIN flush timout stack

Just tested with latest GIT revision available at Linus' tree
(0eddb519b9127c73d53db4bf3ec1d45b13f844d1). That's after merging the latest
drm/nouveau code, and I'm still facing this issue.

Probably this bug is only happening with MacBook Pro version.

My system:
 * MacBook Pro 5,1
 * Booting with normal bios mode (grub)
 * 02:00.0 VGA compatible controller [0300]: nVidia Corporation G96 [GeForce
9600M GT] [10de:0647] (rev a1) (prog-if 00 [VGA controller])

Tested with nomodeset but I ended up in another bug (acpi related).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #4 from Lucas Stach <dev at lynxeye.de> 2011-02-15 01:03:34
PST ---
Is this still an issue with recent nouveau code? Does Ubuntu still needs the
noaccel hack to get the MacBooks running?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #5 from Alex Murray <murray.alex at gmail.com> 2011-03-05
15:08:08 PST ---
The latest development version of Ubuntu (and hence I assume nouveau) still has
this bug - under Ubuntu Natty Alpha 3 I still need nouveau.noaccel=1 to boot
without hanging with a PRAMIN flush timeout on my MacBook Pro 5,1.

Any other info which is required to try and sort out this bug - would be great
to be able to get acceleration on my machine....

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #6 from Alex Murray <murray.alex at gmail.com> 2011-03-10
18:47:13 PST ---
I can also confirm the latest Fedora Alpha 15 LiveCD does not boot either
without nouveau.noaccel=1 - boot locks up with PRAMIN flush timeout as well.
Any chance this bug can get some attention?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #7 from Alex Murray <murray.alex at gmail.com> 2011-06-03
06:16:49 PDT ---
Nouveau still hard-locks with PRAMIN flush timeout on the MacBook Pro 5,1 with
NVIDIA 9600M GT in both Ubuntu Natty final and Fedora 15 Final - the only way
to work-around it is to add nouveau.noaccel=1 to the kernel command line. This
is a pretty long standing bug - any chance of some attention? I'd be happy
to
try and help debug it, I just don't know where to start....

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #8 from Emil Velikov <emil.l.velikov at gmail.com> 2011-06-18
07:58:29 PDT ---
Hi Alex

It may be worth grabbing a mmiotrace [1][2] of the blob

Thanks

[1] http://nouveau.freedesktop.org/wiki/MmioTrace
[2] https://wiki.ubuntu.com/X/MMIOTracing

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #9 from Alex Murray <murray.alex at gmail.com> 2011-07-06
06:41:02 PDT ---
Created an attachment (id=48817)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=48817)
mmiotrace of module load of binary nvidia driver on MacBookPro 5,1 (9600M GT)

Simply modprobing nouveau is enough to hang my machine, so attached is an
mmiotrace of the nvidia driver which does not hang it - hopefully this helps.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #10 from Ben Skeggs <skeggsb at gmail.com> 2011-07-07 17:03:26
PDT ---
Can you get a mmiotrace that includes starting X?  The binary driver doesn't
really do anything at modprobe time, unlike nouveau.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #11 from Alex Murray <murray.alex at gmail.com> 2011-07-07
17:24:59 PDT ---
Yep, will get it for you later tonight - also I've attached a couple[1][2]
captures of the dmesg output to the corresponding fedora version of this bug[3]
if its any help.

[1] https://bugzilla.redhat.com/attachment.cgi?id=511713
[2] https://bugzilla.redhat.com/attachment.cgi?id=511715
[3] https://bugzilla.redhat.com/show_bug.cgi?id=679583

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #12 from Alex Murray <murray.alex at gmail.com> 2011-07-08
05:27:24 PDT ---
I've put a gzipped mmiotrace of nvidia module load then xinit in my dropbox
[1]
- let me know if I can do anything else. Thanks again for looking at this Ben,
I really appreciate it.

[1] http://www.dropbox.com/s/f09sque4l92maqm/mmiotrace.log.gz

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

Viktor Basso <viktor.basso at linux.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |viktor.basso at linux.com

--- Comment #13 from Viktor Basso <viktor.basso at linux.com> 2011-08-23
13:42:54 PDT ---
Hello

I cant add much, but i am having the same problem with MacBook Pro 5,3.
Running 2.6.38-11-generic, and the 3.1 RC3 kernel compiled from git

Have gone back and fourth adding x-updates and xorg-edgers PPAs without any
luck

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #14 from Rolf Offermanns <rolf.offermanns at gmx.net>
2011-08-28 22:28:31 PDT ---
Same here: MacBook Pro (5,2) Ubuntu 11.10 alpha 3 and Fedora 16 alpha.

nouveau.noaccel=1 boots on Ubuntu for me, not tried that on Fedora yet. But
nomodeset works for both, although I am not able to resume from suspend then
(might be bug #38350).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #15 from Mateusz <tomodachi at fishface.se> 2011-11-14
02:48:42 PST ---


I'm using my macbook pro 5.1 with Ubuntu OneIric
(it has two cards  9600GT and a 9400 card)

With nouveau.

I'm booting of the 9400 card though in efi. Disabling the 9600GT card.
If you just want to a working graphical environment maybe that would be a work
around until this has been fixed

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #16 from Roland <rmueller83 at googlemail.com> 2012-02-06
10:11:45 PST ---
I have the same issue booting Arch Linux via EFI on a Macbook Pro 5,2 with
Kernel version 3.2.4.

Mateusz, how did you disable the 9600GT?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #17 from Joanand <MacGyver031 at web.de> 2012-02-17 03:11:41
PST ---
> Mateusz, how did you disable the 9600GT?
I am not Mateusz, but I have succeeded in getting nouveau working without any
parameters working by deactivating 9600M GT with gpupwr and loading nouveau
afterwards.

Otherwise my system crashes and the last message which is send to my central
syslog-server is:

2012-02-16 10:23:00    kernel  [drm] nouveau 0000:02:00.0: PRAMIN flush timeout
2012-02-16 10:23:00    kernel    [drm] nouveau 0000:02:00.0: PFIFO_INTR
0x04000000 - Ch 1
2012-02-16 10:23:00    kernel    [drm] nouveau 0000:02:00.0: PRAMIN flush
timeout
2012-02-16 10:23:00    kernel    [drm] nouveau 0000:02:00.0: PFIFO_INTR
0x04000000 - Ch 1
2012-02-16 10:23:00    kernel    [drm] Cannot find any crtc or sizes - going
1024x768
2012-02-16 10:23:00    kernel    No connectors reported connected with modes
2012-02-16 10:23:00    kernel    [drm] No driver support for vblank timestamp
query.
2012-02-16 10:23:00    kernel    [drm] Supports vblank timestamp caching Rev 1
(10.10.2010).
2012-02-16 10:23:00    kernel    [drm] nouveau 0000:02:00.0: PRAMIN flush
timeout
2012-02-16 10:23:00    kernel    [drm] nouveau 0000:02:00.0: 512 MiB GART
(aperture)
2012-02-16 10:23:00    kernel    [drm] nouveau 0000:02:00.0: Detected 256MiB
VRAM
2012-02-16 10:23:00    kernel    [TTM] Initializing pool allocator.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #18 from Joanand <MacGyver031 at web.de> 2012-02-17 07:53:08
PST ---
I now have found out that using Kernel-3.2.6, and starting with elilo (grub2
with efi has similar result) having both Adapters working, on has to  use the
parameters noaccel=1 and nofbaccel=1 so that the driver is loaded. It will find
both adapters, the screen will be scrambled in console (I have not started X,
because I need the acceleration, or the driver will be of no use).

So to sum up:
Either you want 9400M with acceleration then:
use gpupwr to disable the 9600M GT and load nouveau without any parameters. The
console will be visible then and one can use X.

Or (I have no idea why someone would need this, but for the sake of
documentation):
load nouveau with noaccel=1 and nofbaccel=1.

So for the moment it looks like acceleration-code for 9600M GT seems to be
broken, as well as vga_switcheroo.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #19 from Roland <rmueller83 at googlemail.com> 2012-02-19
02:22:47 PST ---
Thanks! Blacklisting the nouveau module during bootup and afterwards running
gpupwr and modprobing the module works for me.

In the Ubuntu docs there are some "outb" commands for grub which
should switch the GPU: https://help.ubuntu.com/community/UEFIBooting
But my grub rejects these outb commands as unknown.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #20 from Shea Levy <shea at shealevy.com> 2012-03-19 22:11:57
PDT ---
FWIW, I'm seeing this bug as well. Using Linux 3.3, both when EFI booting
(through the EFI boot stub) and when BIOS booting. I have a MBP 5,5. I'm
currently using fbdev for X, I'll try some of the workarounds here to see if
a
non-accelerated nouveau works at least.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #21 from Shea Levy <shea at shealevy.com> 2012-03-20 10:26:24
PDT ---
(In reply to comment #20)
> FWIW, I'm seeing this bug as well. Using Linux 3.3, both when EFI
booting
> (through the EFI boot stub) and when BIOS booting. I have a MBP 5,5.
I'm
> currently using fbdev for X, I'll try some of the workarounds here to
see if a
> non-accelerated nouveau works at least.

Sorry, I have a 5,3 not a 5,5

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

John Flatness <john at zerocrates.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john at zerocrates.org

--- Comment #22 from John Flatness <john at zerocrates.org> 2012-07-24
18:31:40 PDT ---
Is there some kind of tracing or debugging people experiencing this problem can
do to help? It seems that the "full" mmiotrace of the blob loading
mentioned
above has succumbed to bitrot.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #23 from Marcin Slusarz <marcin.slusarz at gmail.com>
2012-07-24 21:13:53 PDT ---
Does it work with nouveau.force_post=1 in kernel command line, by any chance?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #24 from John Flatness <john at zerocrates.org> 2012-07-25
18:56:51 PDT ---
force_post=1 caused the screen to blank out (which isn't normally what
happens), but the system still appeared to hang in basically the same way as
without that option.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #25 from Jamie Macdonald <jamie.alban at gmail.com> ---
On my Macbook Pro 5,2 (early 2009) with 9400M and 9600M GT, I also have this
bug. nouveau freezes the computer after kernel module load with no extra
parameters.

Using nouveau.noaaccel=1, It boots with scrambled console to graphical openbox
session with artifacts at the top of the screen, but openbox is not functional
(I can only waive my cursor around).

Here: http://pastebin.com/4yhXK0Rt is output of dmesg after booting to
commandline with nouveau.noaccel=1

Here: http://ge.tt/8Cn0b0m/v/0 is an mmiotrace & dmesg & lspci from
starting
openbox session with the nvidia blob.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130717/d0afe83b/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

Emil Velikov <emil.l.velikov at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.freedesktop.or
                   |                            |g/show_bug.cgi?id=58556

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130724/8fa863b0/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |MacGyver031 at web.de

--- Comment #26 from Ilia Mirkin <imirkin at alum.mit.edu> ---
*** Bug 58556 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130821/e7c88c73/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #27 from Ilia Mirkin <imirkin at alum.mit.edu> ---
You guys are probably all aware of this, but it seems like one solution is to
have the bootloader kill the NV96 card on boot, if you're using grub2:

https://help.ubuntu.com/community/UEFIBooting#Selecting_the_graphic_card
http://askubuntu.com/questions/149921/how-to-add-a-command-permanently-to-grub2

One could also make an early quirk that does this as well based on a DMI match.
I wrote up a quick patch to do that, but it's completely untested (see
below).
I doubt it'd be upstream-appropriate though, as it would kill the
possibility
of using the second card entirely.

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 230c8ea..8cb7665 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1357,6 +1357,12 @@ static int __init dmi_ignore_irq0_timer_override(const
struct dmi_system_id *d)
        return 0;
 }

+static int __init disable_macbook_second_video(const struct dmi_system_id *d)
+{
+       outb(0, 0x750);
+       return 0;
+}
+
 /*
  * If your system is blacklisted here, but you find that acpi=force
  * works for you, please contact linux-acpi at vger.kernel.org
@@ -1432,6 +1438,15 @@ static struct dmi_system_id __initdata acpi_dmi_table[]
= {
                     DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 360"),
                     },
         },
+       {
+        .callback = disable_macbook_second_video,
+        .ident = "Apple MacBook5",
+        .matches = {
+                    DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
+                    DMI_MATCH(DMI_PRODUCT_NAME, "MacBook5"),
+                    },
+        },
+
        {}
 };

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130821/55f544cd/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|nVidia 9600M GT (Macbook    |MacBook Pro 5,x unable to
                   |Pro current model) is       |boot [NV96 + NVAC]
                   |unable to boot              |

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20130821/fd7457d8/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #28 from Pierre Moreau <pierre.morrow at free.fr> ---
I've made some progress on this bug, enabling Nouveau to be loaded with
acceleration enabled. However, X is **absolutely not** usable: complete garbage
screen, lots of Nouveau errors, only action available is power down the
computer (or reboot). But for using Nouveau with acceleration in console mode,
it works fine.

There are (at least) two main problems:

*   9400M acceleration is broken (resulting in Nouveau locking up on boot);
*   it seems there is a lockup when starting a working X with both cards
enabled.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140817/bf89ee12/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

Pierre Moreau <pierre.morrow at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #34863|0                           |1
        is obsolete|                            |

--- Comment #29 from Pierre Moreau <pierre.morrow at free.fr> ---
Created attachment 106246
  --> https://bugs.freedesktop.org/attachment.cgi?id=106246&action=edit
Temporary patch for 9400M GT acceleration

Could you please test this patch along with Ilia's one? It should fix
acceleration on the 9400M GT, allowing you to boot without nouveau.noaccel=1
and to launch X.

I'll need to refine the patch a bit as it introduces some errors on the
9600M.
Another patch may be mandatory to get both cards to get along: for now, the
laptop seems to be hitting an infinite loop when launching X with both cards
enabled.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140914/709a2649/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #30 from Rolf Offermanns <rolf.offermanns at gmx.net> ---
Pierre, the patch works for me (MacBookPro5,2). I had to modify Ilia's patch
to
have "MacBookPro5" in the DMI_MATCH instead of "MacBook5"
and now I can boot
into a KDE5 session with the nouveau driver. I checked the xorg log file and
verified that it is indeed using hardware accelaration.

I used a fresh git clone of Linus tree for the test.

Let me know if you need further information.

Thanks,
Rolf

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140915/b60e1f92/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #31 from Pierre Moreau <pierre.morrow at free.fr> ---
Awesome! Thanks for testing Rolf! I tested it on my laptop, but as it sometimes
behaves in a strange way, I preferred to get confirmation by at least someone
else. :)

I'll see later today if I can get both cards to get along without locking up
the GPU. Otherwise I'll try to get the patch into 3.17 (not sure if it's
still
possible).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140915/520a1205/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

Pierre Moreau <pierre.morrow at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugreports at nn7.de

--- Comment #32 from Pierre Moreau <pierre.morrow at free.fr> ---
*** Bug 26546 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140916/a1f83a85/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #33 from Joanand <MacGyver031 at web.de> ---
I confirm that the patch works, screen is NOT scrambled.
Unsing my ancient gpupwr-programm to deactivate 9600M, I am able to start
xorg-x11 + fluxbox with accleration.

Pierre, thank you very much.

I have seen that vga-switcheroo does not get started, probably due to the 9600M
fallen off the bus.

I cannot await your fix for 9600M with acceleration.

BR.

(In reply to comment #29)
> Created attachment 106246 [details] [review]
> Temporary patch for 9400M GT acceleration
> 
> Could you please test this patch along with Ilia's one? It should fix
> acceleration on the 9400M GT, allowing you to boot without
nouveau.noaccel=1
> and to launch X.
> 
> I'll need to refine the patch a bit as it introduces some errors on the
> 9600M.
> Another patch may be mandatory to get both cards to get along: for now, the
> laptop seems to be hitting an infinite loop when launching X with both
cards
> enabled.
-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140923/1de4643a/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #34 from Pierre Moreau <pierre.morrow at free.fr> ---
Created attachment 106803
  --> https://bugs.freedesktop.org/attachment.cgi?id=106803&action=edit
Option for disabling acceleration for given chipset

Rather than completely disabling the discrete card, disabling the acceleration
on that card also works. Use nouveau.chipsetnoaccel=0x96 in this case to
disable acceleration on the 9600M GT.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140924/00e48ac7/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #35 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to comment #34)
> Created attachment 106803 [details] [review]
> Option for disabling acceleration for given chipset
> 
> Rather than completely disabling the discrete card, disabling the
> acceleration on that card also works. Use nouveau.chipsetnoaccel=0x96 in
> this case to disable acceleration on the 9600M GT.
How about changing noaccel instead to optionally be able to take a list of pci
addresses? (Or even just one to start...) I think that would have a much higher
chance of being accepted upstream.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140924/99e53c42/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

Pierre Moreau <pierre.morrow at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #106246|0                           |1
        is obsolete|                            |

--- Comment #36 from Pierre Moreau <pierre.morrow at free.fr> ---
Created attachment 106804
  --> https://bugs.freedesktop.org/attachment.cgi?id=106804&action=edit
Fix acceleration on 9400M

This is the minimalistic version of the previous patch.

I'll send the patches to the list, and hopefully they can still be merged
into
3.17.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140924/4102e0d0/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #37 from Joanand <MacGyver031 at web.de> ---
Hi Pierre,
Both patches seems to work (tested 1x on 3.17.rc6). 

Xorg-x11 starts with fluxbox, messages show that 9600 is unacclerated and 9400
is acclerated. There is are two errors in your patch "option for disabling
accleration for given chipset":
* The entries DRM_DEBUG_DRIVER are not available on 3.17.rc6, but it works
either way.
* In the kernel < 3.17 it should be "if (nouveau_noaccel ||
!nouveau_fifo(device) /*XXX*/)" not only "if (nouveau_noaccel)"

Terminating xorg-x11 crashed, probably because I switched off discrete
graphichs adapter after starting xorg. Someone else should check.

Further testing is in queue.

The previous patch you have sent: It solved a problem I had in the past: System
kernel panics if the lid is closed during startup!

Thanks.

Do you think that acceleration for 9600M will be possible sometime?

BR.

(In reply to comment #36)
> This is the minimalistic version of the previous patch.
-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140925/692eab7c/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #38 from Pierre Moreau <pierre.morrow at free.fr> ---
(In reply to comment #37)
> Hi Pierre,
> Both patches seems to work (tested 1x on 3.17.rc6). 
> 
> Xorg-x11 starts with fluxbox, messages show that 9600 is unacclerated and
> 9400 is acclerated. There is are two errors in your patch "option for
> disabling accleration for given chipset":
> * The entries DRM_DEBUG_DRIVER are not available on 3.17.rc6, but it works
> either way.
> * In the kernel < 3.17 it should be "if (nouveau_noaccel ||
> !nouveau_fifo(device) /*XXX*/)" not only "if
(nouveau_noaccel)"
> 
> Terminating xorg-x11 crashed, probably because I switched off discrete
> graphichs adapter after starting xorg. Someone else should check.
> 
> Further testing is in queue.
> 
> The previous patch you have sent: It solved a problem I had in the past:
> System kernel panics if the lid is closed during startup!
> 
> Thanks.
> 
> Do you think that acceleration for 9600M will be possible sometime?
> 
> BR.
> 
> (In reply to comment #36)
> > This is the minimalistic version of the previous patch.
Hi Joanand,

I based my patches on the linux-3.18 branch of Nouveau's repo, which is more
up-to-date than 3.17-rc6: this explains the "if (nouveau_noaccel)" at
least.

Great for the kernel panic! I noticed that using the patches, screen resumes
correctly when resuming the computer, rather than staying completely black.

Well, I'll work 9600M Gt acceleration, but I can't say if I'll
succeed, nor
when. ;)

Best regards

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140925/4b852186/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #39 from thomas <gurutonic at gmail.com> ---
Pierre,

I have tested your patch with the 9400M in my macbookpro 5,2. The card boots
correctly with acceleration enabled, and loads GDM. GDM looks completely
correct, but hangs on login with a cursor on a grey screen. It's possible
that
LXDE, KDE, or some other DE might work, but gnome-shell never loads. I will try
slim/lxde when I get a chance.

At this point I can switch back to VT where I notice some nouveau errors in
dmesg. Killing GDM (and x11 with it) produces a kernel panic.

Next I booted with the 9600GT with acceleration disabled. The display looks
correct with efifb, but loading nouveau scrambles the VT.

Thank you for your efforts!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140928/cc776046/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #40 from thomas <gurutonic at gmail.com> ---
Created attachment 106977
  --> https://bugs.freedesktop.org/attachment.cgi?id=106977&action=edit
dmesg 9400 w/ accel + gdm

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140928/01410de7/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #41 from Pierre Moreau <pierre.morrow at free.fr> ---
Hi Thomas,

(In reply to comment #39)
> Pierre,
> 
> I have tested your patch with the 9400M in my macbookpro 5,2. The card
boots
> correctly with acceleration enabled, and loads GDM. GDM looks completely
> correct, but hangs on login with a cursor on a grey screen. It's
possible
> that LXDE, KDE, or some other DE might work, but gnome-shell never loads. I
> will try slim/lxde when I get a chance.
Oh... I didn't test with Gnome or KDE, as I'm using Awesome (which works
fine).
Maybe if you deactivate composing it will be better (as a temporary solution)?
I'm working on improving the patch: at the moment, it turns some bits on
(enabling some features?), but the blob also writes some things (feature
configuration?) before turning each bit on. So maybe finding what those things
are and implementing them will fix the errors.
> 
> At this point I can switch back to VT where I notice some nouveau errors in
> dmesg. Killing GDM (and x11 with it) produces a kernel panic.
> 
> Next I booted with the 9600GT with acceleration disabled. The display looks
> correct with efifb, but loading nouveau scrambles the VT.
I have seen it once or twice too, but not at each boot.
On a similar note, I sometime get PDISP errors about an unknown method when
loading Nouveau, but as it rarely happen, I haven't tried to fix it yet.
I'll
have a look at both errors later on.
> 
> Thank you for your efforts!
Thanks for testing! :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140928/4438b111/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

Pierre Moreau <pierre.morrow at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #106804|0                           |1
        is obsolete|                            |

--- Comment #42 from Pierre Moreau <pierre.morrow at free.fr> ---
Created attachment 107262
  --> https://bugs.freedesktop.org/attachment.cgi?id=107262&action=edit
Fix acceleration on 9400M v2

Here is an updated version of the patch.

Thomas,
Do you still get screen corruption with it? (I can't reliably reproduce the
screen corruption unfortunately.)
GDM seems to work fine on my laptop with only 9400M having acceleration
enabled. I'll try with 9600M GT acceleration enabled too. :/

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141003/3645fd44/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #43 from thomas <gurutonic at gmail.com> ---
(In reply to Pierre Moreau from comment #42)
> Created attachment 107262 [details] [review]
> Fix acceleration on 9400M v2
> 
> Here is an updated version of the patch.
> 
> Thomas,
> Do you still get screen corruption with it? (I can't reliably reproduce
the
> screen corruption unfortunately.)
> GDM seems to work fine on my laptop with only 9400M having acceleration
> enabled. I'll try with 9600M GT acceleration enabled too. :/
Hi Pierre,

I've applied your v2 patch and the results are similar. The 9400M works
correctly. GDM loads fine, but it won't start a gnome-shell session.
However,
SLIM works correctly and is able to load both gnome-shell and Awesome. I'm
writing this from gnome-shell now, and performance is good. I haven't had
any
screen corruption with the 9400M. I'll use this configuration for now and
report any issues I encounter.

The 9600M GT (acceleration disabled) still has corruption in VT as before, but
this time the screen blanks when X is loaded.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141003/8d558abf/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #44 from Pierre Moreau <pierre.morrow at free.fr> ---
(In reply to thomas from comment #43)
> (In reply to Pierre Moreau from comment #42)
> > Created attachment 107262 [details] [review] [review]
> > Fix acceleration on 9400M v2
> > 
> > Here is an updated version of the patch.
> > 
> > Thomas,
> > Do you still get screen corruption with it? (I can't reliably
reproduce the
> > screen corruption unfortunately.)
> > GDM seems to work fine on my laptop with only 9400M having
acceleration
> > enabled. I'll try with 9600M GT acceleration enabled too. :/
> 
> Hi Pierre,
> 
> I've applied your v2 patch and the results are similar. The 9400M works
> correctly. GDM loads fine, but it won't start a gnome-shell session.
> However, SLIM works correctly and is able to load both gnome-shell and
> Awesome. I'm writing this from gnome-shell now, and performance is
good. I
> haven't had any screen corruption with the 9400M. I'll use this
> configuration for now and report any issues I encounter.
> 
> The 9600M GT (acceleration disabled) still has corruption in VT as before,
> but this time the screen blanks when X is loaded.
Hi Thomas,

Good to hear you can use gnome-shell! :)

By
> I haven't had any screen corruption with the 9400M.
do you mean with the 9600M GT completely disabled?

When using the 9600M GT without acceleration, do you have screen corruption in
VT each time? If so, could you try to modify the patch a bit, like:
- removing the write to 0x100c1c;
- if removing the write doesn't work, changing the offset applied to
priv->r100c08 maybe testing all 4-multiples should do it, from 0 to 28.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141003/872ef7bf/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #45 from thomas <gurutonic at gmail.com> ---
(In reply to Pierre Moreau from comment #44)
> 
> Hi Thomas,
> 
> Good to hear you can use gnome-shell! :)
> 
> By
> > I haven't had any screen corruption with the 9400M.
> do you mean with the 9600M GT completely disabled?
> 
I use the efi stub loader with refind bootloader. Refind doesn't have an
option
to use outb as in grub. I have set OSX preferences to "battery
saving", so that
the firmware sets up the 9400 initially, but the 9600 is still technically
enabled. It shows up in lspci, etc. Whenever I test the 9600, I change the
setting in OSX back to "performance". So yes, with both cards enabled,
the 9400
works without corruption.
> When using the 9600M GT without acceleration, do you have screen corruption
> in VT each time? If so, could you try to modify the patch a bit, like:
> - removing the write to 0x100c1c;
> - if removing the write doesn't work, changing the offset applied to
> priv->r100c08 maybe testing all 4-multiples should do it, from 0 to 28.
I've only tested the 9600 about 10 times, but I've always had
corruption. I
will try your changes and see if it makes a difference.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141003/d30bc469/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #46 from thomas <gurutonic at gmail.com> ---
(In reply to thomas from comment #45)
> (In reply to Pierre Moreau from comment #44)
> > When using the 9600M GT without acceleration, do you have screen
corruption
> > in VT each time? If so, could you try to modify the patch a bit, like:
> > - removing the write to 0x100c1c;
> > - if removing the write doesn't work, changing the offset applied
to
> > priv->r100c08 maybe testing all 4-multiples should do it, from 0 to
28.
> 
> I've only tested the 9600 about 10 times, but I've always had
corruption. I
> will try your changes and see if it makes a difference.
No change, unfortunately. I first removed the write, then tried each of the
offsets.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141003/937fb51c/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #47 from Pierre Moreau <pierre.morrow at free.fr> ---
(In reply to thomas from comment #46)
> (In reply to thomas from comment #45)
> > (In reply to Pierre Moreau from comment #44)
> > > When using the 9600M GT without acceleration, do you have screen
corruption
> > > in VT each time? If so, could you try to modify the patch a bit,
like:
> > > - removing the write to 0x100c1c;
> > > - if removing the write doesn't work, changing the offset
applied to
> > > priv->r100c08 maybe testing all 4-multiples should do it, from
0 to 28.
> > 
> > I've only tested the 9600 about 10 times, but I've always had
corruption. I
> > will try your changes and see if it makes a difference.
> 
> No change, unfortunately. I first removed the write, then tried each of the
> offsets.
After switching to "Higher Performances" in OS X, I understand what
you were
explaining to me about having both cards enabled but having corrupted screen
only in one case. With that in mind, tweaking the patch can't fix the
corruption as we are modifying things on the 9400M but it's the 9600M GT
which
is responsible for displaying; I suggest opening another bug report for that.

I'll continue working on this patch and find how to use 0x100c1c before
switching to the 9600M GT.

Some side notes about what is wrong with the 9600M GT:
- screen corruption when using it to drive the display
- interrupt 0x04000000 + lockup when starting X with acceleration on for 9400M
and 9600M GT, and the 9400M is driving the screen
- when powering it down using vgaswitcheroo:
  * if accel isn't enabled:
    E[   PDISP][0000:02:00.0][0xc000887d][ffff880137b94400] fini: 0x490e0008
    E[   PDISP][0000:02:00.0][0xc000887d][ffff880137b94400] failed suspend, -16
  * if accel is enabled:
    flush timeout + (interrupt 0x04000000 iirc) + lockup

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141004/2c812ed6/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #48 from Ratchanan Srirattanamet <peathot at hotmail.com> ---
Will Pierre Moreau's patch be merged? This patch fix acceleration on system
with only 9400M too. Symptom is X can start but gets locked up when I run
glxgears for a while. System is Ubuntu 14.10 with Linux 3.17 compiled from git.
After apply this patch, the symptom disappear.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141010/5bfebe24/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #49 from Pierre Moreau <pierre.morrow at free.fr> ---
(In reply to Ratchanan Srirattanamet from comment #48)
> Will Pierre Moreau's patch be merged? This patch fix acceleration on
system
> with only 9400M too. Symptom is X can start but gets locked up when I run
> glxgears for a while. System is Ubuntu 14.10 with Linux 3.17 compiled from
> git. After apply this patch, the symptom disappear.
Hi Ratchanan,

My patch wasn't merged into 3.17 as it was a bit too short before the
release,
plus it didn't had time to be properly tested on other machines to check if
it
didn't introduce some regressions; I'll use the extra time to
reverse-engineer
the registers I modify. However it should be able to go into 3.18 if
reverse-engineering goes well.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141012/47d8a44e/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #50 from Joanand <MacGyver031 at web.de> ---
Hi Pierre,
My Macbook Pro 5,1 died two weeks ago. The screen backlight flickered and after
reboot there was no screen at all.
An attempt to find the dead chip was unsuccessful (fuse is ok) so I think after
6 years of MacBook is to move on.
It has been a fun and frustrating time with *unsupported* hardware.

I cannot be able to contribute to this project (as a tester).

Thank you so much for the support and good luck.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141108/08331bea/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

l3iggs <j at greyltc.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |j at greyltc.com

--- Comment #51 from l3iggs <j at greyltc.com> ---
(In reply to Pierre Moreau from comment #49)
> My patch wasn't merged into 3.17 as it was a bit too short before the
> release, plus it didn't had time to be properly tested on other
machines to
> check if it didn't introduce some regressions; I'll use the extra
time to
> reverse-engineer the registers I modify. However it should be able to go
> into 3.18 if reverse-engineering goes well.
I would LOVE to see a fix for this merged into 3.18. Please let me know if I
can help at all. I have a MacBook Pro 5,1 that exhibits this bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141120/7c25376f/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #52 from l3iggs <j at greyltc.com> ---
I have a MacBook Pro 5,1 which has two GPUs: GeForce 9600M GT and GeForce
9400M.


Here is what happens when I 'insmod nouveau' while running Linux 3.18
rc5 on my
system: http://hastebin.com/qusumotusi.m

I hope that helps!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141121/d58a1ebe/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #53 from Pierre Moreau <pierre.morrow at free.fr> ---
Hi,

@Joanand
Sorry for not fixing the issue before your MBP died... I hope your next laptop
will have better support.

@l3iggs
The RE revealed nothing interesting. I'll try again when I can manage to
spare
some time. I asked the Nvidia guys about it, it should help getting a better
patch.
I guess you set 'Better Performances' in Mac OS before getting that
dmesg. In
that case the 9600M GT is driving the screen, and with acceleration enabled
causes this issue (you can try without acceleration, but you'll get another
issue ;) ). You should fill a bug report for that issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141121/7507ac47/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #54 from l3iggs <j at greyltc.com> ---
(In reply to Pierre Moreau from comment #53)
> @l3iggs
> The RE revealed nothing interesting. I'll try again when I can manage
to
> spare some time. I asked the Nvidia guys about it, it should help getting a
> better patch.
Great, thank you for your effort here! I'm more than happy to test anything
you
come up with and provide any feed back I can.
> I guess you set 'Better Performances' in Mac OS before getting that
dmesg.
> In that case the 9600M GT is driving the screen, and with acceleration
> enabled causes this issue (you can try without acceleration, but you'll
get
> another issue ;) ). You should fill a bug report for that issue.
I actually haven't installed OSX on this machine in years. I assume it's
in
high performance mode. I've actually been trying to switch over to the low
power GPU in my testing here with no success. So I'm not having too much
success with many of the workarounds & patches posted in this thread. Am I
correct in understanding that you think I should start another bug report with
this trace? Does that mean this bug report is only concerned with issues when
running from the 9400M then?

I'll keep trying to produce some more info relevant to this bug by working
on
getting switched over to my 9400M.

Does anyone know if it's possible to switch from "9600M GT mode"
to "9400M
mode" without using OSX? I've tried several of the mysterious outb grub
directives. "outb 0x750 0" turns my screen off (I assume that's
shutting off
the 9600M GT) but I can't seem to enable/switch to the 9400M to get the
screen
back on.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141121/de3b821d/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #55 from Pierre Moreau <pierre.morrow at free.fr> ---
(In reply to l3iggs from comment #54)
> (In reply to Pierre Moreau from comment #53)
> > @l3iggs
> > The RE revealed nothing interesting. I'll try again when I can
manage to
> > spare some time. I asked the Nvidia guys about it, it should help
getting a
> > better patch.
> Great, thank you for your effort here! I'm more than happy to test
anything
> you come up with and provide any feed back I can.
> > I guess you set 'Better Performances' in Mac OS before getting
that dmesg.
> > In that case the 9600M GT is driving the screen, and with acceleration
> > enabled causes this issue (you can try without acceleration, but
you'll get
> > another issue ;) ). You should fill a bug report for that issue.
> I actually haven't installed OSX on this machine in years. I assume
it's in
> high performance mode. I've actually been trying to switch over to the
low
> power GPU in my testing here with no success. So I'm not having too
much
> success with many of the workarounds & patches posted in this thread.
Am I
> correct in understanding that you think I should start another bug report
> with this trace? Does that mean this bug report is only concerned with
> issues when running from the 9400M then?
I just opened a bug report for it: #86537. Everyone here has at least the
9400M, but nor necessarily the 9600M GT, and as both issues are different, it
seems better to focus this one on the 9400M and open another one for the other
card, rather than vice-versa.
> 
> I'll keep trying to produce some more info relevant to this bug by
working
> on getting switched over to my 9400M.
> 
> Does anyone know if it's possible to switch from "9600M GT
mode" to "9400M
> mode" without using OSX? I've tried several of the mysterious outb
grub
> directives. "outb 0x750 0" turns my screen off (I assume
that's shutting off
> the 9600M GT) but I can't seem to enable/switch to the 9400M to get the
> screen back on.
The gmux is probably configured differently. You can have a look at this
utility https://gfx.io/ code, as it can switch from integrated to discrete, and
back.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141121/aa2879b3/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #56 from l3iggs <j at greyltc.com> ---
Created attachment 109963
  --> https://bugs.freedesktop.org/attachment.cgi?id=109963&action=edit
9400M dmesg

What follows is my partially working workaround for my 9400M in my MacBook Pro
5,1. For my fully working workaround for my 9600M GT see
https://bugs.freedesktop.org/show_bug.cgi?id=86537

The following was tested with a kernel 3.18-rc6 (without applying any of the
patches here):

(1) Append 'modprobe.blacklist=nouveau' to the kernel boot parameters
This allows the system to boot.
(2) Once booted, as root, reset the 9400M GPU: 'echo 1 >
/sys/bus/pci/devices/0000:03:00.0/reset'
(3) 'echo 1 > /sys/bus/pci/devices/0000:03:00.0/rescan'
(4) 'echo 1 > /sys/bus/pci/devices/0000:02:00.0/remove'
This completely removes the 9600M GT GPU from the system so nouveau does not
use in when we load the module in the next step.
(5) 'modprobe nouveau'

where
0000:03:00.0 is the PCI address of my 9400M
and
0000:02:00.0 is the PCI address of my 9600M GT.

Nouveau seemingly loads fine for the 9400M, however I find myself unable to
actually use my 9400M GPU for anything (while repeating the same above steps
for my 9600M GT works fine). For example, starting gdm with the 9400M does
nothing. I believe this is because the 9400M GPU is not "connected" to
any
display (since it was not selected in OSX). I've attached dmesg logs for
loading nouveau for each of the GPUs in my laptop here. Notice that for the
working 9600M GT, the log shows:
nouveau  [     DRM] allocated 1440x900 fb: 0x70000, bo ffff88014750d400
1449x900 is the native resolution of my laptop's display.

while for the non-working 9400M, the log shows:
nouveau 0000:03:00.0: No connectors reported connected with modes
[drm] Cannot find any crtc or sizes - going 1024x768
nouveau  [     DRM] allocated 1024x768 fb: 0x50000, bo ffff88014715a400

I think I'm pretty close to having a universal working solution for both
GPUs
here. Does anyone know how I can "connect" my 9400M GPU with my
display?

I've tried fiddling a bit with xrandr after loading nouveau for the 9400M,
but
it seems to always report no displays found.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141124/a4d25da4/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #57 from l3iggs <j at greyltc.com> ---
Created attachment 109964
  --> https://bugs.freedesktop.org/attachment.cgi?id=109964&action=edit
9600M GT dmesg

Attaching dmesg for 'modprobe nouveau' for 9600M GT

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141124/86af2a42/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

Pierre Moreau <pierre.morrow at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #107262|0                           |1
        is obsolete|                            |

--- Comment #58 from Pierre Moreau <pierre.morrow at free.fr> ---
Created attachment 110350
  --> https://bugs.freedesktop.org/attachment.cgi?id=110350&action=edit
[Patch] Fix acceleration on 9400M v4

This should be the final verson of this patch, thanks to answers given by the
Nvidia guys.

Please check that you can use the NVAC with acceleration. If you want to start
X or power off the NV96 (if you have one), you will either need to deactivate
acceleration for it (noaccel=0000:02:00.0) or use the trick describe by l3iggs
**before** loading Nouveau.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141202/e88752ef/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #59 from l3iggs <j at greyltc.com> ---
(In reply to Pierre Moreau from comment #58)
> Created attachment 110350 [details] [review]
> [Patch] Fix acceleration on 9400M v4
> 
> This should be the final verson of this patch, thanks to answers given by
> the Nvidia guys.
> 
> Please check that you can use the NVAC with acceleration. If you want to
> start X or power off the NV96 (if you have one), you will either need to
> deactivate acceleration for it (noaccel=0000:02:00.0) or use the trick
> describe by l3iggs **before** loading Nouveau.
Thanks very much for your work on this Pierre (and thanks to your Nvidia
contacts too). With your previous patch, my NVAC was able to start a fully
accelerated gnome session via X, although it was very unstable and was quite
unusable (however, weston seemed to work fine for me with that patch). With
this latest patch, things seem quite stable. I'm writing this from a
google-chrome browser in gnome-shell/X and generally things seem to be working
so far.

~l3iggs

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141202/5c293ebd/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

Pierre Moreau <pierre.morrow at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #110350|0                           |1
        is obsolete|                            |

--- Comment #60 from Pierre Moreau <pierre.morrow at free.fr> ---
Created attachment 110376
  --> https://bugs.freedesktop.org/attachment.cgi?id=110376&action=edit
[Patch v4.5] Enable non-isometric poller

Sorry, there is a new version of the patch to test.
The fix is still the same, but it integrates better with the rest of the code.
It still works on my laptop but it is best to have some more reports.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141202/daf2d562/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #61 from Pierre Moreau <pierre.morrow at free.fr> ---
Patch was merged. I'll close the bug report once a version containing the
patch
is released.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20141216/1178d11c/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

Pierre Moreau <pierre.morrow at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #62 from Pierre Moreau <pierre.morrow at free.fr> ---
Patch is now present in 3.19-rc4, closing this bug report as solved.

For those who have the NV96 along the NVAC, you need to use l3iggs technique
and reset+rescan (echo 1 > /sys/bus/pci/devices/0000:02:00.0/{reset,rescan})
the NV96 **before** loading Nouveau to avoid a hang when starting X and another
hang when trying to power off the NV96.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150112/0e8dc40a/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=27501

--- Comment #63 from Pierre Moreau <pierre.morrow at free.fr> ---
For those with a dual card setup (NVAC + NV96), you should follow bug 86537 if
you want updates on fixing the NV96. Unfortunately there hasn't been much
progress, apart from finding that changing some register's value makes it
work
(most likely by disabling some things, so it is not a valid fix).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20150705/c8097798/attachment.html>