[00:19] !ops [00:19] Help! lamont, zul, T-Bone, mdz, or jdub [00:20] !ops [00:20] Help! lamont, zul, T-Bone, mdz, or jdub [00:31] !ops [00:31] Help! lamont, zul, T-Bone, mdz, or jdub [00:35] !OPS [00:35] Help! lamont, zul, T-Bone, mdz, or jdub [00:38] elementofone: stop that please [00:39] !ops janc [00:39] !ops | JanC [00:39] JanC: Help! lamont, zul, T-Bone, mdz, or jdub [00:40] !ops | JanC \ [00:40] JanC \: Help! lamont, zul, T-Bone, mdz, or jdub [00:55] !ops | JanC \ [00:55] JanC \: Help! lamont, zul, T-Bone, mdz, or jdub === Guest32914 is now known as ogasawara === ogasawara is now known as Guest89782 [08:34] dsmythies, thanks for the update [11:45] How can one identify the kernel version from Linus git tree in comparison with the kernel.ubuntu.com/~kernel-ppa/mainline ? This does not help in my case (http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html_ [11:47] I can understand that 3.17-rc4 it's the same version as v3.17-rc4 (in Linus git), and 3.17-utopic = v3.17(in Linus git), but what about 3.17.1-utopic ? which version is this under Linus git ? [11:48] NikTh, That is the first stable release from upstream stable compiled with mostly the config from utopic [11:49] git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git [11:49] NikTh, as smb says, this is a stable update kerenl, it is therefore _not_ in linus' tree, it is in the stable tree [11:50] there ^ [11:50] NikTh, separatly each of those builds includes a COMMIT file which contains the tag/commit id which was used to build it [11:54] So, if one wants to bisect an rc kernel upstream, should clone the Linus git, but if wants to bisect lets say 3.17-utopic and 3.17.1-utopic should clone the stable git ? [11:54] yes the two tags you need are in there [11:55] and if the last bad kernel is rc-7 and the next good one is a stable, lets say 3.17-rc7 = the last bad one and 3.17-utopic = the first good one. [11:56] well those are both linus' releases, so they are in either [11:56] those versions literally represent v tags [11:56] Yes. Correct apw. Thanks [11:57] correct ? [11:57] The difference would be if the last bad one was , lets say 3.17-utopic and the first good one was 3.17.1-utopic, then one should clone the stable git. Correct ? [11:58] well yes, but you would never find that situation, as if you had v3.17-rc7 as bad and v3.17.1 as good, the next test would be v3.17 [11:58] moving you into one or the other [12:06] Lets say that the last bad kernel is 3.17-utopic and the exact following is the first good one (3.17.1-utopic). How one can reverse bisect ? From stable git ? Or this situation would never happen ? [12:07] stable yes, those tags are both in there [12:11] apw: Thanks for all the answers and explanations, this is the yet another time helping me :-) [12:12] smb: same too you [12:12] if you put a candidate for president and you need my vote, just let me know :P [12:14] heh .. [12:16] Oh, and a last one.. because I don't want to building kernels in vain... I have spotted the bad and good kernels. And I want to start bisecting. I want to build the bad kernel with the first commit from the good one.. will I do "git checkout COMMIT" and then start building ? [12:22] NikTh, doesn't "git bisect" offer you a sensible commit to bisect? [12:23] apw: Yes. It offers me a commit, but I want to build and test the kernel with this commit and particular I'm speaking about a reverse bisection. [12:24] it will have check that commit out when it selected it, iirc [12:24] I've read the wiki, but I'm afraid if I don't understand something.. so I'm asking to be sure. [12:28] apw: For starters, I did a "git checkout COMMIT" where commit is the offered commit from the bisection and I'm building the bad kernel with this commit. Is that right ? [12:29] my memory is the bisect itself checked out the suggested commit for you [12:31] Ok, but is there something wrong with the procedure I followed? I mean, the "git checkout COMMIT" breaks something maybe ? or building an incorrect kernel ? [12:31] if you were on that commit, the git checkout would be a noop [12:34] noop? sorry, what is noop ? you mean something unnecessary ? [12:58] a no-operation indeed [13:04] cking_, would you mind answering this one when you've a moment ? https://bugs.launchpad.net/bugs/1387144 [13:04] Ubuntu bug 1387144 in linux (Ubuntu) "why does linux-image-generic depend on thermald" [Undecided,New] [13:04] yup [13:11] cking_, it is possible that could be a recommended, so it would be uninstallable, but also remain installed by default, something to consider [13:12] I think that would be better, so users can chose to remove it [13:13] cking_, thermald does bail out on platforms for which it can do no good, right ? like virt instances, etc. [13:14] rtg, it does indeed [13:14] I should add that too to the bug report [13:16] making it a recommended is the best plan, this way users can remove it if thermald is too agressive for there liking and they like seeing their H/W shutdown when it gets too hot [13:30] As an addition thermald sometimes needs a special configuration in order to identify the components correctly. https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1367946 [13:30] Ubuntu bug 1367946 in thermald (Ubuntu) "thermald fails to start on AMD Phenom(tm) II X4 945 Processor" [Undecided,Confirmed] [13:34] rtg, apw, are you ok to make that change, or do you want me to? (I'm not upto speed with the packaging foo that's needed to do that) [13:35] cking_, you could certainly write the patch and send it on the list. [13:47] rtg, i'm not sure how the original change was made in utopic [13:47] cking_, debian.master/control.stub.in I think [13:48] yep, I grep'd for thermald in that in utopic, I can't see it [13:48] hmm, lemme check [13:49] cking_, its in the Utopic meta package [13:50] hrm, never futzed with that before [13:58] yeah that is actually on linux-image-generic meta package ... [13:58] cking_, that is more of a "normal" package so you have to edit changelog by hand, no insertchanges help [14:03] apw, hold on, I'm sucked into some phablety issue at the mo [14:03] cking_, np [14:39] hello everyone [14:40] stgraber: do you still have your hardware for bug #1104230? [14:40] bug 1104230 in xserver-xorg-video-intel (Ubuntu) "DisplayPort 1.2 MST support is missing in the Intel driver" [Undecided,Confirmed] https://launchpad.net/bugs/1104230 [14:48] stgraber: I have provided some kernel builds there for testing, unfortunately I have no hardware to test it by myself so I would appreciate any feedback, thanks! [15:01] apw, i fired up a vivid kernel to the kernel PPA. meta package to follow soon. If testing on various bits of kits seems OK then I'll dump it into the archive (after consulting infinity) [15:18] rtg, yeah we need some dkms testing i ugess, which is ... not working right now [15:19] apw, what better way to acquire some launchpad bugs :) [15:19] true we don't have very many right now === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr [19:03] tseliot, we've got a 3.18 based kernel for you to test your DKMS packages against in the kernel PPA === roadmr is now known as roadmr_afk === adam_g_gone is now known as adam_g === roadmr_afk is now known as roadmr [21:22] On ubuntu 14.04 host runing 3.13.0-24-generic kernel, Guests are freezing and I see "BUG: soft lockup - CPU#x stuck for 22s!" Anybody help me narrowing the issue? HW is Supermicro with Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz. I need anybody help. === hughhalf is now known as hugh_otp [21:47] JayJ bad hardware? [21:50] neoark: What I don't understand is that the host is running the same version of ubuntu and kernel. There are no issues with the host. However, teh guest running has all the issues. [21:51] And why this could ever happen ? Am I noob regarding the reverse commit bisect procedure ? Yes I am, but I've followed the procedure step by step. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386695/comments/23 [21:51] Ubuntu bug 1386695 in Linux "[3.16.0-23] Resume from suspend/hibernation, GPU lock - possible regression" [Medium,Confirmed] === hugh_otp is now known as hughhalf