GRUB4DOS更新建议、bug反馈专帖

zxw

不好意思，太马虎了。是输入
(hd96)155+45,0x58e0
回车，能正确显示wenv的帮助信息。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
晕，怎么这么马虎？
才测试了一下，(hd96)155+12,0x58e0
能正常运行！汗！

[ 本帖最后由 zxw 于 2011-4-7 18:56 编辑 ]

不点

你把 45 改成 12 应该也能。如果不能，则表示此处的表示方法的处理中含有 bug。

zxw

抱歉，不点老师。这几天事多，头昏脑胀，又心系grub4dos，总是出错。问题已解决，属自己粗心。
再次诚恳道歉，让您费心了！谢谢！

[ 本帖最后由 zxw 于 2011-4-7 18:59 编辑 ]

不点

不客气。你问的问题属于一般人不常接触到的问题。所以，这是应该给予答复的。

不点

从图片看，执行 int13／ah＝2读硬盘时死机。这说明BIOS不支持 CHS 模式的磁盘读。能进入 grub 环境，则表示 LBA 模式没有死掉。

初步怀疑，这是一个 4K 扇区的硬盘，其 BIOS 仿真 512 扇区的工作没有做好，在 CHS 模式有 bug，只能使用 LBA 模式。

===============

发表一点评论。市场制造了这么多的不兼容，这不是有意的，难道会是无意的？这么折腾的结果，恐怕会让 ARM 有机可乘。

如果这是故意的，则表明华硕也卷入了其中，刷新了记录。

[ 本帖最后由 不点 于 2011-4-8 07:20 编辑 ]

zhaohj

原帖由 不点 于 2011-4-7 21:31 发表
从图片看，执行 int13／ah＝2读硬盘时死机。这说明BIOS不支持 CHS 模式的磁盘读。能进入 grub 环境，则表示 LBA 模式没有死掉。

初步怀疑，这是一个 4K 扇区的硬盘，其 BIOS 仿真 512 扇区的工作没有做好，在 ...

为了找出问题所在，今天又测试了一下：
1：PXE启动，加载DOS镜像，运行grub.exe正常，访问硬盘也都正常；
2：PXE启动，进入grldr命令行：
     pxe unload
     geometry (hd0)
     正常显示硬盘分区信息
==============

到此，问题原因找到了，这个主板的PXE BIOS部分可能有问题

但要解决这个问题不容易，PXE情况下无法把数据写入硬盘，无法提交数据，纠结啊！

不点

总有办法的，你可以先把实模式的内存备份到扩展内存，然后执行 pxe unload，再执行写盘的操作，把扩展内存中的备份写入硬盘文件中。

不过目前要紧的是，先测试 DOS 下能不能用 int13／ah＝2 来访问硬盘扇区。如果不能，我们就知道原因了。如果能，那我们还要继续查明，为何 grub4dos 下不能使用 int13／ah＝2 ？

当然，顺便也可以试试 int13／ah＝42h 的情况。

[ 本帖最后由 不点 于 2011-4-8 12:19 编辑 ]

zhaohj

只要不在PXE环境，其他任何环境都可以读写硬盘。
下面是pxe前后的内存比较，请不点大看一下。

[ 本帖最后由 zhaohj 于 2011-4-8 12:35 编辑 ]

不点

你只贴了中断向量表，这是不够的。

从 400 - 4FF 也要贴。

由于可能涉及到 PXE 的程序，所以，最好把常规内存顶端的部分也贴出。

如果你实在不知道要贴多少内容，干脆把 640K 常规内存全部贴出来。

补充：暂时先贴 400 - 4FF 吧，其他的不要贴了，因为可能并不需要。

============

从已经贴出的中断向量表，可以看出，只有两个差别：

int1A：pxe=9D3B：0F23 -------- non-PXE=F000：FE6E
int72：pxe=8D55：4EAF -------- non-PXE=F000：EF0F

有可能是 PXE 的 int72 与磁盘的 int13 发生了冲突。也有可能是 int1A 的影响。总之，你可以试着把这两个修改为 non-PXE 时的值，看看是否解决了。不过，修改以后，PXE 应该无法工作了，甚至会死机。 看看这两个中断中的哪个有影响。或者两个同时影响磁盘的读取。

