[02:33] <vicTROLLA> Hello, I have some potentially very stupid questions so apologies if I'm wrong or off base. I am running a multi-headed 14.04 system with an nvidia card and the current nvidoa drivers (352). For months now I notice whenever I do anything graphics intensive the system locks. No kernel panic messages no response from input peripherals no logs no nothing. After much frustration I've come to the conclusion that the CPU fan the i7 ships with is
[02:33] <vicTROLLA>  grossly inadequate to control CPU temp. I assume this because I can reproduce a hang by encoding or decoding video on CPU (as opposed to no crash when encoding or decoding via nvenc) 
[02:35] <vicTROLLA> so I've ordered a liquid cooler for my CPU (still waiting for the fedex delivery) but now that I'm watching CPU usage and temps like a hawk I've noticed an odd behavior. After about 24 hours of running there comes this point where temperature rises no matter what. If I look at the process table I notice that there will be a process at the top of the table (python for example)  consuming exactly 12% CPU. If I kill it, another random process
[02:35] <vicTROLLA>  (chrome) will begin consuming exactly 12% CPU. No matter how many processes I kill something always 'takes its place'
[02:36] <vicTROLLA> Since I was able to catch it exhibiting this behavior the last two times I quickly checked dmesg before rebooting to bring temp down and I've notice a (seemingly harmless)  error to the effect of 'perf interrupt took too long'
[02:38] <vicTROLLA> I am (likely naively) assuming that the CPU usage is a side effect of some sort of frequency scaling? If so, why? Also, is this perf interrupt error under these conditions a product of the CPU being so hot it's 'dropping frames' so to speak
[02:39] <vicTROLLA> sorry for the long winded question. Any help advice or clarifications would be really awesome. This problem has been bugging me for months and the instability is starting to make me crazy. Also, I came here because googling this problem is somewhat difficult 
[05:15] <tjaalton> is there a way to force a module to be loaded in initramfs?
[05:16] <tjaalton> /etc/modules doesn't seem to get copied
[07:50] <smb> tjaalton, /etc/initramfs-tools/modules iirc
[08:24] <tjaalton> smb: ah, thx
[10:31] <nchauvet> Hello, I have an issue when I try to build a kernel from https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[10:36] <nchauvet> using a precise (3.2) kernel
[10:36] <nchauvet> It fails at the following step:
[10:36] <nchauvet>  fakeroot debian/rules binary-headers binary-generic
[10:36] <nchauvet> dh_testdir
[10:36] <nchauvet> dh_testdir: cannot read debian/control: No such file or directory
[10:38] <apw> nchauvet, did you clean it first ?
[10:38] <apw> fakeroot debian/rules clean
[11:00] <caribou> apw: smb: would one of you have a few spare cycle to review my blogpost about kdump-tools modifications ?
[11:00] <caribou> or I just publish it & fix stuff later. I'm fine with that too
[11:02] <smb> caribou, I could have a look (though I just thought about some food would be nice...)
[11:03] <caribou> smb: ok, I need to publish it anyway for someone to review it
[11:03] <caribou> smb: so I will publish it & change things if you notice something wrong
[11:03] <smb> caribou, heh ok. wfm
[11:04] <caribou> smb: http://caribou.kamikamamak.com/2015/10/19/kdump-tools-enhancements-to-use-smaller-initrd-img/
[11:06] <smb> caribou, Ack and oh good, I don not have to try my scarce pieces of French from school :)
[11:17] <smb> maybe "triggers the oom killer too early" -> triggers the oom killer"
[11:19] <smb> "to increase to a higher value" -> "to increase the amount of reserved memory to a higher value"
[11:19] <nchauvet> hum, I thought yes I've cleaned it, but it also remove some files from the git repo... maybe I've mixed with make clean...
[11:19] <nchauvet> It' working now, thx
[11:19] <nchauvet> other question, is it possible to have access to pre-release 3.2 precise kernel ?
[11:20] <nchauvet> I need to test the one based on the recent 3.2.72 upstream linux version
[11:22] <smb> nchauvet, You can enable the -proposed pocket for a specific machine. All kernels go through that pocket before being moved to updates
[11:24] <smb> !proposed
[11:28] <smb> "can be adapter according" -> "can be adapted according"
[11:34] <smb> "may diverge in the eventuality of an upgrade of the source" -> ?"may diverge in case the original config file gets upgraded" (not sure there just feels like a phrase more likely used in French or German)
[11:41] <smb> caribou, One final thing (rather nitpicky), but I would probably avoid things like YMMV (through probably it is only /me pre-twitter generation that cannot immediately expand it without using google)
[12:07] <amitk> rsalveti: 
[12:08] <smb> amitk, No comment? :)
[12:08] <rsalveti> :-)
[12:52] <caribou> smb: thanks for the review!
[12:54] <smb> caribou, welcome
[15:11] <tseliot> apw: hey, fglrx seems to be completely broken now (LP: #1493888)
[15:13] <tseliot> rtg ^
[15:14] <tseliot> fglrx dies, as shown in dmesg http://paste.ubuntu.com/12877366/
[15:16] <rtg> tseliot, that is quite early in the module init
[15:16] <tseliot> yep
[15:17] <rtg> tseliot, looks like it is in the open source wrapper code
[15:17] <rtg> which will make it much easier for you to find
[15:20] <tseliot> rtg: it seems a bit odd to me that this failed: http://pastebin.ubuntu.com/12877399/
[15:24] <tseliot> not sure about pci_conf1_write
[15:30] <tseliot> rtg: that seems to be working fine on debian (sid) 4.2.0-1-amd64 (they use our patches)
[15:30] <tseliot> there has to be something else that broke in our kernel
[15:30] <tseliot> http://ati.cchtml.com/show_bug.cgi?id=1189#c8
[15:30] <rtg> tseliot, is Debian up to 4.2.3 ?
[15:31] <tseliot> rtg: the user reported using 4.2.0-1-amd64
[15:31] <tseliot> so, I guess not
[15:32] <tseliot> rtg: wait, sid seems to have it
[15:32] <tseliot> rtg https://packages.debian.org/source/sid/linux
[15:33] <tseliot> Source Package: linux (4.2.3-2)
[16:12] <tseliot> rtg: apparently KCL_fpu_save_init() is never used: http://paste.ubuntu.com/12877716/
[16:13] <tseliot> and we even patched that one
[16:13] <tseliot> something's wrong
[16:14] <tseliot> I suppose it's because of #ifdef TS_USEDFPU ?
[16:55] <jsalisbury> ##
[16:55] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:55] <jsalisbury> ##
[17:02] <cristian_c> jsalisbury: hello
[17:06] <jsalisbury> cristian_c, There is no new update on the bug yet.  I'll make some time today to review it.
[17:06] <cristian_c> jsalisbury: ok