关于e820cycles参数

liuzhaoyzz

关于e820cycles参数
http://bbs.wuyou.net/forum.php?m ... &fromuid=298214
mdyblog 发表于 2014-11-20 06:20
"map --int15nolow=1"  还是 失败。
Video driver failed to initialized.

好的，你这个报告很好，说明了 int15nolow 不起作用，已经被新的 e820cycles 取代了。

那以后，我们就更简单了，只使用 e820cycles 来控制即可。

现实世界是复杂的，是不那么理想的。我们都想简单，省事，但有可能办不成事。

我们采用的默认值，是依据一个没有 bug 的电脑的情况的。我们的默认值不可能以一个 buggy 的电脑为准。所以，你的想法不能够实现。不兼容性是应该避免的，但是我们的软件是向前发展的，是不断完善的。旧版本不具有 e820cycles 的调整能力，它就应该被淘汰。既然旧版本淘汰了，那么也就不存在不兼容性了。

http://bbs.wuyou.net/forum.php?m ... &fromuid=298214
不点发表于 2014-11-20 17:43:54
>>> e820cycles=0
>>> 有时反倒有副作用，反倒启动不了。这个参数e820cycles很不友好。

mdyblog,您是 grub4dos 发展过程中的强力支持者，您是有功之人。尤其是通过本次您的报告，我终于理清了 int15nolow 以及 e820cycles 的关系，知道了 int15nolow 只是阶段性认识的产物，而 e820cycles 才从根本上定位了根源。所以，int15nolow 参数可以废弃了。

我这个帖子，既是给您作进一步的解释，也是给 grub4dos 的维护者做个彻底的技术汇报。

最开始的时候，在英文论坛上，karyonix、 Shao 以及其他开发人员发现，grub4dos 的 int15 不保护常规内存（中的 int13 代码空间），只保护扩展内存（中的内存盘映像） ，这是导致某些蓝屏（或死机）问题的根源。以前我们保护常规内存的 int13 代码空间是通过 0x413 处的用户可用常规内存量来实现的，原以为这样也就 OK 了，但 karyonix 和 Shao 等人的发现，迫使我们完善 int15 处理程序，把常规内存中的 int13 代码也通过 int15 保护起来。这样就是双重保护，一个是利用BIOS 数据区 0x413 处的内存规范，另一个是利用 int15 规范。

接下来，我们中文区的用户很快报告，新版本引起蓝屏死机，还不如旧版本。寻找问题的根源花费了很长时间，终于知道，是增加 int15 代码处理 low memory（即常规内存）而引起的。所以，发明了 int15nolow 参数来应付这些情况。int15nolow=1 时，不再用 int15 保护常规内存。

与此同时，另外有用户报告，即使设定 int15nolow=1，仍有蓝屏死机发生。这就需要进一步通过试验来确定蓝屏死机的原因。最终确定，只要接管 int15 即可导致蓝屏死机，不接管 int15，则可以进入 Windows。在 int15 处理程序的最开头用一条 far jmp 指令跳转到原始的 ROM int15 的入口，则发生完全相同的蓝屏死机现象，连出错码都一样。这就证明了，int15 是不可以接管的，只要接管就蓝屏死机。需要说明的是，发生蓝屏死机的，也只是一部分机器，其他正常的机器也有很多，似乎正常的机器比蓝屏的机器多，蓝屏的是少数，但蓝屏的机器也占有很大的比例，不能忽略不计。后来有人报告，通过更换显卡驱动为 win7 下的驱动，可以解决蓝屏问题。再加上其他大量的用户报告，给开发者提供了重要信息。我们于是逐步明白了，那仅仅是显卡驱动程序的 bug 而已，一部分显卡驱动有问题，而别的厂家的 XP 显卡驱动却没问题。

那时我还没有意识到 int15nolow 与 e820cycles 其实都是在解决同一个问题。int15nolow 的解决方法没有找到症结，它只是阶段性的成果。最终 e820cycles 的解决办法才是对症下药。

现在我已经明白了 int15nolow 的解决办法是靠不住的，根本有效的解决办法是采用 e820cycles 来控制。

http://bbs.wuyou.net/forum.php?m ... &fromuid=298214
不点 发表于 2014-11-20 18:22:49 |
我说的是 “没有需要保护的内存盘”  的情况下。 比如根本没有用  "map --mem" 。


