grub4dos_0.4.6a_20170515 不能识别文件系统类型

jdcgzb

如图所示


http://grub4dos.chenall.net/近几天打不开

2011yaya2007777

已经上传官网。

akkakk

2011yaya2007777 发表于 2017-5-29 08:04
“页映射表”只初始化一次，速度正常了！

正常了！！！！！

2011yaya2007777

“页映射表”只初始化一次，速度正常了！

不点

akkakk 发表于 2017-5-28 19:58
抱歉，今天干了一天活，现在才有时间，赶紧测了一下，发现还是有点问题。
计算机8G内存，VHD镜像4G。4.2 ...

可能与“页映射表”的反复初始化有关，浪费了时间。等待 yaya 给出优化后的测试版吧。

2011yaya2007777

我是为了测试。我的内存只有2GB。看来代码还需优化。只有我的测试是全域使用mem64。上传的测试用grldr，只有超过4GB，才使用mem64。网友报告6分半加载到内存，就是大于4GB的情况。

不点

2011yaya2007777 发表于 2017-5-28 19:37
我是在grub_memmove64全部采用mem64，即屏蔽了4G以下的常规模式。电脑一启动就慢。不一定是执行map --mem时 ...

至于说哪些地方调用了 memmove64，你搜索一下就知道了。好像文件系统驱动都使用了 memmove64。正如你所猜想的那样，mem64 切换 cpu 模式，是个很慢的操作。因此，在 4G 以内不该使用 mem64。

---

哦，看 mem64 函数当中的这条注释：

/* XXX: page maps can initialise only once for efficiency. */

2M 的页映射表，只需要执行一次即可。目前是每调用一次 mem64 就执行一次页表初始化，当然会浪费大量时间了。

你酌情处理吧。

求道者

akkakk 发表于 2017-5-28 19:58
抱歉，今天干了一天活，现在才有时间，赶紧测了一下，发现还是有点问题。
计算机8G内存，VHD镜像4G。4.2 ...

这是好消息吧……
mem64的问题果然没有那么容易修好啊……
然后yaya 首页有个usb --init的兼容问题
PLOP没能开源真是可惜

akkakk

2011yaya2007777 发表于 2017-5-28 07:51
按不点的提示修改了。请 akkakk 帮忙再测试一下，直接替换即可。

抱歉，今天干了一天活，现在才有时间，赶紧测了一下，发现还是有点问题。
计算机8G内存，VHD镜像4G。4.20版本VHD文件加载到内存在20秒以内。
这个grldr速度变得很慢，前2G差不多30秒左右能加载，后2G第一次用了6分钟（总共6分半），第二次2分钟（总共2分半）。加载启动后系统运行正常。
测过的其他版本加载速度均正常，应该在20秒左右。

2011yaya2007777

我是在grub_memmove64全部采用mem64，即屏蔽了4G以下的常规模式。电脑一启动就慢。不一定是执行map --mem时才调用grub_memmove64，有可能是其他什么地方调用了grub_memmove64。我猜测可能是频繁地切换cpu模式引起的吧。

不点

2011yaya2007777 发表于 2017-5-28 18:57
经过测试，mem64 重启的问题已经解决。

grub_memmove64 函数是分段执行的：

我没弄明白你说的情况。难道说在 mem64 的代码还没开始执行的时候，电脑已经很慢了？不可能吧？

如果你是说，“首先用 mem64 加载 img，然后又进入 img 里面的 grldr，此时出现问题”，这倒有可能是 mem64 带来的某个“副作用”。

这个问题出现在什么架构？intel 还是 AMD？有多少人会出现这样的情况？

难道说 mem64 里面的 cpu 模式切换过程，不太彻底？进入了一个“有问题” 的模式？或者说在函数返回时未能彻底恢复到正常的 32 位保护模式？

不点

jdcgzb 发表于 2017-5-28 19:04
用此版本的GRLDR加载0PE会黑屏重启。

非常好，辛苦了。

猜测得到了实践的证实。问题应该算是搞清楚了。

当我们有可能把问题搞清楚时，就应该钉死它、彻底搞清，尽量不留下疑问点。我们有幸能搞清的问题并不多。对于一个问题，如果我们有可能搞清，就尽量搞清。

jdcgzb

