Hello Alan again, we will clear things up. Sorry for the late reply, dark forces delayed us. > Intel probably doesn't care, because they don't make the affected > chipsets any more. I don't know what AMD is currently making. Do you? Yes we do. One of our ICH5 board uses ICH5 with SL7YC SL spec, meaning it is an embedded chipset with extended availability so they must care as it is paired with 865 and 875 series which are listed in http://ark.intel.com/#DesktopProducts-DesktopChipsets and http://ark.intel.com/products/27674/Intel-82801EB-IO-Controller for ICH5. For AMD read below. > I don't know. In my experience, 1000 iterations have been enough for > the bug to show up. But I have tested on only two computers. we have run it up to 2000 for peace of mind each time with a specific USB stick on 12 different EHCI USB hosts. On VT8235M it took ages to go to 1000. A human readable timestamp could be used. > What is A50M? It is an AMD southbridge codenamed Hudson-M produced this period and interestingly it is affected by the bug despite that SB700 and SB950 work fine. We have full docs for this chipset. To sum up printing a start up message to leave it run up to 1000 is necessary as well as a warning to stop it using control+Z in avoid to avoid dmesg spamming. Timestamps is another improvement and fixing the block count issue is the last one as on 2 controllers (moschip and SB850) the program exited immediately after initialization. First we must deal with those 2 controllers and check all hosts with the new version again. Since you prefer the logs with the current program, no problem. You will receive a message after this one with all the logs to keep you happy. Despite that, notice that when the program will be able to run on all hosts, we shall retest and resend the results. Are there any performance or reliability issues from this bug except the original DVB card detection problem? Will the workaround affect performance? -- 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
