[00:26] <srp> Hello. Using DreamStudio (based on Ubunto 12.04 LTS), since kernel upgrade to 3.2.0.40 (low latency) the machine will not boot anymore. It hangs with a blank screen during the initialization process. I now have kernels 3.2.0-39 (low latency, pretty much stuck to it) and 3.8.0-32 (low latency) installed but the latter will not boot. I have looked at syslog for each kernel but could not find anything odd. Can someone point me towards investigating this issue
[00:26] <srp>  further?
[00:26] <srp> s/Ubunto/Ubuntu
[00:27] <srp> by "looked at syslog" I mean trying to boot with either kernel and then comparing the logs in the hopes of finding what was the step that was "hanging"
[00:32] <srp> the one thing I could find that seemed strange was that, in the working kernel there's "Console: colour VGA+ 80x25" whereas the locking kernel there's "Console: colour dummy device 80x25"
[00:32] <srp> since this happens very early in the log, I am unsure whether it could be the problem or not
[04:31] <dorimon5> "perf samples too long (2519 > 2500), lowering kernel.perf_event_max_sample_rate to 50000". this error turns my ubuntu server hang, i will happpen every 3-4 hours. need some help.
[04:56] <RAOF> dorimon5: That error isn't what's causing your server to hang.
[04:57] <RAOF> dorimon5: Why do you think that's the cause of the hang? (ie: What symptoms do you see, what have you done to debug, etc)
[05:01] <dorimon5> RAOF: i run this command to monitor the kernel log "watch dmesg | tail -50", the last log before hangs happen is this "perf samples too long (2519 > 2500), lowering kernel.perf_event_max_sample_rate to 50000"
[05:03] <dorimon5> RAOF: im currently using kernel 3.13.0-34-generic. according to my research it is a kernel bug. i want to verify if it is really true and i want to know what is the stable kernel as of now.
[05:04] <RAOF> And what are you doing when the kernel hangs? Anything in particular?
[05:05] <RAOF> It does sound like a kernel bug, but the log output you're looking at is at best a symptom.
[05:05] <dorimon5> RAOF: just reboot the computer. :)
[05:06] <RAOF> dorimon5: No, I mean what are you doing *before* the kernel hangs.
[05:07] <dorimon5> RAOF: ahhh. im sorry. :). as of now, my ubuntu server work as a diskless-server (if are you familiar), i
[05:08] <dorimon5> RAOF: i am using AOE (ATA OVER ETHERNET)
[05:10] <RAOF> And your server is just entirely idle?
[05:10] <RAOF> Until it dies?
[05:11] <dorimon5> RAOF: hhhmm. nope
[05:13] <dorimon5> RAOF: it is safe to manually install kernel 3.15 in my server, because accordning to them, it is already fixed in kernel 3.15
[05:14] <RAOF> Depends on what you want it to do. It's mostly safe, but you won't have any Ubuntu changes on it (you might want a kernel-PPA build for convenience, though).
[05:14] <RAOF> For me, the annoyance with non-Ubuntu kernel is no overlayfs, so schroot doesn't work.
[07:52] <soren> I'm a bit confused to find "3958afa1b272 net: Change skb_get_rxhash to skb_get_hash" in the Trusty kernel. It changes the kernel API incompatibly with upstream. Upstream didn't include it until 3.14 and Trusty is 3.13, right?
[07:56] <soren> It makes it really hard to write a generic #ifdef to check for this rename. Is there a special macro that says that this is an Ubuntu kernel so that I can apply a different version check there?
[07:58] <smb> soren, Apparently it was to get some drivers upgraded to the latest. And I think Trusty should have something
[07:59] <soren> I really think you ought to provide a compatibility macro so that the API at least matches upstream's 3.13, even if the ABI doesn't.
[08:01] <smb> soren, That is some road we really did not want to go
[08:01] <soren> smb: Ok... So what do you propose as a solution to people who want to write kernel modules that rely on that function?
[08:03] <smb> soren, To check the uts variable thing, which I would tell you as soon as I find it again
[08:04] <smb> UTS_UBUNTU_RELEASE_ABI
[08:04] <smb> defined in utsrelease.h (generated)
[08:05] <soren> smb: So you genuinely expect module authors to handle the fact that Ubuntu renamed a function at a different time than the rest of the world?
[08:06] <soren> smb: Just so that you don't have to add a macro to fix it?
[08:06] <smb> soren, Renamed to an upstream change
[08:06] <soren> smb: BEFORE UPSTREAM!
[08:06] <apw> soren, would after upstream be any better ?
[08:06] <soren> Upstream did it in 3.14. You did it in 3.13.
[08:06] <soren> apw: At the same time would be the sensible thing.
[08:07] <soren> So I can't even use the LINUX_VERSION_CODE macros to check this, because Ubuntu went ahead and did something else.
[08:07] <smb> So you have to cope with it when wanting to write code for 3.14+ anyway 
[08:07] <soren> smb: I sure do.
[08:08] <soren> smb: So I wrap it up in #if (LINUX_VERSION_CODE <= KERNEL_VERSION(3,14,0)  or whatever.
[08:08] <apw> LINUX_VERSION_CODE is an upstream meaning one cant change that anyhow
[08:08] <soren> smb: Except I can't, because Ubuntu is different. For no apparent reason.
[08:09] <smb> soren, You would know the apparent reason if you looked at the buglink on those patches. 
[08:09] <soren> apw: I'm not suggesting you change LINUX_VERSION_CODE. I'm suggesting you add a macro to replace skb_get_rxhash with skb_get_hash so that people's modules work.
[08:09] <apw> soren, we are differnet there to get some h/w support people needed
[08:10] <apw> soren, and if you file a bug and propose one i wouldn't be supprised if we accepted it
[08:10] <soren> apw: I did file a bug, but: 
[08:10] <soren> 07:59 < soren> I really think you ought to provide a compatibility macro so that the API at least matches upstream's 3.13, even if the ABI doesn't.
[08:10] <soren> 08:01 < smb> soren, That is some road we really did not want to go
[08:10] <soren> https://bugs.launchpad.net/intel/+bug/1358162
[08:10] <soren> Oh, whoops.
[08:11] <soren> Gah, I followed the BugLink from that commit and clicked "REport a bug" so now it ended up reported against Intel.
[08:11] <apw> i think what smb is saying there is that we wern't going to have considered it, we change too many things in the api too often
[08:11]  * soren fixes
[08:12] <soren> apw: And how do module authors generally work around this?
[08:12] <soren> apw: If you do it often, this must be a common problem.
[08:12] <apw> soren, we added the UBUNTU_ABI macro as upstream "compat" asked how to tell what ubuntu kernel version we were, that made them happy at least
[08:12] <smb> I probably misunderstood what soren wanted, too. What I meant is, we don't want to go a stable abi path (the way others do)
[08:13] <soren> smb: And I'm all in favour of that.
[08:14] <soren> smb: That's how we've always done it. We've offered API compatibility instead.
[08:15] <soren> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1358162
[08:16] <smb> soren, So show us the bug and we can think about it in a better way than someone whin...complain about it on irc first thing in the morning ... even worse Monday morning
[08:16] <smb> thanks
[08:17] <soren> It's right there ^
[08:17] <smb> Sorry, for the harshness
[08:18] <smb> I saw it
[20:18] <reillyeon> Can I get someone to take a look at this bug? It seems like the fix is a simple cherry-pick: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1353021
[20:31] <rtg> reillyeon, patch sent on the k-team list
[20:32] <reillyeon> rtg, thank you
[21:41] <stevespiegel> hi. is there a documented way to create a new kernel flavor? I'm making some modifications to the linux kernel and would like to install the modified kernel along side the one developed by the kernel team. seams like the easiest way to do this is a kernel flavor? but I dont see any docs for this