Created attachment 17791 [details] X log of gdm session modesetting on NV86: text mode goes blank, machine freeze on gdm stop using branches nouveau/master, mesa/drm/modestting-101 and nouveau/mesa/gallium-0.1. I reboot in single user mode, modprobe "drm debug=1" and "nouveau modeset=1". At this moment, the screen turns blacks but the machine does not freeze. From a SSH, I can start gdm and it seems to work, though the screen is still black. When trying to stop gdm, the machine is freezing. After X start I had many of these lines: Jul 21 15:48:36 xiong kernel: [ 605.062180] [drm] PGRAPH_ERROR - nSource: PROTECTION_ERROR, nStatus: Jul 21 15:48:36 xiong kernel: [ 605.062APH_ERROR - Ch 2/0 Class 0x502d Mthd 0x08dc APH_ERROR - Ch 2/0 Class 0x502d Mthd 0x08dc Data 0x00000000:0x00000000 (Yeah, I was told not to use the debug option, I typed too fast.) Adding logs as usual.
My mistake, the PGRAPH errors occur even without using the modeset.
Created attachment 17792 [details] syslog
Created attachment 17804 [details] my NV86 bios image
Created attachment 17806 [details] a clean syslog with head 625923eb73801659d239aa22f8a46d5cc2460277, trying at the end to reinsert the module without modeset
Created attachment 17918 [details] X log ending with "Failed to allocate memory for framebuffer!" Update: I cannot start X with the nouveau/drm/modesetting-101 branch. After nouveau is complaining about the LVDS revision table not being currently supported, it fails in allocating memory for the framebuffer. After I come back to the master branch, I have to shut down the computer for a minute before I can start X again. This is still my 8400M GS, and the nouveau checkout fetched and rebased regularly.
Hows things now?
I haven't tried since then. I have a 2.6.28 kernel and the master branch of nouveau. Is a special branch of drm needed? Or a flag at the kernel boot or in xorg.conf?
(In reply to comment #7) > I haven't tried since then. > > I have a 2.6.28 kernel and the master branch of nouveau. Is a special branch of > drm needed? Or a flag at the kernel boot or in xorg.conf? You need to use the modesetting-gem branch of drm git still. Just load the nouveau module with modeset=1. Nothing is required on the 2D driver side, it'll detect if kms is in use and act accordingly. >
I installed nouveau master, drm modesetting-gem and rebooted. I modprobed drm, then nouveau with "modeset=1", the screen went black, like when X start, then the console came back but at panel native resolution. I then started GDM but X gave the error I attach. I then tried to remove the nouveau module but it said it was busy, though "lsmod" told no other module was using it. I forgot to save "dmesg" before reboot. It contained many information about the DRM. Do you need it?
Created attachment 24017 [details] X with nouveau modeset and drm modesetting-gem
(In reply to comment #9) > I installed nouveau master, drm modesetting-gem and rebooted. > > I modprobed drm, then nouveau with "modeset=1", the screen went black, like > when X start, then the console came back but at panel native resolution. Cool, that sounds about right :) > > I then started GDM but X gave the error I attach. Hmm, the dmesg log would be very useful here (bonus points for loading drm with "modprobe drm debug=1"). > > I then tried to remove the nouveau module but it said it was busy, though > "lsmod" told no other module was using it. That's normal, the console is being controlled by nouveau.ko. You can unload the module first if you "echo 0 > /sys/class/vtconsole/vtcon<n>/bind" first. What exactly <n> is probably depends on your system, it's 1 for me. Also, once you do that, you won't have a visible console. Nouveau can't switch back to the original resolution yet.. > > I forgot to save "dmesg" before reboot. It contained many information about the > DRM. Do you need it? It would be very useful :) >
Created attachment 24036 [details] dmesg with debug=1
Created attachment 24037 [details] X log after drm debug=1 I've updated to commit 47c68ee6e4c180c18b8d58c74f12c8f90af9da3d and tested with drm debug=1. X behave the same than yesterday. Great news though that the modesetting is behaving as expected, even just on the console.
Someone forgot to close this bug.
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.