| Summary: | kernel-3.10.7 Unable to enumerate USB device on port... | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alex Weiss <gg.alex.weiss> |
| Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Alex Weiss
2013-09-11 07:13:33 UTC
*** Bug 484558 has been marked as a duplicate of this bug. *** Please try the latest sys-kernel/git-sources first before proceeding with the rest of this comment to ensure the problem hasn't already been fixed. Okay, so we know that before 3.8 it worked and somewhere in 3.8 it broke. That are a ~15000 commits that happened between those moment, figuring out which commit did with that amount of commits can take some item. That would require you to build 13 kernels or so and test all of them to find the bad commit. But that's the entire kernel, if we focus on the changes happened to the drivers/usb/ directory (which contains EHCI and relevant files) we we get ~400 commits, which leaves you with 8 or 9 tries to find the bad commit. So, I would suggest you to follow http://wiki.gentoo.org/wiki/Kernel_git-bisect but instead of the start bisect there you will want to do: `git bisect start vBAD vGOOD -- drivers/usb` Here you replace BAD and GOOD by the versions you know are bad and good, eg: `git bisect start v3.8.13 v3.7.10 -- drivers/usb` (Assuming v3.7.10 is confirmed to work and v3.8.13 is broken) I haven't found related reports on a report and the log contains a bit too much commits to get a guess at which commit might be bad; so, I would appreciate it if you could do a git bisect to find the bad commit. (In reply to Tom Wijsman (TomWij) from comment #2) > Please try the latest sys-kernel/git-sources first before proceeding with > the rest of this comment to ensure the problem hasn't already been fixed. > > [ ... See rest of comment #2 too ... ] (In reply to Tom Wijsman (TomWij) from comment #3) > (In reply to Tom Wijsman (TomWij) from comment #2) > > Please try the latest sys-kernel/git-sources first before proceeding with > > the rest of this comment to ensure the problem hasn't already been fixed. > > > > [ ... See rest of comment #2 too ... ] I recently upgraded to 3.10.7-r1. For a while, all was going well, but now the same problem has come back. I know it's not the hardware, either, as it often goes away after I compile a fresh kernel. It's frustrating as I never know when to expect it and when not to. Sorry if I am not able to be more helpful at this stage. Best, Alex Hmm, is an external USB hub or device perhaps faulty? If it doesn't happen often; then yes, a bisect is not really possible that way. Please let us know if this is still an issue with later kernels or if you attempted the bisect request awhile ago. Sorry for not getting back to everybody on this. The problem seems to be resolved with more recent kernels. I'm not sure what the problem was. |
