Skip to contentSkip to conversation

hugeshmat issue

PATCH In review lina.zhao 2 participants 2 messages Aug 12, 2010 – Aug 16, 2010 2 messages not in the archive

lore
Share & tools
lore

lina.zhao

author
#0 lore raw

PATCH 1/1 hugeshmat issue

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

From e337a913dbf366f136b31e96d8662f8e111b9d81 Mon Sep 17 00:00:00 2001
From: Lina Zhao <[email protected]>
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.

---
 .../kernel/mem/hugetlb/hugeshmat/hugeshmat01.c     |    2 +-
 .../kernel/mem/hugetlb/hugeshmat/hugeshmat02.c     |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
testcases/kernel/mem/hugetlb/hugeshmat/hugeshmat01.c +1 -1
index 229b929..7087d26 100644
@@ -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;
testcases/kernel/mem/hugetlb/hugeshmat/hugeshmat02.c +1 -1
index 2f56127..428eeab 100644
@@ -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 {
Signature · 1 line
1.6.3.1

------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

#3 lore raw
Quoted 17 lines · lina.zhao

See Mips run(2nd edition): 14.4 :MIPS/Linux system address transfer: linux address map:see the attachment

Quoted 15 lines
Quoted 9 lines · lina.zhao

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list