不使用内存盘，也得用 int15 保护常规内存中的 grub4dos int13 代码空间，就是前面提到的双重保护。以前我们只用 BIOS 数据区 0x413 的内存规范来保护，但这不够，karyonix，SHao 等开发者发现必须用 int15 来保护，否则在一些机器上会发生死机。然而，当我们用 int15 保护 int13 代码空间时，必然接管 int15，因而必然造成那些 buggy 显卡驱动的蓝屏死机（请看我前一帖的技术汇报）。这才引出了 e820cycles 的处理方法。

int15 内存规范，是 DOS、Windows 以及其他所有的 x86 操作系统以及应用程序所遵守的规范。没有它，DOS 下就无法使用 map --mem 以及 memdisk 来建立虚拟盘，因为 DOS 的内存管理软件要使用 int15，它就有可能把未经保护的内存盘毁掉，造成死机或者在读取虚拟盘时失败。


http://bbs.wuyou.net/forum.php?m ... &fromuid=298214
不点 发表于 2015-1-9 21:14:20
grub4dos 在解决内存冲突方面，作了多次的努力。最早的努力，是 gandalf 发现 grub4dos 总是莫名其妙地死机，然后，我们了解到，那是因为 gnu grub legacy 的保护模式堆栈位于较高内存地址造成的。当某些程序片段使用较多堆栈时，就要发生死机了。对此，我们作了两项改进，其一是把保护模式堆栈撤销，与实模式堆栈合并，只保留一个堆栈；其二是把c语言函数内的数组和局部函数都移出到函数体之外，不再占用堆栈。后来又作了一项改进，那就是，把递归函数修改成非递归的函数，用循环来代替递归，大大减轻了堆栈的负担。所以，后来再也没有出现莫名其妙死机的问题了。

为了解决常规内存太少，没有足够的空间来容纳新的功能代码的问题，从 0.4.5 开始，把保护模式的代码移动到扩展内存中，这样就解决了功能无法扩展的问题了。起初我们使用 16M 内存，后来又增加到 32M。由于有了足够的内存，所以，我们从此可以支持运行用户程序了。

现在的程序代码，也有可能在某些局部范围产生内存冲突。但这都是可以定位的，也是可以解决的。

http://bbs.wuyou.net/forum.php?m ... &fromuid=298214
不点 发表于 2015-2-26 03:47:30

下面是想说给开发者的。

一个软件在功能上尽量可以去完善。但有时候，功能的完善与硬件兼容性发生冲突，迫使你放弃一部分功能，而保证兼容性。一切都是权衡，并无什么绝对的正确性在里面。看问题的角度不同，正确性的概念也不同。也并非所有的用户所提的要求，你都能满足。有可能你满足了一部分用户的要求，却带来了另外的问题。软件不是万能的，它能解决大部分问题，就是基本成功的。如果要以极限挑战的眼光去看问题，那就是企图让功能性达到丰满，这有可能以某种方式损坏兼容性。本问题所提到的 ud 被屏蔽，是我做的。因为grldr启动的时候，要检查是否从ud启动。如果是的，则把 ud 区当作当前 root 区，跳过其他启动步骤。把 ud 区当作当前默认 root 的好处是，ud 区靠前，能够最大限度地适应各种恶劣的 bios 环境。因为优先检查 ud，所以，当后续不是 ud 启动时（比如启动某个软盘映像时，或者启动硬盘的 Windows 时），就不能继续再把 ud 区当作当前 root 了。为了避免 ud 标志被后续的 boot 命令检测到，我在第一次检测 ud 之后，就抹掉了 ud 标志。此时 ud 已经被承认，但后续的启动，如果不是直接模拟 bios 而加载 ud 的第一扇区的话，则无法检测到 ud 标志了，因为这是故意屏蔽掉了。我这说的仍然是现状。至于说这样做是否合理，那我可不敢保证。那将由现在的开发者去权衡和决定。假如能够把这个问题做好，达到两全其美，那也是好事。假如不想动脑筋，不想太费劲去思考这些逻辑问题，那可以保持现状。一句话，看开发者的裁决而定。

