=== ogasawara_ is now known as ogasawara
=== mns` is now known as Guest58915
=== Guest58915 is now known as mns`
[03:19] <jk-> hey
=== mns` is now known as Guest27359
[07:04] <ppisati> morning
[07:04]  * ppisati upgrades to Natty
[08:15]  * apw yawns ... sooo very tired
[08:27]  * jk- waves
[08:30] <apw> moin jk- back ok ?
[08:31] <jk-> heya apw. yeah, all went well.
[08:31] <jk-> just need to not be sleeping on the keyboard
[08:33]  * smb drags himself in
[08:35] <ppisati> doh! mumble recalibration...
[08:35] <smb> ppisati, At least I heard you
[08:38]  * apw has to rebuild his office, bah
[08:38] <smb> apw, Was it "cleaned up"?
[08:38] <apw> yep, nice and shiney
[08:38] <smb> ...and nothing to be found anymore. :-P
[08:39] <ppisati> you lucky, i should clean mine :)
[08:39] <apw> not a thing, including my headphones
[08:39] <smb> ppisati, If you do it yourself you tend to know where tings are after the process. On the other hand... ;)
[08:41] <apw> ... once everything is gone you don't have to worry
[08:41] <Luca> Hi! I'm trying to figure out why my system, which has an ATI with opensource drivers installed, cannot boot the kernel 2.6.38 without having to set the nomodeset parameter. The same happens when I try to use USB pendrive with fresh installation of 10.04. Is there anyone who knows anything about this issue?
[08:41] <ppisati> smb: actually i developed an efficient loosing stuff algorithm, so even if i tidy by myself, i tend to loose stuff :)
[08:48] <tjaalton> yawwn^2
[08:49] <tjaalton> Luca: what happens without nomodeset, black screen?
[08:50] <Luca> On my notebook with kernel 2.6.38 I have a screen screwed up (I see some violet on the screen) and the boot stops there, shortly after grub. With a USB pendrive black screen (the USB pendrive is working with 10.10).
[08:52] <tjaalton> is it 32 or 64bit?
[08:52] <tjaalton> installation
[08:52] <Luca> 32bit
[08:53] <Luca> On the same system, the old kernel 2.6.35 is working ok.
[08:53] <tjaalton> you could try a mainline build: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.39-rc7-oneiric/
[08:54] <tjaalton> install linux-image-2.6.39...deb and boot it without nomodeset
[08:54] <Luca> ok, I'll try this
[08:54] <Luca> thanks
[09:09] <tjaalton> Luca: btw, is there a bugreport about this?
[09:11] <Luca> I've been trying to find something already filed and I found many things similar, but I don't know if those are the same or not. I don't even know whether this is related to the kernel or to the graphics drivers. I'm experiencing other issues as well with the new 11.04.
[09:12] <tjaalton> best to file a new bug
[09:32] <Luca> Sorry, I've never installed a kernel without apt-get. Is there anyway a guide on what I should do to boot the kernel installed from .deb?
[09:33] <_ruben> installing a kernel via apt-get or dpkg doesn't make a difference really
[09:36] <apw> tjaalton, another radeon modeset regression ... sigh
[09:37] <tjaalton> apw: this one? looks like it yeah
[09:37] <tjaalton> could be the grub handoff code messing it too?
[09:37] <tjaalton> Luca: dpkg -i linux-image..deb
[09:38] <apw> tjaalton, good point ...
[09:39] <tjaalton> hmm, /etc/default/grub should really have the GRUB_GFXPAYLOAD_LINUX= commented out, I keep forgetting what the option is called :)
[09:40] <tjaalton> Luca: so you could try adding 'GRUB_GFXPAYLOAD_LINUX=text' to /etc/default/grub, run 'update-grub' and boot the default natty kernel without nomodeset option
[09:41] <Luca> thanks, I'll try this as well. Sorry, I'm quite slow cause I'm at work as well :-)
[09:42] <tjaalton> you can do work later ;)
[09:43] <Luca> :-) Can I add that line wherever? Or is the order important?
[09:43] <apw> Luca, it should already be there commented out
[09:43] <tjaalton> it should? ok, maybe my version is old then
[09:44] <Luca> In /etc/default/grub? I don't have it there...
[09:44] <tjaalton> Luca: would be nice to know if the .39-rc kernel worked out-of-the-box
[09:44] <tjaalton> if not, then try adding the grub option
[09:44] <Luca> Ok, I'm trying that as well.
[09:45] <Luca> I'm removing that line.
[09:45] <tjaalton> nomodeset I hope?
[09:46] <Luca> I mean GRUB_GFXPAYLOAD_LINUX=text
[09:46] <tjaalton> ah you added it already, k
[09:46] <Luca> Ok, see you soon, rebooting now.
[09:50] <Luca> seems very good now!
[09:51] <Luca> uname -r confirms I'm running the 2.6.39...
[09:52] <tjaalton> oh good
[09:52] <tjaalton> and without nomodeset?
[09:55] <Luca> I assume yes. I don't see the parameter set in grub.cfg.
[09:55] <tjaalton> cat /proc/cmdline would confirm that
[09:55] <Luca> And I'm running Unity, which I saw it wasn't possible with nomodeset.
[09:55] <tjaalton> alright
[09:55] <Luca> BOOT_IMAGE=/boot/vmlinuz-2.6.39-020639rc7-generic root=UUID=4635bd6c-8c24-4f5f-b2f6-02c1bd5d5ec8 ro quiet splash vt.handoff=7
[09:55] <Luca> seems ok!
[09:55] <tjaalton> yep
[09:56] <Luca> Thanks for your help!
[09:56] <tjaalton> not so fast :)
[09:56] <Luca> yes
[09:56] <tjaalton> i'd like to have the kern.log or dmesg output from when you boot the stock natty kernel
[09:57] <Luca> so, I have to reboot with 2.6.38 and send you that right?
[09:57] <tjaalton> yes
[09:57] <Luca> no problem
[09:57] <tjaalton> do the VTs work?
[09:58] <Luca> should I remove the current ones I have?
[09:58] <Luca> sorry, what's VT
[09:58] <Luca> ?
[09:58] <tjaalton> or can you log in remotely (ssh)
[09:58] <tjaalton> virtual terminal (ctrl-alt-F[1-6])
[09:59] <Luca> Sorry, not following you... :-) Yes, those are working.
[10:00] <Luca> Oh, OK, now I get it.
[10:01] <tjaalton> but they probably don't work with the broken kernel
[10:01] <Luca> If I boot with 2.6.38 VTs are not working and I already tried ssh as well.
[10:01] <Luca> is kern.log removed in the following reboot?
[10:01] <tjaalton> ssh isn't working either, and you have openssh-server installed?
[10:01] <Luca> I have a ssh server yes.
[10:02] <tjaalton> no, /var/log/kern.log is rotated, so it could be renamed but not removed
[10:02] <tjaalton> and ssh doesn't work while it's in the "state"
[10:02] <tjaalton> ?
=== yofel_ is now known as yofel
[10:03] <Luca> I remember I tried once but I couldn't connect.
[10:03] <tjaalton> ok, maybe it crashed hard then
[10:03] <tjaalton> anyway, boot that kernel, try ssh and if it doesn't work, boot the good kernel and find the /var/log/kern.log.* that has the information from the bad kernel..
[10:04] <Luca> ok, no problem.
[10:04] <tjaalton> then file a bug by running 'ubuntu-bug xserver-xorg-video-ati' and attach the logfile after you've filed it
[10:04] <Luca> very good
[10:05] <tjaalton> even though it's a kernel bug this will gather more information of the machine
[10:05] <tjaalton> i think..
[10:05] <Luca> anyway, I was having some other troubles I've never had with graphics drivers. I don't know if those were related. I'll test this new kernel and see if those are still there.
[10:06] <tjaalton> ok
[10:08] <Luca> I'll file the bug as soon as I get home. Thanks for the help!
[10:08] <tjaalton> ok, good
[10:09] <Luca> oh, and I asked for help on askubuntu as well for this issue, no answers. Can I report there I solved with this new kernel?
[10:09] <tjaalton> sure
[10:10] <Luca> very well! Thanks again!
[10:19] <ricotz> hi, is someone having problems using intel 4965agn wlan-adapter with 2.6.39? 
[10:20] <apw> i've not heard any specifici reports no, but not many would be running that
[10:22] <ricotz> it seems to recognize everything, but while trying to connect it timesout
[10:23] <ricotz> it is working on 2.6.38, it is seems to be related to the driver split in iwl-legacy and iwl-*
[10:23] <smb> Hm, someone had intel wireless on UDS and similar issues, but I cannot say exactly which model and which exact kernel
[10:25] <smb> But I believe it was Natty, so it would be .38...
[10:29] <smb> dmesg would show some authentication going on the then something with disconnect reason 6... 
[10:36] <ricotz> smb, it could be the hardware connection can be established, and maybe the wpa_suppliciant fails
[10:37] <smb> Yeah, in that case it was on a conference. So a lot of (wireless)-noise going on. Which could be hinting to the callibration there...
[10:38] <ricotz> http://paste.debian.net/117092/
[10:38] <ricotz> hmm, could be the same here
[10:39] <ricotz> so *.39 changed some condition which breaks it totally
[10:41] <smb> While the symptoms sounds similar I am pretty sure the other case was .38 and the message looked different to yours. 
[10:41] <ricotz> this is with network-manager 0.9rc, but it was same with 0.8.4
[10:41] <apw> ricotz, if we know it works in .38 and not 39-rc might be worth checking the mainline builds between to see where it broke
[10:42] <smb> Roughly the problem looks like to be the kernel driver 
[10:42] <ricotz> apw, i build
[10:42] <ricotz> oop
[10:42] <ricotz> s
[10:42] <apw> you could try the ones in the mainline archive
[10:42] <ricotz> apw, i built the kernel regulary since rc4 and the problem was there already
[10:43] <ricotz> apw, i checked the build from yesterday
=== cking_ is now known as cking
[11:37] <ppisati> ok so, about oneiric/ti-omap4
[11:38] <ppisati> i'm going to pull the same tree that we have in natty
[11:38] <ppisati> just as a placeholder
[11:41] <apw> ppisati, i am unsure if it matters or not to have that until we upload (here i am assuming you mean to push into the ubuntu-oneiric repo)
[11:41]  * apw finally realises why git seems so slow in the morning ... relatime
[11:41] <ppisati> yeah, i mean push
[11:41] <ppisati> but i didn't get your comment
[11:41] <apw> pretty much the first commit i do reads every time, and triggers a write to the inode for every single one
[11:42] <apw> ppisati, i was just saying as the tree is identcle to that in natty, there is no advantage to having it in the oneiric repo, till it changes
[11:42] <ppisati> ah ok
[11:42] <apw> thats not to say that you can't do it, just its not obvious to me what we gain by your effort there
[11:42] <apw> any idea when we might get some updated bits?
[11:43] <apw> (mumble if its sensitive info)
[11:43] <ppisati> i'm trying to figure it out
[11:48] <ppisati> have you ever tried to switch to text console while playing music?
[11:49] <ppisati> i have audacious running and playing some stuff
[11:49] <ppisati> ctrl+alt F<something>
[11:49] <apw> ppisati, not sure it continues does it ?
[11:49] <ppisati> and the music stops!
[11:49] <ppisati> no!
[11:49] <ppisati> and when i went back, once i got _all_ the audio (skype, audacious, etcetc) cracking
[11:49] <apw> yay
[11:49] <ppisati> a couple more switch and it got fixed
[11:49] <apw> quality software for the masses
[11:50] <ppisati> dunno if it's: audacious, pulseaudio, kernel, etcetc
[11:52] <jk-> I think it's the audio stuff trying to be clever; does the same on my myth box
[11:52] <jk-> (which doesn't use PA)
[11:52] <jk-> what layer of the "audio stuff", I don't know
[11:52] <diwic> ppisati, if you switch to a console, music should stop
[11:53] <diwic> ppisati, at least IIRC. Because you're not currently logged into the system, you don't have access to the sound card.
[11:55] <diwic> ppisati, as for the cracking thing, I've seen more than one bug report about "distorted sound with pulseaudio" so I think we have a natty regression here; I'll try to reproduce it later this week 
[11:56] <ppisati> diwic: actually my session and all my stuff it's still there, so i'm logged
[11:57] <diwic> ppisati, just as your screen stops showing your current X applications, your sound card stops playing your music. 
[11:58] <ppisati> uhm
[11:58] <ppisati> sounds a bit strange to me
[11:58] <ppisati> is it the same with tty[0-9]?
[11:59] <ppisati> whatever, anyway...
[11:59] <diwic> ppisati, however if you log in as the same user, you got access to your sound card again and it starts playing :-)
[11:59] <diwic> (just tried it)
[12:06] <apw> diwic, i assume we know that banshee has no quit window button now
[12:07] <apw> diwic, not that its your problem, just i am assuming you hear about this kind of thing
[12:08] <diwic> apw, eh?
[12:08] <tjaalton> it quits if you stop the playback first
[12:08] <apw> i am fishing to know if you know it has been filed as a bug so i don't have to file a new one ...
[12:09] <diwic> apw, Banshee has three buttons in the top corner here.
[12:09] <apw> oh i am trying to get rid of the window without stopping the music
[12:09] <diwic> apw, no I don't but I'm more into the layers below
[12:09] <apw> as its then 'in my sound indicator'
[12:09] <apw> yeah i'll hastle someone on desktop :)
[12:09] <tjaalton> yes, the window-close button does get rid of the window here, and playback continues
[12:10] <diwic> apw, aha, it has a quit button but it doesn't quit when you press it?
[12:10] <apw> tjaalton, really ?  hrm
[12:11] <tjaalton> apw: yeah, so it just stays there for you? weird..
[12:11] <apw> tjaalton, oh no, it quits but the playback stops
[12:11] <tjaalton> apw: ah :)
[12:11] <tjaalton> maybe the indicator plugin is disabled?
[12:12] <apw> and ^W has gone away
[12:12] <apw> tjaalton, hmmm maybe
[12:12] <tjaalton> it was buggy during natty
[12:13] <apw> tjaalton, ahh i do see an -appindicator package which is not installed
[12:13] <apw> upgrade fail again
[12:14] <tjaalton> banshee-extension-soundmenu?
[12:14] <tjaalton> that's what I have installed
[12:14] <tjaalton> and -ubuntuonemuiscstore
[12:14] <tjaalton> *music
[12:15] <apw> there is also banshee-extension-appindicator i think
[12:15] <apw> but am updating so have lost the ability to check
[12:16] <apw> i have soundmenu installed though
[12:16] <tjaalton> ah right, I actually meant the soundmenu extension :)
[12:16] <tjaalton> but do you have it enabled?
[12:17] <apw> bah no, it was disabled, upgrade FAIL
[12:18] <apw> tjaalton, heh now ^Q doesn't work and ^W does!
[12:18] <apw> thanks
[12:18] <tjaalton> :P
[12:20]  * ppisati food + new power supply for panda/beagle
=== cmagina-afk is now known as cmagina
[13:51]  * apw reboots to get a new broken unity
[13:59]  * smb tries whether a third cup of  coffee finally helps...
=== dimmortal1 is now known as dimmortal
[14:20] <apw> smb, not a hope
[14:22] <apw> ogasawara, when you disable ubuntu/ drivers its simpler (collission later wise) to shove a # in the ubuntu/Makefile on the sourcel l
[14:22] <apw> line, that way we don't have to rebuild the config later when it comes back
[14:23] <apw> ogasawara, and i think i have a building aufs update ready ... just going to see if it works
[14:23] <ogasawara> apw: ack
[14:37]  * ogasawara back in 20
[14:37] <apw> *giggle*
[14:37] <smb> apw, Stop thinking too much about it. :-P
[14:37] <apw> there is little in the way of thinking going on over here today
[14:39] <smb> heh, well yeah. neither here
[14:39] <tgardner> apw, smbwhat are you guys whining about ? its not like you had a 26 hour trip home.
[14:40] <smb> tgardner, Nah, that _is_ the annoying part. No idea why
[14:40] <apw> tgardner, i think you are allowed to whine _more_, but i feel entitled to some ammount of whining, after 10 days of mental abuse
[14:40] <tgardner> apw, yeah, I did forget about summit.
[14:46] <cking> all apw's work is mental
[14:47]  * apw slaps cking
[14:47] <cking> owch
[14:49] <smb> The truth hurts... :-P
[14:52]  * tgardner is sure glad to get back to 21" monitors. that 9" screen was killing me.
[14:52] <smb> So true
[14:52] <smb> Even with a 12"
[14:53] <cking> a week on an Atom with 1GB of memory is a killer with evolution + firefox.
[14:53] <tgardner> cking, yeah, slow as hell
[14:54] <cking> funny that once upon a time a 66Mhz 486DX + 4MB seems powerful
[14:56] <smb> cking, Though I think we did not run more than one program at once then...
[14:56] <smb> Well actually we did
[14:57] <ogasawara> apw: I'm thinking of taking a swap day on Friday, you ok holding down the fort as tgardner and I would both be away
[14:57] <apw> sure thing, do we have a release-meeting, seems unlikely this early
[14:57] <ogasawara> apw: no meeting that I know of
[14:58] <apw> even easier :)
[14:59]  * cking suspects we need all the CPU cycles for interpreted code, Python, javascript, java, ACPI AML, etc..
[14:59] <smb> ...and the additional eye candy
[15:00] <cking> and gwibber + mumble ;-)
[15:02]  * cking kicks mumble
[15:19] <apw> ogasawara, i've just pushed a couple of small updates to clean up the updater and document its use, perhaps you could review the text and see if it makes any sense what so ever.
[15:19] <apw> ogasawara, see ubuntu/aufs/BOM.UPDATING
[15:20] <apw> tgardner, i have cleaned up the aufs-updater to record the real SHA1 of the standalone tree, as well as the log one it used to hold
[15:20] <apw> (so its less confusing when you find the BOM in the furture)
[15:20] <tgardner> apw, ack
[15:20] <ogasawara> apw: ack
[15:23] <apw> tgardner, finally figured out why git is so damn slow for me, in the morning.  seems tis relatime ... seems it updates atime if its 24hours since it last did, so it happens every day first thing!
[15:23] <tgardner> apw, huh, I've been having the same issue.
[15:24] <tgardner> first thing takes forever.
[15:24] <apw> yep, so its one of those pathalogical cases.  you don't use it for a while
[15:24] <apw> say a weekend, then you do a git commit first thing in day
[15:24] <tgardner> apw, any workaround ?
[15:24] <apw> and it reads every file, and you wait a long ass time
[15:24] <apw> from there you are syched
[15:24] <apw> and its every morning first thing
[15:25] <jk-> updatedb still pushing everything out of the page cache?
[15:25] <apw> well now i know i will be doing a git-status before i make my morning tea
[15:25] <apw> jk-, its not page cache, its the atime updates.  basically they are really expensive, one read makes one write, and alogged one at that
[15:26] <apw> so we use relatime, which says if the atime > ctime we don't bother until its 24 hours old
[15:26] <apw> but git is introducing pathological behaviour as it reads the whole tree
[15:26] <apw> tgardner, you could go noatime on the partition, but mutt may not behave as you expect
[15:26] <apw> on a server it would be just fine though
[15:27] <tgardner> apw, hmm, since I'm not using mutt...
[15:27] <apw> you can also increase the time via systl
[15:27] <apw> now i know why its so violently slow in the morning, i can take mitigating action
[15:27] <apw> a partition for my source code with atime off would have been good
[15:28] <jk-> ah
[15:31] <apw>         if ((long)(now.tv_sec - inode->i_atime.tv_sec) >= 24*60*60)
[15:31] <apw> tgardner, no actually its not configurable ... anyhow there is the reason it sucks in the morning every morning
[16:01] <mjg59> apw: Now just remember that until that went in it would have been violently slow *all the time*
[16:01] <apw> mjg59, yep, its cirtainly better, just taken me a long time to work out why its always in the morning
[16:02] <mjg59> You need an SSD
[16:27] <mfilipe> hi! I want download the kernel-2.6.39 through "apt-get source". Is there any way in 11.04? 
[16:27] <tgardner> mfilipe, 'apr-get source linux'
[16:28] <tgardner> apt*
[16:28] <smb> err .39?
[16:28] <tgardner> smb, oneiric isopen
[16:29] <mfilipe> tgardner, no, it will download .38
[16:29] <smb> tgardner, Was just not sure whether you can get a .39 with apt-get from within natty
[16:29] <mfilipe> I want .39 to apply this patch: https://bugs.freedesktop.org/attachment.cgi?id=46702
[16:30] <tgardner> smb, indeed you cannot. Iassumed this command was being executed from with an oneiric chroot or installation
[16:30] <tgardner> can't fr*&*%^%g type this mornign
[16:30] <smb> Yeah, so either this, or to use the git repo directly would be the way to go
[16:31] <smb> tgardner, Had similar issues in mine.
[16:31] <tgardner> mfilipe, use 'dget http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux_2.6.39-2.7.dsc'
[16:32] <smb> Somehow my fingers managed to find the keyboard shortcut for undo all the time
[16:38] <mfilipe> I want the .config and source code of 2.6.39-generic-pae
[16:38] <mfilipe> devscripts installs many things that I don't want :( 
[16:42] <apw> th
[16:43] <smb> aaargh?
[16:44] <apw> yep
[16:51] <lag> apw: When are the dates due to be released for UDS-P?
[16:51] <apw> they may already be set, though i have no clue myself
[16:51] <lag> apw: That's good news (as I'd like to bring Sophie over)
[16:52] <lag> apw: Do you know where I might look?
[16:52] <apw> i suspect i have seen dates mooted in email
[16:52] <tgardner> lag, Oct 24 in Orlando
[16:52] <lag> tgardner: Great, thanks :)
[16:54] <lag> How about Plumbers? 
[16:54] <lag> I thought it was after?
[16:54] <lag> Conference: 7-9 September 2011 in Santa Rosa, CA, USA
[16:54]  * lag is confused
[16:54] <tgardner> lag, what is there to be confused about?
[16:55] <lag> tgardner: For some reason I thought Plumbers was at the same time as last year
[17:03] <tgardner> ogasawara, rebased for yama patches and pushed said crack to oneiric +master-next
[17:04] <ogasawara> tgardner: cool, thanks
[17:04] <tgardner> ogasawara, its still pushing.
[17:48]  * ppisati -> gym
[17:59] <apw> tgardner, you got a pointer to the previous MIR for LTS backports, it is proving hard to find it seems
[18:00] <tgardner> apw, hmm, are you sure I wrote one? 
[18:00] <apw> tgardner, yeah pretty sure you did actually, i have also found refrences to you saying you would file one
[18:00] <tgardner> wouldn't the bug number be in the changelog ?
[18:01] <tgardner> apw, MIRs are always associated with a bug IIRC
[18:01] <apw> you'd think but the backports are generated from our main kernel, so it doesn't appear to be in there
[18:02] <tgardner> apw, unwind it to the very first commit
[18:02] <tgardner> I likely added it by hand.
[18:04] <apw>   [ Tim Gardner ]
[18:04] <apw>   * First upload according to https://wiki.ubuntu.com/KernelTeam/Specs/KernelMaverickNewKernelOnLTS
[18:04] <apw> seems to be what was in the first real upload
[18:04] <tgardner> apw, I'm hunting for the MIR in wiki.ubuntu.com
[18:12] <tgardner> apw, have you stumbled on this page yet? https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
[18:12] <mjampala_> guys need help on setting my KEXE on ppc Board
[18:12] <mjampala_> not sure why and how to setup the crashkernel kernel boot param
[18:13] <mjampala_> anyone care to explain please?
[18:13] <apw> that parameter ensures there is a hole in memory to contains a second kernel to recover and record the first one on a crash
[18:13] <apw> not required if you arn't using kexec for crash dumps
[18:14] <mjampala_> I need to use for crash dumps so I need it
[18:14] <apw> i seem to remember on my system that parameter got added automatically when i installed kexec
[18:14] <mjampala_> how do find the hole
[18:15] <mjampala_> integreated
[18:15] <apw> one normally is made by the option
[18:15] <mjampala_> sorry, interesting ...
[18:15] <mjampala_> my box is an embedded solution 
[18:15] <apw> tgardner, thansk seems i have a lot of bits there
[18:16] <apw> though i am struggling to find either the MIR bug or checklist wiki page
[18:16] <mjampala_> not sure if that will work for me
[18:16] <tgardner> apw, I have not been able to find it, but I'm pretty sure I wrote one.
[18:16] <tgardner> google is not my friend today
[18:16] <smb> mjampala_, That is how it looks on a 64bit x86 (though not sure it helps ppc) crashkernel=384M-2G:64M,2G-:128M
[18:17] <smb> Think it means for memory between 384 and 2G use a 64M hole and for 2G and more 128M
[18:17] <apw> smb, yep thats my understanding
[18:18] <mjampala_> smb, but who devices where that 64 or 128 gets allocated 
[18:18] <mjampala_> which part of memory
[18:18] <apw> tgardner, never mind, think this wiki will guide me thorugh
[18:18] <mjampala_> can you check your /proc/meminfo and see if there is a crash kernel entry in it 
[18:19] <smb> As I understand it the kernel decides it
[18:19] <tgardner> apw, still, it would be handy to be able to clone the maverick MIR and just make some minor edits.
[18:21] <smb> mjampala_, not really in meminfo but "Reserving 128MB of memory at 32MB for crashkernel (System RAM: 33280MB)"
[18:21] <smb> in dmesg
[18:22] <mjampala_> As per the docs, there should be some entry in meminfo in /proc/meminfo
[18:22] <mjampala_> may be it is named with a different name
[18:24] <mjampala_> smp,  crashkernel=384M-2G:64M,2G-:128M
[18:25] <mjampala_> is that for you r grub menu
[18:26] <smb> mjampala_, At least my meminfo has only sizes, not locations, so it would not help. Yes, that is from grub.cfg to be passed as kernel command line
[18:28] <mjampala_> yeah, thats fine, does your meminfo have an entry for crashkernel which mentions the size 
[18:28] <mjampala_> how does it look
[18:35] <smb> mjampala_, Nothing in there saying crash or being something of only 128M
[18:36] <mjampala_> hmm, thanks smb
[18:36] <mjampala_> wonder how it not accounted
[18:36] <mjampala_> I think the crashkernel memory that is allocated at boot time is not used for anything else. 
[18:37] <smb> It could be accoounted, but it may be part of some other thing
[18:37] <mjampala_> one of the start up scripts should just load the kernel and be ready if a crash occurs 
[18:37] <mfilipe> git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git has the last source-code of natty linux-image? what is the version? 
[18:44]  * tgardner --> lunch
[19:03]  * apw wanders off to prepare for guests ... see ya tommorrow
[19:25] <SpamapS> morning folks. Question about the -server kernels.. is there a page pointing out thd differences w/ -generic?
[19:33] <smb> SpamapS, I am not aware of one, but in git debian.master/config/amd64/config.flavour.server is only the config options not the same as for other flavours
[19:33] <jjohansen> SpamapS: not currently, it is largely the same, just a few config diffs
[19:34] <jjohansen> I have a server, -generic config diff that I can throw into a page quickly
[19:34] <jjohansen> give me 30 min and I'll have a basic wiki page up
[19:34] <smb> jjohansen, or you just pastbin the server config
[19:34] <smb> Its only a few kines too
[19:35] <smb> lines even
[19:35] <jjohansen> smb: true enough
[19:38]  * smb stops interrupting and goes afk... 
=== smb is now known as smb-afk
[19:40] <SpamapS> jjohansen: thank you!
[20:25] <kees> tgardner: do you (or anyone else) have a Lenovo T400 in your stacks of laptops?
[20:28] <tgardner> kees, not me. perhaps cert has one ?
[20:28] <kees> tgardner: cool; I'll ask around. thanks!
[21:06] <jjohansen> SpamapS: https://wiki.ubuntu.com/Kernel/FAQ/KernelFlavourDifferences
[21:24] <eruditehermit> bjf, hey
=== baggles is now known as wivlaro
[22:31] <SpamapS> jjohansen: Perfect! Thanks! :) (but aren't we supposed to delete things? ;)
[22:57] <jjohansen> SpamapS: yeah now I need to delete six pages :)
[22:57] <SpamapS> FAIL
[22:58] <SpamapS> One thing thats not mentioned, that might be good to mention, is that there is no longer difference in the HZ setting, and that all of the kernels are tickless (thats true right?)
[22:59] <jjohansen> SpamapS: hrmm that is not true, /me will have to investigate.  They are indeed all tickless NoHZ when sleeping but not when running
[23:00] <jjohansen> SpamapS: natty are all at 250 Hz
[23:01] <jjohansen> that is why it doesn't show as a difference
[23:01] <jjohansen> I'll add the info
[23:02] <SpamapS> the -virtual is CONFIG_HZ_100=y and CONFIG_NO_HZ=y and CONFIG_HZ=100 ..
[23:02] <SpamapS> in natty I mean
[23:02] <SpamapS> but I have no idea how to interpret those
[23:08] <jjohansen> SpamapS: no its stranger than that, 64bit kernels are 100Hz and 32bit are 250Hz
[23:08] <jjohansen> I just checked them all
[23:09] <jjohansen> SpamapS: NO_HZ=y means that the kernel is tickless when idle
[23:10] <jjohansen> CONFIG_HZ_100=y means that the kernel has a tick of 100 Hz, but in this case only when not sleeping because of config NO_HZ
[23:11] <jjohansen> ogasawara,apw: we will want to look at our HZ in the config review later in the week, it is odd that 64bit kernels are all 100 Hz and 32 bit are all 250Hz.  One would think -generic would be 250Hz and -server 100Hz