Still experiencing atkbd serio0: Spurious NAK on isa0060/serio0.

[kcamluap]

I have an absurd problem, where SSH to one single host over a VPN connection (required) causes the disk on my host to spike, and the only error message that has been logged that shows any real indication of a problem is not even consistently reproducible.

SSH to other hosts over the same VPN works fine. I have had this problem since 5.0.30 and another version that I have forgotten.

The only info I can find for this error is 10 years old on average, and I am out of ideas.

ssh -vvvvvvvvvvvv INTERNAL HOSTNAME - REMOVED OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016 debug1: Reading configuration data /home/paco/.ssh/config debug1: /home/paco/.ssh/config line 1: Applying options for * debug1: /home/paco/.ssh/config line 11: Applying options for INTERNAL HOSTNAME - REMOVED debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug3: resolve_canonicalize: not canonicalizing hostname "INTERNAL HOSTNAME - REMOVED" (max dots 1) debug1: Executing proxy command: exec /usr/bin/ssh VPN INFO - REMOVED debug1: identity file /home/paco/.ssh/id_rsa type 1 debug1: key_load_public: No such file or directory debug1: identity file /home/paco/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/paco/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/paco/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/paco/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/paco/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/paco/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/paco/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 debug1: permanently_drop_suid: 1000 ^C

This is always where it hangs. dmesg -wH has nothing. /etc/rc.local:

echo "4 4 1 7" > /proc/sys/kernel/printk

from previous bug (the 10 year old one).

The only issue I can come up with on the host is the use of Veracrypt 1.19. Unfortunately, due to the way software is managed here I am a bit stuck with this configuration. I can easily change vbox versions.

I am out of ideas and this is causing a loss of work and sanity. Please take a look, and excuse any missing troubleshooting data, as I am unsure what is or is not of use, or how to collect it all.

Thank you.

[kcamluap]

Ugh, I'm so sorry for the formatting on the ssh.

ssh -vvvvvvvvvvvv INTERNAL HOSTNAME - REMOVED
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016
debug1: Reading configuration data /home/paco/.ssh/config
debug1: /home/paco/.ssh/config line 1: Applying options for *
debug1: /home/paco/.ssh/config line 11: Applying options for INTERNAL HOSTNAME - REMOVED
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug3: resolve_canonicalize: not canonicalizing hostname "INTERNAL HOSTNAME - REMOVED" (max dots 1)
debug1: Executing proxy command: exec /usr/bin/ssh INTERNAL HOSTNAME - REMOVED
debug1: identity file /home/paco/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/paco/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/paco/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/paco/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/paco/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/paco/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/paco/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/paco/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
debug1: permanently_drop_suid: 1000
^C


/var/log/syslog.1:Jan 16 07:13:37 blugh kernel: [  932.721819] atkbd serio0: Spurious NAK on isa0060/serio0. Some program might be trying to access hardware directly.
/var/log/syslog.1:Jan 16 07:14:24 blugh kernel: [  979.860353] atkbd serio0: Spurious NAK on isa0060/serio0. Some program might be trying to access hardware directly.
/var/log/syslog.1:Jan 17 04:45:16 blugh kernel: [78430.523283] atkbd serio0: Spurious NAK on isa0060/serio0. Some program might be trying to access hardware directly.
/var/log/syslog.2.gz:Jan 16 05:30:27 blugh kernel: [146508.267858] atkbd serio0: Spurious NAK on isa0060/serio0. Some program might be trying to access hardware directly.
/var/log/syslog.3.gz:Jan 14 13:08:50 blugh kernel: [ 1213.647249] atkbd serio0: Spurious NAK on isa0060/serio0. Some program might be trying to access hardware directly.
/var/log/syslog.3.gz:Jan 14 13:15:08 blugh kernel: [ 1591.441084] atkbd serio0: Spurious NAK on isa0060/serio0. Some program might be trying to access hardware directly.

[Klaus Espenlaub]

The "error" is with 99.9999% certainty unrelated to the issue with ssh you're reporting, because if you use ssh then the atkbd stuff should play absolutely no role (as it's only used for keyboard input straight on the console). This message happens with certain Linux kernel versions, but it must have been around a decade since it was truly indicating an error situation. I would consider it to be a harmless warning.

Wonder if you could strace the sshd activity somehow - could be a misconfigured or otherwise buggy sshd, e.g. blocking when needing randomness but not having any entropy left in the pool.

[kcamluap]

I have tried strace with no success; the disk IO always crashed the VM.

Somehow, I missed 5.1.14, and am installing it now. I will attempt strace again.

I guess, delete this shameful 'bug' if possible, please.

Thanks.

[kcamluap]

idiocy solved, jftr.

[Klaus Espenlaub]

I take it from your response that the issue is gone. If not, feel free to reopen.