在我维护 grub4dos 的时候，对于用户所提的问题，如果我能去解决，我尽量自己去做，这样自己就放心，那是因为自己精力充沛，同时也担心别人做的不符合自己的想法。所以都是尽量由自己来完成。假如我自己完成不了，那我就坦率承认自己做不了，放弃。放弃之后，有可能别人能够做这个工作，那么，这就涉及到这个工作如何融入 grub4dos 的问题。肯定不是无条件都可以随便融入的，一定要经过检验。新的工作往往会带来新的问题。有时候，问题很快都会暴露。但有时候，问题潜藏很深，需要很多年才能暴露。举例来说，原来的 gnu grub legacy 里面的 ntfs 代码有问题，我没有能力写 ntfs 代码，甚至也没有能力看懂 linux 当中的 ntfs 代码，所以，无法解决 ntfs 的有关问题。后来 bean 加入了团队，bean 能够做这个工作，目前的代码就是 bean 的。bean 做这个工作的同时，也把旧的代码保留了下来，好像取名为 fsys_ntfs.old，那意思是，万一不行，还可以恢复原始代码。经过多年的检验之后，确实没问题，所以，旧的代码好像已经删除了。新的代码其实也不是完全没问题，多年以后，chenall 和 yaya 都发现了一些问题，并解决了。还有一个例子是，yaya 对于 grub4dos 的改进和增强。我们看到了，有些问题，例如 mbr 和 pbr 代码中的问题，是最近才发现和解决的。可见，有些问题会潜藏很久。我们为什么长期以来都维护了两个版本，一个是 0.4.5c, 一个是 0.4.6a，那就是因为，对新的功能需要有一个锤炼的过程，新功能有可能影响启动的成功率，也有可能带来兼容性等其他问题。假如这些问题都能得到解决，那么大家就可以放心地使用新版本了。旧版本作为一个参照物，永远保留着它的价值。不同的用户根据自己的需要，选用不同的版本。gandalf 提供的 scdrom 代码，好像存在内存冲突，不稳定，后来由我移植 smart boot manager 的 cdrom 代码，替换了 gandalf 的代码。同样是 gandalf，他所做的基于 vga 图形模式的中文化代码则非常稳定，我们一直保留了下来，直到我们彻底转向 vbe 之前。cdrom 驱动支持是 gandalf 首先引进的，他有首创之功，不可抹杀。我所说的重点在于，代码的稳定性以及后续的表现，是需要锤炼的。这决不等于否认初始工作的价值。类似地，bean 所做的 gfxmenu 图形菜单，也是填补了当时的空缺。只是因为 gfxmenu 天然的独立性，它不同于 grub4dos 的内置代码，它是调用外部的 message 里面的代码，所以，不容易与 grub4dos 无缝对接。所以，我们后来推荐采用新的 vbe 图形菜单模式。karyonix 提供的好几个补丁，都直接采纳了，经过后续若干年的检验，证明是没问题的。大家熟悉的 winvblock 软件的作者是 shao miller，他同时也是 syslinux 的开发团队成员。他所提供的一个与 eltorito cdrom 有关的补丁，刚一开始时，我觉得可以采纳。但后来我仔细想想，还是严格要求吧，是技术就得讲技术，在较好和最好之间就有那么一点点差别，既然能够做到最好或更好，就不能退而求其次。我以 "应该避免占用宝贵的 int13 代码空间" 为理由，在得到 chenall 的同意之后，撤销了 shao miller 的补丁。同时我对 eltorito.sys 这个软件打了补丁，并且纳入到 grub4dos 内部一起维护。这属于 "两种做法都能达到目的，但究竟哪种最好？" 的问题。我主张修改 eltorito.sys 这个软件，而 shao miller 主张修改 grub4dos 的 int13 处理程序。这就是分歧所在。假如是仅凭感情和照顾面子，那确实应该采纳 shao miller 的补丁。但我反复思考，觉得不采纳他的补丁，是对 shao miller 最大的尊重。因为我觉得，那是对他提出了更高的要求，他不属于那种需要照顾面子的人，因此我其实是承认并尊重了他的水平。如果要照顾某个人的面子，实际上则是否认了这个人的高水平，因此适得其反，反而照顾不了他的面子。在我看来，指出一个人的工作中的瑕疵，就是对他的一种极大的尊重。同样地，假如有人指出我的缺陷，我也认为是对我的尊重，是瞧得起我。补充：从后来的实践以及今后长远发展的眼光来看，保持 int13 不被更改的这个做法，其合理性似乎越来越明显了。dos 越来越不适应恶劣的bios环境了，现在 dos 基本上都是作为第二启动，即，首先启动 grub4dos 或 syslinux，然后才能启动 dos。尤其是 dos 作为 eltorito 光盘的主角，已经很不常见了。grub4dos 的用户群，主要是 windows 的。因此，假如仅仅为了很狭窄的、越来越边缘化的领域而修改 int13，那么这种修改，其使用率极低，绝大多数情况下都用不上。而它占用 10 多个字节的宝贵的 int13 代码空间，就越发显得不合理了。所以任何事情都是权衡。也许某件事乍一看是合理的，但经过某种仔细权衡和分析以后，其不合理性就暴露出来了。

