zoukankan      html  css  js  c++  java
  • map 后 PE 蓝屏原因专题讨论(e820cycles参数)

    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 的驱动程序的错。

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

    displaymem 命令不显示是否被 map 占据的空间。也就是说,displamem 命令永远显示原来的、系统 BIOS 所赋予的内存布局。

    memcheck 才显示经过 map --hook 修改后的内存布局。

    目前感觉大于4G内存的机器,map --mem --top /iso.iso (0xff)这种形式,会破坏仿真盘;
    曾经测试上面8G内存的sony笔记本,前后map --mem --top一个虚拟盘,也不成功。
    e820在4G以上是否没保护?
    ----------------------
    再找了台8G内存的台式机,map --mem --top 成功。
    看来还是双显卡主板的问题。
    但双显卡主板的机器,不加--top是可以成功的。也许是4G以上的内存区域不是一个连续的空间,里面有空洞,我们没有检测出来。
    大家知道,蓝屏的 workaround 解决方法是用 map --e820cycles=0 。但这并未根本解决问题。

  • 相关阅读:
    两台电脑之间怎么用一根网线传输数据
    IDEA的几个常用配置,日常开发必备
    idea 配置Maven
    IDEA2019 安装和激活
    HTML中各类空格占位符
    jackSon注解-- @JsonInclude 注解不返回null值字段
    Vscode配置Eslint
    Tomcat中容器是什么以及容器与容器之间的数量关系。
    请求是如何传递给StandardEngine的?
    Java中一个线程只有六个状态。至于阻塞、可运行、挂起状态都是人们为了便于理解,自己加上去的。
  • 原文地址:https://www.cnblogs.com/liuzhaoyzz/p/4413661.html
Copyright © 2011-2022 走看看