On Tue, 4 Oct 2005, Yedidyah Bar-David wrote: > On Tue, Oct 04, 2005 at 10:46:32AM -0400, Alan Stern wrote: > > On Tue, 4 Oct 2005, Yedidyah Bar-David wrote: > > It could be that the regression was caused not by a single change, but by > > a large collection of changes that, taken together, altered the timing of > > the computer. > > Are you sure it's only timing? If so, I can add printk's or some other > simple thing to let me time things, and see the differences. Or would > that be too inaccurate?
No, I'm not sure. That was just a guess. Comparison of the logs would help, because it would show if there was a difference in the commands being sent, as opposed to a difference merely in their timing. > > > What should be my next step? > > > > I don't know. You could try binary dissection on the individual patches > > between -rc1 and -rc2. Here's a URL that has a list of all of them (plus > > a lot more, if you let the transfer go all the way): > > > > http://linux.bkbits.net:8080/linux-2.6/[EMAIL PROTECTED]|tags > > > > I am a complete ignorant regarding bitkeeper. Are they ordered in the > order they were applied? Yes. Or rather, the reverse order -- from latest to earliest. > If I am not mistaken, that's 274 changesets between rc1 and rc2. If I > understand right, doing a binary search will only take me around 9 > kernel compilations to find the point it stopped working. Am I wrong? Is > it considered ok to download all these 274 in a row? IIRC it was > questionable, at least on a larger scale. I didn't count them, but 274 sounds about right. Downloading all 274 patches shouldn't annoy anyone. (That's a lot of downloads to do by hand, though! Maybe you can automate it somehow.) And yes, you're right that binary search should narrow it down after no more than 9 attempts. > > It would be a lot of work, though. I don't know any way to get a simple > > file containing all those patches. It might be possible using git. > > I might look at git if I have time. It's up to you. > > I can't access any of these logs: Error 403. > > I don't know why. It does seem to work now. Can you try again? It's working now. The logs for the card reader show everything working correctly. The difference between the two is that in the "nonworking" log, the kernel apparently keeps trying to access the reader. In fact it's not the kernel doing that at all; it's a user program, probably hald. If you would turn off hald then those messages would stop. The same is true for the two pen logs. But it's hard to be sure, because the "working" log doesn't show you actually doing anything with the pen drive (like mounting it). It only shows the device being connected and disconnected. Maybe if hald was running and you mounted the drive and tried doing something with it, then it would fail in the same way. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
