On Fri, 26 Mar 2004, Matthias Andree wrote: > Knowing that SCSI host adaptors (at least the aic7xxx, tmscsim and > ncr53c8xx, sym53c8xx and sym53c8xx_2) do reset the host adaptor if > preceding device and bus resets have failed, the question is: > > What if the UHCI driver aborts all outstanding requests for the HCD with > EAGAIN (if permitted by the API) or EIO, resets the HCD as though it was > freshly loaded? > > If you say the HCD reset is the only way to recover from the problem, > then why not just do it automatically?
It could be done. It would have the undesirable effect of logically disconnecting all the devices attached to the controller and then reconnecting them, forcing them to go through their entire initialization sequence over again. This could cause an endless loop, if some device sends an overlong packet during its startup procedure (it's been known to happen). I regard that as a workaround, not a real solution. I'll implement it if necessary, but I'm still hoping to find out how to prevent the controllers from stopping in the first place. Windows doesn't suffer from this problem, so there is _some_ way around it (even if it's an unpalatable way). Another possible approach, one that's closer to being a solution although it involves a large amount of overhead, is to have the driver modify each USB request as it is set up. Replace each less-than-maximum-size transfer with a maximum-size one, so that the controller will never receive an overlong packet. That might work, even with all the extra effort required. It doesn't solve the problem that a badly broken device might send a packet that is longer than the maximum size allowed, again stopping the controller. > > VIA controllers have this flaw that makes them stop when they > > receive a packet longer than they expect. It's a genuine > > error in the hardware (unless it was done deliberately (?) ) > > Has VIA Tech Support commented on the buffer overflow lockup? I've contacted them, but they've been less than helpful. > > and at the moment we don't have a workaround for it. If you > > can suggest a way to solve this problem I would be very glad > > to hear it. > > I don't have contacts to VIA unfortunately, so I can only suggest that a > list of broken device IDs be assembled and that HCDs on that list be > reset immediately after the "babble" error. > > At the very least, it would be good to reject all further new requests > when the HCD hangs after a "babble" error, so that no new user-space > processes can get stuck - and given they're in D state, they are > unkillable. A better compromise would be to change the way the driver works so that requests that are "stuck" can still be cancelled. That way processes would be able to continue and the driver could be removed and reinstalled. As it stands now, when a controller stops with outstanding transfers in progress you can't even rmmod the uhci-hcd driver. This is one of the next changes I'm planning to make. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
