Bug 29171 - Garbled console on Macbook 13" (6,1 9400M]) when using EFI
Summary: Garbled console on Macbook 13" (6,1 9400M]) when using EFI
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: 7.5 (2009.10)
Hardware: All Linux (All)
: medium major
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-20 06:57 UTC by Felix Leimbach
Modified: 2011-02-20 13:33 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Kernel config for EFI boot (65.34 KB, text/plain)
2010-07-20 06:57 UTC, Felix Leimbach
no flags Details
Xorg log from starting X with the NV driver. Hangs with black screen (15.64 KB, text/plain)
2010-07-20 12:19 UTC, Felix Leimbach
no flags Details
dmesg of the trace in comment #8 (60.00 KB, text/plain)
2010-07-21 13:03 UTC, Felix Leimbach
no flags Details
EVO channel init modifications (6.05 KB, patch)
2010-07-21 19:45 UTC, Ben Skeggs
no flags Details | Splinter Review
dmesg output with evo patch (60.84 KB, text/plain)
2010-07-21 22:58 UTC, Felix Leimbach
no flags Details
dmesg output with evo patch (real) (60.82 KB, text/plain)
2010-07-22 10:55 UTC, Felix Leimbach
no flags Details
Xorg.log after crash (17.48 KB, text/plain)
2010-08-04 11:03 UTC, Felix Leimbach
no flags Details
Updated version that applies to git from 2010-08-06 (6.05 KB, patch)
2010-08-06 01:56 UTC, Felix Leimbach
no flags Details | Splinter Review
OOPS with 2.6.36 (60.82 KB, text/plain)
2010-10-21 13:50 UTC, Felix Leimbach
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Leimbach 2010-07-20 06:57:57 UTC
Created attachment 37238 [details]
Kernel config for EFI boot

On my macbook 13" (late 2009, 6,1) with a GeForce 9400M (0x0ac180b1) when booting nouveaufb kicks in and displays a garbled screen. Mostly black, some greenish lines, some very unreadable text.

Interestingly, that only happens when I use the Macbook's native EFI mode (i.e. *without* BIOS emulation).
If I use the BIOS emulation then nouveau works.

Typing blindly, I extracted the dmesg output, from an EFI boot:

