Bug#962003: Linux kernel 5.6: [drm:i915_gem_gtt_finish_pages [i915]] *ERROR* Failed to wait for idle; VT'd may hang

[Stefan Pietsch]

On 30.12.22 11:42, Diederik de Haas wrote:

On Friday, 30 December 2022 01:48:53 CET Stefan Pietsch wrote:

Affected is at least linux-image-5.6.0-1-amd64 (5.6.7-1) and
linux-image-5.6.0-2-amd64 (5.6.14-1).>

This also affects 5.5.0-rc5-amd64.

(https://snapshot.debian.org/archive/debian/20200106T211159Z/pool/main/l/l
inux/)

The kernel boot option "intel_iommu=igfx_off" prevents the error message.


This seems to be resolved in newer kernel versions.
I'm not able to reproduce this with kernel version 5.14.0-4-amd64
(5.14.16-1).


Great that it is resolved :-)

As many people are affected and the Stable kernel version still seems to
exhibit the problem, I want to ask a question:
Are you willing to help out to narrow down as much as possible which version
introduced the error and in which is was fixed? Wrt the latter, does 5.14.12-1
still show the issue?


[...]

Just a small update: kernel version 5.13.9-1~exp2 is also not affected by the 
problem.

Bug#962003: Linux kernel 5.6: [drm:i915_gem_gtt_finish_pages [i915]] *ERROR* Failed to wait for idle; VT'd may hang

[Stefan Pietsch]

On 07.06.20 08:48, Stefan Pietsch wrote:

On 2020-06-01 20:44, Stefan Pietsch wrote:


Affected is at least linux-image-5.6.0-1-amd64 (5.6.7-1) and 
linux-image-5.6.0-2-amd64 (5.6.14-1).


This also affects 5.5.0-rc5-amd64.

(https://snapshot.debian.org/archive/debian/20200106T211159Z/pool/main/l/linux/)

The kernel boot option "intel_iommu=igfx_off" prevents the error message.


This seems to be resolved in newer kernel versions.
I'm not able to reproduce this with kernel version 5.14.0-4-amd64 (5.14.16-1).


Regards,
Stefan

Bug#963025: fixed in firmware-nonfree 20210315-1~exp1

[Stefan Pietsch]

On 08.04.21 11:50, Stefan Pietsch wrote:

On 30.03.21 13:35, maximilian attems wrote:

reopen 963025
found -1 20210315-2
tags -1 moreinfo
stop


[18661.586025] CPU: 0 PID: 8408 Comm: hostapd Tainted: G    W 
5.10.0-5-amd64 #1 Debian 5.10.24-1
[18661.586029] Hardware name: LENOVO 20N2007GGE/20N2007GGE, BIOS N2IET81W (1.59 
) 11/29/2019



Please could you upgrade the BIOS to latest for T490, 1.72 2021/03/17
to exclude this guy fault.



I upgraded the Lenovo T490 BIOS from 1.59 to 1.72.
That did not make any difference.



I cannot reproduce this with firmware version 46.9d0122c0.0 
9000-pu-b0-jf-b0-46.ucode from firmware-iwlwifi 20221012-1.
This seems to be fixed.

Regards,
Stefan

Bug#963025: fixed in firmware-nonfree 20210315-1~exp1

[Stefan Pietsch]

On 30.03.21 13:35, maximilian attems wrote:

reopen 963025
found -1 20210315-2
tags -1 moreinfo
stop


[18661.586025] CPU: 0 PID: 8408 Comm: hostapd Tainted: GW 
5.10.0-5-amd64 #1 Debian 5.10.24-1
[18661.586029] Hardware name: LENOVO 20N2007GGE/20N2007GGE, BIOS N2IET81W (1.59 
) 11/29/2019



Please could you upgrade the BIOS to latest for T490, 1.72 2021/03/17
to exclude this guy fault.



I upgraded the Lenovo T490 BIOS from 1.59 to 1.72.
That did not make any difference.


Regards,
Stefan

Bug#963025: fixed in firmware-nonfree 20210315-1~exp1

[Stefan Pietsch]

On 16.03.21 17:34, Debian FTP Masters wrote:
> Source: firmware-nonfree
> Source-Version: 20210315-1~exp1
> Done: maximilian attems 
>
> We believe that the bug you reported is fixed in the latest version of
> firmware-nonfree, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 963...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> maximilian attems  (supplier of updated firmware-nonfree 
package)

- snip -


I cannot confirm that the bug is fixed.

firmware-iwlwifi 20210315-2 is installed.



dmesg output when wireless interface stopped working:

[18654.227951] iwlwifi :00:14.3: Microcode SW error detected. Restarting 
0x0.
[18654.228331] iwlwifi :00:14.3: Start IWL Error Log Dump:
[18654.228339] iwlwifi :00:14.3: Status: 0x0040, count: 6
[18654.228345] iwlwifi :00:14.3: Loaded firmware version: 46.6f9f215c.0 
9000-pu-b0-jf-b0-46.ucode
[18654.228353] iwlwifi :00:14.3: 0x3203 | ADVANCED_SYSASSERT
[18654.228358] iwlwifi :00:14.3: 0xA200 | trm_hw_status0
[18654.228363] iwlwifi :00:14.3: 0x | trm_hw_status1
[18654.228368] iwlwifi :00:14.3: 0x00488C0E | branchlink2
[18654.228373] iwlwifi :00:14.3: 0x00478EDE | interruptlink1
[18654.228378] iwlwifi :00:14.3: 0x | interruptlink2
[18654.228383] iwlwifi :00:14.3: 0x0004 | data1
[18654.228388] iwlwifi :00:14.3: 0xDEADBEEF | data2
[18654.228393] iwlwifi :00:14.3: 0xDEADBEEF | data3
[18654.228398] iwlwifi :00:14.3: 0x | beacon time
[18654.228403] iwlwifi :00:14.3: 0x0290028A | tsf low
[18654.228408] iwlwifi :00:14.3: 0x | tsf hi
[18654.228412] iwlwifi :00:14.3: 0x | time gp1
[18654.228417] iwlwifi :00:14.3: 0x0290028B | time gp2
[18654.228422] iwlwifi :00:14.3: 0x0001 | uCode revision type
[18654.228427] iwlwifi :00:14.3: 0x002E | uCode version major
[18654.228432] iwlwifi :00:14.3: 0x6F9F215C | uCode version minor
[18654.228437] iwlwifi :00:14.3: 0x0312 | hw version
[18654.228442] iwlwifi :00:14.3: 0x00C89008 | board version
[18654.228447] iwlwifi :00:14.3: 0x8073FC28 | hcmd
[18654.228452] iwlwifi :00:14.3: 0x24022000 | isr0
[18654.228457] iwlwifi :00:14.3: 0x | isr1
[18654.228461] iwlwifi :00:14.3: 0x08201802 | isr2
[18654.228466] iwlwifi :00:14.3: 0x004168C0 | isr3
[18654.228471] iwlwifi :00:14.3: 0x | isr4
[18654.228476] iwlwifi :00:14.3: 0x0940001C | last cmd Id
[18654.228480] iwlwifi :00:14.3: 0xCEB6 | wait_event
[18654.228485] iwlwifi :00:14.3: 0x10D4 | l2p_control
[18654.228490] iwlwifi :00:14.3: 0x00018034 | l2p_duration
[18654.228495] iwlwifi :00:14.3: 0x0007 | l2p_mhvalid
[18654.228500] iwlwifi :00:14.3: 0x8100 | l2p_addr_match
[18654.228505] iwlwifi :00:14.3: 0x000D | lmpm_pmg_sel
[18654.228510] iwlwifi :00:14.3: 0x28010905 | timestamp
[18654.228514] iwlwifi :00:14.3: 0xD8B8 | flow_handler
[18654.228663] iwlwifi :00:14.3: Start IWL Error Log Dump:
[18654.228668] iwlwifi :00:14.3: Status: 0x0040, count: 7
[18654.228674] iwlwifi :00:14.3: 0x2070 | NMI_INTERRUPT_LMAC_FATAL
[18654.228679] iwlwifi :00:14.3: 0x | umac branchlink1
[18654.228684] iwlwifi :00:14.3: 0xC0088BBE | umac branchlink2
[18654.228689] iwlwifi :00:14.3: 0xC0084458 | umac interruptlink1
[18654.228694] iwlwifi :00:14.3: 0xC0084458 | umac interruptlink2
[18654.228699] iwlwifi :00:14.3: 0x0800 | umac data1
[18654.228704] iwlwifi :00:14.3: 0xC0084458 | umac data2
[18654.228708] iwlwifi :00:14.3: 0xDEADBEEF | umac data3
[18654.228713] iwlwifi :00:14.3: 0x002E | umac major
[18654.228718] iwlwifi :00:14.3: 0x6F9F215C | umac minor
[18654.228723] iwlwifi :00:14.3: 0x029002A9 | frame pointer
[18654.228728] iwlwifi :00:14.3: 0xC088627C | stack pointer
[18654.228733] iwlwifi :00:14.3: 0x00660118 | last host cmd
[18654.228737] iwlwifi :00:14.3: 0x | isr status reg
[18654.228758] iwlwifi :00:14.3: Fseq Registers:
[18654.228769] iwlwifi :00:14.3: 0xA7691BFB | FSEQ_ERROR_CODE
[18654.228780] iwlwifi :00:14.3: 0x | FSEQ_TOP_INIT_VERSION
[18654.228791] iwlwifi :00:14.3: 0x58F7C241 | FSEQ_CNVIO_INIT_VERSION
[18654.228802] iwlwifi :00:14.3: 0xA384 | FSEQ_OTP_VERSION
[18654.228813] iwlwifi :00:14.3: 0x2B29C823 | FSEQ_TOP_CONTENT_VERSION
[18654.228824] iwlwifi :00:14.3: 0x27FAB991 | FSEQ_ALIVE_TOKEN
[18654.228835] iwlwifi :00:14.3: 0xD01B76C3 | FSEQ_CNVI_ID
[18654.228846] iwlwifi :00:14.3: 0xC5454E1C | FSEQ_CNVR_ID
[18654.228857] iwlwifi :00:14.3: 0x01000100 | CNVI_AUX_MISC_CHIP
[18654.228870] iwlwifi :00:14.3: 0x013002

Bug#963025: firmware-iwlwifi: Microcode SW error detected / 9000-pu-b0-jf-b0-46.ucode

[Stefan Pietsch]

On 22.01.21 20:48, maximilian attems wrote:

Firmware 9000-pu-b0-jf-b0-46.ucode stops working when used with
hostapd as soon as a wireless client connects.


Is that still happening with latest 5.10 linux and newer
firmware-iwlwifi version >= 202011?



The problem still exists with firmware-iwlwifi 20201218-2.

# cat /proc/version
Linux version 5.10.0-1-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-5) 10.2.1 20210108, GNU ld (GNU 
Binutils for Debian) 2.35.1) #1 SMP Debian 5.10.5-1 (2021-01-09)



