| === 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 | ||
| ppisati | hallo | 07:17 |
|---|---|---|
| * smb waves tiredly | 08:09 | |
| 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:53 |
| smb | For mainline/upstream: maybe. | 09:55 |
| caribou | smb: yeah, it's for the mainline | 09:57 |
| 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:58 |
| 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 | 09:59 |
| 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:04 |
| smb | cking, ok. To me it looks sensible enough. But its always better to have a second opinion | 10:06 |
| smb | ;) | 10:06 |
| cking | it certainly looks sane to me | 10:09 |
| apw | smb, where did you stumble over that, it has to be old | 10:37 |
| 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:38 |
| apw | smb, ok we have all of those =m so at least they exist | 10:41 |
| apw | mjg59, does your latest patch for the IPMI bits imply you can need them before it is possible to load modules | 10:42 |
| hvn2 | hi, I have a question on configuring the kernel | 11:14 |
| 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. | 11:15 |
| 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:38 |
| 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? | 13:42 |
| === Trevinho_ is now known as Trevinho | ||
| === Guest78972 is now known as fmasi | ||
| 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:08 |
| apw | https://launchpad.net/ubuntu/precise/+source/linux/3.2.0-41.66 for that _very_ old version you are running | 14:10 |
| dslr | apw: thanks. yeah i know it is quite old version. have to live with it. :) | 14:19 |
| apw | dslr, dare i ask why you cannot run the latest | 14:21 |
| 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:22 |
| 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:23 |
| 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:34 |
| 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:35 |
| caribou | otherwise, the delta will be b/w ubuntu 3.13 & mainline 3.13 | 14:36 |
| caribou | am I making any sense ? | 14:36 |
| rtg | caribou, you really want to bisect the mainline kernel 'cause the Ubuntu kernel commit history is not linear | 14:37 |
| caribou | rtg: this is what I wanted to know, thanks rtg | 14:38 |
| caribou | rtg: so it it worth to test the Ubuntu specific 3.13 then to see if kdump still works ? | 14:39 |
| caribou | rtg: if the delta is b/w ubuntu 3.13 & mainline 3.13 is it possible to bisect ? | 14:40 |
| 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:52 |
| 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:53 |
| 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:54 |
| caribou | rtg: but I'll remember the eyeball part :-) | 14:55 |
| 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. | 14:56 |
| mjg59 | apw: It's certainly possible | 16:07 |
| mjg59 | apw: Any _INI method could refer to an IPMI opregion | 16:08 |
| manjo | ppisati, ping | 16:13 |
| manjo | ppisati, around asquare atriangle ? | 16:14 |
| 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:17 |
| gQuigs | I'd hope to do something before the Final Beta. Any suggestions? | 16:19 |
| rtg | gQuigs, we are definitely releasing 14.04 with a 3.13 kernel. | 16:22 |
| gQuigs | rtg: thanks! Then I'm thinking about suggesting customer testing around March1st, any objections? | 16:25 |
| rtg | gQuigs, it seems pretty stable right now, so March 1 ought to be fine. | 16:27 |
| gQuigs | rtg: awesome, thanks | 16:28 |
| ppisati | manjo: no | 16:32 |
| 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:34 |
| manjo | yes I will .. just wanted to give you a heads up that that is happening | 16:35 |
| === cyphermox_ is now known as cyphermox | ||
| manjo | ppisati, emailed you | 16:37 |
| ppisati | manjo: k | 16:41 |
| 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? | 17:01 |
| apw | RoyK, it may be only connected to that one cpu | 18:03 |
| 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:06 |
| rtg | isn't that what it is supposed to do ? keep the caches populated ? | 18:08 |
| RoyK | well, when one core is at 95%+, it should move those interrupts imho | 18:09 |
| RoyK | rtg: also, by default it seems to pin both NICs on core0 | 18:10 |
| arges | sforshee: hey | 18:37 |
| arges | sforshee: I'm seeing this again: http://pastebin.ubuntu.com/6961321/ | 18:37 |
| 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] | 18:39 |
| sforshee | arges: what kernel/firmware versions? | 19:34 |
| arges | sforshee: 3.13.0-8-generic / Centrino Wireless-N 1000 [Condor Peak] | 19:35 |
| arges | sforshee: i'll install 3.14 and see how that works | 19:44 |
| sforshee | arges: what about the firmware? That was updated not too long ago to adress some firmware issues | 19:45 |
| arges | linux-firmware 1.124 | 19:47 |
| sforshee | arges: okay, that should have the new firmware | 19:58 |
| 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:06 |
| sforshee | so I'm wondering if this falls into the category of firmware issues that aren't going to be fixed | 20:07 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!