过去了的事情，都是历史。历史是可以借鉴的，历史也是可以评判的。没有绝对的正确与错误，只有自己的权衡和倾向。这世界很大，自由度也很大。尤其是对于开源软件来说，自由度是相当大的。自己不满意的事情，可以有很多种处理办法，包括另起炉灶。当初我给 gnu grub 开发团队提交补丁，未被采纳，所以我就被迫另起炉灶。这是完全可以复制的，"另起炉灶" 永远是一个选项。任何人，只要他愿意，他都可以另起炉灶。

现在我离开开发者的行列了，我不再做决定和权衡了。我以往所做过的事情，完全可以被借鉴。当然那些不妥的，也应该予以纠正。这由现在的维护者来负责。

我有我的优点和缺点。从最近几年与各位维护者、开发者和坛内外朋友们的交往来看，我体会到了高手如云。记得以前有人说过，胡荣华并非象棋第一人，民间有很多不曾露面的高手可以完胜胡荣华。我个人目前的特长和优势不在电脑技术方面。举例来说，chenall 和 yaya 非常棒。我在疗养期间，亲眼目睹 chenall 和 yaya 的配合，他们的电脑技术水平都在我之上，因此我也真的感到高兴，因而也彻底放心了。尽管我的英文也是下三烂的水平，我愿意在有机会的时候，能够替开发者们做一些力所能及的工作，因为我发现，目前活跃的这两位开发者，似乎都不太擅长英文。

想到了 jaclaz 这个意大利人，就多说几句。他后来改名为 wonko the sane。这个人真是信守诺言。很多年前，那时候英文论坛是 boot-land.net，现在是 reboot.pro. 当时我请求他替 grub4dos 做推广。他答应了。没想到，这么多年他都坚持回答 grub4dos 的问题，从不间断，从不松懈，令人肃然起敬。

liuzhaoyzz

听听不点讲的e820cycles背后的故事。。。。。。
一段时间之后，回过头来，这些故事是不是应该更加单独提出来回味呢。。。

liuzhaoyzz

map 后 PE 蓝屏原因专题讨论(e820cycles参数)
http://bbs.znpc.net/thread-6182-1-5.html
不点发表于 2011-12-8 11:42:31

大家知道，蓝屏的 workaround 解决方法是用 map --e820cycles=0 。但这并未根本解决问题。

本帖希望通过大量的用户测试和使用经验，探讨蓝屏的真正技术原因，以及可能的解决办法。

有以下问题需要澄清：

1。何时开始蓝屏的？就是说，什么时候出厂的机器，开始蓝屏？目的是确定旧电脑有无蓝屏现象。

2。蓝屏与硬件（主板、显卡）有关还是与软件（驱动程序）有关？猜测蓝屏不过就是某个显卡驱动的 bug 所导致的（这 bug 可能是人为制造的，也可能不是，这里不讨论这个话题）。显卡驱动有可能在某种硬件条件之下才 “引爆” bug，而在别的硬件之下，bug 未被 “激活”。如果确实如此，则更换显卡驱动，应该可以解决蓝屏问题。

我觉得WINPE蓝屏可能与FIRADISK或WINVBLOCK驱动有关——现在的PE大都用FIRADISK驱动，而我的上网本上用FIRADISK做WIN2003的RAMOS，也容易出现蓝屏，而WINVBLOCK似乎好一些，不过好象没几个用WINVBLOCK做PE的驱动的。

