Bug 47556

Summary: [NV17] nouveau fails to handle/set resolutions over certain size, nouveau_bo_new() -ENOMEM
Product: xorg Reporter: Elmar Stellnberger <estellnb>
Component: Driver/nouveauAssignee: Nouveau Project <nouveau>
Status: RESOLVED WORKSFORME QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: 7.6 (2010.12)   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.0.log of crashed Xorg
none
Xorg.0.log: external screen only, 1920x1200
none
Xorg.0.log: xinerama configuration
none
Xorg.0.log: xinerama setup(right one)
none
xorg.conf: xinerama setup
none
Xorg.strace: xinerama setup
none
Xorg.ltrace: xinerama setup
none
Xorg.dmesg: xinerama setup
none
/var/log/messages (wild-xranding with different resolution)
none
Xorg.0.log (wild xranding with different resolution) none

Description Elmar Stellnberger 2012-03-20 02:14:07 UTC
Created attachment 58730 [details]
Xorg.0.log of crashed Xorg

If I try to position my main screen leftsides to my integrated screen nouveau comes out on strike:

xrandr --output LVDS-1 --right-of VGA-1

  Previously it was showing garbage on the external screen but now with Xorg 7.6_1.10.4-201.1 and nouveau-0.0.16_20110720_b806e3f-34 it is just switching to the text console (you can see it) and then crashing Xorg itself.

  A Xinerama setup with nouveau would be very fine for my working environment (external screen + keyboard, at different resolution).
Comment 1 Elmar Stellnberger 2012-03-20 02:16:31 UTC
Created attachment 58732 [details]
Xorg.0.log: external screen only, 1920x1200

Just setting the external screen to 1920x1200 gives an error as well:
# xrandr --output LVDS-1 --off
# xrandr --output VGA-1 --mode 1920x1200
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  149 (RANDR)
  Minor opcode of failed request:  7 (RRSetScreenSize)
  Serial number of failed request:  28
  Current serial number in output stream:  29
Comment 2 Emil Velikov 2012-03-20 12:42:39 UTC
Hi Elmar

Looking at your second log, I've noticed the following

The kernel is failing to allocate new buffer object, meaning that
either
* xf86-video-nouveau, is not requesting the correct format/size
* libdrm is not wise enough to forward the info to the kernel
or
* kernel is not aware about the specific format, etc

Can you please check if there is an updated packages from openSUSE - see bug 47288 comment 2


Thanks
Emil
Comment 3 Elmar Stellnberger 2012-03-21 00:42:45 UTC
 By time this is the latest version. The only thing I can offer at the moment is to run Xorg with -logverbose 7, trying to strace it or to setterm a higher kernel reporting stage.
