Re: kern.boottime drift after boot?
On Tue, Oct 10, 2023 at 12:42:48PM +0100, David Brownlee wrote: > I have a system which records the output of "sysctl -n kern.boottime" > as part of a dhcpcd-exit.hook to ensure some processing only occurs > once per boot. > > Except... it doesn't quite work as the value appears to not be > constant for a given boot. It's adjusted in step with the system clock, see settime1() in kern_time.c.
Re: Add five new escape sequences to wscons
On Mon, Jan 16, 2023 at 08:20:35PM +0300, Valery Ushakov wrote: > On Mon, Jan 16, 2023 at 09:18:53 -0300, Crystal Kolipe wrote: > > > It's useful, because these sequences correspond to the terminfo > > capabilities rin, indn, vpa, hpa, and cbt as defined in the xterm > > terminfo entry. With these sequences implemented, it becomes > > slightly more practical to set TERM=xterm when connecting to remote > > systems that don't have a comprehensive terminfo database. > > Why is is desirable to set specifically TERM=xterm instead of, say, > vt220, or whichever vt entry describes wscons the closest? The xterm entry supports colour, which vt220 does not. Remote systems vary in the entries they have available in their terminfo database. In the vast majority of cases it can be expected that they will have an accurate entry for xterm. Wscons is already almost usable with the xterm control sequences, and the five I've added are enough to make many curses based programs just work. > For multi-line scroll the patch just calls scrollup/scrolldown, but > that's not what the single-line scroll commands do (see > wsemul_vt100.c) The single-line scroll commands are concerned with moving the cursor. The multi-line scroll commands, as far as I understand, are supposed to scroll the entire screen, (or the scrolling region). With my patch, the behaviour of wscons matches that of xterm for these sequences. > I'm actually not entirely convinced that it's even correct to describe > vt220 as having sf/ind scrolling capabilities, b/c the vt220 scrolling > sequences take the scrolling region into account and the terminfo > capabilities for scrolling are defined to operate on the whole screen > as far as I can tell. Again, xterm does take into account the scrolling region when interpreting these sequences, so I patched wscons to do the same. > So in its current form I don't think this patch is suitable and I'm > not convinced it's needed at all. If there is really no interest then I'll drop further work on this. I've got other patches in progress for wscons so it would be nice to know. But I don't think that your arguments are very convincing, unless you are saying that xterm is also wrong in it's emulation, or there is a bug in my patch that I am not aware of.
Re: Add five new escape sequences to wscons
On Mon, Jan 16, 2023 at 09:31:35AM -0500, Mouse wrote: > > Here is a patch to implement five additional escape sequences in the > > wscons vt100 emulation. > > Not to pick on this particular addition...but is it really still > appropriate to call it "vt100"? Not really :-). > It's not a very good VT-100 emulation, > handling a bunch of sequences differently from VT-100s (mostly things > wscons implements but VT-100s don't) and having a handful of other > mismatches (such as supporting sizes other than 80x24 and 132x24). A lot of the sequences that it supports are from later VT-series terminals.
Add five new escape sequences to wscons
Here is a patch to implement five additional escape sequences in the wscons
vt100 emulation.
This is a port of some code that I originally wrote for OpenBSD, and which was
recently accepted into CVS there.
It's useful, because these sequences correspond to the terminfo capabilities
rin, indn, vpa, hpa, and cbt as defined in the xterm terminfo entry. With
these sequences implemented, it becomes slightly more practical to set
TERM=xterm when connecting to remote systems that don't have a comprehensive
terminfo database.
The current lack of support for cbt, vpa, and hpa is actually mentioned in
the comments in the terminfo file, (see line 2533).
--- dev/wscons/wsemul_vt100_subr.c.dist 2018-12-05 22:42:20.0 -0300
+++ dev/wscons/wsemul_vt100_subr.c 2023-01-16 08:35:17.292084228 -0300
@@ -188,7 +188,7 @@
void
wsemul_vt100_handle_csi(struct vt100base_data *edp, u_char c)
{
- int n, help, flags, fgcol, bgcol;
+ int n, m, help, flags, fgcol, bgcol;
long attr, bkgdattr;
#define A3(a, b, c) (((a) << 16) | ((b) << 8) | (c))
@@ -410,6 +410,9 @@
edp->ccol -= uimin(DEF1_ARG(edp, 0), edp->ccol);
edp->flags &= ~VTFL_LASTCHAR;
break;
+ case 'G': /* CHA */
+ edp->ccol = uimin(DEF1_ARG(edp, 0)-1, edp->ncols-1);
+ break;
case 'H': /* CUP */
case 'f': /* HVP */
if (edp->flags & VTFL_DECOM)
@@ -445,15 +448,40 @@
COPYCOLS(edp, edp->ccol + n, edp->ccol, help);
ERASECOLS(edp, NCOLS(edp) - n, n, edp->bkgdattr);
break;
+ case 'S': /* SU */
+ wsemul_vt100_scrollup (edp,DEF1_ARG(edp, 0));
+ break;
+ case 'T': /* SD */
+ wsemul_vt100_scrolldown (edp,DEF1_ARG(edp, 0));
+ break;
case 'X': /* ECH erase character */
n = uimin(DEF1_ARG(edp, 0), COLS_LEFT(edp) + 1);
ERASECOLS(edp, edp->ccol, n, edp->bkgdattr);
break;
+ case 'Z': /* CBT */
+ if (edp->ccol == 0)
+ break;
+ for (m = 0; m < DEF1_ARG(edp, 0); m++) {
+ if (edp->tabs) {
+ for (n = edp->ccol - 1; n > 0; n--) {
+ if (edp->tabs[n])
+ break;
+ }
+ } else
+ n = (edp->ccol - 1) & ~7;
+ edp->ccol = n;
+ if (n == 0)
+ break;
+ }
+ break;
case 'c': /* DA primary */
if (ARG(edp, 0) == 0)
wsdisplay_emulinput(edp->cbcookie, WSEMUL_VT_ID1,
sizeof(WSEMUL_VT_ID1));
break;
+ case 'd': /* VPA */
+ edp->crow = uimin(DEF1_ARG(edp, 0)-1, edp->nrows-1);
+ break;
case 'g': /* TBC */
KASSERT(edp->tabs != 0);
switch (ARG(edp, 0)) {
Off by ones in wsemul_vt100_subr.c
The attached patch fixes a couple of off-by-ones in the wscons code.
WSEMUL_VT_ID1 and WSEMUL_VT_ID2 are string constants, and sizeof returns the
length of the string _plus_ the 0x00 terminator. This size is then supplied
to wsdisplay_emulinput, which expects to be passed just the number of
printable characters.
--- sys/dev/wscons/wsemul_vt100_subr.c.dist 2018-12-05 22:42:20.0
-0300
+++ sys/dev/wscons/wsemul_vt100_subr.c 2023-01-08 19:25:52.747978285 -0300
@@ -195,7 +195,7 @@
switch (A3(edp->modif1, edp->modif2, c)) {
case A3('>', '\0', 'c'): /* DA secondary */
wsdisplay_emulinput(edp->cbcookie, WSEMUL_VT_ID2,
- sizeof(WSEMUL_VT_ID2));
+ sizeof(WSEMUL_VT_ID2)-1);
break;
case A3('\0', '\0', 'J'): /* ED selective erase in display */
@@ -452,7 +452,7 @@
case 'c': /* DA primary */
if (ARG(edp, 0) == 0)
wsdisplay_emulinput(edp->cbcookie, WSEMUL_VT_ID1,
- sizeof(WSEMUL_VT_ID1));
+ sizeof(WSEMUL_VT_ID1)-1);
break;
case 'g': /* TBC */
KASSERT(edp->tabs != 0);
Re: ATA TRIM?
On Sun, Dec 25, 2022 at 11:10:44AM -0500, Mouse wrote: > >> I find it far more plausible that I'm doing something wrong. > > Or maybe the drive just doesn't obey the spec? > > That's possible, I suppose. But it's a brand new Kingston SSD I've used quite a few Kingston SSDs in BSD systems over the last ten years or so, and whilst they work they have all shown some odd behaviours compared to other brands. Specifically, after a couple of years of use they suddenly become very slow to _read_, I had one that was literally reading at about 2 or 3 Mb/sec compared to ~140 Mb/sec previously in the same system. A secerase has always fixed this issue every time I've encountered it. BUT, the secerase leaves the device bricked for about 60 minutes or sometimes longer. I.E. it blocks the SATA bus and most machines just hang at the BIOS for about 45 seconds until they time out. Power cycling the bricked device seemingly does nothing to help, you just have to wait until it eventually reverts to normal behaviour. We have at least five Kingston SSDs here that have all exhibited this behaviour. I've never seen it with any other SSD, and have used plenty of Crucial, Corsair, and others. > The packaging promises free technical support. I suppose I should try > to chase down a contact (the packaging gives no hint whom to contact > for that promised support) and ask. At worst I'll be told nothing > useful. That would be interesting.
Re: ATA TRIM?
On Sun, Dec 25, 2022 at 10:27:49AM -0500, Mouse wrote: > I find it far more plausible that I'm doing something wrong. Or maybe the drive just doesn't obey the spec? I've got a disk here that, when sent a SECERASE, writes 0x00 to the first 1 Gb of the media and leaves the rest unchanged. That clearly violates the spec.
Re: Intel GPIO
On Tue, Jan 25, 2022 at 02:55:09PM +, Robert Swindells wrote: > Didn't someone post that the same touchscreen controller is used in > the Pinephone? The Pinephone uses a Goodix gt917s.
Pinephone boot dmesg
Hi, I tested booting NetBSD 9.2 on a Pinephone handset, and thought you might be interested to see the dmesg. Unfortunately there seems to be a problem with the driver for the serial interface. Although the serial output from the phone seems to is fine, keystrokes are often suffering from bit-flips. For example typing, 'a', will sometimes echo back 'A', or '^A'. Since this is happening for something like 25% - 50% of keystrokes, it's virtually impossible to actually use the system. It's not a hardware problem, as I have used the same handset and serial connection with OpenBSD and Linux without any issues. Still, it's interesting to see how the hardware is detected. [ 1.000] NetBSD/evbarm (fdt) booting ... [ 1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, [ 1.000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, [ 1.000] 2018, 2019, 2020 The NetBSD Foundation, Inc. All rights reserved. [ 1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993 [ 1.000] The Regents of the University of California. All rights reserved. [ 1.000] NetBSD 9.2 (GENERIC64) #0: Wed May 12 13:15:55 UTC 2021 [ 1.000] mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/evbarm/compile/GENERIC64 [ 1.000] total memory = 3025 MB [ 1.000] avail memory = 2916 MB [ 1.000] running cgd selftest aes-xts-256 aes-xts-512 done [ 1.000] armfdt0 (root) [ 1.000] simplebus0 at armfdt0: Pine64 PinePhone (1.2) [ 1.000] simplebus1 at simplebus0 [ 1.000] cpus0 at simplebus0 [ 1.000] simplebus2 at simplebus0 [ 1.000] psci0 at simplebus0: PSCI 1.1 [ 1.000] cpu0 at cpus0: Cortex-A53 r0p4 (Cortex V8-A core) [ 1.000] cpu0: package 0, core 0, smt 0 [ 1.000] cpu0: IC enabled, DC enabled, EL0/EL1 stack Alignment check enabled [ 1.000] cpu0: Cache Writeback Granule 16B, Exclusives Reservation Granule 16B [ 1.000] cpu0: Dcache line 64, Icache line 64 [ 1.000] cpu0: L1 32KB/64B 2-way read-allocate VIPT Instruction cache [ 1.000] cpu0: L1 32KB/64B 4-way write-back read-allocate write-allocate PIPT Data cache [ 1.000] cpu0: L2 512KB/64B 16-way write-back read-allocate write-allocate PIPT Unified cache [ 1.000] cpu0: revID=0x80, PMCv3, 4k table, 64k table, 16bit ASID [ 1.000] cpu0: auxID=0x11120, FP, CRC32, SHA1, SHA256, AES+PMULL, NEON, rounding, NaN propagation, denormals, 32x64bitRegs, Fused Multiply-Add [ 1.000] cpufreqdt0 at cpu0 [ 1.000] cpu1 at cpus0: Cortex-A53 r0p4 (Cortex V8-A core) [ 1.000] cpu1: package 0, core 1, smt 0 [ 1.000] cpufreqdt1 at cpu1 [ 1.000] cpu2 at cpus0: Cortex-A53 r0p4 (Cortex V8-A core) [ 1.000] cpu2: package 0, core 2, smt 0 [ 1.000] cpufreqdt2 at cpu2 [ 1.000] cpu3 at cpus0: Cortex-A53 r0p4 (Cortex V8-A core) [ 1.000] cpu3: package 0, core 3, smt 0 [ 1.000] cpufreqdt3 at cpu3 [ 1.000] gic0 at simplebus1: GIC [ 1.000] armgic0 at gic0: Generic Interrupt Controller, 224 sources (215 valid) [ 1.000] armgic0: 16 Priorities, 192 SPIs, 7 PPIs, 16 SGIs [ 1.000] sunxisramc0 at simplebus1: SRAM Controller [ 1.000] fclock0 at simplebus0: 2400 Hz fixed clock (osc24M) [ 1.000] fclock1 at simplebus0: 32768 Hz fixed clock (ext-osc32k) [ 1.000] gtmr0 at simplebus0: Generic Timer [ 1.000] gtmr0: interrupting on GIC irq 27 [ 1.000] armgtmr0 at gtmr0: Generic Timer (24000 kHz, virtual) [ 1.060] sun50ia64ccu0 at simplebus1: A64 CCU [ 1.060] sunxinmi0 at simplebus1: R_INTC [ 1.060] sun50ia64rccu0 at simplebus1: A64 PRCM CCU [ 1.060] sunxigpio0 at simplebus1: PIO [ 1.060] gpio0 at sunxigpio0: 103 pins [ 1.060] sunxigpio0: interrupting on R_INTC [ 1.060] sunxigpio1 at simplebus1: PIO [ 1.060] gpio1 at sunxigpio1: 13 pins [ 1.060] sunxigpio1: failed to establish interrupt on R_INTC [ 1.060] sunxipwm0 at simplebus1: PWM [ 1.060] sunxide2bus0 at simplebus1: DE2 Bus [ 1.060] sunxirsb0 at simplebus1: RSB [ 1.060] sunxirsb0: interrupting on GIC irq 71 [ 1.060] iic0 at sunxirsb0: I2C bus [ 1.060] axppmic0 at iic0 addr 0x3a3: AXP803 [ 1.060] sunxirsb0: transfer error, id 0x00 [ 1.060] sunxirsb0: SRTA failed, flags = 8, error = 5 [ 1.060] axppmic0: couldn't read chipid [ 1.060] fregulator0 at simplebus0: vbat-wifi [ 1.060] sun6idma0 at simplebus1: DMA controller (8 channels) [ 1.060] sun6idma0: interrupting on GIC irq 82 [ 1.060] sunxisid0 at simplebus1: Security ID EFUSE [ 1.060] fregulator1 at simplebus0: ps [ 1.060] com0 at simplebus1: ns16550a, working fifo [ 1.060] com0: console [ 1.060] com0: interrupting on GIC irq 32 [ 1.060] com1 at simplebus1: ns16550a, working fifo [ 1.060] com1: interrupting on GIC irq 33 [ 1.060] com2 at
