Re: [PATCH 0/2] i440fx chipset and larger system memory totals

Is there anything further that I need to do to address this issue?

On 01/05/2026 21:53, Mike Kelly wrote:
> This is a proposal for solving the problem of running i440fx chipset
> on GNU/Hurd when system memory exceeds 3.5G.
>
> I expect that this is probably just a starting point rather than the
> final solution. I'm not totally happy with the solution myself and I'm
> expecting that this pessimism will be confirmed by review.
>
> The solution summary is to:
>
> 1) Overload rumpuser_malloc() and rumpuser_free() to supply pages from
> the 32 bit physical address space regardless of whether that is
> necessary for the chipset being used. I've had to mark the original
> versions of those in rumpkernel as weak symbols by an additional patch
> within the debian/patches/series. The new versions only support
> allocation of whole pages but that is all that is seemingly needed for
> rumpdisk. I've added the new versions to rumpdisk code so that other
> users of rumpkernel are unaffected.
>
> I haven't tested rumpuser_free(). It is not called during boot,
> shutdown or a full compilation of Hurd.
>
> I haven't tested any of these changes with rumpusbdisk.
>
> 2) Alter rumpdisk_device_read to use a buffer allocated from the 32
> bit address space. Change rumpdisk_device_write to always follow the
> conditional path where the unaligned writes use the contiguously
> allocated buffer.
>
> All changes within rumpdisk are conditional on the #define
> RUMPDISK_USE_32BIT_PHYSADDRS so that the original code is still
> present.
>
> I had previously reported how using i440fx there were 0x13c pages
> allocated via rumpuser_malloc(). In fact, that total is the requested
> number of pages and the actual number of pages is more like
> 0x1be. vm_allocate_contiguous() does not yet support caller specified
> alignments other than PAGE_SIZE. The workaround for this results in
> larger than necessary allocations which accounts for the
> difference. I'll try to fix this with a different patch.
>
> Mike.