LinuxLists.cc - 2.6.0-test9-mm4 (only) and vmware

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

On Wednesday, 19 November 2003, at 18:15:18 -0300,
Gerardo Exequiel Pozzi wrote:

> With the recent 2.6.0-test9-mm4 i can't start the vmware, it reports in vmware.log (debug ON):
>
I can confirm the problem here also with 2.6.0-test9-mm4, while
everything worked fine with 2.6.0-test9-mm3 with the same config.

I also realized while doing some basic tests that module "vmmon" was
unable to unload gracefully, and "has" to be forced to do so.

I can try to gather some more info when I come back from sleep + work.

PS: just in case it can help, VMware 4.0.1 5289 "patched" with (if I
recall correctly):
http://ftp.cvut.cz/vmware/vmware-any-any-update43.tar.gz

PS2: trying to "recompile" vmmon and vmnet again and starting VMware,
when tried to boot some guest OS I got the following in the logs:

kernel BUG at mm/memory.c:793!
invalid operand: 0000 [#5]
CPU: 0
EIP: 0060:[<c01425c7>] Tainted: PF VLI
EFLAGS: 00013212
EIP is at get_user_pages+0xe7/0x300
eax: 00001000 ebx: 406a0000 ecx: 00000000 edx: de7452c0
esi: d5966ec0 edi: 00000001 ebp: df8be940 esp: d052bcec
ds: 007b es: 007b ss: 0068
Process vmware-vmx (pid: 11300, threadinfo=d052a000 task=d9634cc0)
Stack: df8be940 d5966ec0 406a0000 00000001 00000002 00000000 00000000 d052a000
d052bd64 000406a0 d052bd44 e0b5012e d9634cc0 df8be940 406a0000 00000001
00000001 00000000 d052bd64 00000000 00000000 406a0000 d052bd74 e0b501a9
Call Trace:
[<e0b5012e>] HostIFGetUserPage+0x3a/0x66 [vmmon]
[<e0b501a9>] HostIF_LockPage+0x4f/0x2a2 [vmmon]
[<e0b52061>] Vmx86_LockPage+0x63/0xe0 [vmmon]
[<e0b4ddb8>] __LinuxDriver_Ioctl+0x2f0/0x978 [vmmon]
[<c013bcc8>] read_pages+0x1c8/0x1e0
[<c018b460>] ext3_get_block+0x0/0xa0
[<c013978f>] __alloc_pages+0xaf/0x350
[<c013bf1e>] do_page_cache_readahead+0xbe/0x110
[<c013964f>] buffered_rmqueue+0xaf/0x140
[<c013978f>] __alloc_pages+0xaf/0x350
[<e0b4d37c>] LinuxDriver_Open+0x7c/0x9e [vmmon]
[<c0139a4f>] __get_free_pages+0x1f/0x50
[<e0b5090d>] HostIF_AllocPage+0x11/0x32 [vmmon]
[<e0b4d711>] LinuxDriverAllocLowMem+0x57/0xca [vmmon]
[<c014494a>] __vma_link+0x3a/0xa0
[<e0b4e4e5>] LinuxDriver_IoctlV4+0x4d/0xd2 [vmmon]
[<c014524a>] do_mmap_pgoff+0x41a/0x6f0
[<e0b4ee73>] LinuxDriver_Ioctl+0x131/0x1b8 [vmmon]
[<c0162b85>] sys_ioctl+0xb5/0x230
[<c0150770>] sys_close+0x50/0x60
[<c02ad977>] syscall_call+0x7/0xb

Code: 00 85 c0 74 4b 85 c0 7e 2c 83 f8 01 75 0c 8b 44 24 30 ff 80 d8 01 00 00 eb bd 83 f8 02 75 0c 8b 54 24 30 ff 82 dc 01 00 00 eb ac <0f> 0b 19 03 d1 b6 2c c0 eb a2 40 75 f3 8b 5c 24 18 b8 f4 ff ff

Greetings.

--
Jose Luis Domingo Lopez
Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test9-mm4)

2003-11-20 01:02:05

by Andrew Morton

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

Jose Luis Domingo Lopez <[email protected]> wrote:
>
> PS2: trying to "recompile" vmmon and vmnet again and starting VMware,
> when tried to boot some guest OS I got the following in the logs:
>
> kernel BUG at mm/memory.c:793!

err, this is due to pagefault-accounting-fix.patch. Looks like vmware has
its own pagefault handler and Bill didn't update vmware ;)

Bill, can we take those BUGs out of there and just do some sane default
thing?

2003-11-20 01:07:32

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

2003-11-20 01:12:36

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

Jose Luis Domingo Lopez <[email protected]> wrote:
>> PS2: trying to "recompile" vmmon and vmnet again and starting VMware,
>> when tried to boot some guest OS I got the following in the logs:
>> kernel BUG at mm/memory.c:793!

On Wed, Nov 19, 2003 at 05:02:33PM -0800, Andrew Morton wrote:
> err, this is due to pagefault-accounting-fix.patch. Looks like vmware has
> its own pagefault handler and Bill didn't update vmware ;)
> Bill, can we take those BUGs out of there and just do some sane default
> thing?

Here it is.

-- wli

diff -prauN mm4-2.6.0-test9-1/arch/i386/mm/fault.c mm4-2.6.0-test9-default-1/arch/i386/mm/fault.c
--- mm4-2.6.0-test9-1/arch/i386/mm/fault.c 2003-11-19 00:07:03.000000000 -0800
+++ mm4-2.6.0-test9-default-1/arch/i386/mm/fault.c 2003-11-19 17:07:44.000000000 -0800
@@ -343,9 +343,6 @@ good_area:
* the fault.
*/
switch (handle_mm_fault(mm, vma, address, write)) {
- case VM_FAULT_MINOR:
- tsk->min_flt++;
- break;
case VM_FAULT_MAJOR:
tsk->maj_flt++;
break;
@@ -353,8 +350,10 @@ good_area:
goto do_sigbus;
case VM_FAULT_OOM:
goto out_of_memory;
+ case VM_FAULT_MINOR:
default:
- BUG();
+ tsk->min_flt++;
+ break;
}

