On 18/03/11 20:19, Greg KH wrote:
On Fri, Mar 18, 2011 at 12:09:31PM +0000, Richard Senior wrote:
OK, so I've completed the git bisect:
$ cat .git/refs/bisect/bad
a1e8fad5900fa94adb500c6e0dfd60a307f7a3c9
Really? Do you have CONFIG_TRACE enabled? If not, that patch should
have no affect on your system.
Thanks.
I don't think so.
If you do have it enabled, this change causing a lack of USB device
connection seems very strange, and I really don't understand what is
going on.
If you manually revert that patch, does your problem go away?
I have checked out the "bad" revision with:
$ git checkout -f a1e8fad5900fa94adb500c6e0dfd60a307f7a3c9
Then I've rebuilt the kernel with those sources and confirmed that I get
the -110 error in syslog when running it. Other symptoms are that 'fdisk
-l' doesn't show the device and lsusb hangs while the device is enabled
and plugged in.
I kept my last kernel from the git bisect (which was a "good" one) and
just re-confirmed that the device comes up as /dev/sdb1 in fdisk -l,
lists the device correctly with lsusb and I can mount it successfully
and read the filesystem.
Is that kernel (the last entry in 'git bisect log') going to be the same
source as reverting that patch? Or do I need to do a diff to get that?
Or can I download that patch file from somewhere?
When I finished the bisect I did run a 'git diff' between the "bad"
source and the last entry in the 'git bisect log' and I did see changes
related to ehci-ecd so I was optimistic that I'd got a good result. But
I'll freely admit that I don't fully understand how the kernel commits
work and don't know whether that diff was worthwhile.
--
Regards,
Richard
--
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
