Comment on attachment 20470 [details]
X log of the nouveau fail on 

Oh- it seems the final error message is "failed to allocate memory for framebuffer".  Which is strange, as the machine has 4 gigs in it and process monitors show only about 500megs total in use including disk buffers.

Part of the problem is that we don't have any microcode copied for your card (type 0xAC). For that you need a mmio-trace and someone bored enough to extract it. I'm curious if your card works with the nv driver (the 0xAA have problems).

OK, no problem.  I'm willing to do that.

It does "work" to some extent with the proprietary driver (that is, I get nice
video), but I don't get external display output (but have only really tried 
from the GUI tool; I didn't go into the xorg.conf file).

I will be on the IRC channel today; you can guide me through capturing 
whatever info you need.

   - Bill

Created attachment 20493 [details]
Xorg.0.log of

Just FYI, since I just tried, the current drm git (b48bd3a036efa3c3aa759759a5be4f80f1c3ac72) and nouveau git (31c9958779d95ae84993f4772607367927a0e313) doesn't work, but for me it just disables the X server and nothing crashes. The kernel also printed some warnings, will attach complete log of both.

Mind you, my memory was fragmented enough yesterday that an order-5 allocation failed, I didn't see a memory allocation failure here though.

Created attachment 21433 [details]
X and kernel log

Oh, and regarding the question about nv, it doesn't work. I can provide a log, but I remember that I explicitly needed to enable "vesa" to get output at all.

Your 9400 seems to have the same problem as the 8200/8300, they are a type of onboard chip we are not familiar with. I'm inclined to wait until nv works with them.

I provide a mmiotrace for 9400M and via HDMI->HDMI connected LCD:

http://www.file-upload.net/download-1947951/9400M-HDMI-mmiotrace.tar.gz.html (~ 12 MiB)

I know it is not for a Macbook but it should also help; it could also be helpful for bug #23373...

Because it seems that there are currently problems with this chipset on all systems I am truncating the bug to "nouveau fails on GeForce 9400M" and changing priority to "high"...

If you need more mmiotraces I can provide them also for DVI->HDMI, DVI->VGA and VGA->VGA (via specific cables...).

Hello all! I have a Macbook 5,1 ; and I would love to see nouveau working on it. I am willing to put some effort into getting an mmiotrace if it will be helpful. Currently when I run: 

echo mmiotrace > /sys/kernel/debug/tracing/current_tracer
bash: echo: write error: Invalid argument

it fails; as you can see. This command is run in a `sudo -s` shell.

Let me know if you can help/if I should persevere.

(In reply to comment #10)
> 
> echo mmiotrace > /sys/kernel/debug/tracing/current_tracer
> bash: echo: write error: Invalid argument

This should mean that mmiotrace support has not been compiled into the kernel. Check that CONFIG_MMIOTRACE is enabled: Kernel hacking -> Tracers [*] -> Memory mapped IO tracing.

Okay... I have finally had time to compile my own kernel (based upon Ubuntu 2.6.31 configuration). It is the first time I have done so; but all seems to be working well.

I have generated the MMIO trace for just starting X; since this is probably going to be cleaner than starting GDM/GNOME. I did generate that as well, just in case you want it later.

The marker indicating that X has fully loaded (after which I had to switch to a virtual terminal and login; which may cause some extraneous debug output; I do not know) is "X is up".

I will try to attach the 19 MB file below.

Okay... that was bound to fail.

Please find the trace file at;

http://www.matthewwardrop.co.cc/tracing.txt.tar.bz2

Note: this trace was run on Ubuntu using a custom kernel based on settings from the default 2.6.31-14 kernel in Karmic (i.e. 2.6.31.4). It traces the starting of an empty X session using the proprietary nVidia drivers 185.18.36 as packaged in Ubuntu. The hardware being used is the MacBook 5,1 ; with nVidia 9400m.

I also uploaded the GDM trace:
http://www.matthewwardrop.co.cc/tracing-gdm.txt.tar.bz2
The details are the same as above, but instead of starting an empty session, I started GDM/GNOME with compiz enabled, etc.

I do hope this helps; for I'd love to run nouveau on my MacBook.

I ought also to add that I had an external monitor plugged into the mini-displayport connector; but that it was disabled.

Kind Regards,
Matthew

Created attachment 30698 [details]
Xorg.0.log

Current Xorg.0.log - git20091024

Created attachment 30699 [details]
dmesg

Current dmesg output - git20091024

According to Ben Skeggs these types of cards, eg the onboard 0xAx cards (8200, 8300, some 9400, g102 iirc) will not run with userspace modesetting mode. Please add modeset=1 to the nouveau module parameters to switch to kernel modesetting.

KMS and X work if I set nouveau.modeset=1 as boot parameter.

dmesg then:
[    0.000000] Unknown boot option `nouveau.modeset=1': ignoring

If I leave it blank or set modeset=1 KMS/X does not work...

On my Laptop with ATI/AMD Radeon 9000 (M9) KMS is working if I set modeset=1, radeon.modeset=1 or leave it blank.

It is stupid and annoying if you do not know this...

Setting modeset=1 and nouveau.modeset=1 does not help the driver to run properly on MacBook 5,1; although it appeared to detect my external monitor automatically (artifacts displayed on both screens).

=(

Kind Regards,
Matthew

I just installed Fedora 12 (which uses nouveau and KMS) on my MacBook this week-end and here's the status: the driver seems to basically work, however it's crashes during resume (making it very hard to use on a laptop).

I filed a bug with the resume crash data in Fedora's bugzilla, should I post it here too? Or maybe this bug should be closed as it seems nouveau is working on the 9400M and handle the resume failure in another bug?

Closing this as fixed, since we have at least one report of nouveau working on this chipset.