| === fabbione_vac is now known as fabbione | ||
| osmosis | any ideas on why a win2k3 kvm guest on ubuntu server works great on hardy, but runs super slow on lucid ? | 05:17 |
|---|---|---|
| lucent | experiencing data corruption with new juju stack post-upgrade to Maverick 10.10, seek advice how to troubleshoot and file a sensible bug report | 05:55 |
| lucent | p.s. I'm talking about firewire for anyone not familiar with juju | 05:55 |
| DanaG | hmm, the Ubuntu kernel's ClickPad support breaks my 3-button touchpad: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/612591 | 08:06 |
| ubot2 | Ubuntu bug 612591 in linux (Ubuntu) "Maverick kernel treats touchpad's middle button as ClickPad (affects: 2) (heat: 16)" [Undecided,New] | 08:06 |
| * smb welcomes cking back | 09:14 | |
| * cking yawns. jet lag is making me feel drowsy | 09:15 | |
| smb | cking, You should not use "jet lag" :-P | 09:15 |
| cking | smb, eh, why? | 09:16 |
| lucent | who would I be waiting for, if I want to chat up about firewire in Ubuntu kernel? | 09:16 |
| lucent | experiencing severe data corruption post-Meerkat upgrade | 09:17 |
| lucent | it's only on one specific firewire adapter, the other works fine | 09:17 |
| smb | Hm I think manjo had been looking into fw stuff, but best would be a) a bug report and b) a mail to the kernel-team mailing list pointing to the bug and issue | 09:18 |
| smb | cking, These drugs a bad for your health | 09:18 |
| smb | cking, Sorry, I know its probably too early and to out of time for lame jokes. | 09:19 |
| lucent | that is helpful, I was going to try linux-ieee1394 directly but it's very low traffic and I don't see much interactivity to resolve issues since a while | 09:19 |
| cking | it's a fine joke, but my brain is somewhere else at the mo | 09:19 |
| smb | lucent, Sometimes it may be helpful to check git for the name of people which had done recent patches | 09:20 |
| lucent | smb: what is my required reading before posting to that mailing list? | 09:23 |
| lucent | I'm curious if there's interest in me even reporting this issue, to be honest, before I do work to report it ah | 09:24 |
| smb | lucent, Writing to kernel-team@list.ubuntu.com probably is rather a heads up, it could be a cc when you report somewhere else, too. But to get ahead with upstream directly it is probably better to write to linux1394 and cc Stefan Richter (see MAINTAINERS file) | 09:28 |
| lucent | I can dig it. Thanks | 09:29 |
| apw | cking, heh you must be bad to not get that joke ;) | 09:29 |
| smb | apw, Morning | 09:29 |
| apw | morning | 09:30 |
| smb | apw, Is your headset on the floor or mumble just not working? :) | 09:30 |
| cking | uh, mumble. | 09:36 |
| smb | *** Lucid 2.6.32-25.44 moved to updates *** | 10:53 |
| apw | smb, yay | 10:54 |
| smb | yeah | 10:54 |
| apw | smb i assume it'll be an hour yet? doesn't seem to have actually occured | 10:56 |
| smb | apw, Right, just was initiated | 10:56 |
| === diwic is now known as diwic_afk | ||
| === diwic_afk is now known as diwic | ||
| === diwic is now known as diwic_afk | ||
| apw | smb, do you keep the kernel-ppa cruft cleaned out ? | 13:50 |
| apw | (or is it reaping itself?) | 13:51 |
| smb | its not me at least | 13:51 |
| * apw means the pre-proposed PPA, rather than mainliine builds in this context | 13:51 | |
| smb | I believe that is now done automatically when things are superseded within the ppa | 13:51 |
| smb | Not doing anything to clean them | 13:52 |
| apw | smb most excellent ... did wonder | 13:52 |
| tgardner | apw, I don't think you can see old packages unless you login as kernel-ppa | 13:52 |
| apw | tgardner, so they could be there and need cleaning up then | 13:53 |
| tgardner | apw, thats my recollection | 13:53 |
| smb | oh, ok | 13:53 |
| cking | btw, I've got a less power intensive notify-osd in my ppa | 13:53 |
| smb | cking, how does that work? | 13:54 |
| apw | cking, sounds good | 13:54 |
| cking | smb, reduces the polling from 120Hz to 10Hz | 13:54 |
| smb | apw, Are you already looking into the ppa? | 13:54 |
| smb | cking, Ouch, that sounds like an awful lot | 13:55 |
| cking | smb, that was my reaction | 13:55 |
| mjg59 | I'm not clear on why it polls. Shouldn't it be entirely event driven? | 13:58 |
| cking | mjg59, it should. I've filed a bug against it | 13:59 |
| apw | mjg59, it seems it is hard to find out where the cursor while ignoring the pointer so that the clicks go through; cnd had a proposal using transparent panels which should do the right thing (tm) | 14:16 |
| mjg59 | Ha. | 14:17 |
| cking | for now, I have a bodge | 14:17 |
| smoser | when is the next stable kernel update expected ? I'm wanting to know when i could expect for jjohansen's patch to bug 574910 to be pulled. | 15:00 |
| ubot2 | Launchpad bug 574910 in linux-meta (Ubuntu) (and 4 other projects) "High load averages on Lucid while idling (affects: 35) (dups: 3) (heat: 232)" [Undecided,Invalid] https://launchpad.net/bugs/574910 | 15:00 |
| smb | smoser, We just moved the last one to updates. That patch is pending to be uploaded and build, but then should move to updates relatively quickly | 15:01 |
| smoser | smb, is there something i can read on the process of this ? i really have no idea how to follow it other than bothering people :) | 15:02 |
| smoser | and although it may seem otherwise, i dont like bothering people | 15:02 |
| smb | smoser, Theoretically things get uploaded and you can see the current pending sru updates there http://people.canonical.com/~ubuntu-archive/pending-sru.html | 15:03 |
| smb | We are a bit behind with the upload to ec2 because the rebase was a bit clashing with upstream | 15:04 |
| smb | smoser, When we upload you normally get a request to verify that posted to the bug report | 15:05 |
| smoser | alright. so we're then hoping for that sometime soon, and then the 1 week stay in -proposed. | 15:05 |
| smoser | right, its more the time before upload that i was/am unclear on. | 15:05 |
| smb | smoser, If you do the testing feedback it could be even quicker for ec2. As the main changes have been in proposed long enough and just pushed to updates | 15:06 |
| smoser | oh. well then i can get those tested. i didn't realize they were in proposed. | 15:07 |
| smb | smoser, Usually the upload is done whenever there is something in proposed for the normal kernel. But this sometimes faces time problems with other things creeping up | 15:07 |
| smb | its currently no. as said we are a bit lagging behind | 15:08 |
| smb | should be today though | 15:08 |
| smoser | ah. well ok. well as soon as its in proposed, i will get it available for others ont hat bug to test. | 15:09 |
| smb | smoser, anybody subscribed to that bug should see the update there and get notified about the new upload to proposed | 15:10 |
| smoser | well, yes. | 15:10 |
| smoser | but its not that easy on ec2 | 15:10 |
| smoser | we (I) have to upload a kernel to ec2 so someone can run it. | 15:11 |
| smoser | there is a whole in the process... we have nothing automated watching -proposed and uploading kernels. | 15:11 |
| smb | Oh, right. Yes. In that case you see the notification and can then upload it to ec2 when it is in proposed | 15:11 |
| smoser | ok. thank you smb. so i'll be expecting something early this week in -proposed, and will make sure it gets tested. | 15:13 |
| smb | smoser, So when things are uploaded you should see without poking people. Until then... Well, if it takes long there may be no way around that for the moment | 15:13 |
| smb | :) | 15:13 |
| smb | yup | 15:13 |
| smoser | yeah. i just wondered if there was a general insight into your proces that i could just follow along with. | 15:13 |
| smoser | i know you dont upload for every fix (which makes sense), but generally don't know how you group them or wait. | 15:13 |
| smoser | thanks | 15:14 |
| === ivoks-afk is now known as ivoks-zombie | ||
| apw | akgraner, have we really scheduled the next openweek the day after release, when half the team will have been working all weekend? | 15:25 |
| === bjf[afk] is now known as bjf | ||
| apw | smoser, smb, isn't that bug on the wrong package ? | 15:27 |
| apw | or is ubotu being hopeless | 15:28 |
| smoser | its just bad ubotu | 15:28 |
| smoser | it is invalid on linux-meta, and in progress on linux-ec2 | 15:28 |
| smb | apw, ubotu. As smoser sais its on linux-ec2 | 15:28 |
| akgraner | apw yep... | 15:28 |
| apw | akgraner, heh good luck with that | 15:29 |
| smb | smoser, Not sure what the New on Linux is about | 15:29 |
| apw | smoser, i assume this does not show up in maverick ? | 15:29 |
| smoser | you should ask jjohansen for sure. i think it actually does affecdt upstream . but my memory is fuzzy | 15:29 |
| akgraner | apw, I'll let jono know :-) | 15:30 |
| smb | apw, Depends. I think we still carry cnd's patch for the load calculation | 15:30 |
| apw | the patch being reverted is cnd's mod | 15:30 |
| smb | apw, Right, I have not exactly followed what happened there. For some reason it feels like there was some talk about a different approach upstream or some update | 15:31 |
| apw | smb i don't see that commit in maverick | 15:31 |
| apw | so i assume maverick is not affected by this bug, but may be affected by the original | 15:32 |
| smb | apw, Ok, right or the is actually the other approach which I was not sure about | 15:32 |
| tgardner | apw, I'm thinking we dropped cnd's fix in favor of an upstream solution | 15:32 |
| smb | tgardner, Ok, so we are thinking the same. I just cannot remember for sure | 15:33 |
| cnd | tgardner, apw, smb, in maverick I believe we have the upstream solution | 15:35 |
| cnd | in lucid and karmic we might still have my patch | 15:35 |
| smb | cnd, yes to lucid and karmic | 15:35 |
| smb | I mean there it is in | 15:35 |
| smb | just reverted for ec2 | 15:36 |
| apw | smoser, so ... have we had any issues reported on the paravirt kernels in maverick ? | 15:36 |
| apw | tgardner, cnd, thanks for the clarification | 15:36 |
| smoser | apw, a couple. but tnothing that appears paravirt specific. | 15:39 |
| apw | cool thanks | 15:40 |
| cnd | smoser, I just took a look at the bug report | 15:41 |
| cnd | I'm concerned that the high load avgs aren't just because of the statistics reporting change | 15:42 |
| cnd | the patch that I wrote only affected the load avg calculation | 15:42 |
| cnd | but people seem to have real loads that are hitting their throughput | 15:42 |
| smoser | well, yes, and we've tried to get them to open new bugs to address that. | 15:43 |
| smb | cnd, IIRC jjohansen has tested reverting and saw things going down to expected values | 15:43 |
| cnd | smoser, ok | 15:43 |
| smoser | there are load issues with lucid | 15:43 |
| cnd | smb, yes, but I still worry that we might be seeing a symptom of a different problem | 15:43 |
| smoser | that bug is very much "meta bug" | 15:43 |
| cnd | and reverting the patch just papers over it | 15:43 |
| cnd | smoser, ahh, ok, that makes sense | 15:43 |
| smb | cnd, Yes, there were multiple issues in that bug | 15:43 |
| smoser | people googled "bad kernel performance lucid" and hit it and it went everywhere | 15:43 |
| cnd | heh | 15:44 |
| apw | a reason to change the title immediatly | 15:44 |
| cnd | anyways, my .02 | 15:44 |
| smoser | so basically, there are real issues with lucid performance that people are seeing, but we've not gotten a lot of good feedback as to what those are. john has a good understanding of what was wrong in the calculation. | 15:44 |
| smoser | hey is infinitely more suited to discuss it. | 15:45 |
| smoser | than i | 15:45 |
| smb | cnd, I believe there might even be some writeback performance issues in there which will get addressed by the changes we just got into updates for master | 15:47 |
| cnd | ok | 15:51 |
| smoser | smb, do you have a bug number for "writeback performance issues" | 16:03 |
| jjohansen | smoser: it should be on the bug a couple of times | 16:04 |
| smb | smoser, There were two I remember. Though those rather addressed the long unmount time. While the set of patches also enhances general write performance | 16:04 |
| jjohansen | smb: yes but it really sounds like a couple people were doing unmounts | 16:05 |
| smoser | well, if its ext4 only, its not likely causing anyone problems on ec2 | 16:05 |
| smoser | our 10.04 images use ext3 | 16:05 |
| smoser | (just remembering that some of the performance issues were ext4, i thought) | 16:06 |
| smb | smoser, jjohansen bug 585092 and bug 543617 | 16:06 |
| jjohansen | smoser: so of those people aren't using our images | 16:06 |
| ubot2 | Launchpad bug 585092 in linux (Ubuntu Maverick) (and 2 other projects) "giant IO delays on unmount (affects: 2) (heat: 64)" [Medium,Fix released] https://launchpad.net/bugs/585092 | 16:06 |
| ubot2 | Launchpad bug 543617 in linux (Fedora) (and 3 other projects) "Unmount of an fs with dirty cache buffers causes pathological slowdown (affects: 14) (dups: 2) (heat: 126)" [Unknown,Unknown] https://launchpad.net/bugs/543617 | 16:06 |
| smb | smoser, the writeback changes affect all filesystems. Though I only tested ext4 and xfs | 16:07 |
| smoser | k | 16:07 |
| jjohansen | cnd: as for the patch, it was a real problem, it was applying nohz logic to a Hz based kernel, reverting your patch and using the upstream problem as fixed the phantom load issue | 16:08 |
| smoser | jjohansen, you and i will have to discuss if this new kernel would warrent racing out new images, rather than releasing them at the end of next month. | 16:08 |
| smb | bjf, How far are you with preparing the ec2 update in Lucid? | 16:09 |
| bjf | smb, i'm still unclear from you email how to get the security fixes back onto the ec2 branch, but other than that, it wouldn't take long to get it ready for upload | 16:10 |
| cnd | jjohansen, yeah, I still believe you :) | 16:11 |
| cnd | just one of those pit of the stomach feelings | 16:11 |
| smb | bjf, You get them by the rebase. The only problem is/was that you don't get the right version by rebasing. So its just a small modification of the last commit to make it right | 16:11 |
| bjf | smb, ok, can take care of it right away | 16:12 |
| smb | bjf, ok great. sconklin should be able to make uploads for it by now | 16:13 |
| bjf | smb, i'll get on it right now | 16:13 |
| smb | bjf, I am not sure how much this helps, just generally in order to verify the rebases i search for the version of the rebase target (eg. 2.6.32-25.44) and look whether the next patch after that looks like some topic branch patch. That does not help that much with the version number which is better looked up with launchpad or rmadison. | 16:17 |
| jjohansen | cnd: oh I agree that there are multiple other issues, I have stated that repeatedly in the bug, along with reverting was only valid for ec2 etc. And begged people to open new bugs, just to have them ignore and continue, accuse us of not working on the real issues etc. | 16:23 |
| cnd | yeah, bug hugging is always fun :) | 16:34 |
| === ivoks-zombie is now known as ivoks | ||
| JFo | gah, totally spaced on the bug review. My computer is still set to Taiwan time :-/ | 17:51 |
| JFo | sorry guys and gals | 17:51 |
| smb | JFo, we danced on the tables as usual when you are not there :) | 17:52 |
| JFo | heh | 17:52 |
| * JFo wants video or it didn't happen :-) | 17:52 | |
| jjohansen | does video taken after the fact count? | 18:00 |
| JFo | jjohansen, I'm willing to allow it :-) | 18:01 |
| JFo | <-lunchies | 18:07 |
| * tgardner lunches | 19:00 | |
| cking | yawn | 19:02 |
| bryceh | JFo, mind taking a look at bug 649141 when you get a moment? | 19:36 |
| ubot2 | Launchpad bug 649141 in linux (Ubuntu Maverick) (and 1 other project) "BUG: unable to handle kernel paging request - EIP: [<f959ae41>] snd_ctl_poll (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/649141 | 19:36 |
| * jjohansen -> lunch | 19:56 | |
| * ogasawara lunch | 20:36 | |
| NCommander | ericm|ubuntu: I need bug #634161 fixed ASAP on Dove. | 21:06 |
| ubot2 | Launchpad bug 634161 in linux-mvl-dove (Ubuntu) "Unable to handle kernel paging request at virtual address 0ce003be - parport_pc driver load issue (affects: 1) (heat: 8)" [High,New] https://launchpad.net/bugs/634161 | 21:06 |
| NCommander | ericm|ubuntu: (config file change I think) | 21:06 |
| === yofel_ is now known as yofel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!