#grep -i -e drm -e nouv -e fb efi-dmesg
Kernel command line: BOOT_IMAGE=/boot/experimental root=/dev/sda5 video=efifb reboot=pci
efifb: probing for efifb
efifb: framebuffer at 0xc0010000, mapped to 0xffffc90004580000, using 6400k, total 6400k
efifb: mode is 1280x800x32, linelength=8192, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
fb0: EFI VGA frame buffer device
[drm] Initialized drm 1.1.0 20060810
nouveau 0000:02:00.0: enabling device (0002 -> 0003)
nouveau 0000:02:00.0: PCI INT A -> Link[LGPU] -> GSI 16 (level, low) -> IRQ 16
nouveau 0000:02:00.0: setting latency timer to 64
[drm] nouveau 0000:02:00.0: Detected an NV50 generation card (0x0ac180b1)
fb: conflicting fb hw usage nouveaufb vs EFI VGA - removing generic driver
[drm] nouveau 0000:02:00.0: Attempting to load BIOS image from ACPI
[drm] nouveau 0000:02:00.0: ... BIOS signature not found
[drm] nouveau 0000:02:00.0: Attempting to load BIOS image from PRAMIN
[drm] nouveau 0000:02:00.0: ... appears to be valid
[drm] nouveau 0000:02:00.0: BIT BIOS found
[drm] nouveau 0000:02:00.0: Bios version 62.79.77.00
[drm] nouveau 0000:02:00.0: TMDS table revision 2.0 not currently supported
[drm] nouveau 0000:02:00.0: Found Display Configuration Block version 4.0
[drm] nouveau 0000:02:00.0: Raw DCB entry 0: 01000123 00010014
[drm] nouveau 0000:02:00.0: Raw DCB entry 1: 02021232 00000010
[drm] nouveau 0000:02:00.0: Raw DCB entry 2: 02021286 0f220010
[drm] nouveau 0000:02:00.0: Raw DCB entry 3: 0000000e 00000000
[drm] nouveau 0000:02:00.0: DCB connector table: VHER 0x40 5 16 4
[drm] nouveau 0000:02:00.0:   0: 0x00000040: type 0x40 idx 0 tag 0xff
[drm] nouveau 0000:02:00.0:   1: 0x0000a146: type 0x46 idx 1 tag 0x08
[drm] nouveau 0000:02:00.0: Parsing VBIOS init table 0 at offset 0xDC70
[drm] nouveau 0000:02:00.0: Parsing VBIOS init table 1 at offset 0xDF48
[drm] nouveau 0000:02:00.0: Parsing VBIOS init table 2 at offset 0xDF4A
[drm] nouveau 0000:02:00.0: Parsing VBIOS init table 3 at offset 0xE00B
[drm] nouveau 0000:02:00.0: Parsing VBIOS init table 4 at offset 0xE0D0
[drm] nouveau 0000:02:00.0: Parsing VBIOS init table at offset 0xE135
[drm] nouveau 0000:02:00.0: 0xE135: Condition still not met after 20ms, skipping following opcodes
[drm] nouveau 0000:02:00.0: Couldn't find matching output script table
[drm] nouveau 0000:02:00.0: 0xC88E: parsing output script 0
[drm] nouveau 0000:02:00.0: 0xCB5A: parsing output script 0
[drm] nouveau 0000:02:00.0: Detected 256MiB VRAM
[drm] nouveau 0000:02:00.0: Stolen system memory at: 0x0070000000
[drm] nouveau 0000:02:00.0: 512 MiB GART (aperture)
[drm] nouveau 0000:02:00.0: Allocating FIFO number 1
[drm] nouveau 0000:02:00.0: nouveau_channel_alloc: initialised FIFO 1
[drm] nouveau 0000:02:00.0: Detected a LVDS output
[drm] nouveau 0000:02:00.0: Detected a TMDS output
[drm] nouveau 0000:02:00.0: Detected a DP output
[drm] nouveau 0000:02:00.0: Detected a LVDS connector
[drm] nouveau 0000:02:00.0: Detected a DisplayPort connector
[drm] nouveau 0000:02:00.0: timeout: (0x610200 & 0x1e0000) != 0
[drm] nouveau 0000:02:00.0: 0x610200 = 0x0c052b08
[drm] nouveau 0000:02:00.0: timeout: (0x610200 & 0x1e0000) == 0
[drm] nouveau 0000:02:00.0: 0x610200 = 0x0c050008
[drm] nouveau 0000:02:00.0: nouveau_channel_free: freeing fifo 1
nouveau 0000:02:00.0: PCI INT A disabled
nouveau: probe of 0000:02:00.0 failed with error -16

Kernel version: 2.6.35-rc3 (config attached)
Distribution: Gentoo

What's wrong? Let me know if you need anything, can even provide shell access if need be.
Comment 1 Marcin Slusarz 2010-07-20 11:43:30 UTC
efifb->nouveau handover seems to work. Probably efifb overwrote some important memory region which nouveau does not initialize/know about.

The code which is printing these "timeout: (0x610200 & 0x1e0000) != 0" comes from nv (bug 12637), so I'm wondering: does xf86-video-nv (without nouveau kernel module) work?
Comment 2 Felix Leimbach 2010-07-20 12:17:49 UTC
> The code which is printing these "timeout: (0x610200 & 0x1e0000) != 0" comes
> from nv (bug 12637), so I'm wondering: does xf86-video-nv (without nouveau
> kernel module) work?

It does *not* work. After booting into runlevel 2 and running startx the screen turned black and stayed black. Networking was still alive and I saved the Xorg.0.log.

