> Date: Mon, 23 Jan 2023 09:33:45 +0100 > From: tlaro...@polynum.com > > Le Mon, Jan 23, 2023 at 05:17:29AM +0700, Robert Elz a écrit : > > Date: Sun, 22 Jan 2023 20:27:24 +0100 > > From: tlaro...@polynum.com > > Message-ID: <y82ohmuo9kdzj...@polynum.com> > > > > > > | +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.
