Re: USB keyboard input overrun on EHCI?
I wrote: > I'll test a kernel without that "else if" block tonight. After discussion on IRC, what I'll try first of all is to change callout_reset(>sc_delay, 1, ukbd_delayed_decode, sc); to callout_reset(>sc_delay, 0, ukbd_delayed_decode, sc); inside the "else if" block. We only need to move the handling of the keyboard event out of the interrupt frame; there's no need to delay it, so unless this causes other problems for keyboard initiated DDB entry, it should be the right thing to do, anyway. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay
Re: USB keyboard input overrun on EHCI?
Brian Buhrow writes:
> hello. My recollection may be slightly wrong here since I'm
> still running NetBSD-5 in most cases, but my understanding is that
> ehci(4) connected devices are all USB-2.0 and for slower devices, the
> uhci(4) or ohci(4) hub drivers provide service.
Ah, it's not different hardware as much as different protocol choices?
I do notice that on the two laptops, where the keyboard works well,
there are "handing over full speed device" messages when connecting it,
whereas on the workstation, where it can overrun the input, this does
not occur. Maybe I should go through the BIOS configuration with a fine
tooth comb, to see if there's something there that limits devices in
what level of USB functionality they can negotiate?
Meanwhile, I think I've found something more interesting (thanks to
debugging guidance from riastradh@): in /sys/dev/usb/ukbd.c, there is
this block of code, in the interrupt handler:
if ((sc->sc_flags & FLAG_DEBOUNCE) && !(sc->sc_flags & FLAG_POLLING)) {
/*
* Some keyboards have a peculiar quirk. They sometimes
* generate a key up followed by a key down for the same
* key after about 10 ms.
* We avoid this bug by holding off decoding for 20 ms.
*/
sc->sc_data = *ud;
callout_reset(>sc_delay, hz / 50, ukbd_delayed_decode, sc);
#ifdef DDB
} else if (sc->sc_console_keyboard && !(sc->sc_flags & FLAG_POLLING)) {
/*
* For the console keyboard we can't deliver CTL-ALT-ESC
* from the interrupt routine. Doing so would start
* polling from inside the interrupt routine and that
* loses bigtime.
*/
sc->sc_data = *ud;
callout_reset(>sc_delay, 1, ukbd_delayed_decode, sc);
#endif
} else {
ukbd_decode(sc, ud);
}
If I read this correctly, the first bit says "for certain keyboards, we
have to wait 20ms after a change before accepting it, because it may be
a switch bounce, which will have cleared by then". Fine - not relevant
to me. The next bit, though, is. It says that if we're the console
keyboard, we always wait 10ms, and then handle the keyboard event (if it
is still relevant). This means, though, that if we get the next event
from the keyboard within 10ms of the last one, we may lose an event.
I haven't carefully measured the output from my new keyboard when it's
generating sequences of keypresses, but by just eyeballing it, I've
estimated it to be in in the vicinity of 50cps, or 10ms per event - and
a difference between the workstation that's being overrun and the two
laptops that aren't, is, of course, that on the former my new keyboard
is the console keyboard.
I'll test a kernel without that "else if" block tonight.
-tih
--
Most people who graduate with CS degrees don't understand the significance
of Lisp. Lisp is the most important idea in computer science. --Alan Kay
Re: Build error for port-sparc
And with even more recent sources (updated on 2020-03-04 at 02:52:55 UTC), I'm getting an error even earlier in the build: dependall ===> external/bsd/pam-u2f/bin/pamu2fcfg #create pamu2fcfg/explicit_bzero.d CC=/build/netbsd-compat/tools/x86_64/sparc/bin/sparc--netbsdelf-gcc /build/netbsd-compat/tools/x86_64/sparc/bin/nbmkdep -f explicit_bzero.d.tmp -- -std=gnu99 --sysroot=/build/netbsd-compat/dest/sparc -I/build/netbsd-compat/src_ro/external/bsd/pam-u2f/dist -I/build/netbsd-compat/src_ro/external/bsd/pam-u2f/bin/pamu2fcfg -DPACKAGE='"pam_u2f"' -DVERSION='"1.0.9"' -DHAVE_UNISTD_H /build/netbsd-compat/src_ro/external/bsd/pam-u2f/dist/explicit_bzero.c && mv -f explicit_bzero.d.tmp explicit_bzero.d In file included from /build/netbsd-compat/src_ro/external/bsd/pam-u2f/dist/explicit_bzero.c:16: /build/netbsd-compat/src_ro/external/bsd/pam-u2f/dist/util.h:9:10: fatal error: security/pam_appl.h: No such file or directory #include ^ compilation terminated. nbmkdep: compile failed. *** [explicit_bzero.d] Error code 1 Again, I'm seeing this _only_ for sparc. I've done ``build.sh release'' for literally dozens of other $ARCH without any problems. Anyone got a clue? On Tue, 3 Mar 2020, Paul Goyette wrote: With sources updated on 2020-03-02 at 13:13:48 UTC I am getting the following build error when doing a ``build.sh release'' # compile ramdisk/gethost.o /build/netbsd-compat/tools/x86_64/sparc/bin/sparc--netbsdelf-gcc -Os -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Werror --sysroot=/build/netbsd-compat/dest/sparc -DSMALL -DLIBHACK -D_REENTRANT -c -I/build/netbsd-compat/src_ro/distrib/utils/libhack/../../../lib/libc/net /build/netbsd-compat/src_ro/distrib/utils/libhack/gethost.c /build/netbsd-compat/src_ro/distrib/utils/libhack/gethost.c:76:1: error: function declaration isn't a prototype [-Werror=strict-prototypes] int h_errno; ^~~ cc1: all warnings being treated as errors ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
daily CVS update output
Updating src tree: U src/external/bsd/pam-u2f/bin/pamu2fcfg/Makefile U src/external/bsd/pam-u2f/bin/pamu2fcfg/cmdline.c U src/external/bsd/pam-u2f/bin/pamu2fcfg/cmdline.h P src/external/cddl/osnet/sys/kern/printf.c P src/external/mit/libcbor/lib/Makefile P src/lib/Makefile P src/libexec/ld.elf_so/headers.c P src/libexec/ld.elf_so/map_object.c P src/libexec/ld.elf_so/rtld.c P src/sys/conf/files P src/sys/dev/pci/if_ena.c P src/sys/dev/pci/if_ixl.c P src/sys/dev/pci/if_ti.c P src/sys/dev/usb/uhid.c P src/sys/dev/usb/usbhid.h P src/sys/kern/vfs_syscalls.c P src/sys/uvm/uvm_page.c P src/sys/uvm/uvm_vnode.c P src/tests/lib/libc/sys/t_ptrace_wait.h P src/usr.sbin/ifmcstat/ifmcstat.c Updating xsrc tree: Killing core files: Updating release-7 src tree (netbsd-7): Updating release-7 xsrc tree (netbsd-7): Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.2 P lib/Makefile P sys/ufs/ufs/dir.h P sys/ufs/ufs/ufs_lookup.c Updating release-8 xsrc tree (netbsd-8): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 35470024 Mar 4 03:11 ls-lRA.gz
Re: Panic on aarch64
Andrew Doran wrote: >On Tue, Mar 03, 2020 at 10:03:38PM +, Robert Swindells wrote: >> >> I just got this: >> >> panic: pr_phinpage_check: [vcachepl] item 0x54d19880 not part of pool >> cpu0: Begin traceback... >> trace fp ffc0405efc90 >> fp ffc0405efcb0 vpanic() at ffc000240880 netbsd:vpanic+0x160 >> fp ffc0405efd20 panic() at ffc000240974 netbsd:panic+0x44 >> fp ffc0405efdb0 pool_cache_put_paddr() at ffc00023e858 >> netbsd:pool_cache_put_paddr+0x110 >> fp ffc0405efde0 vrelel() at ffc00028b058 netbsd:vrelel+0x208 > >What file systems do you have in use? It is using ffs, msdosfs,tmpfs, kernfs, procfs & nfs. It was just reading from the main ffs partition when it paniced. Can plug the eMMC into an extender and check it on another machine if it will help.
Re: Panic on aarch64
On Tue, Mar 03, 2020 at 10:03:38PM +, Robert Swindells wrote: > > I just got this: > > panic: pr_phinpage_check: [vcachepl] item 0x54d19880 not part of pool > cpu0: Begin traceback... > trace fp ffc0405efc90 > fp ffc0405efcb0 vpanic() at ffc000240880 netbsd:vpanic+0x160 > fp ffc0405efd20 panic() at ffc000240974 netbsd:panic+0x44 > fp ffc0405efdb0 pool_cache_put_paddr() at ffc00023e858 > netbsd:pool_cache_put_paddr+0x110 > fp ffc0405efde0 vrelel() at ffc00028b058 netbsd:vrelel+0x208 What file systems do you have in use? Andrew > fp ffc0405efe20 vrecycle() at ffc00028b90c netbsd:vrecycle+0x6c > fp ffc0405efe50 vdrain_thread() at ffc00028bf54 > netbsd:vdrain_thread+0x2ac > address 0x100 is invalid > address 0xe8 is invalid > cpu0: End traceback... > > I didn't have it set to enter ddb on panic and don't have enough swap > on the eMMC disk to dump to. > > Have enabled DDB now.
Panic on aarch64
I just got this: panic: pr_phinpage_check: [vcachepl] item 0x54d19880 not part of pool cpu0: Begin traceback... trace fp ffc0405efc90 fp ffc0405efcb0 vpanic() at ffc000240880 netbsd:vpanic+0x160 fp ffc0405efd20 panic() at ffc000240974 netbsd:panic+0x44 fp ffc0405efdb0 pool_cache_put_paddr() at ffc00023e858 netbsd:pool_cache_put_paddr+0x110 fp ffc0405efde0 vrelel() at ffc00028b058 netbsd:vrelel+0x208 fp ffc0405efe20 vrecycle() at ffc00028b90c netbsd:vrecycle+0x6c fp ffc0405efe50 vdrain_thread() at ffc00028bf54 netbsd:vdrain_thread+0x2ac address 0x100 is invalid address 0xe8 is invalid cpu0: End traceback... I didn't have it set to enter ddb on panic and don't have enough swap on the eMMC disk to dump to. Have enabled DDB now.
Re: benchmark results on ryzen 3950x with netbsd-9, -current, and -current (no DIAGNOSTIC)
Hi. On Tue, Mar 03, 2020 at 08:25:25PM +1100, matthew green wrote: > here are a few build benchmark tests on an amd ryzen 3950x > system, to see the cumulative effect of the various fixes we've > seen since netbsd-9, for this 16 core/ 32 thread CPU, 64GB of > ram, separate nvme ssd for src & obj. Cool! Thank you very much for doing this. Really interesting to see these results. > below has a full summary, but the highlights: > > - building kernels into tmpfs is 10-12% faster > - DIAGNOSTIC costs 3-8% > - current's better CPU thread aware scheduler helps -j16 on >32 CPUs significantly (more than double benefit compared >to the other tests.) > - "build.sh release" is about 10% faster > - kernel builds are similar about 10% faster > - builds of ircII are 22% faster, though configure only 11% > - -j32 is faster than -j16 or -j24 > - -j40 is not much worse than -j32, occasinally faster > > and the one lowlight: > > - "du -mcs *" on a src tree already in ram has lost about 30% >performance, though still under 1 second. OK that's intriguing and something that can hopefully be diagnosed with a bit of dtrace. I'm not aware of a reason for it. > time for amd64 GENERIC kernel builds: > > -j16 -j24 -j32 -j40 >netbsd-9 2m26.561m55:301m43:461m43:82 >current (DIAG) 2m01.251m46.841m40.221m41.12 >current1m54.561m39.571m33.091m34.06 Another perspective and a couple of observations: this is from my dual socket system with 24 cores / 48 threads total, running -current and building GENERIC on a SATA disk. This is with -j48. 132.53s real 1501.10s user 3291.25s systemnov 2019 86.29s real 1537.95s user 786.29s systemmar 2020 79.16s real 1602.97s user 419.54s systemmar 2020 !DIAGNOSTIC I agree with Greg, the picture with DIAGNOSTIC isn't good. I think one of the culprits may be in the x86 pmap where it regularly scans all CPUs checking if a pmap is in use - that should probably be DEBUG. Beyond that, I don't have good ideas (other than investigation warranted). In the case of the dual socket system, the difference is pronounced and my take on it is that contention stresses the interconnect, and backpressure is then exerted on every CPU in the system, not just those CPUs actively contending with others. With a single socket system that kind of fight stays on chip in the cache. Cheers, Andrew
Re: USB keyboard input overrun on EHCI?
hello. My recollection may be slightly wrong here since I'm still running NetBSD-5 in most cases, but my understanding is that ehci(4) connected devices are all USB-2.0 and for slower devices, the uhci(4) or ohci(4) hub drivers provide service. Do these bar code scanners attach as either USB-2 or USB-1, depending on what's available on the hardware or are they USB-1.0 only devices? On older NetBSD-5 systems, if there is an ehci(4) device, but no matching uhci(4) or ohci(4) device, USB-1.0 attached devices just don't work. I don't know how we worked around that in -current, but I wonder if we're trying to run USB-1.0 devices through ehci(4) in some software emulated mode that's not working right? How does the scanner attach to the working hardware versus the broken hardware? -thanks -Brian
Re: USB: Logical Unit Is In Process Of Becoming Ready [was Re: USB umass hard drive "failed to create xfers" when attaching]
w...@netbsd.org (Thomas Klausner) writes: >umass0: using SCSI over Bulk-Only >scsibus0 at umass0: 2 targets, 1 lun per target >sd0 at scsibus0 target 0 lun 0: disk fixed >sd0(umass0:0:0:0): Check Condition on CDB: 0x00 00 00 00 00 00 >SENSE KEY: Not Ready > ASC/ASCQ: Logical Unit Is In Process Of Becoming Ready >sd0: drive offline >autoconfiguration error: sd0: unable to open device, error = 5 That's one of the design issues with wedges. A regular disk exists even when "offline" and evaluating partitions can be deferred to the time when it is opened by some process. Wedges are only created when the device is online, which means you cannot open them to trigger anything. The only option is to poll an "offline" disk regularly to find out when to retry the wedge creation. But this alone is of questionable value because this state usually refers to removable media where partitioning can easily change. So you also need to drop wedges when you detect that the medium got ejected. This may require polling as well, at least in otherwise idle periods. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
USB: Logical Unit Is In Process Of Becoming Ready [was Re: USB umass hard drive "failed to create xfers" when attaching]
While we're talking about annoyances (sorry for hijacking the thread) I often see something like: umass0 at uhub4 port 3 configuration 1 interface 0 umass0: Samsung (0x4e8) D3 Station (0x6125), rev 3.00/2.02, addr 1 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, 1 lun per target sd0 at scsibus0 target 0 lun 0: disk fixed sd0(umass0:0:0:0): Check Condition on CDB: 0x00 00 00 00 00 00 SENSE KEY: Not Ready ASC/ASCQ: Logical Unit Is In Process Of Becoming Ready sd0: drive offline autoconfiguration error: sd0: unable to open device, error = 5 I can usually work around this with # dkctl sd0 makewedges but it'd be nicer if it worked automatically... Thomas On Mon, Feb 17, 2020 at 07:56:02AM -0800, Paul Goyette wrote: > With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC > I get the following errors when plugging in a USB hard drive: > > umass0 at uhub1 port 2 configuration 1 interface 0 > umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr > 32 > umass0: using SCSI over Bulk-Only > umass0: autoconfiguration error: failed to create xfers > > This worked correctly with a 9.99.42 kernel built from sources dated > 2020-01-25 19:35:05 UTC > > Anyone got any clues on how this got broke? Or how to fix? > > > ++--+---+ > | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | > | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | > | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | > ++--+---+ >
Re: benchmark results on ryzen 3950x with netbsd-9, -current, and -current (no DIAGNOSTIC)
matthew green writes: Thanks for the very interstesting data. > below has a full summary, but the highlights: > > - DIAGNOSTIC costs 3-8% This seems higher than it ought to be. I don't doubt your measurements; I mean that probably things are being done under DIAGNOSTIC that aren't really approprirate and are better put under DEBUG. I have always believed, since using DIAGNOSTIC under 2.8BSD, that DIAGNOSTIC should basically only be adding asserttions and not doing anything expensive. Part of that is the basic intent, and part of it is that I don't think anyone should want to turn off DIAGNOSTIC for performance reasons. I don't know how to find the things that cost more (perhaps one could compile some files with and without DIAGNOSTIC?), but if we could remove any expensive things from DIAGNOSTIC that would be good. I'll suggest 1% slowdown as a goal, without really knowing how realistic that is. It's very cool to see that the gains in current overwhelm the DIAGNOSTIC slowdown. It makes me want a new motherboard with more cores :-)
Re: USB deadlock?
On Tue, Mar 03, 2020 at 12:57:28PM +, Robert Swindells wrote: > I don't have an answer to the hang but had been meaning to submit a > patch for review that might help with tracking it down. Please commit it! Martin
Re: Automated report: NetBSD-current/i386 build failure
In article <20200303122717.gb...@mail.duskware.de>, Martin Husemann wrote: >On Tue, Mar 03, 2020 at 01:29:39PM +0200, Andreas Gustafsson wrote: >> Would it be too much to ask that imports of entire new subsystems like >> this be at least build tested with "build.sh release"? > >The lossage in this case seems to depend on -j values and whether you do >incremental builds, so not clearly detectable by a simple local build >(I was able to build sparc64 and evbarm earlier today localy, while the >build cluster still fails all the builds) Yup, I build amd64 and sun2 with no issues but when I built i386 with -j 60 I was able to reproduce it. christos
Re: USB deadlock?
Thomas Klausner wrote:
>I'm doing my backups to USB disks. Last month this worked fine, with
>9.99.48/amd64 the backup process (unison) hung twice, only
>force-reboot got me out of the first one.
>
>The process is hung in ps "D+". top says "uvn_fp".
I don't have an answer to the hang but had been meaning to submit a
patch for review that might help with tracking it down.
There are two candidates for this wait point but the first six
characters of the names are the same, I just took out one character
so that top(1) could tell them apart.
I haven't seen any problems using it.
Index: uvm_vnode.c
===
RCS file: /cvsroot/src/sys/uvm/uvm_vnode.c,v
retrieving revision 1.107
diff -u -r1.107 uvm_vnode.c
--- uvm_vnode.c 27 Feb 2020 22:12:54 - 1.107
+++ uvm_vnode.c 3 Mar 2020 12:49:55 -
@@ -314,7 +314,7 @@
return 0;
}
rw_exit(uobj->vmobjlock);
- uvm_wait("uvn_fp1");
+ uvm_wait("uvnfp1");
uvm_page_array_clear(a);
rw_enter(uobj->vmobjlock, RW_WRITER);
continue;
@@ -339,7 +339,7 @@
UVMHIST_LOG(ubchist, "wait %#jx (color %ju)",
(uintptr_t)pg, VM_PGCOLOR(pg), 0, 0);
UVM_UNLOCK_AND_WAIT_RW(pg, uobj->vmobjlock, 0,
- "uvn_fp2", 0);
+ "uvnfp2", 0);
uvm_page_array_clear(a);
rw_enter(uobj->vmobjlock, RW_WRITER);
continue;
USB deadlock?
Hi! I'm doing my backups to USB disks. Last month this worked fine, with 9.99.48/amd64 the backup process (unison) hung twice, only force-reboot got me out of the first one. The process is hung in ps "D+". top says "uvn_fp". Connecting to the process with gdb does not finish. There is no big load on the machine, disks are mostly idle, and network too. I had a third occurrence last night which looked similar, but it had finished this morning, so perhaps it's not a complete deadlock. Has anyone else seen this? Thomas
Re: Automated report: NetBSD-current/i386 build failure
On Tue, Mar 03, 2020 at 01:29:39PM +0200, Andreas Gustafsson wrote: > Would it be too much to ask that imports of entire new subsystems like > this be at least build tested with "build.sh release"? The lossage in this case seems to depend on -j values and whether you do incremental builds, so not clearly detectable by a simple local build (I was able to build sparc64 and evbarm earlier today localy, while the build cluster still fails all the builds) Martin
Re: Automated report: NetBSD-current/i386 build failure
NetBSD Test Fixture wrote: > *** [cleandir-pamu2fcfg] Error code 2 > nbmake[7]: stopped in > /tmp/bracket/build/2020.03.03.00.47.33-i386/src/external/bsd/pam-u2f/bin The build is still broken as of source date 2020.03.03.08.56.05: http://releng.netbsd.org/b5reports/i386/commits-2020.03.html#2020.03.03.08.56.05 Would it be too much to ask that imports of entire new subsystems like this be at least build tested with "build.sh release"? -- Andreas Gustafsson, g...@gson.org
benchmark results on ryzen 3950x with netbsd-9, -current, and -current (no DIAGNOSTIC)
hi folks. here are a few build benchmark tests on an amd ryzen 3950x system, to see the cumulative effect of the various fixes we've seen since netbsd-9, for this 16 core/ 32 thread CPU, 64GB of ram, separate nvme ssd for src & obj. below has a full summary, but the highlights: - building kernels into tmpfs is 10-12% faster - DIAGNOSTIC costs 3-8% - current's better CPU thread aware scheduler helps -j16 on 32 CPUs significantly (more than double benefit compared to the other tests.) - "build.sh release" is about 10% faster - kernel builds are similar about 10% faster - builds of ircII are 22% faster, though configure only 11% - -j32 is faster than -j16 or -j24 - -j40 is not much worse than -j32, occasinally faster and the one lowlight: - "du -mcs *" on a src tree already in ram has lost about 30% performance, though still under 1 second. .mrg. time to 'grep -r . . > /dev/null' and 'du -mcs *' in /usr/src: 1st run2nd rundu -mcs * run netbsd-9 1m00.580m23.730m0.57 current (DIAG) 0m59.230m17.960m0.78 current0m57.530m17.000m0.80 time for vax release builds on cache-filled tree from above: -j16 -j24 -j32 -j40 netbsd-9 17m24 15m30 14m48 15m19 current (DIAG) 15m43 14m31 14m23 14m30 current14m30 13m19 13m12 13m11 time for vax GENERIC kernel builds: -j16 -j24 -j32 -j40 netbsd-9 0m28.090m22.590m20.220m20.17 current (DIAG) 0m22.950m20.200m19.290m19.20 current0m21.620m18.620m17.440m17.36 time for amd64 release builds with x11 on cache-filled tree like above: -j16 -j24 -j32 -j40 netbsd-9 1h15:141h04:321h00:381h01:24 current (DIAG) 1h05:240h59:400h57:500h58:07 current1h02:170h56:050h54:100h55:23 time for amd64 GENERIC kernel builds: -j16 -j24 -j32 -j40 netbsd-9 2m26.561m55:301m43:461m43:82 current (DIAG) 2m01.251m46.841m40.221m41.12 current1m54.561m39.571m33.091m34.06 time for amd64 GENERIC kernel builds into tmpfs build dir: -j16 -j24 -j32 -j40 netbsd-9 2m09.221m38.021m25.391m25.09 current (DIAG) 1m38.591m23.651m16:251m16.02 current1m35.961m21.691m14:171m13.96 time to configure & build ircii configure -j16 -j24 -j32 -j40 netbsd-90m1.77 0m1.14 0m1.13 0m1.11 0m1.14 current (DIAG) 0m1.80 0m1.02 0m0.94 0m0.94 0m0.92 current 0m1.58 0m0.97 0m0.92 0m0.87 0m0.84
USB keyboard input overrun on EHCI?
This is a problem that I believe has been present for a while, but has recently (since the new year) become worse: I have, for a long time, been using a bar code scanner to register books on LibraryThing, and I've been noticing that my amd64 home workstation has had a tendency to drop a digit from the injected ISBN from time to time - I guess it's typically lost one digit from a 10 digit ISBN on something like every third scan. To check the scanner, I tried it on a Dell laptop, and, more recently, on a Pinebook, and it shows no problems on either. Recently, I bought an Ergodox-EZ keyboard. The BIOS in the keyboard is able to generate Unicode characters using the standard input method that is implemented in e.g. GTK 2. This transmits Ctrl-Shift-U, followed by the hex digits of the Unicode code point, and then a space character. Running a kernel from (IIRC) January 2nd, this mostly worked fine. Then I updated to one from February 21st, and now my workstation only manages to receive a Unicode character once every dozen tries or thereabout. So, the problem that was already present got a lot worse - and on the Dell laptop, and on the Pinebook, running kernels built from the same sources, everything is still fine. The difference between the systems (apart from two of them being amd64, and one aarch64) is that the Pinebook has OHCI, the Dell UHCI, and the (failing) workstation EHCI hardware. The transmit speed of the keyboard is low. I haven't measured it, but it looks to be in the 50cps range, meaning 20ms between characters. (Estimated by watching the keyboard transmit a longer string.) I'd appreciate hints as to where I should be looking for this problem. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay
