| Summary: | Garbled console on Macbook 13" (6,1 9400M]) when using EFI | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Felix Leimbach <felix.leimbach> |
| Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | major | ||
| Priority: | medium | CC: | daniel, hiyuh.root, homyur |
| Version: | 7.5 (2009.10) | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=29714 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
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? > 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 :-(
Created attachment 37250 [details]
Xorg log from starting X with the NV driver. Hangs with black screen
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. 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. Our only chance is mmiotracing nvidia kernel module and figuring out what they do differently. http://nouveau.freedesktop.org/wiki/MmioTrace 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. 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 Created attachment 37278 [details] dmesg of the trace in comment #8 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. 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
The output indicates that you're not running with those patches, those timeout messages don't exist with the patch applied. 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.
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. BTW, should we report this to the nv guys? I guess they need a similar fix. 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) :) 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 ... Created attachment 37574 [details]
Xorg.log after crash
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. 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. 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. #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. With this patch instead corrupted screen I see black screen. Output of dmesg on Linux kernel version 2.6.35 see in bug 29714. Commit http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=2aa335a9b84e5403c3d0be3a35237c6c695d812e fixes similar bug 29714. The issues on MacBooks + EFI (which is all this bug is covering) may be fixed in current nouveau git. 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. Created attachment 39618 [details]
OOPS with 2.6.36
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? Latest git runs fine, thank you Ben. These problems from comment #27 remain but I've opened a new bug #31058. > These problems from comment #27 remain but I've opened a new bug #31058. Typo: comment #17 not #27 Great! REOPENing because this bug still happens as of vanilla kernel 2.6.38-rc2. It is fixed in the nouveau tree though. 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? It works in 2.6.35-rc5. Marking RESOLVED. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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.