Re: [Xen-devel] dom0 / hypervisor hang on dom0 boot

[Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxx>]

Am Dienstag 14 Mai 2013, 13:51:40 schrieb Andrew Cooper:
> 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.

Yes this works, now the system comes up. This remembers me on a problem we
had in 2010 with wrong bios together with iommu.

Dietmar.

> 
> ~Andrew
> 
> >
> >>> Maybe anyone has some better ideas or knowledge to hunt the bug.
> >>> Thanks.

-- 
Company details: http://ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel