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? > > > 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? 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. > 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. > > Also, you should post debugging logs showing the difference between -rc1 > and -rc2. I will. > > > logs: > > As mentioned, all of them done with 2.6.14-rc3, config at > > <http://www.cs.tau.ac.il/~didi/usb/config-2.6.14-rc3> > > > > All created by doing 'dmesg -c >> log' once a second, from before > > plugging in to after plugging out. > > > > dmesg of the working machine, while plugging in and out the card reader: > > <http://www.cs.tau.ac.il/~didi/usb/wcr> > > working machine, plugin/out the pen: > > <http://www.cs.tau.ac.il/~didi/usb/wpen> > > > > non-working, card reader: > > <http://www.cs.tau.ac.il/~didi/usb/nwcr> > > The card reader does work - that is, I can mount it and copy from it. > > But unlike in the working machine, the kernel continues to try doing > > something and outputs lots of stuff during that. > > > > non-working, pen: > > <http://www.cs.tau.ac.il/~didi/usb/nwpen> > > I noticed (by doing cat /proc/partitions) that it does manage to see the > > device for a few seconds (probably at the time it says in the logs 'sda1 > > sda3'), then looses the connection. > > 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? -- Didi ------------------------------------------------------- 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
