similar to: [Bug 31961] New: [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:6]

https://bugs.freedesktop.org/show_bug.cgi?id=46557 Bug #: 46557 Summary: nouveau: nv40 display corruption in framebuffer and X lockups unless nouveau.noaccel=1 Classification: Unclassified Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity:

https://bugs.freedesktop.org/show_bug.cgi?id=67277 Priority: medium Bug ID: 67277 Assignee: nouveau at lists.freedesktop.org Summary: Lockdep splat on kernel 3.10.0 QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: peter at hurleysoftware.com

On 01/26/2016 03:24 PM, Ilia Mirkin wrote: > sleep 1 && xset dpms force off Could you confirm exactly how to add the drm.debug=0x1e option. Is it another parameter on the kernel command line? Where does the output data go? Is there a way to get it into a file? Thanks Don

Hi again, I got a new dmesg log with the debug parameters, but I guess I could not isolate VESA. I blacklisted it at /etc/modprobe.d/blacklist.conf but comparing those logs I see no difference... Is it possible to isolate VESA somehow without removing it? The new logs are here, I'm posting full content because I'm not sure what information is more relevant...

*RESEND* due to exceeding the mailinglists limit for attachment size. Hi, I''m trying to get secondary vga-passthrough on a HVM guest to work with a AMD HD6570 and the native kernel radeon driver and kernel modesetting. So the guest still gets the emulated stdvga or cirrus device(used in my case here) as primary/boot vga adapter. - When i don''t passthrough the radeon card, the

Just some runtime PM fixes for some much less noticeable runtime PM ref tracking issues that I got reminded of when fixing some unrelated issues with nouveau. Changes since v1: * Don't fix CRTC RPM code in dispnv04, because it's not actually doing anything in the first place. Just get rid of it. - imirkin Lyude Paul (2): drm/nouveau/dispnv04: Remove runtime PM drm/nouveau/dispnv50:

> On Tue, Apr 01, 2014 at 02:53:02PM -0400, Ilia Mirkin wrote: >I believe that ch7006 is the only external encoder that's supposed to >work, so you're in luck. It sounds like it passes the nv04_tv_identify >stage of nv04_tv_create -- perhaps it fails later? Although based on >the prints, it's even doing dpms stuff (but it hits _detect a second >time... odd). Try

I have a network at my parent's which consists of 4 machines: 1 Linux Samba saver (Fedora 9, Samba 3.2.x) and 3 Windows Vista Home Premium machine. I have point and print set up, and all load the drivers successfully. However, when they try print, nothing happens. Windows said it was successful however - it appears (then vanishes) from the Windows print queue. However, in the samba logs,

On my Macbook Retina, when switching to the integrated GPU, we see a ioread32 issued to the discrete GPU, which hangs as it is in D3 [1] (drm.debug is set to 14 here). Full kernel 3.6.2 boot logs with drm.debug=5 are at: http://quora.org/2012/mbp-i915-panel.txt What additional information will help debug this? Thanks, Daniel --- [1] cat /sys/kernel/debug/vgaswitcheroo/switch

On Mon, Feb 10, 2014 at 9:34 PM, Thierry Reding <thierry.reding at gmail.com> wrote: > On Mon, Feb 10, 2014 at 02:58:12PM +0900, Alexandre Courbot wrote: >> pm_runtime_get*() may return -EACCESS to indicate a device does not have > > s/-EACCESS/-EACCES/ Oops. >> runtime PM enabled. This is the case when the nouveau.runpm parameter is >> set to 0, and is not an

https://bugs.freedesktop.org/show_bug.cgi?id=51971 Bug #: 51971 Summary: MacBook Pro 10,1 Retina - Display Resets, No Connectors Classification: Unclassified Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium

On 01/26/2016 03:58 PM, Ilia Mirkin wrote: > On Tue, Jan 26, 2016 at 5:54 PM, don fisher <hdf3 at comcast.net> wrote: >> On 01/26/2016 03:24 PM, Ilia Mirkin wrote: >>> >>> sleep 1 && xset dpms force off >> >> Could you confirm exactly how to add the drm.debug=0x1e option. Is it >> another parameter on the kernel command line? > > Yep

Dropping Tegra ML, it's not the place where Nouveau mails should go. Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best. Am Montag, den 04.03.2013, 22:16 +0100 schrieb Borislav Petkov: > New -rc1, so let the stabilization games begin. > > I see the following on rc1, let me know if you need more info. > > > [ 0.633617]

After analyzing verbose nouveau & drm dmesg, I have found seemingly no more useful details pertaining to having no TV-1 device. The TV-1 device might be getting lost within DRM, by setting the TV-1 (SVIDEO, Composite) device into DPMS mode or Full Power Down mode, and the ch7006 datasheet does say in this mode, all but the i2c circuits are disabled! Looking at

https://bugs.freedesktop.org/show_bug.cgi?id=27828 Summary: Changing mode repeatedly locks up card Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

Hi. I have a problem with current kernel 2.6.35 and nouveau module compiled from git (today).From xorg.0.log I got information that no output was found.And here is some nasty kernel logs: ... Aug 2 21:53:02 zilog kernel: Linux agpgart interface v0.103 Aug 2 21:53:02 zilog kernel: [drm] Initialized drm 1.1.0 20060810 Aug 2 21:53:02 zilog kernel: nouveau 0000:01:00.0: PCI INT A -> GSI 16

pm_runtime_get*() may return -EACCESS to indicate a device does not have runtime PM enabled. This is the case when the nouveau.runpm parameter is set to 0, and is not an error in that context. Handle this case without failure. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 2 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-

Hello, I've just been hit by this old bug which is still present in 4.14: https://bugs.freedesktop.org/show_bug.cgi?id=80675 On MCP79 (ION), when stolen memory is set to 32MB in BIOS, console is blank but X11 works. When the stolen memory is increased to 64MB, console works fine. Bisected it to this: 4f6029da58ba9204c98e33f4f3737fe085c87a6f is the first bad commit commit

https://bugs.freedesktop.org/show_bug.cgi?id=96307 Bug ID: 96307 Summary: Kernel 4.7-rc1 oops when starting X Product: xorg Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

Hello, I've started seeing the following warning in 3.11-rc2. [In the interest of full disclosure, I do have a patch applied that tries to implement drm_planes, which I might have done completely incorrectly, but looking around it doesn't seem related. I'm definitely not invoking any of the planes functionality right now. See http://paste.debian.net/hidden/cf8b3a2, plus a call to the