/*
diff -prauN mm4-2.6.0-test9-1/mm/memory.c mm4-2.6.0-test9-default-1/mm/memory.c
--- mm4-2.6.0-test9-1/mm/memory.c 2003-11-19 00:07:15.000000000 -0800
+++ mm4-2.6.0-test9-default-1/mm/memory.c 2003-11-19 17:07:56.000000000 -0800
@@ -779,9 +779,6 @@ int get_user_pages(struct task_struct *t
while (!(map = follow_page(mm, start, write))) {
spin_unlock(&mm->page_table_lock);
switch (handle_mm_fault(mm,vma,start,write)) {
- case VM_FAULT_MINOR:
- tsk->min_flt++;
- break;
case VM_FAULT_MAJOR:
tsk->maj_flt++;
break;
@@ -789,8 +786,10 @@ int get_user_pages(struct task_struct *t
return i ? i : -EFAULT;
case VM_FAULT_OOM:
return i ? i : -ENOMEM;
+ case VM_FAULT_MINOR:
default:
- BUG();
+ tsk->min_flt++;
+ break;
}
spin_lock(&mm->page_table_lock);
}

2003-11-20 01:41:22

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

On Wed, Nov 19, 2003 at 06:15:18PM -0300, Gerardo Exequiel Pozzi wrote:
> Hi Andrew,
>
> With the recent 2.6.0-test9-mm4 i can't start the vmware, it reports in vmware.log (debug ON):
>
> Nov 19 17:27:40: vmx| WSSCAN: Not enough physical memory: req=49152 avail=0 over
> head=4096 maxRespage=106496
> Nov 19 17:27:40: vmx| WSSCAN: Not enough physical (in MB): nbVM=3 hostMem=512 ch
> eckMemory=1

Can you send me a few more lines of the log file before and after that message? I can take
a look at what is going on there. Most likely vmmon driver get confused.

>
> With linus tree from 2.6.0-test9-mm4/broken-out/linus.patch and 2.6.0-test3-mm3 don't have problem.
>

Chris

2003-11-20 01:47:27

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

On Wed, Nov 19, 2003 at 05:34:25PM -0500, Christopher Li wrote:
> Can you send me a few more lines of the log file before and after that message? I can take
> a look at what is going on there. Most likely vmmon driver get confused.

You should have a vm_ops->nopage() method that didn't get updated.
The formerly-unused argument got turned into a status return pointer,
so you need to do something like:

struct page *vmmon_nopage(struct vm_area_struct *vma, unsigned long addr, int *type)
{
...
if (type)
*type = VM_FAULT_MINOR;
return page;
}

It should also give off a big fat warning about initialization from
incompatible pointer types when compiled.

-- wli

2003-11-20 01:52:48

by Andrew Morton

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

William Lee Irwin III <[email protected]> wrote:
>
> > Bill, can we take those BUGs out of there and just do some sane default
> > thing?
>
> Here it is.

All the world's an x86 ;)

This whole patch is getting rather large.

ARM is doing weird stuff.

arch/alpha/mm/fault.c | 7 +++----
arch/arm26/mm/fault.c | 9 ++++++---
arch/cris/mm/fault.c | 9 +++++----
arch/h8300/mm/fault.c | 0
arch/i386/mm/fault.c | 7 +++----
arch/ia64/mm/fault.c | 3 +--
arch/m68k/mm/fault.c | 9 +++++----
arch/m68knommu/mm/fault.c | 0
arch/mips/mm/fault.c | 3 +--
arch/parisc/mm/fault.c | 9 +++++----
arch/ppc/mm/fault.c | 3 +--
arch/ppc64/mm/fault.c | 4 +---
arch/s390/mm/fault.c | 3 +--
arch/sh/mm/fault.c | 9 +++++----
arch/sparc/mm/fault.c | 9 +++++----
arch/sparc64/mm/fault.c | 9 +++++----
arch/x86_64/mm/fault.c | 9 +++++----
mm/memory.c | 7 +++----
18 files changed, 55 insertions(+), 54 deletions(-)

diff -puN arch/i386/mm/fault.c~pagefault-accounting-fix-fix-fix arch/i386/mm/fault.c
--- 25/arch/i386/mm/fault.c~pagefault-accounting-fix-fix-fix 2003-11-19 17:48:24.000000000 -0800
+++ 25-akpm/arch/i386/mm/fault.c 2003-11-19 17:48:24.000000000 -0800
@@ -316,9 +316,6 @@ good_area:
* the fault.
*/
switch (handle_mm_fault(mm, vma, address, write)) {
- case VM_FAULT_MINOR:
- tsk->min_flt++;
- break;
case VM_FAULT_MAJOR:
tsk->maj_flt++;
break;
@@ -326,8 +323,10 @@ good_area:
goto do_sigbus;
case VM_FAULT_OOM:
goto out_of_memory;
+ case VM_FAULT_MINOR:
default:
- BUG();
+ tsk->min_flt++;
+ break;
}

/*
diff -puN mm/memory.c~pagefault-accounting-fix-fix-fix mm/memory.c
--- 25/mm/memory.c~pagefault-accounting-fix-fix-fix 2003-11-19 17:48:24.000000000 -0800
+++ 25-akpm/mm/memory.c 2003-11-19 17:48:24.000000000 -0800
@@ -772,9 +772,6 @@ int get_user_pages(struct task_struct *t
while (!(map = follow_page(mm, start, write))) {
spin_unlock(&mm->page_table_lock);
switch (handle_mm_fault(mm,vma,start,write)) {
- case VM_FAULT_MINOR:
- tsk->min_flt++;
- break;
case VM_FAULT_MAJOR:
tsk->maj_flt++;
break;
@@ -782,8 +779,10 @@ int get_user_pages(struct task_struct *t
return i ? i : -EFAULT;
case VM_FAULT_OOM:
return i ? i : -ENOMEM;
+ case VM_FAULT_MINOR:
default:
- BUG();
+ tsk->min_flt++;
+ break;
}
spin_lock(&mm->page_table_lock);
}
diff -puN arch/alpha/mm/fault.c~pagefault-accounting-fix-fix-fix arch/alpha/mm/fault.c
--- 25/arch/alpha/mm/fault.c~pagefault-accounting-fix-fix-fix 2003-11-19 17:48:45.000000000 -0800
+++ 25-akpm/arch/alpha/mm/fault.c 2003-11-19 17:49:32.000000000 -0800
@@ -152,9 +152,6 @@ do_page_fault(unsigned long address, uns
up_read(&mm->mmap_sem);

switch (fault) {
- case VM_FAULT_MINOR:
- current->min_flt++;
- break;
case VM_FAULT_MAJOR:
current->maj_flt++;
break;
@@ -162,8 +159,10 @@ do_page_fault(unsigned long address, uns
goto do_sigbus;
case VM_FAULT_OOM:
goto out_of_memory;
+ case VM_FAULT_MINOR:
default:
- BUG();
+ current->min_flt++;
+ break;
}
return;

diff -puN arch/arm26/mm/fault.c~pagefault-accounting-fix-fix-fix arch/arm26/mm/fault.c
--- 25/arch/arm26/mm/fault.c~pagefault-accounting-fix-fix-fix 2003-11-19 17:48:45.000000000 -0800
+++ 25-akpm/arch/arm26/mm/fault.c 2003-11-19 17:52:34.000000000 -0800
@@ -176,13 +176,16 @@ survive:
* Handle the "normal" cases first - successful and sigbus
*/
switch (fault) {
- case 2:
+ case VM_FAULT_MAJOR:
+ default:
tsk->maj_flt++;
return fault;
- case 1:
+ case VM_FAULT_MINOR:
tsk->min_flt++;
- case 0:
+ case VM_FAULT_SIGBUS:
return fault;
+ case VM_FAULT_OOM:
+ break;
}

