Alan Stern wrote:
No, I don't want to use it. It's too complicated for the relatively small advantage it offers.
Ok.
This all sounds very strange. Here's an idea. Add
unsigned char unused[32]; struct list_head remove_list_copy;
to the end of the uhci_qh structure. The remove_list_copy field will lie on a different cache line from the rest of the structure. Whenever the code uses or changes the value of remove_list, check first to see that remove_list_copy is equal to remove_list and then copy the new value of remove_list into it. Also, in free_pending_qhs() check whether remove_list.next points to itself.
Depending on what you see, we may be able to determine whether the problem lies in the hardware or in the software.
Ok. By the way, my test is over: - I have a 14h27 uptime, and still running no problem. - The checksum of the xxxxx times copied file is the same that the original one.
In the hardware would be faulty, the checksum would certainly have been diff.
Bye
------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
