=== JanC_ is now known as JanC
=== gerald is now known as Guest90495
[09:50] <alkisg> Hi, I have an i5 PC that half of the times doesn't see the usb devices at all, doesn't even power them up. Ubuntu 12.04 32bit with the lts-trusty kernel.
[09:51] <alkisg> Should I try with some newer kernel?
[09:51] <apw> alkisg, sounds like you should file a bug against the kernel, and we can suggest kerenls to try indeed
[09:52] <alkisg> I have the pc here at the support office, so today I'm able to try sthings, while later on I'll have to send it back and it'll be difficult to provide more feedback at the bug report...
[09:53] <alkisg> ...so while I understand that a bug report is the proper thing to do, in this case IRC might help more than a launchpad bug... and of course I can file it for reference if I find a workaround...
[09:53] <alkisg> Is there any usb-related modprobe/rmmod that I can do?
[09:53] <alkisg> To try to reload the usb devices?
[09:57] <apw> alkisg, well file the bug so we have somewhere to ram logs etc
[09:57] <apw> alkisg, and i'd say we want a dmesg and lsusb at a minimum from the broken state
[09:58] <apw> alkisg, so like file a bug from the machine with it "ok" and then get it into the bust state and get the dmesg and lsusb and attach those
[09:58] <smb> While irc may work quicker for you it is not helping in coming up with advice. Not working half of the time is rather vague and obscure. Generally you could try to figure out whether when not working the usb controllers can be initialized by checking dmesg for usb messages.
[09:58] <apw> alkisg, so we can see the difference
[09:58] <alkisg> I'm at the broken state now, please give me a moment to explore...
[09:58] <alkisg> Thank you btw
[09:58] <apw> alkisg, and then i would recommend trying a v3.19.1 kernel from the mainline archive to see if this is fixed in mainline "near tip"
[09:58] <alkisg> Gotcha
[09:58] <apw> https://wiki.ubuntu.com/Kernel/MainlineBuilds
[09:59] <apw> and if that is relaible we can look at finding out when it got fixed
[10:02] <alkisg> echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/unbind
[10:02] <alkisg> echo -n "0000:00:14.0" | tee /sys/bus/pci/drivers/xhci_hcd/bind
[10:02] <alkisg> ==> allowed me to make the keyboard and mouse work without reboot
[10:03] <alkisg> I'll test first to see how reproducible it is here (the user reported half of the times, just want to check if it is indeed frequently reproducible...)
[10:04] <smb> which shows one missing piece of information is that we are talking about usb3 ports... are there still usb2 ports available. You could try to see whether devices connected there are more reliable
[10:04] <smb> alkisg, ^
[10:05] <apw> alkisg, right, so what we really care about is why it failed the first time ... as it clearly can connect both "working" and "broken"
[10:05] <apw> and that would be visible per
[10:05] <apw> perhaps in the differnce in a good and bad dmesg
[10:08] <alkisg> None of the ports give power to the mouse
[10:08] <alkisg> (collecting more info, patience please and thanks again for the help...)
[10:08] <infinity> zequence: Want to get smoketesty on your kernels so they're ready to go when the rest are?
[10:10] <alkisg> At the broken state: # lsusb -v > lsusb
[10:10] <alkisg> Couldn't open device, some information will be missing
[10:10] <alkisg> Couldn't get configuration descriptor 0, some information will be missing
[10:12] <alkisg> After entering the two "echo" commands, lsusb -v no longer complains
[10:12] <alkisg> Installing a newer kernel...
[10:24] <alkisg> It didn't happen with 4 rc4 in 4 tries... I'll try more tomorrow, thank you guys
=== alkisg is now known as work_alkisg
=== txspud is now known as txspud|ORS
[15:56] <jsalisbury> **
[15:56] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:56] <jsalisbury> **
[16:35] <crshman> Hey Guys, not sure who to notify or if this is the right place, but it looks like the drm-intel-nightly builds stop going through aroudn 3/11
[16:35] <crshman> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/BUILD.LOG
[16:35] <apw> crshman, yep ... looking at it right now as it happens
[16:36] <crshman> ok cool, just wanted to bring it up so it gets some eyes
[16:36] <crshman> I follow that build very closely for intel fixes :)
[16:36] <apw> not that close if it has been broke since the 11th :)
[16:37] <crshman> :P
[16:37] <crshman> I upgrade with that kernel once a week
[16:55] <jsalisbury> ##
[16:55] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:55] <jsalisbury> ##
=== work_alkisg is now known as alkisg
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ## Meeting starting now
[17:00] <jsalisbury> ##
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues March 24th, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes.
[18:06] <apw> crshman, ok i think those builds are repairing self now, and should be done in the next hours
[18:06] <crshman> @apw awesome thanks!
=== alkisg is now known as work_alkisg