=== AceLan__ is now known as AceLan
=== shengyao__ is now known as shengyao
[08:42] <apw> rharper, hrmm, no that just sounds odd to me normally they would be the same as even your first level ports are on a hub
[08:42] <apw> rharper, i would ask you to file a bug, and get straight to bisecting for it as it worked before
[10:32] <tjaalton> is the amd64 build of 4.4.0-9 stuck somehow?
[10:34] <tjaalton> https://launchpad.net/ubuntu/+source/linux/4.4.0-9.24/+build/9279168
[11:13] <tjaalton> nah, done now
[11:34] <apw> tjaalton, was stuck indeed
[11:34] <tjaalton> ah
[11:35] <tseliot> apw: hey, would this be a good pull request? http://paste.ubuntu.com/15256740/
[11:38] <tseliot> bjf: my work is complete, and applies cleanly, with zero conflicts ^
[11:38] <tseliot> and it works well :)
[11:39] <apw> tseliot, i am just going to assume you are jesting
[11:39] <tseliot> so, if that pull request is good, shall I paste it in the bug report or send it to the mailing list?
[11:40] <tseliot> apw: I didn't say it was just a couple of commits
[11:40] <apw> tseliot, so you are serious ... ugg, good in the sense it is properly formed, bad in the sense there is like 200 commits
[11:41] <apw> tseliot, i'd need to fetch it to see how impactful it is in !amdgpu
[11:42] <apw> tseliot, but if its what you need, sending it to the mailing list is your next thing ... but do add some "why" to the top of the pull request
[11:42] <tseliot> apw: ok, I am also going to complete the bug report, just in case
[11:46] <apw> tseliot, thanks indeed
[11:47] <apw> tseliot, though i man never invite you to meet my parents after this
[11:47] <tseliot> apw: am I detecting a hint of sarcasm? :P
[11:47] <apw> just a hint
[11:47] <tseliot> :D
=== rcj` is now known as rcj
[15:49] <rtg> leitao, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1481357/comments/13
[15:49] <ubot5> Launchpad bug 1481357 in linux (Ubuntu Xenial) "[LTCTest][Kernel][OP810]Ubuntu14.04.3: kernel call trace while continuously switching between smt on/off and changing subcores" [Medium,Fix released]
[16:04] <peat-psuwit_> Could anyone help with using backport tree? I ran ./gentree.py --integrate ... and it said "no such file or directory: <kernel-target>/backports/Kconfig"
[16:10] <apw> peat-psuwit_, i am not sure i know what gentree.py is for ?
[16:10] <peat-psuwit_> apw: like, in this one: https://github.com/ubuntu-phonedations/backports
[16:11] <peat-psuwit_> apw: I don't know what it's called.
[16:12] <apw> hrm, you would have to talk to the phonedations lot, and i am struggling to find out where they hang out
[16:15] <bdmurray> apw: Do you have an opinion on bug 1550719? My specific question is should usb-devices be in addition to lsusb or instead of?
[16:15] <ubot5> bug 1550719 in apport (Ubuntu) "Add output of usb-devices when ubuntu-bug linux or apport-collect'ing existing report affecting linux (Ubuntu)" [Wishlist,Triaged] https://launchpad.net/bugs/1550719
[16:15] <peat-psuwit_> apw: Ok, Thank you. I guessed they might be in #ubuntu-touch. I'll try to ask there.
[16:16] <apw> peat-psuwit_, worth a shot indeed
[16:17] <apw> bdmurray, if the upstream maintainers are complaining we have something missing in our bug reports it seems reasonable to add it, we're uploading a ton of stuff already i am sure it will not make the size any different; someone would want to check that file is password freee, bit i expect it to be so
[16:18] <bdmurray> apw: okay
[16:19] <apw> yeah reading the rest of the commentary it seems that this is not expected to have private info in it, so that sounds fine, i wonder if lsusb is any use with that attached, but one problem at a time :)
[16:33] <leitao> rtg, replied to your comment. Thanks!
[16:35] <rtg> leitao, I'm pretty sure we have not changed how the initrd is built, so I'm wondering if the tester actually installed both kernel packages.
[16:36] <leitao> rtg, right. It might be a problem with the test. I will double check that
[16:36] <leitao> Thanks
[16:40] <leitao> rtg, yea. It seems that they wish to have something that never existed in 3.19, which means that this is NOT a regression. 
[16:41] <rtg> leitao, I'm good with that :) I'm going to assume until otherwise notified that the bug is solved.
[17:32] <jdstrand> jsalisbury: fyi, I left feedback for bug 1547619
[17:32] <ubot5> bug 1547619 in linux (Ubuntu Xenial) "Intermittent screen blinking with 4k external mini display port with 4.4 kernels" [Medium,In progress] https://launchpad.net/bugs/1547619
[17:54] <jsalisbury> jdstrand, ack, I'll take a look
[18:05] <jdstrand> jsalisbury: thanks!
[18:06] <jsalisbury> jdstrand, np.  sorry that we have to use the upstream kernel for testing.  
=== shirgall is now known as Guest82093
[19:13] <rtg> jderose, could you open a new bug regarding ureadahead ?
[19:15] <jderose> rtg: after looking into it more, i don't think there's an issue... the warnings about relative paths seem expected, even though there are a lot of them these days
[19:16] <jderose> rtg: but if it seems like there is a new bug, i'll definitely file a bug :)
[19:16] <rtg> jderose, I haven't looked in awhile. Is there actually valid ureadahead info being generated ?
[19:17] <jderose> rtg: i'm not 100% sure about that, it's a bit hard to tell from the logging. currently my theory is valid entries are being generated, but that there are (for whatever reason) a lot more relative paths that are getting ignored during the scan
[19:18] <rtg> jderose, I'll try to remember to have a look tomorrow.
[19:20] <jderose> rtg: this caught my attention at first because there are so many ureadahead warnings in syslog, but maybe their expected, dunno
[19:20] <rtg> jderose, I haven't touched it since Ubuntu was concerned about boot speeds (which has been a few releases)
[21:56] <ngomes> hello , i have a question 
[21:56] <apw> (just ask if you have a question)
[21:57] <ngomes> as far as my understanding from linux,  the hardware devices are probed from the kernel in order to load apropriate driver. my question is : as far as hardware is probed , wouldn't it be faster to write to a file the hardware , than to always probe hardware every single boot ?
[22:10] <xnox> ngomes, .... you are assuming kernel has a device to read a file from.
[22:10] <ngomes> xnox, i know few about kernel , just wondering
[22:10] <xnox> does not scale, cause hardware is different each time one boots, or even resumes from suspend/hybernation
[22:10] <ngomes> how is different ?
[22:11] <xnox> and it often needs to be re-initialised, in a device specific manner.
[22:11] <ngomes> i dont see any load module when i resume from suspend
[22:12] <ngomes> at least, at dmesg
[22:12] <xnox> ngomes, usb devices attached/detached missing, firmware updates changing how hardware is seen, bios updates changing properties as to what sort of things stuff depends on.
[22:12] <xnox> in bios a user can go and change which things are available/visible/enabled, etc.
[22:13] <xnox> it really is a different world each time. And probing, and loading things on demand is often faster than disk-io reading caches =)
[22:13] <ngomes> would give a load error, no problem ?
[22:13] <ngomes> hmm ok
[22:14] <ngomes> i really don't know how probe works , so yeah , overall might be faster
[22:14] <xnox> ngomes, https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface
[22:15] <ngomes> that's ACPI , isnt that about power management ?
[22:16] <xnox> before one can power things on and off, one needs to configure and find them....
[22:20] <ngomes> xnox, so kernel talks AML to ACPI in order to gather info about the hardware components ?
[22:23] <ngomes> ok, i get a better ideia
[22:23] <ngomes> thanks for all
[22:23] <ngomes> byebye