2011yaya2007777 发表于 2017-5-28 17:49
重启的grldr

用此版本的GRLDR加载0PE会黑屏重启。

2011yaya2007777

经过测试，mem64 重启的问题已经解决。

grub_memmove64 函数是分段执行的：
4GB以下采用常规方法；4GB及以上，优先 AMD64/IA32-e 分页模式，其次 PAE 分页模式。

如果全部采用 PAE 分页模式，没有感觉到速度变化。

如果全部采用 AMD64/IA32-e 分页模式，在真实计算机速度奇慢，卡在调用预置菜单及设置视频模式。但是加载内存似乎速度还可以。在虚拟机，则在[0M/325M]停止不前。不过也可能会变，没有耐心等待。

不点

2011yaya2007777 发表于 2017-5-28 17:49
重启的grldr

好的，这个是有问题的 grldr，大家可以证实一下，是不是有重启的问题。虽然已经知道症结了，但确认一下没坏处，以防万一还有别的蹊跷。

2011yaya2007777

重启的grldr

不点

就是 27 楼那个版本，不过，yaya 已经把它删除了，没法测试了。

本帖最后由 2011yaya2007777 于 2017-5-28 07:53 编辑

请 akkakk 帮忙再测试一下， 看看开放 mem64 函数，是否会重启。直接替换即可。
点评
akkakk
这个不能用，试了几次，分别加载vhd到96M、208M、200M的时候出现重启现象。  详情 回复 发表于 昨天 20:21

算了，那就不测试了。

那你最好再测试一个 4G 的大文件，让它加载，看看会不会成功。不用启动它，只要 map 命令能够完成加载，就算成功。

随便一个 4G 的文件都可以的，不一定非得是 img 文件。可以进入命令行，用 map --top --mem 加载它。

jdcgzb

不点 发表于 2017-5-28 16:59
不错，值得庆祝。

不过测试过程只完成了一半。还需要测试上一个版本确实是要导致 “死机” 或 “重启 ...

请说明一下“上一个版本”具体指哪一个版本？

不点

jdcgzb 发表于 2017-5-28 16:42
我是用真机测试启动成功，然后在虚拟机里截图，主要是为了方便。

不错，值得庆祝。

不过测试过程只完成了一半。还需要测试上一个版本确实是要导致 “死机” 或 “重启”，才算完成了测试。

注意，在加载 img 的过程中就应该碰上死机或重启。如果没有碰上死机或重启，那你得换个大一点的 img 才能让它有充足的时间去 “死机” 或 “重启”。

如果加载过程没有死机、重启，那它进入 Windows 也正常，没什么可测试的。问题就出在加载 img 到 4G 之上内存的过程中。加载的 map 命令行必须带有 --top 参数，才可能加载在 4G 以上。

jdcgzb

不点 发表于 2017-5-28 16:34
很抱歉，测试无效，哈哈。

要用真实机来测试，而不是虚拟机。

我是用真机测试启动成功，然后在虚拟机里截图，主要是为了方便。

不点

jdcgzb 发表于 2017-5-28 16:18
8G内存电脑测试成功加载到内存启动。

很抱歉，测试无效，哈哈。

要用真实机来测试，而不是虚拟机。

可以从 U 盘启动来测试，以免还得修改硬盘上的 grldr 文件。

你虚拟机测试，虚拟机的内存只有 256 M，内存没有超过 4G，测试无效啊。

jdcgzb

不点 发表于 2017-5-28 15:16
几个小时过去了，没人测试。其实，任何人都可以测试，并非只有 akkakk 才可以测试。

先前的测试版是未增 ...

8G内存电脑测试成功加载到内存启动。

不点

几个小时过去了，没人测试。其实，任何人都可以测试，并非只有 akkakk 才可以测试。

先前的测试版是未增加 cli 指令的，应该很容易碰上“重启”的问题。就是说，只要试图加载几百 MB 的文件，总会碰上问题。因为加载过程中只要发生时钟中断，或者敲击键盘，或者移动鼠标，这就触发了硬件中断，于是就很容易“重启”。

最新的测试版增加了 cli 指令，应该没问题了。大家都可以测试的，没有什么危险，不会造成损失（最坏的情况，无非就是 “重启”、“死机”）。

只要你有条件加载比较大的 img，你都可以测试。

