[08:13] <fairuz> Hi, I got this when booting a linux kernel, http://pastebin.com/W7YyBM2n .. any idea?
[08:15] <jjohansen> fairuz: what does your grub entry look like
[08:19] <fairuz> jjohansen: I use uboot actually
[08:21] <fairuz> 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] <jjohansen> fairuz: ah did you get a typo in /dev/mmcblk0p2 maybe?
[08:23]  * jjohansen has very little experience with current arm
[08:23] <jjohansen> uboot etc
[08:23] <jjohansen> hrmm no, I see it mounted okay
[08:24] <fairuz> jjohansen: the /dev/mmcblk0p2 is correct
[08:24] <jjohansen> yeah
[08:24] <fairuz> jjohansen: it's just somehow can't start init?
[08:25] <jjohansen> 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] <fairuz> jjohansen: cool
[08:27] <jjohansen> fairuz: which os?
[08:27] <fairuz> jjohansen: android
[08:27] <fairuz> jjohansen: froyo
[08:27] <jjohansen> maybe /sbin/init?
[08:28] <fairuz> jjohansen: i'll try that
[08:35] <fairuz> jjohansen: I don't think so since the init executable is in /
[08:36] <jjohansen> fairuz: okay, well it was worth a shot, my next suggestion was mounting somewhere else and checking the init was in /
[08:37] <fairuz> 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] <fairuz> these files are useful to init?
[08:38] <jjohansen> fairuz: I assume so
[08:38] <jjohansen> :)
[08:38] <jjohansen> fairuz: it really depends on the init system
[08:39] <jjohansen> basically the kernel will exec init and then init can do what it wants
[08:39] <jjohansen> traditionally that is controlled /etc/init and .rc files etc
[08:39] <jjohansen> 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] <jjohansen> does the /init file has exec permissions?
[08:40] <fairuz> jjohansen: yes
[08:41] <jjohansen> what does file init report?
[08:44] <fairuz> jjohansen: sorry but I dont get what you mean. You mean the init log file or something like that?
[08:44] <jjohansen> no, run the file command on the init binary
[08:45] <jjohansen> eg.
[08:45] <jjohansen> > file init
[08:45] <jjohansen> init: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, stripped
[08:56] <fairuz> jjohansen: I have some other problems. Will get to you later. Btw, thanks for the help, really appreciate it.
[08:56] <jjohansen> fairuz: np, I hope you get it working, /me is interested as I expect to be having similar fun
[08:57] <fairuz> jjohansen: what arm platform you will be getting btw?
[08:57] <jjohansen> efika mx
[08:58] <fairuz> jjohansen: nice
[10:15] <fairuz> I got 2.6.38-00366-g65e01eb when i do uname -r. Is it weird or normal? :D
[10:16] <fairuz> Maybe I compile it wrong?
[11:59] <fairuz> I installed linux-headers-2.6.38-1204 but why it doesnt appear in /lib/modules/ ? 
[12:03] <jk-> fairuz: the -headers package doesn't provide any modules; what are you looking to find in /lib/modules?
[12:03] <fairuz> jk-: the headers file 
[12:04] <jj-afk> fairuz: linux-headers only installs into /usr/src/
[12:04] <fairuz> jj-afk: ok, my bad ty
[12:04] <jk-> fairuz: the headers will be in /usr/src/linux-headers-$version/
[12:04] <jk-> (there should be a symlink from /lib/modules/$version/build though)
[12:05] <jk-> fairuz: for future reference, `dpkg -L <package>` will list the files installed by a package
[12:05] <fairuz> jk-: Ah ok, thats will be useful
[12:07] <fairuz> I got Kernel Configuration is invalid error when compiling module using my new 2.3.38 kernel
[12:29] <fairuz> Hi, I got error: unknown field 'ioctl' specified in initializer when compiling a module on 2.6.38
[12:29] <fairuz> It compiles OK on 2.6.35
[12:36] <fairuz> Hmm they stop supporting ioctl in the file_operations?
[12:39] <fairuz> I found the solution in the git log, have to change ioctl to unlocked_ioctl :D
[13:11] <ogasawara> 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)
[13:13] <tgardner> ogasawara, how about the CONFIG_NR_CPUS patch thats still on the mailing list?
[13:14] <tgardner> bug #737124
[13:14] <ubot2> 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
[13:45] <tgardner> ogasawara,  CONFIG_NR_CPUS appears to be an ABI bumper
[13:45] <ogasawara> 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] <ubot2> 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] <tgardner> ogasawara, I think it was -server only
[13:46] <apw> yeah it was only server we applied it for
[13:46]  * apw isn't here
[13:46] <tgardner> ogasawara, rather, it was only applied to -server
[13:46] <ogasawara> tgardner: hrm, was hoping to not have an ABI bumper.  Can it wait till post beta?
[13:46] <tgardner> ogasawara, yep, I thingk so
[13:47] <ogasawara> 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] <tgardner> ogasawara, fire away
[14:27]  * ogasawara slaps forehead.  pulled the trigger too soon with the upload.
[14:27] <ogasawara> I should actually wait for the compiler to finish building for the other aches, sigh
[14:33] <mterry> 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] <Krunch> mterry: do you have the full oops message?
[14:40] <mterry> Krunch, I didn't write it down from the screen, no...  Is it written on my disk anywhere?
[14:41] <cnd> anyone know where to submit patches for latencytop?
[14:41] <Krunch> 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] <Krunch> mterry: without the oops message or the vmcore, there is probably not enough to write a bug report
[14:42] <cnd> actually, it looks kinda dead...
[14:42] <Krunch> mterry: look into netconsole to send the oops message (and all the console messages) to a remote system
[14:42] <soren> mterry: I usually take a photo with my phone and attach it to a bug report.
[14:43] <Krunch> and depending on the oops message, that might not be enough either
[14:43] <mterry> soren, good idea
[14:44] <mterry> Krunch, k, thanks.  (/var/log/kern.log is also there in Ubuntu, btw)
[14:59] <fairuz> Hi, if I do sudo dpkg --unpack file.deb, where the unpacked files will go?
[15:03] <sforshee> fairuz, I believe they go to the same locations as if you installed the package
[15:05] <bjf> fairuz, dpkg --extract unpacks them in the current folder
[15:06] <fairuz> sforshee: I found them in /boot 
[15:06] <fairuz> bjf: ok ty
[15:06] <diwic> cnd, hmm, isn't latencytop maintained by the Redhat Realtime group (or whatever they call themselves)?
[15:07] <cnd> diwic, maybe, but they have no info about that on their website
[15:07] <cnd> I have no clue who is the maintainer or how to contact them...
[15:07] <cnd> no changes to their git tree in 17 months either...
[15:08] <fairuz> 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] <diwic> cnd, hmm, actually it says Intel Open Source Group on the homepage...
[15:10] <diwic> cnd, so I'm correcting myself, the Redhat people probably does the hard realtime stuff rather than this
[15:11] <diwic> 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] <cnd> diwic, probably, but I'm just doing patch piloting
[15:12] <cnd> and the patch fixes a type in the man page
[15:12] <cnd> so I'm reluctant to put too much effort into it :)
[15:12] <diwic> cnd, ah, ok. Well, just send it to those two people and see what happens :-)
[15:16] <tgardner> ogasawara, I rebased Natty master-next against master and added the CONFIG_NR_CPUS=256 patch (after a bump ABI)
[15:16] <ogasawara> tgardner: ack, thanks
[15:19] <tgardner> 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] <ogasawara> tgardner: cool, I'll take a peek
[16:42] <ogasawara> tgardner: ukb-make works well for me
[16:43] <tgardner> 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] <tgardner> actually, natty armel schroots on Lucid build hosts
[16:46] <sconklin> ogasawara: welcome back!
[16:46] <ogasawara> sconklin: thank :)
[16:46] <ogasawara> thanks even
[17:17] <lil_pete> 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
[18:09] <cking> kentb, that vida is now en-route back to Dell
[18:09] <cking> cough
[18:10] <kentb> cking, thanks :)
[18:12] <xuru> 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/
[18:16] <xuru> when I do the make mrproper, it seems to blow away the debian directory
[18:17] <jjohansen> 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] <xuru> ok
[18:19] <xuru> any idea what's causing this in the first place?
[18:19] <xuru> seems to be pretty strait forward following https://help.ubuntu.com/community/Kernel/Compile
[18:20] <jjohansen> 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] <xuru> ok, I'll try doing the make mrproper and copying those files back
[18:27] <xuru> 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] <xuru> so it must be one of the two options I set that are causing the build error
[18:28] <xuru> I'll try adding in each one at a time and see
[18:38] <sforshee> xuru, it's probably the presence of the .config file that's causing the error
[18:38] <sforshee> there's a section on the page you linked to about how to change config options
[18:38] <xuru> oh?  must have missed that
[18:39] <sforshee> xuru, it's a little hidden, it's under "Modify the source for your needs"
[18:41] <xuru> ok, I thought that was just if you were making a special non-generic kernel
[18:41] <xuru> so x86_64 == ia64 or amd64?
[18:43] <jjohansen> amd64
[18:44] <xuru> k, thanks
[18:45] <xuru> is there a way to point make menuconfig to that config file?
[18:46] <xuru> nevermind, I can use the load alternate configuration option right?
[18:53] <xuru> is debian.master/config/config.common.ubuntu read in first?  and then debian.master/config/amd64/config.common.amd64?
[18:57] <ogasawara> 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] <ogasawara> bjf, sconklin: it's for "econet: Fix crash in aun_incoming(). CVE-2010-4342"
[18:57] <ubot2> 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] <bjf> ogasawara, go for it, that's what "master-next" is all about and we have started a new cycle
[18:58] <bjf> ogasawara, so we won't look at master-next until next week some tim
[18:58] <bjf> ogasawara, s/tim/time/
[18:58] <ogasawara> bjf: cool
[18:58] <tgardner> ogasawara, whats wrong with it?
[18:59] <ogasawara> tgardner: struct dst_entry *dst = skb_dst(skb);
[18:59] <ogasawara> tgardner: skb_dst() isn't defined in Hardy
[18:59] <tgardner> ogasawara, doh! I bet I used the Karmic patch.
[19:02] <tgardner> bjf, sconklin, shall I upload the Lucid/Maverick LBM packages with the new compat-wireless 2.6.38 support ?
[19:04] <bjf> tgardner, i think that's ok with me
[19:04] <sconklin> I can't think of a reason not to
[19:46]  * bjf -> lunch
[19:48] <kirkland> tgardner: is there a known reason why my CPU's load never goes below 1.00 on natty?
[19:48] <kirkland> tgardner: system is totally idle
[19:48] <kirkland> tgardner: but the lowest /proc/loadavg ever says is 1.00
[19:49] <kirkland> tgardner: model name      : Intel(R) Core(TM) i7 CPU       M 620  @ 2.67GHz
[19:49] <tgardner> kirkland, none that I know of. lemme check,
[19:50] <tgardner> 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] <kirkland> tgardner: hrm
[19:52] <kirkland> 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] <kirkland> kees: aha, found it in my log
[19:55] <kirkland> tgardner: ah, i see:
[19:55] <kirkland> $ ps auwwx | grep " D "
[19:55] <kirkland> root       701  0.0  0.0      0     0 ?        D    09:07   0:01 [ips-monitor]
[19:55] <kirkland> tgardner: what is ips-monitor?
[19:56] <tgardner> kirkland, intel power save (I think)
[19:56] <kirkland> tgardner: https://lkml.org/lkml/2011/3/19/37
[19:57] <tgardner> intelligent power sharing
[19:57] <kirkland> tgardner: https://lkml.org/lkml/2011/3/21/237
[19:57] <kirkland> tgardner: so it is "phantom" load, as suspected
[19:58] <kirkland> tgardner: still, annoying;  looks like Intel is looking for a fix
[19:59] <tgardner> kirkland, yep. 
[20:46] <kristian-aalborg> hi all, has anyone gotten apmd working?
[21:21]  * ogasawara back on later
[22:56] <Specialist> 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] <jjohansen> Specialist: do fakeroot debian/rules binary-headers binary-generic 
[22:58] <Specialist> jjohansen: thanks!