[20100626正式版]SRS_F6 公用性SRS驱动的F6模块—XP/2003安装及PE 1.x的SRS驱动不愁缺

不点

你的 dell 没有死机，因此不需要中断向量和BDA数据。只有死机的情况，才需要这些数据。

死机是最严重的问题。只要不死机，一切都容易解决。

不点

这只是在 PXE 服务器的根目录时需要把 menu.lst 改为 main.lst。普通的磁盘、光盘上是不可以改的。在普通的磁盘、光盘上，默认时依旧是用 menu.lst。否则我们就是自己与自己不兼容了。

不点

是的，经过你这么一说，我也觉得这样做更符合逻辑。

但我们这样做了之后，需要在显著位置通告这一变动，让所有的 PXE 用户都把服务器上的 menu.lst 文件夹改成 menu 文件夹，否则就有可能在执行 pxe detect 时死机。

让 chenall 来做最后的决定吧。

不点

@zhaohj

hhh333 所说的问题，与你想象的完全无关。他的死机出现在 grub.exe 试图恢复 BIOS 中断向量的阶段。与命令行参数的解释也完全无关。

hhh333 的报告，证实了我前几次的猜测。正是 CPU 的 bug 引起的。我们唯一能做的，就是设法避免诱发 CPU 的 bug。

在 grub.exe 执行之前，是否执行过 HIMEM 或者 EMM386 等其他常驻内存的程序？如果执行过，就可能导致这个问题的出现。

请彻底注释掉所有的不必要的命令。除了运行 DOS 内核以外，别的任何代码都不要运行，例如 config.sys 和 autoexec.bat 中，除了 grub 以外，其余的全部注释掉。然后再试试，如果问题不再发生，则证明，确实是 grub 之前运行的某个程序代码触发了 CPU 的 bug。

也就是说，从机器启动一直到 grub.exe 的运行，这期间，不要运行任何多余的代码。只在 autoexec.bat 中加上 grub 命令，看看死机不死机。如此测试才能找到病根。

＝＝＝＝＝＝＝＝＝

DOS 文件名前不加 ＃＠ 的有时候也能识别出来。比如，你带有 C:\ 字样，就能够被识别为 DOS 文件名了。当然，加上 #@ 就更好一些。

[ 本帖最后由 不点 于 2010-5-24 19:35 编辑 ]

不点

就像见鬼了一样。这是我们早在 2008－11－19 就弄明白了的。正是 CPU 的 bug 引起的。这个 bug 从来没人注意到。

我们有时候在即将死机之前执行一个暂停 5 秒的命令，这样在很多情况下就可以避免死机。你也可以试试，在执行 grub.exe 之前，先执行一个类似于 sleep 5 的 DOS 命令。

而且有的人即使这样做了，仍然不能避免死机。

唯一可靠的办法，就是完全避免碰触 CPU 的 bug。也就是把碰触这个 bug 的 DOS 命令删除掉。

－－－－－－－－－－－－

明天我再在不加载任何驱动下再试。

不仅仅是任何“驱动”，而是任何“程序”。不要运行任何多余的程序，干干净净地，只运行 IO.SYS 和 grub.exe。

如果你的 io.sys 和 grub.exe 是在一个 img 中，你也不能够用 memdisk 来启动它，而只能用 grub4dos 的 map，因为 memdisk 也有可能碰触 cpu 的 bug。

[ 本帖最后由 不点 于 2010-5-25 07:41 编辑 ]

不点

原帖由 zhaohj 于 2010-5-25 11:34 发表
USB-CDROM又是一种特例，与BIOS有关。
在GRLDR转IO.SYS后，USB-CDROM就不能访问了。没办法啊！

有办法。

USB－CDROM 和 CDROM 是一样的。只要光盘的格式是 no－emulation，并且从光盘启动，那么 BIOS 都要给光盘一个盘号。在 GRUB 下可以检测到这个盘号，用 (cd) 来访问它。

注意，这个盘号不需要用 cdrom --init 来产生。这个 (cd) 就代表由 BIOS 提供的 no-emulation 模式的 cdrom 设备。

