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. > [...]
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 FWIW, -- Thierry Laronde <tlaronde +AT+ polynum +dot+ com> http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C