=== mwsb is now known as chu
[01:44] <codepython777> I have a wierd usb problem on 16.04.3 + Intel Nuc + a USB 3 device. I've tried many things. If anyone is familiar with debugging this chain, I could use some help.
=== JanC_ is now known as JanC
=== JanC_ is now known as JanC
[13:07] <codepython777>  I have a wierd usb problem on 16.04.3 + Intel Nuc + a USB 3 device. I've tried many things. If anyone is familiar with debugging this chain, I could use some help.
[13:09] <apw> codepython777, hard to say without some symptoms, if you have a bug or something maybe someone here might have some suggestions
[13:11] <codepython777> hi apw
[13:12] <codepython777> I've a intel nuc on which I am running 4.13.10 - My problem is, one of the devices (A USB 3 SDR) does not show up at boot, and i see a lot of usb errors in dmesg. But when I pull and push it back physically, it works
[13:12] <codepython777> [    7.803149] usb 1-2: device descriptor read/64, error -110 --> dmesg keeps showing these errors till around 60 seconds of boot
[13:13] <codepython777> [   56.316639] usb 1-2: new high-speed USB device number 5 using xhci_hcd  --> [   61.572926] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[13:14] <apw> so works when attached after boot and not if attached on boot
[13:14] <apw> probe ordering perhaps, usb3 is all a bit of a mess the way they did the backwards compatibility
[13:15] <apw> likely those errors are timeouts as they are -110
[13:15] <apw> i thought xhci_hcd was usb2
[13:17] <apw> what is attached to it when you pull and reinsert it
[13:20] <codepython777> apw: let me show you dmesg again
[13:21] <codepython777> apw: https://paste.ubuntu.com/25830301/ - now even push/pulls dont work well
[13:21] <codepython777> physical push pulls do activate the SDR though
[13:21] <codepython777> apw: usb 2-2 should be usb 3
[13:23] <codepython777> apw: I think you are right xhci is usb2 - this device is usb 3 - Even the keyboard and mouse on this machine take time to connect
[13:29] <apw> when usb2 was new the order in which the devices probed mattered, and if you had usb1 builtin and usb2 as a module it would do the wrong thing
[13:29] <apw> i wonder if this is something similar
[13:29] <apw> codepython777, has this ever worked before, befreo 4.13 for instance ?
[13:30] <codepython777> yes, it used to work on ubuntu 16.04 default kernel - and an older intel firmware
[13:31] <codepython777> intel does not let you downgrade the firmware, and now it breaks the whole system
[13:31] <codepython777> apw: when it worked, it would give errors, and connect at boot after 60 seconds
[13:31] <apw> so if you boot back into an older kernel does it still not work
[13:31] <apw> that is probabally less working, and more working by luck for sure
[13:31] <apw> but perhaps if we can find out when it stopped working (assuming it still works with the old kernel)
[13:32] <codepython777> apw: now it does not work on any kernel between 16.04 default and the latest stable
[13:32] <apw> the what made it worse commit might tell us something
[13:32] <apw> ok so they "fixed your firmware" nice
[13:32] <codepython777> we cant make it work. Intel's nuc dont have older firmware now 
[13:33] <apw> ok do you have a bug filed, so we have something to track this on, as we might be able to get some help
[13:33] <codepython777> apw: It would be nice to get the bottom of the issue
[13:33] <codepython777> apw: no, I am not sure where to file it. Intel tells me they dont support ubuntu.
[13:33] <codepython777> or linux
[13:34] <codepython777> when i pull and push the usb for the device, I see xhci_hcd on the dmesg - isnt that a problem? This is a usb 3 device
[13:35] <apw> you'd want to check if usb3 is really different, or just a variant of xhci_hcd
[13:35] <apw> if it is different you could try modprobing the usb3 driver manually then shoving it in
[13:35] <apw> and see if that changes anythign
[13:35] <apw> but regardless, file a bug against linux in ubuntu, and let us know the number here, and maye
[13:35] <apw> and maybe, just maybe, we can get some help with it
[13:36] <codepython777> apw: can you point me to the right url to post the bug?
[13:36] <apw> run 'ubuntu-bug linux' from a terminal
[13:39] <codepython777> apw: thanks
[16:51] <hallyn> apw: I have lvm issues.  anyone in particular you'd recommend talking to? :)
[16:51] <apw> hallyn, point us to the bug and we'll figure something out
[16:51] <hallyn> in particular, I use qemu-nbd to hook up a file;  pvcreate/vgcreate/lvcreate on /dev/nbd0p2; detach,
[16:51]  * hallyn scratches his head
[16:52] <hallyn> ok.  
[16:52] <hallyn> i'm still working on reproducing, trying to figure out what's reasonable and what's not;  but i'll opena  bug with my scripts.
[16:54] <hallyn> ah, - doing dmsetup remove of the lvthin devices *in the right order* helps to recover at least
[16:56] <hallyn> so fragile
[17:10] <jsalisbury> slangasek, I've gotten no further on your bug and am confused by that merge.  I'm going to send out an email with git questions to people that know git better than me.  I'll cc you
[17:12] <slangasek> jsalisbury: fair enough; meanwhile I am iterating my own bisect as I described, which consists of rebasing the tty branch on top of trunk at each iteration
[17:13] <jsalisbury> slangasek, ack.  I've never run into a reverse bisect like this before
[17:15] <hallyn> hm.  16.04 works (with kid-gloves on) on physical hardware, fails inside vmware.
[17:15] <hallyn> Well I guess I"ll still file it as a bug, though i'm starting to thin kit's a vmware bug.
[17:21] <hallyn> apw: bug 1728109 
[17:21] <ubot5> bug 1728109 in linux (Ubuntu) "nbd ( + lvm thin pool?) fragile" [Undecided,New] https://launchpad.net/bugs/1728109
[17:21]  * hallyn bbl
=== JanC_ is now known as JanC