=== _LibertyZero is now known as LibertyZero [08:13] Hi, I got this when booting a linux kernel, http://pastebin.com/W7YyBM2n .. any idea? [08:15] fairuz: what does your grub entry look like [08:19] jjohansen: I use uboot actually [08:21] jjohansen: you need something like this? console=ttyO2,115200n8 mem=456M@0x80000000 mem=512M@0xA0000000 root=/dev/mmcblk0p2 rw rootdelay=2 init=/init vram="10M" omapfb.vram="0:4M" [08:22] fairuz: ah did you get a typo in /dev/mmcblk0p2 maybe? [08:23] * jjohansen has very little experience with current arm [08:23] uboot etc [08:23] hrmm no, I see it mounted okay [08:24] jjohansen: the /dev/mmcblk0p2 is correct [08:24] yeah [08:24] jjohansen: it's just somehow can't start init? [08:25] sorry no ideas, here. Though I expect I will have some better ideas in a week [08:25] * jjohansen has an arm box coming this week [08:25] jjohansen: cool [08:27] fairuz: which os? [08:27] jjohansen: android [08:27] jjohansen: froyo [08:27] maybe /sbin/init? [08:28] jjohansen: i'll try that [08:35] jjohansen: I don't think so since the init executable is in / [08:36] fairuz: okay, well it was worth a shot, my next suggestion was mounting somewhere else and checking the init was in / [08:37] jjohansen: btw, what init will do exactly? because i see there are the init exec, and also some .rc files such as init.rc, init_omap4430.rc etc [08:37] these files are useful to init? [08:38] fairuz: I assume so [08:38] :) [08:38] fairuz: it really depends on the init system [08:39] basically the kernel will exec init and then init can do what it wants [08:39] traditionally that is controlled /etc/init and .rc files etc [08:39] init will exec processes to take care of the rest of boot [08:40] * jjohansen has never played with android, so /me is not sure what their boot sequence is like [08:40] does the /init file has exec permissions? [08:40] jjohansen: yes [08:41] what does file init report? [08:44] jjohansen: sorry but I dont get what you mean. You mean the init log file or something like that? [08:44] no, run the file command on the init binary [08:45] eg. [08:45] > file init [08:45] init: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, stripped === lonewolf is now known as serious__sam [08:56] jjohansen: I have some other problems. Will get to you later. Btw, thanks for the help, really appreciate it. [08:56] fairuz: np, I hope you get it working, /me is interested as I expect to be having similar fun [08:57] jjohansen: what arm platform you will be getting btw? [08:57] efika mx [08:58] jjohansen: nice [10:15] I got 2.6.38-00366-g65e01eb when i do uname -r. Is it weird or normal? :D [10:16] Maybe I compile it wrong? === ogra is now known as Guest34611 === Guest34611 is now known as ogra_ === jjohansen is now known as jj-afk [11:59] I installed linux-headers-2.6.38-1204 but why it doesnt appear in /lib/modules/ ? [12:03] fairuz: the -headers package doesn't provide any modules; what are you looking to find in /lib/modules? [12:03] jk-: the headers file [12:04] fairuz: linux-headers only installs into /usr/src/ [12:04] jj-afk: ok, my bad ty [12:04] fairuz: the headers will be in /usr/src/linux-headers-$version/ [12:04] (there should be a symlink from /lib/modules/$version/build though) [12:05] fairuz: for future reference, `dpkg -L ` will list the files installed by a package [12:05] jk-: Ah ok, thats will be useful [12:07] I got Kernel Configuration is invalid error when compiling module using my new 2.3.38 kernel === yofel_ is now known as yofel [12:29] Hi, I got error: unknown field 'ioctl' specified in initializer when compiling a module on 2.6.38 [12:29] It compiles OK on 2.6.35 === chuck_ is now known as zul [12:36] Hmm they stop supporting ioctl in the file_operations? [12:39] I found the solution in the git log, have to change ioctl to unlocked_ioctl :D [13:11] I'm doing one final upload of the natty kernel before beta due to the new compiler, any last minute patches we need? (as long as they're not ABI bumpers) === diwic is now known as diwic_afk [13:13] ogasawara, how about the CONFIG_NR_CPUS patch thats still on the mailing list? [13:14] bug #737124 [13:14] Launchpad bug 737124 in linux "Support workstations with greater than 64 cores" [Medium,In progress] https://launchpad.net/bugs/737124 [13:14] * ogasawara looks for it === ogra_ is now known as ogra [13:45] ogasawara, CONFIG_NR_CPUS appears to be an ABI bumper [13:45] tgardner: just out of curiosity, did that CONFIG_NR_CPUS patch accidentally get dropped along the way? Looking at bug 706058, it looks like it was previously applied? [13:45] Launchpad bug 706058 in linux "amd64 x86-64 boot fails with more then 64 CPUs" [Undecided,Fix released] https://launchpad.net/bugs/706058 [13:45] ogasawara, I think it was -server only [13:46] yeah it was only server we applied it for [13:46] * apw isn't here [13:46] ogasawara, rather, it was only applied to -server [13:46] tgardner: hrm, was hoping to not have an ABI bumper. Can it wait till post beta? [13:46] ogasawara, yep, I thingk so [13:47] tgardner: ack, I'll shove it on master-next then and just do a no-change upload of the kernel for the new compiler [13:47] ogasawara, fire away === diwic_afk is now known as diwic [14:27] * ogasawara slaps forehead. pulled the trigger too soon with the upload. [14:27] I should actually wait for the compiler to finish building for the other aches, sigh [14:33] What's the most useful way to report a kernel panic? I don't see anything in /var/crash, and I don't get an apport prompt [14:36] mterry: do you have the full oops message? [14:40] Krunch, I didn't write it down from the screen, no... Is it written on my disk anywhere? [14:41] anyone know where to submit patches for latencytop? [14:41] mterry: it might be in the kernel logs (/var/log/kern.log on Debian, not sure for Ubunut) if you are lucky but probably not [14:41] mterry: without the oops message or the vmcore, there is probably not enough to write a bug report [14:42] actually, it looks kinda dead... [14:42] mterry: look into netconsole to send the oops message (and all the console messages) to a remote system [14:42] mterry: I usually take a photo with my phone and attach it to a bug report. [14:43] and depending on the oops message, that might not be enough either [14:43] soren, good idea [14:44] Krunch, k, thanks. (/var/log/kern.log is also there in Ubuntu, btw) [14:59] Hi, if I do sudo dpkg --unpack file.deb, where the unpacked files will go? [15:03] fairuz, I believe they go to the same locations as if you installed the package [15:05] fairuz, dpkg --extract unpacks them in the current folder [15:06] sforshee: I found them in /boot [15:06] bjf: ok ty [15:06] cnd, hmm, isn't latencytop maintained by the Redhat Realtime group (or whatever they call themselves)? [15:07] diwic, maybe, but they have no info about that on their website [15:07] I have no clue who is the maintainer or how to contact them... [15:07] no changes to their git tree in 17 months either... [15:08] When I do sudo flash-kernel, I got cannot find default kernel in /vmlinuz or /boot/vmlinuz ..... I got 3 different vmlinuz in my /boot [15:09] cnd, hmm, actually it says Intel Open Source Group on the homepage... [15:10] cnd, so I'm correcting myself, the Redhat people probably does the hard realtime stuff rather than this [15:11] cnd, from the git tree looks like arjan@linux.intel.com and benh@kernel.crashing.org have several commits in there, so start by emailing them directly and ask where to submit patches? [15:12] diwic, probably, but I'm just doing patch piloting [15:12] and the patch fixes a type in the man page [15:12] so I'm reluctant to put too much effort into it :) [15:12] cnd, ah, ok. Well, just send it to those two people and see what happens :-) [15:16] ogasawara, I rebased Natty master-next against master and added the CONFIG_NR_CPUS=256 patch (after a bump ABI) [15:16] tgardner: ack, thanks [15:19] ogasawara, I worked on a set of build scripts while in London a couple of weeks ago that I haven't really advertised much. You might want to give 'em a spin. kteam-tools/buildscripts/ukb-make* [15:20] tgardner: cool, I'll take a peek === bjf is now known as bjf[afk] === jj-afk is now known as jjohansen === herton is now known as herton_lunch === bjf[afk] is now known as bjf [16:42] tgardner: ukb-make works well for me [16:43] ogasawara, cool. the only issue I've noted so far is an inelegant error when the armel chroot isn't supported,. like on Lucid amd64 hosts. [16:44] actually, natty armel schroots on Lucid build hosts [16:46] ogasawara: welcome back! [16:46] sconklin: thank :) [16:46] thanks even === herton_lunch is now known as herton === sforshee is now known as sforshee-lunch [17:17] hey guys do you happen to know why my usb-bus doesnt detect devices if i plug them in after (!) booting? they work perfectly well when plugged in before booting... :-( [17:47] * tgardner --> lunch === sforshee-lunch is now known as sforshee === chuck_ is now known as zul [18:09] kentb, that vida is now en-route back to Dell [18:09] cough [18:10] cking, thanks :) [18:12] howdy, I'm trying to build a kernel with a few changed options (CONFIG_SYSFS_DEPRECATED=y, etc), and I keep running into an error when I build it. Here is the commands I used and the output: http://paste.pocoo.org/show/357263/ === chuck_ is now known as zul [18:16] when I do the make mrproper, it seems to blow away the debian directory [18:17] xuru: yes you will need to mv the debian and debain.master directory out of the source directory when you run mrproper and then you can mv them back [18:18] ok [18:19] any idea what's causing this in the first place? [18:19] seems to be pretty strait forward following https://help.ubuntu.com/community/Kernel/Compile [18:20] xuru: I can't remember but it does show up occasionally, especially if you poke the kernel build system without specifying it should dump thing in the debian/build directory [18:21] ok, I'll try doing the make mrproper and copying those files back [18:27] interesting... I did a 'make mrproper' and then copied the debian* directories back, then did a build (forgetting to copy my .config back) and it's building fine [18:28] so it must be one of the two options I set that are causing the build error [18:28] I'll try adding in each one at a time and see === chuck_ is now known as zul [18:38] xuru, it's probably the presence of the .config file that's causing the error [18:38] there's a section on the page you linked to about how to change config options [18:38] oh? must have missed that [18:39] xuru, it's a little hidden, it's under "Modify the source for your needs" [18:41] ok, I thought that was just if you were making a special non-generic kernel [18:41] so x86_64 == ia64 or amd64? [18:43] amd64 [18:44] k, thanks [18:45] is there a way to point make menuconfig to that config file? [18:46] nevermind, I can use the load alternate configuration option right? [18:53] is debian.master/config/config.common.ubuntu read in first? and then debian.master/config/amd64/config.common.amd64? === chuck_ is now known as zul [18:57] bjf, sconklin: I think an incorrect version of a CVE patch I sent to the ml was applied to hardy master-next, care if I just fix it up? [18:57] bjf, sconklin: it's for "econet: Fix crash in aun_incoming(). CVE-2010-4342" [18:57] ogasawara: The aun_incoming function in net/econet/af_econet.c in the Linux kernel before 2.6.37-rc6, when Econet is enabled, allows remote attackers to cause a denial of service (NULL pointer dereference and OOPS) by sending an Acorn Universal Networking (AUN) packet over UDP. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4342) [18:58] ogasawara, go for it, that's what "master-next" is all about and we have started a new cycle [18:58] ogasawara, so we won't look at master-next until next week some tim [18:58] ogasawara, s/tim/time/ [18:58] bjf: cool [18:58] ogasawara, whats wrong with it? [18:59] tgardner: struct dst_entry *dst = skb_dst(skb); [18:59] tgardner: skb_dst() isn't defined in Hardy [18:59] ogasawara, doh! I bet I used the Karmic patch. [19:02] bjf, sconklin, shall I upload the Lucid/Maverick LBM packages with the new compat-wireless 2.6.38 support ? [19:04] tgardner, i think that's ok with me [19:04] I can't think of a reason not to [19:46] * bjf -> lunch === bjf is now known as bjf[afk] [19:48] tgardner: is there a known reason why my CPU's load never goes below 1.00 on natty? [19:48] tgardner: system is totally idle [19:48] tgardner: but the lowest /proc/loadavg ever says is 1.00 [19:49] tgardner: model name : Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz [19:49] kirkland, none that I know of. lemme check, [19:50] kirkland, here is a dual CPU: 13:49:41 up 1 day, 19:52, 1 user, load average: 0.00, 0.01, 0.05 [19:50] tgardner: hrm [19:52] kees: when you were here, you pointed me toward something that might have to do with my load-never-goes-below-1.00 problem... I can't remember what it was, though [19:55] kees: aha, found it in my log [19:55] tgardner: ah, i see: [19:55] $ ps auwwx | grep " D " [19:55] root 701 0.0 0.0 0 0 ? D 09:07 0:01 [ips-monitor] [19:55] tgardner: what is ips-monitor? [19:56] kirkland, intel power save (I think) [19:56] tgardner: https://lkml.org/lkml/2011/3/19/37 [19:57] intelligent power sharing [19:57] tgardner: https://lkml.org/lkml/2011/3/21/237 [19:57] tgardner: so it is "phantom" load, as suspected [19:58] tgardner: still, annoying; looks like Intel is looking for a fix [19:59] kirkland, yep. === bjf[afk] is now known as bjf [20:46] hi all, has anyone gotten apmd working? === ogra is now known as Guest27445 [21:21] * ogasawara back on later === sconklin is now known as sconklin-gone [22:56] hi all! quick question: whch target do i need to build for an ubuntu kernel using debian/rules to get the linux-headers*_all.deb (binary-generic does not produce that deb)? [22:58] Specialist: do fakeroot debian/rules binary-headers binary-generic [22:58] jjohansen: thanks!