Re: NetBSD 10.0 BETA kernel testing: framebuffer

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    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.

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