前一个版本是容易发生重启的，后一个版本正常。如果测试结果证实了这样的情况，那就是“测试成功”。

---

再补充，并非只有超过 4G 内存的电脑才可以测试。低于 4G 的电脑也可以测试。只要测试 img 足够大（大约几百 M 即可），必能重现问题。

而且，测试时，你没必要去启动 IMG，你只需要把它完整加载到内存，只要不发生重启的毛病，这就是成功了。前一版本肯定会发生重启，后一版本应该不会发生重启。如果测试结果确实如此，那我们就可以说，确实是找到了问题的症结。

---

再补充，低于 4G 内存的电脑，恐怕测试不出来。因为低于 4G 会自动采用 32 位的 memmove 函数，而不是采用 mem64。

但 yaya 自己可以测试。yaya 自己可以强制采用 mem64，这样就可以用低于 4G 内存的电脑来测试了。

2011yaya2007777

按不点的提示修改了。请 akkakk 帮忙再测试一下，直接替换即可。

不点

报告一个好消息，我似乎猜到了。

从“加载过程不稳定”这一现象，我努力地想，感觉这可能是“中断响应”之类的问题。比如说，数据传输过程中破坏了中断向量表，或者破坏了内存的代码或堆栈。

终于，突然意识到，mem64 没有执行 cli 指令。

在早期，32 位保护模式的代码只运行在 cli 的情况下，只有切换到实模式之后才执行 sti，一旦准备进入保护模式，就又要先执行一条 cli 了。

mem64 就是早期写成的，所以，无需执行 cli 指令（根据刚才的解释，保护模式代码的运行，就意味着 cli 早执行过了）。

然而后来，我们给保护模式开放了中断响应。进入保护模式之后，执行了 sti。就是说，保护模式的代码运行在 sti（允许响应硬件中断）的状态。

这下子，mem64 就“躺枪”了。

假如说 mem64 依旧只是使用 32 位保护模式，那就不用管 cli 和 sti 的问题，因为 32 位代码可以响应硬件中断，我们已经有了 32 位的硬件中断响应处理程序。

然而 mem64 要切换 cpu 模式，就是切换到 64 位模式，这就不能响应硬件中断了，因为我们没有编写 64 位的硬件中断处理程序。只要在 64 位代码执行期间发生硬件中断（比如时钟中断），程序必然要崩溃。因此，在进入 64 位模式之前，必须执行一条 cli 指令（禁止响应硬件中断）。

yaya 可以在 mem64 的开头放置一条 cli，然后在尾部的 ret 之前再放置一条 sti。

更好一点的做法是，在开头放置一条 pushfl（保存原有的中断标志），然后执行 cli（目的是让 64 位指令能够不受干扰地顺利执行），再在结尾的 ret 之前放置一条 popfl 指令，恢复原有的中断标志。

这样的话，程序的适应性就要好一些了：既能适用于早期的情况（32 位保护模式不具有中断响应的功能），也能适用于现在的情况（32 位保护模式能够响应硬件中断，比如键盘中断、时钟中断）。

不点

yaya 能否做这样一个试验：给 0.4.5c 的 mem64 打补丁，试试看怎么样？

加载 img 的过程中重启——看来我们得猜猜这是啥问题了。

另外，需要确定，有没有人能够成功使用 mem64 加载 img 到 4G 以上的内存？只要有一个成功案例就行。

我们获得的信息越多，就越容易猜到症结。目前获得的信息太少，因此判断起来就没有头绪。

2011yaya2007777

看来这个函数有些问题，需要排查。也请不点留意一下。

akkakk

2011yaya2007777 发表于 2017-5-27 15:46
请 akkakk 帮忙再测试一下， 看看开放 mem64 函数，是否会重启。直接替换即可。

这个不能用，试了几次，分别加载vhd到96M、208M、200M的时候出现重启现象。

2011yaya2007777

请 akkakk 帮忙再测试一下， 看看开放 mem64 函数，是否会重启。直接替换即可。

akkakk

2011yaya2007777 发表于 2017-5-27 08:33
请 akkakk 帮忙再测试一下，直接替换即可。

这个可以了，正常引导启动。

2011yaya2007777

请 akkakk 帮忙再测试一下，直接替换即可。