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. It could also be doing a read of a 64 bit value from hardware, where most (or all) of the upper 32 bits don't really exist, and simply float, which isn't being masked - but it seems very unlikely an issue like that would affect multiple different graphics board types (from different manufacturers). I took a quick look in the kernel, and while I could find where this value exists, and is printed, attempting to track down what sets it eluded me. It looks to be via a function referenced by a structure, but I couldn't find anything which looked like it might be calling it (it may be hidden in a macro or something.) Since the same thing happens with all different video drivers, it is unlikely to be in those (though it could be a common, cut&paste buggy code type issue). kre