https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #35 from Hans Petter Selasky ---
Hi,
Each USB device instance has a global SX lock. This lock is held during detach.
usbconfig also acquire this lock. If the USB detach cannot complete, because
character devices towards user-sp
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #34 from Matthias Apitz ---
(In reply to Hans Petter Selasky from comment #31)
Hans, what I do not understand is the problem with 'usbconfig' which, as you
say maybe caused by any other proc blocking something, and the fact that
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #33 from Hans Petter Selasky ---
The delay of usbconfig usually means that the enumeration lock is blocked.
a) when a device driver in userspace is not closing its handle
b) when there are too many explore events from the USB H
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #32 from Matthias Apitz ---
(In reply to Hans Petter Selasky from comment #31)
(In reply to Hans Petter Selasky from comment #31)
I will do so. But doesn't this (delay of usbconfig) is some other other
problem, maybe related to,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #31 from Hans Petter Selasky ---
This sounds like a bug in a user-space daemon which doesn't close its USB
handles to the kernel. Can you also run "procstat -ak" when usbconfig doesn't
print the device lines instantly.
--
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #30 from Matthias Apitz ---
here is the 'usbconfig' output, when the card is not seen; it takes around 10
minutes to print the lines:
# usbconfig
ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps)
pwr=SAVE (0mA)
ugen0.1: <0x
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #29 from Matthias Apitz ---
(In reply to Hans Petter Selasky from comment #28)
when the card *is* connected and seen it says:
# usbconfig list
ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps)
pwr=SA
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #28 from Hans Petter Selasky ---
What does "usbconfig" say when the card is not connected?
--HPS
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #27 from Matthias Apitz ---
part of the problem (if not at all its base) seems to be that sometimes on boot
(i.e. if the card is already connect before boot) or later the card plug-in is
not seen; I have here the example of two
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #26 from Hans Petter Selasky ---
Try to figure out which one of them is the culpit :-)
--HPS
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-us
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #25 from Matthias Apitz ---
with only set
dev.uhub.1.disable_enumeration=1
in loader.conf the 'usbdump' are not working, but the pcscd is now booting
fast and fine; here is its log with time stamped each line; it does see the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #24 from Matthias Apitz ---
(In reply to Hans Petter Selasky from comment #23)
I disabled all of them:
# grep enumer /boot/loader.conf
dev.uhub.0.disable_enumeration=1
dev.uhub.1.disable_enumeration=1
dev.uhub.2.disable_enumer
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #23 from Hans Petter Selasky ---
Try to disable one of the other hubs in turn.
--HPS
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-usb@freebs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #22 from Matthias Apitz ---
(In reply to Hans Petter Selasky from comment #21)
I did so but this does not give any visible change in the problem:
root@c720-r314251:/home/guru # sysctl -a | grep enumeration
hw.usb.disable_enume
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #21 from Hans Petter Selasky ---
Try to put:
dev.uhub.2.disable_enumeration=1
In /boot/loader.conf or something like that and reboot.
--HPS
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #20 from Matthias Apitz ---
(In reply to Hans Petter Selasky from comment #19)
this hangs too :-(
--
You are receiving this mail because:
You are the assignee for the bug.
___
freeb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #19 from Hans Petter Selasky ---
Also the output "vmstat -i" might be interesting.
You can try to disable ugen1.1 like this:
usbconfig -d 1.1 set_config 255
And see if it helps.
--HPS
--
You are receiving this mail because
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #18 from Matthias Apitz ---
(In reply to Hans Petter Selasky from comment #17)
$ dmesg | grep ugen
ugen0.1: <0x8086 XHCI root HUB> at usbus0
ugen1.1: at usbus1
ugen0.2: at usbus0
ugen1.2: at usbus1
ugen0.3: at usbus0
I wil
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #17 from Hans Petter Selasky ---
Which USB device is ugen1.2 ? It is the one causing the TIMEOUT issue according
to the usbdump log you sent.
--HPS
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #16 from Matthias Apitz ---
(In reply to Hans Petter Selasky from comment #15)
procstat -ak | grep usb
only show system processes:
root@c720-r314251:/home/guru # procstat -ak | grep usb > /tmp/usb
root@c720-r314251:/home/guru
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #15 from Hans Petter Selasky ---
Hi,
See "procstat -ak" and which thread is blocked inside USB.
When you have a non-behaving USB device which times out and never closes its
USB handle from userspace, that will block the enumer
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #14 from Matthias Apitz ---
(In reply to Matthias Apitz from comment #13)
are you sure? why all the usbconfig commands are hanging? there is no pcscd
software involved...
--
You are receiving this mail because:
You are the as
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #13 from Matthias Apitz ---
(In reply to Hans Petter Selasky from comment #11)
appart of the test with the mouse (which now is not connected) I can not unplu
any device; they are built-in in the Acer C720 netbook;
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #12 from Hans Petter Selasky ---
Add -vvv to usbdump and send the output with USB_ERR_TIMEOUT to the PCSC USB
driver developers. They might know why the device is hanging on the commands
they are sending.
This does not look lik
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #11 from Hans Petter Selasky ---
Did you replug the USB device after adding the quirk?
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-usb@freeb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #10 from Matthias Apitz ---
they hang all:
root@c720-r314251:~ # ls -l /dev/ug*
lrwxr-xr-x 1 root wheel 9 11 may. 06:57 /dev/ugen0.1 -> usb/0.1.0
lrwxr-xr-x 1 root wheel 9 11 may. 06:57 /dev/ugen0.2 -> usb/0.2.0
lrwxr-
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #9 from Matthias Apitz ---
$ dmesg | grep usb
usbus0 on xhci0
usbus0: 5.0Gbps Super Speed USB v3.0
usbus1: EHCI version 1.0
usbus1 on ehci0
usbus1: 480Mbps High Speed USB v2.0
ugen1.1: at usbus1
ugen0.1: <0x8086 XHCI root HUB>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #8 from Hans Petter Selasky ---
The USB log shows that the device has a timeout on one of the USB commands.
That's the reason it is slow!
Wild guess: Try to set: UQ_NO_STRINGS using:
usbconfig -d X.Y add_quirk UQ_NO_STRINGS
-
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #7 from Matthias Apitz ---
root@c720-r314251:~ # usbdump -i usbus1
14:13:00.912954 usbus1.2
DONE-CTRL-EP=0080,SPD=HIGH,NFR=0,SLEN=0,IVAL=0,ERR=TIMEOUT
14:13:00.979775 usbus1.2 SUBM-CTRL-EP=0080,SPD=HIGH,NFR=2,SLEN=8,IVA
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #6 from Hans Petter Selasky ---
Are there any USB-errors in dmesg?
If you run "usbdump -i usbusX" on the bus where the device is connected, do you
see any timeouts?
--HPS
--
You are receiving this mail because:
You are the a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #5 from Matthias Apitz ---
dmesg shows only attach and deattach of the mouse (which I inserted just to see
if this would kick the pcscd proc forward):
ugen0.4: at usbus0
ums0 on uhub1
ums0: on usbus0
ums0: 3 buttons and [XYZ]
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #4 from Matthias Apitz ---
Created attachment 182510
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=182510&action=edit
output of: procstat -ak
CPU is nearly idle (~95%) and no other proc is using USB
--
You are rec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #3 from Hans Petter Selasky ---
Also check if any processes are consuming 100% CPU.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-usb@freebsd.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
Hans Petter Selasky changed:
What|Removed |Added
CC||hsela...@freebsd.org
--- Com
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
--- Comment #1 from Matthias Apitz ---
Created attachment 182509
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=182509&action=edit
output of kdump -T
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219220
Bug ID: 219220
Summary: syscalls (ioctls) on USB devices are very slow
Product: Base System
Version: CURRENT
Hardware: amd64
OS: Any
Status: New
Sev
36 matches
Mail list logo