# dmesg output #


[81668.281626] iwlwifi :00:14.3: Queue 9 is active on fifo 3 and stuck for 1 ms. SW [0, 2] HW [0, 0] FH 
TRB=0x0baef4f74

[81668.281924] iwlwifi :00:14.3: Microcode SW error detected. Restarting 
0x0.
[81668.282306] iwlwifi :00:14.3: Start IWL Error Log Dump:
[81668.282313] iwlwifi :00:14.3: Status: 0x0040, count: 6
[81668.282319] iwlwifi :00:14.3: Loaded firmware version: 46.4d093a30.0 
9000-pu-b0-jf-b0-46.ucode
[81668.282325] iwlwifi :00:14.3: 0x0084 | NMI_INTERRUPT_UNKNOWN
[81668.282330] iwlwifi :00:14.3: 0x22F0 | trm_hw_status0
[81668.282335] iwlwifi :00:14.3: 0x | trm_hw_status1
[81668.282339] iwlwifi :00:14.3: 0x00488876 | branchlink2
[81668.282344] iwlwifi :00:14.3: 0x00478E36 | interruptlink1
[81668.282348] iwlwifi :00:14.3: 0x00478E36 | interruptlink2
[81668.282352] iwlwifi :00:14.3: 0x00011526 | data1
[81668.282356] iwlwifi :00:14.3: 0xFF00 | data2
[81668.282360] iwlwifi :00:14.3: 0xF008 | data3
[81668.282365] iwlwifi :00:14.3: 0x | beacon time
[81668.282369] iwlwifi :00:14.3: 0x00A556BB | tsf low
[81668.282373] iwlwifi :00:14.3: 0x | tsf hi
[81668.282377] iwlwifi :00:14.3: 0x | time gp1
[81668.282381] iwlwifi :00:14.3: 0x00A556BC | time gp2
[81668.282386] iwlwifi :00:14.3: 0x0001 | uCode revision type
[81668.282390] iwlwifi :00:14.3: 0x002E | uCode version major
[81668.282395] iwlwifi :00:14.3: 0x4D093A30 | uCode version minor
[81668.282399] iwlwifi :00:14.3: 0x0312 | hw version
[81668.282403] iwlwifi :00:14.3: 0x18C89008 | board version
[81668.282407] iwlwifi :00:14.3: 0x0049011C | hcmd
[81668.282412] iwlwifi :00:14.3: 0x00022000 | isr0
[81668.282416] iwlwifi :00:14.3: 0x | isr1
[81668.282420] iwlwifi :00:14.3: 0x08001802 | isr2
[81668.282424] iwlwifi :00:14.3: 0x00417CC0 | isr3
[81668.282428] iwlwifi :00:14.3: 0x | isr4
[81668.282433] iwlwifi :00:14.3: 0x00490191 | last cmd Id
[81668.282437] iwlwifi :00:14.3: 0x00011526 | wait_event
[81668.282441] iwlwifi :00:14.3: 0x4208 | l2p_control
[81668.282445] iwlwifi :00:14.3: 0x0020 | l2p_duration
[81668.282450] iwlwifi :00:14.3: 0x033F | l2p_mhvalid
[81668.282454] iwlwifi :00:14.3: 0xA000 | l2p_addr_match
[81668.282458] iwlwifi :00:14.3: 0x000D | lmpm_pmg_sel
[81668.282462] iwlwifi :00:14.3: 0x01102344 | timestamp
[81668.282466] iwlwifi :00:14.3: 0xB0D0 | flow_handler
[81668.282614] iwlwifi :00:14.3: Start IWL Error Log Dump:
[81668.282619] iwlwifi :00:14.3: Status: 0x0040, count: 7
[81668.282624] iwlwifi :00:14.3: 0x2066 | NMI_INTERRUPT_HOST
[81668.282628] iwlwifi :00:14.3: 0x | umac branchlink1
[81668.282633] iwlwifi :00:14.3: 0xC0088BBE | umac branchlink2
[81668.282637] iwlwifi :00:14.3: 0xC0084458 | umac interruptlink1
[81668.282641] iwlwifi :00:14.3: 0xC0084458 | umac interruptlink2
[81668.282646] iwlwifi :00:14.3: 0x0100 | umac data1
[81668.282650] iwlwifi :00:14.3: 0xC0084458 | umac data2
[81668.282654] iwlwifi :00:14.3: 0xDEADBEEF | umac data3
[81668.282658] iwlwifi :00:14.3: 0x002E | umac major
[81668.282662] iwlwifi :00:14.3: 0x4D093A30 | umac minor
[81668.282667] iwlwifi :00:14.3: 0x00A556AA | frame pointer
[81668.282671] iwlwifi :00:14.3: 0xC088627C | stack pointer
[81668.282675] iwlwifi :00:14.3: 0x00490191 | last host cmd
[81668.282679] iwlwifi :00:14.3: 0x | isr status reg
[81668.282699] iwlwifi :00:14.3: Fseq Registers:
[81668.282709] iwlwifi :00:14.3: 0xAF493BFB | FSEQ_ERROR_CODE
[81668.282720] iwlwifi :00:14.3: 0x | FSEQ_TOP_INIT_VERSION
[81668.282730] iwlwifi :00:14.3: 0x58B74E41 | FSEQ_CNVIO_INIT_VERSION
[81668.282740] iwlwifi :00:14.3: 0xA384 | FSEQ_OTP_VERSION
[81668.282751] iwlwifi :00:14.3: 0x7A29D869 | FSEQ_TOP_CONTENT_VERSION
[81668.282761] iwlwifi :00:14.3: 0x46FAB991 | FSEQ_ALIVE_TOKEN
[81668.282771] iwlwifi :00:14.3: 0x901A6683 | FSEQ_CNVI_ID
[81668.282781] iwlwifi :00:14.3: 0xC545CE1C | FSEQ_CNVR_ID
[81668.282792] iwlwifi :00:14.3: 0x01000100 | CNVI_AUX_MISC_CHIP
[81668.282805] iwlwifi :00:14.3: 0x01300202 | CNVR_AUX_MISC_CHIP
[81668.282818] iwlwifi :00:14.3: 0x485B | 
CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
[81668.282861] iwlwifi :00:14.3: 0xA5A5A5A2 | 
CNVR_SCU_S

Bug#963025: firmware-iwlwifi: Microcode SW error detected / 9000-pu-b0-jf-b0-46.ucode

[Stefan Pietsch]

Package: firmware-iwlwifi
Version: 20190717-2
Severity: important

Firmware 9000-pu-b0-jf-b0-46.ucode stops working when used with hostapd as soon 
as a wireless client connects.
This also affects firmware 9000-pu-b0-jf-b0-41.ucode.

I was not able to reproduce this with firmware 9000-pu-b0-jf-b0-38.ucode


