Hi all, I performed some diff on the logs. From the dmsg, I find that the failing log fails to enable transcoder. However, it appears to detect the panel more accurately (same LG TV is used for both case). From the register dump, it appears that PFA / PFB controls are zero in the failing log and the TRANSA related config are disabled too. Could you comment on which causes the panel no signal syndrome? Thanks, Timothy The dmsg diff, with timestamp stripped out: $ diff pass_lin3.2.31_nomsi_hvm_2.20/dmsg_notime fail_lin3.2.31_hvm_nomsi_2.20/dmsg_notime 508a509 > [drm:intel_enable_transcoder] *ERROR* failed to enable transcoder 0 649,651c650,653 < HDMI: detected monitor at connection type HDMI < HDMI: available speakers: FL/FR < HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000, bits = 16 --- > HDMI: detected monitor LG TV at connection type HDMI > HDMI: available speakers: FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC FLW/FRW FLH/FRH TC FCH > HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 640000 > HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 192000, bits = 16 20 24 895d896 < [drm:intel_prepare_page_flip], preparing flip with no unpin work? 1158,1164d1158 < [drm:drm_mode_addfb], [FB:44] < [drm:intel_update_fbc], < [drm:drm_mode_addfb], [FB:42] < [drm:intel_update_fbc], < [drm:drm_mode_addfb], [FB:44] < [drm:drm_mode_addfb], [FB:42] And here is the difference in register values: $ diff pass_lin3.2.31_nomsi_hvm_2.20/intel_reg_dumper.txt fail_lin3.2.31_hvm_nomsi_2.20/intel_reg_dumper.txt 34c34 < DSPASURF: 0x0084d008 --- > DSPASURF: 0x010af008 59,61c59,61 < PFA_CTL_2: 0x00007de4 (vscale 0.983521) < PFA_CTL_3: 0x00003ef2 (vscale initial phase 0.491760) < PFA_CTL_4: 0x00007c40 (hscale 0.970703) --- > PFA_CTL_2: 0x00000000 (vscale 0.000000) > PFA_CTL_3: 0x00000000 (vscale initial phase 0.000000) > PFA_CTL_4: 0x00000000 (hscale 0.000000) 65,67c65,67 < PFB_CTL_2: 0x00007de4 (vscale 0.983521) < PFB_CTL_3: 0x00003ef2 (vscale initial phase 0.491760) < PFB_CTL_4: 0x00007c40 (hscale 0.970703) --- > PFB_CTL_2: 0x00000000 (vscale 0.000000) > PFB_CTL_3: 0x00000000 (vscale initial phase 0.000000) > PFB_CTL_4: 0x00000000 (hscale 0.000000) 75c75 < PCH_DPLL_SEL: 0x00000008 (TransA DPLL enable (DPLL A), TransB DPLL disable (DPLL (null))) --- > PCH_DPLL_SEL: 0x00000000 (TransA DPLL disable (DPLL (null)), TransB DPLL disable (DPLL (null))) 128c128 < TRANSACONF: 0xc0000000 (enable, active) --- > TRANSACONF: 0x80000000 (enable, inactive) 174,175c174,175 < RC6_RESIDENCY_TIME: 0x00395d5a < RC6p_RESIDENCY_TIME: 0x2a023fc3 --- > RC6_RESIDENCY_TIME: 0x0b5edc2c > RC6p_RESIDENCY_TIME: 0xbc9fc8dc <div class="gmail_extra"> <div class="gmail_quote"> On Sat, Dec 8, 2012 at 2:01 AM, G.R. <<a href="mailto:firemeteor@users.sourceforge.net" target="_blank">firemeteor@users.sourceforge.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi all, I'm running IGD pass through on xen and only get partial success. Basically PVHVM guest works while HVM guest (windows, linux without pvops compiled in) does not. I'm trying to figure out what's the missing piece in xen and need help from you experts. I managed to capture some logs for both passing && failing system. not working reg dump: <a href="http://pastebin.com/7vyG0biu" target="_blank">http://pastebin.com/7vyG0biu</a> dmsg: <a href="http://pastebin.com/svWG0LdY" target="_blank">http://pastebin.com/svWG0LdY</a> working reg dump: <a href="http://pastebin.com/ELsabQEp" target="_blank">http://pastebin.com/ELsabQEp</a> dmsg: <a href="http://pastebin.com/CVrkh8S0" target="_blank">http://pastebin.com/CVrkh8S0</a> Both are linux 3.2.31 kernel with 2.20.14 display driver, running on i7 3770. drm.debug=0x6. I noticed some difference on register values and some failure on dmsg logs. Could you help to identify the fatal ones so that I can dig into xen source? Thanks, Timothy </blockquote></div> </div>