* dom0 / hypervisor hang on dom0 boot @ 2013-05-14 12:35 Dietmar Hahn 2013-05-14 12:42 ` Andrew Cooper 2013-05-14 13:27 ` Jan Beulich 0 siblings, 2 replies; 23+ messages in thread From: Dietmar Hahn @ 2013-05-14 12:35 UTC (permalink / raw) To: xen-devel; +Cc: Konrad Rzeszutek Wilk 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-14 12:35 dom0 / hypervisor hang on dom0 boot Dietmar Hahn @ 2013-05-14 12:42 ` Andrew Cooper 2013-05-14 12:50 ` Dietmar Hahn 2013-05-14 13:27 ` Jan Beulich 1 sibling, 1 reply; 23+ messages in thread From: Andrew Cooper @ 2013-05-14 12:42 UTC (permalink / raw) To: Dietmar Hahn; +Cc: xen-devel, Konrad Rzeszutek Wilk 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. The watchdog is enabled by default with a 5 second timeout. > > (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 ? > > Maybe anyone has some better ideas or knowledge to hunt the bug. > Thanks. > > Dietmar. > > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-14 12:42 ` Andrew Cooper @ 2013-05-14 12:50 ` Dietmar Hahn 2013-05-14 12:51 ` Andrew Cooper 0 siblings, 1 reply; 23+ messages in thread From: Dietmar Hahn @ 2013-05-14 12:50 UTC (permalink / raw) To: xen-devel; +Cc: Andrew Cooper, xen-devel, Konrad Rzeszutek Wilk 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. > > > > > Maybe anyone has some better ideas or knowledge to hunt the bug. > > Thanks. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-14 12:50 ` Dietmar Hahn @ 2013-05-14 12:51 ` Andrew Cooper 2013-05-14 13:25 ` Dietmar Hahn 0 siblings, 1 reply; 23+ messages in thread From: Andrew Cooper @ 2013-05-14 12:51 UTC (permalink / raw) To: Dietmar Hahn; +Cc: xen-devel, Konrad Rzeszutek Wilk, xen-devel 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-14 12:51 ` Andrew Cooper @ 2013-05-14 13:25 ` Dietmar Hahn 0 siblings, 0 replies; 23+ messages in thread From: Dietmar Hahn @ 2013-05-14 13:25 UTC (permalink / raw) To: xen-devel, Konrad Rzeszutek Wilk; +Cc: Andrew Cooper 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-14 12:35 dom0 / hypervisor hang on dom0 boot Dietmar Hahn 2013-05-14 12:42 ` Andrew Cooper @ 2013-05-14 13:27 ` Jan Beulich 2013-05-15 6:53 ` Dietmar Hahn 1 sibling, 1 reply; 23+ messages in thread From: Jan Beulich @ 2013-05-14 13:27 UTC (permalink / raw) To: Dietmar Hahn; +Cc: Konrad Rzeszutek Wilk, xen-devel >>> On 14.05.13 at 14:35, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > [ 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? You should, yes, if the hypervisor is indeed hung. Apart from trying to turn off the IOMMU as Andrew suggested, the more interesting thing might be to turn on IOMMU debugging ("iommu=debug") to see whether there aren't any IOMMU faults. Those shouldn't hang Xen, but then again you never know. You may also want to know that the I relatively recently realized that the AGP and DRM code for IGD doesn't properly handle the Xen case: There are several instances of CONFIG_INTEL_IOMMU dependencies which on our Xen kernel won't have the intended effect (and on pv-ops the way this is being done can't really be correct either afaict, as intel_iommu_gfx_mapped can't possibly get set), since the Dom0 kernel doesn't see any IOMMU. The necessary changes, while in our master branch, didn't get synced over to the 12.3 branch yet. Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-14 13:27 ` Jan Beulich @ 2013-05-15 6:53 ` Dietmar Hahn 2013-05-15 8:35 ` Jan Beulich 0 siblings, 1 reply; 23+ messages in thread From: Dietmar Hahn @ 2013-05-15 6:53 UTC (permalink / raw) To: xen-devel; +Cc: Andrew Cooper, Jan Beulich, Konrad Rzeszutek Wilk Am Dienstag 14 Mai 2013, 14:27:54 schrieb Jan Beulich: > >>> On 14.05.13 at 14:35, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > > [ 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? > > You should, yes, if the hypervisor is indeed hung. > > Apart from trying to turn off the IOMMU as Andrew suggested, > the more interesting thing might be to turn on IOMMU debugging > ("iommu=debug") to see whether there aren't any IOMMU faults. > Those shouldn't hang Xen, but then again you never know. I tried iommu=debug and I can't see any faulting messages but Iam not familiar with this code. I attached the logging, maybe anyone can have a look on this. Thanks for the help. Dietmar. __ __ _ _ _____ _ _ _ \ \/ /___ _ __ | || | |___ / _ _ _ __ ___| |_ __ _| |__ | | ___ \ // _ \ '_ \ | || |_ |_ \ __| | | | '_ \/ __| __/ _` | '_ \| |/ _ \ / \ __/ | | | |__ _| ___) |__| |_| | | | \__ \ || (_| | |_) | | __/ /_/\_\___|_| |_| |_|(_)____/ \__,_|_| |_|___/\__\__,_|_.__/|_|\___| (XEN) Xen version 4.3-unstable (hahn@mch.fsc.net) (gcc (SUSE Linux) 4.7.2 20130108 [gcc-4_7-branch revision 195012]) debug=y Tue May 14 11:22:08 CEST 2013 (XEN) Latest ChangeSet: Mon May 13 14:07:48 2013 +0100 hg:4c6a6b074157-dirty (XEN) Console output is synchronous. (XEN) Bootloader: GRUB2 2.00 (XEN) Command line: console=com1 com1=38400 sync_console debug=yes loglvl=all guest_loglvl=all watchdog iommu=debug (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) VBE/DDC methods: V2; EDID transfer time: 1 seconds (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Xen-e820 RAM map: (XEN) 0000000000000000 - 000000000009d800 (usable) (XEN) 000000000009d800 - 00000000000a0000 (reserved) (XEN) 00000000000ce000 - 00000000000d0000 (reserved) (XEN) 00000000000e4000 - 0000000000100000 (reserved) (XEN) 0000000000100000 - 00000000db7a0000 (usable) (XEN) 00000000db7a0000 - 00000000db7b1000 (ACPI data) (XEN) 00000000db7b1000 - 00000000db7b4000 (ACPI NVS) (XEN) 00000000db7b4000 - 00000000e0000000 (reserved) (XEN) 00000000f8000000 - 00000000fc000000 (reserved) (XEN) 00000000fec00000 - 00000000fec10000 (reserved) (XEN) 00000000fee00000 - 00000000fee01000 (reserved) (XEN) 00000000ffb00000 - 0000000100000000 (reserved) (XEN) 0000000100000000 - 000000010e000000 (usable) (XEN) 000000010e000000 - 0000000110000000 (reserved) (XEN) ACPI: RSDP 000F8EE0, 0024 (r2 PTLTD ) (XEN) ACPI: XSDT DB7AB8D9, 0084 (r1 FSC PC 60000 LTP 0) (XEN) ACPI: FACP DB7B08A5, 00F4 (r3 FSC PC 60000 F4240) (XEN) ACPI: DSDT DB7AB95D, 4ED4 (r1 FSC D2812/A2 60000 MSFT 3000001) (XEN) ACPI: FACS DB7B3FC0, 0040 (XEN) ACPI: TCPA DB7B0999, 0032 (r1 Phoeni x 60000 TL 0) (XEN) ACPI: DMAR DB7B09CB, 00F8 (r1 Intel OEMDMAR 60000 LOHR 1) (XEN) ACPI: SSDT DB7B0AC3, 00F8 (r1 FSC PST_PR00 60000 CSF 1) (XEN) ACPI: SSDT DB7B0BBB, 00F8 (r1 FSC PST_PR01 60000 CSF 1) (XEN) ACPI: SPCR DB7B0CB3, 0050 (r1 PTLTD $UCRTBL$ 60000 PTL 1) (XEN) ACPI: SLIC DB7B0D03, 0176 (r1 FSC PC 60000 LTP 0) (XEN) ACPI: MCFG DB7B0E79, 003C (r1 PTLTD MCFG 60000 LTP 0) (XEN) ACPI: HPET DB7B0EB5, 0038 (r1 PTLTD HPETTBL 60000 LTP 1) (XEN) ACPI: APIC DB7B0EED, 0068 (r1 PTLTD APIC 60000 LTP 0) (XEN) ACPI: BOOT DB7B0F55, 0028 (r1 PTLTD $SBFTBL$ 60000 LTP 1) (XEN) ACPI: ASF! DB7B0F7D, 0083 (r16 CETP CETP 60000 PTL 1) (XEN) System RAM: 3735MB (3824884kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-000000010e000000 (XEN) Domain heap initialised (XEN) found SMP MP-table at 000f8fe0 (XEN) DMI present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x1008 (XEN) ACPI: SLEEP INFO: pm1x_cnt[1004,0], pm1x_evt[1000,0] (XEN) ACPI: wakeup_vec[db7b3fcc], vec_size[20] (XEN) ACPI: Local APIC address 0xfee00000 (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) (XEN) Processor #0 7:7 APIC version 20 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) (XEN) Processor #1 7:7 APIC version 20 (XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) (XEN) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) ACPI: IRQ9 used by override. (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000 (XEN) [VT-D]dmar.c:767: Host address width 36 (XEN) [VT-D]dmar.c:781: found ACPI_DMAR_DRHD: (XEN) [VT-D]dmar.c:461: dmaru->address = fed90000 (XEN) [VT-D]iommu.c:1158: drhd->address = fed90000 iommu->reg = ffff82c3ffd54000 (XEN) [VT-D]iommu.c:1160: cap = c9008020e30272 ecap = 1000 (XEN) [VT-D]dmar.c:382: endpoint: 0000:00:1b.0 (XEN) [VT-D]dmar.c:781: found ACPI_DMAR_DRHD: (XEN) [VT-D]dmar.c:461: dmaru->address = fed91000 (XEN) [VT-D]iommu.c:1158: drhd->address = fed91000 iommu->reg = ffff82c3ffd53000 (XEN) [VT-D]iommu.c:1160: cap = c0000020630272 ecap = 1000 (XEN) [VT-D]dmar.c:382: endpoint: 0000:00:02.0 (XEN) [VT-D]dmar.c:382: endpoint: 0000:00:02.1 (XEN) [VT-D]dmar.c:781: found ACPI_DMAR_DRHD: (XEN) [VT-D]dmar.c:461: dmaru->address = fed92000 (XEN) [VT-D]iommu.c:1158: drhd->address = fed92000 iommu->reg = ffff82c3ffd52000 (XEN) [VT-D]iommu.c:1160: cap = c0000020630272 ecap = 1000 (XEN) [VT-D]dmar.c:382: endpoint: 0000:00:03.0 (XEN) [VT-D]dmar.c:382: endpoint: 0000:00:03.2 (XEN) [VT-D]dmar.c:382: endpoint: 0000:00:03.3 (XEN) [VT-D]dmar.c:781: found ACPI_DMAR_DRHD: (XEN) [VT-D]dmar.c:461: dmaru->address = fed93000 (XEN) [VT-D]iommu.c:1158: drhd->address = fed93000 iommu->reg = ffff82c3ffd51000 (XEN) [VT-D]iommu.c:1160: cap = c9008020630272 ecap = 1000 (XEN) [VT-D]dmar.c:475: flags: INCLUDE_ALL (XEN) [VT-D]dmar.c:786: found ACPI_DMAR_RMRR: (XEN) [VT-D]dmar.c:382: endpoint: 0000:00:1d.0 (XEN) [VT-D]dmar.c:382: endpoint: 0000:00:1d.1 (XEN) [VT-D]dmar.c:382: endpoint: 0000:00:1d.2 (XEN) [VT-D]dmar.c:382: endpoint: 0000:00:1d.7 (XEN) [VT-D]dmar.c:382: endpoint: 0000:00:1a.0 (XEN) [VT-D]dmar.c:382: endpoint: 0000:00:1a.1 (XEN) [VT-D]dmar.c:382: endpoint: 0000:00:1a.2 (XEN) [VT-D]dmar.c:382: endpoint: 0000:00:1a.7 (XEN) [VT-D]dmar.c:655: RMRR region: base_addr db7b4000 end_address db7fffff (XEN) ERST table was not found (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 2 CPUs (0 hotplug CPUs) (XEN) IRQ limits: 24 GSI, 376 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 3166.732 MHz processor. (XEN) Initing memory sharing. (XEN) xstate_init: using cntxt_size: 0x240 and states: 0x3 (XEN) mce_intel.c:717: MCA Capability: BCAST 1 SER 0 CMCI 0 firstbank 1 extended MCE MSR 0 (XEN) Intel machine check reporting enabled (XEN) PCI: MCFG configuration 0: base f8000000 segment 0000 buses 00 - 03 (XEN) PCI: MCFG area at f8000000 reserved in E820 (XEN) PCI: Using MCFG for segment 0000 bus 00-03 (XEN) Intel VT-d iommu 2 supported page sizes: 4kB. (XEN) traps.c:3072: GPF (0000): ffff82c4c02934b6 -> ffff82c4c022d776 (XEN) Intel VT-d iommu 1 supported page sizes: 4kB. (XEN) traps.c:3072: GPF (0000): ffff82c4c02934b6 -> ffff82c4c022d776 (XEN) Intel VT-d iommu 0 supported page sizes: 4kB. (XEN) traps.c:3072: GPF (0000): ffff82c4c02934b6 -> ffff82c4c022d776 (XEN) Intel VT-d iommu 3 supported page sizes: 4kB. (XEN) traps.c:3072: GPF (0000): ffff82c4c02934b6 -> ffff82c4c022d776 (XEN) Intel VT-d Snoop Control not enabled. (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) Intel VT-d Queued Invalidation not enabled. (XEN) Intel VT-d Interrupt Remapping not enabled. (XEN) Intel VT-d Shared EPT tables not enabled. (XEN) I/O virtualisation enabled (XEN) - Dom0 mode: Relaxed (XEN) Interrupt remapping disabled (XEN) ENABLING IO-APIC IRQs (XEN) -> Using new ACK method (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) Using TSC rendezvous (XEN) Platform timer is 14.318MHz HPET (XEN) Allocated console ring of 16 KiB. (XEN) mwait-idle: does not run on family 6 model 23 (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) HVM: ASIDs disabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging (HAP) not detected (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) (XEN) ACPI sleep modes: S3 (XEN) mcheck_poll: Machine check polling timer started. (XEN) *** LOADING DOMAIN 0 *** (XEN) elf_parse_binary: phdr: paddr=0x2000 memsz=0x87c000 (XEN) elf_parse_binary: phdr: paddr=0x87e000 memsz=0x7f0f0 (XEN) elf_parse_binary: phdr: paddr=0x8fe000 memsz=0xb700 (XEN) elf_parse_binary: phdr: paddr=0x90a000 memsz=0x15b000 (XEN) elf_parse_binary: memory: 0x2000 -> 0xa65000 (XEN) elf_xen_parse_note: GUEST_OS = "linux" (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6" (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0" (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0 (XEN) elf_xen_parse_note: ENTRY = 0xffffffff80002000 (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff80003000 (XEN) elf_xen_parse_note: unknown xen elf note (0xd) (XEN) elf_xen_parse_note: MOD_START_PFN = 0x1 (XEN) elf_xen_parse_note: INIT_P2M = 0xffffea0000000000 (XEN) elf_xen_parse_note: FEATURES = "writable_page_tables|writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel" (XEN) elf_xen_parse_note: SUPPORTED_FEATURES = 0x80f (XEN) elf_xen_parse_note: LOADER = "generic" (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1 (XEN) elf_xen_addr_calc_check: addresses: (XEN) virt_base = 0xffffffff80000000 (XEN) elf_paddr_offset = 0x0 (XEN) virt_offset = 0xffffffff80000000 (XEN) virt_kstart = 0xffffffff80002000 (XEN) virt_kend = 0xffffffff80a65000 (XEN) virt_entry = 0xffffffff80002000 (XEN) p2m_base = 0xffffea0000000000 (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, lsb, paddr 0x2000 -> 0xa65000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000105000000->0000000106000000 (888220 pages to be allocated) (XEN) Init. ramdisk: 0000000109ff3000->000000010e000000 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff80002000->ffffffff80a65000 (XEN) Init. ramdisk: 0000000000000000->0000000000000000 (XEN) Phys-Mach map: ffffea0000000000->ffffea00006eed48 (XEN) Start info: ffffffff80a65000->ffffffff80a654b4 (XEN) Page tables: ffffffff80a66000->ffffffff80a6f000 (XEN) Boot stack: ffffffff80a6f000->ffffffff80a70000 (XEN) TOTAL: ffffffff80000000->ffffffff80c00000 (XEN) ENTRY ADDRESS: ffffffff80002000 (XEN) Dom0 has maximum 2 VCPUs (XEN) elf_load_binary: phdr 0 at 0xffffffff80002000 -> 0xffffffff8087e000 (XEN) elf_load_binary: phdr 1 at 0xffffffff8087e000 -> 0xffffffff808fd0f0 (XEN) elf_load_binary: phdr 2 at 0xffffffff808fe000 -> 0xffffffff80909700 (XEN) elf_load_binary: phdr 3 at 0xffffffff8090a000 -> 0xffffffff80971000 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:00.0 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:02.0 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:02.1 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:03.0 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:03.2 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:03.3 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:19.0 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:1a.0 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:1a.1 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:1a.2 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:1a.7 (XEN) [VT-D]iommu.c:1441: d0:PCIe: map 0000:00:1b.0 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:1d.0 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:1d.1 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:1d.2 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:1d.7 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:1f.0 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:1f.2 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:1f.3 (XEN) [VT-D]iommu.c:1453: d0:PCI: map 0000:00:1f.5 (XEN) [VT-D]iommu.c:755: iommu_enable_translation: iommu->reg = ffff82c3ffd52000 (XEN) [VT-D]iommu.c:755: iommu_enable_translation: iommu->reg = ffff82c3ffd53000 (XEN) [VT-D]iommu.c:755: iommu_enable_translation: iommu->reg = ffff82c3ffd54000 (XEN) [VT-D]iommu.c:755: iommu_enable_translation: iommu->reg = ffff82c3ffd51000 (XEN) Scrubbing Free RAM: .done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input to DOM0) (XEN) Freed 272kB init memory. [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.7.10-1.4-xen (geeko@buildhost) (gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) ) #1 SMP Fri Apr 19 12:06:34 UTC 2013 (8ef74f8) [ 0.000000] Command line: root=UUID=f52a54a2-6dda-463a-8ec8-01a04994fdd4 ro resume=/dev/disk/by-id/ata-ST3500418AS_9VM9YKSH-part5 showopts debug console=tty0 console=ttyS0,38400 xencons=ttyS0 drm.debug=6 [ 0.000000] Xen-provided machine memory map: [ 0.000000] BIOS: [mem 0x0000000000000000-0x000000000009d7ff] usable [ 0.000000] BIOS: [mem 0x000000000009d800-0x000000000009ffff] reserved [ 0.000000] BIOS: [mem 0x00000000000ce000-0x00000000000cffff] reserved [ 0.000000] BIOS: [mem 0x00000000000e4000-0x00000000000fffff] reserved [ 0.000000] BIOS: [mem 0x0000000000100000-0x00000000db79ffff] usable [ 0.000000] BIOS: [mem 0x00000000db7a0000-0x00000000db7b0fff] ACPI data [ 0.000000] BIOS: [mem 0x00000000db7b1000-0x00000000db7b3fff] ACPI NVS [ 0.000000] BIOS: [mem 0x00000000db7b4000-0x00000000dfffffff] reserved [ 0.000000] BIOS: [mem 0x00000000f8000000-0x00000000fbffffff] reserved [ 0.000000] BIOS: [mem 0x00000000fec00000-0x00000000fec0ffff] reserved [ 0.000000] BIOS: [mem 0x00000000fee00000-0x00000000fee00fff] reserved [ 0.000000] BIOS: [mem 0x00000000ffb00000-0x00000000ffffffff] reserved [ 0.000000] BIOS: [mem 0x0000000100000000-0x000000010dffffff] usable [ 0.000000] BIOS: [mem 0x000000010e000000-0x000000010fffffff] reserved [ 0.000000] e820: Xen-provided physical RAM map: [ 0.000000] Xen: [mem 0x0000000000000000-0x00000000de5a8fff] usable [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] SMBIOS 2.5 present. [ 0.000000] DMI: FUJITSU ESPRIMO P7935 /D2812-A2, BIOS 6.00 R1.20.2812.A2 01/12/2010 [ 0.000000] e820: last_pfn = 0xde5a9 max_arch_pfn = 0x80000000 [ 0.000000] found SMP MP-table at [mem 0x000f8fe0-0x000f8fef] mapped at [ffffffffff5f2fe0] [ 0.000000] initial memory mapped: [mem 0x00000000-0xffffffffffffffff] [ 0.000000] init_memory_mapping: [mem 0x00000000-0x0500cfff] [ 0.000000] [mem 0x00000000-0x0500cfff] page 4k [ 0.000000] kernel direct mapping tables up to 0x500cfff @ [mem 0x00a6f000-0x00a99fff] [ 0.000000] init_memory_mapping: [mem 0x056ff000-0xde5a8fff] [ 0.000000] [mem 0x056ff000-0xde5a8fff] page 4k [ 0.000000] kernel direct mapping tables up to 0xde5a8fff @ [mem 0x00a9a000-0x01166fff] [ 0.000000] init_memory_mapping: [mem 0x0500d000-0x056fefff] [ 0.000000] [mem 0x0500d000-0x056fefff] page 4k [ 0.000000] kernel direct mapping tables up to 0x56fefff @ [mem 0x05864000-0x05869fff] [ 0.000000] RAMDISK: [mem 0x01000000-0x0500cfff] [ 0.000000] ACPI: RSDP 00000000000f8ee0 00024 (v02 PTLTD ) [ 0.000000] ACPI: XSDT 00000000db7ab8d9 00084 (v01 FSC PC 00060000 LTP 00000000) [ 0.000000] ACPI: FACP 00000000db7b08a5 000F4 (v03 FSC PC 00060000 000F4240) [ 0.000000] ACPI: DSDT 00000000db7ab95d 04ED4 (v01 FSC D2812/A2 00060000 MSFT 03000001) [ 0.000000] ACPI: FACS 00000000db7b3fc0 00040 [ 0.000000] ACPI: TCPA 00000000db7b0999 00032 (v01 Phoeni x 00060000 TL 00000000) [ 0.000000] ACPI: XMAR 00000000db7b09cb 000F8 (v01 Intel OEMDMAR 00060000 LOHR 00000001) [ 0.000000] ACPI: SSDT 00000000db7b0ac3 000F8 (v01 FSC PST_PR00 00060000 CSF 00000001) [ 0.000000] ACPI: SSDT 00000000db7b0bbb 000F8 (v01 FSC PST_PR01 00060000 CSF 00000001) [ 0.000000] ACPI: SPCR 00000000db7b0cb3 00050 (v01 PTLTD $UCRTBL$ 00060000 PTL 00000001) [ 0.000000] ACPI: SLIC 00000000db7b0d03 00176 (v01 FSC PC 00060000 LTP 00000000) [ 0.000000] ACPI: MCFG 00000000db7b0e79 0003C (v01 PTLTD MCFG 00060000 LTP 00000000) [ 0.000000] ACPI: HPET 00000000db7b0eb5 00038 (v01 PTLTD HPETTBL 00060000 LTP 00000001) [ 0.000000] ACPI: APIC 00000000db7b0eed 00068 (v01 PTLTD ? APIC 00060000 LTP 00000000) [ 0.000000] ACPI: BOOT 00000000db7b0f55 00028 (v01 PTLTD $SBFTBL$ 00060000 LTP 00000001) [ 0.000000] ACPI: ASF! 00000000db7b0f7d 00083 (v16 CETP CETP 00060000 PTL 00000001) [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00000000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00000000-0xde5a8fff] [ 0.000000] On node 0 totalpages: 910761 [ 0.000000] free_area_init_node: node 0, pgdat ffffffff808e4000, node_mem_map ffff8800dacfd000 [ 0.000000] DMA zone: 56 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 4040 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 12396 pages used for memmap [ 0.000000] DMA32 zone: 894269 pages, LIFO batch:31 [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ2 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] e820: [mem 0xe0000000-0xf7ffffff] available for PCI devices [ 0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:2 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 19 pages/cpu @ffff8800da200000 s46848 r8192 d22784 u1048576 [ 0.000000] pcpu-alloc: s46848 r8192 d22784 u1048576 alloc=1*2097152 [ 0.000000] pcpu-alloc: [0] 0 1 [ 0.000000] Swapping MFNs for PFN 905 and da207 (MFN 105905 and 101ef8) [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 898309 [ 0.000000] Kernel command line: root=UUID=f52a54a2-6dda-463a-8ec8-01a04994fdd4 ro resume=/dev/disk/by-id/ata-ST3500418AS_9VM9YKSH-part5 showopts debug console=tty0 console=ttyS0,38400 xencons=ttyS0 drm.debug=6 [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) [ 0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) [ 0.000000] __ex_table already sorted, skipping sort [ 0.000000] xsave: enabled xstate_bv 0x3, cntxt size 0x240 [ 0.000000] allocated 14572176 bytes of page_cgroup [ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups [ 0.000000] Software IO TLB enabled: [ 0.000000] Aperture: 64 megabytes [ 0.000000] Address size: 27 bits [ 0.000000] Kernel range: ffff8800d501a000 - ffff8800d901a000 [ 0.000000] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [ 0.000000] Memory: 3402928k/3643044k available (5170k kernel code, 0k absent, 240116k reserved, 4024k data, 432k init) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=2. [ 0.000000] nr_pirqs: 40 [ 0.000000] NR_IRQS:67328 nr_irqs:2792 16 [ 0.000000] Extended CMOS year: 2000 [ 0.000000] Xen reported: 3166.732 MHz processor. [ 0.000000] Console: colour VGA+ 80x25 [ 0.000000] console [tty0] enabled [ 0.000000] console [ttyS0] enabled [ 0.080001] Calibrating delay using timer specific routine.. 6416.08 BogoMIPS (lpj=12832164) [ 0.088002] pid_max: default: 32768 minimum: 301 [ 0.092028] Security Framework initialized [ 0.096010] AppArmor: AppArmor initialized [ 0.100010] Mount-cache hash table entries: 256 [ 0.104165] Initializing cgroup subsys cpuacct [ 0.108002] Initializing cgroup subsys memory [ 0.112009] Initializing cgroup subsys devices [ 0.116002] Initializing cgroup subsys freezer [ 0.120002] Initializing cgroup subsys net_cls [ 0.124002] Initializing cgroup subsys blkio [ 0.128002] Initializing cgroup subsys perf_event [ 0.132036] mce: CPU supports 2 MCE banks [ 0.136012] Last level iTLB entries: 4KB 128, 2MB 4, 4MB 4 [ 0.136012] Last level dTLB entries: 4KB 256, 2MB 0, 4MB 32 [ 0.136012] tlb_flushall_shift: -1 [ 0.175232] ACPI: Core revision 20120913 [ 0.184614] SMP alternatives: switching to SMP code [ 0.223261] Brought up 2 CPUs [ 0.224067] devtmpfs: initialized [ 0.228141] RTC time: 8:12:24, date: 05/15/13 [ 0.232044] NET: Registered protocol family 16 [ 0.236100] ACPI: bus type pci registered [ 0.240058] PCI: MMCONFIG for domain 0000 [bus 00-03] at [mem 0xf8000000-0xf83fffff] (base 0xf8000000) [ 0.244003] PCI: MMCONFIG at [mem 0xf8000000-0xf83fffff] reserved in E820 [ 0.248271] PCI: Using configuration type 1 for base access [ 0.252048] patch_vdso64: .altinstructions not found [ 0.256002] patch_vdsox32: .altinstructions not found [ 0.260391] bio: create slab <bio-0> at 0 [ 0.264037] ACPI: Added _OSI(Module Device) [ 0.268003] ACPI: Added _OSI(Processor Device) [ 0.272002] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.276002] ACPI: Added _OSI(Processor Aggregator Device) [ 0.280745] ACPI: EC: Look up EC in DSDT [ 0.286933] ACPI: Interpreter enabled [ 0.288004] ACPI: (supports S0 S3 S5) [ 0.294357] ACPI: Using IOAPIC for interrupt routing [ 0.299586] ACPI: No dock devices found. [ 0.300004] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 0.304648] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff]) [ 0.309240] pci_root PNP0A08:00: [Firmware Info]: MMCONFIG for domain 0000 [bus 00-03] only partially covers this bridge [ 0.312022] PCI host bridge to bus 0000:00 [ 0.316003] pci_bus 0000:00: root bus resource [bus 00-ff] [ 0.320002] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7] [ 0.324002] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff] [ 0.328002] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff] [ 0.332002] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000d3fff] [ 0.336002] pci_bus 0000:00: root bus resource [mem 0x000d4000-0x000d7fff] [ 0.340002] pci_bus 0000:00: root bus resource [mem 0x000d8000-0x000dbfff] [ 0.344003] pci_bus 0000:00: root bus resource [mem 0x000dc000-0x000dffff] [ 0.348002] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000e3fff] [ 0.352002] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xf7ffffff] [ 0.356002] pci_bus 0000:00: root bus resource [mem 0xfc000000-0xfebfffff] [ 0.360002] pci_bus 0000:00: root bus resource [mem 0xfed00000-0xfedfffff] [ 0.364002] pci_bus 0000:00: root bus resource [mem 0xfef00000-0xffafffff] [ 0.368002] pci_bus 0000:00: root bus resource [mem 0xffc00000-0xffefffff] [ 0.372014] pci 0000:00:00.0: [8086:2e10] type 00 class 0x060000 [ 0.376082] pci 0000:00:02.0: [8086:2e12] type 00 class 0x030000 [ 0.380024] pci 0000:00:02.0: reg 10: [mem 0xfc000000-0xfc3fffff 64bit] [ 0.384015] pci 0000:00:02.0: reg 18: [mem 0xe0000000-0xefffffff 64bit pref] [ 0.388011] pci 0000:00:02.0: reg 20: [io 0x1c70-0x1c77] [ 0.392070] pci 0000:00:02.1: [8086:2e13] type 00 class 0x038000 [ 0.396021] pci 0000:00:02.1: reg 10: [mem 0xfc400000-0xfc4fffff 64bit] [ 0.400097] pci 0000:00:03.0: [8086:2e14] type 00 class 0x078000 [ 0.404040] pci 0000:00:03.0: reg 10: [mem 0xfc524000-0xfc52400f 64bit] [ 0.408101] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold [ 0.412031] pci 0000:00:03.2: [8086:2e16] type 00 class 0x010185 [ 0.416034] pci 0000:00:03.2: reg 10: [io 0x1c88-0x1c8f] [ 0.420017] pci 0000:00:03.2: reg 14: [io 0x1c7c-0x1c7f] [ 0.424018] pci 0000:00:03.2: reg 18: [io 0x1c80-0x1c87] [ 0.428012] pci 0000:00:03.2: reg 1c: [io 0x1c78-0x1c7b] [ 0.432017] pci 0000:00:03.2: reg 20: [io 0x1c20-0x1c2f] [ 0.436136] pci 0000:00:03.3: [8086:2e17] type 00 class 0x070002 [ 0.440035] pci 0000:00:03.3: reg 10: [io 0x1c90-0x1c97] [ 0.444017] pci 0000:00:03.3: reg 14: [mem 0xfc526000-0xfc526fff] [ 0.448232] pci 0000:00:19.0: [8086:10de] type 00 class 0x020000 [ 0.452038] pci 0000:00:19.0: reg 10: [mem 0xfc500000-0xfc51ffff] [ 0.456017] pci 0000:00:19.0: reg 14: [mem 0xfc527000-0xfc527fff] [ 0.460017] pci 0000:00:19.0: reg 18: [io 0x1820-0x183f] [ 0.464136] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold [ 0.468040] pci 0000:00:1a.0: [8086:3a67] type 00 class 0x0c0300 [ 0.472086] pci 0000:00:1a.0: reg 20: [io 0x1840-0x185f] [ 0.476102] pci 0000:00:1a.1: [8086:3a68] type 00 class 0x0c0300 [ 0.480087] pci 0000:00:1a.1: reg 20: [io 0x1860-0x187f] [ 0.484102] pci 0000:00:1a.2: [8086:3a69] type 00 class 0x0c0300 [ 0.488087] pci 0000:00:1a.2: reg 20: [io 0x1880-0x189f] [ 0.492119] pci 0000:00:1a.7: [8086:3a6c] type 00 class 0x0c0320 [ 0.496038] pci 0000:00:1a.7: reg 10: [mem 0xfc528000-0xfc5283ff] [ 0.500166] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold [ 0.504050] pci 0000:00:1b.0: [8086:3a6e] type 00 class 0x040300 [ 0.508031] pci 0000:00:1b.0: reg 10: [mem 0xfc520000-0xfc523fff 64bit] [ 0.512148] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold [ 0.516046] pci 0000:00:1c.0: [8086:3a70] type 01 class 0x060400 [ 0.520153] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold [ 0.524057] pci 0000:00:1c.4: [8086:3a78] type 01 class 0x060400 [ 0.528153] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold [ 0.532054] pci 0000:00:1d.0: [8086:3a64] type 00 class 0x0c0300 [ 0.536087] pci 0000:00:1d.0: reg 20: [io 0x18a0-0x18bf] [ 0.540102] pci 0000:00:1d.1: [8086:3a65] type 00 class 0x0c0300 [ 0.544087] pci 0000:00:1d.1: reg 20: [io 0x18c0-0x18df] [ 0.548102] pci 0000:00:1d.2: [8086:3a66] type 00 class 0x0c0300 [ 0.552087] pci 0000:00:1d.2: reg 20: [io 0x18e0-0x18ff] [ 0.556119] pci 0000:00:1d.7: [8086:3a6a] type 00 class 0x0c0320 [ 0.560038] pci 0000:00:1d.7: reg 10: [mem 0xfc529000-0xfc5293ff] [ 0.564166] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold [ 0.568040] pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401 [ 0.572133] pci 0000:00:1f.0: [8086:3a14] type 00 class 0x060100 [ 0.576200] pci 0000:00:1f.2: [8086:3a00] type 00 class 0x01018a [ 0.580034] pci 0000:00:1f.2: reg 10: [io 0x0000-0x0007] [ 0.584017] pci 0000:00:1f.2: reg 14: [io 0x0000-0x0003] [ 0.588017] pci 0000:00:1f.2: reg 18: [io 0x0000-0x0007] [ 0.592017] pci 0000:00:1f.2: reg 1c: [io 0x0000-0x0003] [ 0.596017] pci 0000:00:1f.2: reg 20: [io 0x1c40-0x1c4f] [ 0.600017] pci 0000:00:1f.2: reg 24: [io 0x1c30-0x1c3f] [ 0.604104] pci 0000:00:1f.3: [8086:3a60] type 00 class 0x0c0500 [ 0.608032] pci 0000:00:1f.3: reg 10: [mem 0xfc52a000-0xfc52a0ff 64bit] [ 0.612046] pci 0000:00:1f.3: reg 20: [io 0x1100-0x111f] [ 0.616073] pci 0000:00:1f.5: [8086:3a06] type 00 class 0x010185 [ 0.620034] pci 0000:00:1f.5: reg 10: [io 0x1cc0-0x1cc7] [ 0.624018] pci 0000:00:1f.5: reg 14: [io 0x1cb4-0x1cb7] [ 0.628017] pci 0000:00:1f.5: reg 18: [io 0x1cb8-0x1cbf] [ 0.632017] pci 0000:00:1f.5: reg 1c: [io 0x1cb0-0x1cb3] [ 0.636017] pci 0000:00:1f.5: reg 20: [io 0x1c60-0x1c6f] [ 0.640017] pci 0000:00:1f.5: reg 24: [io 0x1c50-0x1c5f] [ 0.644178] pci 0000:00:1c.0: PCI bridge to [bus 01] [ 0.648102] pci 0000:00:1c.4: PCI bridge to [bus 02] [ 0.652127] pci 0000:00:1e.0: PCI bridge to [bus 03] (subtractive decode) [ 0.656020] pci 0000:00:1e.0: bridge window [io 0x0000-0x0cf7] (subtractive decode) [ 0.660002] pci 0000:00:1e.0: bridge window [io 0x0d00-0xffff] (subtractive decode) [ 0.664003] pci 0000:00:1e.0: bridge window [mem 0x000a0000-0x000bffff] (subtractive decode) [ 0.668002] pci 0000:00:1e.0: bridge window [mem 0x000d0000-0x000d3fff] (subtractive decode) [ 0.672002] pci 0000:00:1e.0: bridge window [mem 0x000d4000-0x000d7fff] (subtractive decode) [ 0.676002] pci 0000:00:1e.0: bridge window [mem 0x000d8000-0x000dbfff] (subtractive decode) [ 0.680002] pci 0000:00:1e.0: bridge window [mem 0x000dc000-0x000dffff] (subtractive decode) [ 0.684002] pci 0000:00:1e.0: bridge window [mem 0x000e0000-0x000e3fff] (subtractive decode) [ 0.688003] pci 0000:00:1e.0: bridge window [mem 0xe0000000-0xf7ffffff] (subtractive decode) [ 0.692002] pci 0000:00:1e.0: bridge window [mem 0xfc000000-0xfebfffff] (subtractive decode) [ 0.696002] pci 0000:00:1e.0: bridge window [mem 0xfed00000-0xfedfffff] (subtractive decode) [ 0.700002] pci 0000:00:1e.0: bridge window [mem 0xfef00000-0xffafffff] (subtractive decode) [ 0.704003] pci 0000:00:1e.0: bridge window [mem 0xffc00000-0xffefffff] (subtractive decode) [ 0.708030] pci_bus 0000:00: on NUMA node 0 [ 0.712003] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.716120] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEXB._PRT] [ 0.720036] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEXC._PRT] [ 0.724058] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCIH._PRT] [ 0.728086] pci0000:00: ACPI _OSC support notification failed, disabling PCIe ASPM [ 0.732003] pci0000:00: Unable to request _OSC control (_OSC support mask: 0x08) (XEN) PCI add device 0000:00:00.0 (XEN) PCI add device 0000:00:02.0 (XEN) PCI add device 0000:00:02.1 (XEN) PCI add device 0000:00:03.0 (XEN) PCI add device 0000:00:03.2 (XEN) PCI add device 0000:00:03.3 (XEN) PCI add device 0000:00:19.0 (XEN) PCI add device 0000:00:1a.0 (XEN) PCI add device 0000:00:1a.1 (XEN) PCI add device 0000:00:1a.2 (XEN) PCI add device 0000:00:1a.7 (XEN) PCI add device 0000:00:1b.0 (XEN) PCI add device 0000:00:1c.0 (XEN) PCI add device 0000:00:1c.4 (XEN) PCI add device 0000:00:1d.0 (XEN) PCI add device 0000:00:1d.1 (XEN) PCI add device 0000:00:1d.2 (XEN) PCI add device 0000:00:1d.7 (XEN) PCI add device 0000:00:1e.0 (XEN) PCI add device 0000:00:1f.0 (XEN) PCI add device 0000:00:1f.2 (XEN) PCI add device 0000:00:1f.3 (XEN) PCI add device 0000:00:1f.5 [ 0.828097] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 7 9 10 *11 12 14 15) [ 0.838429] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 7 9 10 11 12 14 15) *5 [ 0.847203] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 7 9 *10 11 12 14 15) [ 0.854427] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 7 9 10 *11 12 14 15) [ 0.862423] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 7 *9 10 11 12 14 15) [ 0.870425] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 7 9 10 *11 12 14 15) [ 0.878426] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 7 9 10 *11 12 14 15) [ 0.886424] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 7 9 10 *11 12 14 15) [ 0.894390] pci 0000:00:02.0: GSI16: level-low [ 0.896005] pci 0000:00:03.2: GSI18: level-low [ 0.900004] pci 0000:00:03.3: GSI17: level-low [ 0.904004] pci 0000:00:19.0: GSI23: level-low [ 0.908004] pci 0000:00:1a.0: GSI20: level-low [ 0.912004] pci 0000:00:1a.2: GSI19: level-low [ 0.916005] pci 0000:00:1c.4: GSI22: level-low [ 0.920005] pci 0000:00:1d.2: GSI21: level-low [ 0.924024] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none [ 0.928005] vgaarb: loaded [ 0.932001] vgaarb: bridge control possible 0000:00:02.0 [ 0.936043] xen_mem: Initialising balloon driver. [ 0.940080] xen/balloon: Xen selfballooning driver disabled for domain0. [ 0.944068] SCSI subsystem initialized [ 0.948003] ACPI: bus type scsi registered [ 0.952016] libata version 3.00 loaded. [ 0.956044] PCI: Using ACPI for IRQ routing [ 0.960003] PCI: pci_cache_line_size set to 64 bytes [ 0.964107] e820: reserve RAM buffer [mem 0x0009d800-0x0009ffff] [ 0.968002] e820: reserve RAM buffer [mem 0xdb7a0000-0xdbffffff] [ 0.972002] e820: reserve RAM buffer [mem 0x10e000000-0x10fffffff] [ 0.976066] NetLabel: Initializing [ 0.980002] NetLabel: domain hash size = 128 [ 0.984001] NetLabel: protocols = UNLABELED CIPSOv4 [ 0.988010] NetLabel: unlabeled traffic allowed by default [ 0.992020] Switching to clocksource xen [ 0.997860] AppArmor: AppArmor Filesystem Enabled [ 1.011498] pnp: PnP ACPI init [ 1.020567] ACPI: bus type pnp registered [ 1.033148] pnp 00:00: [bus 00-ff] [ 1.042870] pnp 00:00: [io 0x0000-0x0cf7 window] [ 1.056890] pnp 00:00: [io 0x0d00-0xffff window] [ 1.070911] pnp 00:00: [io 0x0cf8-0x0cff] [ 1.083111] pnp 00:00: [mem 0x000a0000-0x000bffff window] [ 1.099249] pnp 00:00: [mem 0x000c0000-0x000c3fff window] [ 1.115342] pnp 00:00: [mem 0x000c4000-0x000c7fff window] [ 1.131439] pnp 00:00: [mem 0x000c8000-0x000cbfff window] [ 1.147535] pnp 00:00: [mem 0x000cc000-0x000cffff window] [ 1.163631] pnp 00:00: [mem 0x000d0000-0x000d3fff window] [ 1.179728] pnp 00:00: [mem 0x000d4000-0x000d7fff window] [ 1.195825] pnp 00:00: [mem 0x000d8000-0x000dbfff window] [ 1.211923] pnp 00:00: [mem 0x000dc000-0x000dffff window] [ 1.228020] pnp 00:00: [mem 0x000e0000-0x000e3fff window] [ 1.244116] pnp 00:00: [mem 0x000e4000-0x000e7fff window] [ 1.260211] pnp 00:00: [mem 0x000e8000-0x000ebfff window] [ 1.276308] pnp 00:00: [mem 0x000ec000-0x000effff window] [ 1.292405] pnp 00:00: [mem 0x000f0000-0x000fffff window] [ 1.308501] pnp 00:00: [mem 0xe0000000-0xf7ffffff window] [ 1.324598] pnp 00:00: [mem 0xfc000000-0xfebfffff window] [ 1.340696] pnp 00:00: [mem 0xfed00000-0xfedfffff window] [ 1.356790] pnp 00:00: [mem 0xfef00000-0xffafffff window] [ 1.372888] pnp 00:00: [mem 0xffc00000-0xffefffff window] [ 1.389009] pnp 00:00: Plug and Play ACPI device, IDs PNP0a08 PNP0a03 (active) [ 1.410678] pnp 00:01: [io 0x002e-0x002f] [ 1.422735] pnp 00:01: [mem 0xfed40000-0xfed44fff] [ 1.437033] pnp 00:01: Plug and Play ACPI device, IDs IFX0102 PNP0c31 (active) [ 1.458716] pnp 00:02: [mem 0xffb00000-0xffbfffff] [ 1.472862] pnp 00:02: Plug and Play ACPI device, IDs INT0800 (active) [ 1.492451] pnp 00:03: [io 0x0010-0x001f] [ 1.504516] pnp 00:03: [io 0x0022-0x002d] [ 1.516716] pnp 00:03: [io 0x0030-0x003f] [ 1.528917] pnp 00:03: [io 0x0050-0x0053] [ 1.541120] pnp 00:03: [io 0x0062-0x0063] [ 1.553322] pnp 00:03: [io 0x0065-0x006f] [ 1.565524] pnp 00:03: [io 0x0074-0x007f] [ 1.578240] pnp 00:03: [io 0x0090-0x009f] [ 1.590036] pnp 00:03: [io 0x00a2-0x00b1] [ 1.602241] pnp 00:03: [io 0x00b2-0x00b3] [ 1.614441] pnp 00:03: [io 0x00b4-0x00bf] [ 1.626643] pnp 00:03: [io 0x00ec-0x00ef] [ 1.638848] pnp 00:03: [io 0x0072-0x0073] [ 1.651048] pnp 00:03: [io 0x004e-0x004f] [ 1.663251] pnp 00:03: [io 0x04d0-0x04d1] [ 1.675452] pnp 00:03: [io 0x1000-0x107f] [ 1.687656] pnp 00:03: [io 0x1180-0x11bf] [ 1.699857] pnp 00:03: [io 0x0500-0x057f] [ 1.712060] pnp 00:03: [io 0x0800-0x080f] [ 1.724263] pnp 00:03: [io 0x0810-0x081f] [ 1.736464] pnp 00:03: [io 0xfe00] [ 1.746848] pnp 00:03: [io 0xff00] [ 1.757233] pnp 00:03: [mem 0xfec00000-0xfecfffff] [ 1.771513] pnp 00:03: [mem 0xfee00000-0xfeefffff] [ 1.785794] pnp 00:03: [mem 0xf8000000-0xfbffffff] [ 1.800072] pnp 00:03: [mem 0xfed19000-0xfed19fff] [ 1.814352] pnp 00:03: [mem 0xfed14000-0xfed17fff] [ 1.828634] pnp 00:03: [mem 0xfed18000-0xfed18fff] [ 1.842960] system 00:03: [io 0x04d0-0x04d1] has been reserved [ 1.860569] system 00:03: [io 0x1000-0x107f] has been reserved [ 1.878222] system 00:03: [io 0x1180-0x11bf] has been reserved [ 1.895878] system 00:03: [io 0x0500-0x057f] has been reserved [ 1.913532] system 00:03: [io 0x0800-0x080f] has been reserved [ 1.931186] system 00:03: [io 0x0810-0x081f] has been reserved [ 1.948840] system 00:03: [io 0xfe00] has been reserved [ 1.964675] system 00:03: [io 0xff00] has been reserved [ 1.980515] system 00:03: [mem 0xfec00000-0xfecfffff] could not be reserved [ 2.001285] system 00:03: [mem 0xfee00000-0xfeefffff] could not be reserved [ 2.022056] system 00:03: [mem 0xf8000000-0xfbffffff] has been reserved [ 2.041787] system 00:03: [mem 0xfed19000-0xfed19fff] has been reserved [ 2.061516] system 00:03: [mem 0xfed14000-0xfed17fff] has been reserved [ 2.081248] system 00:03: [mem 0xfed18000-0xfed18fff] has been reserved [ 2.101019] system 00:03: Plug and Play ACPI device, IDs PNP0c02 (active) [ 2.121277] pnp 00:04: [io 0x0000-0x000f] [ 2.133466] pnp 00:04: [io 0x0080-0x008f] [ 2.145666] pnp 00:04: [io 0x00c0-0x00df] [ 2.157869] pnp 00:04: [dma 4] [ 2.166973] pnp 00:04: Plug and Play ACPI device, IDs PNP0200 (active) [ 2.186441] pnp 00:05: [io 0x0070-0x0071] [ 2.198636] pnp 00:05: [irq 8] [ 2.207732] pnp 00:05: Plug and Play ACPI device, IDs PNP0b00 (active) [ 2.227203] pnp 00:06: [io 0x00f0-0x00fe] [ 2.239395] pnp 00:06: [irq 13] [ 2.248755] pnp 00:06: Plug and Play ACPI device, IDs PNP0c04 (active) [ 2.268220] pnp 00:07: [io 0x0061] [ 2.278612] pnp 00:07: Plug and Play ACPI device, IDs PNP0800 (active) [ 2.298162] pnp 00:08: [mem 0xfed00000-0xfed003ff] [ 2.312369] pnp 00:08: Plug and Play ACPI device, IDs PNP0103 (active) [ 2.331849] pnp 00:09: [io 0x0060] [ 2.342200] pnp 00:09: [io 0x0064] [ 2.352585] pnp 00:09: [irq 1] [ 2.361692] pnp 00:09: Plug and Play ACPI device, IDs PNP0303 (active) [ 2.381218] pnp 00:0a: [irq 12] [ 2.390512] pnp 00:0a: Plug and Play ACPI device, IDs PNP0f13 (active) [ 2.410277] pnp 00:0b: [io 0x03f8-0x03ff] [ 2.422168] pnp 00:0b: [irq 4] [ 2.431281] pnp 00:0b: Plug and Play ACPI device, IDs PNP0501 (active) [ 2.450767] pnp: PnP ACPI: found 12 devices [ 2.463184] ACPI: ACPI bus type pnp unregistered [ 2.478949] pci 0000:00:1c.0: bridge window [io 0x1000-0x0fff] to [bus 01] add_size 1000 [ 2.502989] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 01] add_size 200000 [ 2.532849] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff] to [bus 01] add_size 200000 [ 2.559859] pci 0000:00:1c.4: bridge window [io 0x1000-0x0fff] to [bus 02] add_size 1000 [ 2.584250] pci 0000:00:1c.4: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 02] add_size 200000 [ 2.614109] pci 0000:00:1c.4: bridge window [mem 0x00100000-0x000fffff] to [bus 02] add_size 200000 [ 2.641125] pci 0000:00:1c.0: res[14]=[mem 0x00100000-0x000fffff] get_res_add_size add_size 200000 [ 2.667848] pci 0000:00:1c.0: res[15]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000 [ 2.697447] pci 0000:00:1c.4: res[14]=[mem 0x00100000-0x000fffff] get_res_add_size add_size 200000 [ 2.724186] pci 0000:00:1c.4: res[15]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000 [ 2.753784] pci 0000:00:1c.0: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 [ 2.777926] pci 0000:00:1c.4: res[13]=[io 0x1000-0x0fff] get_res_add_size add_size 1000 [ 2.802074] pci 0000:00:1c.0: BAR 14: assigned [mem 0xf0000000-0xf01fffff] [ 2.822552] pci 0000:00:1c.0: BAR 15: assigned [mem 0xf0200000-0xf03fffff 64bit pref] [ 2.845948] pci 0000:00:1c.4: BAR 14: assigned [mem 0xf0400000-0xf05fffff] [ 2.866428] pci 0000:00:1c.4: BAR 15: assigned [mem 0xf0600000-0xf07fffff 64bit pref] [ 2.889825] pci 0000:00:1c.0: BAR 13: assigned [io 0x2000-0x2fff] [ 2.908226] pci 0000:00:1c.4: BAR 13: assigned [io 0x3000-0x3fff] [ 2.926658] pci 0000:00:1c.0: PCI bridge to [bus 01] [ 2.941457] pci 0000:00:1c.0: bridge window [io 0x2000-0x2fff] [ 2.959637] pci 0000:00:1c.0: bridge window [mem 0xf0000000-0xf01fffff] [ 2.979885] pci 0000:00:1c.0: bridge window [mem 0xf0200000-0xf03fffff 64bit pref] [ 3.003027] pci 0000:00:1c.4: PCI bridge to [bus 02] [ 3.017784] pci 0000:00:1c.4: bridge window [io 0x3000-0x3fff] [ 3.035965] pci 0000:00:1c.4: bridge window [mem 0xf0400000-0xf05fffff] [ 3.056215] pci 0000:00:1c.4: bridge window [mem 0xf0600000-0xf07fffff 64bit pref] [ 3.079353] pci 0000:00:1e.0: PCI bridge to [bus 03] [ 3.094135] pci 0000:00:1c.0: enabling device (0000 -> 0003) [ 3.111050] pci 0000:00:1c.4: enabling device (0000 -> 0003) [ 3.127918] pci 0000:00:1e.0: setting latency timer to 64 [ 3.144000] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7] [ 3.160612] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff] [ 3.177228] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff] [ 3.195922] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000d3fff] [ 3.214616] pci_bus 0000:00: resource 8 [mem 0x000d4000-0x000d7fff] [ 3.233308] pci_bus 0000:00: resource 9 [mem 0x000d8000-0x000dbfff] [ 3.252001] pci_bus 0000:00: resource 10 [mem 0x000dc000-0x000dffff] [ 3.270954] pci_bus 0000:00: resource 11 [mem 0x000e0000-0x000e3fff] [ 3.289906] pci_bus 0000:00: resource 12 [mem 0xe0000000-0xf7ffffff] [ 3.308857] pci_bus 0000:00: resource 13 [mem 0xfc000000-0xfebfffff] [ 3.327812] pci_bus 0000:00: resource 14 [mem 0xfed00000-0xfedfffff] [ 3.346764] pci_bus 0000:00: resource 15 [mem 0xfef00000-0xffafffff] [ 3.365716] pci_bus 0000:00: resource 16 [mem 0xffc00000-0xffefffff] [ 3.384667] pci_bus 0000:01: resource 0 [io 0x2000-0x2fff] [ 3.401281] pci_bus 0000:01: resource 1 [mem 0xf0000000-0xf01fffff] [ 3.419976] pci_bus 0000:01: resource 2 [mem 0xf0200000-0xf03fffff 64bit pref] [ 3.441554] pci_bus 0000:02: resource 0 [io 0x3000-0x3fff] [ 3.458138] pci_bus 0000:02: resource 1 [mem 0xf0400000-0xf05fffff] [ 3.476833] pci_bus 0000:02: resource 2 [mem 0xf0600000-0xf07fffff 64bit pref] [ 3.498409] pci_bus 0000:03: resource 4 [io 0x0000-0x0cf7] [ 3.514996] pci_bus 0000:03: resource 5 [io 0x0d00-0xffff] [ 3.531611] pci_bus 0000:03: resource 6 [mem 0x000a0000-0x000bffff] [ 3.550306] pci_bus 0000:03: resource 7 [mem 0x000d0000-0x000d3fff] [ 3.568996] pci_bus 0000:03: resource 8 [mem 0x000d4000-0x000d7fff] [ 3.587691] pci_bus 0000:03: resource 9 [mem 0x000d8000-0x000dbfff] [ 3.606382] pci_bus 0000:03: resource 10 [mem 0x000dc000-0x000dffff] [ 3.625337] pci_bus 0000:03: resource 11 [mem 0x000e0000-0x000e3fff] [ 3.644289] pci_bus 0000:03: resource 12 [mem 0xe0000000-0xf7ffffff] [ 3.663242] pci_bus 0000:03: resource 13 [mem 0xfc000000-0xfebfffff] [ 3.682192] pci_bus 0000:03: resource 14 [mem 0xfed00000-0xfedfffff] [ 3.701146] pci_bus 0000:03: resource 15 [mem 0xfef00000-0xffafffff] [ 3.720097] pci_bus 0000:03: resource 16 [mem 0xffc00000-0xffefffff] [ 3.739086] NET: Registered protocol family 2 [ 3.752154] TCP established hash table entries: 262144 (order: 10, 4194304 bytes) [ 3.775514] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [ 3.795466] TCP: Hash tables configured (established 262144 bind 65536) [ 3.814880] TCP: reno registered [ 3.824440] UDP hash table entries: 2048 (order: 5, 131072 bytes) [ 3.842658] UDP-Lite hash table entries: 2048 (order: 5, 131072 bytes) [ 3.862198] NET: Registered protocol family 1 [ 3.875098] pci 0000:00:02.0: Boot video device [ 3.889100] PCI: CLS 32 bytes, default 64 [ 3.900690] Unpacking initramfs... [ 3.962350] Freeing initrd memory: 65588k freed [ 3.995350] Simple Boot Flag at 0x44 set to 0x1 [ 4.008660] audit: initializing netlink socket (disabled) [ 4.024574] type=2000 audit(1368605545.024:1): initialized [ 4.067933] VFS: Disk quotas dquot_6.5.2 [ 4.079235] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 4.098568] msgmni has been set to 7227 [ 4.110105] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) [ 4.132021] io scheduler noop registered [ 4.143638] io scheduler deadline registered [ 4.156366] io scheduler cfq registered (default) [ 4.170551] pcieport 0000:00:1c.0: irq 43 (279) for MSI/MSI-X [ 4.187696] pcieport 0000:00:1c.4: irq 44 (278) for MSI/MSI-X [ 4.204850] GHES: HEST is not enabled! [ 4.215877] Non-volatile memory driver v1.3 [ 4.228276] Linux agpgart interface v0.103 [ 4.240550] agpgart-intel 0000:00:00.0: Intel Q45/Q43 Chipset [ 4.257686] agpgart-intel 0000:00:00.0: detected gtt size: 2097152K total, 262144K mappable [ 4.283885] agpgart-intel 0000:00:00.0: detected 65536K stolen memory [ 4.302820] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xe0000000 [ 4.323055] Xen virtual console successfully installed as ttyS0 [ 4.340692] libphy: Fixed MDIO Bus: probed [ 4.352837] i8042: PNP: PS/2 Controller [PNP0303:KEYB,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 [ 4.380857] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 4.395261] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 4.410404] mousedev: PS/2 mouse device common for all mice [ 4.427011] rtc_cmos 00:05: RTC can wake from S4 [ 4.440834] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0 [ 4.446075] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0 [ 4.484636] rtc0: alarms up to one month, y3k, 114 bytes nvram [ 4.501975] ledtrig-cpu: registered to indicate activity on CPUs [ 4.519874] EFI Variables Facility v0.08 2004-May-17 [ 4.534764] TCP: cubic registered [ 4.544554] NET: Registered protocol family 10 [ 4.557910] Key type dns_resolver registered [ 4.570565] MCE: bind virq for DOM0 logging [ 4.582973] MCE_DOM0_LOG: enter dom0 mce vIRQ handler [ 4.598018] MCE_DOM0_LOG: No more urgent data [ 4.610998] MCE_DOM0_LOG: No more nonurgent data [ 4.624879] registered taskstats version 1 [ 4.637393] Magic number: 13:135:220 [ 4.648198] dmi id: hash matches [ 4.657792] rtc_cmos 00:05: setting system clock to 2013-05-15 08:12:30 UTC (1368605550) [ 4.682117] Freeing unused kernel memory: 432k freed [ 4.696859] Write protecting the kernel read-only data: 8688k doing fast boot [ 4.765829] ata_generic 0000:00:03.2: setting latency timer to 64 [ 4.783815] scsi0 : ata_generic [ 4.793010] scsi1 : ata_generic [ 4.802323] ata1: PATA max UDMA/100 cmd 0x1c88 ctl 0x1c7c bmdma 0x1c20 irq 18 [ 4.823588] ata2: PATA max UDMA/100 cmd 0x1c80 ctl 0x1c78 bmdma 0x1c28 irq 18 FATAL: Module ide_pci_generic not found. FATAL: Module jbd not found. FATAL: Module ext3 not found. [ 5.217820] netfront: Initialising virtual ethernet driver. preping 03-rtc.sh preping 03-scsi_dh.sh running 03-scsi_dh.sh [ 5.258936] emc: device handler registered [ 5.272801] rdac: device handler registered [ 5.286928] alua: device handler registered [ 5.301661] hp_sw: device handler registered preping 03-storage.sh running 03-storage.sh preping 04-udev.sh running 04-udev.sh Creating device nodes with udev [ 5.352712] systemd-udevd[104]: starting version 195 [ 5.386452] ACPI: bus type usb registered [ 5.398051] usbcore: registered new interface driver usbfs [ 5.414371] usbcore: registered new interface driver hub [ 5.432100] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1 [ 5.461873] usbcore: registered new device driver usb [ 5.477573] ACPI: Power Button [PWRB] [ 5.488162] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 [ 5.521061] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 5.540231] ehci_hcd 0000:00:1a.7: setting latency timer to 64 [ 5.557546] ehci_hcd 0000:00:1a.7: EHCI Host Controller [ 5.573119] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1 [ 5.595234] ehci_hcd 0000:00:1a.7: debug port 1 [ 5.611171] ACPI: Power Button [PWRF] [ 5.612615] ehci_hcd 0000:00:1a.7: cache line size of 32 is not supported [ 5.612623] ehci_hcd 0000:00:1a.7: irq 18, io mem 0xfc528000 [ 5.670207] [drm] Initialized drm 1.1.0 20060810 [ 5.721091] input: ImPS/2 Logitech Wheel Mouse as /devices/platform/i8042/serio1/input/input3 [ 5.749989] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00 [ 5.766754] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 5.786981] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 5.808562] usb usb1: Product: EHCI Host Controller [ 5.823066] usb usb1: Manufacturer: Linux 3.7.10-1.4-xen ehci_hcd [ 5.841239] usb usb1: SerialNumber: 0000:00:1a.7 [ 5.855163] hub 1-0:1.0: USB hub found [ 5.866164] hub 1-0:1.0: 6 ports detected [ 5.878229] ehci_hcd 0000:00:1d.7: setting latency timer to 64 [ 5.895502] ehci_hcd 0000:00:1d.7: EHCI Host Controller [ 5.911077] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2 [ 5.933192] ehci_hcd 0000:00:1d.7: debug port 1 [ 5.950554] ehci_hcd 0000:00:1d.7: cache line size of 32 is not supported [ 5.970431] ehci_hcd 0000:00:1d.7: irq 20, io mem 0xfc529000 [ 5.996064] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00 [ 6.012810] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [ 6.033054] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 6.054627] usb usb2: Product: EHCI Host Controller [ 6.069136] usb usb2: Manufacturer: Linux 3.7.10-1.4-xen ehci_hcd [ 6.087312] usb usb2: SerialNumber: 0000:00:1d.7 [ 6.101180] hub 2-0:1.0: USB hub found [ 6.112236] hub 2-0:1.0: 6 ports detected [ 6.124510] [drm:i915_dump_device_info], i915 device info: gen=4, pciid=0x2e12 flags=need_gfx_hws,is_g4x,has_pipe_cxsr,has_hotplug,has_bsd_ring, [ 6.162393] i915 0000:00:02.0: setting latency timer to 64 [ 6.181013] uhci_hcd: USB Universal Host Controller Interface driver [ 6.214757] [drm:intel_opregion_setup], graphic opregion physical addr: 0xdb7b1db8 [ 6.236987] [drm:intel_opregion_setup], SWSCI supported [ 6.252562] i915 0000:00:02.0: irq 47 (277) for MSI/MSI-X [ 6.268630] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 6.288354] [drm] Driver supports precise vblank timestamp query. [ 6.306526] [drm:init_vbt_defaults], Set default to SSC at 100MHz [ 6.324692] [drm:intel_parse_bios], Using VBT from OpRegion: $VBT EAGLELAKE d [ 6.347312] [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.387566] [drm:parse_general_definitions], crt_ddc_bus_pin: 2 [ 6.405184] [drm:parse_sdvo_panel_data], Found SDVO panel mode in BIOS VBT tables: [ 6.427792] [drm:drm_mode_debug_printmodeline], Modeline 0:"1600x1200" 0 162000 1600 1664 1856 2160 1200 1201 1204 1250 0x8 0xa [ 6.462074] [drm:parse_sdvo_device_mapping], No SDVO device info is found in VBT [ 6.484145] [drm:intel_dsm_pci_probe], no _DSM method for intel device [ 6.503584] [drm:intel_modeset_init], 2 display pipes available. [ 6.521486] [drm:intel_modeset_init], plane 0 init failed: -19 [ 6.538879] [drm:intel_modeset_init], plane 1 init failed: -19 [ 6.556272] [drm:intel_pch_pll_init], No PCH PLLs on this hardware, skipping initialisation [ 6.581233] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 6.610131] [drm:intel_setup_outputs], probing SDVOB [ 6.624819] [drm:intel_sdvo_read_byte], i2c transfer returned -6 [ 6.642466] [drm:intel_sdvo_init], No SDVO device found on SDVOB [ 6.660397] [drm:intel_setup_outputs], probing HDMI on SDVOB [ 6.677274] [drm:intel_setup_outputs], probing DP_B [ 6.691809] [drm:intel_dp_i2c_init], i2c_init DPDDC-B [ 6.709873] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8 [ 6.728937] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 6.748054] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x514500c8 [ 6.767120] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110 [ 6.783230] [drm:intel_setup_outputs], probing SDVOC [ 6.798277] [drm:intel_sdvo_read_byte], i2c transfer returned -6 [ 6.815927] [drm:intel_sdvo_init], No SDVO device found on SDVOC -- Company details: http://ts.fujitsu.com/imprint.html ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-15 6:53 ` Dietmar Hahn @ 2013-05-15 8:35 ` Jan Beulich 2013-05-15 9:12 ` Dietmar Hahn 0 siblings, 1 reply; 23+ messages in thread From: Jan Beulich @ 2013-05-15 8:35 UTC (permalink / raw) To: Dietmar Hahn; +Cc: Andrew Cooper, Konrad Rzeszutek Wilk, xen-devel >>> On 15.05.13 at 08:53, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > I tried iommu=debug and I can't see any faulting messages but Iam not > familiar with this code. > I attached the logging, maybe anyone can have a look on this. Indeed, there are no faults being logged. Following the comment yesterday - any chance you could try a recent master branch kernel? Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-15 8:35 ` Jan Beulich @ 2013-05-15 9:12 ` Dietmar Hahn 2013-05-15 9:42 ` Jan Beulich 0 siblings, 1 reply; 23+ messages in thread From: Dietmar Hahn @ 2013-05-15 9:12 UTC (permalink / raw) To: xen-devel; +Cc: Andrew Cooper, Jan Beulich, Konrad Rzeszutek Wilk Am Mittwoch 15 Mai 2013, 09:35:46 schrieb Jan Beulich: > >>> On 15.05.13 at 08:53, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > > I tried iommu=debug and I can't see any faulting messages but Iam not > > familiar with this code. > > I attached the logging, maybe anyone can have a look on this. > > Indeed, there are no faults being logged. > > Following the comment yesterday - any chance you could try a > recent master branch kernel? Sure I can do this, send me a link and I'll try this one. The other thing is that the hypervisor doesn't respond to key pressing on the serial line. This should always be working, shouldn't it? So I need some ideas how I can persuade the hypervisor to print a stack trace in this situation. Dietmar. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-15 9:12 ` Dietmar Hahn @ 2013-05-15 9:42 ` Jan Beulich 2013-05-16 11:07 ` Dietmar Hahn 0 siblings, 1 reply; 23+ messages in thread From: Jan Beulich @ 2013-05-15 9:42 UTC (permalink / raw) To: Dietmar Hahn; +Cc: Andrew Cooper, Konrad Rzeszutek Wilk, xen-devel >>> On 15.05.13 at 11:12, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > Am Mittwoch 15 Mai 2013, 09:35:46 schrieb Jan Beulich: >> >>> On 15.05.13 at 08:53, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: >> > I tried iommu=debug and I can't see any faulting messages but Iam not >> > familiar with this code. >> > I attached the logging, maybe anyone can have a look on this. >> >> Indeed, there are no faults being logged. >> >> Following the comment yesterday - any chance you could try a >> recent master branch kernel? > > Sure I can do this, send me a link and I'll try this one. http://download.opensuse.org/repositories/Kernel:/HEAD/standard/x86_64/ > The other thing is that the hypervisor doesn't respond to key pressing on > the > serial line. This should always be working, shouldn't it? As long as it's alive, it should. > So I need some ideas how I can persuade the hypervisor to print a stack > trace > in this situation. Perhaps only (if at all) by instrumenting the hypervisor. The question of course is how easily/quickly you can narrow down the code region that it might be dying in. And whether it's a hypervisor action at all that causes the hang (as opposed to something the DRM code in Dom0 does). Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-15 9:42 ` Jan Beulich @ 2013-05-16 11:07 ` Dietmar Hahn 2013-05-16 12:10 ` Jan Beulich 2013-05-17 22:28 ` Konrad Rzeszutek Wilk 0 siblings, 2 replies; 23+ messages in thread From: Dietmar Hahn @ 2013-05-16 11:07 UTC (permalink / raw) To: xen-devel; +Cc: Andrew Cooper, Jan Beulich, Konrad Rzeszutek Wilk Am Mittwoch 15 Mai 2013, 10:42:17 schrieb Jan Beulich: > >>> On 15.05.13 at 11:12, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > > Am Mittwoch 15 Mai 2013, 09:35:46 schrieb Jan Beulich: > >> >>> On 15.05.13 at 08:53, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > >> > I tried iommu=debug and I can't see any faulting messages but Iam not > >> > familiar with this code. > >> > I attached the logging, maybe anyone can have a look on this. > > Perhaps only (if at all) by instrumenting the hypervisor. The > question of course is how easily/quickly you can narrow down the > code region that it might be dying in. And whether it's a hypervisor > action at all that causes the hang (as opposed to something the > DRM code in Dom0 does). I added some debug code to the linux kernel and could track down the point of the hang. I used openSuSE kernel 3.7.10-1.4 but I looked at newer kernels and found that the code is similar. i915_gem_init_global_gtt(...) ... intel_gtt_clear_range(start / PAGE_SIZE, (end-start) / PAGE_SIZE); ... void intel_gtt_clear_range(unsigned int first_entry, unsigned int num_entries) { unsigned int i; ---> A printk(...) here is seen on serial line! for (i = first_entry; i < (first_entry + num_entries); i++) { intel_private.driver->write_entry(intel_private.base.scratch_page_dma, i, 0); } ---> A printk(...) here is never seen! readl(intel_private.gtt+i-1); } The function behind the pointer intel_private.driver->write_entry is i965_write_entry(). And the interesting instruction seems to be: writel(addr | pte_flags, intel_private.gtt + entry); I added another printk() on start of the function i965_write_entry(). And surprisingly after printing a lot of messages the kernel came up!!! But now I had other problems like losing the audio device (maybe timeouts). So maybe the hang is a timing problem? What I wanted to check is, what the hypervisor is doing while the system hangs. Has anybody an idea maybe a timer and after 30s printing a dump of the stack of all cpus? Thanks. Dietmar. -- Company details: http://ts.fujitsu.com/imprint.html ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-16 11:07 ` Dietmar Hahn @ 2013-05-16 12:10 ` Jan Beulich 2013-05-16 13:16 ` Dietmar Hahn ` (2 more replies) 2013-05-17 22:28 ` Konrad Rzeszutek Wilk 1 sibling, 3 replies; 23+ messages in thread From: Jan Beulich @ 2013-05-16 12:10 UTC (permalink / raw) To: Donald D Dugger, Dietmar Hahn Cc: Andrew Cooper, Konrad Rzeszutek Wilk, xen-devel >>> On 16.05.13 at 13:07, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > The function behind the pointer intel_private.driver->write_entry is > i965_write_entry(). And the interesting instruction seems to be: > writel(addr | pte_flags, intel_private.gtt + entry); > > I added another printk() on start of the function i965_write_entry(). > And surprisingly after printing a lot of messages the kernel came up!!! > But now I had other problems like losing the audio device (maybe timeouts). > So maybe the hang is a timing problem? Apparently. As the caller is running this in a loop, did you check whether it's the first or always the same entry that it hangs on? > What I wanted to check is, what the hypervisor is doing while the system > hangs. Probably nothing in this case, as it doesn't get involved in the MMIO write being carried out. > Has anybody an idea maybe a timer and after 30s printing a dump of the stack > of all cpus? That would be the watchdog, which you said doesn't kick in either. I'm afraid this is a problem with the graphics device's processing of the written data (locking up the machine at the bus level). Without help from someone knowing what the driver is supposed to do here, and what therefore might be going wrong, I don't see good chances of making progress here. Don - any idea who that could be? Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-16 12:10 ` Jan Beulich @ 2013-05-16 13:16 ` Dietmar Hahn 2013-05-16 13:45 ` Jan Beulich 2013-05-16 14:50 ` Dugger, Donald D 2013-05-20 14:30 ` Dugger, Donald D 2 siblings, 1 reply; 23+ messages in thread From: Dietmar Hahn @ 2013-05-16 13:16 UTC (permalink / raw) To: xen-devel Cc: Andrew Cooper, Donald D Dugger, Jan Beulich, Konrad Rzeszutek Wilk Am Donnerstag 16 Mai 2013, 13:10:27 schrieb Jan Beulich: > >>> On 16.05.13 at 13:07, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > > The function behind the pointer intel_private.driver->write_entry is > > i965_write_entry(). And the interesting instruction seems to be: > > writel(addr | pte_flags, intel_private.gtt + entry); > > > > I added another printk() on start of the function i965_write_entry(). > > And surprisingly after printing a lot of messages the kernel came up!!! > > But now I had other problems like losing the audio device (maybe timeouts). > > So maybe the hang is a timing problem? > > Apparently. As the caller is running this in a loop, did you check > whether it's the first or always the same entry that it hangs on? I did a fast check, did the first entry and a printk() and than the loop with the other entries and the message after the first entry was printed on the serial log. > > What I wanted to check is, what the hypervisor is doing while the system > > hangs. > > Probably nothing in this case, as it doesn't get involved in the MMIO > write being carried out. > > > Has anybody an idea maybe a timer and after 30s printing a dump of the stack > > of all cpus? > > That would be the watchdog, which you said doesn't kick in either. Yes > I'm afraid this is a problem with the graphics device's processing of > the written data (locking up the machine at the bus level). Without > help from someone knowing what the driver is supposed to do here, > and what therefore might be going wrong, I don't see good chances > of making progress here. Don - any idea who that could be? I should mention that with openSuSE 12.2 and older all worked flawless. Dietmar. -- Company details: http://ts.fujitsu.com/imprint.html ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-16 13:16 ` Dietmar Hahn @ 2013-05-16 13:45 ` Jan Beulich 2013-05-17 7:10 ` Dietmar Hahn 0 siblings, 1 reply; 23+ messages in thread From: Jan Beulich @ 2013-05-16 13:45 UTC (permalink / raw) To: Dietmar Hahn Cc: Andrew Cooper, Konrad Rzeszutek Wilk, Donald D Dugger, xen-devel >>> On 16.05.13 at 15:16, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > Am Donnerstag 16 Mai 2013, 13:10:27 schrieb Jan Beulich: >> I'm afraid this is a problem with the graphics device's processing of >> the written data (locking up the machine at the bus level). Without >> help from someone knowing what the driver is supposed to do here, >> and what therefore might be going wrong, I don't see good chances >> of making progress here. Don - any idea who that could be? > > I should mention that with openSuSE 12.2 and older all worked flawless. I took this for given. But I'd expect the 12.2 kernel on the 12.3 hypervisor would work too (though worth a try to be certain), i.e. I rather expect the kernel side (AGP/DRM) changes to have introduced this (which doesn't imply the hypothetical fix necessarily to be to the kernel - that obviously depends on understanding what the problem is). Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-16 13:45 ` Jan Beulich @ 2013-05-17 7:10 ` Dietmar Hahn 0 siblings, 0 replies; 23+ messages in thread From: Dietmar Hahn @ 2013-05-17 7:10 UTC (permalink / raw) To: xen-devel Cc: Andrew Cooper, Donald D Dugger, Jan Beulich, Konrad Rzeszutek Wilk Am Donnerstag 16 Mai 2013, 14:45:00 schrieb Jan Beulich: > >>> On 16.05.13 at 15:16, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > > Am Donnerstag 16 Mai 2013, 13:10:27 schrieb Jan Beulich: > >> I'm afraid this is a problem with the graphics device's processing of > >> the written data (locking up the machine at the bus level). Without > >> help from someone knowing what the driver is supposed to do here, > >> and what therefore might be going wrong, I don't see good chances > >> of making progress here. Don - any idea who that could be? > > > > I should mention that with openSuSE 12.2 and older all worked flawless. > > I took this for given. But I'd expect the 12.2 kernel on the 12.3 > hypervisor would work too (though worth a try to be certain), i.e. > I rather expect the kernel side (AGP/DRM) changes to have > introduced this (which doesn't imply the hypothetical fix necessarily > to be to the kernel - that obviously depends on understanding what > the problem is). I tried openSuSE-12.2 kernel-xen-3.4.45-1.1.gba139d5.x86_64.rpm successfully. So you are right it seems to be the kernel side. Dietmar. -- Company details: http://ts.fujitsu.com/imprint.html ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-16 12:10 ` Jan Beulich 2013-05-16 13:16 ` Dietmar Hahn @ 2013-05-16 14:50 ` Dugger, Donald D 2013-05-20 14:30 ` Dugger, Donald D 2 siblings, 0 replies; 23+ messages in thread From: Dugger, Donald D @ 2013-05-16 14:50 UTC (permalink / raw) To: Jan Beulich, Dietmar Hahn; +Cc: Andrew Cooper, Konrad Rzeszutek Wilk, xen-devel Jan- We have people looking into graphics virtualization, let me ask and see if anyone can help out. -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786 -----Original Message----- From: Jan Beulich [mailto:JBeulich@suse.com] Sent: Thursday, May 16, 2013 6:10 AM To: Dugger, Donald D; Dietmar Hahn Cc: Andrew Cooper; xen-devel@lists.xen.org; Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] dom0 / hypervisor hang on dom0 boot >>> On 16.05.13 at 13:07, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > The function behind the pointer intel_private.driver->write_entry is > i965_write_entry(). And the interesting instruction seems to be: > writel(addr | pte_flags, intel_private.gtt + entry); > > I added another printk() on start of the function i965_write_entry(). > And surprisingly after printing a lot of messages the kernel came up!!! > But now I had other problems like losing the audio device (maybe timeouts). > So maybe the hang is a timing problem? Apparently. As the caller is running this in a loop, did you check whether it's the first or always the same entry that it hangs on? > What I wanted to check is, what the hypervisor is doing while the system > hangs. Probably nothing in this case, as it doesn't get involved in the MMIO write being carried out. > Has anybody an idea maybe a timer and after 30s printing a dump of the stack > of all cpus? That would be the watchdog, which you said doesn't kick in either. I'm afraid this is a problem with the graphics device's processing of the written data (locking up the machine at the bus level). Without help from someone knowing what the driver is supposed to do here, and what therefore might be going wrong, I don't see good chances of making progress here. Don - any idea who that could be? Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-16 12:10 ` Jan Beulich 2013-05-16 13:16 ` Dietmar Hahn 2013-05-16 14:50 ` Dugger, Donald D @ 2013-05-20 14:30 ` Dugger, Donald D 2013-05-21 8:03 ` Jan Beulich 2 siblings, 1 reply; 23+ messages in thread From: Dugger, Donald D @ 2013-05-20 14:30 UTC (permalink / raw) To: Jan Beulich, Dietmar Hahn Cc: Andrew Cooper, Tian, Kevin, Konrad Rzeszutek Wilk, xen-devel Jan- According to Kevin (our expert on Xen & graphics): Haven't seen that specific problem. The only trick for i915 in dom0, in my mind, is to have CONFIG_DMAR enabled in dom0 although dom0 is not actually exposed with a VT-d engine. This sets need_dmar flag in i915, ensures i915 to use Xen DMA interface instead of virt_to_phys, so that MFN is written to GTT entries. Otherwise, having GPFN in GTT entries is bogus, since GPU will DMA to wrong locations then, and thus cause random issues. Once we also identified a regression in 3.8, where need_dmar is not honored in i915 driver: commit 20652097dadd9a7fb4d652f25466299974bc78f9 Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Thu Dec 13 23:47:47 2012 +0800 drm/i915: Fix missed needs_dmar setting From Ben's AGP dependence removal change, "needs_dmar" flag has not been properly setup for new chips using new GTT init function. This one adds missed setting of that flag to make sure we do pci mappings with IOMMU enabled. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> So, I didn't see the exact same phenomenon, but GTT is always the 1st culprit to study when seeing such issue. -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786 -----Original Message----- From: Jan Beulich [mailto:JBeulich@suse.com] Sent: Thursday, May 16, 2013 6:10 AM To: Dugger, Donald D; Dietmar Hahn Cc: Andrew Cooper; xen-devel@lists.xen.org; Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] dom0 / hypervisor hang on dom0 boot >>> On 16.05.13 at 13:07, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > The function behind the pointer intel_private.driver->write_entry is > i965_write_entry(). And the interesting instruction seems to be: > writel(addr | pte_flags, intel_private.gtt + entry); > > I added another printk() on start of the function i965_write_entry(). > And surprisingly after printing a lot of messages the kernel came up!!! > But now I had other problems like losing the audio device (maybe timeouts). > So maybe the hang is a timing problem? Apparently. As the caller is running this in a loop, did you check whether it's the first or always the same entry that it hangs on? > What I wanted to check is, what the hypervisor is doing while the system > hangs. Probably nothing in this case, as it doesn't get involved in the MMIO write being carried out. > Has anybody an idea maybe a timer and after 30s printing a dump of the stack > of all cpus? That would be the watchdog, which you said doesn't kick in either. I'm afraid this is a problem with the graphics device's processing of the written data (locking up the machine at the bus level). Without help from someone knowing what the driver is supposed to do here, and what therefore might be going wrong, I don't see good chances of making progress here. Don - any idea who that could be? Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-20 14:30 ` Dugger, Donald D @ 2013-05-21 8:03 ` Jan Beulich 2013-05-21 8:28 ` Tian, Kevin 0 siblings, 1 reply; 23+ messages in thread From: Jan Beulich @ 2013-05-21 8:03 UTC (permalink / raw) To: Donald D Dugger, Kevin Tian Cc: Andrew Cooper, Konrad Rzeszutek Wilk, Dietmar Hahn, xen-devel >>> On 20.05.13 at 16:30, "Dugger, Donald D" <donald.d.dugger@intel.com> wrote: > The only trick for i915 in dom0, in my mind, is to have CONFIG_DMAR enabled in > dom0 although dom0 is not actually exposed with a VT-d engine. This sets need_dmar > flag in i915, ensures i915 to use Xen DMA interface instead of virt_to_phys, so that > MFN is written to GTT entries. Otherwise, having GPFN in GTT entries is bogus, since > GPU will DMA to wrong locations then, and thus cause random issues. Enabling CONFIG_DMAR (or really CONFIG_INTEL_IOMMU in recent kernels) is not an option. However, we patch all respective sites to also take effect on Xen (of course that doesn't help pv-ops, but here we're talking about a forward ported kernel anyway). > Once we also identified a regression in 3.8, where need_dmar is not honored in > i915 driver: Dietmar had already tested with 3.9, so this ought to not affect him. Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-21 8:03 ` Jan Beulich @ 2013-05-21 8:28 ` Tian, Kevin 2013-05-21 8:47 ` Jan Beulich 0 siblings, 1 reply; 23+ messages in thread From: Tian, Kevin @ 2013-05-21 8:28 UTC (permalink / raw) To: Jan Beulich, Dugger, Donald D Cc: Andrew Cooper, Konrad Rzeszutek Wilk, Dietmar Hahn, xen-devel > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Tuesday, May 21, 2013 4:04 PM > > >>> On 20.05.13 at 16:30, "Dugger, Donald D" <donald.d.dugger@intel.com> > wrote: > > The only trick for i915 in dom0, in my mind, is to have CONFIG_DMAR enabled > in > > dom0 although dom0 is not actually exposed with a VT-d engine. This sets > need_dmar > > flag in i915, ensures i915 to use Xen DMA interface instead of virt_to_phys, > so that > > MFN is written to GTT entries. Otherwise, having GPFN in GTT entries is > bogus, since > > GPU will DMA to wrong locations then, and thus cause random issues. > > Enabling CONFIG_DMAR (or really CONFIG_INTEL_IOMMU in recent > kernels) is not an option. However, we patch all respective sites to > also take effect on Xen (of course that doesn't help pv-ops, but here > we're talking about a forward ported kernel anyway). could you elaborate why CONFIG_DMAR is not an option? we still use it at least on 3.8 series kernel. if you have already patched all the address translation codes in i915 driver, i.e. where need_dmar is checked, yes this looks not a reason. > > > Once we also identified a regression in 3.8, where need_dmar is not honored > in > > i915 driver: > > Dietmar had already tested with 3.9, so this ought to not affect > him. > no much idea then. For random issues with Intel gfx card in a virtualization world, normally GTT is the most likely problem, and then comes the cache attributes of i915 buffer objects. However I don't remember any recent issue related to cache side... Thanks Kevin ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-21 8:28 ` Tian, Kevin @ 2013-05-21 8:47 ` Jan Beulich 0 siblings, 0 replies; 23+ messages in thread From: Jan Beulich @ 2013-05-21 8:47 UTC (permalink / raw) To: Donald D Dugger, Kevin Tian Cc: Andrew Cooper, Konrad Rzeszutek Wilk, Dietmar Hahn, xen-devel >>> On 21.05.13 at 10:28, "Tian, Kevin" <kevin.tian@intel.com> wrote: >> From: Jan Beulich [mailto:JBeulich@suse.com] >> Sent: Tuesday, May 21, 2013 4:04 PM >> >> >>> On 20.05.13 at 16:30, "Dugger, Donald D" <donald.d.dugger@intel.com> >> wrote: >> > The only trick for i915 in dom0, in my mind, is to have CONFIG_DMAR enabled >> in >> > dom0 although dom0 is not actually exposed with a VT-d engine. This sets >> need_dmar >> > flag in i915, ensures i915 to use Xen DMA interface instead of > virt_to_phys, >> so that >> > MFN is written to GTT entries. Otherwise, having GPFN in GTT entries is >> bogus, since >> > GPU will DMA to wrong locations then, and thus cause random issues. >> >> Enabling CONFIG_DMAR (or really CONFIG_INTEL_IOMMU in recent >> kernels) is not an option. However, we patch all respective sites to >> also take effect on Xen (of course that doesn't help pv-ops, but here >> we're talking about a forward ported kernel anyway). > > could you elaborate why CONFIG_DMAR is not an option? we still use it at > least on 3.8 series kernel. Because this enables a bunch of dead code that in our Xen kernel we want to be sure is dead (i.e. not becoming reachable all of the sudden by some code path added without us noticing). Consequently INTEL_IOMMU depends on !XEN, and there's no intention to change this. > if you have already patched all the address translation codes in i915 > driver, i.e. > where need_dmar is checked, yes this looks not a reason. All the places under drivers/char/agp/ and drivers/gpu/drm/i915/ that reference CONFIG_INTEL_IOMMU, and the declaration of intel_iommu_gfx_mapped is a #define to 1 under CONFIG_XEN. Jan ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-16 11:07 ` Dietmar Hahn 2013-05-16 12:10 ` Jan Beulich @ 2013-05-17 22:28 ` Konrad Rzeszutek Wilk 2013-05-21 7:39 ` Dietmar Hahn 1 sibling, 1 reply; 23+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-05-17 22:28 UTC (permalink / raw) To: Dietmar Hahn; +Cc: Andrew Cooper, Konrad Rzeszutek Wilk, Jan Beulich, xen-devel [-- Attachment #1: Type: text/plain, Size: 2581 bytes --] On Thu, May 16, 2013 at 01:07:05PM +0200, Dietmar Hahn wrote: > Am Mittwoch 15 Mai 2013, 10:42:17 schrieb Jan Beulich: > > >>> On 15.05.13 at 11:12, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > > > Am Mittwoch 15 Mai 2013, 09:35:46 schrieb Jan Beulich: > > >> >>> On 15.05.13 at 08:53, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > > >> > I tried iommu=debug and I can't see any faulting messages but Iam not > > >> > familiar with this code. > > >> > I attached the logging, maybe anyone can have a look on this. > > > > Perhaps only (if at all) by instrumenting the hypervisor. The > > question of course is how easily/quickly you can narrow down the > > code region that it might be dying in. And whether it's a hypervisor > > action at all that causes the hang (as opposed to something the > > DRM code in Dom0 does). > > I added some debug code to the linux kernel and could track down the > point of the hang. I used openSuSE kernel 3.7.10-1.4 but I looked at newer > kernels and found that the code is similar. > > i915_gem_init_global_gtt(...) > ... > intel_gtt_clear_range(start / PAGE_SIZE, (end-start) / PAGE_SIZE); > ... > > void intel_gtt_clear_range(unsigned int first_entry, unsigned int num_entries) > { > unsigned int i; > > ---> A printk(...) here is seen on serial line! > > for (i = first_entry; i < (first_entry + num_entries); i++) { > intel_private.driver->write_entry(intel_private.base.scratch_page_dma, > i, 0); > } > > ---> A printk(...) here is never seen! > > readl(intel_private.gtt+i-1); > } > > The function behind the pointer intel_private.driver->write_entry is > i965_write_entry(). And the interesting instruction seems to be: > writel(addr | pte_flags, intel_private.gtt + entry); > > I added another printk() on start of the function i965_write_entry(). > And surprisingly after printing a lot of messages the kernel came up!!! > But now I had other problems like losing the audio device (maybe timeouts). > So maybe the hang is a timing problem? > > What I wanted to check is, what the hypervisor is doing while the system hangs. > Has anybody an idea maybe a timer and after 30s printing a dump of the stack of > all cpus? Yes. Can you try the two attached patches please. > Thanks. > > Dietmar. > > > -- > Company details: http://ts.fujitsu.com/imprint.html > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel > [-- Attachment #2: 0001-drm-i915-Don-t-leak-a-page-in-case-of-DMA-error-mapp.patch --] [-- Type: text/plain, Size: 1947 bytes --] >From 4201962b743a44325ff848ba6387d3710343c123 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Fri, 17 May 2013 18:13:35 -0400 Subject: [PATCH 1/2] drm/i915: Don't leak a page in case of DMA error mapping. We don't free the allocated page if we fail to setup the DMA mapping. This fixes it. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/char/agp/intel-gtt.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c index dbd901e..701b328 100644 --- a/drivers/char/agp/intel-gtt.c +++ b/drivers/char/agp/intel-gtt.c @@ -294,9 +294,10 @@ static int intel_gtt_setup_scratch_page(void) if (intel_private.base.needs_dmar) { dma_addr = pci_map_page(intel_private.pcidev, page, 0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL); - if (pci_dma_mapping_error(intel_private.pcidev, dma_addr)) + if (pci_dma_mapping_error(intel_private.pcidev, dma_addr)) { + __intel_gtt_teardown_scratch_page(); return -EINVAL; - + } intel_private.base.scratch_page_dma = dma_addr; } else intel_private.base.scratch_page_dma = page_to_phys(page); @@ -542,15 +543,18 @@ static unsigned int intel_gtt_mappable_entries(void) return aperture_size >> PAGE_SHIFT; } - -static void intel_gtt_teardown_scratch_page(void) +static void __intel_gtt_teardown_scratch_page(void) { set_pages_wb(intel_private.scratch_page, 1); - pci_unmap_page(intel_private.pcidev, intel_private.base.scratch_page_dma, - PAGE_SIZE, PCI_DMA_BIDIRECTIONAL); put_page(intel_private.scratch_page); __free_page(intel_private.scratch_page); } +static void intel_gtt_teardown_scratch_page(void) +{ + pci_unmap_page(intel_private.pcidev, intel_private.base.scratch_page_dma, + PAGE_SIZE, PCI_DMA_BIDIRECTIONAL); + __intel_gtt_teardown_scratch_page(); +} static void intel_gtt_cleanup(void) { -- 1.8.1.2 [-- Attachment #3: 0002-drm-i915-Sync-the-scratch-page-after-writting-values.patch --] [-- Type: text/plain, Size: 1221 bytes --] >From 51908f611fb00195d98f1a552106c6d1709720c0 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Fri, 17 May 2013 18:20:46 -0400 Subject: [PATCH 2/2] drm/i915: Sync the scratch page after writting values to it. We don't sync the page after we have written to it - this is what you are suppose to when doing: pci_map_page .. write some values [ was missing a call to pci_dma_sync_single_for_device] .. read some values pci_unmap_page Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> --- drivers/char/agp/intel-gtt.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c index 701b328..89dd698 100644 --- a/drivers/char/agp/intel-gtt.c +++ b/drivers/char/agp/intel-gtt.c @@ -902,6 +902,9 @@ void intel_gtt_clear_range(unsigned int first_entry, unsigned int num_entries) intel_private.driver->write_entry(intel_private.base.scratch_page_dma, i, 0); } + pci_dma_sync_single_for_device(intel_private.pcidev, + intel_private.base.scratch_page_dma, + PAGE_SIZE, PCI_DMA_BIDIRECTIONAL); readl(intel_private.gtt+i-1); } EXPORT_SYMBOL(intel_gtt_clear_range); -- 1.8.1.2 [-- Attachment #4: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-17 22:28 ` Konrad Rzeszutek Wilk @ 2013-05-21 7:39 ` Dietmar Hahn 2013-05-21 14:10 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 23+ messages in thread From: Dietmar Hahn @ 2013-05-21 7:39 UTC (permalink / raw) To: xen-devel Cc: Konrad Rzeszutek Wilk, Konrad Rzeszutek Wilk, Jan Beulich, Andrew Cooper [-- Attachment #1.1: Type: text/plain, Size: 2793 bytes --] Am Freitag 17 Mai 2013, 18:28:16 schrieb Konrad Rzeszutek Wilk: > On Thu, May 16, 2013 at 01:07:05PM +0200, Dietmar Hahn wrote: > > Am Mittwoch 15 Mai 2013, 10:42:17 schrieb Jan Beulich: > > > >>> On 15.05.13 at 11:12, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > > > > Am Mittwoch 15 Mai 2013, 09:35:46 schrieb Jan Beulich: > > > >> >>> On 15.05.13 at 08:53, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > > > >> > I tried iommu=debug and I can't see any faulting messages but Iam not > > > >> > familiar with this code. > > > >> > I attached the logging, maybe anyone can have a look on this. > > > > > > Perhaps only (if at all) by instrumenting the hypervisor. The > > > question of course is how easily/quickly you can narrow down the > > > code region that it might be dying in. And whether it's a hypervisor > > > action at all that causes the hang (as opposed to something the > > > DRM code in Dom0 does). > > > > I added some debug code to the linux kernel and could track down the > > point of the hang. I used openSuSE kernel 3.7.10-1.4 but I looked at newer > > kernels and found that the code is similar. > > > > i915_gem_init_global_gtt(...) > > ... > > intel_gtt_clear_range(start / PAGE_SIZE, (end-start) / PAGE_SIZE); > > ... > > > > void intel_gtt_clear_range(unsigned int first_entry, unsigned int num_entries) > > { > > unsigned int i; > > > > ---> A printk(...) here is seen on serial line! > > > > for (i = first_entry; i < (first_entry + num_entries); i++) { > > intel_private.driver->write_entry(intel_private.base.scratch_page_dma, > > i, 0); > > } > > > > ---> A printk(...) here is never seen! > > > > readl(intel_private.gtt+i-1); > > } > > > > The function behind the pointer intel_private.driver->write_entry is > > i965_write_entry(). And the interesting instruction seems to be: > > writel(addr | pte_flags, intel_private.gtt + entry); > > > > I added another printk() on start of the function i965_write_entry(). > > And surprisingly after printing a lot of messages the kernel came up!!! > > But now I had other problems like losing the audio device (maybe timeouts). > > So maybe the hang is a timing problem? > > > > What I wanted to check is, what the hypervisor is doing while the system hangs. > > Has anybody an idea maybe a timer and after 30s printing a dump of the stack of > > all cpus? > > Yes. Can you try the two attached patches please. I tried both but none helped. I think it couldn't be expected as the first patch handles an error case and the line with the second patch, the call of pci_dma_sync_single_for_device(), gets not reached. Dietmar. -- Company details: http://ts.fujitsu.com/imprint.html [-- Attachment #1.2: Type: text/html, Size: 12612 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: dom0 / hypervisor hang on dom0 boot 2013-05-21 7:39 ` Dietmar Hahn @ 2013-05-21 14:10 ` Konrad Rzeszutek Wilk 0 siblings, 0 replies; 23+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-05-21 14:10 UTC (permalink / raw) To: Dietmar Hahn; +Cc: Konrad Rzeszutek Wilk, Andrew Cooper, Jan Beulich, xen-devel On Tue, May 21, 2013 at 09:39:14AM +0200, Dietmar Hahn wrote: > Am Freitag 17 Mai 2013, 18:28:16 schrieb Konrad Rzeszutek Wilk: > > On Thu, May 16, 2013 at 01:07:05PM +0200, Dietmar Hahn wrote: > > > Am Mittwoch 15 Mai 2013, 10:42:17 schrieb Jan Beulich: > > > > >>> On 15.05.13 at 11:12, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > > > > > Am Mittwoch 15 Mai 2013, 09:35:46 schrieb Jan Beulich: > > > > >> >>> On 15.05.13 at 08:53, Dietmar Hahn <dietmar.hahn@ts.fujitsu.com> wrote: > > > > >> > I tried iommu=debug and I can't see any faulting messages but Iam not > > > > >> > familiar with this code. > > > > >> > I attached the logging, maybe anyone can have a look on this. > > > > > > > > Perhaps only (if at all) by instrumenting the hypervisor. The > > > > question of course is how easily/quickly you can narrow down the > > > > code region that it might be dying in. And whether it's a hypervisor > > > > action at all that causes the hang (as opposed to something the > > > > DRM code in Dom0 does). > > > > > > I added some debug code to the linux kernel and could track down the > > > point of the hang. I used openSuSE kernel 3.7.10-1.4 but I looked at newer > > > kernels and found that the code is similar. > > > > > > i915_gem_init_global_gtt(...) > > > ... > > > intel_gtt_clear_range(start / PAGE_SIZE, (end-start) / PAGE_SIZE); > > > ... > > > > > > void intel_gtt_clear_range(unsigned int first_entry, unsigned int num_entries) > > > { > > > unsigned int i; > > > > > > ---> A printk(...) here is seen on serial line! > > > > > > for (i = first_entry; i < (first_entry + num_entries); i++) { > > > intel_private.driver->write_entry(intel_private.base.scratch_page_dma, > > > i, 0); > > > } > > > > > > ---> A printk(...) here is never seen! > > > > > > readl(intel_private.gtt+i-1); > > > } > > > > > > The function behind the pointer intel_private.driver->write_entry is > > > i965_write_entry(). And the interesting instruction seems to be: > > > writel(addr | pte_flags, intel_private.gtt + entry); > > > > > > I added another printk() on start of the function i965_write_entry(). > > > And surprisingly after printing a lot of messages the kernel came up!!! > > > But now I had other problems like losing the audio device (maybe timeouts). > > > So maybe the hang is a timing problem? > > > > > > What I wanted to check is, what the hypervisor is doing while the system hangs. > > > Has anybody an idea maybe a timer and after 30s printing a dump of the stack of > > > all cpus? > > > > Yes. Can you try the two attached patches please. > > I tried both but none helped. I think it couldn't be expected as the first > patch handles an error case and the line with the second patch, > the call of pci_dma_sync_single_for_device(), gets not reached. OK, perhaps move the pci_dma_sync_single_for_device in the while loop? The idea behind that flush code is to kick the GTT to do its job. But if the SWIOTLB is used and the bounce page is used, then the writes don't end up in the flush code area at all - until the pci_unmap_page. Or the pci_dma_sync_single call. The other option was to use pci_alloc_coherent so that we would not need to use the PCI API. But I would like to verify that the theory is correct. > > Dietmar. > > -- > Company details: http://ts.fujitsu.com/imprint.html ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2013-05-21 14:10 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-05-14 12:35 dom0 / hypervisor hang on dom0 boot Dietmar Hahn 2013-05-14 12:42 ` Andrew Cooper 2013-05-14 12:50 ` Dietmar Hahn 2013-05-14 12:51 ` Andrew Cooper 2013-05-14 13:25 ` Dietmar Hahn 2013-05-14 13:27 ` Jan Beulich 2013-05-15 6:53 ` Dietmar Hahn 2013-05-15 8:35 ` Jan Beulich 2013-05-15 9:12 ` Dietmar Hahn 2013-05-15 9:42 ` Jan Beulich 2013-05-16 11:07 ` Dietmar Hahn 2013-05-16 12:10 ` Jan Beulich 2013-05-16 13:16 ` Dietmar Hahn 2013-05-16 13:45 ` Jan Beulich 2013-05-17 7:10 ` Dietmar Hahn 2013-05-16 14:50 ` Dugger, Donald D 2013-05-20 14:30 ` Dugger, Donald D 2013-05-21 8:03 ` Jan Beulich 2013-05-21 8:28 ` Tian, Kevin 2013-05-21 8:47 ` Jan Beulich 2013-05-17 22:28 ` Konrad Rzeszutek Wilk 2013-05-21 7:39 ` Dietmar Hahn 2013-05-21 14:10 ` Konrad Rzeszutek Wilk
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.