[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <46CCCF51.8070709@vmware.com>
Date: Wed, 22 Aug 2007 17:05:37 -0700
From: Zachary Amsden <zach@...are.com>
To: Parag Warudkar <parag.warudkar@...il.com>
CC: linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
rusty@...tcorp.com.au, Chris Wright <chrisw@...s-sol.org>,
Andi Kleen <ak@...e.de>
Subject: Re: 2.6.23-rc3 - CONFIG_VMI broken
Parag Warudkar wrote:
> CONFIG_VMI seems to be broken, but I am not sure when - the last
> kernel I was running was 2.6.22-rc4 which used to boot fine and use
> VMI. Current git with same configuration causes the kernel to reboot
> early. Logs below.
>
> Deselecting CONFIG_VMI and rebuilding allows the kernel to boot normally.
>
> (I am running it on VMWare workstation 6 latest release.)
>
> Thanks
>
> Parag
>
> Linux version 2.6.23-rc3 (root@...ntu) (gcc version 4.1.2 (Ubuntu
> 4.1.2-0ubuntu4)) #4 Mon Aug 13 21:50:06 EDT 2007
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
> BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000ca000 - 00000000000cc000 (reserved)
> BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000001fef0000 (usable)
> BIOS-e820: 000000001fef0000 - 000000001feff000 (ACPI data)
> BIOS-e820: 000000001feff000 - 000000001ff00000 (ACPI NVS)
> BIOS-e820: 000000001ff00000 - 0000000020000000 (usable)
> BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> BIOS-e820: 00000000fffe0000 - 0000000100000000 (reserved)
> console [earlyser0] enabled
> 0MB HIGHMEM available.
> 512MB LOWMEM available.
> found SMP MP-table at 000f6c90
> VMI: Found VMware, Inc. Hypervisor OPROM, API version 3.0, ROM version 1.0
> Reserving virtual address space above 0xfc000000
> Int 14: CR2 fc37e260 err 00000000 EIP fc37e260 CS 00000062 flags 00010006
> Stack: c0490ec7 c04913cb 00000001 00000000 fc001340 c047fff4 c04a6080 c047aa00
>
I reproduced this, slightly different EIP, but I notice that all
paravirt-ops function calls are to bogus addresses; the first byte
appears correct (0xfc00XXXX is in the VMI ROM range), and the extracted
function addresses in the paravirt_ops struct are correct. However, it
looks like the patching of the call instructions went wrong. Does this
sound familiar to anyone?
In any case, I think the bug is already fixed.
Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists