联想收了Phoenix，BIOS要变天？

#1 snarky__x 2026-05-12 08:04

[链接]

联想居然把Phoenix BIOS业务给吞了，说真的，这比我看到Linux 7.0还意外。当年AMI、Phoenix、Award三足鼎立的时候，我还在论坛上跟人吵NTFS驱动呢，没想到如今Phoenix直接成了联想的部门。

搞内核的都知道，BIOS/UEFI看着只是开机时闪一下的破界面，实际上操作系统和硬件之间的烂账全堆在这儿。ACPI表填错了，Linux直接睡死；SMM中断写歪了，你的键盘随机失联。Phoenix的代码库积累了几十年x86平台的阴间 corner case，联想这下等于把PC启动的“暗桩”一把攥手里了。

离谱的是，这边龙芯还在吭哧吭哧推自主指令集和开源固件，那边联想直接买下成熟IP走捷径。两条路无所谓高下，可问题是——以后Think系列的固件bug，联想会不会老老实实往upstream修？还是说继续搞那种“Windows启动完美，Linux随机暴毙”的祖传秘方？
我去
绝了，别最后花了大钱，就为了让老子的笔记本多睡死几次。

#2 lol49 2026-05-12 08:10

[链接]

笑死联想这是把祖传bug库直接买断以后ThinkPad装Linux怕不是得先烧柱香

#3 sweat 2026-05-12 09:36

[链接]

这吐槽精准到位，Phoenix的老代码确实像铁桶阵。我当年熬大夜调底层驱动，全靠死磕硬扛。联想接手正好清理烂账，btw，新固件直接刷，干就完了！

#4 void_73 2026-05-12 11:17

[链接]

lol49你这比喻到位，不过实际情况比烧香更魔幻一点。我在肯尼亚这边给工地装监控系统，去年搞了批ThinkPad T14装Ubuntu 22.04，ACPI表里有三个method的返回值跟Linux内核预期的不一致，直接导致suspend后唤醒时屏幕背光不亮。

查了kernel bugzilla，发现这问题从2019年就有人报了，Phoenix那边给的workaround是"请使用Windows的Modern Standby"。典型的vendor lock-in思路，用固件层面的小动作让第三方系统难受但又不算完全不能用。

现在联想收了Phoenix，我倒是觉得对Linux兼容性可能是利好。你想，以前Phoenix作为独立vendor，它的KPI是让OEM客户（联想戴尔惠普）满意，而OEM的诉求是Windows认证一次过、成本最低。Linux兼容性？简单说那属于nice to have，优先级排到爪哇国去了。现在Phoenix成了联想内部部门，如果联想自己想把Linux support做好（他们这几年在Linux社区确实活跃了不少），反而能直接推动固件层改代码，不用像以前那样走vendor沟通的漫长流程。
其实
当然前提是联想真愿意投入。从他们最近对Fedora和Ubuntu的认证机型数量来看，趋势是好的。不过Phoenix那堆legacy code确实是个雷区，有些bug fix的注释写着"// Don’t touch, it works"，改一行可能炸一片。我在Reddit上看到过Phoenix前员工吐槽，说他们的build system还在用Python 2.7…，CI pipeline跑一次要6小时。

所以与其烧香，不如多给联想Linux团队提bug report，现在他们至少能直接改固件了，不用转发邮件等三个月。

#5 couchive 2026-05-12 13:25

[链接]

笑死烧香怕是不够还得备个风扇哈哈哈我这边非洲工地上的ThinkPad装Fedora直接热到BIOS抽风

#6 null83 2026-05-12 14:05

[链接]

看了下lol49和void_73的回复，方向都对，但我觉得还漏了个关键点——这次收购对固件开源生态的冲击，可能比单台机器的ACPI bug更值得关注。其实
简单说
Phoenix的代码库我十几年前做嵌入式Linux移植时打过交道，说实话，那里面大量SMM handler是用汇编嵌C写的，很多函数连基本的输入校验都没有。当年为了适配一个非标的Super I/O芯片，我反汇编过他们的一段SMI处理代码，注释少得可怜，全靠经验猜寄存器用途。这种代码能跑到现在，靠的是x86平台向后兼容的执念，而不是工程质量的优秀。联想接手后，如果要重构这部分，工作量不亚于重写半个kernel的驱动层；如果不动，那等于花钱买了个需要持续喂人力的legacy黑洞。

简单说更值得想的是coreboot和LinuxBoot的未来。过去Phoenix作为独立vendor，虽然不开源，但至少不会主动给开源固件使绊子。现在它变成联想内部部门，Think系列产品的固件策略很可能收紧——我猜不出三年，主流ThinkPad的coreboot移植会变得更难，因为联想想把Phoenix的“增值特性”（比如他们的Secure Wipe、特定电源管理profile）作为差异化卖点锁死在闭源固件里。void_73提到的Modern Standby那类问题，本质是vendor用固件实现绑定操作系统体验，这种倾向在收购后只会强化。

技术上多说一句：UEFI规范里DXE driver的加载顺序和依赖关系，Phoenix的实现有很多private protocol，这些协议文档不全，导致开源UEFI payload（比如TianoCore的衍生版本）在模拟Phoenix环境时经常卡在BDS阶段。如果联想把这些private protocol进一步和自家硬件绑定，未来想在ThinkPad上跑完全开源的UEFI固件，相当于要逆向一整套闭源DXE栈，那可比现在调ACPI表恶心多了。
其实
当然也不是全无利好。Phoenix的工程师团队里有一批真懂x86底层的人，联想如果愿意投入资源让他们去修复Linux兼容性，而不是只伺候Windows，那对社区反而是好事。判断标准很简单：看未来一年fwupd上联想提交的更新数量和质量。如果这个数字暴跌，那就说明联想把Phoenix当成护城河在挖，而不是桥梁。

#7 maple_x 2026-05-12 20:17

[链接]

void_73, post: 167377

笑死联想这是把祖传bug库直接买断以后ThinkPad装Linux怕不是得先烧柱香

lol49你这比喻到位，不过实际情况比烧香更魔幻一点。我在肯尼亚这边给工地装监控系统，去年搞了批ThinkPad T14装Ubuntu 22.04，ACPI表里有三个method的返回值跟Linux内核预期的不一致，直接导致suspend后唤醒时屏幕背光不亮。

查了kernel bugzilla，发现这问题从2019年就有人报了，Phoenix那边给的workaround是"请使用Windows的Modern Standby"。典型的vendor lock-in思路，用固件层面的小动作让第三方系统难受但又不算完全不能用。

现在联想收了Phoenix，我倒是觉得对Linux兼容性可能是利好。你想，以前Phoenix作为独立vendor，它的KPI是让OEM客户（联想戴尔惠普）满意，而OEM的诉求是Windows认证一次过、成本最低。Linux兼容性？简单说那属于nice to have，优先级排到爪哇国去了。现在Phoenix成了联想内部部门，如果联想自己想把Linux support做好（他们这几年在Linux社区确实活跃了不少），反而能直接推动固件层改代码，不用像以前那样走vendor沟通的漫长流程。

其实

当然前提是联想真愿意投入。从他们最近对Fedora和Ubuntu的认证机型数量来看，趋势是好的。不过Phoenix那堆legacy code确实是个雷区，有些bug fix的注释写着"// Don’t touch, it works"，改一行可能炸一片。我在Reddit上看到过Phoenix前员工吐槽，说他们的build system还在用Python 2.7…，CI pipeline跑一次要6小时。

所以与其烧香，不如多给联想Linux团队提bug report，现在他们至少能直接改固件了，不用转发邮件等三个月。

void_73 在肯尼亚装监控那段让我想起以前在NUS做嵌入式课设的时候，调ACPI调到头秃。你说的那个"请使用Windows的Modern Standby"真的绝了，我当年debug一个S3唤醒问题，Phoenix那边的FAE也是甩过来一句"建议用Windows测试"，气得我差点把开发板扔出窗外…

不过话说回来，你提到联想在Linux社区活跃度上升这点我倒是挺有感触的。去年他们给Fedora贡献了不少thinkpad-acpi的patch，有些还是直接改固件层的。如果这次收购能让固件团队和kernel开发者坐在一起开会，那确实比之前那种vendor沟通效率高多了。

btw，肯尼亚工地那边电压稳吗？我以前在印尼出差遇到过电压波动把BIOS flash搞坏的情况…( ･᷄ὢ･᷅ )

#8 velvet2004 2026-05-13 00:22

[链接]

void_73, post: 167377

笑死联想这是把祖传bug库直接买断以后ThinkPad装Linux怕不是得先烧柱香

lol49你这比喻到位，不过实际情况比烧香更魔幻一点。我在肯尼亚这边给工地装监控系统，去年搞了批ThinkPad T14装Ubuntu 22.04，ACPI表里有三个method的返回值跟Linux内核预期的不一致，直接导致suspend后唤醒时屏幕背光不亮。

查了kernel bugzilla，发现这问题从2019年就有人报了，Phoenix那边给的workaround是"请使用Windows的Modern Standby"。典型的vendor lock-in思路，用固件层面的小动作让第三方系统难受但又不算完全不能用。

现在联想收了Phoenix，我倒是觉得对Linux兼容性可能是利好。你想，以前Phoenix作为独立vendor，它的KPI是让OEM客户（联想戴尔惠普）满意，而OEM的诉求是Windows认证一次过、成本最低。Linux兼容性？简单说那属于nice to have，优先级排到爪哇国去了。现在Phoenix成了联想内部部门，如果联想自己想把Linux support做好（他们这几年在Linux社区确实活跃了不少），反而能直接推动固件层改代码，不用像以前那样走vendor沟通的漫长流程。

其实

当然前提是联想真愿意投入。从他们最近对Fedora和Ubuntu的认证机型数量来看，趋势是好的。不过Phoenix那堆legacy code确实是个雷区，有些bug fix的注释写着"// Don’t touch, it works"，改一行可能炸一片。我在Reddit上看到过Phoenix前员工吐槽，说他们的build system还在用Python 2.7…，CI pipeline跑一次要6小时。

所以与其烧香，不如多给联想Linux团队提bug report，现在他们至少能直接改固件了，不用转发邮件等三个月。

void_73，看到你在肯尼亚工地那段，我突然想起去年暑假的事。其实

那天傍晚我从琴行回来，路过学校机房，灯还亮着。我觉得吧进去一看，学长正对着一台ThinkPad T480发呆，屏幕上黑底白字，滚动着kernel panic的调用栈。话说回来他桌上摊着三包速溶咖啡的包装袋，键盘旁边放着一本翻烂了的《Understanding the Linux Kernel》。我问他在干嘛，他说"在跟Phoenix的ACPI表谈恋爱"。

他说这话的时候窗外正好下起雨，雨点打在机房那扇永远关不严的窗户上，噼里啪啦的。我那时候刚学会编译内核，连DSDT是什么都不知道，只觉得他那个样子特别像电影里被困在孤岛上的程序员——明知道问题在哪儿，但就是够不着。

你提到那个"请使用Windows的Modern Standby"的workaround，让我想起一句歌词，Bob Dylan唱的，“You don’t need a weatherman to know which way the wind blows”。Phoenix那帮人当然知道风往哪儿吹，他们只是不在乎Linux用户被淋成什么样。几十年的x86兼容性代码堆在那儿，像一座谁也不敢动的老坟，上面长满了向后兼容的杂草，拨开一看，底下全是90年代的汇编注释。

不过你说的有道理，联想收了之后反而可能是转机。就像有时候，你只有把一盆花从阳台搬进屋里，它才不再是"那盆阳台上的花"，而变成了"你的花"。归属感这东西很奇怪，它能让一个部门突然觉得Linux兼容性不再是别人家的事。
嗯…
我弹吉他的时候也有这种感觉。一把琴放在琴行里，它就是商品；但你把它买回家，调好弦，弹出第一个和弦的时候，它突然就变成了你的一部分。你会在意它面板上每一道划痕，会为它找最合适的琴弦。联想现在大概也是这样，Phoenix不再是别人的代码库了，是他们自己的。

只是不知道那些几十年前的corner case，会不会在某一天，被一个刚入职的年轻工程师翻出来，然后他看着那段没有注释的汇编，愣了很久，最后在commit message里写了一句"fixed a legacy issue, no idea what it was doing"。

#9 bored6 2026-05-13 00:58

[链接]

void_73, post: 167377

笑死联想这是把祖传bug库直接买断以后ThinkPad装Linux怕不是得先烧柱香

lol49你这比喻到位，不过实际情况比烧香更魔幻一点。我在肯尼亚这边给工地装监控系统，去年搞了批ThinkPad T14装Ubuntu 22.04，ACPI表里有三个method的返回值跟Linux内核预期的不一致，直接导致suspend后唤醒时屏幕背光不亮。

查了kernel bugzilla，发现这问题从2019年就有人报了，Phoenix那边给的workaround是"请使用Windows的Modern Standby"。典型的vendor lock-in思路，用固件层面的小动作让第三方系统难受但又不算完全不能用。

现在联想收了Phoenix，我倒是觉得对Linux兼容性可能是利好。你想，以前Phoenix作为独立vendor，它的KPI是让OEM客户（联想戴尔惠普）满意，而OEM的诉求是Windows认证一次过、成本最低。Linux兼容性？简单说那属于nice to have，优先级排到爪哇国去了。现在Phoenix成了联想内部部门，如果联想自己想把Linux support做好（他们这几年在Linux社区确实活跃了不少），反而能直接推动固件层改代码，不用像以前那样走vendor沟通的漫长流程。

其实

当然前提是联想真愿意投入。从他们最近对Fedora和Ubuntu的认证机型数量来看，趋势是好的。不过Phoenix那堆legacy code确实是个雷区，有些bug fix的注释写着"// Don’t touch, it works"，改一行可能炸一片。我在Reddit上看到过Phoenix前员工吐槽，说他们的build system还在用Python 2.7…，CI pipeline跑一次要6小时。

所以与其烧香，不如多给联想Linux团队提bug report，现在他们至少能直接改固件了，不用转发邮件等三个月。

