tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NetBSD 10.0 BETA kernel testing: framebuffer



Le Sun, Jan 22, 2023 at 02:56:47PM +0100, tlaronde%polynum.com@localhost a écrit :
> [...]
> 
> The main difference is about the framebuffer: previous kernel version
> picked the correct mode. NetBSD 10.0 does not and use "entry level"
> mode 640x480x67, resulting streched fat big characters; message:
> 
> no data for est. mode 640x480x67
> 
> while in dmesg the framebuffer has the same dimensions as with the
> 9.2 kernel:
> 
> 9.2:
> -radeondrmkmsfb0: framebuffer at 0xffffb000aec89000, size 1600x900, depth 32, stride 6400
> 
> 10.0:
> +radeondrmkmsfb0: framebuffer at 0xe034d000, size 1600x900, depth 32, stride 6400
> 

The differences between 9.2 (/^-/) and 10.0 (/^+/) extracted:

-kern info: [drm] initializing kernel modesetting (CEDAR 0x1002:0x68F9 0x174B:0xE164).
+initializing kernel modesetting (CEDAR 0x1002:0x68F9 0x174B:0xE164 0x00).
-Zone  kernel: Available graphics memory: 2601178 kiB
-Zone   dma32: Available graphics memory: 2097152 kiB
+Zone  kernel: Available graphics memory: 9007199254079374 KiB
+Zone   dma32: Available graphics memory: 2097152 KiB

Note the value, on 10.0 about the "Zone kernel" and cf. with the correct
(9.2) one.

In PR #56847, this is mentionned about "nouveau" (and I have "radeon")
and about the problem been with UEFI and not BIOS: this is incorrect,
since my node is in legacy boot: it uses BIOS and the value is
incorrect. So the problem is not UEFI vs. BIOS.

There is also a third argument about CEDAR in 10.0 not existing in
9.2.  May be the same as for the sound: 10.0 is not enumerating in
the same order, and what succeeded previously because the first
entry was fortunately the correct one, is now failing.

Note: I stumbled upon PR #56847, previously, while searching
something else and had quite a time, now, remembering it, finding
it back with the PR search tools. And then, trying to find a way to find
it back... I stumbled on a page by D. Holland stating that the bug
report system should be revamped. It's difficult not to concur...

May I suggest that a future system should send candidates PR to a
mailing list so that keywords and sorting is done by knowledgeable
people in order to put in their vincinity PRs based on the moon they
are (probably) pointing to, instead of the finger of the reporter ?
(It's not a derision against the reporter---me included; the
reporter reports what he sees: symptoms.)
-- 
        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


Home | Main Index | Thread Index | Old Index