GreeK
2025-07-16T13:39:45+00:00
现在论坛里有一种很深的误解，认为缩缸是因为英特尔出厂设定“超太猛了”，以及认为限压、限频能够预防缩缸的。这些想法是很危险的。
你们可以去读一下英特尔自己关于12B微码针对的问题是怎么写的：
[quote]Microcode and BIOS code requesting elevated core voltages which can cause Vmin shift especially during periods of idle and/or light activity.
微码和BIOS程序在静止或轻载情况下会请求过高的电压，可能会导致临界电压偏移。[url]https://community.intel.com/t5/Blogs/Tech-Innovation/Client/Intel-Core-13th-and-14th-Gen-Desktop-Instability-Root-Cause/post/1633446[/url][/quote]怎么会出现轻载电压过高？我立刻就联想到极有可能是在某种情况下产生了[url=https://zh.wikipedia.org/wiki/%E6%95%B4%E6%95%B0%E6%BA%A2%E5%87%BA]数值下溢[/url]，在验证中没有覆盖到。于是一个轻载自动降压省电、降着降着就突然降到了1.65V的CPU就这么上市了。英特尔自己永远不会直接承认：他的AVS系统(在芯片里电路实现的Boost算法)出了恶性Bug。
它肯定也不是所有轻载工况都会召唤高压电自己，不然是不会躲过所有测试环节的。一定是在某种测试未覆盖到的特殊情况下(比如片上分布的CPM探针回报的压降、温度情况散布在某个特定范围里时)会触发下溢，-1=255，一下子把电压拉满。打个比方，你平时跑跑跳跳都没事，看起来像个正常人，但每当先迈左腿上第三层楼梯的时候就会癫痫发作，所以体检查不出来。
如果猜测是真的，这种Bug不太可能通过微码彻底修复。微码能起到的作用是调节一些参数，让这种下溢处在更难触发的范围里。按上一个比方，就像让你从四楼搬到二楼去住，这样你需要爬三楼楼梯的机会就少了。
在往常这种设计有误的硬件是要召回的，比如当年FDIV Bug，牢英为召回计提了4.75亿美金(1995年)。但是现在英特尔正深困于财务危机当中，已经在不断割肉卖产业、裁员改善现金流的状态，再进行一次相当规模的召回，牢英直接破产了。
所以牢英这回的策略很简单：认了必死，所以死也不认，责任必须往外甩。比如一开始赖板厂不遵循“Intel Default Settings”；人家遵循了还缩，就没事发几个微码，每次都说这次一定修好了；过一阵子再缩再发，不断刷新你的耐心。反正就是不能承认是需要召回的硬件缺陷，不承认只是不要脸慢慢砸招牌，承认了原地暴毙。
已经造出来的残次品怎么办？当然是无事发生接着卖。搞点水军洗一洗，反正下一代产品马上都出来了，忍一忍就过去了。
所以最新微码修好了吗？你就猜吧，猜着猜着这事就过去了。
所以，假设以上猜测都成立(你信我，大概率就这么回事)，一些危险的错误认知需要纠正：
佯谬：是英特尔官超太猛了
驳斥：只是这样一个微码降降频就搞定了，不会像现在这样三番五次地修，夏天一来仍然大面积暴雷。
佯谬：不重度使用就不会缩
驳斥：这U的问题是轻载时召唤高压电自己，你若一直重载烤着机用可能反倒问题小一点
(但缩了之后也更快影响你的工作，这绝不是建议重载用户买这些残次品)
佯谬：限压限频使用就不缩了
驳斥：限制工作范围相当于额外准备出了裕量给缩缸来吃，但不解决缩缸问题，相当于加厚了血条但还站在毒圈里，早晚还是会死的
佯谬：136/146不会缩
驳斥：出厂预设工作范围保守而已，早晚还是会死的
你们可以去读一下英特尔自己关于12B微码针对的问题是怎么写的：
[quote]Microcode and BIOS code requesting elevated core voltages which can cause Vmin shift especially during periods of idle and/or light activity.
微码和BIOS程序在静止或轻载情况下会请求过高的电压，可能会导致临界电压偏移。[url]https://community.intel.com/t5/Blogs/Tech-Innovation/Client/Intel-Core-13th-and-14th-Gen-Desktop-Instability-Root-Cause/post/1633446[/url][/quote]怎么会出现轻载电压过高？我立刻就联想到极有可能是在某种情况下产生了[url=https://zh.wikipedia.org/wiki/%E6%95%B4%E6%95%B0%E6%BA%A2%E5%87%BA]数值下溢[/url]，在验证中没有覆盖到。于是一个轻载自动降压省电、降着降着就突然降到了1.65V的CPU就这么上市了。英特尔自己永远不会直接承认：他的AVS系统(在芯片里电路实现的Boost算法)出了恶性Bug。
它肯定也不是所有轻载工况都会召唤高压电自己，不然是不会躲过所有测试环节的。一定是在某种测试未覆盖到的特殊情况下(比如片上分布的CPM探针回报的压降、温度情况散布在某个特定范围里时)会触发下溢，-1=255，一下子把电压拉满。打个比方，你平时跑跑跳跳都没事，看起来像个正常人，但每当先迈左腿上第三层楼梯的时候就会癫痫发作，所以体检查不出来。
如果猜测是真的，这种Bug不太可能通过微码彻底修复。微码能起到的作用是调节一些参数，让这种下溢处在更难触发的范围里。按上一个比方，就像让你从四楼搬到二楼去住，这样你需要爬三楼楼梯的机会就少了。
在往常这种设计有误的硬件是要召回的，比如当年FDIV Bug，牢英为召回计提了4.75亿美金(1995年)。但是现在英特尔正深困于财务危机当中，已经在不断割肉卖产业、裁员改善现金流的状态，再进行一次相当规模的召回，牢英直接破产了。
所以牢英这回的策略很简单：认了必死，所以死也不认，责任必须往外甩。比如一开始赖板厂不遵循“Intel Default Settings”；人家遵循了还缩，就没事发几个微码，每次都说这次一定修好了；过一阵子再缩再发，不断刷新你的耐心。反正就是不能承认是需要召回的硬件缺陷，不承认只是不要脸慢慢砸招牌，承认了原地暴毙。
已经造出来的残次品怎么办？当然是无事发生接着卖。搞点水军洗一洗，反正下一代产品马上都出来了，忍一忍就过去了。
所以最新微码修好了吗？你就猜吧，猜着猜着这事就过去了。
所以，假设以上猜测都成立(你信我，大概率就这么回事)，一些危险的错误认知需要纠正：
佯谬：是英特尔官超太猛了
驳斥：只是这样一个微码降降频就搞定了，不会像现在这样三番五次地修，夏天一来仍然大面积暴雷。
佯谬：不重度使用就不会缩
驳斥：这U的问题是轻载时召唤高压电自己，你若一直重载烤着机用可能反倒问题小一点
(但缩了之后也更快影响你的工作，这绝不是建议重载用户买这些残次品)
佯谬：限压限频使用就不缩了
驳斥：限制工作范围相当于额外准备出了裕量给缩缸来吃，但不解决缩缸问题，相当于加厚了血条但还站在毒圈里，早晚还是会死的
佯谬：136/146不会缩
驳斥：出厂预设工作范围保守而已，早晚还是会死的