On Thu 29 Mar 2018 at 21:19:38 (+0100), Jonathan de Boyne Pollard wrote: > David Wright: > > >an extra ^@ character¹ > > > > Unix & Linux Stack Exchange had this last year.
These look like very different symptoms. Taken in reverse order, > * https://unix.stackexchange.com/questions/360830/ The screenshot looks as if an X session has just terminated, returning to a VC-style screen. I get this type of "problem" (though it's actually no problem at all) occasionally when I terminate X (being a startx user). It's not usually NUL characters, but always non-ASCII of some sort. For obvious reasons, it's usually £, but can be § and suchlike, and it's always characters that I'm fairly sure I typed in that X session. It's as if the characters "leaked" through into the VC that's hosting the X session. If it happened in the past, I was much less likely to spot it as X used to run on VC7 which I'd only see by chance, whereas now the X session typically runs in VC1, meaning I'm bound to notice it when it happens. I'm uncertain if I've ever seen it outside jessie. > * https://unix.stackexchange.com/questions/395494/ > > * https://unix.stackexchange.com/questions/396192/ (These two questions appear to have been merged.) Their problem appears to be persistent and widespread in its effects, whereas mine is very sporadic in occurrence, specific in effect, and only lasts between boot time and the first login on the console. The spurious NULs (assuming that's what they are) interfere with my own typing, from the decryption passphrase until and including the login password. Their reflection changes from * (passphrase) to ^@ (username) to nothing visible (during login password). The timing is always 21 seconds between each NUL character, and that's unaffected by whatever prompts and responses are taking place. As soon as there's a successful login, the problem ceases: no more NULs. I used the laptop all through yesterday after having the problem, and there were no perceptible differences from normal behaviour. I've checked the modules with and without the problem and the same modules get loaded in either case (the order obviously differs). Likewise the dmesg output is the same. I have a /lib/modules/4.9.0-6-amd64/kernel/drivers/input/input-polldev.ko but I've never seen it loaded. I think the problem has only happened with the latest kernel. FWIW the configuration differences are: --- /boot/config-4.9.0-5-amd64 2018-01-04 05:12:40.000000000 -0600 +++ /boot/config-4.9.0-6-amd64 2018-03-02 01:52:22.000000000 -0600 @@ -3 +3 @@ -# Linux/x86 4.9.65 Kernel Configuration +# Linux/x86 4.9.82 Kernel Configuration @@ -222,0 +223 @@ +# CONFIG_BPF_JIT_ALWAYS_ON is not set @@ -418,0 +420 @@ +CONFIG_RETPOLINE=y @@ -1788,0 +1791 @@ +CONFIG_GENERIC_CPU_VULNERABILITIES=y Cheers, David.
