I used iPXE with wimboot to boot wim images, the configuration works well except on an old machine, whose components could mainly dateback to 2004 and 2005, BIOS only. It hangs after prompting "Emulating drive 0x81", shown as the figure below.
After compilation of wimboot with higher verbose level, I found that it enters an infinite loop, and the message starting with "INT 15,e820" points to the memmap.c section. Tracing the program, the chain is
I limited the maximum iteration in paging.c, and added some details in verbose messages of memmap.c:
...
DBG2 ( "INT 15,e820 region [%llx,%llx) type %d attr %d next=%d\n",
e820_buf.start, ( e820_buf.start + e820_buf.len ),
e820_buf.type, e820_buf.attrs, e820_ebx);
/* Skip non-RAM regions */
if ( e820_buf.type != E820_TYPE_RAM ) {
continue;
}
if ( params.ecx > offsetof ( typeof ( e820_buf ), attrs ) ) {
if ( ! ( e820_buf.attrs & E820_ATTR_ENABLED ) )
continue;
if ( e820_buf.attrs & E820_ATTR_NONVOLATILE )
continue;
}
DBG2 ( "^^ RETURNED AS E820_BUF\n" );
/* Return this region */
return &e820_buf;
} while ( e820_ebx != 0 );
DBG2 ( "NULL WILL BE RETURNED\n" );
return NULL;
And compare with a virtual machine messages:
I can now confirm that there is some bug in memmap.c: as long as the last entry (where [ebx(next) = 0]) returns, then the caller of memmap_next (usually use another while to call) enters an infinite loop.
A noticeable difference of the two figures above is about the map order. In the virtual machine, these maps are sorted, and the last entry will be ignored because it is probably reserved, then e820_ebx != 0 is checked, so memmap_next returns NULL; but in my old machine, these maps are not sorted by address offset, i.e. the last entry is possible to be any type, then it might be returned by memmap_next. Then it causes an infinite loop in paging.c(relocate_memory_high)
I used iPXE with wimboot to boot wim images, the configuration works well except on an old machine, whose components could mainly dateback to 2004 and 2005, BIOS only. It hangs after prompting "Emulating drive 0x81", shown as the figure below.
After compilation of wimboot with higher verbose level, I found that it enters an infinite loop, and the message starting with "INT 15,e820" points to the
memmap.csection. Tracing the program, the chain isI limited the maximum iteration in paging.c, and added some details in verbose messages of
memmap.c:And compare with a virtual machine messages:
I can now confirm that there is some bug in
memmap.c: as long as the last entry (where [ebx(next) = 0]) returns, then the caller ofmemmap_next(usually use anotherwhileto call) enters an infinite loop.A noticeable difference of the two figures above is about the map order. In the virtual machine, these maps are sorted, and the last entry will be ignored because it is probably reserved, then
e820_ebx != 0is checked, somemmap_nextreturns NULL; but in my old machine, these maps are not sorted by address offset, i.e. the last entry is possible to be any type, then it might be returned bymemmap_next. Then it causes an infinite loop inpaging.c(relocate_memory_high)