Comment 4 Elmar Stellnberger 2012-03-21 08:04:16 UTC
 In deed, nouveau seems to have a problem in allocating video memory. I have 2GB main memory but however an Nvidia GForce 420 Go which uses to come with 32MB of dedicated video RAM like in most embedded systems. I can achieve a resolution off up to 1280x1024 (1600x1200 does not work) with a proper xorg.conf however not with desktop video effects. The desired setup as supported by the proprietary driver is 1920x1200+1024x768, xinerama. Switching DRI off doesn`t make a difference.
Comment 5 Elmar Stellnberger 2012-03-21 08:06:05 UTC
Created attachment 58815 [details]
Xorg.0.log: xinerama configuration
Comment 6 Elmar Stellnberger 2012-03-21 08:08:44 UTC
Created attachment 58817 [details]
Xorg.0.log: xinerama setup(right one)

 Here come the test results for full xinerama setup including -logverbose 7, strace & dmesg.
Comment 7 Elmar Stellnberger 2012-03-21 08:09:32 UTC
Created attachment 58818 [details]
xorg.conf: xinerama setup
Comment 8 Elmar Stellnberger 2012-03-21 08:10:15 UTC
Created attachment 58819 [details]
Xorg.strace: xinerama setup
Comment 9 Elmar Stellnberger 2012-03-21 08:11:12 UTC
Created attachment 58820 [details]
Xorg.ltrace: xinerama setup
Comment 10 Elmar Stellnberger 2012-03-21 08:12:07 UTC
Created attachment 58821 [details]
Xorg.dmesg: xinerama setup
Comment 11 Ilia Mirkin 2013-09-06 22:29:15 UTC
Could you retest with more recent software? I think there have been a lot of changes both to xf86-video-nouveau/libdrm and the kernel since you tested this.
Comment 12 Elmar Stellnberger 2013-09-07 08:33:52 UTC
Well, I would have to reinstall on one of those machines ...
Comment 13 Ilia Mirkin 2013-09-07 17:48:29 UTC
You could also boot with, e.g., an Arch livecd/liveusb which is fairly up-to-date.
Comment 14 Elmar Stellnberger 2013-09-10 12:03:35 UTC
Well done!; it works with oS13.1_MS4, xorg-x11-driver-video-nouveau-1.0.9-1.2.i586 for most practical purposes very well. However by finally plugging xranding and unplugging different monitors I did finally get an error on re-enabling the same screen with different resolution (i.e. --off -right-of --mode newone). The error may or may not have to do something with nouveau; see for the logs (using xorg-x11-7.6_1-9.2.noarch, Xorg server 1.14.2, release date 2013-06-25).
Comment 15 Elmar Stellnberger 2013-09-10 12:05:49 UTC
Created attachment 85551 [details]
/var/log/messages (wild-xranding with different resolution)
Comment 16 Elmar Stellnberger 2013-09-10 12:06:24 UTC
Created attachment 85552 [details]
Xorg.0.log (wild xranding with different resolution)
Comment 17 Ilia Mirkin 2013-09-10 14:57:54 UTC
Is it a persistent failure (i.e. do future commands that used to work before start failing), or is it a "if I use this weird set of 75 arguments, it fails"? If the latter, what's exactly are the arguments?
Comment 18 Elmar Stellnberger 2013-09-11 06:07:56 UTC
No, all further requests have failed from a certain xrandr command on. The command looked very normal like this:
xrandr --output VGA-1 --right-of LVDS-1 --mode 800x6000
The only difference to commands issued before was the resolution (given here as 800x600; may have been 1024x768 or something else).
Comment 19 Emil Velikov 2013-10-16 17:49:07 UTC
Almost the same issue as originally, short on memory :'(

I admit some work on optimising such cases for low (gpu/vram) memory may be needed, but I do not think it high up the priority list. Read - it's a most likely a gem/ttm work than nouveau specific. Either way anyone is welcome to give it a crack

Following the messages from xorg.log

drmmode_crtc_shadow_allocate >
nouveau_allocate_surface >
(libdrm) nouveau_bo_new >
(most likely) drmCommandWriteRead(dev->fd, DRM_NOUVEAU_GEM_NEW...) >
(kernel) nouveau_gem_ioctl_new >
(most likely) nouveau_gem_new >
chaos x)
Comment 20 Ilia Mirkin 2013-11-26 04:17:38 UTC
I noticed that the kernel you used in the last test was compiled with gcc 4.8. Was libdrm also compiled with gcc 4.8? If so, please try it with libdrm-2.4.48 or later.
Comment 21 Elmar Stellnberger 2013-11-26 08:02:36 UTC
It should be the same compiler as I used the default toolkit of the same version of the distribution.
Comment 22 Elmar Stellnberger 2015-11-27 11:15:38 UTC
This is likely still an issue with some older machines though testing it got stuck because of a kernel s2ram bug: http://mirror1.htu.tugraz.at/archlinux/iso/2015.11.01/archlinux-2015.11.01-dual.iso. The notebook used to test this is still alive.
Comment 23 Elmar Stellnberger 2015-11-27 12:28:05 UTC
Bug 70510 seems to be the newer candidate (pls. correct if I missed sth.).

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.