Hi Michael,
On Tue, Jan 29, 2019 at 11:02 PM Michael Schmitz <[email protected]> wrote:
> On 30/01/19 3:10 AM, Kars de Jong wrote:
> Op di 29 jan. 2019 om 10:45 schreef Geert Uytterhoeven <[email protected]>:
> On Tue, Jan 29, 2019 at 10:17 AM Kars de Jong <[email protected]> wrote:
> Op ma 28 jan. 2019 om 21:32 schreef Michael Schmitz <[email protected]>:
>
> How much RAM does your HP have?
>
> It has 64 MB, so no problems there.
>
> But it is located at the end of the 32-bit address space ;-)
>
> Is HP9000/300 the only platform where that is the case?
>
> As far as I am aware of, yes. At least on m68k.
>
> Digging a bit deeper it turns out that the proposed patch from Roman
> (https://marc.info/?l=linux-m68k&m=117184910524555&w=2) that fixed my
> problem never made it into the tree.
> Since then there have been more changes to
> arch/m68k/kernel/mm/motorola.c so that patch probably needs some
> changing (and testing on other platforms).
>
> The first two hunks seem to be some safeguards for cases that cannot
> happen (memory size must be a multiple of 256 KiB, IIRC, at least on
> '020/030). Oh, you had subtracted two from the real size, to avoid wrap
> around. Yes, then the memory size is no longer a multiple of 256 KiB.
> There may be other places in the kernel where the '020/'030 assumes a
> multiple of 256 KiB, so I'd recommend not doing that.
>
> Shouldn't be needed either since I removed the "subtract 1 from size"
> from the boot loader already.
>
> The remainder is a fix for address wrap around when there is memory located
> at the end of the 32-bit address space.
> That part looks OK to me, and is still applicable.
>
> I will retest with just the last part of the patch applied.
>
> max_addr was reduced by one earlier in the last part, so isn't this one
>
> min_low_pfn = availmem >> PAGE_SHIFT;
> - max_low_pfn = max_addr >> PAGE_SHIFT;
> + max_low_pfn = (max_addr >> PAGE_SHIFT) + 1;
>
> wrong? i.e. shouldn't we use
>
> max_low_pfn = (max_addr+1) >> PAGE_SHIFT;
>
> instead?
That would give 0 if max_addr = 0xffffffff, due to overflow.
However, the workaround is not correct in the (unlikely) case where the
memory block size is not a multiple of PAGE_SIZE.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
