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´m not so sure regarding bulk transfers, but I still think it´s 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, <cinap_len...@gmx.de> 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: Bruce Ellis <bruce.el...@gmail.com> > To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> > Date: Sun, 19 Jul 2009 17:21:16 +1000 > Subject: Re: [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, <cinap_len...@gmx.de> wrote: >> from the manpage: >> >> For control, bulk, and isochronous transfers, there is an >> implicit timeout performed by the kernel and it is not nec- >> essary for applications to place their own timers. For >> interrupt transfers, the kernel will not time out any opera- >> tion. >> >> 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 >> >> >> >