[ 本帖最后由 不点 于 2011-4-8 17:53 编辑 ]

zhaohj

我先上传640kb的两个文件，有空我再改一下上面的两个内存地址。

jianliulin

grub4dos的外部命令，能否也像grldr一样内置个发布日期，方便识别版本

zhaohj

原帖由 jianliulin 于 2011-4-9 00:29 发表
grub4dos的外部命令，能否也像grldr一样内置个发布日期，方便识别版本

外部命令确实没有，不过目前没几个外部命令。建议C大以后加上。

问一下，你的打包工具生成的grub4dos.mod我改成grub4dos.mod.gz后怎么无法解压？

[ 本帖最后由 zhaohj 于 2011-4-9 13:59 编辑 ]

zhaohj

原帖由 不点 于 2011-4-8 17:49 发表
你只贴了中断向量表，这是不够的。

从 400 - 4FF 也要贴。

由于可能涉及到 PXE 的程序，所以，最好把常规内存顶端的部分也贴出。

如果你实在不知道要贴多少内容，干脆把 640K 常规内存全部贴出来。

...

测试步骤：
pxe启动进入命令行：
1）write 0x68 0xf000fe6e
geometry (hd0) 死机

2）重启后，write 0x1c8 0xf000ef0f
geometry (hd0) 正常
ls (hd0,0)/   正常
pxe 正常

3）重启后，write 0x68 0xf000fe6e
write 0x1c8 0xf000ef0f
geometry (hd0) 正常
ls (hd0,0)/   正常
pxe 正常
=============
上面测试结果看，与int1A无关，只有int72中断有关。而且不影响pxe的连接。

zhaohj

2）重启后，write 0x1c8 0xf000ef0f
geometry (hd0) 正常
ls (hd0,0)/   正常
pxe 正常
=============
上面虽然正常，但也无法访问PXE上的文件了，如:
cat --length=0 /GRLDR && echo ok 导致假死

jianliulin

原帖由 zhaohj 于 2011-4-9 12:37 发表


外部命令确实没有，不过目前没几个外部命令。建议C大以后加上。

问一下，你的打包工具生成的grub4dos.mod我改成grub4dos.mod.gz后怎么无法解压？

改名，还是用gzip再次压缩？能上传你的mod文件吗？

zhaohj

按我的理解，mod文件实际上是个gz压缩的IMG文件，现在怎么无法解压了？

zxw

你用winhex查看就知道是怎么回事了。

不点

2）重启后，

write 0x1c8 0xf000ef0f
geometry (hd0) 正常
ls (hd0,0)/   正常
pxe 正常

你是说，这个就完全正常了，对吧？

然而我们怎么在 pxe unload 之前知道 F000EF0F 这个正确的中断向量呢？

请思考一下。我们必须把这个值找出来。

========

你再看看 int72 的程序是什么样的？你在 DOS 下可以用 debug 跟踪 int72 的执行过程。我猜它死机了，比如进入了无限循环，或者执行了一条非法指令。

如果确实是这样，那么怀疑这是有意制造的死机。

如果你把 int72 更正以后，一切正常，这就差不多说明是有意制造的死机。

不管如何，这个问题好像没有更好的解决办法。write 0x1c8 0xf000ef0f 大概就是最好的解决办法了。

好了，到此为止吧。

[ 本帖最后由 不点 于 2011-4-9 16:42 编辑 ]

zhaohj

不是完全正常

write 0x1c8 0xf000ef0f后虽然pxe命令正常显示（访问硬盘倒很正常了），但访问(pd)上的文件不正常，这个很奇怪。
如cat (pd)/menu.lst进入死机状态。
说明int72中断向量对pxe还是很重要，找到了0xf000ef0f，但pxe部分代码已经失效。

不点

唉，这还差不多，至少说明，这个 int72 还是有用的。

好了，你有事干了：

在 DOS 下，用 debug 跟踪 int72 的执行过程，看看有什么机关？

它应该在某个时候把控制传递给 0xf000ef0f。

你也可以把 int72 反汇编出来。然后我们分析一下它的程序流程。

其实现在你已经明白怎么来对付了：作为一个 workaround，当访问 PXE 时，用 PXE 的 int72, 当访问硬盘时，用 0xf000ef0f。

