Re: [patch] fix uplcom(4) clear stall logic for PL2303HX
On Tue, Nov 20, 2012 at 08:15:19AM +0100, Hans Petter Selasky wrote:
On Tuesday 20 November 2012 03:57:22 Mark Johnston wrote:
1. What exactly is the purpose of clearing ENDPOINT_HALT when a
userspace program attaches to a device? Is it just to make sure that the
device fw is in some known good state before starting to transmit data?
The purpose is to ensure that the so-called data toggle is reset to zero. If
a
packet is sent using the wrong data-toggle, it will simply get dropped. This
is not so important for Serial devices, but for other device classes it is.
If a USB device does not support clear-stall, it is not complying with the
basics of the USB standards defined at usb.org, and I think it is not USB
certified either.
That seems to be the case unfortunately, i.e. the device is responding
with USB_ERROR_STALLED when it receives a clear stall request over the
intr or bulk transfers.
2. uplcom(4) tries to clear any stalls after an error in its r/w and
intr callbacks. Is there some way I can trigger an error so that I can
test and fix that code too?
Does the device choke on clear-stall?
You can test that simply by adding a sysctl to the code, which you set to
make
the code go to the error case upon transfer completion.
I suggest you look at storage/umass.c and the reset states for an example on
how to make a non-default asynchronous control transfer.
When you have a patch I can commit it.
It doesn't seem like the vendor-specific commands help at all in
clearing errors. I spent some time playing around with the patch at [1],
which adds some reset callbacks that submit the vendor commands, but I
couldn't get the device to recover - I just get more STALLED errors back.
Looking at the Linux driver (pl2303) doesn't reveal anything helpful - I
don't really see any kind of error-handling code.
At any rate, my original patch below fixes my problems. I don't like the
fact that the error handling is broken, but at least everything (seems)
to clean itself up nicely in the error case - the driver just
disconnects and reattaches.
Thanks,
-Mark
[1] https://www.student.cs.uwaterloo.ca/~m6johnst/patch/uplcom_reset_logic.patch
diff --git a/sys/dev/usb/serial/uplcom.c b/sys/dev/usb/serial/uplcom.c
index 4549bad..4998c3f 100644
--- a/sys/dev/usb/serial/uplcom.c
+++ b/sys/dev/usb/serial/uplcom.c
@@ -433,10 +433,19 @@ uplcom_attach(device_t dev)
goto detach;
}
/* clear stall at first run */
- mtx_lock(sc-sc_mtx);
- usbd_xfer_set_stall(sc-sc_xfer[UPLCOM_BULK_DT_WR]);
- usbd_xfer_set_stall(sc-sc_xfer[UPLCOM_BULK_DT_RD]);
- mtx_unlock(sc-sc_mtx);
+ if (sc-sc_chiptype != TYPE_PL2303HX) {
+ /* HX variants seem to lock up after a clear stall request. */
+ mtx_lock(sc-sc_mtx);
+ usbd_xfer_set_stall(sc-sc_xfer[UPLCOM_BULK_DT_WR]);
+ usbd_xfer_set_stall(sc-sc_xfer[UPLCOM_BULK_DT_RD]);
+ mtx_unlock(sc-sc_mtx);
+ } else {
+ if (uplcom_pl2303_do(sc-sc_udev, UT_WRITE_VENDOR_DEVICE,
+ UPLCOM_SET_REQUEST, 8, 0, 0) ||
+ uplcom_pl2303_do(sc-sc_udev, UT_WRITE_VENDOR_DEVICE,
+ UPLCOM_SET_REQUEST, 9, 0, 0))
+ goto detach;
+ }
error = ucom_attach(sc-sc_super_ucom, sc-sc_ucom, 1, sc,
uplcom_callback, sc-sc_mtx);
@@ -555,9 +564,6 @@ uplcom_pl2303_init(struct usb_device *udev, uint8_t
chiptype)
if (err)
return (EIO);
- if (uplcom_pl2303_do(udev, UT_WRITE_VENDOR_DEVICE, UPLCOM_SET_REQUEST,
8, 0, 0)
- || uplcom_pl2303_do(udev, UT_WRITE_VENDOR_DEVICE,
UPLCOM_SET_REQUEST, 9, 0, 0))
- return (EIO);
return (0);
}
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [patch] fix uplcom(4) clear stall logic for PL2303HX
On Wednesday 21 November 2012 09:43:02 Mark Johnston wrote: Mark Johnston Here you go: http://svnweb.freebsd.org/changeset/base/243380 Please test and verify. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [patch] fix uplcom(4) clear stall logic for PL2303HX
On Wed, Nov 21, 2012 at 11:07:20PM +0100, Hans Petter Selasky wrote:
Here you go:
http://svnweb.freebsd.org/changeset/base/243380
Please test and verify.
--HPS
Yep, it's working. Thanks a lot!
When I was debugging the problem I noticed the UQ_OPEN_CLEARSTALL quirk,
and then later discovered that it no longer has any effect. Is there any
reason for keeping it around? Or can it be removed (patch below)?
Thanks,
-Mark
diff --git a/share/man/man4/usb_quirk.4 b/share/man/man4/usb_quirk.4
index 65deafa..f017e01 100644
--- a/share/man/man4/usb_quirk.4
+++ b/share/man/man4/usb_quirk.4
@@ -76,8 +76,6 @@ mouse sends an unknown leading byte
mouse has Z-axis reversed
.It UQ_NO_STRINGS
string descriptors are broken
-.It UQ_OPEN_CLEARSTALL
-device needs clear endpoint stall
.It UQ_POWER_CLAIM
hub lies about power status
.It UQ_SPUR_BUT_UP
diff --git a/sys/dev/usb/quirk/usb_quirk.c b/sys/dev/usb/quirk/usb_quirk.c
index fe15a0a..8f35584 100644
--- a/sys/dev/usb/quirk/usb_quirk.c
+++ b/sys/dev/usb/quirk/usb_quirk.c
@@ -508,7 +508,6 @@ static const char *usb_quirk_str[USB_QUIRK_MAX] = {
[UQ_MS_LEADING_BYTE]= UQ_MS_LEADING_BYTE,
[UQ_MS_REVZ]= UQ_MS_REVZ,
[UQ_NO_STRINGS] = UQ_NO_STRINGS,
- [UQ_OPEN_CLEARSTALL]= UQ_OPEN_CLEARSTALL,
[UQ_POWER_CLAIM]= UQ_POWER_CLAIM,
[UQ_SPUR_BUT_UP]= UQ_SPUR_BUT_UP,
[UQ_SWAP_UNICODE] = UQ_SWAP_UNICODE,
diff --git a/sys/dev/usb/quirk/usb_quirk.h b/sys/dev/usb/quirk/usb_quirk.h
index 32a60a1..15d5f15 100644
--- a/sys/dev/usb/quirk/usb_quirk.h
+++ b/sys/dev/usb/quirk/usb_quirk.h
@@ -54,7 +54,6 @@ enum {
UQ_MS_LEADING_BYTE, /* mouse sends an unknown leading byte */
UQ_MS_REVZ, /* mouse has Z-axis reversed */
UQ_NO_STRINGS, /* string descriptors are broken */
- UQ_OPEN_CLEARSTALL, /* device needs clear endpoint stall */
UQ_POWER_CLAIM, /* hub lies about power status */
UQ_SPUR_BUT_UP, /* spurious mouse button up events */
UQ_SWAP_UNICODE,/* has some Unicode strings swapped */
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/172199: high interrupts load xhci
The following reply was made to PR usb/172199; it has been noted by GNATS. From: Victor van Vlaardingen v...@lfs.net To: bug-follo...@freebsd.org, reytsman@solvex.travel Cc: Subject: Re: usb/172199: high interrupts load xhci Date: Thu, 22 Nov 2012 08:09:03 +0100 This is a multi-part message in MIME format. --=_NextPart_000_0224_01CDC888.A290ABB0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Can you collect some dmesg? sysctl hw.usb.xhci.debug=3D16 ; sleep 1; sysctl hw.usb.xhci.debug=3D0 --HPS Hi, I have the same symptom, but with plugging and unplugging a monitor and = also just toggling the monitor's power. With the high interrupt happening I did your dmesg test. I got a whole = bunch of : xhci_interrupt: real interrupt (sts=3D0x, iman=3D0x0002) I have seen this on a : Gigabyte GA-Z77-DS3H (with Core i3-2120T) Intel DH77KC (same Core i3-2120T) I'm using the intergrated graphics on the cpu. It doesn't matter whether the DSUB (only on the GA) or DVI port is used. Currently I'm on the Intel board and its interrupt usage reported by = systat -vmstat is : Interrupts 159k total atkbd0 1 158k xhci0 ehci 4 em1 17 56 ath0 19 2 ehci1 23 1127 cpu0:timer 2 em0 256 35 ahci0 257 16 cpu1:timer 10 cpu3:timer 22 cpu2:timer Some more info about the system follows : [root@bsd /]# uptime 6:57AM up 11:28, 1 user, load averages: 0.51, 0.38, 0.23 [root@bsd /]# uname -a FreeBSD bsd.hostname.here 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue = Jun 12 02:52:29 UTC 2012 = r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 Note that I saw the same thing when I tried 9.1RC3 amd64 [root@bsd /]# dmesg Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights = reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 02:52:29 UTC 2012 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC = amd64 CPU: Intel(R) Core(TM) i3-2120T CPU @ 2.60GHz (2594.16-MHz K8-class CPU) Origin =3D GenuineIntel Id =3D 0x206a7 Family =3D 6 Model =3D 2a = Stepping =3D 7 = Features=3D0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PG= E,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE = Features2=3D0x159ae3bfSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3= ,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,TSCDLT,XSAVE,AVX AMD Features=3D0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=3D0x1LAHF TSC: P-state invariant, performance statistics real memory =3D 17179869184 (16384 MB) avail memory =3D 16423026688 (15662 MB) Event timer LAPIC quality 600 ACPI APIC Table: INTEL DH77KC FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ACPI Warning: FADT (revision 5) is longer than ACPI 2.0 version, = truncating length 268 to 244 (20110527/tbfadt-320) ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: INTEL DH77KC on motherboard acpi0: Power Button (fixed) acpi0: reservation of 67, 1 (4) failed Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0xf000-0xf03f mem = 0xf780-0xf7bf,0xe000-0xefff irq 16 at device 2.0 on pci0 xhci0: XHCI (generic) USB 3.0 controller mem 0xf7d2-0xf7d2 irq = 16 at device 20.0 on pci0 xhci0: 32 byte context size. usbus0 on xhci0 pci0: simple comms at device 22.0 (no driver attached) em0: Intel(R) PRO/1000 Network Connection 7.2.3 port 0xf080-0xf09f mem = 0xf7d0-0xf7d1,0xf7d35000-0xf7d35fff irq 20 at device 25.0 on = pci0 em0: Using an MSI interrupt em0: Ethernet address: e8:40:f2:ab:e1:13 ehci0: EHCI (generic) USB 2.0 controller mem 0xf7d34000-0xf7d343ff irq = 16 at device 26.0 on pci0 usbus1: EHCI version 1.0 usbus1: EHCI (generic) USB 2.0 controller on ehci0 pcib1: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge irq 19 at device 28.7 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge irq 19 at device 0.0 on pci2 pci3: ACPI PCI bus on pcib3 ath0: Atheros 5212 mem 0xf7c6-0xf7c6 irq 19 at device 0.0 on = pci3 ath0: AR2413 mac 7.9 RF2413 phy 4.5 em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.3 port = 0xe000-0xe03f mem 0xf7c4-0xf7c5,0xf7c2-0xf7c3 irq 17 at = device 2.0 on pci3 em1: Ethernet
