=== \sh_away is now known as \sh
[07:36] <abogani> cking: Are you around?
[07:36] <cking> abogani:  Hi there..
[07:38] <abogani> cking: About Bug #177895
[07:38] <ubotu> Launchpad bug 177895 in linux "Kernel 2.6.24-2 causing ~1000 wakeups by "Rescheduling Interrupts"" [Medium,In progress] https://launchpad.net/bugs/177895
[07:38] <abogani> cking: Interesting commit is 62fb185130e4d420f71a30ff59d8b16b74ef5d2b in mainline.
[07:38] <cking> Yes, I am very familiar with this one :-)
=== doko_ is now known as doko
[07:39] <cking> Yep - apparently it removes two earlier commits 
[07:39] <abogani> So I let thi Bug to you :-)
[07:39] <cking> ..well I had a look at it and I was not sure if these commits are actually in our kernel
[07:39] <abogani> It isn't a trivial merge.
[07:40] <abogani> cking: Do you have hw that incurr evidently in this bug?
[07:41] <abogani> cking: What is your TZ?
[07:41] <cking> abogani: I have a Centrino duo which I see 200-300+ Rescheduling Interrupts. But not 5000+ as some are seeing
[07:41] <cking> cking: My TZ is UTC. I start early :-)
[07:42] <abogani> cking:so  Good Morning! :-)
[07:42] <abogani> cking: Mainline give the same result on my Centrino duo!
[07:43] <cking> abogani: Back to commit 62fb185130e4d420f71a30ff59d8b16b74ef5d2b... I believe it reverts 58e2d4ca581167c2a079f4ee02be2f0bc52e8729 and 6b2d7700266b9402e12824e11e0099ae6a4a6a79
[07:44] <cking> abogani: however, I was unsure if these commits were actually made to our current kernel tree
[07:44] <cking> abogani: have you investigated this to any depth yourself?
[07:44] <abogani> cking: I'm already cherry-picked and my laptop works perfectly. 
[07:45] <cking> abogani: do you have a patch that I can pick from so that I can give it a run through?
[07:45] <abogani> cking: But i don't have hw that expose evidently thus bug. I'm not sure that this fix... :-(
[07:45] <abogani> cking: Do you prefer git or email?
[07:46] <cking> abogani: yes this is the same kind of problem I am facing too. And the patch is a bit "radical" as it does touch a lot of the important parts of the  scheduler
[07:46] <abogani> Agreed
[07:46] <cking> abogani: git - if that's OK, but email if that's easier for you.
[07:47] <cking> abogani: I have some tests with powertop and so forth that I can apply to see what's going on.
[07:47] <abogani> cking: Ok i'll push it in my git tree. Please Let me some minutes...
[07:48] <cking> abogani: The main thing is to see if the rescheduling interrupts are legitimate - a lot of them really are due to correct load balancing
[07:48] <cking> abogani: so it will take me 3-4 hours to shove in some diagnostics and see if the fix really is OK
[07:49] <cking> abogani: OK - much appreciated - this saves me a lot of work. :-)
=== asac_ is now known as asac
[09:16] <abogani> cking: Sorry I don't know why but my git don't work anymore! :-(
[09:17] <cking> abogani: Ah. Problem :-(
[09:18] <abogani> cking: Mhhhh .gitignore conflict
[09:27] <abogani> No way to understand why git stop work... 
[09:34] <cking> abogani: perhaps I should try the patch on my git tree and toy with the fix that way
[09:34] <abogani> cking: Are you registered user on Freenode?
[09:35] <cking> abogani: I thought so - why?
[09:35] <abogani> cking: I'm trying to send you a file
[09:36] <cking> abogani: perhaps try Emailing it to colin.king "at" ubuntu.com 
[09:37] <cking> abogani: meanwhile I check my Freenode and IRC settings 
[09:38] <abogani> cking: Mailed. I send you my adaptation of the cherry-pick fix 
[09:38] <cking> abogani: many thanks!
[09:39] <abogani> Sorry but my git is completely break ... :-(
[09:39] <cking> abogani: ..I know the feeling, when it breaks, it *really* breaks - and usually at the worst time.
[09:40] <abogani> :-)
[09:41] <abogani> Murphy docet ;-)
[09:46] <amitk> abogani: what seems to be the problem with git?
=== setmora is now known as eradicus
[09:49] <abogani> amitk: Hi Amit! I cherry-pick a commit from a remote tracked repo, use git-mergetool and git-status. And all is ok. I execute git-commit and all things disappear. git-log and git-status don't show nothing! Work seems completely lost!
[09:49] <abogani> Seems to me a index problem...
[09:49] <abogani> s/index/git index/
[09:52] <amitk> abogani: interesting. And you weren't working on a branch?
[09:54] <abogani> amitk: No. Just created with 'git-checkout -b'
[09:55] <amitk> abogani: that is a branch
[10:09] <cking> abogani: Hi again..
[10:09] <abogani> cking: Hi
[10:10] <cking> can you gzip the patch and re-send it to me as a gzip attachment. My mail client is silently putting in white spaces that cause git-apply to fail :-(
=== rikai__ is now known as rikai
[10:11] <cking> ..by the way I can reproduce the 10,000+ Rescheduling Interrupts quite predictably now - so it will be straight forward to test the patch.
[10:14] <abogani> cking: The fault is my webmail!
[10:15] <abogani> cking: Mailed.
[10:15] <cking> abogani: no worries - thanks again for the speedy response!
[10:16] <abogani> cking: How can you reproduce the bug? Is it necessary something special actions?
[10:17] <cking> abogani: It's a case of getting the right suite of apps to generate loads of timer actions and get enough free CPU cycles so that both cores are incorrectly balanced... 
[10:17] <cking> ...then one can see the scheduler working hard to try to rebalance the load and cause zillions of IPI events.
[10:17] <Ng> cking: is that going to be easily fixable for hardy? :)
[10:18] <abogani> Not easily...
[10:19] <cking> ..I hope so.. it will take a few hours of analysing the IPI events under different loads before I can say. I think it's not easily fixable..
[10:19] <cking> ...I've been looking at an answer on and off for a few weeks on this one - and tinkering with the scheduler is risky for Beta
[10:20] <Ng> yeah
[10:20] <Ng> just curious because my laptop seems to do several hundred wakeups a second for that
[10:20] <cking> After a lot of consideration I believe a lot of the rescheduling interrupts are legitimate.
[10:21] <cking> A lot of apps do very frequent timer events .. they wake up and the scheduler tries to spread the load across cores
[10:23] <cking> For laptops with Centrino Duo cores it is better to spread the load across cores so that they are busy rather than have one core running at full speed 
[10:23] <amitk> cking: what happens if IRQ balancing is disabled? the interrupts only go to the core on which the app is running?
[10:25] <cking> amitk: Not sure if this is just a IRQ balancing. My understanding is that the scheduler is rebalancing the load across cores in probably too agressive a manner 
[10:25] <cking> ..OR...
[10:25] <cking> ..that we can now see the IPI events because the Rescheduling Interrupts are more visible 
[10:27] <cking> amitk: Any wise input on this?
[10:28] <amitk> cking: not really. Though I wonder if the rebalancing behaviour will change if the scheduler is changed.
[10:29] <cking> amitk: looking at all the scheduler tweaking in 2.6.25+ I am very concerned that this type of issue has a lot of life in it..
[10:31] <cking> amitk: my big worry is that the problem may be resolvable for Hardy, but need a lot more work for later kernels.
[10:32] <cking> ..and also the scheduler is not a trivial piece of code to tinker with - if one goofs up, one goofs up big time.
[10:32] <amitk> cking: how so?
[10:32] <cking> amitk: sorry.. I misunderstand: how so what?
[10:34] <amitk> cking: why would it be harder to fix for later kernels? It should be fixed upstream, right?>
[10:36] <cking> amitk: true
[10:38] <cking> I'm just concerned with a fix now in Hardy LTS which makes the scheduler diverge from upstream in a (perhaps significant and) unmaintainable way
[10:40] <amitk> cking: i see you point now. But with LTS, it is unlikely that we will upgrade to a newer kernel.
[10:40] <amitk> *your
[10:42] <cking> amitk: indeed.. but I'm always keen to reduce risk.. especially wrt key kernel components.
[10:43] <amitk> cking: agreed
[11:01] <cking> Hi BenC
[11:02] <BenC> hey
[11:02] <cking> another day, another bug :-)
[11:04] <BenC> hehe
[11:09] <BenC> cking, amitk: If either of you wants to follow up on my work on cpu1 losing cpufreq capa, I found some interesting bits after some debug last night
[11:10] <BenC> after suspend, when bringing up cpu1, there are some acpi errors about unknown op codes
[11:10] <cking> BenC: Sounds like something meaty that I could get my teeth into..
[11:10] <BenC> bringing cpu1 down/up before suspend/resume works fine (the cpufreq symlink returns in sysfs)
[11:11] <BenC> doing so after suspend resume repeats the acpi errors though
[11:11]  * amitk gives up the bug to cking reluctantly - not :)
[11:12] <BenC> mjg59: Does the acpi subsystem reread the acpi tables after suspend/resume, or rely on it's internal copy?
[11:12] <cking> BenC: Sounds like https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/183033
[11:12] <ubotu> Launchpad bug 183033 in linux-source-2.6.22 "Intel Core 2 Duo - Resume from suspend, CPU Frequency Scaling is gone on CPU1" [Undecided,Confirmed] 
[11:12] <BenC> cking: That's the one
[11:12] <mjg59> BenC: They're never re-read
[11:12] <mjg59> Hm. In principle, SSDTs can be loaded and unloaded at runtime.
[11:13] <cking> mjg59: Not sure what happens in reality though. I will look into it.
[11:13] <mjg59> BenC: Curious. acpidump and iasl -d should let you figure out where that object is meant to live
[11:15] <BenC> mjg59: Then my first guess is that the internal copy is getting corrupt somehow
[11:16] <BenC> maybe acpidump before and after suspend will confirm that
[11:16] <mjg59> BenC: acpidump will dump direct from the hardware, not the kernel's representation
[11:16] <mjg59> /proc/dsdt /might/ give you the kernel version of the dsdt
[11:17] <mjg59> /proc/acpi/dsdt, that is
[11:17] <mjg59> BenC: What hardware are you seeing this on?
[11:17] <mjg59> A d630 has literally just turned up at my front door, so I can poke it there
[11:17] <cking> mjg59: This bug also occurs on my Lenovo 3000N200 Centrino Duo 
[11:17] <BenC> mjg59: Lots of systems
[11:18] <cking> BenC: so at least I can dig into the bug on my hardware straight away
[11:19] <mjg59> Ok. I'm not seeing it on my HP.
[11:19] <BenC> I reproduced it on two of my dell laptops
[11:19] <Ng> fwiw, not seeing it on my thinkpad
[11:20] <BenC> hoping this isn't a BIOS bug
[11:20] <BenC> or if it is, hopefully we can work around it somehow
[11:22] <BenC> mjg59: Should acpidump and /proc/acpi/dsdt match?
[11:22] <mjg59> BenC: The dsdt hunk of acpidump should I believe, yes
[11:22] <mjg59> Certainly after passing them through iasl -d
[11:23] <BenC> mjg59: Are the CPU related bits we are concerned about in the dsdt?
[11:23] <mjg59> BenC: Not sure. If you disassemble the dsdt and find the _PCT methods, then yes :)
[11:24] <BenC> mjg59: Thanks :)
[11:24] <BenC> cking: Ok, sounds like you've got plenty to go on...I expect a patch in upstream kernel and a full report when I return in 3 hours :)
[11:24] <mjg59> Otherwise, probably in an SSDT
[11:24] <cking> BenC: Of course ;-)
[11:25] <BenC> See you guys in a bit
[11:45] <adinc> if i download the packaged ubuntu kernel sources, where does it install them?
[12:09] <abogani> adinc: apt-get source linux-image-2.6.24-12-generic will install source in current dir
[12:19] <adinc> abogani: no it did install to AAAAAAAAAAAAAAAAAAAAAAAA/AAAAAABBBBBBBBBBB
[12:19] <adinc> pardon to /usr/src
[13:53] <adinc> can i disable CGROUPS on a running kernel, or do i have to disable it in the kernel configuration before compiling?
[13:55] <rtg> adinc: its a compilation config macro, so I don't think you can change the way the scheduler works at runtime.
[13:55] <adinc> is this essential in ubuntu kernel? or can i safely disable it
[13:58] <rtg> adinc: you can set it however you like. the current value is targeted to desktop single user environments.
[13:58] <adinc> where can i get the complete config file for the hardy kernel packages kernel?
[13:59] <adinc> the config file which is in /boot is unfortunately not complete
[13:59] <rtg> adinc: install a headers package, then look for a .config in /usr/src/linux-headers*
[14:00] <adinc> which one is complete linux-headers-2.6.24-12 or linux-headers-2.6.24-12-generic
[14:00] <adinc> generic
[14:00] <adinc> ...
[14:01] <rtg> adinc: alternatively you could 'debian/rules prepare-generic', then look in debian/build/build-generic for a .config for that specific flavour.
[14:01] <adinc> rtg: no this can't be the complete .config file since the .config in linux-headers is IWL3945 module missing, i mean it is not set
[14:02] <mjg59> adinc: iwl3945 comes from linux-ubuntu-modules
[14:02] <mjg59> Not linux-image
[14:02] <rtg> adinc: thats because iwlwifi is built in LUM, not the kernel.
[14:02] <adinc> so how do i get a complete config file
[14:02] <mjg59> adinc: That is a complete config file
[14:03] <adinc> i don't understand
[14:03] <rtg> adinc: its the complete kernel config.
[14:03] <mjg59> adinc: The Ubuntu kernel does not include iwl3945. It's in a separate package.
[14:03] <adinc> but the kernel needs to be prepared in order to accept this module, doesnt it
[14:03] <mjg59> adinc: No
[14:04] <rtg> adinc: have you read https://wiki.ubuntu.com/KernelMaintenance?
[14:04] <adinc> i've read several wiki pages, but let me see if i know this aswell
[14:04] <adinc> i'm thankfull for any information
[14:07] <adinc> this would mean that i could compile this particular module only with the kernel headers, but without the source. only this particular modul, is this right?
[14:08] <adinc> rtg: thank you for the link,  here it tells that the config files are concatenated into one file
=== \sh is now known as \sh_away
[16:50] <tseliot> BenC: did you review my patch?
[17:32] <lamont> BenC: which version of things was that vmmon, I wonder... no networking here.. FTL
[18:26] <infinity> BenC: Is the patch from #201591 queued for the next kernel upload, by any chance?
[18:26] <infinity> BenC: I'd love to be able to see myself type in consoles. :)
[18:36] <rtg> infinity: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=4cbe826672e05ace08a4848e53135d652772feae will appear with the next upload.
[18:38] <infinity> rtg: Danke.
[18:38] <infinity> rtg: (For the record, despite the bug title, it's a regression for all *fb drivers, not just atyfb... I have the same bug on vesafb)
[18:41] <rtg> infinity: you are correct, the commit title is disingenuous, but the code is correct.
[18:42] <infinity> rtg: Yeah, I know the code is correct, the heads up was just for the Debian changelog to be accurate. :)
[18:43] <rtg> infinity: I'll try to remember when I do the upload.
[18:46] <infinity> rtg: Is there a timeframe on that?  There's nothing scarier for me than running a devel release without consoles. :)
[18:49] <rtg> infinity: by next Friday for sure, perhaps sooner. 
[19:00] <cradek> rtg: thanks, that patch is the one that fixed my system too
[19:04] <BenC> rtg: I'm doing an upload this evening
[19:04] <BenC> or, soon after on the weekend
[19:15] <tseliot> BenC: did you review my patch (or read my email)?
[19:17] <rtg> BenC: good. I was gonna ask Steve if there was any reason I shouldn't do an upload today.
[21:30] <deb> Am i connected
[21:31] <deb> I have downloaded 8.04 and found it is not a viable distro for me, and many others.
[21:31] <deb> The reason is the lack of internet apps
[21:31] <alex_joni> you do know that on the CD there's only a tiny amount of installed packages
[21:32] <alex_joni> there are about 18-19000 other apps in repositories, which you can easily install
[21:32] <deb> Pardon?  There are more apps on the CD
[21:32] <deb> ?
[21:33] <deb> Oh, that. That  is my point.  As presently setup, I cannot get to the repositories with 8.04
[21:33] <deb> Reason is the internet access apps are so skimpy.
[21:33] <infinity> Define "internet access apps".
[21:34] <infinity> Also, please define it in another channel (#ubuntu, perhaps?), this is A) not a support channel, and B) dedicated to kernel discussion.
[21:34] <deb> I have two locations and two different ISP's that I connect through - as setup I cannot connect from either with 8.04
[21:35] <deb> One location has a wireless network and the main computer on it has a D-Link DWA-552 wireless card, which 8.04 does not recognize (There is a GPL driver for it beause Sabayon uses it)
[21:35] <deb> There is also no "ndiswrapper."
[21:35] <deb> So I can use the Windows driver
[21:36] <deb> The other location uses PPPOE -complete with user name and password - for each log on, there are no apps to allow me to do that (they are available as PCLinuxOS uses thenm)(
[21:37] <alex_joni> then use PCLinuxOS
[21:37] <alex_joni> as infinity pointed out, this is a place to discuss kernel development, which you obviously aren't interested in
[21:37] <deb> A less than "sensitive" anwer
[21:38] <infinity> We ship ndiswrapper and ppoeconf, both installed by default no less.
[21:38] <deb> No I am not interested in kernel development, but your folks on the desktop sent me here 
[21:39] <deb> Where are they, I looked but did not find them.
[21:41] <infinity> deb: pppoeconf is in /usr/sbin, ndiswrapper modules are provided by the default kernel setup, though you might need ndiswrapper-utils-1.9, if you need the userspace apps.
[21:43] <soren> ndisgtk is.. Oh, he buggered off.
[21:43] <soren> *shrug*
[21:44] <infinity> It's always unforunate when we lose a "IS THIS THE KERNEL CHANNEL, GIVE ME FREE SUPPORT NOW, UR DISTRO SUCKS, U ALL SUXORS!!" type.
[21:46] <alex_joni> infinity: you forgot "I HAVE NO CLUE WHAT I'M DOING, BUT THERE IS SOMETHING WRONG WITH WHAT YOU DID"
[21:46] <infinity> alex_joni: I'm fine with people lacking clue but, yes, I agree that it's irksome when they blame their lack of clue on us clearly having broken their computer from afar.
[21:47] <alex_joni> and sometimes even meaning to do that (breaking their computers)
[21:54] <zul> if everyone based their stuff off of pclinuxos then a world will be a happier place
[22:02] <alex_joni> how do you guys debug machine crashes.. if there's nothing in syslog?
[23:32] <desrt> hai!  i can has kernel hacker?
[23:41]  * desrt requires patch application