| Summary: | Flickering area on external monitor [9400M] | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Felix Leimbach <felix.leimbach> | ||||||
| Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> | ||||||
| Status: | RESOLVED INVALID | QA Contact: | Xorg Project Team <xorg-team> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | CC: | hramrach | ||||||
| Version: | git | ||||||||
| Hardware: | Other | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
|
Description
Felix Leimbach
2010-10-22 13:09:25 UTC
This is probably an irrelevant comment, but... You seem to have Samsung SyncMaster 204B monitor, which has two known typical faults: dying chinese electrolyte capacitors, and instability at the monitor's own recommended mode of 1600x1200 60 Hz. Your symptoms, though, do not fit either of these, but I tought you'd like to know. I have personally fixed one of these monitors. The only fix for capacitors is replacing them. The display mode problem, however, is more interesting. The standard (and the one the monitor EDID advertises) 1600x1200 mode uses 162 MHz pixel clock, which the monitor can only barely accept. Symptoms of mode failure are image blackouts, and white or green "snowing" (fast moving random bright pixels). Severity depends on the screen contents. The fix for the mode failure is easy: use 1600x1200 60 Hz reduced blanking mode. Its pixel clock is low enough (130-something MHz) for the monitor to be stable. That is my personal experience. If you want to stress-test your monitor, make it show this image: http://koti.mbnet.fi/inventor/download/kuvia/raster.gif In the 162 MHz mode, my monitor simply refuses to show anything, or misbehaves badly. On reduced blanking mode, it works like a charm. I would recommend the reduced blanking mode regardless if my explanation has anything to do with your actual problem. When you test different resolutions and display modes, check the monitor's on-screen display for the mode size and frequencies. I do not remember the default on Nouveau, but we may be feeding a 1600x1200 mode regardless of the resolution you have selected (GPU rescaling), even on VGA text mode(!). Cheers. (In reply to comment #1) > You seem to have Samsung SyncMaster 204B monitor, which has two known typical > faults: > dying chinese electrolyte capacitors, and instability at the monitor's > own recommended mode of 1600x1200 60 Hz. (offtopic) Yeah, had to replace 4 leaking capacitors after approx 2 years too, since then its running great again. However the same monitor works just fine with another PC and also with the nvidia binary driver. Thanks for the hint re. ReducedBlanking, will check it out once I *can* run at the native resolution. (back on topic) Today I've found a reproducable kernel panic related to the external display might be related: When I play a video in VLC on the external Monitor the kernel panics as soon as I switch to fullscreen. Maximized window works. I'll attach a screenshot of the OOPs. Created attachment 39654 [details]
screenshot of reproducable kernel OOPS because of fullscreen VLC on external monitor
We are hitting BUG_ON in drm_vblank_put, but the stacktrace from your oops does not make any sense. Please recompile your kernel with CONFIG_DEBUG_INFO, reproduce this bug and attach new oops. If it's possible catch it with netconsole (see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/networking/netconsole.txt;hb=HEAD ) Created attachment 39662 [details] stacktrace (netconsole) of OOPS Stacktrace as requested in comment #4. Note that every line was logged twice, due to me exerimenting with netconsole targets. Please just ignore that. New finding: The OOPS disappears if I disable VLC's option "Accelerated video output (Overlay)". Note that on the laptop's internal screen I *can* play full screen with that option *enabled* and no OOPS happens. It only happens on the external display. I've split off bug #31074 which is about that OOPS triggered by VLC. This bug is about the original problem of a flickering area on the external screen. It appears that this bug report has laid dormant for quite a while. Sorry we haven't gotten to it. Since we fix bugs all the time, chances are pretty good that your issue has been fixed with the latest software. Please give it a shot. (Linux kernel 3.10.7, xf86-video-nouveau 1.0.9, mesa 9.1.6, or their git versions.) If upgrading to the latest isn't an option for you, your distro's bugzilla is probably the right destination for your bug report. In an effort to clean up our bug list, we're pre-emptively closing all bugs that haven't seen updates since 2011. If the original issue remains, please make sure to provide fresh info, see http://nouveau.freedesktop.org/wiki/Bugs/ for what we need to see, and re-open this one. Thanks, The Nouveau Team |
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.
