| === AceLan__ is now known as AceLan | ||
| === shengyao__ is now known as shengyao | ||
| 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 | 08:42 |
| tjaalton | is the amd64 build of 4.4.0-9 stuck somehow? | 10:32 |
| tjaalton | https://launchpad.net/ubuntu/+source/linux/4.4.0-9.24/+build/9279168 | 10:34 |
| tjaalton | nah, done now | 11:13 |
| apw | tjaalton, was stuck indeed | 11:34 |
| tjaalton | ah | 11:34 |
| tseliot | apw: hey, would this be a good pull request? http://paste.ubuntu.com/15256740/ | 11:35 |
| tseliot | bjf: my work is complete, and applies cleanly, with zero conflicts ^ | 11:38 |
| tseliot | and it works well :) | 11:38 |
| 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:39 |
| 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:40 |
| apw | tseliot, i'd need to fetch it to see how impactful it is in !amdgpu | 11:41 |
| 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:42 |
| apw | tseliot, thanks indeed | 11:46 |
| 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 | 11:47 |
| === rcj` is now known as rcj | ||
| 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] | 15:49 |
| 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:04 |
| 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:10 |
| peat-psuwit_ | apw: I don't know what it's called. | 16:11 |
| apw | hrm, you would have to talk to the phonedations lot, and i am struggling to find out where they hang out | 16:12 |
| 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:15 |
| apw | peat-psuwit_, worth a shot indeed | 16:16 |
| 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:17 |
| bdmurray | apw: okay | 16:18 |
| 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:19 |
| leitao | rtg, replied to your comment. Thanks! | 16:33 |
| 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:35 |
| leitao | rtg, right. It might be a problem with the test. I will double check that | 16:36 |
| leitao | Thanks | 16:36 |
| 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:40 |
| rtg | leitao, I'm good with that :) I'm going to assume until otherwise notified that the bug is solved. | 16:41 |
| 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:32 |
| jsalisbury | jdstrand, ack, I'll take a look | 17:54 |
| jdstrand | jsalisbury: thanks! | 18:05 |
| jsalisbury | jdstrand, np. sorry that we have to use the upstream kernel for testing. | 18:06 |
| === shirgall is now known as Guest82093 | ||
| rtg | jderose, could you open a new bug regarding ureadahead ? | 19:13 |
| 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:15 |
| 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:16 |
| 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:17 |
| rtg | jderose, I'll try to remember to have a look tomorrow. | 19:18 |
| 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) | 19:20 |
| ngomes | hello , i have a question | 21:56 |
| apw | (just ask if you have a question) | 21:56 |
| 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 ? | 21:57 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| ngomes | that's ACPI , isnt that about power management ? | 22:15 |
| xnox | before one can power things on and off, one needs to configure and find them.... | 22:16 |
| ngomes | xnox, so kernel talks AML to ACPI in order to gather info about the hardware components ? | 22:20 |
| ngomes | ok, i get a better ideia | 22:23 |
| ngomes | thanks for all | 22:23 |
| ngomes | byebye | 22:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!