[02:11] <bryce> ogasawara, thanks for the kernel for bug 419264 - I'm testing it now, so far so good
[02:11] <ubot3`> Malone bug 419264 in linux "Uses 100% CPU with latest mesa/libdrm update" [High,In progress] https://launchpad.net/bugs/419264
[02:12] <ogasawara> bryce: ok cool.  let me when your finished with the testing and assume the results are good, I'll submit for inclusion in karmic.
[02:13] <bryce> will do
[02:14] <bryce> ogasawara, btw, we'll be discussing this bug at the 9:30am desktop team meeting tomorrow, in case you would be interested in poking your head in.
[02:14] <ogasawara> bryce: sure, I'll try and sit in.  I have a ubuntu dev week class I have to teach at 10am so may have to drop out.
[06:02] <ericm> anyone knows how to extract the initramfs from a zImage binary?
[06:02] <jk-> ericm: not off the top of my head, but should be doable with a couple of 'objcopy's
[06:03] <ericm> y, I think so - wondering if there is simple command for that
[06:26] <jjohansen> ericm: if the initramfs in builtin to the kernel it is in the section .init.ramfs
[06:26] <jjohansen> readelf should give you the ranges to grab
[06:26] <ericm> jjohansen: ok, let me try
[06:27] <jjohansen> and then you should just be able to cpio --extract the data
[06:30] <ericm> objdump reported not recognized file format - stumped - weird image binary
[06:32] <jjohansen> is it gziped?
[06:33] <jjohansen> what does head of the file show, or if that is garbage head <file> | hexdump -C
[06:34] <ericm> let me see
[06:35] <ericm> if that's gziped, 'file' should give me some hints
[06:35] <ericm> 00000000  00 00 a0 e1 00 00 a0 e1  00 00 a0 e1 00 00 a0 e1  |................|
[06:35] <ericm> *
[06:35] <ericm> 00000020  02 00 00 ea 18 28 6f 01  00 00 00 00 24 1e 12 00  |.....(o.....$...|
[06:35] <ericm> 00000030  01 70 a0 e1 02 80 a0 e1  00 20 0f e1 03 00 12 e3  |.p....... ......|
[06:36] <ericm> mmm... this makes sense - the 00 00 a0 e1 stands for a jump instruction in ARM - and that's where the vectors are
[06:37] <jjohansen> yeah, extracting from that is not going to as straight forward as an elf
[06:38] <ericm> yes - the final zImage of ARM did append some raw code ahead - just like head.S in x86
[06:39] <ericm> I guess I have to find out the original source instead of dis-section this binary into known pieces
[06:40] <jk-> you could find the gzip header, and extract from there on
[06:41] <jk-> 0x1f 0x8b, I think
[06:59] <ericm> jk-: that's useful, I extract a gz file from there, however, 'file' still thinks it's a 'data' file, but it looks a bit closer :)
[07:01] <ericm> I doubt that's a correct 0x1f 0x8b - since there are many of them - but at least looks like a most correct one to me, though
[07:18]  * amitk wonders what ericm and jjohansen are upto
[07:19]  * jjohansen has no idea what ericm is up to
[07:19]  * jjohansen is looking at config diffs for xen
[07:20]  * ericm gave up dissection that binary
[08:31] <amitk> ikepanhc: when you send a multi-patch series, could you consider using the --in-reply-to option of git-send-email? That makes sure that 1/n...n/n come as a reply to 0/n and the email client keeps them together.
[08:31] <amitk> ikepanhc: http://pastebin.ubuntu.com/262954/ is a script that I use to ease that process.
[08:32]  * ikepanhc reading
[08:32] <ikepanhc> amitk: thanks, I remember you have told me once before
[08:34] <amitk> ikepanhc: it just makes it easier to follow threads.
[08:34] <ikepanhc> amitk: got it
[08:38] <ericm> anyone knows if grub is able to run on top of an existing kernel and load another kernel via kexec?
[08:38] <amitk> ericm: why do you want grub to kexec to another kernel? the old kernel can do so itself.
[08:40] <ericm> this way - the old way of kernel loading by grub - let's say config files and kernel build scripts (grub hooks) needn't be changed?
[08:41] <ericm> grub is actually runnable as an individual console application - just wondering if kexec can be added
[08:41] <amitk> I am not sure what you are trying to do. But from Karmic onwards (?) we use kexec in our reboot init scripts. /etc/init.d/kexec*
[08:42] <ericm> OK, let me take a look
[09:07] <amitk> smb: what does PREFIX do in printk(KERN_INFO PREFIX ....);
[09:07] <smb> amitk, ADD a "ACPI: "
[09:08] <amitk> ok
[09:19] <shobhit> can any one tell me where do i find this flag named as "PSEUDO_RANDOMLY_DISCHARGE_BATTERY" ?I need to set this flag to 0 during recompilation.
[09:20] <shobhit> I heard that by setting this to 0 and recompiling the kernel,i will get a better battery life.
[09:20] <amitk> shobhit: please don't depend on slashdot.org for your daily dose of technology. :)
[09:22] <shobhit> amitk: Is it so?but why?
[09:22] <amitk> shobhit: because someone was making a joke there.
[09:23] <shobhit> amitk : what?are you sure about that?
[09:23] <amitk> Doesn't the name PSEUDO_RANDOMLY_DISCHARGE_BATTERY tell you so?
[09:26] <shobhit> Oh!!! you are right i guess....:-)
[09:28] <shobhit> and can you suggestl me any method to increase the battery life in ubuntu 9.04?
[09:29] <amitk> shobhit: use powertop and follow its suggestions. If you are happy with them, then make them permanent by putting in /etc/rc.local
[09:33] <shobhit> amitk: thnx... :-)
[09:58] <AnAnt> Hello, is there hope that this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/417748 gets implemented in karmic ?
[09:58] <ubot3`> Malone bug 417748 in linux "Please enable CONFIG_USB_DEVICEFS" [Medium,Triaged] 
[10:06] <amitk> AnAnt: That is a deprecated kernel feature. The application should be fixed to use the new way to probe usb devices. Hence I am loathe to fix it in karmic
[10:07] <AnAnt> will it hurt to enable the feature in karmic ?
[10:07] <amitk> But I'll send a patch to fix it if you promise to contact the application writer to fix their apps
[10:08] <amitk> AnAnt: applications don't get fixed if we keep supporting old features forever. I'll send a patch recommending that this be enabled for Karmic only.
[10:10] <AnAnt> ok, I'm finding out how to contact them
[10:14] <AnAnt> amitk: ok, do you know what I should tell them ?
[10:16] <AnAnt> amitk: I mean, what's the new way to probe usb devices (if you can provide any links...)
[10:17] <amitk> AnAnt: tell them that USB_DEVICEFS is now deprecated and they should use libusb and udev to probe for usb devices
[10:17] <AnAnt> amitk: thanks
[10:17] <amitk> I've made some comments on the bug if you want to point them to it
[10:32] <AnAnt> thanks, I've submitted a service request there !
[12:11] <smulcahy> hi, i'm having problems getting the forcedeth module to use options at boot-time (using 8.10). I've put them in /etc/modprobe.d/options but they seem to get ignored.
[12:11] <smulcahy> Do I need to do anything special to pass options to a kernel module in 8.10 ?
[13:18] <amitk> hmm, where did the rebase-branch script disappear?
[13:20] <smb> amitk, After getting rid of all-including-debian and having moved to debian.* there was no need for it anymore
[13:37] <amitk> we still require to rebase the branches, I guess they are to be done manually
[13:41] <smb> Yes, but as branch specific things are in a directory which is independent from the main branch. A simple git rebase should work without too much trouble
[13:49] <NCommander> bjf-afk, ping, do you know if a kernel upload is planned before A5 for dove?
[15:55] <haruspexed> hei, 2.6.31rc8 fails with dkms at nvidia 185.18.14 module build with "bad exit status:10"... is that kernel fault or mine? :/
[16:11] <SlickT10> Hey guys, Ive exuasted every resource on this issue. Ive run out of leads, and have no idea where to go next. Im not expecting you guys to have to give me support on this one, but maybe at least point me in the right direction. It is important that I get this working. The question has been posted at: https://answers.launchpad.net/ubuntu/+question/81460. No one in the #ubuntu support channel even notice my inquiries, i think thats due to the highl
[16:21] <amitk> SlickT10: it is better to file a bug in launchpad since IRC makes a very bad bug tracker. answers.lp.net allows you to create a bug out of this very easily.
[16:21] <mjg59> It's a bug in the kernel, probably in pciehp
[16:22] <mjg59> Likely to be related to the firmware tables in the Mac
[16:24] <SlickT10> hmm,
[16:24] <mjg59> Might be acpiphp, though
[16:25] <mjg59> File a bug with the full dmesg output
[16:25] <SlickT10> ok
[16:25] <SlickT10> thanks
[16:25] <SlickT10> i finally now have a next step
[16:26] <junior1> help with kernel issue...  My CPU locks up and gives me flashing scroll and caps lock... any ideas??
[16:26] <mjg59> SlickT10: Any time something straightforward doesn't work without you having to try to reconfigure stuff, file a bug
[16:27] <SlickT10> ok, not just put it answers.launchpad
[16:27] <SlickT10> im at work right now, but during lunch ill post it as a bug with full dmesg
[16:32] <smb> junior1, That is a kernel panic. If you can repeatedly get into this state you might switch to a console before this happens to see the error message
[16:33] <smb> mjg59, Do you thing acpi=noirq might be worthwhile to try for SlickT10 ?
[16:35] <mjg59> smb: Worth a go, but if it's using acpiphp then I suspect it still won't have a lot of luck in finding an IRQ
[16:37] <SlickT10> ill try that, but I think I may have already tried that one
[16:40] <smb> If it is acpiphp there seems to be a debug option... acpiphp.debug=1 
[18:19] <EagleScreen> hi
[18:19] <EagleScreen> are we on kernel bug day session?
[19:00] <ogra> bjf, http://paste.ubuntu.com/263307/ :(
[19:00] <ogra> lots and lots of that in my dmesg
[19:01] <bjf> ogra, sigh
[19:01] <ogra> yeah
[19:01] <ogra> its under heavy load though
[19:02] <ogra> i havent seen it before
[19:02]  * ogra is building webkit atm ... running since about 6h
[19:02] <ogra> system is permanently at 100% CPU
[19:51] <JFo> ogasawara, I am once again available for bug work
[19:52] <ogasawara> JFo: sweet!  good timing, today is a bug day.
[19:52] <JFo> oh excellent
[19:52] <JFo> :)
[19:52] <ogasawara> JFo: take a look at https://wiki.ubuntu.com/KernelTeam/BugDay/20090901
[19:52] <JFo> ok
[19:53] <ogasawara> JFo: that'll just explain what we're focusing on for the bug day today and eventually point you at http://qa.ubuntu.com/reports/ogasawara/kernel-bugday/20090901.html
[19:53] <JFo> okey dokey
[19:53] <ogasawara> JFo: the Community section could definitely use some help
[19:54] <JFo> right, I'll start looking at that then
[19:54] <ogasawara> JFo: awesome, lemme know if you have any questions
[19:54] <JFo> I certainly will
[20:16] <rtg> ogasawara, Linus picked up Anholt's i915 fence patch already.
[21:13] <ogasawara> rtg: ah cool, then disregard that pull request
[21:14] <rtg> ogasawara, too late, but it should be ok
[23:55] <tewk> looking for the latest suspend/resume debugging guide for karmic.