From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3651cf29f627aaa60374ed89f882e752@gmx.de> To: 9fans@9fans.net Date: Sun, 19 Jul 2009 09:54:05 +0200 From: cinap_lenrek@gmx.de In-Reply-To: <775b8d190907190021hadae3ffyea534970379e313d@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-otpkfirzyhogkkfdslxdmvdbfq" Subject: Re: [9fans] new usb stack and implicit timeouts Topicbox-Message-UUID: 26f738bc-ead5-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-otpkfirzyhogkkfdslxdmvdbfq Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit pulling the device gets me a "crc/timeout error", not a "request timed out". but i'm not sure if this is always the case though. the driver should not artificially generate errors in my opinion even if it would be convinient for some userspace drivers to have it. those who need a timeout should choose ther own value depending on what they are doing. -- cinap --upas-otpkfirzyhogkkfdslxdmvdbfq Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-bounces+cinap_lenrek=gmx.de@9fans.net> X-Flags: 0000 Delivered-To: GMX delivery to cinap_lenrek@gmx.de Received: (qmail invoked by alias); 19 Jul 2009 07:25:33 -0000 Received: from gouda.swtch.com (EHLO gouda.swtch.com) [67.207.142.3] by mx0.gmx.net (mx027) with SMTP; 19 Jul 2009 09:25:33 +0200 Received: from localhost ([127.0.0.1] helo=gouda.swtch.com) by gouda.swtch.com with esmtp (Exim 4.69) (envelope-from <9fans-bounces@9fans.net>) id 1MSQi4-0005LW-4l; Sun, 19 Jul 2009 07:21:24 +0000 Received: from mail-px0-f178.google.com ([209.85.216.178]) by gouda.swtch.com with esmtp (Exim 4.69) (envelope-from ) id 1MSQi1-0005LM-Vl for 9fans@9fans.net; Sun, 19 Jul 2009 07:21:22 +0000 Received: by pxi8 with SMTP id 8so1308850pxi.22 for <9fans@9fans.net>; Sun, 19 Jul 2009 00:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=iTJuLGh3uNH9RSDEQcsNN98ufNZ9S7ryrw5+ZQ7gi+8=; b=C2dewO7BEmc+x0tjtLZOnPJh5a0Nf03iMv2tNw5JdItAreR1KN9UL4hPPJMoABPDT2 SFTE1jUj/gW1f4afWhWq1XXRJ//V+c0lvu1I/jjlq/qhHs/kJRG5Lsa08KbTMvp/WLBB cokROSdPpzuULJr5uvnNt6srLfvM4KJL+3GHw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=oAbXqLtpgy05EwwrtxeZpoRAcT0vagIs0XrWsVpw5tos8MzefGjoZiU3e+I4RqOGMR x5K1BS60+gpgfHjAuzAwOz45i70qc0L2PiwqbsLtUCago3fLB0TE5TXNEflAUmywlKAj xw02ca1spSPjKuP+/UhpJutnouZ0G0OlU3734= MIME-Version: 1.0 Received: by 10.114.190.18 with SMTP id n18mr4959385waf.179.1247988076225; Sun, 19 Jul 2009 00:21:16 -0700 (PDT) In-Reply-To: <06cb592e495ddaf9655a4d0ffae3c661@gmx.de> References: <06cb592e495ddaf9655a4d0ffae3c661@gmx.de> Date: Sun, 19 Jul 2009 17:21:16 +1000 Message-ID: <775b8d190907190021hadae3ffyea534970379e313d@mail.gmail.com> From: Bruce Ellis To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] new usb stack and implicit timeouts X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.10 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces@9fans.net Errors-To: 9fans-bounces+cinap_lenrek=gmx.de@9fans.net X-GMX-Antivirus: 0 (no virus found) X-GMX-Antispam: 0 (Mail was not recognized as spam) X-GMX-UID: XPNRcplaMmApOpQryGFnJucxMjQ1N53S The only justification I can see is to disconnect to stuff that's been unplugged or misbehaves. In your case that's not true. brucee On Sun, Jul 19, 2009 at 5:16 PM, wrote: > from the manpage: > > =A0 =A0 =A0 =A0 =A0For control, bulk, and isochronous transfers, there is= an > =A0 =A0 =A0 =A0 =A0implicit timeout performed by the kernel and it is not= nec- > =A0 =A0 =A0 =A0 =A0essary for applications to place their own timers. =A0= For > =A0 =A0 =A0 =A0 =A0interrupt transfers, the kernel will not time out any = opera- > =A0 =A0 =A0 =A0 =A0tion. > > souldnt the application / userspace driver know better than some > random choosen timeout in the kernel driver? > > also, this has not been taken into account for the new usb/ether. > > for now i'll just compare the errstr and try again, but this implicit > timeout stuff just smells "too smart" for me. > > -- > cinap > > > --upas-otpkfirzyhogkkfdslxdmvdbfq--