[LTP] [patch]hugeshmat issue

[LTP] [patch]hugeshmat issue

[lina.zhao]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

Hi,

In hugeshmat01 and hugeshmat02, the attach address for shard memory is 
0x90000eee.
For 32bits mips/Linux system, user space is under 0x7FFFFFFF,
0x90000eee is too big. The new address 0x60000eee has been tested
on mips and other arch systems, it hasn't caused a issue yet.

Regards,

Lina Zhao

[-- Attachment #2: hugeshmat-attach-address-change.patch --]
[-- Type: text/x-diff, Size: 1700 bytes --]

From e337a913dbf366f136b31e96d8662f8e111b9d81 Mon Sep 17 00:00:00 2001
From: Lina Zhao <lina.zhao@windriver.com>
Date: Thu, 12 Aug 2010 15:27:53 +0800
Subject: [PATCH] For 32bits mips/Linux system, user space is under 0x7FFFFFFF,
 0x90000eee is too big. The new address 0x60000eee has been tested
 on mips and other arch systems, it hasn't caused a issue yet.

Signed-off-by: Lina Zhao <lina.zhao@windriver.com>
---
 .../kernel/mem/hugetlb/hugeshmat/hugeshmat01.c     |    2 +-
 .../kernel/mem/hugetlb/hugeshmat/hugeshmat02.c     |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/testcases/kernel/mem/hugetlb/hugeshmat/hugeshmat01.c b/testcases/kernel/mem/hugetlb/hugeshmat/hugeshmat01.c
index 229b929..7087d26 100644
--- a/testcases/kernel/mem/hugetlb/hugeshmat/hugeshmat01.c
+++ b/testcases/kernel/mem/hugetlb/hugeshmat/hugeshmat01.c
@@ -70,7 +70,7 @@ unsigned long huge_pages_shm_to_be_allocated;
 #if __WORDSIZE==64
 #define UNALIGNED      0x10000000eee
 #else
-#define UNALIGNED      0x90000eee
+#define UNALIGNED      0x60000eee
 #endif
 
 int shm_id_1 = -1;
diff --git a/testcases/kernel/mem/hugetlb/hugeshmat/hugeshmat02.c b/testcases/kernel/mem/hugetlb/hugeshmat/hugeshmat02.c
index 2f56127..428eeab 100644
--- a/testcases/kernel/mem/hugetlb/hugeshmat/hugeshmat02.c
+++ b/testcases/kernel/mem/hugetlb/hugeshmat/hugeshmat02.c
@@ -74,7 +74,7 @@ void	*addr;				/* for result of shmat-call */
 #if __WORDSIZE==64
 #define NADDR   0x10000000eef           /* a 64bit non alligned address value */
 #else
-#define NADDR	0x90000eef		/* a non alligned address value */
+#define NADDR	0x60000eef		/* a non alligned address value */
 #endif
 
 struct test_case_t {
-- 
1.6.3.1


[-- Attachment #3: Type: text/plain, Size: 224 bytes --]

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 

[-- Attachment #4: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [patch]hugeshmat issue

[Garrett Cooper]

On Mon, Aug 16, 2010 at 1:13 AM, lina.zhao <lina.zhao@windriver.com> wrote:
> See Mips run(2nd edition): 14.4 :MIPS/Linux system address transfer: linux
> address map:see the attachment
>>
>> On Thu, Aug 12, 2010 at 1:13 AM, lina.zhao <lina.zhao@windriver.com>
>> wrote:
>>
>>>
>>> Hi,
>>>
>>> In hugeshmat01 and hugeshmat02, the attach address for shard memory is
>>> 0x90000eee.
>>> For 32bits mips/Linux system, user space is under 0x7FFFFFFF,
>>> 0x90000eee is too big. The new address 0x60000eee has been tested
>>> on mips and other arch systems, it hasn't caused a issue yet.
>>>
>>
>>    Interesting. Do you have documentation to back up your claim?

Thanks for the info -- committed!
-Garrett

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list