[00:49] <mwhudson> hello
[00:49] <mwhudson> i am trying to build a kernel from git
[00:50] <mwhudson> (on armhf)
[00:50] <mwhudson> and getting bales of /root/linux-linaro-tracking/net/sunrpc/auth_gss/svcauth_gss.c:1328: undefined reference to `__stack_chk_guard' type errors
[00:50] <mwhudson> do i need to do something to disable stack protection in gcc?
[00:54] <lifeless> http://osdir.com/ml/linux-kernel/2009-02/msg04270.html
[00:54] <lifeless> stack protection is in the kernel itself it seems
[00:54] <lifeless> I'm sure I'm reading that naively :)
[08:00] <erle-> may i ask you a somewhat intimate question?
[08:01] <erle-> does really anybody here use unity?
[08:10] <hyperair> yes
[08:10] <hyperair> i do.
[08:10] <hyperair> but why come to the kernel channel for trolling about unity?
[08:11] <ohsix> o noes you did it now
[08:27] <hyperair> ohsix: he left though? ;p
[09:13] <abhishek> I want to run Ubuntu Desktop on the device which is having Android ...Please help me
[09:16] <cking> abhishek, perhaps try #ubuntu-desktop with that question
[09:17] <abhishek> cking: ok ....
[09:17] <abhishek> cking: Can you please give me some guildlines anyways
[09:17] <RAOF> You're immediate problems are going to be: lack of OpenGL drivers and lack of X drivers.
[12:34] <cer> hi there .... I think I found a bug in the kubuntu / ubuntu kernel but I need to have a chat to confirm before logging.
[12:34] <cer> anyway, there seems to be some problem with setting the frequency of some Core 2 Xtreme CPUs .... 
[12:34] <cer> so I recompiled the kernel without intel_pstate support and everything else as module using the classic debian system
[12:34] <cer> and modprobing each module one by one and then debugging .... it turns out that p4_clockmod is loading, but return wrong frequency reading (as it should) and recommends acpi-cpufreq
[12:35] <cer> but acpi-cpufreq does not actaully load, because one of the checks says that the CPU is not supported (which is incorrect). I think the bug may be in the acpi-cpufreq module.
[12:35] <cer> what do you think?
[15:41] <mwhudson> lifeless: yes, that much makes sense, doesn't help me know how to make the error go away though :)
[15:41] <mwhudson> infinity: are you here/awake?
[15:51] <infinity> mwhudson: I'm one of those things.
[15:52] <mwhudson> infinity: is there some trick to building kernels from git on armhf to avoid linker errors about stack protection?
[15:53] <mwhudson> i noticed some mention of gcc 4.7 somewhere so i'm trying that now...
[15:53] <rtg> apw, pushed trusty master-next with all of the packaging done. no tag yet.
[15:54] <infinity> mwhudson: -UFORTIFY_SOURCE, I'd assume.
[15:54] <infinity> mwhudson: But I would have thought the kernel makefiles did that by default.
[15:55] <mwhudson> hmm
[15:55] <mwhudson> there is some of that, but only in a few places
[15:55] <mwhudson> and only for user space stuff
[15:56] <apw> rtg, great
[15:57] <mwhudson> (i'm building 3.11 + sprinkles, fwiw)
[16:00] <mwhudson> infinity: build with gcc 4.7 completed
[16:02] <apw> mwhudson, mostly we use older gccs for the arm kernels indeed
[16:03] <rtg> ppisati, have you built and booted trusty on armhf with gcc-4.8 ? so far the compiler has been pinned to gcc-4.7.
[16:04] <mwhudson> apw: now i know why :)
[16:07] <ppisati> rtg: let me check the gcc version
[16:08] <rtg> ppisati, I know we're building with -4.7 right now, but I'm thinking about building with the default version
[16:09] <rtg> debian.master/rules.d/armhf.mk:gcc              = gcc-4.7
[16:10] <ppisati> rtg: when i do some quick test using linus tree, im compiling with 4.8
[16:10] <rtg> ppisati, ok, I'll assume for now that -4.8 can generate a bootable kernel
[16:26] <bjf> ppisati, were you going to rebase omap4 kernels for this sru cycle?
[16:28] <ppisati> bjf: ouch, i'll do
[16:38] <backjlack> Hello.
[16:39] <backjlack> I've reported a while ago that I was having problems after having upgraded to kernel 3.2.0-53 on Ubuntu 12.04 amd64.
[16:39] <backjlack> The machine wasn't booting properly into the OS, it was just showing a blinking cursor. This is still an issue.
[16:41] <apw> backjlack, what was the bug number
[16:42] <backjlack> apw: I haven't opened any bug because it's not clear whether it's a bug or just some kind of OS issue triggered by the update to 3.2.0-53+.
[16:44] <backjlack> I'll just try 3.5 to see if that fixes it.
[16:45] <rtg> jsalisbury, re: bug #1245938 - please have that guy try the stable mainline kernel(s). his NIC really ought to be functional.
[16:45] <ubot2> Launchpad bug 1245938 in linux (Ubuntu) "Intel x520 NIC's (ixgbe) stop working in 12.10, 13.04, 13.10" [Undecided,Confirmed] https://launchpad.net/bugs/1245938
[17:54] <jsalisbury> rtg, ack
[18:29] <erle-> jsalisbury, new observation: when i suspend with "sudo pm-suspend", no freeze
[18:29] <erle-> maybe it is not the kernel
[18:29] <erle-> maybe something with X
[18:29] <erle-> with screen locking and so on
[18:29] <erle-> jsalisbury, after more tests i will report to launchpad
[18:31] <jsalisbury> erle-, thanks for the info
[18:46] <apw> jibel, we just dumped a new trusty kernel into the ckt PPA, will that auto fire new dkms tests ?
[20:39] <rtg> apw, looks like iwlwifi power save is off by default. drivers/net/wireless/iwlwifi/iwl-drv.c:MODULE_PARM_DESC(power_save,
[21:33] <apw> rtg, ta
[21:38]  * mwhudson is now confused that perf ever worked on arm32
[22:04] <rtg> jsalisbury, rebooting gomeisa for kernel update
[22:04] <apw> mwhudson, i od't think it was even built for the longest time, and done wrong often
[22:05] <mwhudson> apw: it worked for a while for me in raring
[22:05] <mwhudson> but doesn't for me now
[22:05] <mwhudson> and i even sort of know why
[22:13] <apw> care to share
[22:34] <rtg> jjohansen, AceLan: rebooting tangerine for kernel update
[22:45] <mwhudson> apw: the MMAP events that perf synthesizes at start up put the last module processed as taking up from its start in /proc/modules up until the end of the address space
[22:45] <mwhudson> apw: and despite this being something the user space tool does, it seems that it's actually a question of which kernel is running
[22:58] <mwhudson> oh oh
[22:58] <mwhudson> is this because /proc/kallsyms now starts with a symbol with an address of 0?