void_73你在肯尼亚工地还盯着ACPI表看，这可比我们当年在机房调屏幕分辨率刺激多了哈哈哈

说起vendor lock-in，我留学时候刷盘子那家店老板有台老ThinkPad X220，我手贱给装了Debian，结果合盖休眠之后风扇直接全速转停不下来。查了三天论坛，最后发现是Phoenix固件里有个S3 state的flag设置反了，得进Windows改个注册表在重启才行。我当时就想，这不就是故意恶心人吗

现在联想收了Phoenix，起码不用两头扯皮了。不过就怕他们把祖传bug当传家宝，毕竟老代码跑得动就别动，这心态做硬件的都懂

#10 pixel 2026-05-13 06:40

[链接]

couchive，你那个"热到BIOS抽风"不是段子，是thermal throttling和SMM交互的经典bug。Fedora默认的thinkpad_acpi驱动在读取thermal zone时，如果BIOS的_CRT和_PSV这两个method返回值格式不对，kernel会fallback到80度的保守阈值，然后EC风扇曲线直接拉满——但实际CPU才60度出头。
其实
我去年在首尔帮一个咖啡店修他们的ThinkPad X1 Carbon（装Arch，대박，那家店的浓缩咖啡是真不错），症状跟你描述的一模一样。最后发现是BIOS里一段SMM代码在thermal interrupt触发时，会错误地覆写EC的fan control register。解决方法也简单：用acpi_override把DSDT里那个_CRT method的返回值硬编码成95度，然后modprobe thinkpad_acpi时加fan_control=1参数。

不过话说回来，联想收购Phoenix后如果能统一维护thermal相关的ACPI实现，反而是好事。现在的情况是同一台ThinkPad，Windows下的thermal profile和Linux下完全是两个世界，根因就是Phoenix那帮人写firmware时只对着Windows的驱动调参。联想内部如果能把firmware team和Linux compatibility team打通，至少不会出现"装Fedora风扇起飞"这种低级问题。

你那边工地环境温度多少？如果超过40度，建议直接改/etc/modprobe.d/thinkpad_acpi.conf，把fan speed下限调到level 3以上。

#11 chill71 2026-05-13 06:48

[链接]

void_73, post: 167377

笑死联想这是把祖传bug库直接买断以后ThinkPad装Linux怕不是得先烧柱香

lol49你这比喻到位，不过实际情况比烧香更魔幻一点。我在肯尼亚这边给工地装监控系统，去年搞了批ThinkPad T14装Ubuntu 22.04，ACPI表里有三个method的返回值跟Linux内核预期的不一致，直接导致suspend后唤醒时屏幕背光不亮。

查了kernel bugzilla，发现这问题从2019年就有人报了，Phoenix那边给的workaround是"请使用Windows的Modern Standby"。典型的vendor lock-in思路，用固件层面的小动作让第三方系统难受但又不算完全不能用。

现在联想收了Phoenix，我倒是觉得对Linux兼容性可能是利好。你想，以前Phoenix作为独立vendor，它的KPI是让OEM客户（联想戴尔惠普）满意，而OEM的诉求是Windows认证一次过、成本最低。Linux兼容性？简单说那属于nice to have，优先级排到爪哇国去了。现在Phoenix成了联想内部部门，如果联想自己想把Linux support做好（他们这几年在Linux社区确实活跃了不少），反而能直接推动固件层改代码，不用像以前那样走vendor沟通的漫长流程。

其实

当然前提是联想真愿意投入。从他们最近对Fedora和Ubuntu的认证机型数量来看，趋势是好的。不过Phoenix那堆legacy code确实是个雷区，有些bug fix的注释写着"// Don’t touch, it works"，改一行可能炸一片。我在Reddit上看到过Phoenix前员工吐槽，说他们的build system还在用Python 2.7…，CI pipeline跑一次要6小时。

所以与其烧香，不如多给联想Linux团队提bug report，现在他们至少能直接改固件了，不用转发邮件等三个月。

void_73 你这段真的把我看笑了 “请使用Windows的Modern Standby” 这回复简直是典中典我前公司采购那批ThinkPad P1也是 suspend醒不来最后解决方案是——把盖子合上这件事戒掉改用关机
对了
不过说真的联想这几年在Linux社区确实刷了不少存在感我之前折腾Legion系列的hybrid graphics 居然在Lenovo的官方GitHub找到了还算能看的文档虽然最后还是要自己patch一下但至少比Phoenix时代那个"请咨询您的OEM"强八百倍

肯尼亚装监控这个经历有点东西啊那边电网稳定吗我很好奇你们是不是整了一堆UPS当传家宝用
嘿嘿
反正我现在心态就是收购归收购代码能开源再吹不然不过是换了个logo的祖传shit山罢了

btw 你那个背光不亮的问题最后是不是自己写了个ACPI override丢进initramfs了还是直接放弃治疗上systemd