Re: Kernel Oops with kvm 66 running WinXP

Izik Eidus
2008-05-05T07:01:56Z

> Izik Eidus wrote:
>> Michal Ludvig wrote:
>>
>>> Avi Kivity wrote:
>>>
>>>> Avi Kivity wrote:
>>>>
>>>>> Michal Ludvig wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I've experienced a kernel Oops on 2.6.24 with kvm 66 on AMD in
>>>>>> 64bit mode while starting up WinXP:
>>>>>>
>>>>>> The host is still alive but the XP guest is locked up in a boot
>>>>>> screen.
>>>>>>
>>> Hi again, just wanted to let you know that I still get this Oops with
>>> kvm-68. It comes a bit later, not during the boot but after the XP
>>> desktop comes up. As there were some changes in kernel/x86_emulate.c
>>> the patch you provided for kvm-66 can't be applied anymore.
>>>
>>> loaded kvm module (kvm-68)
>>> kvm: emulating exchange as write
>>> Unable to handle kernel NULL pointer dereference at 0000000000000000
>>> RIP:
>>> [<ffffffff88373b4a>] :kvm:x86_emulate_insn+0x3fa/0x4240
>>> PGD 3145e067 PUD 409b9067 PMD 0
>>> Oops: 0002 [1] SMP
>>> CPU 0
>>> Modules linked in: kvm_amd kvm reiserfs tun bridge llc nfsd lockd
>>> nfs_acl auth_rpcgss sunrpc exportfs iptable_filter ip_tables autofs4
>>> snd_pcm_oss snd_mixer_oss w83627ehf snd_seq snd_seq_device hwmon_vid
>>> ip6table_filter ip6_tables x_tables af_packet ipv6 fuse ext2 loop
>>> snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc sr_mod
>>> k8temp hwmon i2c_nforce2 button i2c_core cdrom forcedeth sg floppy
>>> linear ehci_hcd ohci_hcd sd_mod usbcore dm_snapshot edd dm_mod fan
>>> sata_nv pata_amd libata scsi_mod thermal processor
>>> Pid: 14776, comm: qemu-system-x86 Not tainted 2.6.24-mludvig #1
>>> RIP: 0010:[<ffffffff88373b4a>] [<ffffffff88373b4a>]
>>> :kvm:x86_emulate_insn+0x3fa/0x4240
>>> RSP: 0018:ffff81007d52fc18 EFLAGS: 00010246
>>> RAX: 000000008001003b RBX: 0000000000000000 RCX: 0000000000000000
>>> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff810079c5c000
>>> RBP: ffff810079c5d320 R08: ffff810079c5d3c0 R09: 0000000000000006
>>> R10: 0000000000000002 R11: 0000000000000000 R12: ffff810079c5d368
>>> R13: ffff810079c5d3c0 R14: ffffffff8838ab20 R15: 00000000019d1353
>>> FS: 0000000040800950(0063) GS:ffffffff8053e000(0000)
>>> knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>> CR2: 0000000000000000 CR3: 000000007985a000 CR4: 00000000000006e0
>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>> Process qemu-system-x86 (pid: 14776, threadinfo ffff81007d52e000,
>>> task ffff81003f4e6780)
>>> Stack: 000000007d52fc74 0000000011fda618 000000000f399068
>>> ffff810079c5d3c0
>>> ffff81007d52fc94 ffffffff88368ae0 0000000000000000 ffff810079c5c000
>>> ffff810079c5d320 0000000000000000 0000000000000000 0000000000000000
>>> Call Trace:
>>> [<ffffffff88368ae0>] :kvm:seg_desct_to_kvm_desct+0x40/0xb0
>>>
>>
>> ok, if we are here it mean windows did task switch,
>> and if windows did task switch it mean something was probably wrong
>> before.
>>
>>
>
> We need to fix the oops regardless.
>
>
i know..., it was just an hint...

--
woof.