이것은 다소의 연속입니다
1.4GB의 4GB RAM을 사용하는 하드웨어 장치는 무엇입니까?
몇 가지 신비한 이유 때문에 BIOS를 업그레이드 한 후 그래픽 어댑터가 갑자기 1.4GB의 메모리를 (동적으로 예약하지 않고) 예약했습니다 (노트북의 보증 기간이 만료 된 후 2 주). Linux 라이브 CD 몇 개 (USB 키에서 루프백 부팅)를 시도하고 UEFI에서 BIOS CSM으로 부팅 옵션을 변경 한 후 몇 번이나 변경하면 갑자기 800MB 이상이 예약됩니다.
그리고 명확하게 말하면, 이것은 Windows 문제가 아닙니다. memtest와 Linux 모두 해당 메모리 양을 봅니다. Lenovo Diagnostics만이 여전히 전체 4GB의 메모리를 확인합니다 (테스트 한 후 오류가 없음)
다음은 그래픽 드라이버 진단 도구 및 리소스 모니터의 스크린 샷입니다.
참고로 1435MB 이전에는 하드웨어 용으로 예약되었으며 최대 그래픽 메모리는 1138MB였습니다.
내 메모리의 절반이 “하드웨어에 의해 예약되어”있기 때문에 분명히 문제를 훨씬 더 시급하게 만듭니다.
출력은 크게 meminfo -r바뀌지 않았습니다 (4 번째 메모리 범위는 거의 800MB 줄었습니다).
MemInfo v2.10 - Show PFN database information
Copyright (C) 2007-2009 Alex Ionescu
www.alex-ionescu.com
Physical Memory Range: 0000000000001000 to 000000000009D000 (156 pages, 624 KB)
Physical Memory Range: 0000000000100000 to 0000000020000000 (130816 pages, 523264 KB)
Physical Memory Range: 0000000020200000 to 0000000040004000 (130564 pages, 522256 KB)
Physical Memory Range: 0000000040005000 to 0000000057D32000 (97581 pages, 390324 KB)
Physical Memory Range: 0000000100000000 to 000000011F600000 (128512 pages, 514048 KB)
MmHighestPhysicalPage: 1177088
삼성과 레노버와의 이전 이야기 이후 더 이상 UEFI를 신뢰하지 않기 때문에 EFI 셸에 들어가서 몇 가지 정보를 더 버렸습니다. 나는 이것이 무엇에 관한 것인지 정말로 모른다. 그러나 아마도 이것은 누군가를 도울 것이다.
mm
Type Start End # Pages Attributes
BS_code 0000000000000000-0000000000000FFF 0000000000000001 000000000000000F
available 0000000000001000-000000000005AFFF 000000000000005A 000000000000000F
BS_data 000000000005B000-000000000005BFFF 0000000000000001 000000000000000F
BS_code 000000000005C000-0000000000086FFF 000000000000002B 000000000000000F
BS_data 0000000000087000-0000000000087FFF 0000000000000001 000000000000000F
BS_code 0000000000088000-000000000008FFFF 0000000000000008 000000000000000F
reserved 0000000000090000-000000000009FFFF 0000000000000010 000000000000000F
BS_code 0000000000100000-000000000010FFFF 0000000000000010 000000000000000F
available 0000000000110000-000000001FFFFFFF 000000000001FEF0 000000000000000F
reserved 0000000020000000-00000000201FFFFF 0000000000000200 000000000000000F
available 0000000020200000-0000000040003FFF 000000000001FE04 000000000000000F
reserved 0000000040004000-0000000040004FFF 0000000000000001 000000000000000F
available 0000000040005000-0000000057D31FFF 0000000000017D2D 000000000000000F
BS_data 0000000057D32000-0000000057D51FFF 0000000000000020 000000000000000F
available 0000000057D52000-000000005A34AFFF 00000000000025F9 000000000000000F
BS_data 000000005A34B000-000000005A360FFF 0000000000000016 000000000000000F
reserved 000000005A361000-000000005A562FFF 0000000000000202 000000000000000F
BS_data 000000005A563000-000000005AD21FFF 00000000000007BF 000000000000000F
available 000000005AD22000-0000000096B02FFF 000000000003BDE1 000000000000000F
LoaderData 0000000096B03000-0000000096B04FFF 0000000000000002 000000000000000F
available 0000000096B05000-0000000096B06FFF 0000000000000002 000000000000000F
LoaderData 0000000096B07000-0000000096B14FFF 000000000000000E 000000000000000F
LoaderCode 0000000096B15000-0000000096BD1FFF 00000000000000BD 000000000000000F
LoaderData 0000000096BD2000-00000000C9468FFF 0000000000032897 000000000000000F
available 00000000C9469000-00000000C9474FFF 000000000000000C 000000000000000F
LoaderCode 00000000C9475000-00000000C9668FFF 00000000000001F4 000000000000000F
available 00000000C9669000-00000000CA828FFF 00000000000011C0 000000000000000F
BS_data 00000000CA829000-00000000CAE22FFF 00000000000005FA 000000000000000F
available 00000000CAE23000-00000000CAE31FFF 000000000000000F 000000000000000F
BS_data 00000000CAE32000-00000000CD668FFF 0000000000002837 000000000000000F
available 00000000CD669000-00000000CDCD5FFF 000000000000066D 000000000000000F
BS_code 00000000CDCD6000-00000000D6268FFF 0000000000008593 000000000000000F
RT_code 00000000D6269000-00000000D6344FFF 00000000000000DC 800000000000000F
RT_code 00000000D6345000-00000000D6468FFF 0000000000000124 800000000000000F
RT_data 00000000D6469000-00000000D6FEDFFF 0000000000000B85 800000000000000F
RT_data 00000000D6FEE000-00000000D9E9EFFF 0000000000002EB1 800000000000000F
reserved 00000000D9E9F000-00000000DAC13FFF 0000000000000D75 000000000000000F
reserved 00000000DAC14000-00000000DAE9EFFF 000000000000028B 000000000000000F
ACPI_NVS 00000000DAE9F000-00000000DAF04FFF 0000000000000066 000000000000000F
ACPI_NVS 00000000DAF05000-00000000DAF9EFFF 000000000000009A 000000000000000F
ACPI_recl 00000000DAF9F000-00000000DAFD9FFF 000000000000003B 000000000000000F
ACPI_recl 00000000DAFDA000-00000000DAFFEFFF 0000000000000025 000000000000000F
BS_data 00000000DAFFF000-00000000DAFFFFFF 0000000000000001 000000000000000F
available 0000000100000000-000000011F5FFFFF 000000000001F600 000000000000000F
reserved 00000000000A0000-00000000000BFFFF 0000000000000020 0000000000000000
reserved 00000000DB000000-00000000DF9FFFFF 0000000000004A00 0000000000000000
MemMapIO 00000000F80F8000-00000000F80F8FFF 0000000000000001 8000000000000001
MemMapIO 00000000FED1C000-00000000FED1FFFF 0000000000000004 8000000000000001
reserved : 24,115 Pages (98,775,040)
LoaderCode: 689 Pages (2,822,144)
LoaderData: 207,015 Pages (847,933,440)
BS_code : 34,263 Pages (140,341,248)
BS_data : 13,865 Pages (56,791,040)
RT_code : 512 Pages (2,097,152)
RT_data : 14,902 Pages (61,038,592)
available : 748,703 Pages (3,066,687,488)
ACPI_recl : 96 Pages (393,216)
ACPI_NVS : 256 Pages (1,048,576)
MemMapIO : 5 Pages (20,480)
Total Memory: 3,985 MB (4,179,152,896) Bytes
(UEFI noob으로서 BS_data는 무엇을 의미합니까?)
dh -d
(dh -v는 무한 루프로 실행되며 덤프 할 수 없습니다 …)
dmpstore (Windows 8 제품 키를 편집했습니다) :
이 메모리를 되 찾을 수있는 아이디어 나 다른 방법 (기계를 부팅 할 수있게하지 않고 UEFI NVRAM을 완전히 재설정하는 효과적인 방법이 있는지 아는 사람이 있습니까?)
편집 1
UEFI 모드에서 Linux를 부팅 할 때 대부분의 메모리를 사용할 수 있습니다.
그러나 CSM을 통해 호환성 BIOS 모드로 부팅 할 때는 다음이 아닙니다.
아마도 CSM의 버그일까요? (그러나 여전히 갑자기 등장한다는 것은 놀라운 일입니다 …)
기본 OS가 Windows (7)이므로 UEFI를 사용하려면 8 (.1)로 업그레이드하고 GPT 파티션에서 전체 재설치를 수행해야한다고 생각합니다. 그리고 UEFI가 (여전히) 규칙적으로 발생하는 문제를 고려할 때 해당 경로로 가고 싶은지 확실하지 않습니다 …
편집 2
나는이에 대한 레노버 포럼에 스레드를 게시,하지만 응답 지금까지 :
http://forums.lenovo.com/t5/R-and-L-Series-ThinkPad-Laptops/L530-2481-3SG-First-1 하드웨어별로 예약 된 -4-GB RAM-// td-p / 1539272
또한 (이 원인을 제외하고) CMOS 배터리를 제거했지만 “맨 아래 도어”(하드 디스크와 RAM이 숨겨져있는 덮개)에서 발견 된 일부 어두운 지문을 제외하고는 더 현명하지 않았습니다.
편집 3
별로 뉴스는 아니지만 Lenovo의 일부 직원이 포럼에서 내 게시물을 팔로우하여 일부 엔지니어가 살펴볼 것이라고 말했습니다. 최선을 기대해 보자구.
편집 4
또 다른 21MB는 먼지를 깨뜨 렸습니다. 이번에는 UEFI 보안 부팅을 통해 Linux 배포판을 부팅하려고 시도했습니다. 위에서 언급 한 Lenovo 포럼 스레드에 대한 자세한 내용.
답변
해결 🙂
원인은 UEFI 구현에서 이상한 기능인 것 같습니다.이 기능은 오픈 소스 TianoCore 구현에서도 볼 수 있습니다.
마지막 21MB “손실”이후 EFI 변수 덤프를 비교하여 흥미로운 변수를 찾은 후 궁극적으로 발견했습니다.
마지막 21MB의 메모리를 잃기 전에
Variable NV+RT+BS '4C19049F-4137-4DD3-9C10-8B97A83FFDFA:MemoryTypeInformationBackup' DataSize = 50
00000000: 09 00 00 00 60 00 00 00-0A 00 00 00 00 01 00 00 *....`...........*
00000010: 00 00 00 00 00 10 00 00-06 00 00 00 36 3A 00 00 *............6:..*
00000020: 05 00 00 00 00 02 00 00-03 00 00 00 00 8C 00 00 *................*
00000030: 04 00 00 00 00 40 00 00-01 00 00 00 00 02 00 00 *.....@..........*
00000040: 02 00 00 00 78 F2 03 00-0E 00 00 00 00 00 00 00 *....x...........*
Variable NV+RT+BS '4C19049F-4137-4DD3-9C10-8B97A83FFDFA:MemoryTypeInformation' DataSize = 50
00000000: 09 00 00 00 60 00 00 00-0A 00 00 00 00 01 00 00 *....`...........*
00000010: 00 00 00 00 00 10 00 00-06 00 00 00 36 3A 00 00 *............6:..*
00000020: 05 00 00 00 00 02 00 00-03 00 00 00 00 8C 00 00 *................*
00000030: 04 00 00 00 00 40 00 00-01 00 00 00 00 02 00 00 *.....@..........*
00000040: 02 00 00 00 38 E7 06 00-0E 00 00 00 00 00 00 00 *....8...........*
그들을 잃은 후
Variable NV+RT+BS '4C19049F-4137-4DD3-9C10-8B97A83FFDFA:MemoryTypeInformationBackup' DataSize = 50
00000000: 09 00 00 00 60 00 00 00-0A 00 00 00 00 01 00 00 *....`...........*
00000010: 00 00 00 00 00 10 00 00-06 00 00 00 36 3A 00 00 *............6:..*
00000020: 05 00 00 00 00 02 00 00-03 00 00 00 00 8C 00 00 *................*
00000030: 04 00 00 00 00 40 00 00-01 00 00 00 00 02 00 00 *.....@..........*
00000040: 02 00 00 00 38 E7 06 00-0E 00 00 00 00 00 00 00 *....8...........*
Variable NV+RT+BS '4C19049F-4137-4DD3-9C10-8B97A83FFDFA:MemoryTypeInformation' DataSize = 50
00000000: 09 00 00 00 60 00 00 00-0A 00 00 00 00 01 00 00 *....`...........*
00000010: 00 00 00 00 00 10 00 00-06 00 00 00 36 3A 00 00 *............6:..*
00000020: 05 00 00 00 00 02 00 00-03 00 00 00 00 8C 00 00 *................*
00000030: 04 00 00 00 82 55 00 00-01 00 00 00 00 02 00 00 *.....U..........*
00000040: 02 00 00 00 38 E7 06 00-0E 00 00 00 00 00 00 00 *....8...........*
이것이 흥미로운 이유 : 물건을 테스트하고, BIOS를 업그레이드 및 다운 그레이드하고, 설정을 변경하는 등 이러한 변수는 변하지 않았습니다 (그리고 설치된 RAM의 제조사 / 모델 등에 관한 정보를 저장한다고 가정했습니다).
메모리가 줄어 들었으므로 MemoryTypeInformation의 값이 MemoryTypeInformationBackup (이전 백업 덮어 쓰기)으로 백업되었으며 값의 정확히 하나의 DWORD가 오프셋 0x34에서 변경되었습니다. 이전 값은 0x4000이고 새 값은 0x5582입니다. 그 차이는 십진수로 0x1582 또는 5506이며, 지난 번에 메모리가 축소 된 페이지 수 (4K 블록)와 정확히 일치합니다.
한 단계 더 나아가 : MemoryTypeInformation과 MemoryTypeInformationBackup의 이전 값도 정확히 하나의 값이 다릅니다 (0x44와는 다른 오프셋에서). 값을 다시 비교할 때 0x2F4C0 또는 193728 (10 진수)은 내 기억이 이전 시간 (시작 주소가 871F2000에서 57D32000으로 변경되었을 때)에서 줄어든 페이지 수입니다.
이것을 앞에서 언급 한 TianoCore 코드와 비교하면 갑자기 완벽한 의미가 있습니다.
이 코드는 시스템이 부팅 옵션을 부팅하려고 할 때마다 트리거되며 다른 UEFI 메모리 영역에 MemoryTypeInformation에 저장된 것보다 할당 된 페이지 수가 적은지 확인합니다. 그렇지 않은 경우 메모리 맵이 올바르지 않고 변수가 현재 할당 된 것의 125 %로 업데이트되고 재부팅이 트리거되어 최신 데이터에서 메모리 맵을 다시 작성할 수 있습니다. 구현시 메모리 유형에 대한 캐시 크기가 절대 줄어들지 않으므로 여기에서 변경하면 영구적입니다.
여기서 UEFI 부팅에 실패하면 부팅 선택 메뉴로 돌아갑니다 (또는 기본 부팅 순서의 장치 인 경우 다음 장치가 시도 됨). 다음 메뉴가 부팅 되 자마자 부팅 실패시 대부분의 UEFI 부팅 로더가 자체적으로 정리되지 않기 때문에이 코드는 더 많은 메모리가 할당되었음을 감지하여 메모리 맵을 업데이트해야한다고 결정합니다. 다음 OS는 문제가되지 않습니다. 불행히도 이것은 모든 부팅 실패에 대해 반복되므로 결국 부팅에 실패 할 수있는 빈도에 대한 “하드 한계”가 있습니다.
TianoCore의 코드에는 변수가 없거나 변형 된 경우 (대체 코드를 올바르게 이해하면 최대 두 번의 추가 재부팅 비용이들 수 있지만) Lenovo에 백업 변수가 포함되어 있다는 사실을 고려할 때 대체 옵션이 있습니다. TianoCore에 존재하지 않는 경우)이 폴백을 신뢰하지 않기로 결정했으며 LoaderData 유형의 경우 800MB를 뺀 가장 오래된 백업으로 되돌 렸습니다. 이는 효과적인 667MB 하드웨어 예약 메모리를 제공합니다 (지금은 충분합니다). 그리고 그것은 작동합니다 🙂
교훈
-
UEFI 부팅이 실패하고 부팅 메뉴로 돌아 가면 다른 부팅을 시도하지 말고 시스템을 다시 설정하십시오. 코드를 트리거하지 않기를 바랍니다. 그렇다면 게시물을 업데이트합니다.
-
EFI 셸에는 EFI 변수를 편집하고 이러한 문제를 해결하는 데 사용할 수있는 16 진 편집기가 있습니다.
-
벤더가 당신을 도울 수 없거나 도와주고 싶지 않더라도 고집을 부리지 마십시오. 결국 당신은 해결책을 찾을 것입니다 (몇 달 후에도)