On Fri, 26 Mar 2004, Alan Stern wrote: > On Fri, 26 Mar 2004, Matthias Andree wrote: > > > So can the initialization sequence be run after "babble" was detected on > > a VIA controller that locked up? > > I'm not sure what initialization you're referring to. After a VIA > controller has locked up, _nothing_ can be done with it, other than > completely resetting it. That's what the UHCI driver does when it is > first loaded, and that's why rmmod/modprobe uhci-hcd will get the > controller going again.
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 isn't a single issue, it's a confluence of several problems. > > 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? > 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. > Your scanner gets confused when it receives too many requests > too quickly. It doesn't answer them properly and it sends > replies that are longer than they should be. That's a genuine > error in the scanner's firmware, and it can't be fixed by > messing around with the Linux kernel. It's a bit of a pity that I get to know this five weeks after the two-year warranty has expired... else I could've returned the beast and got either a newer one or a different model. So I can only check with Epson if they have new firmware and how this can be upgraded. > Access control in usbfs doesn't work well. In fact, you can't > even mount the filesystem with 0666 permissions, so you have > to be root to write to any of the device files. Eventually > this will be fixed, but not for quite some time. Not a priority issue, Hotplug works fine to run chmod 0660/chown root:trusted on the device node and allows per-device access control. I only wish that resmgr would die for it doesn't work right given the unstable device numbering. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ------------------------------------------------------- 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