貌似从Intel的5系列芯片开始出现的，集显或可切换显卡的笔记本较常出现，估计是跟Intel的HD显卡有关，但至于是驱动还是硬件导致的，还得懂PE制作的人帮忙测试
什么叫 BIOS？那可不是只有主板才有 BIOS。显卡也有 BIOS。那些板卡，它们插在主板上，都可能有自己的 BIOS，也可能影响主板上原有的 BIOS。它们与主板一起，构成一个统一的、最终的 BIOS。这个最终的 BIOS，有时候为了简单起见，就统称为主板 BIOS。板卡插在主板上，影响的就是这个最终的 BIOS。因此，在上述讨论中，说 BIOS 没问题，是不对的。

你可以 “排除” 掉主板的问题，但你不能 “排除” 掉 BIOS 的问题。“主板” 与 “BIOS” 是两个不同的概念，即，它们互相有 “交叉”，但不是完全相同的。

根据诸位的描述，我也觉得问题可能是由显卡引起的。但严格来说，其实任何一个板卡（包括主板）都可能有问题。就是说，理论上存在这样的可能性，即，问题根本上是主板造成的，但显卡只是不幸地成为了 “受害者”（它被冤枉，它成为最大的 “嫌疑”）。

如果有人能够证明，这个显卡插在任何主板上都有同样的问题，那么这就基本上证明了确实是显卡的问题。
越来越多的迹象表明，正是由于 intel 的显卡造成的问题。大家继续给出 “ 证明 ”。
如果可能，希望您提供grub4dos命令行下（直接进入命令行后）执行 displaymem 命令的显示结果和执行 ' map --status '命令的显示结果 。
我开这个帖子，本来的目的仅仅是探讨在默认的 --e820cycles=-1 的情况下蓝屏问题的，结果，大家超出了这个范围。

原来的目的只是是想搞清导致蓝屏的具体技术细节的。就是想判断出，究竟哪个驱动程序导致了死机，以及可否通过更换有问题的驱动程序而解决问题。这才是开这个帖子的目的。

再次澄清：

当 --e820cycles 不是 -1 的时候，出现任何情况，都是正常的，就是说，死机、蓝屏，都属于正常现象，我想，这一点就不用多次重复解释了吧？而且这也不是本帖关注的重点。
sony vaio vpcsa双显卡笔记本电脑：
map --e820cycles=-1后蓝屏，改成map --e820cycles=3正常
仔细看“framebuf”，说明是显示缓存有关

蓝屏的原因，以前就搞清楚了，是 Windows 保护模式的驱动程序导致的。zhaohj 的情况，在蓝屏时已经把出错的驱动程序名字列出来了，它叫 framebuf 。

如果能够更换掉这个驱动程序，就可以避免蓝屏。

别再怀疑 grub4dos 的 int15 了。完全与此无关。zw2312914 仔细看看，grub4dos 的 int15，基本上可以说，不可能出错的，这已经经过了无数次反复的锤炼了。应该是你自己搞错了。你从头到尾，仔细看看，就可知道，不会犯这样低级的错误。

为什么说与 grub4dos 的 int15 无关呢？因为已经证明了，在 grub4dos 的 int15 接管控制之后，什么也不做，立即用 jmp 指令转到 ROM 中原来的入口，照样死机。而只有完全把 int15 的中断向量直接改成 ROM 入口，才不死机。这就是为什么要添加 e820cycles 参数的缘由了。

就是说，只要中断号被修改成指向低于 ROM 的常规内存（即使立即又转向 ROM 入口），在有问题的机器上，必死无疑。否则，如果不被 grub4dos 接管，就不会蓝屏。问题十分清楚明白，这与 grub4dos 的 int15 的处理过程，完全无关。

所以，别在这个问题上纠结了。根本无解，除了更换驱动程序以外。

有证据显示，同一台机器，换用 win7 一切正常，这说明，问题不在 grub4dos 上，而正是 XP 的驱动程序的错。

以上都是有证明的，没有含糊不清的地方。

guyue2011

看来我来对地方了   听楼主  说说历史吧  小生膜拜

红毛樱木

liuzhaoyzz 发表于 2015-4-10 09:29
map 后 PE 蓝屏原因专题讨论(e820cycles参数)
http://bbs.znpc.net/thread-6182-1-5.html
不点发表于 201 ...

最终是不是确认是NT5.X内置VGA驱动的问题？

liuzhaoyzz

似乎是的？

abs

尊重人，尊重他人的奉献，比起指责别人困难的多，相对于技术，我更佩服奉献者的人品，学习了

abs

尊重人，尊重他人的奉献，比起指责别人困难的多，相对于技术，我更佩服奉献者的人品，学习了