From owner-freebsd-usb@freebsd.org Tue May 17 17:04:10 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DC1EB3F2B2 for ; Tue, 17 May 2016 17:04:10 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B8E01FE1 for ; Tue, 17 May 2016 17:04:09 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 61357118A71 for ; Tue, 17 May 2016 11:54:02 -0500 (CDT) To: freebsd-usb@freebsd.org From: Karl Denninger Subject: Oddity with ugen Message-ID: Date: Tue, 17 May 2016 11:53:54 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms030000040809030000090108" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 17:04:10 -0000 This is a cryptographically signed message in MIME format. --------------ms030000040809030000090108 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Consider the following snippet of code.... sprintf(tmp, "/dev/usb/0.%d.1", x); /* Get input handle *= / _i =3D open(tmp, O_RDONLY|O_NDELAY); /* Open it */ if (_i < 0) { syslog(LOG_WARNING, "Error opening USB input channel (%d)", errno); } else { y =3D 8; /* Set buffer size */ if (ioctl(_i, USB_SET_RX_BUFFER_SIZE, &y) < 0) { syslog(LOG_WARNING, "Error setting USB buffer"); } y =3D 0; /* Set timeout */ if (ioctl(_i, USB_SET_RX_TIMEOUT, &y) < 0) { syslog(LOG_WARNING, "Error setting USB timeout to zero") ; } y =3D 1; /* Set short xfer ok */ if (ioctl(_i, USB_SET_RX_SHORT_XFER, &y) < 0) { syslog(LOG_WARNING, "Error setting USB short XFER= "); } } sprintf(tmp, "/dev/usb/0.%d.2", x); /* Get output handle = */ _o =3D open(tmp, O_WRONLY); /* Open it */ if (_o < 0) { syslog(LOG_WARNING, "Error opening USB output channel (%d)", errno); } else { y =3D 8; /* Set buffer size; low-speed device */ if (ioctl(_o, USB_SET_TX_BUFFER_SIZE, &y) < 0) { syslog(LOG_WARNING, "Error setting USB TX buffer"= ); } y =3D 0; /* Set timeout */ if (ioctl(_o, USB_SET_TX_TIMEOUT, &y) < 0) { syslog(LOG_WARNING, "Error setting USB TX timeout= "); } } =20 Ok, we now have two open handles (we have previously ascertained that the correct device is at the instance in question ("x") by checking its vendor number, and we know it has two endpoints, one for input and one for output. We also know it is a low-speed device and thus theoretically is limited to 8-character buffering. So we start reading and writing and it mostly works. select() works on the filehandles to know if we can read or write as expected, etc. The format from the device is in the general form of a preamble byte that is a flag, a length byte (for most of the preambles) and then up to six bytes of data. I read the data into a buffer (so if I get more than one packet, or a packet and a part of a second one I'm ok) and then whenever a read succeeds I parse through the buffer and empty it of anything that's complete. This is working reasonable well...... except for one problem. Sometimes, without warning, select() will return a ready on the input file handle and when you read you get the *last* packet of data you read back. You read it, you select() again, you get the same packet of data again and again. This can and does go on for a *long* time (sometimes minutes!) but it does eventually clear on its own. I *suspect* the device itself is not actually re-sending the data, but it might be -- I have no good way to be sure that I'm aware of. In other words I get something like this: select() returns ready on _i bytes =3D read(_i, buffer, 8); Buffer contains 4 bytes (and bytes =3D 4): 0x50, 0x02, 0x01, 0x04 select() once again returns ready on _i immediately (no delay) bytes =3D read(_i, buffer, 8); Buffer contains the same four bytes and bytes =3D 4 again, as if the read() did not empty the buffer but read it and left the buffer contents *and count* alone. If this is a condition of some sort in the device or driver I've not been able to figure out what it is, or how to force it to clear -- or to prove whether it's in the device or the ugen driver. Any ideas? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms030000040809030000090108 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTcxNjUzNTRaME8GCSqGSIb3DQEJBDFCBECN R6dsTZSKS66CWQ4IbKn2N9AtqE67LmRmHUiSvObyHkgm4aOEotQe4H+by/q/Y3rtYWGVnb0m 0Rzsr7XUSG8BMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAadDffa1t KU71w2SVX4BbkUtZvqOMRK4dH1hzNHqQPXw/BLuR/HteRTEeTa5PclyzA5++GRMC7pQqWMP0 KLRMyjz3JS//XOHaKJ2FsBvzXF7l/aXNTVr9jlK7BOBTAWxMH6VQjzMvzrPhHu6mj5BXhxLS iOy+Q0I40mIO0c6HLFQu6YgBftZCyx4qvYVtqliBJl7T7fEA34hwamcUL1mZVdvW8bxoxUgs rUu9K4OFxA1Uq1OqNon9o96eM/4Gap8quppzR5MMpItKKXB2iO9FT/SvK3exLykJAW0IflPN FIyzsPlgfcDK6lvEF62CEzXPXgoXgEotJmmmbAQJMJ5BaNii69dD4Gm4bSR3FZRE+fHTxpfY /SnvkP998DNGXa8WQY0gXVX0lt5M9e2Zi0DfVDE5t6czrQvMr+n1EqKEuygWiIep8SK4LjA5 s2sDmIsvMoZdXx5wUNLQcp8rVRXJ/Cu71fgKRaV9xis2PMujkPLGiklHvsNSkFOXR3OJsw8W qS0Z2OJkigKfGH799nY08kDt5v3i9xz9bzvA4RcDR2oQxtTfSL8h/1HiASqLu/NKOrap+ay6 akurhZzvPB70sig3XsD+5Pt5NjHvG/tGB2WBkL8A2BvpKkN+QT8GtuC0lAOWiWgZyZxG3gWC V7i8rxuycRnUcW51zWDA6UKt3BkAAAAAAAA= --------------ms030000040809030000090108-- From owner-freebsd-usb@freebsd.org Tue May 17 18:53:19 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E89DAB3F759 for ; Tue, 17 May 2016 18:53:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BFEB818EF for ; Tue, 17 May 2016 18:53:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u4HIrJnP072888 for ; Tue, 17 May 2016 18:53:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-usb@FreeBSD.org Subject: [Bug 209586] Ozone Strike Pro Keyboard bugged Date: Tue, 17 May 2016 18:53:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: usb X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jakob@gillich.me X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-usb@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 18:53:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209586 Bug ID: 209586 Summary: Ozone Strike Pro Keyboard bugged Product: Base System Version: 11.0-CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: usb Assignee: freebsd-usb@FreeBSD.org Reporter: jakob@gillich.me CC: freebsd-amd64@FreeBSD.org CC: freebsd-amd64@FreeBSD.org I have a "Ozone Strike Pro" USB keyboard that is pretty bugged on FreeBSD -CURRENT r299864 (yesterday's head) and 20160429-r298793 (the latest snapsh= ot). Relevant dmesg output: ugen1.3: at usbus1 uhub5: on usbus1 uhub5: 4 ports with 4 removable, self powered ugen1.4: at usbus1 ukbd1: on us= bus1 kbd3 at ukbd1 ukbd2: on us= bus1 kbd4 at ukbd2 uhid0: on us= bus1 Note that plugging in the keyboard create *two* ukbd devices. When keys on = the keyboard are pressed, various bugs happen: * The "space" key enters an "a" character * The "d" key switches the active tty * All other keys misbehave as well Additionally, only sometimes, the internal keyboard of the notebook also st= arts entering the wrong things when the Ozone is plugged in. There is a workaround that fixes the issue when the following steps are executed in this exact order: 1. Plug in the keyboard 2. Run "usbconfig -d ugen1.4 add_quirk UQ_KBD_BOOTPROTO" on *both* devices 3. Plug out the keyboard 4. Plug it in again After going through this procedure once, the correct behavior persists, even through a standby cycle, but it does not persist through reboots. The keyboard works completely fine on Linux and OpenBSD. It does not work on another machine running FreeBSD -CURRENT. I did not test it on any -RELEASE. I am not sure what else would help to track this down, please let me know i= f I can provide anything else. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-usb@freebsd.org Wed May 18 07:48:15 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A3DCB400BC for ; Wed, 18 May 2016 07:48:15 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 16F801CFF for ; Wed, 18 May 2016 07:48:15 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 5EA471FE024; Wed, 18 May 2016 09:48:13 +0200 (CEST) Subject: Re: Oddity with ugen To: Karl Denninger , freebsd-usb@freebsd.org References: From: Hans Petter Selasky Message-ID: <46bd6efe-5335-f659-0b07-5107b0e9a326@selasky.org> Date: Wed, 18 May 2016 09:51:34 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 07:48:15 -0000 On 05/17/16 18:53, Karl Denninger wrote: > If this is a condition of some sort in the device or driver I've not > been able to figure out what it is, or how to force it to clear -- or to > prove whether it's in the device or the ugen driver. > > Any ideas? Hi, The most easy way to know this for sure, is to check the real data traffic using usbdump: usbdump -i usbusX -f Y -s 65536 -vvv My guess is there is some data toggle issue, and that the USB stack tries to clear some error using a clear-stall command, which possibly your device does not handle properly. --HPS From owner-freebsd-usb@freebsd.org Wed May 18 15:32:31 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D359B41D13 for ; Wed, 18 May 2016 15:32:31 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CFBCA139B for ; Wed, 18 May 2016 15:32:30 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id B74681182DE for ; Wed, 18 May 2016 10:32:26 -0500 (CDT) Subject: Re: Oddity with ugen To: freebsd-usb@freebsd.org References: <46bd6efe-5335-f659-0b07-5107b0e9a326@selasky.org> From: Karl Denninger Message-ID: Date: Wed, 18 May 2016 10:32:17 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <46bd6efe-5335-f659-0b07-5107b0e9a326@selasky.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms040907010105080409020709" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 15:32:31 -0000 This is a cryptographically signed message in MIME format. --------------ms040907010105080409020709 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/18/2016 02:51, Hans Petter Selasky wrote: > On 05/17/16 18:53, Karl Denninger wrote: >> If this is a condition of some sort in the device or driver I've not >> been able to figure out what it is, or how to force it to clear -- or = to >> prove whether it's in the device or the ugen driver. >> >> Any ideas? > > Hi, > > The most easy way to know this for sure, is to check the real data > traffic using usbdump: > > usbdump -i usbusX -f Y -s 65536 -vvv > > My guess is there is some data toggle issue, and that the USB stack > tries to clear some error using a clear-stall command, which possibly > your device does not handle properly. > > --HPS Well that doesn't help me... from what I can determine the device thinks its sending it, well, at least usbdump thinks the device is sending it. (bunch of ordinary stuff elided) 10:20:15.826093 usbus0.5 SUBM-INTR-EP=3D00000002,SPD=3DLOW,NFR=3D1,SLEN=3D= 4,IVAL=3D10 frame[0] WRITE 2 bytes 0000 06 43 -- -- -- -- -- -- -- -- -- -- -- -- -- -- |.C = | flags 0x11 status 0xc0023 10:20:15.833049 usbus0.5 DONE-INTR-EP=3D00000002,SPD=3DLOW,NFR=3D1,SLEN=3D0,IVAL=3D10,ERR=3D0 frame[0] WRITE 2 bytes flags 0x11 status 0xc0021 10:20:17.183085 usbus0.5 DONE-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D4,IVAL=3D0,ERR=3D0 frame[0] READ 1 bytes 0000 55 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- |U = | flags 0x12 status 0xc1021 10:20:17.183127 usbus0.5 SUBM-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D= 0,IVAL=3D0 frame[0] READ 8 bytes flags 0x12 status 0xc1023 Up to here all is ok. 10:20:17.342824 usbus0.5 SUBM-INTR-EP=3D00000002,SPD=3DLOW,NFR=3D1,SLEN=3D= 4,IVAL=3D10 frame[0] WRITE 2 bytes 0000 04 4A -- -- -- -- -- -- -- -- -- -- -- -- -- -- |.J = | flags 0x11 status 0xc0023 10:20:17.353046 usbus0.5 DONE-INTR-EP=3D00000002,SPD=3DLOW,NFR=3D1,SLEN=3D0,IVAL=3D10,ERR=3D0 frame[0] WRITE 2 bytes flags 0x11 status 0xc0021 10:20:20.183068 usbus0.5 DONE-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D4,IVAL=3D0,ERR=3D0 frame[0] READ 4 bytes 0000 5A 02 00 4A -- -- -- -- -- -- -- -- -- -- -- -- |Z..J = | flags 0x12 status 0xc1021 10:20:20.183113 usbus0.5 SUBM-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D= 0,IVAL=3D0 frame[0] READ 8 bytes flags 0x12 status 0xc1023 This is ok; we got the "echo" back (which we usually don't, but we did, and it's all right that we did.) 10:20:20.367909 usbus0.5 SUBM-INTR-EP=3D00000002,SPD=3DLOW,NFR=3D1,SLEN=3D= 4,IVAL=3D10 frame[0] WRITE 2 bytes 0000 06 43 -- -- -- -- -- -- -- -- -- -- -- -- -- -- |.C = | flags 0x11 status 0xc0023 10:20:20.373052 usbus0.5 DONE-INTR-EP=3D00000002,SPD=3DLOW,NFR=3D1,SLEN=3D0,IVAL=3D10,ERR=3D0 frame[0] WRITE 2 bytes flags 0x11 status 0xc0021 Sent the next command..... and.... 10:20:21.733059 usbus0.5 DONE-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D4,IVAL=3D0,ERR=3D0 frame[0] READ 4 bytes 0000 5A 02 00 4A -- -- -- -- -- -- -- -- -- -- -- -- |Z..J = | flags 0x12 status 0xc1021 10:20:21.733103 usbus0.5 SUBM-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D= 0,IVAL=3D0 frame[0] READ 8 bytes flags 0x12 status 0xc1023 I got the old one back (instead of either a "55", which is an "ack; you may proceed with the next request" or the echo of what I sent which also implies a clear interface once I've processed it.) 10:20:22.353058 usbus0.5 DONE-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D4,IVAL=3D0,ERR=3D0 frame[0] READ 4 bytes 0000 5A 02 00 4A -- -- -- -- -- -- -- -- -- -- -- -- |Z..J = | flags 0x12 status 0xc1021 10:20:22.353102 usbus0.5 SUBM-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D= 0,IVAL=3D0 frame[0] READ 8 bytes flags 0x12 status 0xc1023 10:20:24.063055 usbus0.5 DONE-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D4,IVAL=3D0,ERR=3D0 frame[0] READ 4 bytes 0000 5A 02 00 4A -- -- -- -- -- -- -- -- -- -- -- -- |Z..J = | flags 0x12 status 0xc1021 10:20:24.063085 usbus0.5 SUBM-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D= 0,IVAL=3D0 frame[0] READ 8 bytes flags 0x12 status 0xc1023 And then I get a bunch of repeats on ~2 second intervals even though I haven't sent anything else... If I'm reading this correctly usbdump is showing me exactly what the device is sending; that is, there is no "driver" involved here (just bus traffic) -- correct? If so that looks like a device bug (and a nasty one that I may have all sorts of fun trying to work around.) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms040907010105080409020709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTgxNTMyMTdaME8GCSqGSIb3DQEJBDFCBEDy 9PiGabqJepAngIQq5xB1JrnB88z8Yb6FRnYAyhhQVoBjErazA03oSR3S/HE0Qt9/9gqXdLeu 5xVls91TIZKTMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAi4qUhTDE dOiGZU5I0EtDGCdqaKKPzXU0+PntcEGQ+sOZr6bnnrSWCTNAzTArLO4IpOcvPSaeQekGuI0L hB6amDboGy6+NPwBngvP6OpBSMfAMu3dBHSVum36pUcLAdAfZch4FKnu9X9FxBWaetxCGOAt 4GlC9OX4UjzBuh9rHju0chDXax779nAZ1uF8Tmi78HpJr/zkUYDfWL2JWms2NRfIIH3/lcZN 5CC3XX2pu0hYZmkBlF6anLPp9UkVrGhT2VPoeY+H1+bYzsS3EIkVTWmzY41UWBLZqiQj+DXe cPO+2DBLKikIHaPsDa6CpEmQG0TqMgTX3eafDE5j8Prw8j8gtpxEvbVy6pySL3jw8r5YDjna gx1FlQ4y1CdMBWaEyvnGEk3QeISPyPIe4m2zBKM9qwN2LFzXbLZl6XoHn90l9GG3R/Xgra0S uYHP8wPovfH9gYYze58+Afs3XkpgdtA+FOSDTXRGco9yuc5huI4I7q59wiCwMWVqckC59EKc AvT3tzMAeIPEASQNegp2D+Yt6TIIPPT4C7t1FI2enEFnlLoAfceLDo1RngiuhsxPCpN6gCOy 1DT97RFWVgUEOYFJGAbtVuVUi9V5ZtCXAjbd1YUoDHY/LnZjtobcb/boeMEA+pRR16VjRCww wY2Sj77MA1z9qy9116767mZmRMEAAAAAAAA= --------------ms040907010105080409020709-- From owner-freebsd-usb@freebsd.org Wed May 18 15:42:45 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43104B41E86 for ; Wed, 18 May 2016 15:42:45 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1039A18A2 for ; Wed, 18 May 2016 15:42:45 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 0CB2C1FE024; Wed, 18 May 2016 17:42:42 +0200 (CEST) Subject: Re: Oddity with ugen To: Karl Denninger , freebsd-usb@freebsd.org References: <46bd6efe-5335-f659-0b07-5107b0e9a326@selasky.org> From: Hans Petter Selasky Message-ID: Date: Wed, 18 May 2016 17:46:03 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 15:42:45 -0000 On 05/18/16 17:32, Karl Denninger wrote: > If I'm reading this correctly usbdump is showing me exactly what the > device is sending; that is, there is no "driver" involved here (just bus > traffic) -- correct? Hi, usbdump is showing exactly what the USB controller driver is sending and receiving. It is similar to a USB wire trace. > > If so that looks like a device bug (and a nasty one that I may have all > sorts of fun trying to work around.) Yes, most likely a bug on the device side. I assume you are running this software on a regular computer with EHCI/XHCI/OHCI/UHCI ? --HPS From owner-freebsd-usb@freebsd.org Wed May 18 15:53:23 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EBC92B412F5 for ; Wed, 18 May 2016 15:53:23 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 99EAA1365 for ; Wed, 18 May 2016 15:53:23 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id B31961183BA for ; Wed, 18 May 2016 10:53:21 -0500 (CDT) Subject: Re: Oddity with ugen To: freebsd-usb@freebsd.org References: <46bd6efe-5335-f659-0b07-5107b0e9a326@selasky.org> From: Karl Denninger Message-ID: <8dfad53f-e8a6-68b7-37e2-d5cd95768ceb@denninger.net> Date: Wed, 18 May 2016 10:53:11 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070408020103050700090308" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 15:53:24 -0000 This is a cryptographically signed message in MIME format. --------------ms070408020103050700090308 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/18/2016 10:46, Hans Petter Selasky wrote: > On 05/18/16 17:32, Karl Denninger wrote: >> If I'm reading this correctly usbdump is showing me exactly what the >> device is sending; that is, there is no "driver" involved here (just b= us >> traffic) -- correct? > Hi, > > usbdump is showing exactly what the USB controller driver is sending > and receiving. It is similar to a USB wire trace. > Basically tcpdump for usb. Got it. >> >> If so that looks like a device bug (and a nasty one that I may have al= l >> sorts of fun trying to work around.) > > Yes, most likely a bug on the device side. > > I assume you are running this software on a regular computer with > EHCI/XHCI/OHCI/UHCI ? > > --HPS This is being seen on a Pi2 / 11-Current. I'm reasonably sure that the Pi2 itself and the base USB code is ok, however, because there is another USB device also in use by the same software (it emulates a serial port and so attaches on the serial driver; it exposes itself as a /dev/cua.... device) which has never exhibited repeated frames although it too talks using interrupt mode, and also has a packet style of communication, so if it was doing the same sort of thing my code would have been yelling about it, particularly since that other device also generates sequence numbers on the packets for use by the software in implementing a callback stack (this one doesn't.) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms070408020103050700090308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTgxNTUzMTFaME8GCSqGSIb3DQEJBDFCBEBe suZLWsAAv+hnh395Zinz1sbHXlZeFrBU/PKF3n4LwWstNYwh8ir2+1cjHcaYW+pLAvVpo0Us eyP/Tn4DTsgHMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIActoZ1vVO 7bz8EQ+cybxZP+QfzdsoimaxiZao6po5dYV1bC7iwjrKsOfWzx44A4CpztkYByCdglEfmc5s dzctYK384P0Tq869BKOwZPPuqtAMB7fMe3jTOTDV7EX2yM/LQte8ohaAoOyQ6wFxJs7cBvp1 xZSQAsiwKeltCBdvQYlmOJ8G4MnNoCYYR9igfNTUWfuH5ixREW9ijlikWAU4MeuYlAFiSZNU L0hshZ5PjUmWVAzFy+PfmHlq7d/DaCi/Lsn2A4PXtIweDRwyembGwwEViAbmCtbiBtF8pjrX Ic0PswcxaRRqj6e8UjSKZ2Ufklp2thxD7D99U3qcpbk1lyb+5sRaU/dyQjo6P/SgMOUi74WT oiycwubsFWNtwhcxauqqlqGquvpvqzWu/6QoS8x0t7ms0eRp5jW1tp4zHhlvrGbSJ711LA9H FSo/PwgqGSjGpjrRzi9EMXIBpWX8kJow30mjueULWIgXazHotoP1eXZJfQpY4Z1lxlJqk/gC G4vIcoUlKkjYFEm1Zz/CopZJgXmr4J96J9P+j6vzUjute7p7gq/qpZMRMGSPbxrgAgkEG9b9 zfdl1+vGzYpfOaBfDJMcDtMEyOzIgdUxpYhF+uel3pRVbBDUTJImfkgLI8jKz6b6tJvRDjVj 0eu4z2j9ExmoyUezH7BDAfQgNBgAAAAAAAA= --------------ms070408020103050700090308-- From owner-freebsd-usb@freebsd.org Wed May 18 16:18:57 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 200D7B417DB for ; Wed, 18 May 2016 16:18:57 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CFCE4112E for ; Wed, 18 May 2016 16:18:56 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 523371FE024; Wed, 18 May 2016 18:18:54 +0200 (CEST) Subject: Re: Oddity with ugen To: Karl Denninger , freebsd-usb@freebsd.org References: <46bd6efe-5335-f659-0b07-5107b0e9a326@selasky.org> <8dfad53f-e8a6-68b7-37e2-d5cd95768ceb@denninger.net> From: Hans Petter Selasky Message-ID: <10288d18-6da5-f5e8-e8ec-57d59b32ca7a@selasky.org> Date: Wed, 18 May 2016 18:22:14 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <8dfad53f-e8a6-68b7-37e2-d5cd95768ceb@denninger.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:18:57 -0000 On 05/18/16 17:53, Karl Denninger wrote: > This is being seen on a Pi2 / 11-Current. > > I'm reasonably sure that the Pi2 itself and the base USB code is ok, > however, because there is another USB device also in use by the same > software (it emulates a serial port and so attaches on the serial > driver; it exposes itself as a /dev/cua.... device) which has never > exhibited repeated frames although it too talks using interrupt mode, > and also has a packet style of communication, so if it was doing the > same sort of thing my code would have been yelling about it, > particularly since that other device also generates sequence numbers on > the packets for use by the software in implementing a callback stack > (this one doesn't.) Hi, Is this reproducable on a PC w/ EHCI/OHCI/UHCI/XHCI ? Can you check the USB speed of the two different devices? LOW/HIGH/FULL The RPi2 drives most of the USB controller in software, which might influence some of the timing. Further there is quirk for USB interrupt endpoints in the DWC OTG driver, but I'm not sure if that is the cause of the problem. What is the exact time between these spurious packets as seen by usbdump? --HPS From owner-freebsd-usb@freebsd.org Wed May 18 16:49:47 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 345A3B41D34 for ; Wed, 18 May 2016 16:49:47 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF86F12D7 for ; Wed, 18 May 2016 16:49:46 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 962421FE024; Wed, 18 May 2016 18:49:44 +0200 (CEST) Subject: Re: Oddity with ugen To: Karl Denninger , freebsd-usb@freebsd.org References: <46bd6efe-5335-f659-0b07-5107b0e9a326@selasky.org> <8dfad53f-e8a6-68b7-37e2-d5cd95768ceb@denninger.net> From: Hans Petter Selasky Message-ID: Date: Wed, 18 May 2016 18:53:05 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <8dfad53f-e8a6-68b7-37e2-d5cd95768ceb@denninger.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:49:47 -0000 On 05/18/16 17:53, Karl Denninger wrote: > I'm reasonably sure that the Pi2 itself and the base USB code is ok, > however, because there is another USB device also in use by the same > software (it emulates a serial port and so attaches on the serial > driver; Hi, When you are using /dev/usb/X.Y.Z the IN-endpoints will be polling for data all the time. I've seen devices that return crap data if you try to read from them while you are not supposed to get data, in typical ping-pong protocol scenarios. Using libusb might be a better solution. --HPS From owner-freebsd-usb@freebsd.org Wed May 18 16:57:48 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3E7DB41F40 for ; Wed, 18 May 2016 16:57:48 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6AA2A1B65 for ; Wed, 18 May 2016 16:57:47 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 3E2421186AE for ; Wed, 18 May 2016 11:57:41 -0500 (CDT) Subject: Re: Oddity with ugen To: freebsd-usb@freebsd.org References: <46bd6efe-5335-f659-0b07-5107b0e9a326@selasky.org> <8dfad53f-e8a6-68b7-37e2-d5cd95768ceb@denninger.net> <10288d18-6da5-f5e8-e8ec-57d59b32ca7a@selasky.org> From: Karl Denninger Message-ID: <694e8b6a-2607-ff4e-58ea-53d544ee4e52@denninger.net> Date: Wed, 18 May 2016 11:57:31 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <10288d18-6da5-f5e8-e8ec-57d59b32ca7a@selasky.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050106040908080609090006" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:57:48 -0000 This is a cryptographically signed message in MIME format. --------------ms050106040908080609090006 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/18/2016 11:22, Hans Petter Selasky wrote: > On 05/18/16 17:53, Karl Denninger wrote: >> This is being seen on a Pi2 / 11-Current. >> >> I'm reasonably sure that the Pi2 itself and the base USB code is ok, >> however, because there is another USB device also in use by the same >> software (it emulates a serial port and so attaches on the serial >> driver; it exposes itself as a /dev/cua.... device) which has never >> exhibited repeated frames although it too talks using interrupt mode, >> and also has a packet style of communication, so if it was doing the >> same sort of thing my code would have been yelling about it, >> particularly since that other device also generates sequence numbers o= n >> the packets for use by the software in implementing a callback stack >> (this one doesn't.) > > Hi, > > Is this reproducable on a PC w/ EHCI/OHCI/UHCI/XHCI ? Unknown. Will see if I can find out... the code can be recompiled to run a PC, of course, but this does not show up on my bench, only under actual use load, which makes it a lot of fun to isolate. > > Can you check the USB speed of the two different devices? LOW/HIGH/FULL= This is the only "LOW" device in the system. > > The RPi2 drives most of the USB controller in software, which might > influence some of the timing. Further there is quirk for USB interrupt > endpoints in the DWC OTG driver, but I'm not sure if that is the cause > of the problem. > > What is the exact time between these spurious packets as seen by usbdum= p? > > --HPS Here is a sequence of four of them in a row... 10:20:31.463029 usbus0.5 DONE-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D4,IVAL=3D0,ERR=3D0 frame[0] READ 4 bytes 0000 5A 02 00 4A -- -- -- -- -- -- -- -- -- -- -- -- |Z..J = | flags 0x12 status 0xc1021 10:20:31.463052 usbus0.5 SUBM-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D= 0,IVAL=3D0 frame[0] READ 8 bytes flags 0x12 status 0xc1023 10:20:32.073035 usbus0.5 DONE-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D4,IVAL=3D0,ERR=3D0 frame[0] READ 4 bytes 0000 5A 02 00 4A -- -- -- -- -- -- -- -- -- -- -- -- |Z..J = | flags 0x12 status 0xc1021 10:20:32.073076 usbus0.5 SUBM-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D= 0,IVAL=3D0 frame[0] READ 8 bytes flags 0x12 status 0xc1023 ~610ms 10:20:32.693053 usbus0.5 DONE-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D4,IVAL=3D0,ERR=3D0 frame[0] READ 4 bytes 0000 5A 02 00 4A -- -- -- -- -- -- -- -- -- -- -- -- |Z..J = | flags 0x12 status 0xc1021 10:20:32.693085 usbus0.5 SUBM-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D= 0,IVAL=3D0 frame[0] READ 8 bytes flags 0x12 status 0xc1023 ~620ms 10:20:33.313048 usbus0.5 DONE-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D4,IVAL=3D0,ERR=3D0 frame[0] READ 4 bytes 0000 5A 02 00 4A -- -- -- -- -- -- -- -- -- -- -- -- |Z..J = | flags 0x12 status 0xc1021 10:20:33.313079 usbus0.5 SUBM-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D= 0,IVAL=3D0 frame[0] READ 8 bytes flags 0x12 status 0xc1023 ~620ms Rather consistent.... note that the device itself, however, is a power-line (X10) interface and thus the actual timing of a command that can be sent (the bits are clocked during the zero-crossing of each 60hz cycle) is approximately this figure. This is an "orphan" device (X10 CM15) and thus there's zero manufacturer support available for it. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050106040908080609090006 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTgxNjU3MzFaME8GCSqGSIb3DQEJBDFCBEB6 rxJB1aCcVMY8XQM3YLF0Bf4mIDnswLtCQ+HtV5FlFnt1zNqe0hPcP2JaWACbOFfW+EuA5sAb t4c4bfoXdhEFMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIATBXNTMO3 qVE/m4F3zP8x1+sC4mvUJrTSH9j5HcgNBjQvCgMiMIV0cc9S2mQ4OJsIdx+bWe8FupYmYFrQ RtXjrbRBlhAbqkgr0sScYFwlVKivwlrHVAoMjTeaagXAeLpncSN3MxKjVoDFJZNpYLdTkfeP OiUQ90hX8ue06bDuYLJDC8oyIkPWrKGBCThULoyGBa9ajcYg4kAy5ZZKkCozrqXyrMcwUXkt OLjaz8X1m0dBeHBMYKgJy6yFFOK4AoUjTxChtehx4VkrGF4uIjD+3BEdZQHChPstEb7z2fIN powLnXn0OxedsyumpJSVjDm3j8gD5L4gRqqNGYDcTAf/6wBuOgTArUvhYV2EUK/Xr1s6Rn9D hIky///+d6UUSnOQBUftpyWtEjp4gMLSsjCDqFPw93CngYzoUdWTjFNYQpki1JvbWapxmVFv xYBAs5RyU4O3aMKzeeCjjMLWquU8p9swHo7/ewQYTJyG1cKUAuB+Ds/J+uxa6fsKTkp1U3C6 3bMHD1BJv6WwnXisun8ou8UTaUSXfmlKFPYwHswX/a8/FxkTwIf/vXbCL7uuGTjAOny5xsBd issqvTH/8fvlV0XKOnuqMdM3RAupcqAxSxcuzxcwsurBeR1ndk01029CCxJU4FUaCfGx1Nma ZyNPh+zZYNa6l9f5NJ2ogzCSO6oAAAAAAAA= --------------ms050106040908080609090006-- From owner-freebsd-usb@freebsd.org Wed May 18 17:16:17 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A510FB413CF for ; Wed, 18 May 2016 17:16:17 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6212816AF for ; Wed, 18 May 2016 17:16:16 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id CB9591FE024; Wed, 18 May 2016 19:16:14 +0200 (CEST) Subject: Re: Oddity with ugen To: Karl Denninger , freebsd-usb@freebsd.org References: <46bd6efe-5335-f659-0b07-5107b0e9a326@selasky.org> <8dfad53f-e8a6-68b7-37e2-d5cd95768ceb@denninger.net> <10288d18-6da5-f5e8-e8ec-57d59b32ca7a@selasky.org> <694e8b6a-2607-ff4e-58ea-53d544ee4e52@denninger.net> From: Hans Petter Selasky Message-ID: <0442915e-8020-b521-3dd5-29c9937cd204@selasky.org> Date: Wed, 18 May 2016 19:19:35 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <694e8b6a-2607-ff4e-58ea-53d544ee4e52@denninger.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 17:16:17 -0000 On 05/18/16 18:57, Karl Denninger wrote: > ~620ms > > Rather consistent.... note that the device itself, however, is a > power-line (X10) interface and thus the actual timing of a command that > can be sent (the bits are clocked during the zero-crossing of each 60hz > cycle) is approximately this figure. > > This is an "orphan" device (X10 CM15) and thus there's zero manufacturer > support available for it. Hi, From what I know, there is no USB magic about these intervals. Did you try to run some ethernet traffic, like "ping" while running your test application? The DWC OTG uses a ring buffer for data reception from all endpoints. It is connected to a HighSpeed transaction translator USB HUB chip on the RPI2. The external USB HUB also has some internal memories, though I would think they would get wiped after that many milliseconds. The best way to figure out would be to connect a USB analyzer, like the Beagle one, to see if the traffic is really on the line. An oscilliscope might do too for 1MBit/s traffic (USB LowSpeed), just to figure out the length of the data. --HPS From owner-freebsd-usb@freebsd.org Wed May 18 17:21:15 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1031CB4152D for ; Wed, 18 May 2016 17:21:15 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9543E18B9 for ; Wed, 18 May 2016 17:21:14 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 3E6C711882A for ; Wed, 18 May 2016 12:21:12 -0500 (CDT) Subject: Re: Oddity with ugen To: freebsd-usb@freebsd.org References: <46bd6efe-5335-f659-0b07-5107b0e9a326@selasky.org> <8dfad53f-e8a6-68b7-37e2-d5cd95768ceb@denninger.net> <10288d18-6da5-f5e8-e8ec-57d59b32ca7a@selasky.org> <694e8b6a-2607-ff4e-58ea-53d544ee4e52@denninger.net> From: Karl Denninger Message-ID: <4d3e7356-bd57-a03c-b499-325bfd2bd027@denninger.net> Date: Wed, 18 May 2016 12:21:02 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <694e8b6a-2607-ff4e-58ea-53d544ee4e52@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020504040303050003010004" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 17:21:15 -0000 This is a cryptographically signed message in MIME format. --------------ms020504040303050003010004 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/18/2016 11:57, Karl Denninger wrote: > On 5/18/2016 11:22, Hans Petter Selasky wrote: >> On 05/18/16 17:53, Karl Denninger wrote: >>> This is being seen on a Pi2 / 11-Current. >>> >>> I'm reasonably sure that the Pi2 itself and the base USB code is ok, >>> however, because there is another USB device also in use by the same >>> software (it emulates a serial port and so attaches on the serial >>> driver; it exposes itself as a /dev/cua.... device) which has never >>> exhibited repeated frames although it too talks using interrupt mode,= >>> and also has a packet style of communication, so if it was doing the >>> same sort of thing my code would have been yelling about it, >>> particularly since that other device also generates sequence numbers = on >>> the packets for use by the software in implementing a callback stack >>> (this one doesn't.) >> Hi, >> >> Is this reproducable on a PC w/ EHCI/OHCI/UHCI/XHCI ? > Unknown. Will see if I can find out... the code can be recompiled to > run a PC, of course, but this does not show up on my bench, only under > actual use load, which makes it a lot of fun to isolate. >> Can you check the USB speed of the two different devices? LOW/HIGH/FUL= L > This is the only "LOW" device in the system. root@HD-MCP:/tmp # usbconfig show_ifdrv ugen0.1: at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr=3DSAVE (0mA) ugen0.1.0: uhub0: = ugen0.2: at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr=3DSAVE (2mA) ugen0.2.0: uhub1: ugen0.3: at usbus0, cfg=3D0 md=3DHOST spd=3DHIGH (480Mbps) pwr=3DON (2mA) ugen0.3.0: smsc0: ugen0.4: at usbus0, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON (100mA) ugen0.4.0: umodem0: ugen0.5: at usbus0, cfg=3D0 md=3DHOST spd=3DLOW (1.5Mbps) pwr=3DON (2mA) The device that comes up on "umodem" isn't really a modem, but that interface works fine. I toyed with the idea of detaching it and going after it directly as well off ugen but decided to leave it alone as it is working fine as it stands. >> The RPi2 drives most of the USB controller in software, which might >> influence some of the timing. Further there is quirk for USB interrupt= >> endpoints in the DWC OTG driver, but I'm not sure if that is the cause= >> of the problem. >> >> What is the exact time between these spurious packets as seen by usbdu= mp? >> >> --HPS > Here is a sequence of four of them in a row... > > 10:20:31.463029 usbus0.5 > DONE-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D4,IVAL=3D0,ERR=3D0 > frame[0] READ 4 bytes > 0000 5A 02 00 4A -- -- -- -- -- -- -- -- -- -- -- -- |Z..J = | > flags 0x12 > status 0xc1021 > > 10:20:31.463052 usbus0.5 SUBM-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN= =3D0,IVAL=3D0 > frame[0] READ 8 bytes > flags 0x12 > status 0xc1023 > > > 10:20:32.073035 usbus0.5 > DONE-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D4,IVAL=3D0,ERR=3D0 > frame[0] READ 4 bytes > 0000 5A 02 00 4A -- -- -- -- -- -- -- -- -- -- -- -- |Z..J = | > flags 0x12 > status 0xc1021 > > 10:20:32.073076 usbus0.5 SUBM-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN= =3D0,IVAL=3D0 > frame[0] READ 8 bytes > flags 0x12 > status 0xc1023 > > > ~610ms > > 10:20:32.693053 usbus0.5 > DONE-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D4,IVAL=3D0,ERR=3D0 > frame[0] READ 4 bytes > 0000 5A 02 00 4A -- -- -- -- -- -- -- -- -- -- -- -- |Z..J = | > flags 0x12 > status 0xc1021 > > 10:20:32.693085 usbus0.5 SUBM-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN= =3D0,IVAL=3D0 > frame[0] READ 8 bytes > flags 0x12 > status 0xc1023 > > > ~620ms > > 10:20:33.313048 usbus0.5 > DONE-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN=3D4,IVAL=3D0,ERR=3D0 > frame[0] READ 4 bytes > 0000 5A 02 00 4A -- -- -- -- -- -- -- -- -- -- -- -- |Z..J = | > flags 0x12 > status 0xc1021 > > 10:20:33.313079 usbus0.5 SUBM-INTR-EP=3D00000081,SPD=3DLOW,NFR=3D1,SLEN= =3D0,IVAL=3D0 > frame[0] READ 8 bytes > flags 0x12 > status 0xc1023 > > > ~620ms > > Rather consistent.... note that the device itself, however, is a > power-line (X10) interface and thus the actual timing of a command that= > can be sent (the bits are clocked during the zero-crossing of each 60hz= > cycle) is approximately this figure. > > This is an "orphan" device (X10 CM15) and thus there's zero manufacture= r > support available for it. One other note -- I looked at libusb but it does not appear that there is a way to do a "select()" on the input endpoint to determine if data is available. The device in question can send data upstream to the application at any time if it "sees" traffic either from RF or the power line; it is not necessarily only going to do so when talked to. This makes speaking to it "fun", especially considering that there are responses it can reply with that have no fixed preamble or length byte which means there's no way to be sure that particular response is what it appears to be other than to ask for them only when the interface is quiescent and hope you don't collide with an asynchronous event coming up the pipe. Fortunately I don't need to make those inquiries during normal operation... In theory the unit should only respond with an "ACK" when told to transmit but in practice (both this and the CM11, which is a serial-attached thing that is even MORE buggy and has nasty timing requirements that are impossible to correctly support without being able to sense the RI modem control signal reliably) it will sometimes "see" a reflected copy of a transmitted command due to phase-coupling effects and thus it will claim to have "received" data that it actually sent, and never send an ACK at all. As a result the state machine necessary to talk to these things can be a bit messy. It's possible this is a bug in the interface firmware -- there are known ones in the CM11 that can cause a complete lockup that requires a power-cycle to correct, and a transmit lockup-producing one in an earlier revision of this unit that is lots of fun (it claims to be sending and acknowledges having done so but actually sends nothing -- which cannot be detected in the code since the interface says all is well!) so I wouldn't be shocked if the unit is actually transmitting upstream like this.... it may be that I have to get cute with timing in the code on my end to prevent it from getting into this state. I have a DSS and know how to use it so that's gonna be next I suspect.... :-) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020504040303050003010004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp 3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5 vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/ o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6 eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+ JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ 3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0 FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG 1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5 c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTgxNzIxMDJaME8GCSqGSIb3DQEJBDFCBEDm uUwsjz1zlgYOxDHUQ8KtaLiSUtRNTDGCxlAfzVMQbsj9Ev1GFH6REk+Bc2C7cRBma/eKv7MK bafb6KIZJ6+jMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAB9pkfPZN wA7h0v/E00eeZP7nQMQ+MaPEAl5iy6jH1sjrTgORDPoQF1Xyp+iz+9AvX4YytH581o66DKRJ uymq2Pjbv+FlIU9SZcfe7agQm9fJu3pTFce9auT60hHnYtuOPblwVEg7KaBmPjQsodvGX4MW faf4QbOo7snKR/hEmQj8wAQj2fq2cin3aQ60togHiGro3bT+nSTKWbUGwMk5VFbSEtTPJXYV gpnbZM59lsnjjPkrua0ZY0mS2a+Mp2jD3lyyg9GZ6FhfTy+ybw7ETCFuk+nFBSFsNiE9qK3Y vl0z+/ANlkq2xCfgZy5M72+5B174fBGA44OGcm03HFekiDqU4xZCIf9QnXJHTQbLTUU5Ihpa Xlz3MuOzDUk4eScC6DaC6ZP56uyzqo+8cxwYzvTjbzdHvoA5dD/nBZGId2fO2uZ6YrHCvg+O mgOioMAMPXR4Ld96c5CRifaeHix3rH6CXeOai2bopDP8BBwBc5wUBjEIolYhyqyWsp+//QO1 iSlx1SWn3k+nUiSj4rPWYEHUFe5rzzaW8UaWx+NLOjJOlrxIVhk7IEljFsBYWHlTDsGzg3Qw YcU1uaV9wKB1wckW5fugm8Kof6rDBoyg8WEm/X8qyq2Y9ZVnTVznmJIHLceQbo2JbnZmrzOR KeMSDgM+KGWMucjIpq1xl9w5+p0AAAAAAAA= --------------ms020504040303050003010004-- From owner-freebsd-usb@freebsd.org Wed May 18 19:05:39 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E30B8B40E6B for ; Wed, 18 May 2016 19:05:39 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE5A31EA6 for ; Wed, 18 May 2016 19:05:39 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B551D1FE024; Wed, 18 May 2016 21:05:35 +0200 (CEST) Subject: Re: Oddity with ugen To: Karl Denninger , freebsd-usb@freebsd.org References: <46bd6efe-5335-f659-0b07-5107b0e9a326@selasky.org> <8dfad53f-e8a6-68b7-37e2-d5cd95768ceb@denninger.net> <10288d18-6da5-f5e8-e8ec-57d59b32ca7a@selasky.org> <694e8b6a-2607-ff4e-58ea-53d544ee4e52@denninger.net> <4d3e7356-bd57-a03c-b499-325bfd2bd027@denninger.net> From: Hans Petter Selasky Message-ID: <944fecd7-da8d-c89b-83fd-c84cd4501e24@selasky.org> Date: Wed, 18 May 2016 21:08:56 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <4d3e7356-bd57-a03c-b499-325bfd2bd027@denninger.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 19:05:40 -0000 On 05/18/16 19:21, Karl Denninger wrote: > One other note -- I looked at libusb but it does not appear that there > is a way to do a "select()" on the input endpoint to determine if data > is available. LibUSB v2.0 has: int libusb20_dev_get_fd(struct libusb20_device *pdev); --HPS From owner-freebsd-usb@freebsd.org Thu May 19 10:53:11 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1DDD9B422C1 for ; Thu, 19 May 2016 10:53:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0EE1C12CD for ; Thu, 19 May 2016 10:53:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u4JArAPY090137 for ; Thu, 19 May 2016 10:53:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-usb@FreeBSD.org Subject: [Bug 209636] usr/src/sys/dev/usb/controller/generic_ohci.c:169: possible bad size ? Date: Thu, 19 May 2016 10:53:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: usb X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dcb314@hotmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-usb@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 10:53:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209636 Bug ID: 209636 Summary: usr/src/sys/dev/usb/controller/generic_ohci.c:169: possible bad size ? Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: usb Assignee: freebsd-usb@FreeBSD.org Reporter: dcb314@hotmail.com [usr/src/sys/dev/usb/controller/generic_ohci.c:169]: (warning) Size of poin= ter 'clkp' used instead of size of its data. Source code is clkp =3D malloc(sizeof(clkp), M_DEVBUF, M_WAITOK | M_ZERO); Maybe better code clkp =3D malloc(sizeof(*clkp), M_DEVBUF, M_WAITOK | M_ZERO); --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-usb@freebsd.org Thu May 19 11:02:48 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA62AB426C5 for ; Thu, 19 May 2016 11:02:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B22D1C87 for ; Thu, 19 May 2016 11:02:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u4JB2mRc053695 for ; Thu, 19 May 2016 11:02:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-usb@FreeBSD.org Subject: [Bug 209636] usr/src/sys/dev/usb/controller/generic_ohci.c:169: possible bad size ? Date: Thu, 19 May 2016 11:02:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: usb X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-usb@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 11:02:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209636 --- Comment #1 from commit-hook@freebsd.org --- A commit references this bug: Author: hselasky Date: Thu May 19 11:02:39 UTC 2016 New revision: 300200 URL: https://svnweb.freebsd.org/changeset/base/300200 Log: Fix bad sizeof(). Submitted by: David Binderman PR: 209636 Changes: head/sys/dev/usb/controller/generic_ohci.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-usb@freebsd.org Thu May 19 11:03:05 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4777BB42701 for ; Thu, 19 May 2016 11:03:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 382801DB1 for ; Thu, 19 May 2016 11:03:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u4JB35Tv054263 for ; Thu, 19 May 2016 11:03:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-usb@FreeBSD.org Subject: [Bug 209636] usr/src/sys/dev/usb/controller/generic_ohci.c:169: possible bad size ? Date: Thu, 19 May 2016 11:03:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: usb X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hselasky@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: hselasky@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 11:03:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209636 Hans Petter Selasky changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-usb@FreeBSD.org |hselasky@FreeBSD.org CC| |hselasky@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-usb@freebsd.org Fri May 20 21:15:16 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1F65B4217E for ; Fri, 20 May 2016 21:15:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E32F81840 for ; Fri, 20 May 2016 21:15:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u4KLFFpB085950 for ; Fri, 20 May 2016 21:15:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-usb@FreeBSD.org Subject: [Bug 209674] USB keyboard's keys become sticky Date: Fri, 20 May 2016 21:15:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: usb X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bourne.identity@hotmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-usb@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 21:15:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209674 Bug ID: 209674 Summary: USB keyboard's keys become sticky Product: Base System Version: 10.2-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: usb Assignee: freebsd-usb@FreeBSD.org Reporter: bourne.identity@hotmail.com CC: freebsd-amd64@FreeBSD.org CC: freebsd-amd64@FreeBSD.org I would like to report a possible bug on my amd64 system running FreeBSD 10= .2, which at least one gentleman also suffers from on his 10.3 system. While ty= ping with the X server running, keys of my keyboard become 'sticky': pressing 'A' once results in multiple (dozens, sometimes hundreds) of 'A'. This nuisance= - which happens about once in 5 minutes of typing - usually stops by itself a= nd the key gets 'unstuck' automatically after a couple of seconds. This happens only under FreeBSD (not Linux, not Windows) and only under the X server (not when typing on the console when there is no X). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-usb@freebsd.org Sat May 21 08:32:27 2016 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2566B436BA for ; Sat, 21 May 2016 08:32:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C36ED1FF7 for ; Sat, 21 May 2016 08:32:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u4L8WRk4022851 for ; Sat, 21 May 2016 08:32:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-usb@FreeBSD.org Subject: [Bug 209674] USB keyboard's keys become sticky Date: Sat, 21 May 2016 08:32:27 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: usb X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: hselasky@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-usb@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 08:32:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209674 Hans Petter Selasky changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hselasky@FreeBSD.org --- Comment #1 from Hans Petter Selasky --- Hi, Can you give some more information: usbconfig pciconf -lv dmesg | grep ukbd Capture USB traffic while problem occurs: usbdump -i usbusX -f Y -s 65536 -vvv X and Y are numbers after ugenX.Y for the keyboard device. --HPS --=20 You are receiving this mail because: You are the assignee for the bug.=