cdrom --init 所产生的是 (cd0), (cd1) ... 这些。

(cd) 这个光盘，在 DOS 下也可以识别，需要 eltorito.sys 这个驱动。

但是，eltorito.sys 有个问题，当碰到（很多）恶意的 BIOS 的时候，它被这些恶意的 BIOS 欺骗，停止在 0xff 处，无法搜索到真正的光盘。

此时，可以试试

map (cd) (0xff)
map --rehook

然后再把控制权交给 io.sys，如此，DOS 下的 eltorito.sys 和 mscdex 就可以成功访问 (cd) 了。看看 grub4dos 的 readme，再搜索网络找到相关的信息。

－－－－－－－－

进一步补充说明，eltorito.sys 已经开源了，现在归 syslinux 管辖。非常好的消息。但是，究竟开源后是否解决了以前 0xff 的问题，还不清楚。如果解决了恶意 BIOS 攻击的问题，那么就不再需要 map (cd) (0xff) 这个步骤了。

不点

只要你的 DOS 不需要 (cd) 了，你就什么也不用管了。grub4dos 能够自动找回 (cd) 的。

加载 eltorito.sys 不会对真实光驱产生什么影响。它只对 BIOS 所提供的 (cd) 设备进行服务。这个 (cd) 设备既可以是真实的 cdrom，也可以是 usb 的 cdrom。

只要启动的是 no-emulation 格式的光盘，那么，eltorito.sys 都可以驱动它。由于这是利用了 BIOS 提供的 int13 接口，所以，这不会失败的，除非就像前面所说，恶意 BIOS 专门制造一个虚假的 0xff 光盘，让 eltorito.sys 上当。无论是IDE还是SCSI，无论是 PARALLEL还是SATA，或者是 USB－CDROM，或者是将来的新的介质，如 IEEE1394 等等等等，只要你采用的 ISO 格式是 no-emulation 模式的，那么在启动这个格式的光盘时，BIOS 都要赋予一个光盘号码（绝对保证，无一例外，因为这是光盘启动规范所规定了的），这就是 grub 之下的 (cd)。这样一个 (cd)，对于 eltorito.sys 来说也是同样方便的，eltorito.sys 在原理上就等同于 grub4dos，它本来就是用来驱动这样一个 (cd) 的。

不点

你还该问的是：为什么加上 call 以后就好了？为什么拔掉一个硬盘也好了？…… 可是为什么都不问了，只问这样一个 .exe 的问题呢？

你问完了我，想没想到，我会不会问你什么？

不点

int13/42h Read error (ax=0961, DL=EF) Block=00002E61

我似乎以前也见到过这样的出错信息。信息似乎是 ISOLINUX 发出的，但我不能肯定我的记忆是否准确。

谁发出的信息，谁应该为此负责。它是前线负责人。当然，后防也有负责人。后防就是前期那些运行过的程序，也就是那些用来作为基础的程序。

这条信息倒是说的比较明白了。当 ISOLINUX （或者是某个其他的程序）试图用 int13／42h 来访问光盘的时候，BIOS 的 int13 却返回了失败的信号 AX＝0961。如果是 grub4dos，则直接忽略这个错误信号，不认为曾经有错误发生，继续运行程序。但是，别的软件可能就要严格按照规范去处理，结果只能是失败停机。

世界上有两套（或者三套）规范：一套是业界精英们当初制定的规范。一套是实际广泛使用的规范。第三套规范（潜规则）是业界精英们自己故意破坏掉的规范。也就是说，制定规范的是谁，破坏规范的也是谁。别人你若想破坏规范，你还没有资格。你既没有制定规范的资格，也没有破坏规范的资格。破坏规范的目的，就是为了让某些软件无法运行，让其逐渐失去市场地位。这是有目标的，不是漫无目的的。

不点

Bootable CD Wizard v2.0a1 copy……这条消息很明显是 BCDW 发出的。你给 BCDW 的开发者报告一下。