On Mon, 31 Mar 2014, Peter Münster wrote: > On Mon, Mar 31 2014, Alan Stern wrote: > > > That's totally crazy. With wakeup enabled, the commit should have had > > no effect at all. > > Hi Alan, > > With 0aa2832dd0d9d860 kernel, the freeze happens only when something is > connected to the rear port. > > But with later kernels (>= 3.11), the freeze happens also without > anything connected to the rear port. So maybe we're talking about more than one bug. I thought you had posted a log showing 3.12 working with no reversions and everything plugged into the front, but my memory must be wrong. > (See also here: > https://bugzilla.novell.com/show_bug.cgi?id=868315#c12 ) > > > > Here's another diagnostic patch to try (use it along with the first > > one). Do the same test, i.e., only the keyboard in a rear port. This > > patch effectively reverts commit 0aa2832dd0d9d860 and instead, prints > > out information showing what the commit would do. > > Please find attached 3 files: > > - messages-1.log: wake-up ok, but problem with nouveau or cpu. > I guess, it was just bad luck and this has nothing to do with usb. > I've had a similar lock-up already with 3.7 kernel. > > - messages-2.log: this time without X-server > > - messages-3.log: with X-server (and no lock-up this time) These all seem to be basically the same, apart from the Nouveau issue. This suggests that the previous test (i.e., without the new diagnostic patch) would have worked if _nothing_ was plugged into a front port and the keyboard was plugged into the rear port. Can you try that? Also, I'd like to track down the problem when both devices are plugged into front ports. Can you try that as well, again without the new diagnostic patch? If the problem in this case is caused by a separate bug then we may not learn anything, but it's worth a try. > > (By the way, the first diagnostic patch did provide interesting > > information. Maybe you noticed: The frame values were _not_ changing!) > > Yes. I guess that means, that the usb-hub did not wake up? So it seems. This evidently is a problem in the hardware, and the final fix will have to work around it. Probably I'll end up adding code to ohci-hcd that will cancel out the effect of 0aa2832dd0d9d860 on all systems having that type of OHCI controller. Please provide the output from "lspci -v -s 12.1" and "lspci -v -n -s 12.1". Alan Stern -- 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
