系统与基础设施downtowndougbrown.com
在不支持 16GB 内存的主板上塞进 16GB 内存
Adventures of putting 16 GB of RAM in a motherboard that doesn’t support it
2019 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者在官方标称不支持 16GB 内存的旧主板上强行加装大内存，记录了从查证规格、排查蓝屏到修改 ACPI/DSDT 等一系列折腾过程，最终成功让系统识别全部内存。文章展示了“不支持”往往只是厂商未测试，而非物理不可行。
为什么经久不衰：它把硬件规格背后的真相和排查思路讲得清晰有趣，对任何想榨干旧硬件性能的人都有启发，因此多年后仍被反复讨论。
HN 评论精选
批评 Windows 10 隐藏蓝屏错误参数，错误界面应保留技术信息而非追求美观
我需要找到旧版 Windows 蓝屏时会显示的四个错误参数。Windows 10 默认隐藏了这些信息，但可以通过修改注册表重新开启显示。我讨厌这种设计。把参数藏起来有什么意义？错误界面不需要漂亮，需要的是功能性。可以有一个清晰友好的错误提示，但屏幕上应保留技术信息。想象一下，比电脑无法启动更让人恼火的，就是它不告诉你问题所在，除非你改注册表——而它无法启动时你根本改不了。保留这些信息没有任何坏处，还能让人有东西可以搜索。
CharlesColeman查看英文原文
> In order for the document to help me, I clearly needed to find the four error parameters that used to be displayed with the blue screen on older versions of Windows. Windows 10 hides all the information by default, but I discovered that it’s possible to re-enable display of the extra error information by adding an entry to your registry. I hate stuff like this. What's the point of hiding the parameters, instead of tucking them away in the corner of the screen or something? It just makes things needlessly difficult. I know the answer is going to be "but it makes the UI look beautiful and most users don't know what the parameters mean anyway!" Error UIs don't need to be beautiful, they need to be functional. Definitely have a nice, clear user-friendly error message, but keep the overall screen technically informative. I can imagine that the only thing more infuriating than having a computer that won't boot, is having one that won't tell you the problem unless you change registry settings (which you can't, because it can't boot). Leaving the extra information there does not harm, and it give people something to Google if they do run into a problem.
回忆当年绕过 BIOS 内存映射限制的经历，赞文章有趣
这让我回想起 2003 年往主板里塞 3.5-4GB 内存的日子。在多次向主板厂商反馈需求、他们把 BIOS 改得只对某一种内存配置有效之后，我最终放弃了指望 BIOS。我在 Linux 启动流程里加了代码，无视 BIOS 提供的内存映射，自己查询物理内存条并手工重建映射表。虽然年代久远已分不清 e820 和 MTRR，但这仍是篇有趣的文章。
uranium查看英文原文
Man, this gave me flashbacks to trying to put 3.5-4GB of RAM into motherboards in 2003. After a bunch of iterations of telling the motherboard manufacturers what we wanted, and having them hack the BIOS to work for exactly one DIMM configuration, then fail on anything else, I eventually gave up expecting most of the BIOS to work at all. I added code to the Linux startup sequence that ignored everything the BIOS said about memory maps, queried what physical DIMMS were there, and rebuilt my maps by hand. It's been so long that I can't tell an e820 map from an MTRR, but this was still a fun read.
“不支持”可能只是厂商懒得测试或写文档，未必真的不可行
在 IT 行业你很快会学到，“不支持”的含义可以从“物理上不可能”到“我们不想让你这么做”不等。就内存而言，物理不可能意味着 CPU 地址位不够或 PCB 走线缺失，但同容量的内存条有很多未公开的配置差异，厂商标注较低的最大值可能只是为了避免回答那些微妙的问题。比如 2x8GB 可以但 1x16GB 不行。也可能是“X 条件下可以但 Z 除外”的情况，厂商只是懒得把所有组合都写进文档。想测试内存是否全部可用，跑 MemTest86 之类的工具就够了。
userbinator查看英文原文
One of the things you'll quickly learn from working in IT (and probably other fields) is that "not supported" can mean anything from "physically impossible" to "we don't want you to". In the case of RAM, "physically impossible" would mean something like the CPU not having that many address bits or the PCB traces not routed, but there are a lot of different not-well-advertised configurations of DIMMs available with the same size[1], so it could be that the manufacturer specified a lower maximum just to avoid having to answer subtle questions. For example, 2x8GB may be OK but 1x16GB not. It could also be a "X if Y except Z else B" situation, and they just couldn't be bothered to document all the possible combinations and/or explain the details of the PC system architecture that result in such limitations. To test if all the memory is present (and if it all works correctly), running something like MemTest86 might be sufficient. [1] https://en.wikipedia.org/wiki/Memory_geometry
亲身经历印证官方规格上限常常是虚的，还吐槽 ACPI 表兼容性的坑
我曾想把一台旧戴尔台式机装成 Hackintosh，收集硬件时所有文档都坚称它最高只支持 4GB。这是一台晚期 Core 2，这说法在我看来完全不合理（我拥有的 Core 2 没有低于 8GB 的），结果 8GB 用得完全没问题。有趣的是，和文章作者一样，我也在那台机器上遇到了 DSDT 相关的问题：用 Intel 标准工具重新编译 ACPI 表根本不行。后来发现有两个编译器，Intel 的和微软的，微软那个对垃圾输入极其宽容。最终查明，原厂 ACPI 表的逻辑是除非操作系统向 ACPI 自报为 Vista（精确的 Vista，而不是 Vista+），否则 HPET 和睡眠等功能根本无法工作。真是折磨。
benjaminpv查看英文原文
I was looking to Hackintosh an older Dell desktop I had squirreled away and in the process of gathering all the hardware every piece of documentation I found insisted that it topped out at 4GB. This was a late-era Core 2 so that seemed completely nonsensical to me (I don't think I ever owned a Core 2 that had less than 8) and, wouldn't you know it, 8GB worked perfectly fine. Funnily enough, like the article's author I also encountered a DSDT-related problem on that same system: if you were to dump the tables and recompile them with the standard Intel utility it straight up wouldn't work. Came to find out that there are apparently two compilers, one from Intel and another from MS and the MS one is super-lenient about accepting garbage. Eventually worked out that the logic in the stock tables was such that several features (HPET and sleep, iirc) just straight up don't work unless the OS identifies itself to ACPI as Vista (and not like Vista+, Vista exclusively). Such a pain.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选