On Wed, 22 Feb 2006, Thomas Thanner wrote:
> Thanks for taking the time to look at our problem.
>
> Please send us the patch, so we can check with this Version.
The patch is below. You should build it with CONFIG_USB_STORAGE_DEBUG
turned off so that you get only the messages from the patch, without all
of the other debugging messages.
> Maybe this is a hardware problem. Meanwhile I have seen the same thing when
> using an USB 1.1 memeory stick (definitely working in a lot of other
> computers) on this particular server.
But a USB 1.1 device would not use the EHCI controller, and you said
earlier that without ehci-hcd loaded everything worked okay.
> Is there a slight possibility that the trouble comes from the really high
> speed machine we are using? It is a hyperthreaded dual processor XEON 3GHz (4
> CPUs reported) with 4 GByte RAM installed. When doing the tests no other load
> is on the machine.
I suppose it's possible, although I don't see how. The controllers have
their own clocks, because the USB bus has to run at a fixed rate
regardless of the processor's speed.
Can you tell Linux to use only one processor with no hyperthreading (maybe
build a UP kernel) for purposes of testing?
> I almost don't dare to say it, but when we install Windows 2000 / SP4 on that
> server everything works just fine. Bu we definitely have to get Linux running
> stable on that machine, using all the peripherals that are in there (we have
> similar problems with a DVDRAM drive coupled over IDE bus in this server, but
> that's another story).
>
> Is there a possibility that "the others" have some workarounds included into
> their drivers to overcome such hardware quirks?
I have no idea what workarounds are included in the Windows drivers.
You'd have to ask someone at Microsoft.
> Is it possible that most of PC hardware works only because software drivers
> tolerate their faults and retry in some way?
Well, not "most" -- but certainly some hardware is like that.
> I agree that there might be a hardware problem. But sometimes software has to
> correct were hardware fails. Maybe we can implement some of these workarounds
> here, too?
The drivers already include such workarounds, for all the problems we know
how to fix.
Alan Stern
Index: usb-2.6/drivers/usb/storage/transport.c
===================================================================
--- usb-2.6.orig/drivers/usb/storage/transport.c
+++ usb-2.6/drivers/usb/storage/transport.c
@@ -679,8 +679,11 @@ void usb_stor_invoke_transport(struct sc
return;
}
- US_DEBUGP("-- Result from auto-sense is %d\n", temp_result);
- US_DEBUGP("-- code: 0x%x, key: 0x%x, ASC: 0x%x, ASCQ: 0x%x\n",
+ printk(KERN_DEBUG USB_STORAGE
+ "OP 0x%x -- Result from auto-sense is %d\n",
+ old_cmnd[0], temp_result);
+ printk(KERN_DEBUG USB_STORAGE
+ "-- code: 0x%x, key: 0x%x, ASC: 0x%x, ASCQ: 0x%x\n",
srb->sense_buffer[0],
srb->sense_buffer[2] & 0xf,
srb->sense_buffer[12],
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
