Bug 601181 - Integrated graphics connecting secondary monitor to HP 8440p crashes the system.
Summary: Integrated graphics connecting secondary monitor to HP 8440p crashes the system.
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
(Show other bugs)
Version: 13
Hardware: x86_64 Linux
low
high
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: card_Arrandale
Keywords: Triaged
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-07 12:27 UTC by Jeroen van Velden
Modified: 2018-04-11 14:08 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-12 10:35:58 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Requeste Xorg.0.log, .old because restart after crash required to access the files (56.00 KB, text/plain)
2010-06-07 15:45 UTC, Jeroen van Velden
no flags Details
dmesg output (44.47 KB, text/plain)
2010-06-07 15:45 UTC, Jeroen van Velden
no flags Details
lspci -nvv output (8.71 KB, text/plain)
2010-06-07 15:48 UTC, Jeroen van Velden
no flags Details
Message log crash 7 june arround 17:36 (1.54 MB, text/plain)
2010-06-07 17:09 UTC, Jeroen van Velden
no flags Details
dmesg output after crash and restarted in runlevel 3 (44.44 KB, text/plain)
2010-06-08 20:45 UTC, Jeroen van Velden
no flags Details
Xorg0.log after crash and restarted in runlevel 3 (56.00 KB, text/plain)
2010-06-08 20:50 UTC, Jeroen van Velden
no flags Details
dmesg output while crashing logged with nc on another system (271.13 KB, text/plain)
2010-06-20 19:18 UTC, Jeroen van Velden
no flags Details

Description Jeroen van Velden 2010-06-07 12:27:11 UTC
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

Comment 1 Vedran Miletić 2010-06-07 14:57:10 UTC
Hi,

can you provide Xorg.0.log, dmesg, lspci -vnn? It would help in debugging this issue.

Comment 2 Jeroen van Velden 2010-06-07 15:45:19 UTC
Created attachment 421867 [details]
Requeste Xorg.0.log, .old because restart after crash required to access the files

Comment 3 Jeroen van Velden 2010-06-07 15:45:58 UTC
Created attachment 421868 [details]
dmesg output

Comment 4 Jeroen van Velden 2010-06-07 15:48:11 UTC
Created attachment 421870 [details]
lspci -nvv output

Comment 5 Adam Williamson 2010-06-07 16:14:03 UTC
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

Comment 6 Adam Williamson 2010-06-07 16:15:06 UTC
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

Comment 7 Jeroen van Velden 2010-06-07 17:09:11 UTC
Created attachment 421890 [details]
Message log crash 7 june arround 17:36

Comment 8 Jeroen van Velden 2010-06-07 17:26:09 UTC
(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

Comment 9 Matěj Cepl 2010-06-07 21:41:12 UTC
(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

Comment 10 Jeroen van Velden 2010-06-08 20:45:58 UTC
Created attachment 422351 [details]
dmesg output after crash and restarted in runlevel 3

ctrl+alt+f2 has no effect after crash.

Comment 11 Jeroen van Velden 2010-06-08 20:50:57 UTC
Created attachment 422353 [details]
Xorg0.log after crash and restarted in runlevel 3

ctrl+alt+F2 has no effect after crash

Comment 12 Adam Williamson 2010-06-09 21:16:31 UTC
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

Comment 13 Jeroen van Velden 2010-06-10 07:21:09 UTC
(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?

Comment 14 Matěj Cepl 2010-06-10 14:31:48 UTC
(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.

Comment 15 Adam Williamson 2010-06-10 16:19:42 UTC
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.

Comment 16 Jeroen van Velden 2010-06-20 17:00:10 UTC
(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?

Comment 17 Jeroen van Velden 2010-06-20 19:18:52 UTC
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.

Comment 18 Adam Williamson 2010-06-21 16:27:37 UTC
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

Comment 19 Adam Williamson 2010-06-21 16:30:44 UTC
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

Comment 20 Jeroen van Velden 2010-11-11 22:40:29 UTC
Problem disappeared in Fedora 14

Comment 21 Matěj Cepl 2010-11-12 10:35:58 UTC
Thank you for letting us know.


Note You need to log in before you can comment on or make changes to this bug.