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
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
|
semantic: 0.904
device: 0.897
assembly: 0.896
other: 0.895
instruction: 0.873
graphic: 0.870
boot: 0.868
vnc: 0.857
socket: 0.849
KVM: 0.816
mistranslation: 0.808
network: 0.804
DRIVER_IRQL_NOT_LESS_OR_EQUAL booting WIndows XP with Synaptics driver installed
Positng the issue here since I did not get any reply on the ML.
I was trying to update some windows XP (SP3) images in kvm.
It worked fine several times but last time I added mass storage
drivers to sysprep and now on the second boot after reseal (the first
is mini-setup) I get a BSOD with message
DRIVER_IRQL_NOT_LESS_OR_EQUAL. I can post the screenshot if somebody
thinks it is interesting enough.
The same image works on hardware (which has controllers different from
the qemu PIIX3) and in VirtualBox (with the default PIIX4 as well as
PIIX3) so long as IO apic is enabled).
I am not sure if this is an error with the MS drivers or how they are
used in sysprep in this particular case or if his is some strange
error in qemu emulation in the PIIX3 controller or elsewhere.
The image is originally created on hardware with MP acpi (not virtualization).
Note that most of the section is generated by sysprep (the drivers referencing C:\windows), only small part at the end is generated by my script for additional drivers (references C:\drivers).
The previous images that did not have this section worked only on controllers compatible with the MS generic PCI IDE driver (and also on KVM).
Just to be sure, you are not using the virtio-blk driver for Windows here?
I have seen similar crashes with the older version of virtio-blk when used on
recent versions of KVM.
On 7 October 2010 11:05, Jes Sorensen <email address hidden> wrote:
> Just to be sure, you are not using the virtio-blk driver for Windows
> here?
>
> I have seen similar crashes with the older version of virtio-blk when used on
> recent versions of KVM.
>
> --
> DRIVER_IRQL_NOT_LESS_OR_EQUAL booting WIndows XP with Synaptics driver installed
> https://bugs.launchpad.net/bugs/639651
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
>
> Status in QEMU: New
> Status in Debian GNU/Linux: New
>
> Bug description:
> Positng the issue here since I did not get any reply on the ML.
>
> I was trying to update some windows XP (SP3) images in kvm.
>
> It worked fine several times but last time I added mass storage
> drivers to sysprep and now on the second boot after reseal (the first
> is mini-setup) I get a BSOD with message
> DRIVER_IRQL_NOT_LESS_OR_EQUAL.
>
> It turns out that the error is unrelated to storage drivers. It is triggered by Synaptics driver installing for the PS2 mouse in kvm (which does not happen in VirtualBox or on real hardware).
>
> The image is originally created on hardware with MP acpi (not virtualization).
>
> qemu-kvm 0.12.5+dfsg-2
>
Actually the issue is caused by the Synaptics touchpad driver binding
to the PS/2 mouse device in qemu.
I have no idea how PS/2 devices are detected but the one present in
qemu is misdetected as a synaptics touchapd by the Synaptics driver
for Windows.
As a workaround I have patched my qemu to not enable the PS/2 mouse device.
Thanks
Michal
On 10/07/10 11:51, Michal Suchanek wrote:
> Actually the issue is caused by the Synaptics touchpad driver binding
> to the PS/2 mouse device in qemu.
>
> I have no idea how PS/2 devices are detected but the one present in
> qemu is misdetected as a synaptics touchapd by the Synaptics driver
> for Windows.
>
> As a workaround I have patched my qemu to not enable the PS/2 mouse device.
Hi Michal,
If you have the time to look, it would be interesting to see what
actually goes over the wire to/from the PS/2 driver in QEMU just prior
to the crash. It would be good to get this fixed.
Cheers,
Jes
I have no idea how to log the data.
I looked at the qemu man page but it does not even mention the PS/2
mouse as a chardev nor offers an option to log traffic of chardevs
without attaching them to a file and thus detaching them from the
emulated device.
Thanks
Michal
On 10/07/10 12:17, Michal Suchanek wrote:
> I have no idea how to log the data.
>
> I looked at the qemu man page but it does not even mention the PS/2
> mouse as a chardev nor offers an option to log traffic of chardevs
> without attaching them to a file and thus detaching them from the
> emulated device.
I would attack it by hacking hw/ps.c a bit to monitor the transactions
in ps2_queue() and ps2_read_data().
Cheers,
Jes
Attaching logged PS/2 port communication.
For reference attaching the patch used for obtaining the log.
I guess the problem here is that qemu emulates some very basic mouse (reported as PS/2 compatible mouse in Windows) whereas real hardware usually has a fancy mouse (reported as MS Explorer compatible mouse in Windows).
I don't know how PS/2 mice are detected but due to different mice being detected differently there is obviously some detection mechanism.
The Windos device IDs in a Touchpad driver that does not exhibit the problem (synaptics v8)
[SynMfg]
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN010D
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN010E
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN010F
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0110
%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN0111
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0112
%PS2.SynDeviceDesc% = HP__0100__PS2_Inst,*SYN0113
%PS2.SynDeviceDesc% = HP__0100__PS2_Inst,*SYN0114
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0115
%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN0116
%PS2.SynDeviceDesc% = HP_GROUP1_PS2_Inst,*SYN0117
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0118
%PS2.SynDeviceDesc% = HP_GROUP5_PS2_Inst,*SYN0119
%PS2.SynDeviceDesc% = HP_GROUP6_PS2_Inst,*SYN011A
%PS2.SynDeviceDesc% = HP_GROUP4_PS2_Inst,*SYN011B
%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN011C
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN011D
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN011E
%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN011F
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0120
%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN0121
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0122
%PS2.SynDeviceDesc% = HP_GROUP7_PS2_Inst,*SYN0123
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0124
%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN0125
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0126
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0127
%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN0128
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0129
%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN012A
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN012B
%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN012C
and in drivers that do exhibit the problem (note the first device):
Synaptics v9
[SynMfg]
%PS2.SynDeviceDesc% = HP__0100__PS2_Inst,*PNP0F13
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN010D
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN010E
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN010F
%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN0110
%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN0111
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0112
%PS2.SynDeviceDesc% = HP__0100__PS2_Inst,*SYN0113
%PS2.SynDeviceDesc% = HP__0100__PS2_Inst,*SYN0114
%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN0115
%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN0116
%PS2.SynDeviceDesc% = HP_GROUP1_PS2_Inst,*SYN0117
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0118
%PS2.SynDeviceDesc% = HP_GROUP5_PS2_Inst,*SYN0119
%PS2.SynDeviceDesc% = HP_GROUP6_PS2_Inst,*SYN011A
%PS2.SynDeviceDesc% = HP_GROUP4_PS2_Inst,*SYN011B
%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN011C
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN011D
%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN011E
%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN011F
%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN0120
%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN0121
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0122
%PS2.SynDeviceDesc% = HP_GROUP7_PS2_Inst,*SYN0123
%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN0124
%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN0125
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0126
%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN0127
%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN0128
%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN0129
%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN012A
%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN012B
%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN012C
%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN012D
%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN012E
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN012F
%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN0130
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0131
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0132
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0133
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0134
%PS2.SynDeviceDesc% = HP_GROUP10_PS2_Inst,*SYN0135
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN0136
%PS2.SynDeviceDesc% = HP_GROUP3_PS2_Inst,*SYN0137
%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN0138
%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN0139
%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN013A
%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN013B
%PS2.SynDeviceDesc% = HP_GROUP9_PS2_Inst,*SYN013C
%PS2.SynDeviceDesc% = HP_GROUP8_PS2_Inst,*SYN013D
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN013E
%PS2.SynDeviceDesc% = HP_GROUP2_PS2_Inst,*SYN013F
Syanptics v14
[SynMfg]
%PS2.DeviceDesc% = DEFAULT__0000__PS2_Inst,*PNP0F13,*PNP0F0E,*PNP0F03,*PNP0F12 ; Std PS/2 mouse
%PS2.SynDeviceDesc% = DEFAULT__0000__PS2_Inst,*SYN0002 ; Synaptics PS2 TouchPad
Either of the synaptics drivers v9 and v14 would bind to the qemu mouse and crash the system when installed.
QEMU 0.12 is pretty much outdated nowadays ... can you still reproduce this problem with the latest version of QEMU, or can we close this ticket nowadays?
Does qemu allow to disable the PS/2 port now?
If so then there is easy workaround in case something similar ever happens.
Hmm, I'm not aware of a way to disable the PS2 mouse in QEMU yet. Looking at your other related bug (https://bugs.launchpad.net/qemu/+bug/813546), I think you might need to discuss that patch on the qemu-devel mailing list.
[Expired for QEMU because there has been no activity for 60 days.]
|