问题就算解决了。

如果你不想用 DOS 的 debug 来跟踪的话，现在就可以结束了。

[ 本帖最后由 不点 于 2011-4-9 16:52 编辑 ]

zhaohj

这还需要你的指点，什么时候算跟踪到位了？
应该加pxe keep后才能加载DOS镜像吧
pxe keep
map --mem /dos.img (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
===========
运行
debug
a 100
int 72
db eb fe
t

[ 本帖最后由 zhaohj 于 2011-4-9 17:05 编辑 ]

不点

你先看看这个程序有多长，上次你上载的内存，没有包括这一部分，所以，我这里没法知道。

要不你把这段内存再上载一下？从 7000:0000 到 A000:0000 之间的内存，应该包含了 int72 的代码了。

其实我也懒得看它了，毕竟我们已经知道怎么 workaround 了。

------------------

也有可能华硕在 PXE 的情况下，故意禁止用户对于硬盘的访问。问问华硕的工程师，看看是不是这样。请华硕的工程师解决好了，我们实在没必要去折腾了。

[ 本帖最后由 不点 于 2011-4-9 17:12 编辑 ]

zhaohj

http://bbs.wuyou.net/forum.php?mod=viewthread&tid=180142&page=70#pid2199824
已经上传了。

目前单位还有好多新机器都是asus的，我发现问题差不多。

[ 本帖最后由 zhaohj 于 2011-4-9 17:11 编辑 ]

不点

你只上载了很少一部分内存，你看看就知道了。你是以文本方式上载的，所以，整个文本有 640K，但实际显示的内存信息，远远低于 640K。

算了，不用重复上载了。我觉得研究它们，没有太大的意义。请华硕工程师解决，则是正道。

zhaohj

不管怎样，我还是再次上传一下，不点大有空时候研究一下。
华硕可能故意为之，也可能是他的bug.
现在至少用光驱或硬盘启动，也能解决问题。

不点

又是无效的上载。

你只上载了 0 － 9FFF 的值。实际需要的是 0 － 9FFFF 的值。

分析 int72 的程序，是一个很辛苦的活。这应该是 BIOS 工程师的事。我们不应该无偿为他们服务。

到此为止吧，也不用上载了。

我们其实已经为他们做了不少工作了，还不知他们是否领情呢。

zhaohj

你下载有问题吧，我改个名试试

[ 本帖最后由 zhaohj 于 2011-4-9 18:41 编辑 ]

jianliulin

原帖由 zhaohj 于 2011-4-9 14:51 发表
按我的理解，mod文件实际上是个gz压缩的IMG文件，现在怎么无法解压了？

1.chenall定义的mod文件（以下称模块文件）与你说的有些不一样，模块文件可以用gzip压缩，但模块文件的组成只能是grub的批处理或者外部命令，
   模块文件有其自己的标识，打包时候把批处理或者命令文件的名称和大小都记录在模块文件里面，以便insmod 时候使用。

2.fbinstTool 打包的模块文件时是先把批处理或者外部命令用gzip 压缩后再打包，这样可能让大于40K的外部命令压缩后可能小于40k从而可以正确安装，

3.fbinstTool 如果发现模块文件时被gzip压缩过，会先解压然后再判断是否是模块文件，如果是则解析其组成的批处理或者外部命令。

[ 本帖最后由 jianliulin 于 2011-4-9 18:57 编辑 ]

不点

1. 000923FF FA                             cli
   
2. 00092400 1E                             pushw   %ds
   
3. 00092401 06                             pushw   %es
   
4. 00092402 0F A0                          pushw   %fs
   
5. 00092404 0F A8                          pushw   %gs
   
6. 00092406 66 60                          pushal
   
7. 00092408 2E 8E 1E DA 4D                 movw    %cs:0x4DDA, %ds # DS=0x89C0
   
8. 0009240D 83 3E C8 38 FF                 cmpw    $0xFFFF, 0x38C8 # [8D4C8]=000A
   
9. 00092412 74 4A                          jz      0x0009245E
   
10. 00092414 C7 06 22 00 00 00              movw    $0, 0x0022
    
11. 0009241A C7 06 24 00 01 00              movw    $1, 0x0024
    
12. 00092420 1E                             push    %ds
    
13. 00092421 68 22 00                       push    $0x0022
    
14. 00092424 6A 14                          push    $0x14
    
15. 00092426 C4 1E A8 38                    les     0x38A8, %bx # ES:BX=9D3B:0070
    
16. 0009242A 26 FF 5F 10                    lcall   *%es:0x10(%bx)
    
17. ........................................此处还要 call far 9D3B:0080，就比较麻烦了。那又是一段很长的程序。
    
18. ........................................估计错误就在那里面。
    
19. 0009242E 83 C4 06                       add     $0x06, %sp
    
20. 00092431 83 F8 00                       cmp     $0x00, %ax
    
21. 00092434 75 08                          jnz     0x0009243E
    
22. 00092436 A1 24 00                       movw    0x00000024, %ax
    
23. 00092439 83 F8 00                       cmp     $0x00, %ax
    
24. 0009243C 74 02                          jz      0x00092440
    
25. 0009243E EB 1E                          ljmp    0x0009245E
    
26. 
    
27. 00092440 A1 C8 38                       movw    0x000038C8, %ax
    
28. 00092443 8A D0                          mov     %al, %dl
    
29. 00092445 B0 20                          mov     $0x20, %al
    
30. 00092447 80 FA 08                       cmp     $0x08, %dl
    
31. 0009244A 72 04                          jc      0x00092450
    
32. 0009244C BA A0 00                       mov     $0x00A0, %dx
    
33. 0009244F EE                             out     %al, %dx
    
34. 00092450 BA 20 00                       mov     $0x0020, %dx
    
35. 00092453 EE                             out     %al, %dx
    
36. 
    
37. 00092454 66 61                          popal
    
38. 00092456 90                             nop
    
39. 00092457 0F A9                          pop     %gs
    
40. 00092459 0F A1                          pop     %fs
    
41. 0009245B 07                             pop     %es
    
42. 0009245C 1F                             pop     %ds
    
43. 0009245D CF                             iret
    
44. 
    
45. 0009245E 2E 83 3E DE 4D 00              cmpw    $0, %cs:0x4DDE
    
46. 00092464 74 26                          jz      0x0009248C
    
47. 
    
48. 00092466 FB                             sti
    
49. ................................................# 此处的 pushf ; call far 就对应于访问磁盘的情况。
    
50. 00092467 9C                             pushf
    
51. 00092468 2E FF 1E DC 4D                 lcall   *%cs:0x4DDC
    
52. 0009246D BA 21 00                       movw    $0x21, %dx
    
53. 00092470 8B 1E                          movw    0x38C8, %bx
    
54. 00092472 C8 38 80 FB 08                 cmp     $8, %bl
    
55. 00092477 72 03                          jb      0009247C
    
56. 00092479 BA A1 00                       mov     $0x00A1, %dx
    
57. 0009247C 8A 1E 1A 00                    movb    0x001A, %bl
    
58. 00092480 EC                             in      %dx, %al
    
59. 00092481 F6 D3                          not     %bl
    
60. 00092483 84 C3                          test    %al, %bl
    
61. 00092485 74 05                          jz      0x0009248C
    
62. 00092487 F6 D3                          not     %bl
    
63. 00092489 22 C3                          and     %bl, %al
    
64. 0009248B EE                             out     %al, %dx
    
65. 0009248C EB C6                          ljmp    0x00092454

复制代码

程序很复杂，错误在里面，但只有硬件工程师才能定位。

这是中断共享的冲突问题。我估计硬件工程师忘了在 int13 的程序开头设置一个开关，用于通知 int72，让它执行硬盘的访问，所以，才出现这样的问题。

总之，基本能够确定是 BIOS 的 bug，而不是故意制造的死机。

＝＝＝＝＝＝＝＝＝

顺便说，华硕的工程师很负责的，只要你报告，他们会解决的。这问题对于他们来说，其实是很小的，很容易就解决了。估计几个小时就能解决。



好了，我们尽力了，无法解决。还是用我们自己的 workaround 吧，那既简单又管用。

[ 本帖最后由 不点 于 2011-4-9 22:32 编辑 ]

不点

你咋不说说从什么版本开始引入的 bug 呢？

不然的话，很难确定问题在哪里。