Description of problem: Pluging in a secondary monitor blanks the primary screen and locks the system. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Plug-in secondary monitor 2. 3. Actual results: Crash Expected results: Monitor detected and used in dual-head mode Additional info: Notebook used: HP 8440p with Nvidia NVS 3100 Fresh installation of Fedora 13
Hi, can you provide Xorg.0.log, dmesg, lspci -vnn? It would help in debugging this issue.
Created attachment 421867 [details] Requeste Xorg.0.log, .old because restart after crash required to access the files
Created attachment 421868 [details] dmesg output
Created attachment 421870 [details] lspci -nvv output
so, from that Xorg.0.log, this is actually using the integrated Intel chipset, not an NVIDIA chipset. (vedran, remember how I said to check everything ;>). the lspci -nvv output shows nothing from NVIDIA, so either you don't actually have an NVIDIA chipset at all, or you have one of the new type of laptops with switchable graphics, and it's currently locked into onboard graphics mode. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
does the Xorg.0.log from the crash really just end in the middle of a line like that? if so, can we have /var/log/messages , and an indication of the time at which the crash occurred, so we can find the appropriate location? thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 421890 [details] Message log crash 7 june arround 17:36
(In reply to comment #5) > so, from that Xorg.0.log, this is actually using the integrated Intel chipset, > not an NVIDIA chipset. (vedran, remember how I said to check everything ;>). > the lspci -nvv output shows nothing from NVIDIA, so either you don't actually > have an NVIDIA chipset at all, or you have one of the new type of laptops with > switchable graphics, and it's currently locked into onboard graphics mode. > > > > -- > Fedora Bugzappers volunteer triage team > https://fedoraproject.org/wiki/BugZappers Yep, your correct it is using the integrated Intel chipset. I will change the title of the bug
(In reply to comment #3) > Created an attachment (id=421868) [details] > dmesg output Is this dmesg output captured AFTER the Xorg crash (can you switch at least to VT2 with Ctrl+Alt+F2)? Also, if this happens again, can we ask for getting /var/log/Xorg.0.log AFTER the crash (if your computer is completely gone and you have to restart it, try to restart to add 3 on the end of the kernel command line to get previous Xorg.0.log, please)? Thank you very much for your patience with us
Created attachment 422351 [details] dmesg output after crash and restarted in runlevel 3 ctrl+alt+f2 has no effect after crash.
Created attachment 422353 [details] Xorg0.log after crash and restarted in runlevel 3 ctrl+alt+F2 has no effect after crash
just so you know, dmesg after a reboot is no use, as dmesg only gives you output since the last boot. You can give /var/log/messages , but unfortunately the most useful drm messages don't go there :( -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #12) > just so you know, dmesg after a reboot is no use, as dmesg only gives you > output since the last boot. You can give /var/log/messages , but unfortunately > the most useful drm messages don't go there :( > > > > -- > Fedora Bugzappers volunteer triage team > https://fedoraproject.org/wiki/BugZappers Can you tell me which additional information you need?
(In reply to comment #13) > Can you tell me which additional information you need? http://wiki.x.org/wiki/Development/Documentation/ServerDebugging but really what we really need is output of dmesg AFTER the crash and BEFORE reboot. If you cannot provide it (e.g., because computer freezes so hard, it is not accessible even with ssh), there is unfortunately not much you can do for us, I am afraid.
I did find a way to do it, but it's pretty roundabout and I don't quite remember all the steps. You need to pass a kernel parameter which causes all kernel messages to go to the console instead of dmesg, then use netconsole to pass console messages out to another machine. Then monitor the console messages on that machine as you attach the other monitor, and you should capture the failure. If you're up for trying that, I can try to drag out more detailed instructions.
(In reply to comment #15) > I did find a way to do it, but it's pretty roundabout and I don't quite > remember all the steps. You need to pass a kernel parameter which causes all > kernel messages to go to the console instead of dmesg, then use netconsole to > pass console messages out to another machine. Then monitor the console messages > on that machine as you attach the other monitor, and you should capture the > failure. If you're up for trying that, I can try to drag out more detailed > instructions. I tried using a background job continuously looping "dmesg" to an output file. This crashed in the middle of a line. Do you have further instructions which kernel parameter to use?
Created attachment 425469 [details] dmesg output while crashing logged with nc on another system Running a "dmesg"-loop and sending the output with nc to another system resulted in the attached output. Each "dmesg" output starts with "START START START" and ends with "END END END". The last entries are the output after the system hangs, but continues sending output to nc.
okay, the kernel parameter you want is 'ignore_loglevel' . Just booting with that kernel parameter should result in all sorts of messages that would usually go to system logs being dumped to console, including things from drm. You also want to boot with 'drm.debug=0x06', to get more verbose messages out of drm. final piece of the puzzle is to use netconsole to get the console messages onto another system. I used this howto: http://www.novell.com/communities/node/4753/netconsole-howto-send-kernel-boot-messages-over-ethernet Obviously adjust the SUSE-specific bits for the Fedora equivalents, that shouldn't be too hard. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
oh, forgot - I monitored the console on the remote machine with the 'netcat' method, but Fedora doesn't actually have netcat, it has 'nc', with slightly different parameters. I found the working invocation was: nc -l -u 6666 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Problem disappeared in Fedora 14
Thank you for letting us know.