[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] dom0 / hypervisor hang on dom0 boot
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 (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. Maybe anyone has some better ideas or knowledge to hunt the bug. Thanks. Dietmar. -- Company details: http://ts.fujitsu.com/imprint.html _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |