[07:17] <ppisati> hallo
[08:09]  * smb waves tiredly
[09:53] <caribou> Is there issues with doing a bisect b/w 3.11 & 3.13 kernels ?
[09:53] <caribou> I mean will a bisection work between 11 & 13 ?
[09:55] <smb> For mainline/upstream: maybe. 
[09:57] <caribou> smb: yeah, it's for the mainline
[09:58] <smb> caribou, It probably works but can't you just go for a mainline 3.12 manually and then decide
[09:58] <smb> ?
[09:58] <smb> (which is what bisect would probably do anyways)
[09:58] <caribou> smb: yeah, that would be better indeed
[09:59] <caribou> smb: thanks, will do that
[09:59] <smb> caribou, I usually take the mainline builds as first approximation (the RCs, too)
[09:59] <smb> Unfortunately most of the time its in -RC1
[09:59] <smb> But at least that reduces your bisect to between last release and next -rc1
[10:04] <smb> 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] <cking> smb, thanks for that, I'll look at that later today
[10:06] <smb> cking, ok. To me it looks sensible enough. But its always better to have a second opinion
[10:06] <smb> ;)
[10:09] <cking> it certainly looks sane to me
[10:37] <apw> smb, where did you stumble over that, it has to be old
[10:38] <smb> apw, on the acpi-devel mailing list and for me it looks to be sent yesterday around 5pm
[10:38] <apw> oh missread what you said, thought you were saying it was mine
[10:38] <smb> No, no. Not at all
[10:41] <apw> smb, ok we have all of those =m so at least they exist
[10:42] <apw> mjg59, does your latest patch for the IPMI bits imply you can need them before it is possible to load modules
[11:14] <hvn2> hi, I have a question on configuring the kernel
[11:15] <hvn2> 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] <apw> hvn2, i cannot find anything which even smells similar to that in any of the kernels i am looking at ehre, no
[13:38] <apw> what makes you think you need to set that, ie. what docs are you reading
[13:42] <dslr> 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?
[14:08] <apw> 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] <apw> https://launchpad.net/ubuntu/precise/+source/linux/3.2.0-41.66 for that _very_ old version you are running
[14:19] <dslr> apw: thanks.  yeah i know it is quite old version.  have to live with it. :)
[14:21] <apw> dslr, dare i ask why you cannot run the latest
[14:22] <hvn2> 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] <dslr> 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] <caribou> 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] <caribou> now we will test with the ubuntu specific 3.13 from Trusty to see if it continues to work.
[14:35] <caribou> then we want to do a bisection. should we do the bisect with the mainline kernels or with the ubuntu specific ?
[14:35] <caribou> given that the ubuntu specific 3.13 does work
[14:36] <caribou> otherwise, the delta will be b/w ubuntu 3.13 & mainline 3.13
[14:36] <caribou> am I making any sense ?
[14:37] <rtg> caribou, you really want to bisect the mainline kernel 'cause the Ubuntu kernel commit history is not linear
[14:38] <caribou> rtg: this is what I wanted to know, thanks rtg 
[14:39] <caribou> rtg: so it it worth to test the Ubuntu specific 3.13 then to see if kdump still works ?
[14:40] <caribou> rtg: if the delta is b/w ubuntu 3.13 & mainline 3.13 is it possible to bisect ?
[14:52] <rtg> 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] <caribou> 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] <caribou> rtg: i.e. test with 3.12 mainline
[14:54] <caribou> rtg: ah, sorry just realized you were talking about Ubuntu 3.13
[14:55] <caribou> rtg: but I'll remember the eyeball part :-)
[14:56] <rtg> 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] <mjg59> apw: It's certainly possible
[16:08] <mjg59> apw: Any _INI method could refer to an IPMI opregion
[16:13] <manjo> ppisati, ping 
[16:14] <manjo> ppisati, around asquare atriangle ? 
[16:17] <gQuigs> 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] <gQuigs> I'd hope to do something before the Final Beta.  Any suggestions?
[16:22] <rtg> gQuigs, we are definitely releasing 14.04 with a 3.13 kernel.
[16:25] <gQuigs> rtg: thanks!  Then I'm thinking about suggesting customer testing around March1st, any objections? 
[16:27] <rtg> gQuigs, it seems pretty stable right now, so March 1 ought to be fine.
[16:28] <gQuigs> rtg: awesome, thanks
[16:32] <ppisati> manjo: no
[16:34] <manjo> 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] <ppisati> manjo: yep, can you point me to the new patch?
[16:35] <manjo> yes I will .. just wanted to give you a heads up that that is happening 
[16:37] <manjo> ppisati, emailed you 
[16:41] <ppisati> manjo: k
[17:01] <RoyK> 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] <apw> RoyK, it may be only connected to that one cpu
[18:06] <RoyK> 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] <rtg> isn't that what it is supposed to do ? keep the caches populated ?
[18:09] <RoyK> well, when one core is at 95%+, it should move those interrupts imho
[18:10] <RoyK> rtg: also, by default it seems to pin both NICs on core0
[18:37] <arges> sforshee: hey
[18:37] <arges> sforshee: I'm seeing this again: http://pastebin.ubuntu.com/6961321/
[18:39] <arges> looks like this https://bugzilla.kernel.org/show_bug.cgi?id=69051
[18:39] <ubot2`> 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] <sforshee> arges: what kernel/firmware versions?
[19:35] <arges> sforshee: 3.13.0-8-generic / Centrino Wireless-N 1000 [Condor Peak]  
[19:44] <arges> sforshee: i'll install 3.14 and see how that works
[19:45] <sforshee> arges: what about the firmware? That was updated not too long ago to adress some firmware issues
[19:47] <arges> linux-firmware 1.124
[19:58] <sforshee> arges: okay, that should have the new firmware
[20:06] <sforshee> 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] <sforshee> so I'm wondering if this falls into the category of firmware issues that aren't going to be fixed