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--