fault = -3; /* out of memory */
diff -puN arch/cris/mm/fault.c~pagefault-accounting-fix-fix-fix arch/cris/mm/fault.c
--- 25/arch/cris/mm/fault.c~pagefault-accounting-fix-fix-fix 2003-11-19 17:48:45.000000000 -0800
+++ 25-akpm/arch/cris/mm/fault.c 2003-11-19 17:53:15.000000000 -0800
@@ -229,15 +229,16 @@ do_page_fault(unsigned long address, str
*/

switch (handle_mm_fault(mm, vma, address, writeaccess)) {
- case 1:
+ case VM_FAULT_MINOR:
+ default:
tsk->min_flt++;
break;
- case 2:
+ case VM_FAULT_MAJOR:
tsk->maj_flt++;
break;
- case 0:
+ case VM_FAULT_SIGBUS:
goto do_sigbus;
- default:
+ case VM_FAULT_OOM:
goto out_of_memory;
}

diff -puN arch/h8300/mm/fault.c~pagefault-accounting-fix-fix-fix arch/h8300/mm/fault.c
diff -puN arch/ia64/mm/fault.c~pagefault-accounting-fix-fix-fix arch/ia64/mm/fault.c
--- 25/arch/ia64/mm/fault.c~pagefault-accounting-fix-fix-fix 2003-11-19 17:48:45.000000000 -0800
+++ 25-akpm/arch/ia64/mm/fault.c 2003-11-19 17:53:34.000000000 -0800
@@ -136,6 +136,7 @@ ia64_do_page_fault (unsigned long addres
*/
switch (handle_mm_fault(mm, vma, address, (mask & VM_WRITE) != 0)) {
case VM_FAULT_MINOR:
+ default:
++current->min_flt;
break;
case VM_FAULT_MAJOR:
@@ -151,8 +152,6 @@ ia64_do_page_fault (unsigned long addres
goto bad_area;
case VM_FAULT_OOM:
goto out_of_memory;
- default:
- BUG();
}
up_read(&mm->mmap_sem);
return;
diff -puN arch/m68k/mm/fault.c~pagefault-accounting-fix-fix-fix arch/m68k/mm/fault.c
--- 25/arch/m68k/mm/fault.c~pagefault-accounting-fix-fix-fix 2003-11-19 17:48:45.000000000 -0800
+++ 25-akpm/arch/m68k/mm/fault.c 2003-11-19 17:54:09.000000000 -0800
@@ -160,15 +160,16 @@ good_area:
printk("handle_mm_fault returns %d\n",fault);
#endif
switch (fault) {
- case 1:
+ case VM_FAULT_MINOR:
+ default:
current->min_flt++;
break;
- case 2:
+ case VM_FAULT_MAJOR:
current->maj_flt++;
break;
- case 0:
+ case VM_FAULT_SIGBUS:
goto bus_err;
- default:
+ case VM_FAULT_OOM:
goto out_of_memory;
}

diff -puN arch/m68knommu/mm/fault.c~pagefault-accounting-fix-fix-fix arch/m68knommu/mm/fault.c
diff -puN arch/mips/mm/fault.c~pagefault-accounting-fix-fix-fix arch/mips/mm/fault.c
--- 25/arch/mips/mm/fault.c~pagefault-accounting-fix-fix-fix 2003-11-19 17:48:45.000000000 -0800
+++ 25-akpm/arch/mips/mm/fault.c 2003-11-19 17:54:19.000000000 -0800
@@ -111,6 +111,7 @@ survive:
*/
switch (handle_mm_fault(mm, vma, address, write)) {
case VM_FAULT_MINOR:
+ default:
tsk->min_flt++;
break;
case VM_FAULT_MAJOR:
@@ -120,8 +121,6 @@ survive:
goto do_sigbus;
case VM_FAULT_OOM:
goto out_of_memory;
- default:
- BUG();
}

up_read(&mm->mmap_sem);
diff -puN arch/parisc/mm/fault.c~pagefault-accounting-fix-fix-fix arch/parisc/mm/fault.c
--- 25/arch/parisc/mm/fault.c~pagefault-accounting-fix-fix-fix 2003-11-19 17:48:45.000000000 -0800
+++ 25-akpm/arch/parisc/mm/fault.c 2003-11-19 17:54:56.000000000 -0800
@@ -175,20 +175,21 @@ good_area:
*/

switch (handle_mm_fault(mm, vma, address, (acc_type & VM_WRITE) != 0)) {
- case 1:
+ case VM_FAULT_MINOR:
+ default:
++current->min_flt;
break;
- case 2:
+ case VM_FAULT_MAJOR:
++current->maj_flt;
break;
- case 0:
+ case VM_FAULT_SIGBUS:
/*
* We ran out of memory, or some other thing happened
* to us that made us unable to handle the page fault
* gracefully.
*/
goto bad_area;
- default:
+ case VM_FAULT_OOM:
goto out_of_memory;
}
up_read(&mm->mmap_sem);
diff -puN arch/ppc64/mm/fault.c~pagefault-accounting-fix-fix-fix arch/ppc64/mm/fault.c
--- 25/arch/ppc64/mm/fault.c~pagefault-accounting-fix-fix-fix 2003-11-19 17:48:45.000000000 -0800
+++ 25-akpm/arch/ppc64/mm/fault.c 2003-11-19 17:55:04.000000000 -0800
@@ -122,8 +122,8 @@ good_area:
* the fault.
*/
switch (handle_mm_fault(mm, vma, address, is_write)) {
-
case VM_FAULT_MINOR:
+ default:
current->min_flt++;
break;
case VM_FAULT_MAJOR:
@@ -133,8 +133,6 @@ good_area:
goto do_sigbus;
case VM_FAULT_OOM:
goto out_of_memory;
- default:
- BUG();
}

up_read(&mm->mmap_sem);
diff -puN arch/ppc/mm/fault.c~pagefault-accounting-fix-fix-fix arch/ppc/mm/fault.c
--- 25/arch/ppc/mm/fault.c~pagefault-accounting-fix-fix-fix 2003-11-19 17:48:45.000000000 -0800
+++ 25-akpm/arch/ppc/mm/fault.c 2003-11-19 17:55:13.000000000 -0800
@@ -257,6 +257,7 @@ good_area:
survive:
switch (handle_mm_fault(mm, vma, address, is_write)) {
case VM_FAULT_MINOR:
+ default:
current->min_flt++;
break;
case VM_FAULT_MAJOR:
@@ -266,8 +267,6 @@ good_area:
goto do_sigbus;
case VM_FAULT_OOM:
goto out_of_memory;
- default:
- BUG();
}

up_read(&mm->mmap_sem);
diff -puN arch/s390/mm/fault.c~pagefault-accounting-fix-fix-fix arch/s390/mm/fault.c
--- 25/arch/s390/mm/fault.c~pagefault-accounting-fix-fix-fix 2003-11-19 17:48:45.000000000 -0800
+++ 25-akpm/arch/s390/mm/fault.c 2003-11-19 17:55:21.000000000 -0800
@@ -247,6 +247,7 @@ survive:
*/
switch (handle_mm_fault(mm, vma, address, error_code == 4)) {
case VM_FAULT_MINOR:
+ default:
tsk->min_flt++;
break;
case VM_FAULT_MAJOR:
@@ -256,8 +257,6 @@ survive:
goto do_sigbus;
case VM_FAULT_OOM:
goto out_of_memory;
- default:
- BUG();
}

up_read(&mm->mmap_sem);
diff -puN arch/sh/mm/fault.c~pagefault-accounting-fix-fix-fix arch/sh/mm/fault.c
--- 25/arch/sh/mm/fault.c~pagefault-accounting-fix-fix-fix 2003-11-19 17:48:45.000000000 -0800
+++ 25-akpm/arch/sh/mm/fault.c 2003-11-19 17:55:51.000000000 -0800
@@ -95,15 +95,16 @@ good_area:
*/
survive:
switch (handle_mm_fault(mm, vma, address, writeaccess)) {
- case 1:
+ case VM_FAULT_MINOR:
+ default:
tsk->min_flt++;
break;
- case 2:
+ case VM_FAULT_MAJOR:
tsk->maj_flt++;
break;
- case 0:
+ case VM_FAULT_SIGBUS:
goto do_sigbus;
- default:
+ case VM_FAULT_OOM:
goto out_of_memory;
}

diff -puN arch/sparc64/mm/fault.c~pagefault-accounting-fix-fix-fix arch/sparc64/mm/fault.c
--- 25/arch/sparc64/mm/fault.c~pagefault-accounting-fix-fix-fix 2003-11-19 17:48:46.000000000 -0800
+++ 25-akpm/arch/sparc64/mm/fault.c 2003-11-19 17:56:18.000000000 -0800
@@ -419,15 +419,16 @@ good_area:
}

switch (handle_mm_fault(mm, vma, address, (fault_code & FAULT_CODE_WRITE))) {
- case 1:
+ case VM_FAULT_MINOR:
+ default:
current->min_flt++;
break;
- case 2:
+ case VM_FAULT_MAJOR:
current->maj_flt++;
break;
- case 0:
+ case VM_FAULT_SIGBUS:
goto do_sigbus;
- default:
+ case VM_FAULT_OOM:
goto out_of_memory;
}

diff -puN arch/sparc/mm/fault.c~pagefault-accounting-fix-fix-fix arch/sparc/mm/fault.c
--- 25/arch/sparc/mm/fault.c~pagefault-accounting-fix-fix-fix 2003-11-19 17:48:46.000000000 -0800
+++ 25-akpm/arch/sparc/mm/fault.c 2003-11-19 17:56:40.000000000 -0800
@@ -276,15 +276,16 @@ good_area:
* the fault.
*/
switch (handle_mm_fault(mm, vma, address, write)) {
- case 1:
+ case VM_FAULT_MINOR:
+ default:
current->min_flt++;
break;
- case 2:
+ case VM_FAULT_MAJOR:
current->maj_flt++;
break;
- case 0:
+ case VM_FAULT_SIGBUS:
goto do_sigbus;
- default:
+ case VM_FAULT_OOM:
goto out_of_memory;
}
up_read(&mm->mmap_sem);
diff -puN arch/x86_64/mm/fault.c~pagefault-accounting-fix-fix-fix arch/x86_64/mm/fault.c
--- 25/arch/x86_64/mm/fault.c~pagefault-accounting-fix-fix-fix 2003-11-19 17:48:46.000000000 -0800
+++ 25-akpm/arch/x86_64/mm/fault.c 2003-11-19 17:57:08.000000000 -0800
@@ -289,15 +289,16 @@ good_area:
* the fault.
*/
switch (handle_mm_fault(mm, vma, address, write)) {
- case 1:
+ case VM_FAULT_MINOR:
+ default:
tsk->min_flt++;
break;
- case 2:
+ case VM_FAULT_MAJOR:
tsk->maj_flt++;
break;
- case 0:
+ case VM_FAULT_SIGBUS:
goto do_sigbus;
- default:
+ case VM_FAULT_OOM:
goto out_of_memory;
}

_

2003-11-20 02:13:06

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

William Lee Irwin III <[email protected]> wrote:
>> Here it is.

On Wed, Nov 19, 2003 at 05:58:03PM -0800, Andrew Morton wrote:
> All the world's an x86 ;)
> This whole patch is getting rather large.
> ARM is doing weird stuff.

I just realized this can all be done in one line by setting the initial
value of ret to VM_FAULT_MINOR in do_no_page(). The ->nopage() methods
not updated will give off compiler warnings and since they think their
third arguments are ordinary integers, they won't update the referenced
content, and the initializer of VM_FAULT_MINOR then comes into play.

-- wli

diff -prauN mm4-2.6.0-test9-1/mm/memory.c mm4-2.6.0-test9-default-2/mm/memory.c
--- mm4-2.6.0-test9-1/mm/memory.c 2003-11-19 00:07:15.000000000 -0800
+++ mm4-2.6.0-test9-default-2/mm/memory.c 2003-11-19 18:08:49.000000000 -0800
@@ -1424,7 +1424,7 @@ do_no_page(struct mm_struct *mm, struct
pte_t entry;
struct pte_chain *pte_chain;
int sequence = 0;
- int ret;
+ int ret = VM_FAULT_MINOR;

if (!vma->vm_ops || !vma->vm_ops->nopage)
return do_anonymous_page(mm, vma, page_table,

2003-11-20 02:29:45

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

Thanks, I post a totally untested patch follows, but the testing of
which kernel has this feature is not completed yet.

Is there a way to reliably detect which kernel has this change?

Look at all the ifdef I need to make to keep the module working
with other kernels. :-(

Best Regards,

Chris

--- /tmp/p5diffhtml.tmp1.27140 2003-11-19 18:28:07.000000000 -0800
+++ /modules/shared/linux/compat_version.h 2003-11-19 18:25:12.000000000 -0800
@@ -96,5 +96,10 @@
# define KERNEL_2_5_5
#endif

+#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 0)
+/* New status return pointer in vmop->nopage() */
+/* FIXME: We need to test against 2.6.0-test9-mm4 */
+# define KERNEL_2_6_0_TEST9_MM4
+#endif

#endif /* __COMPAT_VERSION_H__ */
--- /tmp/p5diffhtml.tmp1.27140 2003-11-19 18:28:07.000000000 -0800
+++ /modules/vmmon/linux/driver.c 2003-11-19 18:26:28.000000000 -0800
@@ -548,6 +548,11 @@
*-----------------------------------------------------------------------------
*/

+#ifdef KERNEL_2_6_0_TEST9_MM4
+static struct page *LinuxDriverNoPage(struct vm_area_struct *vma, //IN
+ unsigned long address, //IN
+ int *type) //OUT
+#else
#ifdef KERNEL_2_4_0
static struct page *LinuxDriverNoPage(struct vm_area_struct *vma, //IN
unsigned long address, //IN
@@ -557,6 +562,7 @@
unsigned long address, //IN
int write_access) //IN
#endif
+#endif
{
VMLinux *vmLinux = (VMLinux *) vma->vm_file->private_data;
unsigned long pg;
@@ -566,6 +572,11 @@
return 0;
}
get_page(virt_to_page(vmLinux->pages4Gb[pg]));
+#ifdef KERNEL_2_6_0_TEST9_MM4
+ if (type) {
+ *type = VM_FAULT_MINOR;
+ }
+#endif
#ifdef KERNEL_2_4_0
return virt_to_page(vmLinux->pages4Gb[pg]);
#else
On Wed, Nov 19, 2003 at 05:47:18PM -0800, William Lee Irwin III wrote:
> On Wed, Nov 19, 2003 at 05:34:25PM -0500, Christopher Li wrote:
> > Can send me a few more lines of the log file before and after that message? I can take
> > a look at what is going on there. Most likely vmmon driver get confused.
>
> You should have a vm_ops->nopage() method that didn't get updated.
> The formerly-unused argument got turned into a status return pointer,
> so you need to do something like:
>
> struct page *vmmon_nopage(struct vm_area_struct *vma, unsigned long addr, int *type)
> {
> ...
> if (type)
> *type = VM_FAULT_MINOR;
> return page;
> }
>
> It should also give off a big fat warning about initialization from
> incompatible pointer types when compiled.
>
>
> -- wli

2003-11-20 02:35:09

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

On Wed, Nov 19, 2003 at 06:22:46PM -0500, Christopher Li wrote:
> Thanks, I post a totally untested patch follows, but the testing of
> which kernel has this feature is not completed yet.
> Is there a way to reliably detect which kernel has this change?
> Look at all the ifdef I need to make to keep the module working
> with other kernels. :-(
> Best Regards,
> Chris

akpm wants us not to barf when ->nopage() methods not updated to the
new signature are used, so we're either setting the initial value of
ret in do_no_page() to something that won't get barfed on by
do_page_fault() or teaching all the fault handlers to ignore invalid
return values. As far as fixing the warning, the #ifdef is still needed.

I'm going to ruminate on non-fatal methods of complaining loudly.

-- wli

2003-11-20 02:31:48

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

On Wed, Nov 19, 2003 at 06:12:58PM -0800, William Lee Irwin III wrote:
> I just realized this can all be done in one line by setting the initial
> value of ret to VM_FAULT_MINOR in do_no_page(). The ->nopage() methods
> not updated will give off compiler warnings and since they think their
> third arguments are ordinary integers, they won't update the referenced
> content, and the initializer of VM_FAULT_MINOR then comes into play.

Yes, that is a good idea.

Chris

>
>
> -- wli
>
>
> diff -prauN mm4-2.6.0-test9-1/mm/memory.c mm4-2.6.0-test9-default-2/mm/memory.c
> --- mm4-2.6.0-test9-1/mm/memory.c 2003-11-19 00:07:15.000000000 -0800
> +++ mm4-2.6.0-test9-default-2/mm/memory.c 2003-11-19 18:08:49.000000000 -0800
> @@ -1424,7 +1424,7 @@ do_no_page(struct mm_struct *mm, struct
> pte_t entry;
> struct pte_chain *pte_chain;
> int sequence = 0;
> - int ret;
> + int ret = VM_FAULT_MINOR;
>
> if (!vma->vm_ops || !vma->vm_ops->nopage)
> return do_anonymous_page(mm, vma, page_table,
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

2003-11-20 02:47:35

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

On Wed, Nov 19, 2003 at 06:34:57PM -0800, William Lee Irwin III wrote:
> I'm going to ruminate on non-fatal methods of complaining loudly.

SPARSE checker?

Chris

2003-11-20 02:57:39

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

On Wed, Nov 19, 2003 at 06:34:57PM -0800, William Lee Irwin III wrote:
>> I'm going to ruminate on non-fatal methods of complaining loudly.

On Wed, Nov 19, 2003 at 06:40:37PM -0500, Christopher Li wrote:
> SPARSE checker?

I was thinking of teaching the fault handlers to complain about
->nopage() methods returning invalid results in a non-fatal manner,
possibly with code consolidation.

e.g. every arch does:

switch (handle_mm_fault(...)) {
case VM_FAULT_MINOR:
tsk->min_flt++;
break;
case VM_FAULT_MAJOR:
tsk->maj_flt++;
break;
case VM_FAULT_SIGBUS:
goto do_sigbus;
case VM_FAULT_OOM:
goto out_of_memory;
default:
BUG();
}

which is vaguely repetitive. It's not immediately clear how to
consolidate gotos, which is where the thought starts happening.

The other part was replacing default: BUG() with something that
complained (e.g. putting print_symbol() to use on the ->nopage()
method) and treating the invalid statuses like OOM, but that's
not really very hard to do (I posted something that did some
crude reporting of that kind already to handle the sound/ bogons).

-- wli

2003-11-20 04:16:58

by Gerardo Exequiel Pozzi

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

On Wed, 19 Nov 2003 13:38:14 -0800, Andrew Morton wrote:
>Gerardo Exequiel Pozzi <[email protected]> wrote:
>>
>> With the recent 2.6.0-test9-mm4 i can't start the vmware, it reports in vmware.log (debug ON):
>>
>> Nov 19 17:27:40: vmx| WSSCAN: Not enough physical memory: req=49152 avail=0 over
>> head=4096 maxRespage=106496
>> Nov 19 17:27:40: vmx| WSSCAN: Not enough physical (in MB): nbVM=3 hostMem=512 ch
>> eckMemory=1
>>
>> With linus tree from 2.6.0-test9-mm4/broken-out/linus.patch and 2.6.0-test3-mm3 don't have problem.
>
>hm, that's funny.
>
>> Any other test from broken-out to patch it?
>
>I can't immediately think what could have caused that. Maybe if you were
>to strace vmware startup, see what is failing?

Sorry for my fast report (was hurried) Andrew and others, i don't checked the logs :(

Appears the same message that posted Jose Luis Domingo Lopez.

Now it will prove the patches and it will comment the results to them.

Thanks people!,

chau,
djgera

------------[ cut here ]------------
kernel BUG at mm/memory.c:793!
invalid operand: 0000 [#2]
PREEMPT
CPU: 0
EIP: 0060:[<c014a62b>] Tainted: P VLI
EFLAGS: 00013282
EIP is at get_user_pages+0x11b/0x390
eax: c13fa819 ebx: db6e0000 ecx: 00000000 edx: d9fab8c0
esi: db6e0000 edi: 40630000 ebp: da172680 esp: db6e1d24
ds: 007b es: 007b ss: 0068
Process vmware-vmx (pid: 377, threadinfo=db6e0000 task=da271980)
Stack: da292940 da172680 40630000 00000001 db6e0000 db6e0000 db6e0000 00000002
00000000 00000000 db6e0000 00040630 40630000 00000000 e095aa65 da271980
da292940 40630000 00000001 00000001 00000000 db6e1da0 00000000 00000000
Call Trace:
[<e095aa65>] HostIFGetUserPage+0x65/0xa0 [vmmon]
[<e095ab00>] HostIF_LockPage+0x60/0x300 [vmmon]
[<e095cb2d>] Vmx86_LockPage+0x7d/0xf0 [vmmon]
[<e0957fdd>] __LinuxDriver_Ioctl+0x3bd/0xb80 [vmmon]
[<c0143497>] do_page_cache_readahead+0xf7/0x180
[<c013bf5c>] find_get_page+0x2c/0x60
[<c0140970>] buffered_rmqueue+0xd0/0x180
[<c0140acf>] __alloc_pages+0xaf/0x350
[<e0959b37>] LinuxDriverQueue+0x17/0x40 [vmmon]
[<c0140d8f>] __get_free_pages+0x1f/0x50
[<c014ccca>] __vma_link+0x3a/0xa0
[<c014cd8b>] vma_link+0x5b/0x90
[<e095886e>] LinuxDriver_IoctlV4+0x5e/0x100 [vmmon]
[<e09594a7>] LinuxDriver_Ioctl+0x177/0x210 [vmmon]
[<c016d6b3>] sys_ioctl+0xf3/0x280
[<c0159aa2>] sys_close+0x62/0xa0
[<c038883f>] syscall_call+0x7/0xb

Code: 4c 8b 4c 24 40 89 7c 24 08 89 6c 24 04 89 54 24 0c 89 0c 24 e8 17 18 00 00 85 c0 74 4e 85 c0 7e 2f 83 f8 01 74 1e 83 f8 02 74 0d <0f> 0b 19 03 1a 76 3a c0 ff 46 14 eb 98 8b 54 24 3c ff 82 dc 01

--
Gerardo Exequiel Pozzi ( djgera )
http://www.vmlinuz.com.ar http://www.djgera.com.ar
KeyID: 0x1B8C330D
Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

2003-11-20 04:40:26

by Gerardo Exequiel Pozzi

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

On Wed, 19 Nov 2003 18:12:58 -0800, William Lee Irwin III wrote:
>William Lee Irwin III <[email protected]> wrote:
>diff -prauN mm4-2.6.0-test9-1/mm/memory.c mm4-2.6.0-test9-default-2/mm/memory.c
>--- mm4-2.6.0-test9-1/mm/memory.c 2003-11-19 00:07:15.000000000 -0800
>+++ mm4-2.6.0-test9-default-2/mm/memory.c 2003-11-19 18:08:49.000000000 -0800
>@@ -1424,7 +1424,7 @@ do_no_page(struct mm_struct *mm, struct
> pte_t entry;
> struct pte_chain *pte_chain;
> int sequence = 0;
>- int ret;
>+ int ret = VM_FAULT_MINOR;
>
> if (!vma->vm_ops || !vma->vm_ops->nopage)
> return do_anonymous_page(mm, vma, page_table,
>-

Applied this only against 2.6.0-test9-mm4 and vmware now works OK!
Not applied the previous change in mm/fault.c and mm/memory.c .

Thanks :P

chau,
djgera

--
Gerardo Exequiel Pozzi ( djgera )
http://www.vmlinuz.com.ar http://www.djgera.com.ar
KeyID: 0x1B8C330D
Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

2003-11-20 10:03:50

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

May I have the patch of this vmware fix to run a few tests?
Best regards,
Liviu

William Lee Irwin III wrote:

>On Wed, Nov 19, 2003 at 06:34:57PM -0800, William Lee Irwin III wrote:
>
>
>>>I'm going to ruminate on non-fatal methods of complaining loudly.
>>>
>>>
>
>On Wed, Nov 19, 2003 at 06:40:37PM -0500, Christopher Li wrote:
>
>
>>SPARSE checker?
>>
>>
>
>I was thinking of teaching the fault handlers to complain about
>->nopage() methods returning invalid results in a non-fatal manner,
>possibly with code consolidation.
>
>e.g. every arch does:
>
> switch (handle_mm_fault(...)) {
> case VM_FAULT_MINOR:
> tsk->min_flt++;
> break;
> case VM_FAULT_MAJOR:
> tsk->maj_flt++;
> break;
> case VM_FAULT_SIGBUS:
> goto do_sigbus;
> case VM_FAULT_OOM:
> goto out_of_memory;
> default:
> BUG();
> }
>
>which is vaguely repetitive. It's not immediately clear how to
>consolidate gotos, which is where the thought starts happening.
>
>The other part was replacing default: BUG() with something that
>complained (e.g. putting print_symbol() to use on the ->nopage()
>method) and treating the invalid statuses like OOM, but that's
>not really very hard to do (I posted something that did some
>crude reporting of that kind already to handle the sound/ bogons).
>
>
>-- wli
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>

--
Liviu Voicu
Assistant Programmer and network support
Computation Center, Mount Scopus
Hebrew University of Jerusalem
Tel: 972(2)-5881253
E-mail: "Liviu Voicu"<[email protected]>

/**
* cat /usr/src/linux/arch/i386/boot/bzImage > /dev/dsp
* ( and the voice of God will be heard! )
*
*/

Click here to see my GPG signature:
----------------------------------
http://search.keyserver.net:11371/pks/lookup?template=netensearch%2Cnetennomatch%2Cnetenerror&search=pacman%40mscc.huji.ac.il&op=vindex&fingerprint=on&submit=Get+List

2003-11-20 10:23:20

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

William Lee Irwin III wrote:

>On Thu, Nov 20, 2003 at 12:03:42PM +0200, Voicu Liviu wrote:
>
>
>>May I have the patch of this vmware fix to run a few tests?
>>Best regards,
>>
>>
>
>Here you go.
>
I really appreciate your quick reply, will this also work with -bk24 branch?
Thank you

>
>
>-- wli
>
>
>diff -prauN mm4-2.6.0-test9-1/mm/memory.c mm4-2.6.0-test9-default-2/mm/memory.c
>--- mm4-2.6.0-test9-1/mm/memory.c 2003-11-19 00:07:15.000000000 -0800
>+++ mm4-2.6.0-test9-default-2/mm/memory.c 2003-11-19 18:08:49.000000000 -0800
>@@ -1424,7 +1424,7 @@ do_no_page(struct mm_struct *mm, struct
> pte_t entry;
> struct pte_chain *pte_chain;
> int sequence = 0;
>- int ret;
>+ int ret = VM_FAULT_MINOR;
>
> if (!vma->vm_ops || !vma->vm_ops->nopage)
> return do_anonymous_page(mm, vma, page_table,
>
>

--
Liviu Voicu
Assistant Programmer and network support
Computation Center, Mount Scopus
Hebrew University of Jerusalem
Tel: 972(2)-5881253
E-mail: "Liviu Voicu"<[email protected]>

/**
* cat /usr/src/linux/arch/i386/boot/bzImage > /dev/dsp
* ( and the voice of God will be heard! )
*
*/

Click here to see my GPG signature:
----------------------------------
http://search.keyserver.net:11371/pks/lookup?template=netensearch%2Cnetennomatch%2Cnetenerror&search=pacman%40mscc.huji.ac.il&op=vindex&fingerprint=on&submit=Get+List

2003-11-20 10:42:26

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

William Lee Irwin III wrote:
>> What -bk24 branch?

On Thu, Nov 20, 2003 at 12:37:35PM +0200, Voicu Liviu wrote:
> http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.0-test9-bk24.bz2

It has nothing to do with that, no. It is specific to 2.6.0-test9-mm4.

-- wli

2003-11-20 10:31:48

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

On Thu, Nov 20, 2003 at 12:23:00PM +0200, Voicu Liviu wrote:
> I really appreciate your quick reply, will this also work with -bk24 branch?
> Thank you

What -bk24 branch?

-- wli

2003-11-20 10:37:54

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

William Lee Irwin III wrote:

>On Thu, Nov 20, 2003 at 12:23:00PM +0200, Voicu Liviu wrote:
>
>
>>I really appreciate your quick reply, will this also work with -bk24 branch?
>>Thank you
>>
>>
>
>What -bk24 branch?
>
http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.0-test9-bk24.bz2

>
>
>-- wli
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>

--
Liviu Voicu
Assistant Programmer and network support
Computation Center, Mount Scopus
Hebrew University of Jerusalem
Tel: 972(2)-5881253
E-mail: "Liviu Voicu"<[email protected]>

/**
* cat /usr/src/linux/arch/i386/boot/bzImage > /dev/dsp
* ( and the voice of God will be heard! )
*
*/

Click here to see my GPG signature:
----------------------------------
http://search.keyserver.net:11371/pks/lookup?template=netensearch%2Cnetennomatch%2Cnetenerror&search=pacman%40mscc.huji.ac.il&op=vindex&fingerprint=on&submit=Get+List

2003-11-20 10:51:06

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

William Lee Irwin III wrote:

>William Lee Irwin III wrote:
>
>
>>>What -bk24 branch?
>>>
>>>
>
>On Thu, Nov 20, 2003 at 12:37:35PM +0200, Voicu Liviu wrote:
>
>
>>http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.0-test9-bk24.bz2
>>
>>
>
>It has nothing to do with that, no. It is specific to 2.6.0-test9-mm4.
>
Ah, sorry, I got comfussed!
Any way to get vmware working with 2.6.0-test9 or with 2.6.0-test9-bk24?
Thanks

>
>
>-- wli
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>

--
Liviu Voicu
Assistant Programmer and network support
Computation Center, Mount Scopus
Hebrew University of Jerusalem
Tel: 972(2)-5881253
E-mail: "Liviu Voicu"<[email protected]>

/**
* cat /usr/src/linux/arch/i386/boot/bzImage > /dev/dsp
* ( and the voice of God will be heard! )
*
*/

Click here to see my GPG signature:
----------------------------------
http://search.keyserver.net:11371/pks/lookup?template=netensearch%2Cnetennomatch%2Cnetenerror&search=pacman%40mscc.huji.ac.il&op=vindex&fingerprint=on&submit=Get+List

2003-11-20 11:35:59

by Petr Vandrovec

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

On 20 Nov 03 at 12:51, Voicu Liviu wrote:
> >
> >It has nothing to do with that, no. It is specific to 2.6.0-test9-mm4.
> >
> Ah, sorry, I got comfussed!
> Any way to get vmware working with 2.6.0-test9 or with 2.6.0-test9-bk24?

Just hit poweron button? Maybe you can download & install
ftp://platan.vc.cvut.cz/pub/vmware/vmware-any-any-update45.tar.gz before,
but there is no need for it unless you are using prebuilt RedHat's
kernels which are built with -mregparm=3... (and update45 does not
contain Christopher's patch for -mm4 yet).

BTW, anybody knows how to explain to gcc that inline assembly uses
push & pop, and so $esp relative addressing is not going to work very
well?
Thanks,
Petr Vandrovec

2003-11-20 20:28:06

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

Have your try Petr Vandrovec's patch?
ftp://platan.vc.cvut.cz/pub/vmware

Chris

On Thu, Nov 20, 2003 at 12:51:00PM +0200, Voicu Liviu wrote:
> Ah, sorry, I got comfussed!
> Any way to get vmware working with 2.6.0-test9 or with 2.6.0-test9-bk24?
> Thanks
>

2003-11-20 21:38:22

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

On Thursday, 20 November 2003, at 12:20:59 -0500,
Christopher Li wrote:

> Have your try Petr Vandrovec's patch?
> ftp://platan.vc.cvut.cz/pub/vmware
>
I just tried to "recompile" VMware Workstation 4.0.1 build 5289 applying:
ftp://platan.vc.cvut.cz/pub/vmware/vmware-any-any-update45.tar.gz

And the preblem persists. I get a BUG in the logs, very similar to the
one I reported yesterday (both with 2.6.0-test9-mm4):

kernel BUG at mm/memory.c:793!
invalid operand: 0000 [#2]
CPU: 0
EIP: 0060:[<c01425c7>] Tainted: PF VLI
EFLAGS: 00013282
EIP is at get_user_pages+0xe7/0x300
eax: c109e391 ebx: 406a0000 ecx: 00000000 edx: ce90d580
esi: ddb89a00 edi: 00000001 ebp: d1af24c0 esp: c17d5d30
ds: 007b es: 007b ss: 0068
Process vmware-vmx (pid: 12494, threadinfo=c17d4000 task=dfd9acc0)
Stack: d1af24c0 ddb89a00 406a0000 00000001 00000002 00000000 00000000 c17d4000
000406a0 406a0000 00000000 e0b61925 dfd9acc0 d1af24c0 406a0000 00000001
00000001 00000000 c17d5da0 00000000 00000000 000406a0 e0b619c0 406a0000
Call Trace:
[<e0b61925>] HostIFGetUserPage+0x65/0xa0 [vmmon]
[<e0b619c0>] HostIF_LockPage+0x60/0x300 [vmmon]
[<e0b63b6d>] Vmx86_LockPage+0x7d/0xf0 [vmmon]
[<e0b5ef5d>] __LinuxDriver_Ioctl+0x36d/0xb30 [vmmon]
[<c013978f>] __alloc_pages+0xaf/0x350
[<c013bf1e>] do_page_cache_readahead+0xbe/0x110
[<c013516a>] find_get_page+0x1a/0x30
[<c0136607>] filemap_nopage+0x267/0x420
[<c013964f>] buffered_rmqueue+0xaf/0x140
[<c013978f>] __alloc_pages+0xaf/0x350
[<c015dda9>] permission+0x49/0x50
[<c0139a4f>] __get_free_pages+0x1f/0x50
[<c014494a>] __vma_link+0x3a/0xa0
[<c0144a06>] vma_link+0x56/0x80
[<e0b5f7ee>] LinuxDriver_IoctlV4+0x5e/0x100 [vmmon]
[<e0b60427>] LinuxDriver_Ioctl+0x177/0x210 [vmmon]
[<c0162b85>] sys_ioctl+0xb5/0x230
[<c0150770>] sys_close+0x50/0x60
[<c02ad977>] syscall_call+0x7/0xb

Code: 00 85 c0 74 4b 85 c0 7e 2c 83 f8 01 75 0c 8b 44 24 30 ff 80 d8 01 00 00 eb bd 83 f8 02 75 0c 8b 54 24 30 ff 82 dc 01 00 00 eb ac <0f> 0b 19 03 d1 b6 2c c0 eb a2 40 75 f3 8b 5c 24 18 b8 f4 ff ff

Greetings.

--
Jose Luis Domingo Lopez
Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test9-mm4)

2003-11-20 21:55:40

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

On Thursday, 20 November 2003, at 12:20:59 -0500, Christopher Li wrote:
>> Have your try Petr Vandrovec's patch?
>> ftp://platan.vc.cvut.cz/pub/vmware

On Thu, Nov 20, 2003 at 10:38:10PM +0100, Jose Luis Domingo Lopez wrote:
> I just tried to "recompile" VMware Workstation 4.0.1 build 5289 applying:
> ftp://platan.vc.cvut.cz/pub/vmware/vmware-any-any-update45.tar.gz
> And the preblem persists. I get a BUG in the logs, very similar to the
> one I reported yesterday (both with 2.6.0-test9-mm4):

Okay, several questions:
(a) is _this_ run with 2.6.0-test9-mm4?
(b) which _exact_ fixes did you run with?

-- wli

2003-11-20 22:54:37

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

On Thursday, 20 November 2003, at 13:55:36 -0800,
William Lee Irwin III wrote:

> Okay, several questions:
> (a) is _this_ run with 2.6.0-test9-mm4?
>
Yes, kernel version 2.6.0-test9-mm4.

> (b) which _exact_ fixes did you run with?
>
I downloaded:
ftp://platan.vc.cvut.cz/pub/vmware/vmware-any-any-update45.tar.gz

I untarred it to /tmp and, as root, I run:
/tmp/vmware-any-any-update45/runme.pl

Then the script stopped VMware services, went to recompile both vmnet.o
and vmmon.o, and then started the services again.

Launched VMware as usual, tried to boot the same guest operating system
I used on yesterday's BUG report, and got the messages in the log.

What I am going to try now is to completely uninstall VMware, install it
from scratch and apply vmware-any-any-update45.tar.gz and see how it goes
(to avoid previously applied patches or manual modifications to VMware
sources done by me making some difference).

Installed the VMware version shown above (via vmware-install.pl),
skipping the configuration part. Then I run "runme.pl" from the VMware
update version 45 to configure VMware and compile modules against my
current and configured 2.6.0-test9-mm4 kernel sources.

Started Vmware, tried to boot the guest operating system I have always
tried to boot during these tests and the result is the same as before,
including the BUG.

Hope this helps.

PS: just in case anyone sees it other way, I am just trying to help
giving information about a problem with a propietary application and
their binary only modules just in case this can unveil some sort of
kernel problem, but I am NOT trying to urge anyone to give me (us) a fix.

--
Jose Luis Domingo Lopez
Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test9-mm4)

2003-11-20 23:02:33

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

On Thu, Nov 20, 2003 at 11:53:54PM +0100, Jose Luis Domingo Lopez wrote:
> I untarred it to /tmp and, as root, I run:
> /tmp/vmware-any-any-update45/runme.pl
> Then the script stopped VMware services, went to recompile both vmnet.o
> and vmmon.o, and then started the services again.
> Launched VMware as usual, tried to boot the same guest operating system
> I used on yesterday's BUG report, and got the messages in the log.
> What I am going to try now is to completely uninstall VMware, install it
> from scratch and apply vmware-any-any-update45.tar.gz and see how it goes
> (to avoid previously applied patches or manual modifications to VMware
> sources done by me making some difference).
[...]

Okay, try this fix:

diff -prauN mm4-2.6.0-test9-1/mm/memory.c mm4-2.6.0-test9-default-2/mm/memory.c
--- mm4-2.6.0-test9-1/mm/memory.c 2003-11-19 00:07:15.000000000 -0800
+++ mm4-2.6.0-test9-default-2/mm/memory.c 2003-11-19 18:08:49.000000000 -0800
@@ -1424,7 +1424,7 @@ do_no_page(struct mm_struct *mm, struct
pte_t entry;
struct pte_chain *pte_chain;
int sequence = 0;
- int ret;
+ int ret = VM_FAULT_MINOR;

if (!vma->vm_ops || !vma->vm_ops->nopage)
return do_anonymous_page(mm, vma, page_table,

2003-11-21 20:10:24

[permalink] [raw]

Subject: Re: 2.6.0-test9-mm4 (only) and vmware

On Thursday, 20 November 2003, at 14:56:29 -0800,
William Lee Irwin III wrote:

> @@ -1424,7 +1424,7 @@ do_no_page(struct mm_struct *mm, struct
> pte_t entry;
> struct pte_chain *pte_chain;
> int sequence = 0;
> - int ret;
> + int ret = VM_FAULT_MINOR;
>
I applied it manually to 2.6.0-test9-mm4 (because there is some offset
that prevents the patch to apply cleanly to it).

Compiled the kernel with the exact same configuration used in previous
tests, as well as modules. Booted with this new kernel
(2.6.0-test9-mm4-fix) and reconfigured (vmware-config.pl) VMware.

Otherwise, everything is as it was yesterday. Booted the program,
started the same guest operating system as ever, and now the BUG is gone
and everything works OK.

Great work, greetings.

--
Jose Luis Domingo Lopez
Linux Registered User #189436 Debian Linux Sid (Linux 2.6.0-test9-mm4-fix)

2003-11-21 23:09:08