[09:35] <Ng> is it possible/likely that 2.6.30 is not switching off as much hardware for S3 suspend as 2.6.$jaunty was?
[09:35] <Ng> I suspended last night with 30 minutes of runtime left and my laptop was off this morning
[09:35] <Ng> I'm pretty sure that previously that would have been plenty
[09:49] <Kano> hi apw , i prepared a little patch for the double ids already
[09:50] <Kano> apw: http://kanotix.com/files/kernel/unused-patches/2.6.30-disable-some-rt2500usb-ids.patch
[09:50] <Kano> if you want to be able to compile fglrx with some tricks you need
[09:50] <Kano> http://kanotix.com/files/kernel/unused-patches/2.6.30-export-flush_tlb_page.patch
[09:51] <smb> Ng, It might be possible. You could do the suspend/resume tests which have one testcase that verifies power consumption to verify this further...
[09:51] <Ng> smb: oh interesting
[09:52] <Ng> powertop suggests that running power consumption is the same or slightly less than jaunty
[09:52] <Ng> but I don't exactly have hard numbers for how much power was used while suspended
[09:52] <Kano> for fglrx again is that patch: http://kanotix.com/files/kernel/unused-patches/2.6.29-ubuntu-copy-headers-for-fglrx.patch
[09:53] <Kano> then the needed patch is MUCH smaller
[09:54] <smb> Ng, the script would be in /usr/share/checkbox/scripts/suspend_test It would not be impossible to consume less power running but miss to power down something on suspend
[09:54] <Kano> i still need to create a patch to support fritz usb draft-n, maybe later...
[09:55] <Ng> smb: yeah that's what I figured. I think I know someone running equivalent hardware on jaunty, so I'll try to get some comparison figures. thanks :)
[09:56] <smb> Ng, But to have more confidence it likely would require to compare a few runs on both. I sometimes got quite a variation on the same hardware on several runs
[10:00] <Ng> smb: ok
[13:19] <lamalex> how do i check out the jaunty kernel repo? whats the clone url, its not shown in gitweb and im having trouble guessing it
[13:20] <smb> lamalex, git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty.git
[13:21] <lamalex> hm why isnt that working for me..
[13:21] <lamalex> ah, because im an idiot
[13:22] <lamalex> ive been typing http://. 
[13:22] <lamalex> I wish I could say it was morning and i just needed my coffee, but its after 2pm
[13:22] <lamalex> maybe I can say I haven't had lunch and im really hungry
[13:23] <smb> lamalex, Or maybe it is just Monday ;-)
[13:25] <lamalex> that works for me
[14:31] <apw> smb, anyone,  any of you heard of karmic kernels panicing with splash on boot on jaunty userspace (32bit)
[14:32] <smb> Hm, I feel like I heard of it, but I believe only from walking over the list with you
[14:33] <apw> smb ... yeah i feel it may be true.  cirtainly happening on my crashy laptop right now
[14:37] <smb> apw, awkward to debug... :/
[15:19] <amitk> apw, how would I go about looking at history of a file that is no longer present in the index? IOW, the file existed, but doesn't anymore. So 'git log foo.c' doesn't work.
[15:26] <smb> amitk, might "git log --follow -- foo.c" work?
[15:28] <amitk> smb: yup, that does it. Thanks
[15:29] <apw> the -- is the key ther
[15:29] <apw> as the file is definatly a file if it appears after the --
[15:30] <amitk> so --follow is the inverse operation of git format-patch -M, I guess.
[15:32] <smb> Hm, would that not be "similar"? As both follow/detect renames
[15:34] <amitk> smb: yes and no. patches created with 'git format-patch -M' will need to be tracked with 'git log --follow' to list the file renames.
[15:34] <amitk> so they are inverse operations in that sense, but I see what you mean.
[16:03] <Keybuk> did we lose the ftrace open patch?
[16:07] <CarlFK> not to be confused with the mentioned panic, I have my own: http://dpaste.com/52812/ [ 7776.273727] kernel BUG at /build/buildd/linux-2.6.28/net/core/skbuff.c:124!
[18:57]  * Keybuk tosses a random kernel patch into a PPA
[18:59] <Keybuk> if it works, it should make the populate_rootfs call async
[18:59] <Keybuk> of course, that's a very big if :p
[19:52] <cr3> hi folks, where can I find the kernel arguments which were passed when booting? I vaguely remember that information being available somewhere under /proc or somesuch
[19:52] <cr3> aha! nevermind, it was in /proc/cmdline... I was looking for *arg*
[20:46] <invisibill> Greetings ubuntu kernel devs:  I'm using "2.6.28-3-rt #12-Ubuntu SMP PREEMPT RT Fri Apr 17 10:09:12 UTC 2009 x86_64 GNU/Linux" kernel but it keeps freezing my fresh install of jaunty during any file download.  I'm tracking this thread http://ubuntuforums.org/showthread.php?t=1145879 and want to upgrade to the 2.6.30rc8 
[20:47] <invisibill> Is there a repo I can add to apt for this.  Or should I just download directly from the site? 
[21:23] <apw> invisibill, the mainline kernels can be gotten from the mainline kernels archive
[21:23] <apw> see this url for instructions: https://wiki.ubuntu.com/KernelMainlineBuilds
[21:26] <invisibill> thanks apw.  I'll try downloading the image file and installing it with dpkg.
[23:05] <Ng> good work on the grub2 packaging, upgrade worked fine here :)
[23:15] <Kano> well i use grub2 for ages now ;)
[23:16] <Kano> best remove the old menu.lst as soon as possible, because os prober from other distros will find otherwise outdated entries