From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <3651cf29f627aaa60374ed89f882e752@gmx.de> References: <775b8d190907190021hadae3ffyea534970379e313d@mail.gmail.com> <3651cf29f627aaa60374ed89f882e752@gmx.de> Date: Sun, 19 Jul 2009 11:07:31 +0200 Message-ID: <8ccc8ba40907190207n2bd97032ra267bff7e45f7813@mail.gmail.com> From: Francisco J Ballesteros To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] new usb stack and implicit timeouts Topicbox-Message-UUID: 2700f9d8-ead5-11e9-9d60-3106f5b1d025 THere are some disks that do not respond to the controller after they crash. Also, RPCs carrying ctl requests to the devices may not respond either in some devices. I thought it was for sure an error when control and bulk requests took more than a while. Right now I=C2=B4m not so sure regarding bulk transfers, but I still think it=C2=B4s a good idea to timeout in the kernel control requests. pulling out is a different thing, as you say. ether requires more work, agree. On Sun, Jul 19, 2009 at 9:54 AM, wrote: > 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 > > > > ---------- Forwarded message ---------- > From:=C2=A0Bruce Ellis > To:=C2=A0Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> > Date:=C2=A0Sun, 19 Jul 2009 17:21:16 +1000 > Subject:=C2=A0Re: [9fans] new usb stack and implicit timeouts > 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: >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For control, bulk, and isochronous tra= nsfers, there is an >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implicit timeout performed by the kern= el and it is not nec- >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0essary for applications to place their= own timers. =C2=A0For >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interrupt transfers, the kernel will n= ot time out any opera- >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=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 >> >> >> >