So only the proprietary driver works :-(
Comment 3 Felix Leimbach 2010-07-20 12:19:07 UTC
Created attachment 37250 [details]
Xorg log from starting X with the NV driver. Hangs with black screen
Comment 4 Felix Leimbach 2010-07-20 12:33:53 UTC
Interestingly, if I boot a kernel which only has vesafb (i.e. not efifb) I get the exact same result: Console is fine, starting X with the nv driver produces black screen and hang.
Comment 5 Felix Leimbach 2010-07-20 12:36:25 UTC
Another interesting tidbit: While X works well with the proprietary driver the consoles (efifb) stay black once X started. I.e pressing ctrl+alt+f1 gives a black screen (but typing blindly works) and pressing crtl+alt+f7 brings me back to the X session.
Comment 6 Marcin Slusarz 2010-07-20 12:51:32 UTC
Our only chance is mmiotracing nvidia kernel module and figuring out what they do differently. 

http://nouveau.freedesktop.org/wiki/MmioTrace
Comment 7 Ben Skeggs 2010-07-20 15:33:22 UTC
Ah, this is a known issue.  EFI leaves the display engine in a state we're not expecting.  As Marcin said, a mmiotrace of the binary driver would be very useful to see how they reset it to the state we expect.
Comment 8 Felix Leimbach 2010-07-21 13:02:35 UTC
OK, I've got the mmio trace:
http://rapidshare.com/files/408257350/nvidia-efi-trace.bz2

This is how it was produced:
1) boot into console on kernel 2.6.32-gentoo-r6
2) start tracing
3) add marker
4) modprobe nvidia
5) add marker
6) start x and wait until DE is finished
6) end trace
Comment 9 Felix Leimbach 2010-07-21 13:03:41 UTC
Created attachment 37278 [details]
dmesg of the trace in comment #8
Comment 10 Ben Skeggs 2010-07-21 19:45:41 UTC
Created attachment 37289 [details] [review]
EVO channel init modifications

Can you try the attached patch for me, and provide the dmesg output you see with it.
Comment 11 Felix Leimbach 2010-07-21 22:58:03 UTC
Created attachment 37292 [details]
dmesg output with evo patch

Attached booting into efifb => nouveaufb => x with the attached patch applied.
However, I think the debug output you are looking for is not there?

Here's what I did:
1) Apply patch to 2.6.35-rc3, applied fine with 1 line offset (don't have the bandwidth to download current git at the moment - can do that on the weekend if needed)
2) boot into patched kernel with video=efifb
3) symptoms are the same (garbled screen)
4) log in blindly to start x
5) switch to a console again and dump dmesg
Comment 12 Ben Skeggs 2010-07-21 23:10:14 UTC
The output indicates that you're not running with those patches, those timeout messages don't exist with the patch applied.
Comment 13 Felix Leimbach 2010-07-22 10:55:13 UTC
Created attachment 37320 [details]
dmesg output with evo patch (real)

Ben, you're the man. After applying your patch correctly (didn't remove the --dry-run last time ...) nouveaufb now *works*. Yay!

The X driver doesn't yet work, but I will update to latest git first before reporting that.
Comment 14 Felix Leimbach 2010-07-22 12:38:49 UTC
Now I've updated xf86-video-nouveau to latest git and voila, X runs perfectly.

Kernel: 2.6.35-rc5 with nouveau-drm from today's git
xorg nouveau driver: today's git

On a small sidenote: When during boot the console switches from efifb to nouveaufb for about one second there is still the garbled screen. Then it goes away and the console output starts at around the middle of the screen (vertical).

Big thanks for the uber-fast and competent handling, closing as FIXED.
Comment 15 Felix Leimbach 2010-07-22 12:41:25 UTC
BTW, should we report this to the nv guys? I guess they need a similar fix.
Comment 16 Ben Skeggs 2010-07-22 19:42:52 UTC
Re-opening bug, as it's not fixed in nouveau as of yet.  I'm still not entirely sure what the correct fix *is*.

Reporting to the nv guys may be useful, though I'm not entirely sure if you'll see any response from them.  If for some reason they do fix it, it'll be useful as we'll hopefully get some idea of how to properly fix it (hint: nvidia write nv) :)
Comment 17 Felix Leimbach 2010-08-04 10:54:50 UTC
OK, I've used nouveau on this configuration for some weeks now and here are my findings:

