Some BIOSes require us to pass in not only the continuation value (in %ebx) as returned by the previous call to INT 15,e820 but also the unmodified buffer (at %es:%di) as returned by the previous call to INT 15,e820. Apparently, someone thought it would be a worthwhile optimisation to fill in only the low dword of the "length" field and the low byte of the "type field", assuming that the buffer would remain unaltered from the previous call. This problem was being triggered by the "peek ahead" logic in get_mangled_e820(), which would read the next entry into a temporary buffer in order to be able to guarantee terminating the map with %ebx=0 rather than CF=1. (Terminating with CF=1 upsets some Windows flavours, despite being documented legal behaviour.) Work around this problem by always fetching directly into our e820 cache; that way we can guarantee that the underlying call always sees the previous buffer contents (and the same buffer address).tags/v0.9.4
|
||
245 | 245 |
|
246 | 246 |
|
247 | 247 |
|
248 |
|
|
249 |
|
|
250 |
|
|
251 |
|
|
252 |
|
|
253 |
|
|
248 | 254 |
|
249 | 255 |
|
250 | 256 |
|
251 | 257 |
|
258 |
|
|
259 |
|
|
260 |
|
|
252 | 261 |
|
253 | 262 |
|
254 | 263 |
|
|
||
262 | 271 |
|
263 | 272 |
|
264 | 273 |
|
265 |
|
|
266 |
|
|
267 |
|
|
268 |
|
|
269 |
|
|
270 |
|
|
271 |
|
|
272 |
|
|
273 |
|
|
274 |
|
|
275 |
|
|
276 |
|
|
277 |
|
|
278 |
|
|
279 |
|
|
280 |
|
|
281 |
|
|
282 |
|
|
283 |
|
|
284 | 274 |
|
285 | 275 |
|
286 | 276 |
|