Hi All,
On 26/09/2026 23:28, Mike Kelly wrote:
I've sent this out as an RFC rather than a PATCH because there is
still an outstanding issue. I hit a problem whilst testing on
hurd-i386 with the boot crashing mysteriously. It took a while to
get anywhere with understanding why. I can't fully explain what is
going on still but it's connected to the memory addressing during
early boot without paging.
Patch 4 includes a call to phystovm to convert the physical address of
the multiboot2 information structure into a virtual pointer. That
pointer is passed up to other functions as a parameter. At least it
does in the C code. The generated asm actually inlines the static
functions, stores the physical address value in the frame data instead
and uses that along with the phystovm offset in various 'MOV'
instructions. Somewhere along the way something goes wrong and it
compares physical and virtual address values for an iteration
condition and loops forever.
The above analysis was mostly wrong. I've now tracked this down to the
%ebx register getting corrupted between when it is initialised shortly
after entry to c_boot_entry() and the entry to i386at_init().
discover_x86_cpu_type() trashes %ebx because that is what the cpuid
instruction does. I'll follow up this message with a replacement for
patch 14 which preserves %ebx for both x86 architectures within
discover_x86_cpu_type().
Cheers,
Mike.
