I noticed that when I download file with wget, the transfer stops for 1 second 2 or 3 times before usb will finally hang. With usb hard drive usb hangs sometimes on plugin, sometimes it will initialize Ok, mount ok and hang at beginning of file copy. What I learned fast usb 1.1 devices use bulk/iso transfers where bulk transfers are the most popular. Slow usb devices use different transfer. So if slow devices are ok this means there must be problem with bulk. The question is if this is chipset design bug or linux ohci driver has bug causing problems on multicore/fast cpu. Windows XP SP3 works with default OS ohci usb drivers. If there would be bug in chip design Nvidia would provide filter driver for usb (like VIA provided viausb.sys in ancient days). Because Windows XP SP3 works with default OS ohci usb drivers the hardware/chipset design is OK. So problem lies in Linux ohci driver. The noapic or acpi=noirq may suggest problem inside bios/acpi code. But if none of interrupts are shared and every other piece of hardware works great in Linux can I still blame this part of code? Because usb hang only happens during fast, big bulk transfers can you please tell me what parts of usb ohci driver (kernel 2.6.30.1) I should modify to slow down usb transmission in bulk mode? I think extending queues and adding delay/wait/sleep commands before ohci controller I/O commands could make usb bulk transmissions less aggressive for chipset which may hang because data overload. If you know how to do that can you please show me example patch? have a nice day, Zbigniew Luszpinski -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
