[02:07] <zul> hey
[02:11] <_ion> Hi
[07:49] <glick> hi
[07:53] <glick> hey is it hard to build the kernel in eclpise?
[07:53] <glick> eclipse?
[08:33] <glick> has anyone done any kernel dev with eclipse?
[08:59] <glick> damn, kernel development on my main machine is dangerous isnt it
[09:39] <superm1> BenC, did you get a chance to look over lirc patch i made this past week?
[09:41] <glick> hey im tryin to config a vanilla kernel
[09:41] <glick> its asking me at what physical address i want to load the kernel and i have no idea what i should put
[09:43] <crimsun> superm1: he's EDT, which is -0400 UTC. It's currently 3:43 AM.
[09:45] <superm1> crimsun, ah ok thx
[09:45] <superm1> crimsun, which reminds me - i should get to bed (i'm CDT :) )
[10:34] <glick> hey does anyone use eclipse for kernel dev?
[10:34] <fabbione> glick: please stop asking every hour.. people lives in different TimeZones and it can take over 24 hours to get an answer here
[10:35] <glick> fabbione, new people came in
[10:35] <glick> i thought they might know
[10:36] <crimsun> glick: well, the answer to your question is "yes". When I worked at IBM, quite a few people did (unsurprisingly). As for whether anyone present does, it's fairly unlikely.
[10:36] <fabbione> most of the kernel developers are in the US and won't be around for the next 5/6 hours
[10:37] <glick> you just use vim?
[10:39] <fabbione> i personally do yes
[10:40] <glick> but isnt that difficult if you need to cross check a symbol reference, or check the definition of a function or see what calls it?
[10:40] <crimsun> no, you can use ctags.
[10:40] <fabbione> matter of taste.. and i use grep...
[10:41] <fabbione> really.. developing is a matter of taste
[10:41] <fabbione> everybody has its own
[10:41] <fabbione> there is no standard
[10:41] <glick> so for someone new lookin to get grok the kernel should they look at vanilla or ubuntu kern?
[10:42] <fabbione> glick: it depends what you are going to do
[10:42] <fabbione> what do you plan to develop on the kernel?
[10:42] <glick> drivers mainly at this point
[10:42] <fabbione> new drivers or fixing bugs in existing ones?
[10:43] <glick> yeah both
[10:43] <fabbione> i would personally do it on vanilla because no matter how quickly we keep up with upstream, at some point in time our kernel is behind
[10:43] <fabbione> and driver interfaces might change in the meantime
[10:43] <fabbione> but nothing stops you to use both trees
[10:44] <fabbione> develop a fix in vanilla and push the patch to the ubuntu kernel
[10:44] <fabbione> it's fairly simple to do cherry picking with git
[10:44] <fabbione> anyway.. brb
[10:44] <glick> k
[11:06] <pkl_> glick: couple of answers....  The kernel physical location should be 0.  I personally use vim and grep.
[11:08] <pkl_> glick: unless you're working on drivers which Ubuntu has put into the driver (Ubuntu top-level directory), it doesn't really make much difference whether you're using the vanilla or Ubuntu version.  Ubuntu's kernel follows vanilla very closely.
[11:10] <maks_> pkl_ following closesly with a huge stack of patches on top
[11:10] <glick> pkl_, i thought < 16M was DMA pool?
[11:11] <crimsun> maks_: we don't touch the scheduler or the network stack, really, for starters.
[11:11] <crimsun> or the vm or many fses
[11:12] <pkl_> most of of Ubuntu's changes are in driver code.  Very little core code is touched.  Doesn't need to be, the core code is generally very stable and well written.  It is the drivers which are a mess, and need to be patched :)
[11:12] <maks_> plus adding oot mess :P
[11:18] <pkl_> glick: I should have asked which arch you're using :) PPC kernel physical address 0x0.  x86 phys address 0x00100000.
[11:19] <glick> x86
[11:20] <pkl_> I tend to use PPC (PowerPC) when talking about kernels internals.
[11:24] <pkl_> The x86 is the odd architecture, most architectures load at 0.  The x86 is 'special' because of BIOS and weird legacy restrictions (the 640KB -> 1MB hole).
[11:25] <glick> you do your dev on ppc?
[11:27] <pkl_> I used to (until last November).
[11:29] <fabbione> hey pkl_ 
[11:29] <fabbione> pkl_: how are your cluster testing going?
[11:30] <glick> damn eclipse is slow
[11:31] <glick> night
[11:34] <pkl_> fabbione: badly, too much work, too little time :)
[11:35] <fabbione> pkl_: what about tomorrow we setup an Oracle and one RH cluster together?
[11:35] <fabbione> pkl_: so that i can kick you off the first step
[11:38] <pkl_> fabbione: sounds good.  I'll see what else I've got to do on Tuesday.
[11:39] <fabbione> pkl_: just make sure you have 2 feisty machines uptodate.. no matter if they are desktop or server installs..
[11:39] <fabbione> then we figure it from there
[11:39] <fabbione> (better if they are in the same LAN/subnet)
[02:00] <shawarma> initramfs-tools is the kernel-team's "problem", no?
[02:04] <maks_> shawarma : yes
[02:04] <maks_> why what's up?
[02:06] <shawarma> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/101844
[02:07] <shawarma> It's easily reproducable. With a Feisty userland, run an Edgy kernel, run "update-initramfs -u" twice, and that's the last time you'll ever boot with that kernel.
[02:08] <maks_> shawarma the bak file should only get updated if there is a boot inbetween
[02:09] <shawarma> maks_: eh? the bak file is created by update-initramfs.
[02:09] <maks_> yes but only once
[02:09] <shawarma> per run of update-initramfs, yes.
[02:09] <maks_> no
[02:10] <maks_> shawarma can you attach please an sh -x update-initramfs -u run
[02:10] <maks_> i have only debian boxes
[02:11] <shawarma> maks_: Why would it not be updated with each run of update-initramfs?
[02:12] <shawarma> maks_: I need a minute to fire up the machine again.
[02:12] <maks_> shawarma look into backup_booted_initramfs
[02:12] <maks_> if it does what you say there is a bug there
[02:13] <maks_> shawarma: no hurry, but interested :)
[02:15] <maks_> ah it does exchange it because you rebooted inbetween
[02:15] <maks_> but it shouldn't do it now if you execute it 2x in a row
[02:15] <maks_> please post also the second sh -x update-initramfs run
[02:16] <shawarma> maks_: What exactly should stop it?
[02:18] <maks_> it only mv ak overwrites the .bak if boot_initramfs is defined
[02:18] <maks_> did you look at backup_booted_initramfs()?
[02:19] <shawarma> briefly. I thought it ran backup_initramfs
[02:21] <maks_> you want to checkout the section below "# keep booted initramfs"
[02:22] <shawarma> maks_: The fact remains that I end up with a trunced initrd, and the attached fix fixes it.  My analysis of why it goes wrong may be off, though.
[02:22] <maks_> shawarma np, please provide the further output
[02:22] <shawarma> the output of the two runs are identical.
[02:22] <maks_> sh -x update-initramfs
[02:23] <maks_> upps of course with -u
[02:23] <shawarma> Sure
[02:23] <maks_> i'd really appreciate if you attached that to the bug report :)
[02:24] <shawarma> Will od.
[02:24] <shawarma> do, even.
[02:25] <shawarma> done.
[02:28] <maks_> shawarma hmm this is your hacked update-initramfs
[02:29] <shawarma> No
[02:30] <shawarma> oh, wait.
[02:30] <maks_> shawarma it's ok i ack your patch
[02:31] <shawarma> what the.. I dpkg -i the initramfs-tools in my apt cache and it's still my patched u-i..
[02:32] <maks_> adding it to the debian repo atm and i'll remind BenC when he is around
[02:32] <shawarma> Cool.
[02:32] <shawarma> thanks.
[02:33] <maks_> won't push it for etch updates as in debian nobody uses the minversion, so i never saw that
[02:33] <maks_> thank you
[02:33] <shawarma> Any time.
[02:34] <shawarma> How do you work around udev's dependencies without it?
[02:39] <shawarma> There. updated the bug with proper logs. Silly me.
[02:56] <maks_> shawarma: we had no "real" udev upgrade now as sarge relied still on the hotplug scripts and currently i manage that by depending on newer udev simply
[02:57] <maks_> (speaking for the debian side of udev upgrades)
[02:59] <maks_> shawarm: please next time fix your patch to run diff -pruN initramfs-tools-0.85eubuntu8 initramfs-tools-0.85eubuntu9, then it can be easier applied from topdir i-t and -p is cool for showing modified functions, just as quick hint :)
[03:00] <maks_> s/shawarm/shawarma/ uups ^^
[03:07] <Nafallo> debdiff ftw
[03:56] <shawarma> maks_: Er.. Ok. I've always just used debdiff. I'll keep it in mind.
[04:08] <zul> BenC: ping
[05:54] <BenC> zul: pong
[05:55] <maks_> BenC i guess you have followed aboves backlog related to LP: #101844
[05:55] <zul> BenC: I should have the openvz tonight
[05:56] <BenC> maks_: no
[05:56] <maks_> BenC: ok so in short i ack the patch in aboves report
[05:56] <maks_> added the code to debian repo
[05:58] <BenC> maks_: Ok, thanks
[06:17] <jammcq> hey guys, i'm trying to track down a performance issue with a thin client. I'd like to build a kernel without debugging to see if that has any effect.  I've built several kernels using the Ubuntu wiki page, and i've had great success.  But if I try setting 'CONFIG_DEBUG_KERNEL=y' or '# CONFIG_DEBUG_KERNEL is not set', I get an error after about 40 minutes saying:   "module has gone missing: dccp_probe"
[06:17] <jammcq> err, s/=y/=n/
[06:41] <zul> happy joy joy
[08:00] <mathrick> hi, why doesn't Feisty let me eject mounted CDs anymore? It was there in edgy, and disappeared in feisty
[08:00] <mathrick> AFAIK, it was some kind of kernel patch (not surprisingly), so whatever happened to that?
[08:28] <zul> BenC: ping is it ok if the openvz creates a linux-image.deb?
[09:28] <newz2000> I want to try and help get my bugs fixed, how do I test the -14 kernel?
[09:28] <newz2000> oh, there's a link to the wiki...
[09:30] <newz2000> ok, I give up... how do I try out the 2.6.20-14.22 kernel?
[09:31] <Nafallo> oh. kewl
[09:31] <Nafallo> 14 is out :-)
[09:31] <newz2000> Nafallo: do you know where those are stored?
[09:32] <Nafallo> oh, new ABI... so in the NEW-queue :-(
[09:33] <Nafallo> should be a way to find them on launchpad though :-)
[09:36] <Nafallo> https://launchpad.net/ubuntu/+source/linux-source-2.6.20/2.6.20-14.22
[09:37] <Nafallo> then click on the corresponding buildlog for your architecture
[09:38] <Nafallo> oh. still builds...
[09:39] <Nafallo> anyway, if it's finished you just click the resulting binary -)
[09:42] <maks_> how can i in list all initramfs-tools bug reports in launchpad?
[09:43] <Mithrandir> maks_: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/
[09:44] <newz2000> I've got two outstanding problems I'm eager to help fix... both work in past kernels
[09:45] <maks_> Mithrandir thx
[09:45] <newz2000> no sound --> works fine when I boot into 2.6.17 and can't suspend --> works fine in 2.6.20-12
[09:46] <crimsun> "no sound" isn't quite helpful.
[09:46] <newz2000> I've got a bug report, looking for it now
[09:47] <newz2000> crimsun: #92171
[09:47] <crimsun> bug 92171
[09:47] <crimsun> oh, right, bot thing.
[09:47] <newz2000> crimsun: a moment ago I booted into 2.6.17-10 and the sound worked great
[09:48] <newz2000> now in 2.6.20 with every volume control full blast its a faint whisper
[09:48] <newz2000> alsamixer has a "master" volume control but I can't change it... it has no bar graph, and the numbers stay at 00
[09:48] <crimsun> yes, that's the ff10 change.
[09:49] <crimsun> I'll just revert it for Feisty, and we'll live with whatever breaks for the newer laptops.
[09:49] <crimsun> "it" -> addition of ALC66x/86xVD support, aka WildWets
[09:49] <crimsun> WildWest, even.
[09:50] <crimsun> the "no audio on resume" issue is known, and it won't be fixed for Feisty.
[09:51] <newz2000> I think with the most recent edgy kernel that went away for me
[09:51] <newz2000> crimsun: I don't suppose you're able to help at all with bug 96679 are you?
[09:51] <newz2000> acpi related
[09:51] <newz2000> it works great in -12, but not in -13
[09:52] <crimsun> newz2000: not my realm, sorry.
[09:52] <newz2000> ok. Is this the right place? Or does acpi stuff go to a different irc channel?
[09:52] <crimsun> this is the right place.
[09:54] <mjg59> So going back to -12 definitely results in it working?
[09:54] <newz2000> mjg59: yes, tested a few minutes ago
[09:55] <newz2000> in -11 I could only suspend once, after that shutting my laptop just locked the screen. But with -12 I could open and close as much as I wanted.
[09:55] <newz2000> -13 results in a hard lock when I shut the lid
[09:56] <newz2000> mjg59: if there's any info I can provide you, I have some time to test now
[09:56] <mjg59> Weird. Nothing in the changelog that looks even vaguely relevant.
[09:56] <mjg59> Can you try:
[09:56] <mjg59> Going to a console, becoming root, and doing echo -n mem >/sys/power/state
[09:57] <mjg59> And then letting me know what happens
[10:04] <newz2000> mjg59: running that command caused my computer to suspend immediately. When I resumed, the screen didn't come back on. However, it appears the computer did a graceful shutdown when I hit the power button.
[10:04] <newz2000> it sounded like my computer was working though
[10:05] <mjg59> Ok. So that makes it sound like the kernel isn't too much of a problem.
[10:05] <newz2000> do other things change when I boot into a different kernel with grub?
[10:05] <mjg59> So, next thing - can you edit /etc/default/acpi-support
[10:06] <mjg59> And change USE_DPMS to false
[10:06] <mjg59> Then edit /etc/acpi/sleep.sh
[10:06] <mjg59> And just above where it says DeviceConfig add a line saying
[10:06] <mjg59> set -x
[10:07] <mjg59> Then, again at a console as root, do /etc/acpi/sleep.sh force
[10:08] <newz2000> ok, here it goes
[10:13] <newz2000> mjg59: ok, that time the screen went to a blinking cursor in the top left, it never suspended. After a minute I hit Alt+F1 and got a console login. I hit Alt+F7 and then my computer appearded to freeze, I had to hold the power button in to shut down
[10:14] <mjg59> newz2000: Ok. Can you do that again, do the alt+f1 thing, do dmesg >~/dmesg.out, ps aux >~/ps.out, sync, reboot and then put those files up somewhere?
[10:14] <newz2000> sure
[10:15] <newz2000> what was the command I ran before?
[10:15] <newz2000> oh, found it
[10:15] <newz2000> brb
[10:17] <newz2000> mjg59: that time it worked fine
[10:18] <mjg59> newz2000: Ok. Repeat until it breaks :)
[10:18] <newz2000> ok
[10:22] <newz2000_> mjg59: ok, that time it broke.
[10:22] <mjg59> newz2000_: Excellent
[10:23] <newz2000_> Alt+F1 switched me to a console, but I couldn't log in. My keyboard only allowed Alt+F1-AltF7. 
[10:23] <newz2000_> Alt+F7 again froze the computer and I could do nothing
[10:24] <mjg59> Ok. Edit /etc/acpi/suspend.d/75-console-switch.sh and comment out the "chvt 12" line
[10:24] <mjg59> You're triggering the suspend from the console, not X, right?
[10:24] <newz2000> no, I'm in x
[10:24] <newz2000> should I try it from a console before I do this?
[10:25] <mjg59> Yes, you have to do this from a console
[10:25] <mjg59> But make that change first
[10:25] <newz2000> ok
[10:25] <mjg59> Basically, I want to know what the last few lines of output are
[10:35] <newz2000> mjg59: ok, I thought I could tee the output of that, but apparently not...
[10:36] <newz2000> near the end I got two alsa errors (command not found) then the last thing was a for loop... I think it was refering to for SCRIPT
[10:36] <newz2000> amixer command not found twice
[10:37] <newz2000> (amixer errors were followed by the for loop)
[10:37] <newz2000> is that detailed enough? If not, I may be able to redirect stderr to stdout and try tee again
[10:39] <mjg59> Can you boot without the "quiet" option and try again?
[10:40] <mjg59> And also edit /etc/acpi/suspend.d/90-framebuffer-stop.sh and comment out everything in it
[10:40] <newz2000> yep
[10:41] <newz2000> finally, a graceful reboot. :-) brb.
[10:46] <newz2000> mjg59: ok, I'm back
[10:46] <mjg59> newz2000: Excellent
[10:53] <mjg59> newz2000: Had a chance to test that?
[10:53] <newz2000> mjg59: test what?
[10:53] <newz2000> what was I supposed to do after I rebooted? I must have missed an instruction
[10:53] <mjg59> 21:40 < mjg59> And also edit /etc/acpi/suspend.d/90-framebuffer-stop.sh and  comment out everything in it
[10:53] <newz2000> yes, I did that too
[10:54] <mjg59> Then, from a console, do /etc/acpi/sleep.sh force
[10:54] <newz2000> oh, ok. just a min, will try
[10:59] <newz2000> mjg59: got it. The last bits are:
[10:59] <newz2000> ++ . /etc/acpi/suspend.d/85-alsa-state.sh
[10:59] <newz2000> +++ '[' -x /etc/init.d/alsa-utils '] '
[10:59] <newz2000> +++ /etc/init.d/alsa-utils stop
[10:59] <newz2000>  * Shutting down ALSA...                                                        amixer: Invalid command!
[10:59] <newz2000> amixer: Invalid command!
[10:59] <newz2000>                                                                          [ OK ] 
[10:59] <newz2000> ++ for SCRIPT in '/etc/acpi/suspend.d/*.sh'
[11:00] <newz2000> ++ . /etc/acpi/suspend.d/90-framebuffer-stop.sh
[11:00] <newz2000> + '[' x = xtrue '] '
[11:00] <newz2000> + echo -n mem
[11:00] <mjg59> And then it hangs?
[11:00] <newz2000> yes
[11:01] <newz2000> I can still Alt+F? but thats it
[11:01] <mjg59> Ok. Now you get to go through each of the files in /etc/acpi/suspend.d and see which of them is breaking it...
[11:01] <newz2000> and if I hit Alt+F7 I'm really stuck
[11:01] <newz2000> :-)
[11:01] <newz2000> so for each, should I just put a little echo statement to differentiate them? See which one is last
[11:02] <mjg59> No, they're all running
[11:02] <mjg59> Disable each of them in turn
[11:03] <newz2000> whats the best way to disable, rename to *.sh~ or comment out the lines or something else?
[11:03] <mjg59> Yeah, change the name so they don't end in .sh
[11:03] <newz2000> ok
[11:06] <newz2000> ok, trying again, brb I think. :-)
[11:11] <newz2000> mjg59: that was easy... with all disabled, it still freezes. Just much sooner this time.
[11:11] <mjg59> newz2000: But echo -n mem >/sys/power/state always works?
[11:12] <newz2000> well, we tried it that one time adn it went ok (except I couldn't resume)
[11:12] <mjg59> Yes
[11:12] <mjg59> At this point, that should be basically all that the script is doing
[11:12] <mjg59> Can you try it a few more times?
[11:13] <newz2000> try echo -n mem >/sys/power/stat
[11:13] <newz2000> ?
[11:15] <newz2000> mjg59: btw, here's the output of /etc/acpi/sleep.sh force  http://people.ubuntu.com/~mnuzum/tmp/sleep.txt (with a.. .sh disabled)
[11:15] <newz2000> trying echo -n...
[11:17] <mjg59> newz2000: Looks like it's doing pretty much nothing other than the echo
[11:20] <newz2000> mjg59: ok, echo -n mem didn't work... I got stuck at the console again with only Alt+F? working
[11:25] <mjg59> Ok. So it's the kernel.
[11:25] <mjg59> When you get to that point, can you do alt+sysrq+t and see what shows up?
[11:26] <newz2000> sure, never done that before
[11:39] <newz2000> mjg59: sorry for delay, fsck had to run. Alt +SysReq + t didn't show anything
[11:44] <mjg59> Hm. Ok, all I can suggest is trying -14 when it hits the archive
[11:45] <newz2000> ok. mjg59 any idea when thats coming?
[11:48] <mjg59> Next few hours
[11:48] <mjg59> It's uploaded, just needs to finish building and get through NEW
[11:48] <newz2000> cool, that gives me something to look forward to
[11:48] <newz2000> Guess I'll undo all our changes then