Created attachment 87204 [details]
Full dmesg when trying to modprobe the nouveau driver

Created attachment 87205 [details]
Full dmesg when using the nvidia driver

From the MMIO trace - the binary driver seems to be retrying in a very unusual manner to retrieve the vbios from ACPI.
[mem 0x00000000c9e25000-0x00000000cab27fff] ACPI NVS


acpi_vbios() {
  W 0x088050 0x00000000 PPCI.ROM_SHADOW_ENABLE <= 0

  origin = 0xc9eca000;
  size = 0x1000;

  MAP $origin $size
  UNMAP

  base = origin;

  for (i = 0; i < ??; i++) {
    for (j = 0; j < 8; j++) {
      for (k = 1; k <= 8; k++) {
        MAP $base+(k*$size) $size
        UNMAP
      }
      MAP $base $size
      SLEEP 0.182000ms
      UNMAP
    }
    base += 8*$size;
  }
}

Not entirely sure if it succeeds though, but after this sequence it seems to be doing all sorts of stupid stuff as init script tables do.
  R 0x000000 0x0e7240a2 PMC.ID
  W 0x000000 0x0e7240a2 
etc.

Created attachment 87207 [details] [review]
retry 16 times to retrieve the vbios from ACPI

Give this patch a try, and attach the resulting dmesg. Thanks

Created attachment 87210 [details]
Full dmesg with patch from attachment 87207 [details] [review] applied

In addition to the patch an additional line of debug output was added which shows the "JOEY: Yes this is the patched module"... Please just ignore this line of debug output in the dmesg :-)

Created attachment 87214 [details] [review]
count DISPLAY_3D devices while considering dsm/optimus presence

Created attachment 87215 [details]
Full dmesg with the count DISPLAY_3D devices patch

Created attachment 87216 [details]
Full dmesg with the count DISPLAY_3D devices and starting X

When starting X with the patch it now crashes. See dmesg for details.

Feel free to try the DISPLAY_3D patch and make sure that you have

From 5495e39fb3695182b9f2a72fe4169056cada37a1 Mon Sep 17 00:00:00 2001
From: Ben Skeggs <bskeggs@redhat.com>
Date: Tue, 10 Sep 2013 02:11:01 +0000
Subject: drm/nouveau/bios/init: stub opcode 0xaa

Created attachment 87217 [details]
Full dmesg with additional stub opcode 0xaa patch

In addition to the count DISPLAY_RD devices patch now I applied this patch:

http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?h=drm-nouveau-next&id=5495e39fb3695182b9f2a72fe4169056cada37a1

Good news: with the "count DISPLAY_3D devices" patch and http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?h=drm-nouveau-next&id=5495e39fb3695182b9f2a72fe4169056cada37a1 applied nouveau loads successfully and I can now also start X without crashing.

Created attachment 87218 [details] [review]
cleaner approach to patch 87214

Another patch that does the same thing, without iterating though all the pci devices twice :) Currently only VGA and 3D devices are selected via the mask, although it may be easily changed in the future :)

Tested about 30 minutes running things with "DRI_PRIME=1 someprogramm" and everything is working fine now. Also running full gnome 3 session with DRI_PRIME=1 now.

Note: I did not test it with the newer patch 87218 yet. (will do so during the next days if I find the time)

Spoken too soon :-)

By accident I also "fixed" my haswell's internal intel DRI and so the system is now running much faster than before, but still powered by the intel's rendering.

I'm surprised how fast the build in haswell's intel rendering is already :-)


But for the nouveau: It fails to initialise the acceleration, as far as I can see.

The /var/log/Xorg.0.log shows: (i will attach the full log)

[    75.892] (II) NOUVEAU(G0): Opened GPU channel 0
[    77.893] (EE) NOUVEAU(G0): Failed to initialise context object: 2D_NVC0 (0)
[    77.893] (EE) NOUVEAU(G0): Error initialising acceleration.  Falling back to NoAccel
[    77.893] (==) NOUVEAU(G0): Backing store disabled
[    77.893] (==) NOUVEAU(G0): Silken mouse enabled
[    77.893] (==) NOUVEAU(G0): DPMS enabled
[    77.893] (II) NOUVEAU(G0): RandR 1.2 enabled, ignore the following RandR disabled message.


And so "DRI_PRIME=1 glxinfo | grep OpenGL" shows that it is running on intel only:

OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile 
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 9.2.0
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:

Created attachment 87232 [details]
Xorg.0.log with Error initialising acceleration message

Joey can we keep one bug per report please. It's quite easy to jump on the wagon and describe any issue and/or glitch within the same report, but it's never a good idea :)

Thanks

Emil, you're right, sorry ... As the subject from this report already tells this one is about the vbios issue which is already solved by the patch and we should have a look at the other issue separately :-) (Will try to check this on IRC and open a new bug if required)

FWIW, I had problem building the kernel with the second version of the patch (87214) for Fedora 20 beta TC1 using rpmbuild, but then I'm a lightweight when it comes to actual programming:

drivers/gpu/drm/nouveau/nouveau_acpi.c: In function 'nouveau_pci_get_class_masked':
drivers/gpu/drm/nouveau/nouveau_acpi.c:276:2: error: implicit declaration of function 'pci_get_dev_by_id' [-Werror=implicit-function-declaration]
  return pci_get_dev_by_id(&id, from);
  ^
drivers/gpu/drm/nouveau/nouveau_acpi.c:276:2: warning: return makes pointer from integer without a cast [enabled by default]
cc1: some warnings being treated as errors
make[4]: *** [drivers/gpu/drm/nouveau/nouveau_acpi.o] Error 1
make[3]: *** [drivers/gpu/drm/nouveau] Error 2
make[2]: *** [drivers/gpu/drm] Error 2
make[1]: *** [drivers/gpu] Error 2
make: *** [drivers] Error 2

Oops, make that patch 87218 that had the problem.

Ouch, yes. Seems like the function pci_get_dev_by_id() in undefined outside of drivers/pci

In that case I see two solution - iterate through each device type (vga/3d) or making the symbol accessible at a larger scale.

(In reply to comment #15)
> But for the nouveau: It fails to initialise the acceleration, as far as I
> can see.
> 
> The /var/log/Xorg.0.log shows: (i will attach the full log)
> 
> [    75.892] (II) NOUVEAU(G0): Opened GPU channel 0
> [    77.893] (EE) NOUVEAU(G0): Failed to initialise context object: 2D_NVC0
> (0)
> [    77.893] (EE) NOUVEAU(G0): Error initialising acceleration.  Falling
> back to NoAccel
> [    77.893] (==) NOUVEAU(G0): Backing store disabled
> [    77.893] (==) NOUVEAU(G0): Silken mouse enabled
> [    77.893] (==) NOUVEAU(G0): DPMS enabled
> [    77.893] (II) NOUVEAU(G0): RandR 1.2 enabled, ignore the following RandR
> disabled message.

Agree with Emil. See bug 70354 -- it covers this problem. Let's keep this issue to just being about VBIOS failure.

This is fixed by:

http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=4c60fac111961e7eb71a08928c22b43cff55f1fb

Which should appear in 3.13-rc1. Marking this as fixed.