My desktop workstation has been encountering intermittent video issues, including illegible screen displays and cases in which the monitor doesn't respond at all after Linux is loaded. Rebooting the system always seems to fix it however. This isn't so much of a problem for me, as I have a vision impairment and use braille and speech output, but it is an issue when someone else wants to use the machine. The only relevant error I found in the kernel log is: Mar 20 15:05:58 jdc kernel: [23207.760016] [drm] nouveau 0000:40:00.0: DDC responded, but no EDID for DVI-I-2 (after turning the monitor off then back on, after which it still didn't display any video.) The video card in this machine has been replaced twice over the years, both times under warranty/service contract, and with the same model of card, so I have my suspicions. It's a very up to date Debian Sid system, kernel 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64 GNU/Linux I didn't find any relevant Debian bug reports. Obviously I want to know whether it's hardware or software, and if hardware, the card itself or something else.
Jason White <jason@jasonjgw.net> writes:
The only relevant error I found in the kernel log is: Mar 20 15:05:58 jdc kernel: [23207.760016] [drm] nouveau 0000:40:00.0: DDC responded, but no EDID for DVI-I-2
FWIW... IIRC EDID (and DCC?) are the way the computer asks the monitor "hey, what resolutions do you support?" -- they are the reason we don't need to manually specify modelines in xfree86.conf anymore. If it can't talk EDID to DVI-I-2, I would expect a monitor plugged into it to either get a generic "hopefully works anywhere" VESA mode line 800x600. I once had an LG 2010 LCD monitor where over DVI-D, EDID worked fine, but over D-sub, it negotiated an incorrect modeline. I worked around it by manually specifying a "2048x1024twb" type modeline each time I connected the laptop to that monitor.
I didn't find any relevant Debian bug reports. Obviously I want to know whether it's hardware or software, and if hardware, the card itself or something else.
Assuming there's nothing in Xorg.0.log either, I would next check xrandr's output to see what modelines it knows about. If you have a computer that works correctly with that monitor, or a monitor that works correctly with that computer, you should compare with its xrandr.
Trent W. Buck <trentbuck@gmail.com> wrote:
Assuming there's nothing in Xorg.0.log either, I would next check xrandr's output to see what modelines it knows about. If you have a computer that works correctly with that monitor, or a monitor that works correctly with that computer, you should compare with its xrandr.
Thanks. My suspicion at the moment is that something isn't initialized properly: usually, the system boots fine and the monitor works; sometimes, the system boots apparently normally and the screen display is either unreadable or totally absent. A reboot is enough to fix it. This phenomenon is very recent; I'm suspecting either a kernel upgrade (one of the Debian patches) or a developing hardware fault somewhere.
Check the temperature of the card too. Try and see if increasing the load on it can trigger the condition. Also compare the cards diagnostics in Linux and Windows. On Wednesday, 20 March 2013, Jason White wrote:
Trent W. Buck <trentbuck@gmail.com <javascript:;>> wrote:
Assuming there's nothing in Xorg.0.log either, I would next check xrandr's output to see what modelines it knows about. If you have a computer that works correctly with that monitor, or a monitor that works correctly with that computer, you should compare with its xrandr.
Thanks. My suspicion at the moment is that something isn't initialized properly: usually, the system boots fine and the monitor works; sometimes, the system boots apparently normally and the screen display is either unreadable or totally absent. A reboot is enough to fix it.
This phenomenon is very recent; I'm suspecting either a kernel upgrade (one of the Debian patches) or a developing hardware fault somewhere.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au <javascript:;> http://lists.luv.asn.au/listinfo/luv-main
-- *Michael Lindner* IT Systems Consultant _______________________________________ "It's always now"
Michael Lindner <michael@tropyx.com> wrote:
Check the temperature of the card too. Try and see if increasing the load on it can trigger the condition. Also compare the cards diagnostics in Linux and Windows.
I can do the first two, but not the third (no Windows around here). nouveau-pci-4000 Adapter: PCI adapter temp1: +81.0°C (high = +100.0°C, crit = +120.0°C) That's with the machine mostly idle.
On Wed, Mar 20, 2013 at 05:36:21PM +1100, Trent W. Buck wrote:
Jason White <jason@jasonjgw.net> writes:
The only relevant error I found in the kernel log is: Mar 20 15:05:58 jdc kernel: [23207.760016] [drm] nouveau 0000:40:00.0: DDC responded, but no EDID for DVI-I-2
FWIW... IIRC EDID (and DCC?) are the way the computer asks the monitor "hey, what resolutions do you support?" -- they are the reason we don't need to manually specify modelines in xfree86.conf anymore.
If it can't talk EDID to DVI-I-2, I would expect a monitor plugged into it to either get a generic "hopefully works anywhere" VESA mode line 800x600.
I once had an LG 2010 LCD monitor where over DVI-D, EDID worked fine, but over D-sub, it negotiated an incorrect modeline. I worked around it by manually specifying a "2048x1024twb" type modeline each time I connected the laptop to that monitor.
Over the years, I've had a few monitors with similar EDID problems - including the LG TV currently connected to my MythTV box. Dunno if it's the nvidia card, the nvidia driver, or the LG TV itself....both nvidia and LG seem less than stringent when conforming to standards. I have found that you can use get-edid from the read-edid package to dump the EDID data to a file, and then tell X to use that. e.g. in the Monitor section of /etc/X11/xorg.conf on my myth box, I have: Option "CustomEDID" "DFP-1:/etc/X11/LG-42LD560.edid.bin" Package: read-edid Version: 2.0.0-3.1 Installed-Size: 76 Description-en: hardware information-gathering tool for VESA PnP monitors read-edid consists of two tools: . get-edid uses a VESA VBE 2 interrupt service routine request to read a 128 byte EDID version 1 structure from your graphics card, which retrieves this information from the monitor via the Data Display Channel (DDC). . get-edid uses architecture-specific methods for querying the video hardware (real-mode x86 instructions on i386, Open Firmware device tree parsing on PowerMac) and is therefore only available for i386 and powerpc architectures. . parse-edid parses this data structure and outputs data suitable for inclusion into the XFree86 or X.org configuration file. It is available for any architecture. Homepage: http://www.polypux.org/projects/read-edid/ BTW, the package description says it only works for i386 and powerpc architectures - however, i had no difficulty using it on debian amd64 (with both 32-bit and 64-bit libs installed) IIRC (and i could be wrong coz it was a couple of years ago), i had to run it from a virtual console, without X started. craig -- craig sanders <cas@taz.net.au>
I upgraded the kernel to linux-image-3.8-trunk-amd64 from Debian experimental and, so far, the video symptoms haven't recurred. The changelog for the Debian 3.2-4 kernel shows that there were indeed Nouveau driver updates included in late February, corresponding approximately to the onset of the problem here. However, I still suspect the hardware due to the history of video card replacement on this machine, so I am not yet ready to attribute it to the kernel.
On Sat, Mar 30, 2013 at 12:41:57PM +1100, Jason White wrote:
I upgraded the kernel to linux-image-3.8-trunk-amd64 from Debian experimental and, so far, the video symptoms haven't recurred.
just noticed your reply, hadn't seen it earlier. have you noticed any oddities with USB on the 3.8 kernel? the reason i ask is that every debian kernel package i've tried after linux-headers-3.7-trunk-amd64 3.7.3-1~experimental.1 results in broken USB support on both my main desktop machine and my mythtv box. i.e. with 3.7.3, USB works. >= 3.7.8 it doesn't. I never tried 3.7.[4567] so i have no idea if they have the problem or not - i went straight from 3.7.3 to 3.7.8 and then tried 3.8 before reverting to 3.7.3 this is particularly annoying on the myth box because the tuner cards are USB-on-a-PCI-card (with a VIA USB chip). the USB keyboard/mouse work but the tuner cards don't. on my main desktop machine, the USB keyboard & mouse also work but it won't recognise a USB HP printer when i plug it in...doesn't even notice that it has been plugged in. this may be a complete red-herring, but the only USB thing both machines have in common is that they both have Dell Multimedia keyboards plugged into them. I bought a bunch of them from a swap meet a few years ago because it was the kb i used at work and i got tired of fat-fingering the wrong keys when switching between work and home. they're not bad keyboards, not great but better than the typical cheap junk keyboards, but I have noticed weird problems with them in the past (e.g. until recently, maybe 3.2 or 3.5 or the 3.7 kernel, they'd freeze and need to be unplugged and plugged back in after a reboot...something in the linux kernel initialisation confused them. it was linux-specific because my gaming machine which is dual-boot linux & windows 7 had the problem when booting linux but not booting win7). i think the problems are due to the weird USB hub they have built in to them. craig -- craig sanders <cas@taz.net.au>
On 12/04/13 15:32, Craig Sanders wrote:
have you noticed any oddities with USB on the 3.8 kernel?
Nope, I've been running mainline 3.8 from before rc1 through to 3.8.6 on my ZaReason UltraLap and it's been fine. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On Fri, Apr 12, 2013 at 03:38:40PM +1000, Chris Samuel wrote:
On 12/04/13 15:32, Craig Sanders wrote:
have you noticed any oddities with USB on the 3.8 kernel?
Nope, I've been running mainline 3.8 from before rc1 through to 3.8.6 on my ZaReason UltraLap and it's been fine.
and Sean Crosby <richardnixonshead@gmail.com> wrote:
I've been running the mainline Ubuntu 3.8.5 kernel on my Mac Air, and it's been perfect.
damn. that means it some weird non-reproducible problem that only i have so it's unlikey to get fixed any time soon i kind of guessed that when google didn't reveal hordes of people complaining about USB in recent kernels. i think i'll try 3.8 again sometime soon without the Dell keyboard plugged in. craig -- craig sanders <cas@taz.net.au> BOFH excuse #152: My pony-tail hit the on/off switch on the power strip.
On Fri, Apr 12, 2013 at 04:23:47PM +1000, Craig Sanders wrote:
damn. that means it some weird non-reproducible problem that only i have so it's unlikey to get fixed any time soon
i kind of guessed that when google didn't reveal hordes of people complaining about USB in recent kernels.
in case anyone else is interested, the following post to lkml might hold the solution: http://lkml.indiana.edu/hypermail/linux/kernel/1301.2/00314.html haven't tested it myself yet, but apparently the ehci-hcd module has been split into two modules, ehci-hcd and ehci-pci. unless you specify the exact load order in /etc/modules or similar (i.e. to force ehci-pci to be loaded immediately before ehci-hcd), module auto-loading may cause one of the other *hci-hcd modules may load before ehci-pci. given that my DVB cards are PCI based (with VIA USB interfaces on them), this seems likely. and now that i know what to search for, there's even a bug report in debian against initramfs-tools: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700572 apparently there's a fix in initramfs-tools version 0.110 released on March 1st. this may even fix the problem for me without any further action - according to my boot logs, the last times i tried 3.7.8 and 3.8.2 were Mar 13 and Mar 16 respectively, but according to /var/log/dpkg.log, i didn't upgrade to initramfs-tools 0.110 until April 1st.
i think i'll try 3.8 again sometime soon without the Dell keyboard plugged in.
still haven't had time to test this, but now that i have a reasonable theory to test i'll try to find some time to boot 3.8.x again this week. craig ps: adding "-src" to google searches about kernel drivers makes it much easier to find bug reports, blog comments and mailing list posts rather than umpty-billion copies of the source code. duh, i should have remembered that. -- craig sanders <cas@taz.net.au> BOFH excuse #57: Groundskeepers stole the root password
On Tue, Apr 16, 2013 at 09:12:02PM +1000, Craig Sanders wrote:
still haven't had time to test this, but now that i have a reasonable theory to test i'll try to find some time to boot 3.8.x again this week.
i rebooted my myth box with 3.8.5 yesterday. No USB problems, everything's working perfectly. so, loading the ehci-pci module fixed it. craig -- craig sanders <cas@taz.net.au>
On 12 April 2013 06:32, Craig Sanders <cas@taz.net.au> wrote:
On Sat, Mar 30, 2013 at 12:41:57PM +1100, Jason White wrote:
I upgraded the kernel to linux-image-3.8-trunk-amd64 from Debian experimental and, so far, the video symptoms haven't recurred.
just noticed your reply, hadn't seen it earlier.
have you noticed any oddities with USB on the 3.8 kernel?
I've been running the mainline Ubuntu 3.8.5 kernel on my Mac Air, and it's been perfect.
they're not bad keyboards, not great but better than the typical cheap junk keyboards, but I have noticed weird problems with them in the past (e.g. until recently, maybe 3.2 or 3.5 or the 3.7 kernel, they'd freeze and need to be unplugged and plugged back in after a reboot...something in the linux kernel initialisation confused them. it was linux-specific because my gaming machine which is dual-boot linux & windows 7 had the problem when booting linux but not booting win7). i think the problems are due to the weird USB hub they have built in to them.
Agreed about the quality of the keyboard. I have had experiences where that multimedia keyboard did not get recognised by IBM servers though (couldn't press the key to enter the bios, and once in the OS, didn't register any keypress). But on the whole, it has been a very good keyboard. Sean
participants (6)
-
Chris Samuel -
Craig Sanders -
Jason White -
Michael Lindner -
Sean Crosby -
trentbuck＠gmail.com