Bug 27501

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.

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.

Created attachment 34863 [details]
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).

Is this still an issue with recent nouveau code? Does Ubuntu still needs the noaccel hack to get the MacBooks running?

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....

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?

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....

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

Created attachment 48817 [details]
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.

Can you get a mmiotrace that includes starting X?  The binary driver doesn't really do anything at modprobe time, unlike nouveau.

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

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

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

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).

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

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?

> 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.

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.

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.

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.

(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

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.

Does it work with nouveau.force_post=1 in kernel command line, by any chance?

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.

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.

*** Bug 58556 has been marked as a duplicate of this bug. ***

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@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"),
+                    },
+        },
+
        {}
 };

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.

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.

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

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).

*** Bug 26546 has been marked as a duplicate of this bug. ***

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] [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.

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.

(In reply to comment #34)
> Created attachment 106803 [details] [review] [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.

Created attachment 106804 [details] [review]
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.

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.

(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

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!

Created attachment 106977 [details]
dmesg 9400 w/ accel + gdm

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! :)

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. :/

(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.

(In reply to thomas from comment #43)
> (In reply to Pierre Moreau from comment #42)
> > Created attachment 107262 [details] [review] [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.

(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.

(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.

(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

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.

(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.

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.

(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.

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!

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.

(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.

(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.

Created attachment 109963 [details]
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.

Created attachment 109964 [details]
9600M GT dmesg

Attaching dmesg for 'modprobe nouveau' for 9600M GT

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.

(In reply to Pierre Moreau from comment #58)
> Created attachment 110350 [details] [review] [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

Created attachment 110376 [details] [review]
[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.

Patch was merged. I'll close the bug report once a version containing the patch is released.

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.

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).