daily CVS update output
Updating src tree: P src/UPDATING P src/distrib/sets/lists/xcomp/mi P src/distrib/sets/lists/xdebug/md.alpha P src/distrib/sets/lists/xdebug/md.amd64 P src/distrib/sets/lists/xdebug/md.amiga P src/distrib/sets/lists/xdebug/md.bebox P src/distrib/sets/lists/xdebug/md.cats P src/distrib/sets/lists/xdebug/md.dreamcast P src/distrib/sets/lists/xdebug/md.evbarm P src/distrib/sets/lists/xdebug/md.evbarm.armeb P src/distrib/sets/lists/xdebug/md.evbmips P src/distrib/sets/lists/xdebug/md.evbppc P src/distrib/sets/lists/xdebug/md.ews4800mips P src/distrib/sets/lists/xdebug/md.hp300 P src/distrib/sets/lists/xdebug/md.hpcarm P src/distrib/sets/lists/xdebug/md.hpcmips P src/distrib/sets/lists/xdebug/md.hpcsh P src/distrib/sets/lists/xdebug/md.hppa P src/distrib/sets/lists/xdebug/md.i386 P src/distrib/sets/lists/xdebug/md.ibmnws P src/distrib/sets/lists/xdebug/md.iyonix P src/distrib/sets/lists/xdebug/md.luna68k P src/distrib/sets/lists/xdebug/md.mac68k P src/distrib/sets/lists/xdebug/md.macppc P src/distrib/sets/lists/xdebug/md.netwinder P src/distrib/sets/lists/xdebug/md.newsmips P src/distrib/sets/lists/xdebug/md.ofppc P src/distrib/sets/lists/xdebug/md.pmax P src/distrib/sets/lists/xdebug/md.prep P src/distrib/sets/lists/xdebug/md.sgimips P src/distrib/sets/lists/xdebug/md.shark P src/distrib/sets/lists/xdebug/md.sparc P src/distrib/sets/lists/xdebug/md.sparc64 P src/distrib/sets/lists/xdebug/md.vax P src/distrib/sets/lists/xdebug/md.zaurus P src/distrib/sets/lists/xserver/md.alpha P src/distrib/sets/lists/xserver/md.amd64 P src/distrib/sets/lists/xserver/md.amiga P src/distrib/sets/lists/xserver/md.bebox P src/distrib/sets/lists/xserver/md.cats P src/distrib/sets/lists/xserver/md.dreamcast P src/distrib/sets/lists/xserver/md.evbarm P src/distrib/sets/lists/xserver/md.evbmips P src/distrib/sets/lists/xserver/md.evbppc P src/distrib/sets/lists/xserver/md.ews4800mips P src/distrib/sets/lists/xserver/md.hp300 P src/distrib/sets/lists/xserver/md.hpcarm P src/distrib/sets/lists/xserver/md.hpcmips P src/distrib/sets/lists/xserver/md.hpcsh P src/distrib/sets/lists/xserver/md.hppa P src/distrib/sets/lists/xserver/md.i386 P src/distrib/sets/lists/xserver/md.ibmnws P src/distrib/sets/lists/xserver/md.iyonix P src/distrib/sets/lists/xserver/md.luna68k P src/distrib/sets/lists/xserver/md.mac68k P src/distrib/sets/lists/xserver/md.macppc P src/distrib/sets/lists/xserver/md.netwinder P src/distrib/sets/lists/xserver/md.newsmips P src/distrib/sets/lists/xserver/md.ofppc P src/distrib/sets/lists/xserver/md.pmax P src/distrib/sets/lists/xserver/md.prep P src/distrib/sets/lists/xserver/md.sgimips P src/distrib/sets/lists/xserver/md.shark P src/distrib/sets/lists/xserver/md.sparc P src/distrib/sets/lists/xserver/md.sparc64 P src/distrib/sets/lists/xserver/md.vax P src/distrib/sets/lists/xserver/md.zaurus P src/external/bsd/top/dist/machine/m_netbsd.c P src/external/mit/xorg/server/drivers/Makefile P src/external/mit/xorg/server/drivers/Makefile.xf86-driver P src/external/mit/xorg/server/xorg-server/Makefile.Xserver P src/external/mit/xorg/server/xorg-server/Makefile.serverlib P src/external/mit/xorg/server/xorg-server/Makefile.servermod P src/external/mit/xorg/server/xorg-server/config/Makefile P src/external/mit/xorg/server/xorg-server/dix/Makefile P src/external/mit/xorg/server/xorg-server/hw/netbsd/x68k/Makefile P src/external/mit/xorg/server/xorg-server/hw/sun/Makefile.Xsun P src/external/mit/xorg/server/xorg-server/hw/vfb/Makefile P src/external/mit/xorg/server/xorg-server/hw/xfree86/Makefile P src/external/mit/xorg/server/xorg-server/hw/xfree86/Xorg/Makefile P src/external/mit/xorg/server/xorg-server/hw/xfree86/common/Makefile P src/external/mit/xorg/server/xorg-server/hw/xfree86/dixmods/Makefile P src/external/mit/xorg/server/xorg-server/hw/xfree86/int10/Makefile P src/external/mit/xorg/server/xorg-server/hw/xfree86/ramdac/Makefile P src/external/mit/xorg/server/xorg-server/hw/xfree86/xf86modes/Makefile P src/external/mit/xorg/server/xorg-server/hw/xfree86/xorgos/Makefile P src/external/mit/xorg/server/xorg-server/include/Makefile P src/external/mit/xorg/server/xorg-server/os/Makefile P src/external/mit/xorg/server/xorg-server/present/Makefile P src/external/mit/xorg/server/xorg-server/xfixes/Makefile P src/share/mk/bsd.x11.mk P src/sys/external/bsd/drm2/dist/drm/radeon/radeon_btc_dpm.c P src/sys/external/bsd/drm2/dist/drm/radeon/radeon_cypress_dpm.c P src/sys/kern/kern_ksyms.c Updating xsrc tree: P xsrc/external/mit/xf86-video-ag10e/dist/src/ag10e.h P xsrc/external/mit/xf86-video-ati/dist/src/radeon_modes.c P xsrc/external/mit/xf86-video-ati-kms/dist/src/compat-api.h P xsrc/external/mit/xf86-video-ati-kms/dist/src/radeon.h P xsrc/external/mit/xf86-video-crime/dist/src/crime.h P xsrc/external/mit/xf86-video-glint/dist/src/glint.h P xsrc/external/mit/xf86-video-igs/dist/src/igs.h P xsrc/external/mit/xf86-video-intel/dist/src/sna/sna_accel.c P xsrc/external/mit/xf86-video-intel/dist/src/sna/sna_video.h P
Re: Weird clock behaviour with current (amd64) kernel
On Fri, 15 Jul 2022, Robert Elz wrote:
If that is all it is, it is barely worth fixing ... though this
must have happened sometime in the 9.99.9[78] series (sometime
after early last Dec).
Farther back than that I think: 9.2_STABLE does the same thing.
On Fri, 15 Jul 2022, Michael van Elst wrote:
Whatever driver you use either doesn't translate correctly or badly
assumes some hardware configuration (e.g. color palette) when booting.
Unsurprisingly, EFI also has a colour-index similar to VGA (see:
/usr/src/sys/external/bsd/gnu-efi/dist/inc/eficon.h). I tried fixing the
indexes like this, but, it doesn't for some (autoconfig?) reason. Can
only look into this after I come back from my road-trip.
---
diff -urN a/src/sys/arch/x86/x86/genfb_machdep.c
b/src/sys/arch/x86/x86/genfb_machdep.c
--- a/src/sys/arch/x86/x86/genfb_machdep.c 2021-01-28 01:57:31.0
+
+++ b/src/sys/arch/x86/x86/genfb_machdep.c 2022-07-15 23:29:07.334415944
+
@@ -163,24 +163,60 @@
return 1;
}
+/*
+ * translate WS(=ANSI) color codes to EFI/PC ones
+ */
+#define bg(x) ((x)<<4U)
+static const unsigned char fgansitopc[] = {
+ WSCOL_BLACK, WSCOL_BLUE, WSCOL_GREEN, WSCOL_CYAN, WSCOL_RED,
+ WSCOL_MAGENTA, WSCOL_BROWN, WSCOL_WHITE,
+ WSCOL_LIGHT_GREY, WSCOL_LIGHT_BLUE, WSCOL_LIGHT_GREEN, WSCOL_LIGHT_CYAN,
+ WSCOL_LIGHT_RED, WSCOL_LIGHT_MAGENTA, WSCOL_LIGHT_BROWN,
WSCOL_LIGHT_WHITE
+}, bgansitopc[] = {
+ bg(WSCOL_BLACK), bg(WSCOL_BLUE), bg(WSCOL_GREEN), bg(WSCOL_CYAN),
+ bg(WSCOL_RED), bg(WSCOL_MAGENTA), bg(WSCOL_BROWN), bg(WSCOL_LIGHT_GREY)
+};
+#undef bg
+
+static void
+x86_genfb_pc_colour(long *attr)
+{
+ uint32_t fg, bg, flag;
+ long aa;
+
+ rasops_unpack_attr(*attr, , , NULL);
+ if (__predict_false(fg >= sizeof(fgansitopc) || bg >=
sizeof(bgansitopc))) {
+ aprint_normal("x86_genfb_pc_colour: out of range\n");
+ return;
+ }
+ flag = *attr & 0xU;
+ aa = fgansitopc[fg] << 24 | bgansitopc[bg] << 16 | flag;
+ aprint_normal("x86_genfb_pc_colour: old = 0x%lX, new = 0x%lX\n", *attr,
aa);
+ *attr = aa;
+}
+
int
x86_genfb_cnattach(void)
{
static int ncalls = 0;
struct rasops_info *ri = _genfb_console_screen.scr_ri;
- long defattr;
+ long defattr = 0;
/* XXX jmcneill
* Defer console initialization until UVM is initialized
*/
+ aprint_normal("x86_genfb_cnattach()\n");
++ncalls;
if (ncalls < 3)
return -1;
- if (!x86_genfb_init())
+ if (!x86_genfb_init()) {
+ aprint_normal("x86_genfb_init ERROR\n");
return 0;
+ }
ri->ri_ops.allocattr(ri, 0, 0, 0, );
+ x86_genfb_pc_colour();
wsdisplay_preattach(_genfb_stdscreen, ri, 0, 0, defattr);
return 1;
---
-RVP
Removing swapfile takes a lock for long time
I've noticed that when you do ``swapctl -d ' all accesses to the count-of-swapped-out-pages are blocked. Seems that bringing the out-swapped pages back takes some lock for the entire process, which can be quite lengthy if there's a lot of swap... Among other use cases, there's no way to tell how-many-pages-remain- to-swap-in; it also seems to prevent running processes from bringing their own pages back in. Shouldn't we be occassionally releasing-and-reacquiring the relevant lock, so that other things can also make progress? ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Weird clock behaviour with current (amd64) kernel
Date:Fri, 15 Jul 2022 13:32:55 +0900 From:Masanobu SAITOH Message-ID: <87553319-950b-7dad-ac64-29d2c25d1...@execsw.org> | Could you show me the full dmesg with verbose output? I could, but it turns out to be about a megabyte, so unless you need to see all that noise, perhaps just this will help: jacaranda$ grep -i TSC ~/dmesg*cold [ 1.03] cpu0: Use lfence to serialize rdtsc [ 1.03] cpu0: TSC freq CPUID 341760 Hz [ 1.031552] cpu0: TSC freq CPUID 341760 Hz [ 1.031552] cpu0: TSC freq calibrated 10483939000 Hz [ 1.457151] timecounter: Timecounter "TSC" frequency 10483939000 Hz quality 3000 When that was running, I did a while sleep 1; do date; done loop, and watched it compared with time from my phone. The date lines showed nicely incrementing seconds, but each "sleep 1" lasted for (about) 3 seconds. I switched from TSC to hpet0 and repeated the loop, the sleeps still slept for 3 seconds, but now time went up in steps of 3. (ie: time of day keeping became accurate, internal relative times remained broken). It is difficult to believe that the ratio 10483939000/341760 (== 3.067) is not related here. A different boot produced this instead [ 1.03] cpu0: TSC freq CPUID 341760 Hz [ 1.031706] cpu0: TSC freq CPUID 341760 Hz [ 1.031706] cpu0: TSC freq calibrated 10491257000 Hz [ 1.345506] timecounter: Timecounter "TSC" frequency 10491257000 Hz quality 3000 A similar calibrated value, but not identical. That kind of looks like the PCI_CONFIG_DUMP output/scrolling/something related is interfering with the calibration ... all the messages with dmesg timestamps of 1.03xxx are being produced while all of that is happening. The 1.000 message is before the config dump starts, the 1.3455 or 1.457... messages appear after the config dump has ended. | i.e. add -v option to the boot command in /boot.cfg. I can't do exactly that, as I cannot find a boot.cfg file anywhere that gets used (this is another issue I'm having, which I was going to ask about sometime) - I have been modifying the banner= strings on every one I can find (turns out I have a lot of them... none being used) so I know when one is picked. None of the boot.cfg files I can find has the ascii art flag in the banner - the menu printed by efiboot does have that. So, instead I simply hand typed a boot command, with -v at the end. I'm not sure that worked (that is, the system certainly booted, but I don't know that the -v flag worked). If you'd like to see the complete dmesg I can make that available (either one from a cold boot, or the subsequent one, from a reboot, where the previous boot's dmesg is still in the buffer - that file is about 2MB). For comparison, when I boot generic (built from the same kernel sources, but no pci config dump of course) what I see is: [ 1.03] cpu0: Use lfence to serialize rdtsc [ 1.03] cpu0: TSC freq CPUID 341760 Hz [ 1.059545] cpu0: TSC freq CPUID 341760 Hz [ 1.059545] cpu0: TSC freq calibrated 3417601000 Hz [ 2.106529] timecounter: Timecounter "TSC" frequency 3417601000 Hz quality 3000 That there is no info not there which is included above, is why I suspect the -v might not have worked .. of course, this is all from a simple grep (using -i, which is why that rdtsc line is included). Of course, if the additional info you are looking for doesn't contain "tsc" (or TSC) then I wouldn't have found it, in which case either I give you the whole dmesg, or you supply a different grep pattern (if I can find one line, I can easily extract any relevant looking surrounding lines). kre
Re: Weird clock behaviour with current (amd64) kernel
Date:Fri, 15 Jul 2022 05:12:10 - (UTC) From:mlel...@serpens.de (Michael van Elst) Message-ID: | Does the color shift also happen after a cold boot ? Yes, it is yellow, rather than cyan, when the system boots, cold or warm (or if booting warm after linux had borrowed the system for a few minutes). For the cold boot, I made it quite cold (not literally, no ice involved) - shutdown -p, then switched off the power supply, and removed the power cord, and left it like that about a minute, before supplying power and booting. kre
Re: FYI: new X server in -current, among other X things
Thanks for your work. mrg@ wrote: > i've updated most of xsrc to their latest versions. > fontconfig and Mesa are remaining. i've tested the > new code on amd64 and arm64, and built several ports > to confirm they still build. the biggest change is > the new xorg-server. On 1.21.x, I'm afraid there are two known issue for ancient Tier-II ports. (1) out of bounds problem in xserver/hw/xfree86/modes/xf86Crtc.h OpenBSD/luna88k maintainer (Kenji Aoyama) reported the following fix was neceesary for non-XFree86 driver based dumb server (on luna88k etc.): https://gist.github.com/ao-kenji/afb0ea5b6dca04975161f84ab41ba32b https://gist.github.com/ao-kenji/b0fd6b876605ba1b2b43309233566153 https://cvsweb.openbsd.org/cgi-bin/cvsweb/xenocara/xserver/hw/xfree86/modes/xf86Crtc.h#rev1.16 (2) "-flipPixels" option removal "-flipPixels" option (that inverts black and white on 1bpp server) has been removed since 1.21. https://gitlab.freedesktop.org/xorg/xserver/-/commit/d1c00c859c6676fbb540420c9055788bc19cb18f As noted in the log the upstream authors claim "No supported driver supports 1bpp anymore, nor has in a very long time." Howeverwe we still have several working servers (xf86-video-wsfb based servers on mac68k and luna68k, monolithic servers for sun3 and x68) and at least there was a report that this option was mandatory on SE/30. So I would like to revert this change. I've filed several issue reports about the 1bpp server including this, but it looks the upstream has ~no interest to keep it. https://gitlab.freedesktop.org/xorg/xserver/-/issues/1057 https://gitlab.freedesktop.org/xorg/xserver/-/issues/1056 Thanks, --- Izumi Tsustui
Re: Weird clock behaviour with current (amd64) kernel
Date:Fri, 15 Jul 2022 05:12:10 - (UTC) From:mlel...@serpens.de (Michael van Elst) Message-ID: | Does the color shift also happen after a cold boot ? Not sure, I rarely do that, and don't think I ever have for a kernel intended to have cyan text. I will try it when I next boot in a bit. kre ps: wscons seems to be correct, it is whatever is before that which gets the colours wrong - the early boot messages (eg: the copyright message output, and everything around and following that until the graphics switch is made).
