=== gerald is now known as Guest62191 === gerald is now known as Guest56030 === BruceMa is now known as BruceMa-afk === BruceMa-afk is now known as BruceMa [07:17] hallo [08:09] * smb waves tiredly [09:53] Is there issues with doing a bisect b/w 3.11 & 3.13 kernels ? [09:53] I mean will a bisection work between 11 & 13 ? [09:55] For mainline/upstream: maybe. [09:57] smb: yeah, it's for the mainline [09:58] caribou, It probably works but can't you just go for a mainline 3.12 manually and then decide [09:58] ? [09:58] (which is what bisect would probably do anyways) [09:58] smb: yeah, that would be better indeed [09:59] smb: thanks, will do that [09:59] caribou, I usually take the mainline builds as first approximation (the RCs, too) [09:59] Unfortunately most of the time its in -RC1 [09:59] But at least that reduces your bisect to between last release and next -rc1 [10:04] cking, apw, Btw, I just happened to stumble over "[PATCH V2] Change ACPI IPMI support to "default y"" on the acpi mailing list today. It will not be a stable change but maybe its worth thinking about it for T anyway... [10:04] smb, thanks for that, I'll look at that later today [10:06] cking, ok. To me it looks sensible enough. But its always better to have a second opinion [10:06] ;) [10:09] it certainly looks sane to me [10:37] smb, where did you stumble over that, it has to be old [10:38] apw, on the acpi-devel mailing list and for me it looks to be sent yesterday around 5pm [10:38] oh missread what you said, thought you were saying it was mine [10:38] No, no. Not at all [10:41] smb, ok we have all of those =m so at least they exist [10:42] mjg59, does your latest patch for the IPMI bits imply you can need them before it is possible to load modules [11:14] hi, I have a question on configuring the kernel [11:15] I need to set the UART for debugging purpose, and that can be done using setting CONFIG_OMAP_LL_DEBUG_UARTx=y...but I can't find this option. [13:38] hvn2, i cannot find anything which even smells similar to that in any of the kernels i am looking at ehre, no [13:38] what makes you think you need to set that, ie. what docs are you reading [13:42] hi, i am on ubuntu and i would like to build my current kernel from source. my machine has version 3.2.0-41-generic on it. so i tried apt-get source linux-image-`(uname -r)`. but this downloads the original kernel source and 3.2.0, and then patches it to a version ahead of -41-. it patches it to version -46-, is there any way to get the source for exact same kernel version? === Trevinho_ is now known as Trevinho === Guest78972 is now known as fmasi [14:08] dslr, the source for older versions of the kernel are not in the archive, you can get them from either the +source page for linux or from our git repository [14:10] https://launchpad.net/ubuntu/precise/+source/linux/3.2.0-41.66 for that _very_ old version you are running [14:19] apw: thanks. yeah i know it is quite old version. have to live with it. :) [14:21] dslr, dare i ask why you cannot run the latest [14:22] apw: from what I find about current kernels, it's completely gone. Most likely due to the not-use of the legacy uart. [14:23] apw: work related, it is not my machine and we have dependencies on plenty of other source code that will have to be upgraded. [14:34] I have a DL460g8 where kdump doesn't work (kernel seems to hang before init get called). We tested with 3.13 mainline + kdump-tools and it works fine [14:35] now we will test with the ubuntu specific 3.13 from Trusty to see if it continues to work. [14:35] then we want to do a bisection. should we do the bisect with the mainline kernels or with the ubuntu specific ? [14:35] given that the ubuntu specific 3.13 does work [14:36] otherwise, the delta will be b/w ubuntu 3.13 & mainline 3.13 [14:36] am I making any sense ? [14:37] caribou, you really want to bisect the mainline kernel 'cause the Ubuntu kernel commit history is not linear [14:38] rtg: this is what I wanted to know, thanks rtg [14:39] rtg: so it it worth to test the Ubuntu specific 3.13 then to see if kdump still works ? [14:40] rtg: if the delta is b/w ubuntu 3.13 & mainline 3.13 is it possible to bisect ? [14:52] caribou, that bisect might be more difficult because of packaging and ABI issues. if Ubuntu 3.13 doesn't work, then maybe we can just eyeball the Ubuntu specific code commits. [14:53] rtg: no, 3.13 mainline works fine, it's either b/w 3.11 & 3.12 or b/w 3.12 & 3.13 we need do to one last test to narrow it down [14:54] rtg: i.e. test with 3.12 mainline [14:54] rtg: ah, sorry just realized you were talking about Ubuntu 3.13 [14:55] rtg: but I'll remember the eyeball part :-) [14:56] caribou, the other big difference is that Ubuntu 3.13 is based on stable 3.13.3 whereas mainline is vanilla 3.13 (I think). apw could answer that for sure. [16:07] apw: It's certainly possible [16:08] apw: Any _INI method could refer to an IPMI opregion [16:13] ppisati, ping [16:14] ppisati, around asquare atriangle ? [16:17] I'm trying to pick the best time for customers to try out 14.04 pre-release for testing purposes. If we might end up going with the 3.14 kernel I'd prefer to wait for that to land. [16:19] I'd hope to do something before the Final Beta. Any suggestions? [16:22] gQuigs, we are definitely releasing 14.04 with a 3.13 kernel. [16:25] rtg: thanks! Then I'm thinking about suggesting customer testing around March1st, any objections? [16:27] gQuigs, it seems pretty stable right now, so March 1 ought to be fine. [16:28] rtg: awesome, thanks [16:32] manjo: no [16:34] ppisati, hello, you remember we put in a one line patch to saucy to fix serial console on guest iamges? there is supposedly a patch landing upstream that fixes that [16:34] manjo: yep, can you point me to the new patch? [16:35] yes I will .. just wanted to give you a heads up that that is happening === cyphermox_ is now known as cyphermox [16:37] ppisati, emailed you [16:41] manjo: k [17:01] hi all. I have eth0 on int 19, and all interrupts are processed by core0, which is getting rather hot with >10k interrupts/s. I've set smp_affinity to 0f, having 4 cores, but it's still stuck at core 0. any idea why? [18:03] RoyK, it may be only connected to that one cpu [18:06] apw: problem is, it works if I pin it to another cpu, but if I set affinity to f (4 cores), it stays at core0 [18:08] isn't that what it is supposed to do ? keep the caches populated ? [18:09] well, when one core is at 95%+, it should move those interrupts imho [18:10] rtg: also, by default it seems to pin both NICs on core0 [18:37] sforshee: hey [18:37] sforshee: I'm seeing this again: http://pastebin.ubuntu.com/6961321/ [18:39] looks like this https://bugzilla.kernel.org/show_bug.cgi?id=69051 [18:39] bugzilla.kernel.org bug 69051 in network-wireless "iwlwifi 0000:01:00.0: fail to flush all tx fifo queues Q 2" [Normal,New] [19:34] arges: what kernel/firmware versions? [19:35] sforshee: 3.13.0-8-generic / Centrino Wireless-N 1000 [Condor Peak] [19:44] sforshee: i'll install 3.14 and see how that works [19:45] arges: what about the firmware? That was updated not too long ago to adress some firmware issues [19:47] linux-firmware 1.124 [19:58] arges: okay, that should have the new firmware [20:06] arges: so I do see people saying that loading iwlwifi with 11n_disable=1 gets rid of it, and intel has gone so far as sending a patch recently to make that the default due to firmware issues [20:07] so I'm wondering if this falls into the category of firmware issues that aren't going to be fixed === mwhudson is now known as zz_mwhudson === zz_mwhudson is now known as mwhudson === mwhudson is now known as zz_mwhudson === zz_mwhudson is now known as mwhudson