[06:26] 1;2c/away [06:26] ^^typingfail === _LibertyZero is now known as LibertyZero === zul_ is now known as zul [14:16] hi guys, having [14:18] hi guys, can any1 help me w/ this error? [14:19] drivers/dsp/syslink/multicore_ipc/gate.c: In function ‘gate_enter_system’: [14:19] drivers/dsp/syslink/multicore_ipc/gate.c:38: error: implicit declaration of function ‘local_irq_save’ [14:19] thats it [14:52] Ober7: Where did you get your tree from? [14:53] lag: ubuntu git tag Ubuntu-2.6.35-903.9 [14:54] Okay, give me a moment [14:54] thanks [14:57] Have you changed anything in the config? [14:59] Ober7: --^ [15:00] Can you grep your config files for "CONFIG_TRACE_IRQFLAGS_SUPPORT" [15:00] lag: i used localmodconfig, when i looked at it later with menuconfig the whole sys_linux was built-in [15:01] lag: CONFIG_TRACE_IRQFLAGS_SUPPORT=y [15:01] Ober7: That's a good start [15:03] lag: nice [15:07] Ober7: Bear with me, I'm going to build that Tag [15:10] Ober7: Which platform are you trying to build for? [15:23] lag: 686 [15:24] i686* === akgraner` is now known as akgraner [15:49] lag, would appreciate your help thanks === jdstrand_ is now known as jdstrand [16:11] Ober7: Why are you building Ubuntu-2.6.35-903.9? [16:17] Ober7: What made you choose Ubuntu-2.6.35-903.9? [16:19] lag i just like trying out the latest [16:19] starting to think maybe this build is for something specific [16:19] Ober7: Correct [16:19] Ober7: Specifically, ARM [16:19] :) [16:20] But it's not the lastest [16:20] ahhh [16:20] Checkout the lastest master branch [16:20] That is the lastest [16:20] thanks lag [16:20] :) [16:20] np [16:20] That's why we're here [16:20] anyways i removed syslink form the config and it compiled fine [16:21] im on it right now [16:21] will rebuild the master [16:21] Yes, syslink is an ARM thinkg [16:21] thing* [16:21] TI specific [16:21] sorry for the trouble [16:21] cheers [16:21] S'ok [17:09] #ubuntu-uds-bonaire1 [17:10] what's the bonaire for? [17:12] Ian_Corne: the room name [17:12] ok :) === smb` is now known as smb [22:17] Does anyone know of a convenient way to un-Ubuntuize for patches a Ubuntu kernel package? [22:18] huh? un-ubuntuize patches? [22:18] if you want a vanilla kernel, why don't you just download it from kernel.org? [22:18] hyperair: Remove all the ubuntu patches, but leave the build environment [22:18] ah [22:19] that sounds like it could be tough =p [22:19] check debian/patches? [22:19] if there's nothing there, then just copy debian/ onto a vanilla kernel [22:19] hyperair: What I really want is to take the linux-rt package and take out the ubuntu patches, making what Ubuntu calls a -realtime kernel. [22:19] eh? [22:19] hyperair: I tried something like that [22:19] wait, so you want a realtime kernel minus ubuntu patches? [22:20] hyperair: as a package, yes [22:20] hmm why would you want to do that? [22:20] hyperair: There is one for 2.6.33, but I need 2.6.31 [22:20] * hyperair repeats. why would you want to do that? [22:20] hyperair: Because there is an issue with kernels with Ubuntu patches [22:21] and that is? [22:22] hyperair: The error message is like info: task jbd2 312 blocked for more than 120 seconds. [22:22] =\ [22:22] a hung task. [22:22] hyperair: I don't see it on Fedora kernels, or -realtime kernels. But I do see it on all Ubuntu kernels, even the latest development 2.6.36 kernels [22:23] you should report a bug [22:23] and maybe bisect the patch out [22:23] hyperair: There are open bugs for issues like this. Mine might be slightly different, but this issue has been around since the beginning of Lucid, at least. They have been patching it, which makes it less frequent, but it still isn't gone. [22:24] hyperair: All it takes for me to reproduce it on a normal -generic kernel is dd a big file, and looping a apt-get remove ; apt-get install [22:24] Edgan: https://bugzilla.kernel.org/show_bug.cgi?id=15370 <-- looks like fedora has it. [22:24] bugzilla.kernel.org bug 15370 in LVM2/DM "task jbd2/dm-1-8:973 blocked for more than 120 seconds." [High,Resolved: invalid] [22:25] hyperair: That is fc12, but I don't see it on fc13, which is now on 2.6.34 [22:25] so basically you're seeing those i/o latencies [22:25] hyperair: I have also tested newer development Fedora 2.6.36 [22:26] i think you're seeing those i/o hangs where your load level temporarily shoots up to the 20s or 30s [22:26] and suddenly everything gets swapped out, and swapped back in [22:26] and so everything grinds to a halt. [22:26] hyperair: It doesn't shoot that high with dd and apt-get, but yes, in some cases we shoot it way higher than that. [22:26] it's not due to an ubuntu patch imo [22:26] i've been compiling my own vanilla kernels for some time now [22:27] hyperair: Well here is my evidence [22:27] and until my recent RAM upgrade, i've had this issue on every kernel i've compiled [22:27] since karmic. [22:27] which was approximately when i started compiling my own kernels [22:28] hyperair: 2.6.31-rt(official lucid realtime) has it, 2.6.32-25(official lucid) has it, 2.6.35-22(official maverick) has it, 2.6.36(development maverick) has it [22:28] * hyperair shrugs [22:28] hyperair: 2.6.33-realtime(ppa lucid realtime) doesn't have it, 2.6.36(Fedora development) doesn't have it [22:28] i'm just saying that i've seen the issue in vanilla kernels. [22:29] hyperair: I have seen this issue in the past with Fedora, but it went away long ago [22:29] hmm [22:29] hyperair: I think there have also been multiple bugs that trigger that error [22:29] apw: you seen this issue before? [22:30] Edgan: are you saying that this 2.6.33-realtime kernel doesn't get the severe i/o hangs? [22:30] at all? [22:30] hyperair: Right, though I have other issues with it, which make me want to go back to 2.6.31, but then the 120 second error comes back [22:31] -realtime kernel - is based on the vanilla kernel source tree with Ingo Molnar maintained PREEMPT_RT patch applied to it. Also know as a hard real-time kernel. [22:31] well that's really something. [22:31] That is the description for -realtime [22:32] hyperair: I am the sysadmin at a robotics research company. We run the realtime kernel on our robots, and they have been crashing left and right. I have been working for over a week to find a truly stable kernel. It has been very frustrating. [22:33] i see. [22:34] i think you might have better luck digging around the git tree for ubuntu kernels [22:35] hyperair: My theory is that it is differences in the ext4 code. Red Hat writes more of the code, so they stay on top of it more. in something like 2.6.32-23, Ubuntu was like oh look we are missing 100+ ext4 patches, lets add those in. In this exact case I suspect it is either out dated or one-off Ubuntu patch. [22:36] hyperair: What doesn't help is that Ubuntu's kernel is one big monster patch, that isn't broken out into individual patches [22:36] Edgan: you need to see the git tree. [22:36] i believe that the big monster patch is generated from the git tree [22:36] and that the actual maintenance of the separate patches happens within that git tree [22:37] hyperair: lame [22:37] hyperair: Any pointer page? [22:37] Edgan: not so lame when you consider that there are potentially hundreds of those patches there, which without git's delta-compression can cause the package size to swell. [22:39] Edgan: https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide [22:39] hyperair: Fedora's build environment is somewhat git-ized. I have to use it build non-debugging development kernels. But normal packages have all the patches broken out. In the spec file you can just comment them out one by one for a build. [22:39] hyperair: Plus patches are just text, which compresses well [22:39] Edgan: one or two patches compress well. not hundreds. [22:40] hyperair: They end up as one big monster patch in the apt-get source results anyway. For 2.6.32-25, that is 2.1mb compressed. [22:41] hyperair: kernel tarball, 79mb [22:41] 1 monster patch = 1 set of context lines. [22:41] 100 patches = 100 sets of context lines [22:42] couple that with merges and whatnot, and you've got yourself a fine mess of patches that you don't know to apply in what order ^_^ [22:42] It would also be more sane if the debian* directories where outside the build tree, but that is Debian's fault [22:42] hyperair: That is what a spec file sorts out for you. [22:42] that is what quilt sorts out for you [22:43] but you need to generate the series file [22:43] which is a set of patches in linear order [22:43] when you have merges with conflicts, they're not so easy to generate patches for [22:43] i don't believe the spec file handles all of that [22:43] perhaps redhat just has less distro-specific patches [22:44] or take great pains to make sure their patches are linear [22:44] have linear history, i mean [22:44] either way, i maintain that rpm is a joke of a package format and package manager, so *shrug* [22:45] if you really want fedora kernels, then go ahead and use fedora. [22:45] hyperair: haha, I find dpkg far worse. [22:45] then let's agree to disagree [22:45] hyperair: I would but before me they settled on Ubuntu as their development platform [22:45] i lack sleep and don't feel like continuing this disagreement. [22:46] hyperair: http://kernel.ubuntu.com/git I am not finding any realtime branches here [22:46] well redhat junkies will be redhat junkies. i remember the short period of time i administrated a centos server [22:46] that was a real nightmare. [22:46] hyperair: I did that for years, they have their problems, but I am finding Ubuntu far worse as a server. [22:47] hyperair: But I am willing to drop that topic [22:47] hyperair: realtime branch? [22:47] Edgan: i like debian on my servers. but yes, let's drop it [22:47] as for realtime branch, i don't know, i've never poked around [22:48] what you could do, however, is wait for apw to come around and tell you things that kernelteam knows about [22:48] i'm just a random non-kernel-hacker who compiles his own kernels and hangs around the channel. [22:48] hyperair: ok, I will look to ask him if he pokes his head up. [22:49] if all else fails, what you can do is just go get ingo molnar's PREEMPT_RT tree and compile that straight [22:49] make-kpkg generates deb packages you can install [22:49] ah, not bad [22:49] buildkernel='rm -f .version; KBUILD_BUILD_VERSION=0 AUTOBUILD=1 CONCURRENCY_LEVEL=${CONCURRENCY_LEVEL:-2} ionice -c 3 schedtool -D -e time make-kpkg --initrd --rootcmd=fakeroot --append-to-version=-hyper${KERNELREV:-1} kernel_{headers,image}' [22:49] that's my alias i use for building kernels [22:50] Sarvatt: what was the new and improved way of building kernels again? [22:50] * hyperair still loves his make-kpkg [22:51] i think there was a make deb-pkg target as well in the mainline tree, but never experimented with that [22:51] well then, my vision is hazy and the sun's about to rise, so off i go to bed.