##


# lspci output of wireless controller

00:14.3 Network controller: Intel Corporation Cannon Point-LP CNVi 
[Wireless-AC] (rev 30)
Subsystem: Intel Corporation Cannon Point-LP CNVi [Wireless-AC]
Flags: fast devsel, IRQ 16, IOMMU group 5
Memory at c9738000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [40] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [80] MSI-X: Enable- Count=16 Masked-
Capabilities: [100] Null
Capabilities: [14c] Latency Tolerance Reporting
Capabilities: [164] Vendor Specific Information: ID=0010 Rev=0 Len=014 

Kernel modules: iwlwifi


##


# cat /proc/version
Linux version 5.6.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-13)) #1 SMP Debian 
5.6.14-2 (2020-06-09)



##


# dmesg with 9000-pu-b0-jf-b0-41.ucode loaded

[ 1368.793833] iwlwifi :00:14.3: Microcode SW error detected. Restarting 
0x0.
[ 1368.794275] iwlwifi :00:14.3: Start IWL Error Log Dump:
[ 1368.794282] iwlwifi :00:14.3: Status: 0x0040, count: 6
[ 1368.794287] iwlwifi :00:14.3: Loaded firmware version: 41.fc1a7aea.0 
9000-pu-b0-jf-b0-41.ucode
[ 1368.794293] iwlwifi :00:14.3: 0x3203 | ADVANCED_SYSASSERT
[ 1368.794298] iwlwifi :00:14.3: 0xA200 | trm_hw_status0
[ 1368.794302] iwlwifi :00:14.3: 0x | trm_hw_status1
[ 1368.794306] iwlwifi :00:14.3: 0x004885AA | branchlink2
[ 1368.794310] iwlwifi :00:14.3: 0x0047A3E2 | interruptlink1
[ 1368.794313] iwlwifi :00:14.3: 0x | interruptlink2
[ 1368.794317] iwlwifi :00:14.3: 0x0004 | data1
[ 1368.794323] iwlwifi :00:14.3: 0xDEADBEEF | data2
[ 1368.794327] iwlwifi :00:14.3: 0xDEADBEEF | data3
[ 1368.794331] iwlwifi :00:14.3: 0x | beacon time
[ 1368.794335] iwlwifi :00:14.3: 0x0489CF77 | tsf low
[ 1368.794338] iwlwifi :00:14.3: 0x | tsf hi
[ 1368.794342] iwlwifi :00:14.3: 0x | time gp1
[ 1368.794346] iwlwifi :00:14.3: 0x0489CF77 | time gp2
[ 1368.794350] iwlwifi :00:14.3: 0x0001 | uCode revision type
[ 1368.794354] iwlwifi :00:14.3: 0x0029 | uCode version major
[ 1368.794358] iwlwifi :00:14.3: 0xFC1A7AEA | uCode version minor
[ 1368.794370] iwlwifi :00:14.3: 0x0312 | hw version
[ 1368.794391] iwlwifi :00:14.3: 0x18C89008 | board version
[ 1368.794407] iwlwifi :00:14.3: 0x8069FC28 | hcmd
[ 1368.794422] iwlwifi :00:14.3: 0x24022000 | isr0
[ 1368.794435] iwlwifi :00:14.3: 0x | isr1
[ 1368.794447] iwlwifi :00:14.3: 0x0820180A | isr2
[ 1368.794459] iwlwifi :00:14.3: 0x00416CC0 | isr3
[ 1368.794474] iwlwifi :00:14.3: 0x | isr4
[ 1368.794486] iwlwifi :00:14.3: 0x00490191 | last cmd Id
[ 1368.794494] iwlwifi :00:14.3: 0x | wait_event
[ 1368.794498] iwlwifi :00:14.3: 0x10D4 | l2p_control
[ 1368.794502] iwlwifi :00:14.3: 0x00018034 | l2p_duration
[ 1368.794506] iwlwifi :00:14.3: 0x0007 | l2p_mhvalid
[ 1368.794510] iwlwifi :00:14.3: 0x8100 | l2p_addr_match
[ 1368.794514] iwlwifi :00:14.3: 0x000F | lmpm_pmg_sel
[ 1368.794518] iwlwifi :00:14.3: 0x04100930 | timestamp
[ 1368.794521] iwlwifi :00:14.3: 0x502C | flow_handler
[ 1368.794669] iwlwifi :00:14.3: Start IWL Error Log Dump:
[ 1368.794674] iwlwifi :00:14.3: Status: 0x0040, count: 7
[ 1368.794679] iwlwifi :00:14.3: 0x2070 | NMI_INTERRUPT_LMAC_FATAL
[ 1368.794683] iwlwifi :00:14.3: 0x | umac branchlink1
[ 1368.794687] iwlwifi :00:14.3: 0xC0087F22 | umac branchlink2
[ 1368.794691] iwlwifi :00:14.3: 0xC0083C9C | umac interruptlink1
[ 1368.794695] iwlwifi :00:14.3: 0xC0083C9C | umac interruptlink2
[ 1368.794699] iwlwifi :00:14.3: 0x0800 | umac data1
[ 1368.794703] iwlwifi :00:14.3: 0xC0083C9C | umac data2
[ 1368.794707] iwlwifi :00:14.3: 0xDEADBEEF | umac data3
[ 1368.794710] iwlwifi :00:14.3: 0x0029 | umac major
[ 1368.794714] iwlwifi :00:14.3: 0xFC1A7AEA | umac minor
[ 1368.794718] iwlwifi :00:14.3: 0xC0886280 | frame pointer
[ 1368.794722] iwlwifi :00:14.3: 0xC0886280 | stack pointer
[ 1368.794725] iwlwifi :00:14.3: 0x004A0118 | last host cmd
[ 1368.794729] iwlwifi :00:14.3: 0x | isr status reg
[ 1368.794751] iwlwifi :00:14.3: Fseq Registers:
[ 1368.794774] iwlwifi :00:14.3: 0xA7493BFB | FSEQ_ERROR_CODE
[ 1368.794794] iwlwifi :00:14.3: 0x | FSEQ_TOP_INIT_VERSION
[ 1368.794816] iwlwifi :00:14.3: 0x58

Bug#962003: Linux kernel 5.6: [drm:i915_gem_gtt_finish_pages [i915]] *ERROR* Failed to wait for idle; VT'd may hang

[Stefan Pietsch]

On 2020-06-01 20:44, Stefan Pietsch wrote:

Affected is at least linux-image-5.6.0-1-amd64 (5.6.7-1) and 
linux-image-5.6.0-2-amd64 (5.6.14-1).


This also affects 5.5.0-rc5-amd64.

