El día jueves, enero 03, 2019 a las 09:31:53a. m. +0100, Hans Petter Selasky escribió:
> On 1/3/19 7:04 AM, Matthias Apitz wrote:
> > I think, we should isolate the problem from PCSC and focus (first) on the
> > question why are calls to usbconfig(8) are not answered anymore
> > *without* any kind of PCSC software being involved as I wrote in the
> > originating email of this thread. Here it is again in case in got lost
> > while talking about PCSC:
>
> Hi,
>
> Usually this happens if a user-space component is not closing its device
> handle while enumeration happens. Can you run pcsd in the foreground
> with debugging enabled and show what it prints while you plug unplug the
> device.
>
> Also try setting the hw.usb.uhub.debug=16 sysctl and collect messages in
> dmesg.
Hi,
I wasn't lazy and did several tests as root:
1. booting to single user mode with the token attached:
running usbconfig(8) works fine and fast; tested multiple times the
cmd, no delays;
2. booting to multiuser, login as root, no KDE started, just first login
as root in multiuser; devd(8) hook was moved away before booting;
running 'truss -o usbconfig.tr -d usbconfig list' gives the attached
output; long delays on open of the ugen0.X files:
3. re-boot again to multiuser, login as root, no KDE starting as root;
again without the devd(8) hook for the card:
running as root:
/usr/local/sbin/pcscd --debug --foreground > pcscd.stdout
gives:
00000000 pcscdaemon.c:347:main() pcscd set to foreground with debug send to
stdout
00000554 configfile.l:361:DBGetReaderList() Parsing conf file:
/usr/local/etc/reader.conf.d
00000062 pcscdaemon.c:662:main() pcsc-lite 1.8.23 daemon ready.
no reaction on plug-in or card detach; then I killed it with Ctrl-C
77360913 pcscdaemon.c:193:signal_thread() Received signal: 2
00000063 pcscdaemon.c:226:signal_thread() Preparing for suicide
02189136 pcscdaemon.c:193:signal_thread() Received signal: 2
00639842 pcscdaemon.c:193:signal_thread() Received signal: 2
00000055 pcscdaemon.c:247:signal_thread() Forced suicide
00000020 pcscdaemon.c:785:at_exit() cleaning /var/run/pcscd
4. with devd(8) hook active, booted into multiuser the pcscd started by
devd(8) works fine until detaching the card (which let devd(8) kill
the running pcscd; a new started pcscd will not work anymore;
This means: something during boot damages the USB stack; this must be
something after devd(8) bring up pcscd (because this is still fine
working).
Is there a way log log any init call to libusb.so to see which process
is doing something with libusb.so after devd(8) started pcscd?
An option to test is deleting the devd(8) hooks for DETACH and
let pcscd just continue and see if ATTACH of the card works ...
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars,
Druschba
instead of Nazis, to live instead of to survive.
signature.asc
Description: PGP signature
