Created attachment 181986 [details] Dmesg output My system is having issues with USB keyboards and VGA output. When I type on the keyboard, the text is slow to display (on the order of seconds usually). Sometimes, it doesn't show up at all. However, if I mash keys on the keyboard (like Ctrl, Shift, Esc, etc), it will actually update the screen. On occasion when I reboot, the system will not shutdown unless I continually press keys on the keyboard, as if the system is halting unless there is an interrupt. In addition, I am able to setup networking with SSH. When I SSH into the system, it seems to work fine remotely. I don't have any of these issue in my SSH session. I have checked vmstat -i for interrupt storms, but the interrupt levels are normal. I have attached usbdump, dmesg, and pciconf logs below.
Created attachment 181987 [details] Pciconf output
Created attachment 181988 [details] Usbconfig output
Created attachment 181989 [details] Usbdump output
> FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016 Hi, This is likely not a USB issue. Can you try to compile a new kernel using 11-stable? --HPS
(In reply to Hans Petter Selasky from comment #4) Ok, so I have upgraded to 11-stable. Whenever I am in regular, multi-user mode, the issue still persists. However, when in single-user mode, I no longer have the issue. Bug in kernel module maybe?
Try to collect the following log: procstat -ak > kernelprocs.txt
Created attachment 182010 [details] Kernel procs
And also: vmstat -i > vmstat.txt It looks like an IRQ is going loose, cause the issue you are describing.
Created attachment 182011 [details] Vmstat output I had looked at the vmstat -i output initially, and it didn't seem as bad. Note that at this point, the system has been online for about 8 hours, so the interrupts added up quite a bit than when I had initially looked.
I set hw.usb.uhci.debug to 15 and watched the messages log. Below is what is being printed ad infinitum. Apr 23 09:24:27 freebsd kernel: uhci_interrupt: uhci_interrupt: host controller halted Apr 23 09:24:27 freebsd kernel: uhci_dumpregs: usbus6 regs: cmd=0080, sts=0020, intr=000f, frnum=0417, flbase=10b3305c, sof=0040, portsc1=0080, portsc2=0080 Apr 23 09:24:27 freebsd kernel: uhci_dump_qh: QH(0xfffffe0665934000) at 0x10b34002: h_next=0x10b35002 e_next=0x00000001 Apr 23 09:24:27 freebsd kernel: uhci_dump_qh: QH(0xfffffe0665935000) at 0x10b35002: h_next=0x10b36002 e_next=0x00000001 Apr 23 09:24:27 freebsd kernel: uhci_dump_qh: QH(0xfffffe0665936000) at 0x10b36002: h_next=0x10b37002 e_next=0x00000001 Apr 23 09:24:27 freebsd kernel: uhci_dump_qh: QH(0xfffffe0665937000) at 0x10b37002: h_next=0x00000001 e_next=0x10b38000
Apr 23 09:24:27 freebsd kernel: uhci_interrupt: uhci_interrupt: host controller halted Do you have the possibility to build a kernel w/o uhci, and then try to reload this driver after boot? --HPS
Do you have the possibility to build a kernel w/o uhci, and then try to reload this driver after boot? I was able to successfully build the kernel while excluding uhci. The problem has disappeared, so the problem most definitely lies in the uhci module.
I loaded the UHCI driver back with kldload after the system had booted up, the problem immediately came back again.
A couple of updates: 1.) Compiling my kernel without SMP slows down the messages considerably. Race condition? 2.) When debug mode is enable for UHCI, the keyboard works fine on other TTYs. As far as I can see in the source, debug only dumps extra data to the screen. It shouldn't be modifying anything. If this is a race condition, could dumping to the screen be adding enough time to alleviate the issue?
I have the same problem on core-i7 machines if booting up single user mode. And more, today, my old celeron machine is broken with power unit failure, I moved this HDD to another old duron machine, it happened problem that stopped machine including ping responce until I pressed any keys. When I logged in from other machine with ssh, and do 'pkg upgrade', the machine stops operation until any keys of local keyboard are pressed. I pressed any local keys, ping responce is come back and pkg upgrade is resumed normally.
(In reply to Masachika ISHIZUKA from comment #15) The duron machine's keyboard and mouse are PS/2, not usb, and os is FreeBSD 11.1-RELEASE-p4 (userland is 11.1-RELEASE-p6).
My problem of duron is the same issue of bug 215021.