1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
[[!toc]]
# Running GNU Mach in VirtualBox crashes during initialization.
[[!tag open_issue_gnumach]]
## IRC, freenode, #hurd, 2011-08-15
<BlueT_> HowTo Reproduce: 1) Use `reboot` to reboot the system. 2) Once
you see the Grub menu, turn off the debian hurd box. 3) Let the box boot
normally, and wait for the error/crash/reboot. 4) The error/crash will
happen twice and it's reboot automatically. The 3rd boot will success.
<BlueT_> root@dhurd:/boot# addr2line -f -e gnumach-1.3.99-486-dbg-copy 0x106c93 0x1556a5 0x152c54
<BlueT_> copyoutmsg
<BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../i386/i386/locore.S:1289
<BlueT_> exec_load
<BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../kern/elf-load.c:80
<BlueT_> user_bootstrap
<BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../kern/bootstrap.c:756
i386/i386/locore.S:1289 is
movl $USER_DS,%eax /* use user data segment for accesses */
=> mov %ax,%es
State is
cs: 0x8
ds: 0x10
es: 0x10
fs: 0
gs: 0
ss: 0x10
eax: 0x1f
ecx: 0x8048000
edx: 0x15fb7f
ebx: 0x1001000
esp: 0x75e47e08
ebp: 0x75e47e6c
esi: 0x1002000
edi: 0x8048000
eip: 0x106c93
efl: 0x10206
<youpi> oh, wait, it's not even the data access which poses problem
<youpi> but the use of $USER_DS
<youpi> ew
<youpi> looks like a gdt initialization emulation issue in virtualbox...
<BlueT_> just found that at the second crash, the address is different
<BlueT_> 2nd time:
<BlueT_> addr2line -f -e gnumach-1.3.99-486-dbg-copy 0x1068bd 0x152c74
<BlueT_> _kret_popl_es
<BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../i386/i386/locore.S:527
<BlueT_> user_bootstrap
<BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../kern/bootstrap.c:765
i386/i386/locore.S:527 is:
_return_from_kernel:
_kret_popl_gs:
popl %gs /* restore segment registers */
_kret_popl_fs:
popl %fs
_kret_popl_es:
=> popl %es
_kret_popl_ds:
cs: 0x8
ds: 0x10
es: 0x10
fs: 0
gs: 0
ss: 0x10
eax: 0x106c95
ecx: 0x6aab096c
edx: 0x106cec
ebx: 0x75e47f04
esp: 0x75e47f0c
ebp: 0x75e47fac
esi: 0x75e47f8c
edi: 0x7fffff3c
eip: 0x1068bd
efl: 0x10216
<youpi> looks again like a $USER_DS issue
<youpi> what's interesting is that that one means that $USER_DS did load in
%es fine at least once
<youpi> and it's the reload that fails
# Slow SCSI probing
[[!tag open_issue_gnumach]]
## IRC, freenode, #hurd, 2012-08-07
<braunr> youpi: it seems the slow boot on virtualbox is really because of
scsi (it spends a long time in scsi_init, probing for all the drivers)
<youpi> braunr: we know that
<youpi> isn't it in the io port probe printed at boot?
<youpi> iirc that was that
<braunr> the discussion i found was about eata
<braunr> not the whole scsi group
<youpi> there used to be another in eata, yas
<braunr> oh
<braunr> i must have missed the first discussion then
<youpi> I mean
<youpi> the eata is the first
<braunr> ok
<youpi> and scsi was mentioned later
<youpi> just nobody took the time to track it down
<braunr> ok
<braunr> so it's not just a matter of disabling a single driver :(
<youpi> braunr: I still believe it's a matter of disableing a single driver
<youpi> I don't see why scsi in general should take a lot of time
<braunr> youpi: it doesn't on qemu, it may simply be virtualbox's fault
<youpi> it is, yes
<youpi> and virtualbox people say it's hurd's fault, of course
<braunr> both are possible
<braunr> but we can't expect them to fix it :)
<youpi> that's what I mean
|
