Bug 218800 - USB Keyboard Interrupts messing with VGA Output
Summary: USB Keyboard Interrupts messing with VGA Output
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: 11.0-STABLE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-usb mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-21 20:23 UTC by Kyle
Modified: 2018-02-18 10:24 UTC (History)
2 users (show)

See Also:


Attachments
Dmesg output (10.46 KB, text/plain)
2017-04-21 20:23 UTC, Kyle
no flags Details
Pciconf output (11.76 KB, text/plain)
2017-04-21 20:24 UTC, Kyle
no flags Details
Usbconfig output (889 bytes, text/plain)
2017-04-21 20:24 UTC, Kyle
no flags Details
Usbdump output (31.07 KB, text/plain)
2017-04-21 20:24 UTC, Kyle
no flags Details
Kernel procs (82.20 KB, text/plain)
2017-04-23 09:08 UTC, Kyle
no flags Details
Vmstat output (780 bytes, text/plain)
2017-04-23 09:15 UTC, Kyle
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle 2017-04-21 20:23:34 UTC
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.
Comment 1 Kyle 2017-04-21 20:24:01 UTC
Created attachment 181987 [details]
Pciconf output
Comment 2 Kyle 2017-04-21 20:24:21 UTC
Created attachment 181988 [details]
Usbconfig output
Comment 3 Kyle 2017-04-21 20:24:44 UTC
Created attachment 181989 [details]
Usbdump output
Comment 4 Hans Petter Selasky freebsd_committer 2017-04-22 09:12:13 UTC
> 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
Comment 5 Kyle 2017-04-23 01:27:08 UTC
(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?
Comment 6 Hans Petter Selasky freebsd_committer 2017-04-23 08:41:39 UTC
Try to collect the following log:

procstat -ak > kernelprocs.txt
Comment 7 Kyle 2017-04-23 09:08:03 UTC
Created attachment 182010 [details]
Kernel procs
Comment 8 Hans Petter Selasky freebsd_committer 2017-04-23 09:10:46 UTC
And also:

vmstat -i > vmstat.txt


It looks like an IRQ is going loose, cause the issue you are describing.
Comment 9 Kyle 2017-04-23 09:15:36 UTC
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.
Comment 10 Kyle 2017-04-23 09:27:35 UTC
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
Comment 11 Hans Petter Selasky freebsd_committer 2017-04-23 10:04:59 UTC
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
Comment 12 Kyle 2017-04-24 05:29:28 UTC
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.
Comment 13 Kyle 2017-04-24 05:41:34 UTC
I loaded the UHCI driver back with kldload after the system had booted up, the problem immediately came back again.
Comment 14 Kyle 2017-04-27 22:02:06 UTC
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?
Comment 15 Masachika ISHIZUKA 2018-02-16 06:35:13 UTC
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.
Comment 16 Masachika ISHIZUKA 2018-02-16 06:53:38 UTC
(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).
Comment 17 Masachika ISHIZUKA 2018-02-18 10:24:57 UTC
My problem of duron is the same issue of bug 215021.