From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: dom0 / hypervisor hang on dom0 boot Date: Tue, 14 May 2013 13:51:40 +0100 Message-ID: <5192335C.5050903@citrix.com> References: <3374329.VOz1gdFjBv@amur.mch.fsc.net> <51923145.4030506@citrix.com> <3357808.j5N0N8MOVB@amur.mch.fsc.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <3357808.j5N0N8MOVB@amur.mch.fsc.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dietmar Hahn Cc: "xen-devel@lists.xensource.com" , Konrad Rzeszutek Wilk , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 14/05/13 13:50, Dietmar Hahn wrote: > Am Dienstag 14 Mai 2013, 13:42:45 schrieb Andrew Cooper: >> On 14/05/13 13:35, Dietmar Hahn wrote: >>> Hi, >>> >>> Yesterday I installed openSuSE 12.3 on my workplace system and have some >>> trouble to run Xen. >>> Every boot with Xen and dom0 leads to a system hang. >>> Linux kernel: 3.7.10-1.4-xen. >>> Xen: xen-4.2.1_12-1.8.1.gz >>> CPU is: Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz >>> >>> It looks similar to https://bugs.freedesktop.org/show_bug.cgi?id=54575 >>> >>> I tried xen-unstable hypervisor but got the same behaviour. >>> >>> dom0 boots, prints some messages, last message is: >>> [ 6.535048] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem >>> Then the screen gets black. >>> >>> I installed the serial connection and added "drm.debug=6" to the linux boot >>> param list and the last messages I saw: >>> >>> [ 6.143094] [drm:intel_opregion_setup], graphic opregion physical addr: 0xdb7b1db8 >>> [ 6.165332] [drm:intel_opregion_setup], SWSCI supported >>> [ 6.180906] i915 0000:00:02.0: irq 47 (277) for MSI/MSI-X >>> [ 6.196975] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). >>> [ 6.216696] [drm] Driver supports precise vblank timestamp query. >>> [ 6.234870] [drm:init_vbt_defaults], Set default to SSC at 100MHz >>> [ 6.253036] [drm:intel_parse_bios], Using VBT from OpRegion: $VBT EAGLELAKE d >>> [ 6.275655] [drm:parse_general_features], BDB_GENERAL_FEATURES int_tv_support 1 int_crt_support 1 lvds_use_ssc 0 lvds_ssc_freq 96 display_clock_mode 0 >>> [ 6.315906] [drm:parse_general_definitions], crt_ddc_bus_pin: 2 >>> [ 6.333530] [drm:parse_sdvo_panel_data], Found SDVO panel mode in BIOS VBT tables: >>> [ 6.344959] input: ImPS/2 Logitech Wheel Mouse as /devices/platform/i8042/serio1/input/input3 >>> [ 6.381581] [drm:drm_mode_debug_printmodeline], Modeline 0:"1600x1200" 0 162000 1600 1664 1856 2160 1200 1201 1204 1250 0x8 0xa >>> [ 6.415858] [drm:parse_sdvo_device_mapping], No SDVO device info is found in VBT >>> [ 6.437956] [drm:intel_dsm_pci_probe], no _DSM method for intel device >>> [ 6.457394] [drm:intel_modeset_init], 2 display pipes available. >>> [ 6.475298] [drm:intel_modeset_init], plane 0 init failed: -19 >>> [ 6.492691] [drm:intel_modeset_init], plane 1 init failed: -19 >>> [ 6.510084] [drm:intel_pch_pll_init], No PCH PLLs on this hardware, skipping initialisation >>> [ 6.535048] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem >>> [ 6.563939] [drm:intel_setup_outputs], probing SDVOB >>> [ 6.578634] [drm:intel_sdvo_read_byte], i2c transfer returned -6 >>> [ 6.596280] [drm:intel_sdvo_init], No SDVO device found on SDVOB >>> [ 6.614212] [drm:intel_setup_outputs], probing HDMI on SDVOB >>> [ 6.631090] [drm:intel_setup_outputs], probing DP_B >>> [ 6.645626] [drm:intel_dp_i2c_init], i2c_init DPDDC-B >>> [ 6.663688] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8 >>> [ 6.682751] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 >>> [ 6.701868] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8 >>> [ 6.720931] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 >>> [ 6.737040] [drm:intel_setup_outputs], probing SDVOC >>> [ 6.752089] [drm:intel_sdvo_read_byte], i2c transfer returned -6 >>> [ 6.769739] [drm:intel_sdvo_init], No SDVO device found on SDVOC >>> >>> The strange thing is, it seems that the hypervisor hangs! >>> While the boot is running I can press 'h' and see the help messages between >>> the linux kernel messages. When the system hangs pressing 'h' leads to nothing. >>> So I tried the watchdog flag on the hypervisor boot line. I can see a message >> At a certain point on boot, Xen switches where the serial input goes. >> Use CTRL-a three times to switch. > Iam aware of this! > >> The watchdog is enabled by default with a 5 second timeout. > I waited definitely longer ;-) > >>> (XEN) Brought up 2 CPUs >>> (XEN) Testing NMI watchdog --- CPU#0 okay. CPU#1 okay. >>> (XEN) HPET: 8 timers (2 will be used for broadcast) >>> >>> But when the system hangs nothing happens - should I get a hypervisor dump? >>> >>> I booted linux without xen but with the debug flags and got: >>> >>> [ 9.069744] [drm:intel_sdvo_init], No SDVO device found on SDVOC >>> --> Until here like with Xen, but further >>> [ 9.089468] [drm:init_status_page], render ring hws offset: 0x00001000 >>> [ 9.109159] [drm:init_status_page], bsd ring hws offset: 0x00024000 >>> [ 9.128085] [drm:intel_modeset_setup_hw_state], [CRTC:3] hw state readout: enabled >>> >>> So it seems somewhere around the ring buffer stuff the boot stops. >>> As a next step I'll insert some debug messages in the linux kernel to isolate >>> the call leading to the hang. >> Are you saying that it is broken with Xen, and differently broken >> without Xen ? > No no, without Xen the linux kernel runs fine. Ok - one place to start might be with iommu=off on the Xen command line and see whether that affects the results. ~Andrew > >>> Maybe anyone has some better ideas or knowledge to hunt the bug. >>> Thanks.