: glibc 라이브러리에서 malloc 는 2의 배수로 메모리를 할당하는 것으로
: 알고 있읍니다. 혹시 이 문제가 아닐까 생각도 드네요...

메모리 할당 문제가 있을 것 같아서

#define TEST_MEM_SIZE 21*1024*1024

위와 같이 define해서 메모리를 잡았습니다.
이렇게 하면 2의 배수로 메모리를 할당하게 되는 것 아닌가요?

그러면 메모리 테스트 할 수있는 다른 방법이 없을 까요?
으으으.... 머리아프당....

이해를 좀 더 돕고자 메모리 테스트를 하게된 이유를 설명드리겠습니다.

지금 시스템 보드를 개발하는 중인데 대략 16M 정도의 버퍼가 최소 두개
이상이 꼭 필요합니다.
그래서 미리 점검차원에서 메모리 테스트를 해 본 것인데 이런 결과가
나오고 말았군요. T.T

메모리 테스트는 다음 두가지 방법으로 해봤습니다.

1. EZ Board에 저장된 Boot Loader, Kernel Image, Ramdisk Image를 지우고
직접 제작한 Boot Code로 Boot Image를 만들어 부팅 했습니다.
그리고 난 후에 전체 메모리 영역(0xC0000000 ~ 0xC4000000)에
대해서 일일이 한 번지씩 Write/Read 테스트 해봤습니다.

2. EZ Board에 Kernel Source Code를 수정하여 64M로 메모리를 설정했습니다.
그 내용은 앞서 올린 글의 내용입니다.

No.1의 방법으로 Test를 해 보니 0xC2000000 의 영역을 넘으면 메모리 에러가
났는지
바로 다운되는 현상이 나타납니다. 읽기만 해도 바로 다운됩니다.
왜 그런지 모르겠습니다.
그래서 No.2의 방법으로 해 봤는데 결과는 앞서 말씀드린 그대로 입니다.

제가 기대한 것은 이렇습니다.
No.1의 방법으로 했을 경우, OS가 없으므로 OS로부터 메모리 할당 받을 필요
가 없고
메모리 테스트 프로그램이 한 번지씩 읽도록 단순하게 짜서
문제가 없을 것으로 보았던 것입니다.

혹시, No.2의 경우도 No.1의 경우와 마찬가지로 0xC2000000영역을 벗어나서 문
제가
생기는 건 아닌가 싶기도 하네요.

결과적으로 No.2의 방법으로도 테스트에 성공하지 못했으니 어케하죠?

혹시 이런 문제가 발생하는 것이 SDRAM Configuration에 관계하는 것은 아닐까
요?

으으으... 확실한게 하나도 없군요...

제발 누가좀 도와 주세요...


개구리 wrote..
: 이 문제는 솔직히 남감하네요...
:
: 페이징 에러라고 하면 커널내의 메모리 관리 쪽 문제로
: 보이는 것 같은데....
:
: 일단 추측적인것을 한번 말씀드리면
:
: glibc 라이브러리에서 malloc 는 2의 배수로 메모리를 할당하는 것으로
: 알고 있읍니다. 혹시 이 문제가 아닐까 생각도 드네요...
:
: http://scl.snu.ac.kr/~vivlavie/CReference/3.html
: 를 참조해 보시고 시험 보시고 다시 질문을 올려 주세요...
이 게시물을...