What is great:
1) Suspend & Resume works beautifully
2) X feels snappy and KDE 4.4's composite effects work very well
3) Dual-screen configuration works (also on-the-fly plugging and unplugging) except:
3a) When setting the external monitor's native resolution of 1600x1200 that monitor flickers badly and moving mouse or windows there is very very sluggy.
3b) If I use 1200x1024 instead then all works well except that there is an occasional flicker. I.e. it flickers once and all is fine for 10 minutes until it flickers once again

But there is problem too:

4) X.org freezes always after roughly 1 day of uptime. In just hangs and not even switching to the console is possible. However network login through ssh is possible and the Xorg.log contains a stacktrace which I will post below.

How shall we proceed? I can test anything you throw at me ...
Comment 18 Felix Leimbach 2010-08-04 11:03:50 UTC
Created attachment 37574 [details]
Xorg.log after crash
Comment 19 Daniel Stone 2010-08-04 13:41:49 UTC
The patch also fixes it for me on a MacBookAir2,1 w/9400M, booting through EFI.  Thanks! :) I see hangs every now and again, but haven't managed to grab a log out of them yet.
Comment 20 Felix Leimbach 2010-08-06 01:56:42 UTC
Created attachment 37622 [details] [review]
Updated version that applies to git from 2010-08-06

Ben's original patch doesn't apply to today's git anymore, so here's an updated version. No real changes were made.
Now I'm seeing another bug (#29415) but I guess that's not due to this patch.
Comment 21 Yuriy Khomchik 2010-09-13 02:32:45 UTC
It looks like bug 29714. In this case, my laptop also uses EFI. I also sent output of MMIO tracing by e-mail to the appropriate address on 4 September.
Comment 22 Felix Leimbach 2010-09-13 05:47:36 UTC
#29714 has indeed the very same symptoms as this. Also, I've seen similar and repeated messages of "unplugged DisplayPort" and "plugged DisplayPort".

What happens when you try the attachment "EVO channel init modifications"? For me it solved the garbled screen problem.
But unfortunately nouveau crashes so frequently that I had to revert to the binary driver for now.
Comment 23 Yuriy Khomchik 2010-09-14 11:25:12 UTC
With this patch instead corrupted screen I see black screen. Output of dmesg on Linux kernel version 2.6.35 see in bug 29714.
Comment 25 Ben Skeggs 2010-10-19 22:39:02 UTC
The issues on MacBooks + EFI (which is all this bug is covering) may be fixed in current nouveau git.
Comment 26 Felix Leimbach 2010-10-21 13:48:58 UTC
Tried nouveau-drm and xf86-video-nouveau from today's git together with kernel 2.6.36.

However the screen freezes in the middle of the boot process (at the udev stage) and the dmesg (attached) shows an OOPS.
Comment 27 Felix Leimbach 2010-10-21 13:50:10 UTC
Created attachment 39618 [details]
OOPS with 2.6.36
Comment 28 Ben Skeggs 2010-10-21 15:46:20 UTC
Oops, I'm very sorry about that.  Some other work I did introduced a regression on a couple of IGP chipsets.  Can you retry latest git?
Comment 29 Felix Leimbach 2010-10-22 13:12:28 UTC
Latest git runs fine, thank you Ben.

These problems from comment #27 remain but I've opened a new bug #31058.
Comment 30 Felix Leimbach 2010-10-22 13:13:17 UTC
> These problems from comment #27 remain but I've opened a new bug #31058.

Typo: comment #17 not #27
Comment 31 Marcin Slusarz 2010-10-23 02:47:01 UTC
Great!
Comment 32 Felix Leimbach 2011-01-23 07:00:06 UTC
REOPENing because this bug still happens as of vanilla kernel 2.6.38-rc2.
It is fixed in the nouveau tree though.
Comment 33 Ben Skeggs 2011-01-23 15:16:11 UTC
Err, what branch of the nouveau tree does this work on?  drm-nouveau-staging is currently the main development branch, and is 2.6.38-rc2 + a couple of other bits.  If it doesn't work there, can you bisect it back the where it broke again?
Comment 34 Felix Leimbach 2011-02-20 13:33:00 UTC
It works in 2.6.35-rc5. Marking RESOLVED.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.