(https://snapshot.debian.org/archive/debian/20200106T211159Z/pool/main/l/linux/)

The kernel boot option "intel_iommu=igfx_off" prevents the error message.

Bug#962003: Linux kernel 5.6: [drm:i915_gem_gtt_finish_pages [i915]] *ERROR* Failed to wait for idle; VT'd may hang

[Stefan Pietsch]

Package: linux-image-amd64
Version: 5.6.14-1


Starting with Linux kernel package linux-image-5.6.0-1-amd64 (5.6.7-1) I 
get the following error message that is repeating every few seconds:


kernel: [drm:i915_gem_gtt_finish_pages [i915]] *ERROR* Failed to wait 
for idle; VT'd may hang.



Affected is at least linux-image-5.6.0-1-amd64 (5.6.7-1) and 
linux-image-5.6.0-2-amd64 (5.6.14-1).


The error message does not appear with linux-image-5.4.0-4-amd64 
(5.4.19-1).


Hardware is a Lenovo T410 with integrated Intel graphics controller.

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 26.06.2013 12:47, Gleb Natapov wrote:
> On Mon, Jun 24, 2013 at 10:42:57PM +0200, Stefan Pietsch wrote:
>> On 24.06.2013 14:30, Gleb Natapov wrote:
>>> On Mon, Jun 24, 2013 at 01:59:34PM +0200, Stefan Pietsch wrote:
>>>> As soon as I remove "kvmvapic.bin" the virtual machine boots with
>>>> qemu-kvm 1.5.0. I just verified this with Linux kernel 3.10.0-rc5.
>>>> "emulate_invalid_guest_state=0" or "emulate_invalid_guest_state=1" make
>>>> no difference.
>>>>
>>>> Please send your patches.
>>> Here it is, run with it and kvmvapic.bin present. See what is printed in
>>> dmesg after the failure.
>>>
>>>
>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>>> index f4a5b3f..65488a4 100644
>>> --- a/arch/x86/kvm/vmx.c
>>> +++ b/arch/x86/kvm/vmx.c
>>> @@ -3385,6 +3385,7 @@ static void vmx_get_segment(struct kvm_vcpu *vcpu,
>>>  {
>>> struct vcpu_vmx *vmx = to_vmx(vcpu);
>>> u32 ar;
>>> +   unsigned long rip;
>>>  
>>> if (vmx->rmode.vm86_active && seg != VCPU_SREG_LDTR) {
>>> *var = vmx->rmode.segs[seg];
>>> @@ -3408,6 +3409,9 @@ static void vmx_get_segment(struct kvm_vcpu *vcpu,
>>> var->db = (ar >> 14) & 1;
>>> var->g = (ar >> 15) & 1;
>>> var->unusable = (ar >> 16) & 1;
>>> +   rip = kvm_rip_read(vcpu);
>>> +   if ((rip == 0xc101611c || rip == 0xc101611a) && seg == VCPU_SREG_FS)
>>> +   printk("base=%p limit=%p selector=%x ar=%x\n", var->base, 
>>> var->limit, var->selector, ar);
>>>  }
>>>  
>>>  static u64 vmx_get_segment_base(struct kvm_vcpu *vcpu, int seg)
>>
>>
>> Booting kernel Linux 3.10-rc5 with your patch applied produces these
>> messages in dmesg when starting a virtual machine:
>>
>> emulate_invalid_guest_state=0
>> [  118.732151] base= limit=  (null) selector=ffff ar=0
>> [  118.732341] base= limit=  (null) selector=ffff ar=0
>>
> I've butchered printk format, but it gives me the idea of what is going
> on anyway. Can you try the patch below with
> emulate_invalid_guest_state=0|1?
> 
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index f4a5b3f..eb062ce 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -3395,19 +3395,20 @@ static void vmx_get_segment(struct kvm_vcpu *vcpu,
>   var->selector = vmx_read_guest_seg_selector(vmx, seg);
>   return;
>   }
> +
>   var->base = vmx_read_guest_seg_base(vmx, seg);
>   var->limit = vmx_read_guest_seg_limit(vmx, seg);
>   var->selector = vmx_read_guest_seg_selector(vmx, seg);
>   ar = vmx_read_guest_seg_ar(vmx, seg);
> + var->unusable = (ar >> 16) & 1;
>   var->type = ar & 15;
>   var->s = (ar >> 4) & 1;
>   var->dpl = (ar >> 5) & 3;
> - var->present = (ar >> 7) & 1;
> + var->present = !var->unusable;
>   var->avl = (ar >> 12) & 1;
>   var->l = (ar >> 13) & 1;
>   var->db = (ar >> 14) & 1;
>   var->g = (ar >> 15) & 1;
> - var->unusable = (ar >> 16) & 1;
>  }
>  
>  static u64 vmx_get_segment_base(struct kvm_vcpu *vcpu, int seg)


Kernel 3.10-rc5 with your latest patch applied can successfully boot the
virtual machine with emulate_invalid_guest_state 0 or 1.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51cc47ae.20...@sp.consulting.lsexperts.de

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 24.06.2013 14:30, Gleb Natapov wrote:
> On Mon, Jun 24, 2013 at 01:59:34PM +0200, Stefan Pietsch wrote:
>> As soon as I remove "kvmvapic.bin" the virtual machine boots with
>> qemu-kvm 1.5.0. I just verified this with Linux kernel 3.10.0-rc5.
>> "emulate_invalid_guest_state=0" or "emulate_invalid_guest_state=1" make
>> no difference.
>>
>> Please send your patches.
> Here it is, run with it and kvmvapic.bin present. See what is printed in
> dmesg after the failure.
> 
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index f4a5b3f..65488a4 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -3385,6 +3385,7 @@ static void vmx_get_segment(struct kvm_vcpu *vcpu,
>  {
>   struct vcpu_vmx *vmx = to_vmx(vcpu);
>   u32 ar;
> + unsigned long rip;
>  
>   if (vmx->rmode.vm86_active && seg != VCPU_SREG_LDTR) {
>   *var = vmx->rmode.segs[seg];
> @@ -3408,6 +3409,9 @@ static void vmx_get_segment(struct kvm_vcpu *vcpu,
>   var->db = (ar >> 14) & 1;
>   var->g = (ar >> 15) & 1;
>   var->unusable = (ar >> 16) & 1;
> + rip = kvm_rip_read(vcpu);
> + if ((rip == 0xc101611c || rip == 0xc101611a) && seg == VCPU_SREG_FS)
> + printk("base=%p limit=%p selector=%x ar=%x\n", var->base, 
> var->limit, var->selector, ar);
>  }
>  
>  static u64 vmx_get_segment_base(struct kvm_vcpu *vcpu, int seg)


Booting kernel Linux 3.10-rc5 with your patch applied produces these
messages in dmesg when starting a virtual machine:

emulate_invalid_guest_state=0
[  118.732151] base= limit=  (null) selector=ffff ar=0
[  118.732341] base= limit=  (null) selector=ffff ar=0

emulate_invalid_guest_state=1
[  196.481653] base= limit=  (null) selector=ffff ar=0
[  196.481700] base= limit=  (null) selector=ffff ar=0
[  196.481706] base= limit=  (null) selector=ffff ar=0
[  196.481711] base= limit=  (null) selector=ffff ar=0
[  196.481716] base= limit=  (null) selector=ffff ar=0
[  196.481720] base= limit=  (null) selector=ffff ar=0
[  196.481725] base= limit=  (null) selector=ffff ar=0
[  196.481730] base= limit=  (null) selector=ffff ar=0
[  196.481735] base= limit=  (null) selector=ffff ar=0
[  196.481739] base= limit=  (null) selector=ffff ar=0
[  196.481777] base= limit=  (null) selector=ffff ar=0
[  196.482068] base= limit=  (null) selector=ffff ar=0
[  196.482073] base= limit=  (null) selector=ffff ar=0
[  196.482079] base= limit=  (null) selector=ffff ar=0
[  196.482084] base= limit=  (null) selector=ffff ar=0
[  196.482131] base= limit=  (null) selector=ffff ar=0
[  196.482136] base= limit=  (null) selector=ffff ar=0
[  196.482142] base= limit=  (null) selector=ffff ar=0
[  196.482146] base= limit=  (null) selector=ffff ar=0
[  196.482193] base= limit=  (null) selector=ffff ar=0
[  196.482198] base= limit=  (null) selector=ffff ar=0
[  196.482203] base= limit=  (null) selector=ffff ar=0
[  196.482208] base= limit=  (null) selector=ffff ar=0
[  196.482255] base= limit=  (null) selector=ffff ar=0
[  196.482259] base= limit=  (null) selector=ffff ar=0
[  196.482265] base= limit=  (null) selector=ffff ar=0
[  196.482269] base= limit=  (null) selector=ffff ar=0
[  196.482316] base= limit=  (null) selector=ffff ar=0
[  196.482321] base= limit=  (null) selector=ffff ar=0
[  196.482326] base= limit=  (null) selector=ffff ar=0
[  196.482331] base= limit=  (null) selector=ffff ar=0
[  196.482378] base= limit=  (null) selector=ffff ar=0
[  196.482382] base= limit=  (null) selector=ffff ar=0
[  196.482388] base= limit=  (null) selector=ffff ar=0
[  196.482392] base= limit=  (null) selector=ffff ar=0
[  196.482439] base= limit=  (null) selector=ffff ar=0
[  196.482444] base= limit=  (null) selector=ffff ar=0
[  196.482449] base= limit=  (null) selector=ffff ar=0
[  196.482454] base= limit=  (null) selector=ffff ar=0
[  196.482501] base= limit=  (null) selector=ffff ar=0
[  196.482505] base= limit=  (null) selector=ffff ar=0
[  196.482511] base= limit=  (null) selector=ffff ar=0
[  196.482516] base= limit=  (null) selector=ffff ar=0
[  196.482562] base= limit=  (null) selector=ffff ar=0
[  196.482567] base= limit=  (null) selector=ffff ar=0
[  196.482573] base= limit=  (null) selector=f000

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 24.06.2013 13:47, Gleb Natapov wrote:
> On Mon, Jun 24, 2013 at 01:43:26PM +0200, Stefan Pietsch wrote:
>> On 23.06.2013 19:36, Gleb Natapov wrote:
>>> On Sun, Jun 23, 2013 at 06:51:30PM +0200, Stefan Pietsch wrote:
>>>> On 23.06.2013 09:51, Gleb Natapov wrote:
>>>>> On Thu, Jun 20, 2013 at 07:01:49PM +0200, Stefan Pietsch wrote:
>>>>>>> Can you provide the output of 25391454e73e3156202264eb3c473825afe4bc94
>>>>>>> and emulate_invalid_guest_state=0. Also run "x/20i $pc-20" in qemu
>>>>>>> monitor after the hang.
>>>>>>
>>>>>>
>>>>>> 25391454e73e3156202264eb3c473825afe4bc94
>>>>>>  emulate_invalid_guest_state=0
>>>>>>
>>>>> Very interesting. Looks like somewhere during TPR access FS
>>>>> register gets corrupted. Can you remove /usr/share/kvm/kvmvapic.bin
>>>>> and try again? This will disable some code paths during TPR access and
>>>>> will narrow down the issue.
>>>>
>>>>
>>>> Doing this, qemu complains
>>>> "Could not open option rom 'kvmvapic.bin': No such file or directory",
>>>> but the virtual machine boots successful with
>>>> emulate_invalid_guest_state=0 and emulate_invalid_guest_state=1.
>>>>
>>> Hmm, I think we ate close. Can you try with upstream qemu?
>>>
>>>> kvmvapic.bin comes with Debian package "seabios 1.7.2-3".
>>
>> I already tried this with the Debian package qemu-kvm 1.5.0+dfsg-4.
> And it didn't work? Mind trying some debug kernel patches? I suspect
> your CPU does something no CPU I have do, so I want to verify it.


As soon as I remove "kvmvapic.bin" the virtual machine boots with
qemu-kvm 1.5.0. I just verified this with Linux kernel 3.10.0-rc5.
"emulate_invalid_guest_state=0" or "emulate_invalid_guest_state=1" make
no difference.

Please send your patches.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c834a6.7030...@sp.consulting.lsexperts.de

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 23.06.2013 19:36, Gleb Natapov wrote:
> On Sun, Jun 23, 2013 at 06:51:30PM +0200, Stefan Pietsch wrote:
>> On 23.06.2013 09:51, Gleb Natapov wrote:
>>> On Thu, Jun 20, 2013 at 07:01:49PM +0200, Stefan Pietsch wrote:
>>>>> Can you provide the output of 25391454e73e3156202264eb3c473825afe4bc94
>>>>> and emulate_invalid_guest_state=0. Also run "x/20i $pc-20" in qemu
>>>>> monitor after the hang.
>>>>
>>>>
>>>> 25391454e73e3156202264eb3c473825afe4bc94
>>>>  emulate_invalid_guest_state=0
>>>>
>>> Very interesting. Looks like somewhere during TPR access FS
>>> register gets corrupted. Can you remove /usr/share/kvm/kvmvapic.bin
>>> and try again? This will disable some code paths during TPR access and
>>> will narrow down the issue.
>>
>>
>> Doing this, qemu complains
>> "Could not open option rom 'kvmvapic.bin': No such file or directory",
>> but the virtual machine boots successful with
>> emulate_invalid_guest_state=0 and emulate_invalid_guest_state=1.
>>
> Hmm, I think we ate close. Can you try with upstream qemu?
> 
>> kvmvapic.bin comes with Debian package "seabios 1.7.2-3".

I already tried this with the Debian package qemu-kvm 1.5.0+dfsg-4.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c830de.2010...@sp.consulting.lsexperts.de

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 23.06.2013 09:51, Gleb Natapov wrote:
> On Thu, Jun 20, 2013 at 07:01:49PM +0200, Stefan Pietsch wrote:
>>> Can you provide the output of 25391454e73e3156202264eb3c473825afe4bc94
>>> and emulate_invalid_guest_state=0. Also run "x/20i $pc-20" in qemu
>>> monitor after the hang.
>>
>>
>> 25391454e73e3156202264eb3c473825afe4bc94
>>  emulate_invalid_guest_state=0
>>
> Very interesting. Looks like somewhere during TPR access FS
> register gets corrupted. Can you remove /usr/share/kvm/kvmvapic.bin
> and try again? This will disable some code paths during TPR access and
> will narrow down the issue.


Doing this, qemu complains
"Could not open option rom 'kvmvapic.bin': No such file or directory",
but the virtual machine boots successful with
emulate_invalid_guest_state=0 and emulate_invalid_guest_state=1.

kvmvapic.bin comes with Debian package "seabios 1.7.2-3".


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c72792.90...@sp.consulting.lsexperts.de

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 19.06.2013 16:38, Gleb Natapov wrote:
> On Wed, Jun 19, 2013 at 04:12:04PM +0200, Stefan Pietsch wrote:
>> On 19.06.2013 15:41, Gleb Natapov wrote:
>>> On Sun, Jun 16, 2013 at 02:25:04AM +0200, Stefan Pietsch wrote:
>>>>
>>>> first bad commit: [25391454e73e3156202264eb3c473825afe4bc94]
>>>> KVM: VMX: don't clobber segment AR of unusable segments.
>>>>
>>>>
>>>> 25391454e73e3156202264eb3c473825afe4bc94
>>>> emulate_invalid_guest_state=0 -> hangs and shows "KVM: entry failed"
>>>> emulate_invalid_guest_state=1 -> hangs
>>>>
>>> With emulate_invalid_guest_state=1 the commit does nothing. Can you
>>> double check that 218e763f458c44f30041c1b48b4371e130fd4317 works for you
>>> with emulate_invalid_guest_state=1?
>>
>>
>> 218e763f458c44f30041c1b48b4371e130fd4317
>> emulate_invalid_guest_state=0 -> works
>> emulate_invalid_guest_state=1 -> hangs
>>
>> 25391454e73e3156202264eb3c473825afe4bc94 broke
>> emulate_invalid_guest_state=0.
> Can you provide the output of 25391454e73e3156202264eb3c473825afe4bc94
> and emulate_invalid_guest_state=0. Also run "x/20i $pc-20" in qemu
> monitor after the hang.


25391454e73e3156202264eb3c473825afe4bc94
 emulate_invalid_guest_state=0

(qemu) info registers
EAX= EBX=0001 ECX=f000 EDX=f000
ESI=00195e93 EDI= EBP=de84c000 ESP=de84df64
EIP=c101611c EFL=00010246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =007b   00c0f300 DPL=3 DS   [-WA]
CS =0060   00c09b00 DPL=0 CS32 [-RA]
SS =0068   00c09300 DPL=0 DS   [-WA]
DS =007b   00c0f300 DPL=3 DS   [-WA]
FS =  ffff 00f0ff00 DPL=3 CS64 [CRA]
GS =00e0 c1438b40 0018 00409100 DPL=0 DS   [--A]
LDT=  ffff 00f0ff00 DPL=3 CS64 [CRA]
TR =0080 c1400f00 206b 8b00 DPL=0 TSS32-busy
GDT= c13f6000 00ff
IDT= c13f5000 07ff
CR0=8005003b CR2= CR3=014bc000 CR4=0690
DR0= DR1= DR2=0007
DR3=
DR6=0ff0 DR7=0400
EFER=
FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80
FPR0=f44d002c6000 400d FPR1=80847fe7 400e
FPR2=fa007fa24000 400e FPR3=80e88055f000 400e
FPR4=ea61009c4000 400d FPR5=ea62009c4000 400c
FPR6=800bf600 4015 FPR7= 
XMM00=
XMM01=
XMM02=
XMM03=
XMM04=
XMM05=
XMM06=
XMM07=

(qemu) x/20i $pc-20
0xc1016108:  (bad)
0xc1016109:  decl   0x158bc310(%ecx)
0xc101610f:  les-0x7b723ec0(%ebx),%eax
0xc1016115:  adc%al,(%eax)
0xc1016117:  sar$0xff,%bh
0xc101611a:  mov(%eax),%eax
0xc101611c:  ret
0xc101611d:  jmp0xc1016121
0xc101611f:  pause
0xc1016121:  mov(%eax),%edx
0xc1016123:  test   %edx,%edx
0xc1016125:  je 0xc101611f
0xc1016127:  ret
0xc1016128:  cmp$0xfe,%eax
0xc101612d:  setle  %al
0xc1016130:  movzbl %al,%eax
0xc1016133:  ret
0xc1016134:  mov0xc1407b64,%edx
0xc101613a:  mov$0x20,%eax
0xc101613f:  call   *0x9c(%edx)


last 20 lines of the trace:
 qemu-system-x86-4042  [000]   295.592694: vcpu_match_mmio:  gva
0xb0d0 gpa 0xfee000d0 Read GVA
 qemu-system-x86-4042  [000]   295.592694: kvm_apic:
apic_read APIC_LDR = 0x100
 qemu-system-x86-4042  [000]   295.592695: kvm_mmio: mmio
read len 4 gpa 0xfee000d0 val 0x100
 qemu-system-x86-4042  [000]   295.592696: kvm_entry:vcpu 0
 qemu-system-x86-4042  [000]   295.592699: kvm_exit: reason
EXCEPTION_NMI rip 0xc101611a info b080 8b0e
 qemu-system-x86-4042  [000]   295.592700: kvm_page_fault:   address
b080 error_code 9
 qemu-system-x86-4042  [000]   295.592701: kvm_emulate_insn:
0:c101611a:8b 00 (prot32)
 qemu-system-x86-4042  [000]   295.592702: vcpu_match_mmio:  gva
0xb080 gpa 0xfee00080 Read GVA
 qemu-system-x86-4042  [000]   295.592703: kvm_apic:
apic_read APIC_TASKPRI = 0x0
 qemu-system-x86-4042  [000]   295.592703: kvm_mmio: mmio
read len 4 gpa 0xfee00080 val 0x0
 qemu-system-x86-4042  [000]   295.592704: kvm_userspace_exit:   reason
KVM_EXIT_TPR_ACCESS (12)
 qemu-system-x86-4042  [000]   295.592805: kvm_entry:vcpu 0
 qemu-system-x86-4042  [000]   295.592808: kvm_exit: reason
 rip 0xc101611c info 0 8b0e
 qemu-system-x86-4042  [000]   295.592809: kvm_userspace_exit:   reason
KVM_EXIT_FAIL_ENTRY (9)
 qemu-sy

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 19.06.2013 15:41, Gleb Natapov wrote:
> On Sun, Jun 16, 2013 at 02:25:04AM +0200, Stefan Pietsch wrote:
>>
>> first bad commit: [25391454e73e3156202264eb3c473825afe4bc94]
>> KVM: VMX: don't clobber segment AR of unusable segments.
>>
>>
>> 25391454e73e3156202264eb3c473825afe4bc94
>> emulate_invalid_guest_state=0 -> hangs and shows "KVM: entry failed"
>> emulate_invalid_guest_state=1 -> hangs
>>
> With emulate_invalid_guest_state=1 the commit does nothing. Can you
> double check that 218e763f458c44f30041c1b48b4371e130fd4317 works for you
> with emulate_invalid_guest_state=1?


218e763f458c44f30041c1b48b4371e130fd4317
emulate_invalid_guest_state=0 -> works
emulate_invalid_guest_state=1 -> hangs

25391454e73e3156202264eb3c473825afe4bc94 broke
emulate_invalid_guest_state=0.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c1bc34.6020...@sp.consulting.lsexperts.de

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 17.06.2013 18:07, Paolo Bonzini wrote:
> Il 16/06/2013 02:25, Stefan Pietsch ha scritto:
>> Bisecting leads to
>>
>> git bisect bad 378a8b099fc207ddcb91b19a8c1457667e0af398
>> git bisect good 007a3b547512d69f67ceb9641796d64552bd337e
>> git bisect good 1f3141e80b149e7215313dff29e9a0c47811b1d1
>> git bisect good 286da4156dc65c8a054580fdd96b7709132dce8d
>> git bisect bad 25391454e73e3156202264eb3c473825afe4bc94
>> git bisect good 218e763f458c44f30041c1b48b4371e130fd4317
>>
>>
>> first bad commit: [25391454e73e3156202264eb3c473825afe4bc94]
>> KVM: VMX: don't clobber segment AR of unusable segments.
>>
>> 25391454e73e3156202264eb3c473825afe4bc94
>> emulate_invalid_guest_state=0 -> hangs and shows "KVM: entry failed"
>> emulate_invalid_guest_state=1 -> hangs
>>
>> Please note, I had to compile some revisions with
>> 3f0c3d0bb2bcc4b88b22452a7cf0073ee9a0f1e6 applied, caused by
>> 9ae9febae9500a0a6f5ce29ee4b8d942b5332529.
> 
> Can you please execute "info registers" and "x/10i $pc" from the QEMU
> monitor at the time of the hang, and include the output?  Using
> "-monitor stdio" or the new GTK+ interface can help.
> 
> Also, can you run under tracing (for information on how to do this, see
> http://www.linux-kvm.org/page/Tracing) and include the bottom of the log?

Tested with 25391454e73e3156202264eb3c473825afe4bc94
 emulate_invalid_guest_state=1


(qemu) info registers
EAX=00010286 EBX= ECX=c12c527c EDX=
ESI=00010286 EDI=c14c4744 EBP=c10161f5 ESP=de84df10
EIP=c1014a8d EFL=00010286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =007b   00c0f300 DPL=3 DS   [-WA]
CS =0060   00c09b00 DPL=0 CS32 [-RA]
SS =0068   00c09300 DPL=0 DS   [-WA]
DS =007b   00c0f300 DPL=3 DS   [-WA]
FS =  ffff 00f0ff00 DPL=3 CS64 [CRA]
GS =00e0 c1438b40 0018 00409100 DPL=0 DS   [--A]
LDT=  ffff 00f0ff00 DPL=3 CS64 [CRA]
TR =0080 c1400f00 206b 8b00 DPL=0 TSS32-busy
GDT= c13f6000 00ff
IDT= c13f5000 07ff
CR0=8005003b CR2= CR3=014bc000 CR4=0690
DR0= DR1= DR2=0007
DR3=
DR6=0ff0 DR7=0400
EFER=
FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80
FPR0=f44d002c6000 400d FPR1=80847fe7 400e
FPR2=fa007fa24000 400e FPR3=80e88055f000 400e
FPR4=ea61009c4000 400d FPR5=ea62009c4000 400c
FPR6=800bf600 4015 FPR7= 
XMM00=
XMM01=
XMM02=
XMM03=
XMM04=
XMM05=
XMM06=
XMM07=

(qemu) x/10i $pc
0xc1014a8d:  lea0x0(%esi),%esi
0xc1014a91:  ret
0xc1014a92:  cli
0xc1014a93:  nop
0xc1014a94:  lea0x0(%esi),%esi
0xc1014a98:  ret
0xc1014a99:  push   %eax
0xc1014a9a:  call   0xc1014a84
0xc1014a9f:  mov%eax,(%esp)
0xc1014aa2:  call   0xc1014a92


last 20 lines of the trace:
 qemu-system-x86-3575  [000]   542.279800: kvm_entry:vcpu 0
 qemu-system-x86-3575  [000]   542.279802: kvm_inj_virq: irq 48
 qemu-system-x86-3575  [000]   542.279802: kvm_entry:vcpu 0
 qemu-system-x86-3575  [000]   542.279803: kvm_inj_virq: irq 48
 qemu-system-x86-3575  [000]   542.279804: kvm_entry:vcpu 0
 qemu-system-x86-3575  [000]   542.279805: kvm_inj_virq: irq 48
 qemu-system-x86-3575  [000]   542.279806: kvm_entry:vcpu 0
 qemu-system-x86-3575  [000]   542.279807: kvm_inj_virq: irq 48
 qemu-system-x86-3575  [000]   542.279808: kvm_entry:vcpu 0
 qemu-system-x86-3575  [000]   542.279809: kvm_inj_virq: irq 48
 qemu-system-x86-3575  [000]   542.279810: kvm_entry:vcpu 0
 qemu-system-x86-3575  [000]   542.279811: kvm_inj_virq: irq 48
 qemu-system-x86-3575  [000]   542.279812: kvm_entry:vcpu 0
 qemu-system-x86-3573  [001]   542.280010: kvm_set_irq:  gsi 0
level 1 source 0
 qemu-system-x86-3573  [001]   542.280013: kvm_pic_set_irq:  chip 0
pin 0 (edge|masked)
 qemu-system-x86-3573  [001]   542.280015: kvm_apic_accept_irq:  apicid
0 vec 48 (LowPrio|edge) (coalesced)
 qemu-system-x86-3573  [001]   542.280015: kvm_ioapic_set_irq:   pin 2
dst 1 vec=48 (LowPrio|logical|edge) (coalesced)
 qemu-system-x86-3573  [001]   542.280016: kvm_set_irq:  gsi 0
level 0 source 0
 qemu-system-x86-3573  [001]   542.280017: kvm_pic_set_irq:  chip 0
pin 0 (edge|masked)
 qemu-system-x86-3573  [001]   542.280017: kvm_ioapic_set_irq:   pin 2
ds

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 13.06.2013 16:59, Stefan Pietsch wrote:
> On 13.06.2013 15:42, Paolo Bonzini wrote:
>> Il 13/06/2013 07:57, Stefan Pietsch ha scritto:
>>> git bisect tells me:
>>> 79fd50c67f91136add9726fb7719b57a66c6f763 is the first bad commit
>>
>> This is an s390 commit, so the bisect somehow went wrong.  Can you
>> confirm that 3.7 works and 3.8 doesn't?
> 
> Confirmed. Something went wrong.
> I replayed the bisect log and now I have
> 
> git bisect bad 9626357371b519f2b955fef399647181034a77fe
> git bisect good ef4e359d9b9e2dc022f79840fd207796b524a893
> git bisect good b5c78e04dd061b776978dad61dd85357081147b0
> git bisect good 9e2d59ad580d590134285f361a0e80f0e98c0207
> git bisect bad 69086a78bdc973ec0b722be790b146e84ba8a8c4
> git bisect good 9ecf9b085a0926e07c78c08a07296bbfd1c37d07
> git bisect bad 21fbd5809ad126b949206d78e0a0e07ec872ea11
> git bisect bad 79fd50c67f91136add9726fb7719b57a66c6f763
> git bisect bad aa11e3a8a6d9f92c3fe4b91a9aca5d8c23d55d4d
> git bisect good 66cdd0ceaf65a18996f561b770eedde1d123b019
> git bisect bad d99e415275dd3f757b75981adad8645cdc26da45
> 
> So please wait for my results.


Bisecting leads to

git bisect bad 378a8b099fc207ddcb91b19a8c1457667e0af398
git bisect good 007a3b547512d69f67ceb9641796d64552bd337e
git bisect good 1f3141e80b149e7215313dff29e9a0c47811b1d1
git bisect good 286da4156dc65c8a054580fdd96b7709132dce8d
git bisect bad 25391454e73e3156202264eb3c473825afe4bc94
git bisect good 218e763f458c44f30041c1b48b4371e130fd4317


first bad commit: [25391454e73e3156202264eb3c473825afe4bc94]
KVM: VMX: don't clobber segment AR of unusable segments.


25391454e73e3156202264eb3c473825afe4bc94
emulate_invalid_guest_state=0 -> hangs and shows "KVM: entry failed"
emulate_invalid_guest_state=1 -> hangs

Please note, I had to compile some revisions with
3f0c3d0bb2bcc4b88b22452a7cf0073ee9a0f1e6 applied, caused by
9ae9febae9500a0a6f5ce29ee4b8d942b5332529.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51bd05e0.5000...@sp.consulting.lsexperts.de

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 13.06.2013 15:42, Paolo Bonzini wrote:
> Il 13/06/2013 07:57, Stefan Pietsch ha scritto:
>> git bisect tells me:
>> 79fd50c67f91136add9726fb7719b57a66c6f763 is the first bad commit
> 
> This is an s390 commit, so the bisect somehow went wrong.  Can you
> confirm that 3.7 works and 3.8 doesn't?

Confirmed. Something went wrong.
I replayed the bisect log and now I have

git bisect bad 9626357371b519f2b955fef399647181034a77fe
git bisect good ef4e359d9b9e2dc022f79840fd207796b524a893
git bisect good b5c78e04dd061b776978dad61dd85357081147b0
git bisect good 9e2d59ad580d590134285f361a0e80f0e98c0207
git bisect bad 69086a78bdc973ec0b722be790b146e84ba8a8c4
git bisect good 9ecf9b085a0926e07c78c08a07296bbfd1c37d07
git bisect bad 21fbd5809ad126b949206d78e0a0e07ec872ea11
git bisect bad 79fd50c67f91136add9726fb7719b57a66c6f763
git bisect bad aa11e3a8a6d9f92c3fe4b91a9aca5d8c23d55d4d
git bisect good 66cdd0ceaf65a18996f561b770eedde1d123b019
git bisect bad d99e415275dd3f757b75981adad8645cdc26da45

So please wait for my results.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51b9de49.3070...@sp.consulting.lsexperts.de

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 09.06.2013 11:43, Gleb Natapov wrote:
> On Thu, Jun 06, 2013 at 02:10:39PM +0200, Stefan Pietsch wrote:
>> On 06.06.2013 13:40, Gleb Natapov wrote:
>>> On Thu, Jun 06, 2013 at 01:35:13PM +0200, Stefan Pietsch wrote:
>>
>>>> I had no success with the Debian kernel 3.10~rc4-1~exp1 (3.10-rc4-686-pae).
>>>>
>>>> The machine hangs after "Enabling APIC mode:  Flat.  Using 1 I/O APICs".
>>> OK, since it looks like it hangs during timer initialization can you try
>>> to disable kvmclock? Add -cpu qemu64,-kvmclock to your command line.
>>> Also can you provide the output of "cat /proc/cpuinfo" on your host? And
>>> complete serial output before hang.
>>
>>
>> command line:
>> qemu-system-i386 -machine accel=kvm -m 512 -cpu qemu64,-kvmclock -cdrom
>> grml32-full_2013.02.iso -serial file:ttyS0.log
>>
>>
>> ttyS0.log:
>> ##
>>
> 
> Nothing out of ordinary here. Since you can reproduce the hang and I
> cannot, can you try and bisect it? Also can trace kvm during the hang
> http://www.linux-kvm.org/page/Tracing? Start the trace as close to hang
> as possible and stop it as quick after it as possible too to make trace
> file smaller.


git bisect tells me:
79fd50c67f91136add9726fb7719b57a66c6f763 is the first bad commit


This is my bisect log:

git bisect start
git bisect bad 9626357371b519f2b955fef399647181034a77fe
git bisect good ef4e359d9b9e2dc022f79840fd207796b524a893
git bisect good b5c78e04dd061b776978dad61dd85357081147b0
git bisect good 9e2d59ad580d590134285f361a0e80f0e98c0207
git bisect bad 69086a78bdc973ec0b722be790b146e84ba8a8c4
git bisect good 9ecf9b085a0926e07c78c08a07296bbfd1c37d07
git bisect bad 21fbd5809ad126b949206d78e0a0e07ec872ea11
git bisect bad 79fd50c67f91136add9726fb7719b57a66c6f763
git bisect good 66cdd0ceaf65a18996f561b770eedde1d123b019


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51b9b3ae.2040...@sp.consulting.lsexperts.de

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 06.06.2013 13:40, Gleb Natapov wrote:
> On Thu, Jun 06, 2013 at 01:35:13PM +0200, Stefan Pietsch wrote:

>> I had no success with the Debian kernel 3.10~rc4-1~exp1 (3.10-rc4-686-pae).
>>
>> The machine hangs after "Enabling APIC mode:  Flat.  Using 1 I/O APICs".
> OK, since it looks like it hangs during timer initialization can you try
> to disable kvmclock? Add -cpu qemu64,-kvmclock to your command line.
> Also can you provide the output of "cat /proc/cpuinfo" on your host? And
> complete serial output before hang.


command line:
qemu-system-i386 -machine accel=kvm -m 512 -cpu qemu64,-kvmclock -cdrom
grml32-full_2013.02.iso -serial file:ttyS0.log



/proc/cpuinfo:
##

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 14
model name  : Intel(R) Core(TM) Duo CPU  L2400  @ 1.66GHz
stepping: 12
microcode   : 0x54
cpu MHz : 1000.000
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc
arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm dtherm
bogomips: 3325.02
clflush size: 64
cache_alignment : 64
address sizes   : 32 bits physical, 32 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 14
model name  : Intel(R) Core(TM) Duo CPU  L2400  @ 1.66GHz
stepping: 12
microcode   : 0x54
cpu MHz : 1000.000
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 1
cpu cores   : 2
apicid  : 1
initial apicid  : 1
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc
arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr pdcm dtherm
bogomips: 3325.02
clflush size: 64
cache_alignment : 64
address sizes   : 32 bits physical, 32 bits virtual
power management:



ttyS0.log:
##

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.7-1-grml-486 (t...@grml.org) (gcc version
4.7.2 (Debian 4.7.2-5) ) #1 Debian 3.7.9-1+grml.1
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff]
usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009]
reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f]
reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fffdfff]
usable
[0.00] BIOS-e820: [mem 0x1fffe000-0x1fff]
reserved
[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff]
reserved
[0.00] BIOS-e820: [mem 0xfffc-0x]
reserved
[0.00] Notice: NX (Execute Disable) protection cannot be
enabled: non-PAE kernel!
[0.00] SMBIOS 2.4 present.
[0.00] Hypervisor detected: KVM
[0.00] e820: last_pfn = 0x1fffe max_arch_pfn = 0x10
[0.00] PAT not supported by CPU.
[0.00] found SMP MP-table at [mem 0x000fdb00-0x000fdb0f] mapped
at [c00fdb00]
[0.00] init_memory_mapping: [mem 0x-0x1fffdfff]
[0.00] RAMDISK: [mem 0x1f33-0x1ffdbfff]
[0.00] ACPI: RSDP 000fd9a0 00014 (v00 BOCHS )
[0.00] ACPI: RSDT 1fffe4b0 00034 (v01 BOCHS  BXPCRSDT 0001
BXPC 0001)
[0.00] ACPI: FACP 1f80 00074 (v01 BOCHS  BXPCFACP 0001
BXPC 0001)
[0.00] ACPI: DSDT 1fffe4f0 011A9 (v01   BXPC   BXDSDT 0001
INTL 20100528)
[0.00] ACPI: FACS 1f40 00040
[0.00] ACPI: SSDT 1800 00735 (v01 BOCHS  BXPCSSDT 0001
BXPC 0001)
[0.00] ACPI: APIC 16e0 00078 (v01 BOCHS  BXPCAPIC 0001
BXPC 0001)
[0.00] ACPI: HPET 16a0 00038 (v01 BOCHS  BXPCHPET 0001
BXPC 0001)
[0.00] 0MB HIGHMEM available.
[0.00] 511MB LOWMEM available.
[0.00]   mapped low ram: 0 - 1fffe000
[0.00]   low ram: 0 - 1fffe000
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x0001-0x00ff]
[0.00]   Normal   [mem 0x0100-0x1fffdfff]
[0.00]   HighMem  empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0001-0x0009efff]
[0.00]   node   0: [mem 0x0010-0x1fffdfff]
[0.00] Using APIC driver 

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 06.06.2013 08:42, Gleb Natapov wrote:
> On Wed, Jun 05, 2013 at 02:51:19PM +0200, Stefan Pietsch wrote:
>> On 05.06.2013 14:10, Gleb Natapov wrote:
>>> On Wed, Jun 05, 2013 at 01:57:25PM +0200, Stefan Pietsch wrote:
>>>> On 19.05.2013 14:32, Gleb Natapov wrote:
>>>>> On Sun, May 19, 2013 at 02:00:31AM +0100, Ben Hutchings wrote:
>>>>>> Dear KVM maintainers, it appears that there is a gap in x86 emulation,
>>>>>> at least on a 32-bit host.  Stefan found this when running GRML, a live
>>>>>> distribution which can be downloaded from:
>>>>>> <http://download.grml.org/grml32-full_2013.02.iso>.  His original
>>>>>> reported is at <http://bugs.debian.org/707257>.
>>>>>>
>>>>> Can you verify with latest linux.git HEAD? It works for me there on
>>>>> 64bit. There were a lot of problems fixed in this area in 3.9/3.10 time 
>>>>> frame,
>>>>> so it would be helpful if you'll test 32bit before I install one myself.
>>>>
>>>>
>>>> Kernel version 3.9.4-1 (linux-image-3.9-1-686-pae) made things worse.
>>>>
>>>> The virtual machine tries to boot the kernel, but stops after a few
>>>> seconds and the kern.log shows:
>>> At what point does it stop?
>>
>>
>> The machine stops at:
>>
>> Performance Events: Broken PMU hardware detected, using software events
>> only.
>> Failed to access perfctr msr (MSR c1 is 0)
>> Enabling APIC mode:  Flat.  Using 1 I/O APICs
> Timer initialization is what comes next.
> 
> I tried 32bit kernel compiled from kvm.git "next" (3.10.0-rc2+) branch and 
> upstream
> qemu and I cannot reproduce the problem. The guest boots fine.


I had no success with the Debian kernel 3.10~rc4-1~exp1 (3.10-rc4-686-pae).

The machine hangs after "Enabling APIC mode:  Flat.  Using 1 I/O APICs".


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51b073f1.8030...@sp.consulting.lsexperts.de

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 05.06.2013 14:10, Gleb Natapov wrote:
> On Wed, Jun 05, 2013 at 01:57:25PM +0200, Stefan Pietsch wrote:
>> On 19.05.2013 14:32, Gleb Natapov wrote:
>>> On Sun, May 19, 2013 at 02:00:31AM +0100, Ben Hutchings wrote:
>>>> Dear KVM maintainers, it appears that there is a gap in x86 emulation,
>>>> at least on a 32-bit host.  Stefan found this when running GRML, a live
>>>> distribution which can be downloaded from:
>>>> <http://download.grml.org/grml32-full_2013.02.iso>.  His original
>>>> reported is at <http://bugs.debian.org/707257>.
>>>>
>>> Can you verify with latest linux.git HEAD? It works for me there on
>>> 64bit. There were a lot of problems fixed in this area in 3.9/3.10 time 
>>> frame,
>>> so it would be helpful if you'll test 32bit before I install one myself.
>>
>>
>> Kernel version 3.9.4-1 (linux-image-3.9-1-686-pae) made things worse.
>>
>> The virtual machine tries to boot the kernel, but stops after a few
>> seconds and the kern.log shows:
> At what point does it stop?


The machine stops at:

Performance Events: Broken PMU hardware detected, using software events
only.
Failed to access perfctr msr (MSR c1 is 0)
Enabling APIC mode:  Flat.  Using 1 I/O APICs


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51af3447.6090...@sp.consulting.lsexperts.de

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 19.05.2013 14:32, Gleb Natapov wrote:
> On Sun, May 19, 2013 at 02:00:31AM +0100, Ben Hutchings wrote:
>> Dear KVM maintainers, it appears that there is a gap in x86 emulation,
>> at least on a 32-bit host.  Stefan found this when running GRML, a live
>> distribution which can be downloaded from:
>> .  His original
>> reported is at .
>>
> Can you verify with latest linux.git HEAD? It works for me there on
> 64bit. There were a lot of problems fixed in this area in 3.9/3.10 time frame,
> so it would be helpful if you'll test 32bit before I install one myself.


Kernel version 3.9.4-1 (linux-image-3.9-1-686-pae) made things worse.

The virtual machine tries to boot the kernel, but stops after a few
seconds and the kern.log shows:

kernel: [13851.000412] kvm [7482]: vcpu0 disabled perfctr wrmsr: 0xc1
data 0x


virtual machine was started with:
qemu-system-i386 -machine accel=kvm -m 512 -cdrom grml32-full_2013.02.iso

qemu-system-x86: 1.5.0+dfsg-3


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51af27a5.5030...@sp.consulting.lsexperts.de

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 19.05.2013 14:32, Gleb Natapov wrote:
> On Sun, May 19, 2013 at 02:00:31AM +0100, Ben Hutchings wrote:
>> Dear KVM maintainers, it appears that there is a gap in x86 emulation,
>> at least on a 32-bit host.  Stefan found this when running GRML, a live
>> distribution which can be downloaded from:
>> .  His original
>> reported is at .
>>
> Can you verify with latest linux.git HEAD? It works for me there on
> 64bit. There were a lot of problems fixed in this area in 3.9/3.10 time frame,
> so it would be helpful if you'll test 32bit before I install one myself.


Ben,

can you provide a 3.9 series kernel package?

Thanks.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51a61953.4050...@sp.consulting.lsexperts.de

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 09.05.2013 20:56, Stefan Pietsch wrote:
> On 09.05.2013 03:08, Ben Hutchings wrote:
> 
>> Please could you test some of the intermediate versions at
>> <http://snapshot.debian.org/package/linux/> to find the first upstream
>> version where this was broken.
> 
> The first version which does not work is 3.6.4-1~experimental.1.
> 3.5.5-1~experimental.1 works.


I was able to start KVM under kernel version 3.8.12-1 after loading the
"kvm_intel" module with the option "emulate_invalid_guest_state=0".


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5194c254.4000...@sp.consulting.lsexperts.de

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

On 09.05.2013 03:08, Ben Hutchings wrote:

> Please could you test some of the intermediate versions at
>  to find the first upstream
> version where this was broken.

The first version which does not work is 3.6.4-1~experimental.1.
3.5.5-1~experimental.1 works.


Regards,
Stefan


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518bf14e.3070...@sp.consulting.lsexperts.de

Bug#707257: linux-image-3.8-1-686-pae: KVM crashes with "entry failed, hardware error 0x80000021"

[Stefan Pietsch]

Package: linux-image-3.8-1-686-pae
Version: 3.8.11-1


KVM fails with the unstable kernel 3.8.11-1.


#

kvm -m 512 -cdrom grml32-full_2013.02.iso

KVM: entry failed, hardware error 0x8021

If you're running a guest on an Intel machine without unrestricted mode
support, the failure can be most likely due to the guest entering an invalid
state for Intel VT. For example, the guest maybe running in big real mode
which is not supported on less recent Intel processors.

EAX= EBX=0001 ECX=f000 EDX=f000
ESI=00195e78 EDI= EBP=de84c000 ESP=de84df64
EIP=c101611c EFL=00010246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =007b   00c0f300 DPL=3 DS   [-WA]
CS =0060   00c09b00 DPL=0 CS32 [-RA]
SS =0068   00c09300 DPL=0 DS   [-WA]
DS =007b   00c0f300 DPL=3 DS   [-WA]
FS =  ffff 00f0ff00 DPL=3 CS64 [CRA]
GS =00e0 c1438b40 0018 00409100 DPL=0 DS   [--A]
LDT=  ffff 00f0ff00 DPL=3 CS64 [CRA]
TR =0080 c1400f00 206b 8b00 DPL=0 TSS32-busy
GDT= c13f6000 00ff
IDT= c13f5000 07ff
CR0=8005003b CR2= CR3=014bc000 CR4=0690
DR0= DR1= DR2=0007
DR3=
DR6=0ff0 DR7=0400
EFER=
Code=ff ff 89 10 c3 8b 15 c4 83 40 c1 8d 84 10 00 c0 ff ff 8b 00  eb
02 f3 90 8b 10 85 d2 74 f8 c3 3d fe 00 00 00 0f 9e c0 0f b6 c0 c3 8b 15
64 7b 40 c1

#


Host CPU: Intel(R) Core(TM) Duo CPU  L2400  @ 1.66GHz
QEMU KVM Package: qemu-kvm 1.1.2+dfsg-6

Running KVM works on this host with the kernel package
linux-image-3.2.0-4-686-pae 3.2.41-2.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/518a7323.7000...@sp.consulting.lsexperts.de