t == -ECONNRESET) {
ret = USB_STOR_TRANSPORT_ABORTED;
goto out;
}
@@ -1213,7 +1213,7 @@
result = usb_stor_clear_halt(us, pipe);
/* if the command was aborted, indicate that */
- if (result == -ENOENT) {
+ if (result == -ECONNRESET) {
ret = USB_STOR_TRANSPORT_ABORTED;
} else {
ret = USB_STOR_TRANSPORT_ERROR;
--
Tom Collins
[EMAIL PROTECTED]
know what to do with that result code?
Any ideas why the error handling for unexpected errors isn't able to
reset the device?
--
Tom Collins
[EMAIL PROTECTED]
---
This SF.net email is sponsored by: Scholarships for Techies!
Can't aff
d
drives mount just fine (Spd=480) under the EHCI driver.
--
Tom Collins
[EMAIL PROTECTED]
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide
far drivers/usb reaches out of its directory
and impacts other drivers? I'll probably start experimenting later
tomorrow, but thought I'd seek out some advice before doing so.
--
Tom Collins
[EMAIL PROTECTED]
---
This SF.NET ema
generic_ffs was undefined, including linux/bitops.h solved that. Don't
know if this is the best place/way to do it, but it works. I'm
cross-compiling for MIPS, so let me know if it's actually an error in
include/asm-mips.
--- drivers/usb/hcd/ehci-hcd-orig.c Tue Jan 14 16:52:53 2003
+++ dr
Using Alan Cox's patch to ehci-dbg.c so it will compile on my system.
I'm using a MontaVista cross-compiler for MIPS (Globespan IVR) and it
chokes on lines in the EHCI driver that reference
ehci_{dbg|err|info|warn} -- I don't know if it's unique to that
compiler or not. Alan's change solv
activity for a period of time. This is quite easy to see as I
>have distributed net running so my CPU usage is always near 100%.
>
>I have been seeing this behaviour for a while but seems easiest to reproduce
>when I do alot of IO over the USB.
At 3:23 PM -0700 7/10/02, Tom Collins
At 9:58 AM -0700 7/11/02, David Brownell wrote:
>Tom Collins wrote:
>>I'm working with some USB drives and trying to troubleshoot a few
>>problems. MIPS hardware, kernel 2.4.19-rc1 (for the EHCI driver).
>
>Out of curiousity -- big-endian or little-endian MIPS?
>(O
t port number am I
actually plugging into? It's not in the kernel messages, but my
serial console reported "hub.c: port 3 over-current change" followed
by "hub.c: port 2 over-current change".
Does the drive draw too much power to use
