Re: NetBSD 10.0 BETA kernel testing: framebuffer

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Mon, 23 Jan 2023 09:33:45 +0100
> From: tlaronde%polynum.com@localhost
> 
> Le Mon, Jan 23, 2023 at 05:17:29AM +0700, Robert Elz a écrit :
> >     Date:        Sun, 22 Jan 2023 20:27:24 +0100
> >     From:        tlaronde%polynum.com@localhost
> >     Message-ID:  <Y82OHMUo9kDzjlZW%polynum.com@localhost>
> > 
> > 
> >   | +Zone  kernel: Available graphics memory: 9007199254079374 KiB
> > 
> > I see something like that too, but while it is obviously absurd,
> > I'm not sure that it actually does any harm (maybe) - my system
> > mostly works -- though I am still using wsfb - the last time I
> > tried to start X with nouveau and no X server config at all
> > (a week or so ago) the kernel crashed very soon after.
> > 
> > In every case I have looked that big number has been (when converted
> > to bytes, which the actual value being printed is - the output simply
> > divides by 2^10 (ie: >>10) for our convenience, a value of the same
> > general form, in your case
> > 
> >    9007199254079374 KiB == 9223372036177278976 bytes == 0x7FFFFFFFD79E3800
> > 
> > To me that suggests that probably something has a 64 bit value set to
> > MAXINT, and then writes a 32 bit value on top of it (and then treats that
> > as a 64 bit value).   The top 32 bits being 0x7FFFFFFF seems always there.
> > [...]

This is the result of an integer overflow.  It started to happen after
a change in some uvm kernel memory parameters which are used by a
Linux API shim, struct sysinfo::totalhigh.  The definition of
si_meminfo, which initializes this, is wrong, but previously the
kernel map virtual size was usually much smaller than the amount of
physical RAM anyway so it would print a less bonkers number in the
past.  This should be fixed, but it's only relevant to allocation in
low-memory situations, not relevant to mode setting early at boot.

> Another possibility is a ptr diff'ing that gave the correct value
> previously and is not pertinent anymore because the memory address hasi
> changed:
> 
> 9.2:
> -radeondrmkmsfb0: framebuffer at 0xffffb000aec89000, size 1600x900, depth 32, stride 6400
> 
> while 10.0 is:
> +radeondrmkmsfb0: framebuffer at 0xe034d000, size 1600x900, depth 32, stride 6400

Red herring:

- 9.2 prints the framebuffer's kernel virtual address, which is not
  very useful (and bad for kaslr).

- 10.0 prints the framebuffer's physical address.

Nothing changed in what is stored or calculated -- only in what is
printed, in genfb.c 1.79.