=== shang_ is now known as shang
[05:45] <aaschez> Is it safe to have linux-headers-generic, linux-image-generic, linux, linux-headers-generic-pae, linux-headers-image-pae and linux-image installed after having linux-headers-3.0.0-14 generic?
[05:51] <RAOF> aaschez: It is (almost) always safe to have more packages than you need installed.
[05:52] <RAOF> The more vaguely named ones (linux, linux-image-generic, etc) are metapackages; their only point is to ensure that the latest kernel is installed, even if the kernel package name changes (as it does, when you go from linux-image-3.0.0-13-generic to linux-image-3.0.0-14-generic, for example)
[05:54] <aaschez> RAOF: Certain applications require loading and compiling of modules in to running kernel, which package to instll for that?
[05:54] <aaschez> install
[05:55] <RAOF> linux-headers-generic will always depend on the headers for the most recent kernel; this will not necessarily be the kernel that you're *running*, but if you keep linux-headers-generic installed and don't remove older kernel headers you'll have all the headers you need.
[05:56] <aaschez> 'and don't remove older kernel headers ' ..why?
[05:57] <aaschez> As far as I understand I'm running linux-headers-3.0.0-14-generic
[05:57] <RAOF> Well, you can select any of the previous kernels at boot.
[05:57] <RAOF> So if you need to guarantee that any kernel you choose to run has associated headers, you need to keep the old headers around.
[05:58] <RAOF> If, on the other hand, you only ever need to guarantee that module building will succeed against the most recent kernel, you don't need the older header packages.
[05:59] <aaschez> Yes, but I think it safer to have atleast one old running kernel. Could you explain me what headers, image, generic means?
[06:00] <aaschez> s/but/so
[06:03] <RAOF> The image is the kernel itself.  The headers are the stuff required to build out-of-tree modules against that kernel.
[06:03] <aaschez> Ok, so headers are the ones required to build modules?
[06:04] <aaschez> ok
[06:06] <aaschez> Lastly, what is generic and generic-pae ?
[06:10] <aaschez> Thanks a lot RAOF 
[06:10] <RAOF> Ah.
[06:11] <RAOF> -generic-pae is a build with PAE (Physical Address Extensions) enabled.
[06:11] <RAOF> It allows a 32bit kernel to address 48 bits of physical memory (ie: more memory than you have).
[06:12] <RAOF> I'm not sure if that's going to remain for Precise; there was talk about always having that enabled, as it only has a small performance impact.
[06:17] <aaschez> Thanks for explaining me the basic terms related to kernel :)
[06:42] <RAOF> aashez: There's no problem with asking basic (relevant) questions; go ahead :)
[06:45] <aashez> RAOF: :) I just restarted after intsalling linux, linux-image-generic and linux-headers-generic packages. There was no error but when I'm trying to build kernel module it gives error
=== Guest66638 is now known as lag
=== smb` is now known as smb
[09:56]  * apw looks miserably out at the world
[10:13]  * jussi hugs apw
[10:13] <smb> jussi now is infected...
[10:14] <jussi> :(
[10:15] <smb> Luckily its "just" a cold ;)
[10:16] <apw> jussi, thanks but i don't recommend breathing near me
[10:16] <jussi> apw: colds arent catchable over the interwebs
[10:17] <jussi> so interwebs hugs are ok :D
[10:17] <apw> heres hoping you are right
[10:35]  * LetoThe2nd suggests gluhwein to cure about everything :)
[10:47] <apw> sounds better than the honey and lemon i am being offered
[10:50] <smb> apw, how about ginger and honey. :)
[10:51] <LetoThe2nd> oO( gluhwein and gluhwein? or rather gluhwein and rum in severe cases )
[10:54] <smb> Gloehwein macht gloecklich... :-P
[11:09] <apw> that sounds rather rude :)
[11:10] <bryceh> apw, only if you're a teetotaler.
[11:12] <apw> hny bryceh ... hows you
[11:13]  * apw tries to imagine self as teetotal ... its not working
[11:14] <bryceh> apw, good good
[11:14] <bryceh> apw, my son and daughter share your cold
[11:14] <bryceh> (I guess)
[11:14] <apw> yay :/, that'll be amusing for you
[11:14] <bryceh> apw, indeed
[11:15] <bryceh> apw, invariably I'll catch it myself the day before the Budapest flight
[11:15] <apw> hense you are awake at this god forsaken time
[11:15] <apw> bryceh, so very true, hopefully it is the same one, so i am at least immune
[11:15] <bryceh> creature of the night I am
[11:15] <apw> that seems to be the lot of fathers the world over
[11:35] <cking> sounds like the Budapest rally will be a "share a cold virus" event
[11:38] <bryceh> cking, :-/
[11:38] <amitk> talking about cold, Helsinki received its first real snowfall for the season. Much better than the wet greyness.
[11:38] <cking> share and enjoy ;-)
[11:39] <ppisati> we should rename Canonical's event after a famous Anthrax album: "Spreading the disease"!
[11:40] <amitk> there is already 'ubuflu' which is a take away gift from the events :)
[11:41] <cking> ubuflu is something also free to share with the family when you get back home
[11:42] <amitk> ...hence sticking to the spirit of ubuntu ;)
[11:43] <cking> apart from the fact we don't get the source code to the cold virus 
[11:43] <amitk> cking: the source is available. We just don't know the programming language yet
[11:44]  * cking consideres objdump on a virus...
[12:48] <apw> herton, bjf, ppisati, i have found a build error in maverick/ti-omap4, in the unreleased bit so i want to force the tip to fix it ... any of you playing with it?
[12:48] <bjf> apw, not I
[12:49] <apw> bjf, happy new year ... early for you isn't it ?
[12:49] <herton> apw, no as well
[12:49] <apw> then as ppisati can't be pushing it, i can ;)
[12:49] <bjf> apw, same to you. Yes, woke up at 3, couldn't get back to sleep
[12:49] <apw> bjf, now that sucks and no mistake
[12:52] <apw> herton, bjf, pushed ... was a missing header include in the top-down patches, now fixed
[12:55]  * apw notes he is beign pretty random about who he is wishing new years to, strange ...
[12:55] <apw> happy new years all round
[13:03] <cking> #include <happynewyear.h>
[13:04] <ppisati> apw: not messing with m/omap4
[13:04] <ppisati> apw: *i'm
[13:04] <apw> ppisati, thanks, all updated now
=== bjf is now known as bjf[afk]
=== bladernr_afk is now known as bladernr_
[14:52] <ppisati> back in 20m
[15:41] <apw> ppisati, p/ti-omap4 is now a rebase tree against p/master-next right ?
[15:49]  * ogasawara back in 20
[15:59] <ppisati> apw: yep
[16:00] <apw> ppisati, cool thanks
[16:00] <apw> jsalisbury, we got a top 10 meeting shortly ?
[16:00] <jsalisbury> apw, yes
[16:01] <jsalisbury> apw, 30 minutes
[16:01] <apw> ack
[16:01] <ppisati> isn't it 30min before kernel meeting?
[16:02] <jsalisbury> ppetraki, correct
[16:02] <jsalisbury> And on that note:
[16:02] <jsalisbury> **
[16:02] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:02] <jsalisbury> **
[16:02] <smb> ppisati, I would say 1hr
[16:02] <jsalisbury> sorry ppetraki, I meant ppisati correct.
[16:03] <ppetraki> jsalisbury, happens a lot :), hny
[16:03] <jsalisbury> :)
[16:03] <smb> oh the top ten thing...
[16:09] <brendand> anyone here from the stable team?
[16:09] <herton> brendand, yes
[16:09] <brendand> herton - hi
[16:11] <herton> hi
[16:11] <brendand> herton - we're considering re-testing for oneiric because of the reverted patch. the reversion seems to have fixed what looked like a seperate issue as well, so it seems significant
[16:13] <herton> brendand, yes, re-testing is needed, although it's a small change has considerable impact
[16:15] <bjf[afk]> brendand, can you explain what the "separate issue" is that it fixed ?
=== bjf[afk] is now known as bjf
[16:16] <brendand> bjf[afk] - this one https://bugs.launchpad.net/ubuntu/+source/linux/+bug/907454
[16:16] <ubot2`> Launchpad bug 907454 in linux "[Dell Precision M4500] offlining and then re-onlining CPUs makes the system unresponsive" [Medium,Confirmed]
[16:16] <brendand> we had one other independent confirmation
[16:17] <bjf> brendand, thanks, that is interesting
[16:17] <tgardner> bjf, given that suspend offlines CPUs, I think this is likely the same symptom.
[16:18] <bjf> tgardner: that was what I was thinking as well
[16:21] <brendand> bjf - now my colleague tells me that the system hit by that bug also couldn't resume from S3 so it seems almost certain they're related
[16:23] <bjf> brendand: did they run into the issue as part of cert. testing ?
[16:27] <brendand> bjf - yep, sure did
[16:28] <bjf> brendand: i'm "curious" why it didn't get raised with us (or did it?)
[16:30] <brendand> afair i did mention it here before the holidays
[16:31] <bjf> brendand: thanks
[16:32] <brendand> bjf - the bug also has the regression-update tag. does that not bring it into view for you?
[16:33] <bjf> brendand, no, at this point that tag is on so many bugs it's useless
[16:33] <diwic> ogasawara, just a question, can I really cherry-pick to the precise kernel? I mean, the stuff that currently is in takashi's tree only, not in linus tree, and therefore not in the precise tree, and you cannot cherrypick between different trees, or can you?
[16:35] <ogasawara> diwic: I believe if you fetch takashi's tree you should be able to cherry-pick
[16:35] <diwic> ogasawara, hmm, so I would start with a precise tree and then "git remote add" for takashi's tree?
[16:37] <arges> jsalisbury, whats the link?
[16:37] <jsalisbury> arges, http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/_kernel_hot_.html
[16:37] <arges> thanks
[16:37] <jsalisbury> arges, Then sort by heat
[16:37] <arges> ok I was looking at the right page then
[16:38] <ogasawara> diwic: you could do that or I think you can just do 'git fetch ...'
[16:38] <diwic> ogasawara, ok, I'll try that. Thanks!
[16:40] <ogasawara> diwic: a lot of times I do "git fetch <repo> <branch>" and then just "git cherry-pick FETCH_HEAD" (assuming the patch I want is at the tip)
[16:50] <jono> hey all
[16:50] <jono> my wireless keeps dropping and dmesg is giving me a stack of [21740.360855] wlan0: deauthenticating from 3c:ea:4f:85:07:d1 by local choice (reason=3)
[16:50] <jono>  errors
[16:51] <jono> it looks like I get that error whenever it disconnects
[16:51] <jono> any idea what the possible cause could be?
[16:52] <apw> jono, does that happen randomly a few times a day ?
[16:52] <jono> apw, yeah
[16:52] <jono> it seems to be happening at least once an hour
[16:52] <apw> what wireless do you have ?
[16:52] <jono> cfg80211
[16:52] <jono> Intel
[16:52] <apw> jono, sounds like what i am seeing, where likely rekeying is being exposed
[16:53] <apw> but no idea as to cause, why are you seeing it all of a sudden?
[16:53] <jono> I saw a few bugs in LP that suggest others are seeing this too
[16:53] <jono> apw, I have seen this ever since I upgraded to 12.04
[16:53] <jono> oddly, it varies between APs I think
[16:53] <jono> see these issues with my AP, but less with my parents
[16:53] <jono> I thought it might be the power saving, but that is off on my machine
[16:54] <apw> jono, yep i'd say there is an ap component.  but rekeying time is AP specific
[16:54] <apw> i started seeing it when i upgraded my AP to WPA
[16:54] <jono> what is rekeying time?
[16:55] <apw> wpa requires rekeying (making up new keys) effectivly a reassociation though it should be transparent
[16:55] <jono> right
[16:55] <jono> so does the AP basically kick me off the AP and then it should automatically create the new key and connect?
[16:56] <apw> jono, i am unsure as to what should happen, the 'error' whcih is reported implies that the local end decided it wanted off the AP
[16:58] <jono> apw, the bug I saw reported was https://bugs.launchpad.net/ubuntu/+source/linux/+bug/548992 and 
[16:58] <ubot2`> Launchpad bug 548992 in debian "Wireless connection frequently drops [deauthenticating by local choice (reason=3)]" [Undecided,Confirmed]
[17:08] <brendand> bjf - what's going to happen with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/910894 then? how long is it staying in verification for?
[17:08] <ubot2`> Launchpad bug 910894 in kernel-sru-workflow/verification-testing "linux: 3.0.0-15.25 -proposed tracker" [Undecided,In progress]
[17:11] <arges> jsalisbury, i was wondering why https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/836250 wasn't high in heat... but I think its because its been updated recently perhaps
[17:11] <ubot2`> Launchpad bug 836250 in linux "[Oneiric] [Regression] Intel Corporation Centrino Ultimate-N 6300 poor networking, packet loss and very slow Lenovo X201 and T500 laptops" [Critical,In progress]
[17:11] <bjf> brendand, good question. I guess I'd like to see it stay in verification this week
[17:12] <jsalisbury> arges, that's a good question.  
[17:15] <brendand> bjf - so we'll leave our retesting for next week then i guess
[17:24] <bjf> brendand, i think it would be safe to test this week if you wanted 
[17:43] <tgardner> bjf, Greg has added 'Revert "clockevents: Set noop handler in clockevents_exchange_device()' to all of the maintained stable trees beginning with 2.6.32.y
[17:45] <bjf> tgardner: ack, herton, we should revert and respin
[17:58] <bjf> tgardner: only lucid has the bad commit, we'll respin that
[17:58] <tgardner> bjf, right.
[18:06] <jono> apw, is there anything I can do to resolve this wireless dropping issue, it is disrupting my work
[18:06] <jono> know of any workarounds?
[18:06] <tgardner> jono, ethernet
[18:07] <jono> tgardner, I might need to do that
[18:07] <apw> jono, no i have yet to find anything that helps
[18:07] <jono> no worries, thanks for looking into apw
[18:07] <jono> obviously if you want to look at my machine in budapest, that is fine
[18:07] <tgardner> jono, I'm stuck on Maverick on one of my laptops 'cause wireless just goes to hell with a newer kernel
[18:07] <jono> tgardner, yikes
[18:08] <jono> tgardner, you having the same dropouts issues?
[18:08] <apw> jono, i have the same issue on my natty box at home, thats the first time i noticed it, but also the first time i had wpa, which is uspect has always been broke in this way
[18:08] <tgardner> apw, try Maverick with WPA. I think you'll find that works OK
[18:09] <jono> apw, gotcha
[18:10] <apw> tgardner, yeah i had moved forword from M before i moved to wpa, will try that out when i get back to the machine
=== yofel_ is now known as yofel
[18:12] <apw> tgardner, and i am not sure its limited to intel, so i suspect this is either a 80211 stack issue, or an NM issue
[18:13] <tgardner> apw, Johannes Burg has been working on this with arges since before Xmas. dunno what that status is, but I agree that it looks like a stack issue.
[18:14] <arges> tgardner, yea I built a test kernel with Johannes patch to get some debug info. he was looking at the tx/rx aggregation code in the kernel
[18:15] <herton> tgardner, I noticed that smb announced 2.6.32.52+drm33.21 with only the clockevents revert, I'll apply it as a stable update (create-stable-tracker)
[18:15] <arges> tgardner, unfortunately I'm not sure that bug is just *1* issue, it seems like there could be multiple issues at work
[18:16] <tgardner> herton, good, was just gonna ask about that
[18:16] <smb> herton, Yeah, Greg just did the same
[18:16] <tgardner> arges, it seems power saving mode is wadded up in the general symptoms
[18:16] <apw> arges, if you have some test kernels, or patches point me at them and i can try them on my kit
[18:17] <jono> tgardner, yeah I thought it was the power saving issues, but I switched off power saving and the issues are still there
[18:17] <arges> apw, do you have a wifi card that exhibits the issue?
[18:17] <apw> arges, i have two machines at least which show this behaviour in my home yes
[18:17] <tgardner> arges, you can also abuse jono
[18:17] <jono> bring it!
[18:17] <arges> awesome
[18:17] <apw> i think i have three, which are the three i use routinely, so it could be more
[18:18] <arges> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/836250
[18:18] <ubot2`> Launchpad bug 836250 in linux "[Oneiric] [Regression] Intel Corporation Centrino Ultimate-N 6300 poor networking, packet loss and very slow Lenovo X201 and T500 laptops" [Critical,In progress]
[18:18] <jono> brb, nipping out to get some longer ethernet
[18:18] <smb> herton, I wonder whether in this special case I could wait till tomorrow and then use the current make ec2 topic branch tracking bug created today which I have not touched, yet...
[18:18]  * smb is lazy
[18:18] <arges> apw, jono: #124 has a build with gives us multiple options for disabling n mode in the kernel
[18:18] <herton> smb, yes, just ignore the current tracking bug, the bot will open a new one after the build of new kernel
[18:18] <bjf> smb, i'm ok with that
[18:19] <apw> arges, i don't thnk i have any N capable kit involved
[18:19] <arges> Johannes Berg wanted to know how those various parameters related
[18:19] <arges> apw, oh, which card(s) do you have that would relate to this?
[18:19] <smb> herton, bjf Oh, if the bot creates a new one anyway... I take whatever is latest then
[18:19] <apw> something intel, and something brcm at least
[18:20] <apw> i haven't got the h/w in hand right not, but my constant disconnects is occuring at home
[18:20] <arges> apw, ok this is a different bug than I've been looking at
[18:21] <smb> ogasawara, actually I guess you may be interested to be aware of bug 911204, too. Not sure the change I have in there will be embraced but it seems to help the xen case...
[18:21] <ubot2`> Launchpad bug 911204 in linux "precise ec2 images fail to boot with kernel oops" [Critical,Confirmed] https://launchpad.net/bugs/911204
[18:21] <ogasawara> smb: ack
[18:22] <arges> apw, essentially wifi worked in natty, then stopped working in oneiric. in oneiric if n mode is disabled (11n_disable=1) wireless works again.   the periodic disconnections sounds pretty different
[18:24] <ogasawara> smb: you plan on shooting that upstream?
[18:25] <smb> ogasawara, Yes, sent it already. Though rather to the stable with both from the sob cc'ed. I found that thread more quickly
[18:26] <apw> smb, we shall see what they say i gues
[18:26] <smb> apw, Right, if there is no response I need to shoot wider
[18:27] <ogasawara> smb: I'll apply it as sauce for now and we can follow up later
[18:27] <smb> Just was meant as a note to let you know.
[18:28] <smb> ogasawara, Hmmmm. Maybe I should test on real hw before...
[18:28] <ogasawara> smb: oh, I thought you had tested
[18:28] <smb> Just booted as a xen guest
[18:28] <smb> which failed before...
[18:29] <smb> ogasawara, So let me do the proper testing
[18:29] <ogasawara> smb: ack
[18:33] <tgardner> ogasawara, where did 'fs: limit filesystem stacking depth' come from in Precise ?
[18:33] <ogasawara> tgardner: hrm, don't recall off the top of my head.  just a sec and lemme look.
[18:33] <tgardner> ogasawara, it ain't upstream, so I was kind of curious
[18:34] <ogasawara> tgardner: ah, I think that's part of the overlayfs bits
[18:34] <tgardner> ah
[18:34] <tgardner> ogasawara, perhaps we should have marked those SAUCE or somethinig
[18:35] <ogasawara> tgardner: I think we'd prefixed those with "overlayfs:" or something similar.  I'll get em cleaned up and marked sauce 
[18:37] <tgardner> ogasawara, I noticed it whilst reviewing tyhicks statfs reporting patch.
[18:41] <tyhicks> yes, I remember seeing that patch in the overlayfs patchset
[18:42] <tyhicks> tgardner, ogasawara: FWIW, the eCryptfs changes looked good to me
[18:43] <tgardner> tyhicks, is the patch on the mailing list the same as whats in linux-next ?
[18:43] <tyhicks> tgardner: BTW, I've got a working statfs reporting patch with a single code path. I just need a little time to go back and clean some things up.
[18:44] <tyhicks> tgardner: Sorry, are you talking about the eCryptfs patch in the overlayfs patchset or the eCryptfs statfs patch?
[18:44] <tgardner> tyhicks, the statfs patch on the Ubuntu k-team list
[18:45] <tgardner> I was just about to push that one. despite our comments it does work.
[18:45] <tyhicks> tgardner: The statfs patch in linux-next and the Ubuntu k-team list are the same. I'm working on an improved version for the 3.3 merge window.
[18:46] <tyhicks> tgardner: It will incorporate the changes suggested by you and apw
[18:46] <tgardner> tyhicks, ok, then I'll push the one I've got.
[18:46] <tyhicks> sounds good, thanks
[19:16] <tgardner> tyhicks, I'm still getting hate mail about bug #509180. Have you review it recently ?
[19:16] <ubot2`> Launchpad bug 509180 in ecryptfs "ecryptfs sometimes seems to add trailing garbage to encrypted files" [High,Fix released] https://launchpad.net/bugs/509180
[19:27] <tyhicks> tgardner: Yes. A lot of those comments are not helpful, but I looked at a bug yesterday which had helpful steps to reproduce the issue - bug 842647
[19:27] <ubot2`> Launchpad bug 842647 in ecryptfs "[git] file blocks duplicated at the end of the file" [High,In progress] https://launchpad.net/bugs/842647
[19:28] <tyhicks> tgardner: I'm almost done with that patch. It should go upstream by the end of the week.
[19:29] <tgardner> tyhicks, cool. if it looks like the same symptoms, then mark 509180 as a duplicate when you've got a patch ready to go.
[19:29]  * tgardner --> lunchtime errands
=== tgardner is now known as tgardner-afk
[19:35] <apw> tgardner-afk, bah ... we need to fix the 'going to apply' protocol ... we just clashed :)
[19:36] <lamont> I have a few Dell poweredge machines that have recently started seeing ntp step back and forth OTOO .2 seconds... any known fuzziness in the kernel's ntp world?
[19:37] <lamont> (lucid and hardy both, so I'm suspecting that the hardware is just plain getting old)
[19:48] <lamont> just wondering if the ticks/sec there is consistent with other machines, or if said hardware has something special of its own
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Jan 17, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
=== bjf is now known as bjf[afk]
[20:18]  * herton -> eod
=== bjf[afk] is now known as bjf
[21:16] <Beanow> Oh wow, accidentally changed status of a bug I had nothing to do with.
[21:16] <Beanow> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904569
[21:16] <ubot2`> Launchpad bug 904569 in linux "Linux 3.0.0-15 causes laptops to fail to resume from suspend (Dell XPS 1645, Sony Vaio VPCF1390)" [Medium,Fix released]
[21:17] <Beanow> Anyone in here that can revert Oneiric status to Fix Commited?
[21:18] <bjf> Beanow: done
[21:18] <ohsix> someone that can will see the change and fix it, most likely
[21:18] <Beanow> Thanks and apologies.
[21:19] <Beanow> (How do I even have permission for that?)
[21:30] <Beanow> jsalisbury: just reading back on the first kernel meeting I saw. I'm impressed. Neatly organized.
[21:30] <jsalisbury> Beanow, thanks, glad the notes can help
[21:31] <Beanow> jsalisbury, actually got it in my chat here but pretty much the same thing
[21:32] <Beanow> And yeah they helped. Now I know my suspend problem is going to be fixed quickly. :P
[21:36] <jsalisbury> Beanow, yes, the commit that caused the bug has been identified.