[03:41] <infinity> ogasawara / apw: Kernel's through NEW, BTW.
[03:42] <ogasawara> infinity: cool, I'll upload lbm then
[03:43] <infinity> ogasawara: When staging to -proposed, you may as well just blat linux/lbm/meta all at once.
[03:43] <infinity> ogasawara: (Assuming build-deps on lbm are correct for it to dep-wait)
[03:43] <ogasawara> infinity: I think they are, or at least I recall they were
[03:43] <ogasawara> infinity: I'll do meta too then
[03:44] <infinity> Then yeah.  The whole point of staging it is that we don't care if it's temporarily broken, so easier for you to just fire and forget until morning. ;)
[03:44] <infinity> (This should, hopefully, simplify your workflow a tiny bit in Q)
[03:45] <ogasawara> infinity: indeed
[07:34] <ppisati> moin
[08:10]  * apw survives an update
[08:25]  * ppisati -> reboot
[09:37] <viktor_d> Hello! i've been advised to ask my question here.
[09:38] <viktor_d> It is almost year since i can't use wi-fi on my netbook. I didn't really needed it but finally decided to investigate this issue.
[09:38] <viktor_d> I tested upstream linux kernels 3.3.1 and 3.4.0rc and have been told to perform a kernel bisection.
[09:38] <viktor_d> Since my problem appeared for the first time after i upgraded from maverick to natty, i need to compare latest maverick and earliest natty kernel.
[09:38] <apw> smb, you have a bug linked to hardware-p-config-review, bug #913860
[09:38] <ubot2> Launchpad bug 913860 in linux "Suepend/resume causes problems with mounted and active mmcblk device" [Medium,In progress] https://launchpad.net/bugs/913860
[09:39] <viktor_d> So here is the question: how to work with git with two kernels lying in different repositories?
[09:39] <apw> viktor_d, so i assume its not fixed in the latest kernels and the issue appeared back between those two
[09:39] <smb> apw, Oh dear... 
[09:39] <apw> between natty and maverick
[09:40] <c10ud> i have a big question for you, i'll let you finish with this issue and then post my walltext ;)
[09:41] <apw> c10ud, we're not signly threaded here
[09:41] <smb> apw, I will have to look back at that. But I have not found a really good way around it
[09:41] <c10ud> ok then:
[09:41] <c10ud> hello there, i do not intend to generate flames or whatever, i tried searching but no luck so far on this. here's my story: i've read there's a proposal on lkml to change the default io scheduler to deadline for ssd etc. then i discovered the possibility to change it on the fly and for my system it really feels snappier (e.g. firefox+heavy wine game+dvb-tv app) but i have SATA and AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (they say for SA
[09:41] <c10ud> TA cfq is better..but..) running on lucid with 3.0.0-18-generic #31~lucid1-Ubuntu
[09:41] <viktor_d> yes, wi-fi worked in maverick and doesn't work in latest versions
[09:42] <c10ud> question is: any reason on why deadline isn't the default for desktop?
[09:43] <apw> c10ud, partly collective wisdom and partly experimentation, deadline is normally for situations where raw throughput is needed i believe and fairness is not an issue.  so you'd also need to consider how things are when you have many things running
[09:44] <apw> c10ud, it is likely one of those things that needs someone to make a good test to allow comparitive testing
[09:45] <cking> ..me senses a study of different usecases on a bunch of SSDs is required...
[09:46] <c10ud> btw, lkml thread is here: https://lkml.org/lkml/2012/4/10/198
[09:46] <apw> viktor_d, ok then personally i would do a manual bisection using the mainline kernels for the same versions, so the latest 2.6.35.x mainline kerenl and the latest 2.6.38.x mainline kernel; if those work boot ok and exhibit the same wifi working/not working, you can use the in between kernels to narrow the search to the mainline kernel tree
[09:46] <apw> c10ud, snappiness is such a subjective thing ... but without testing properly we arn't going to change the default in a hurry
[09:47] <apw> cking, something to add to your suggestions box for Q perhaps
[09:47] <cking> apw, reckon so
[09:47] <apw> cking, given we always say use deadline for servers and not for desktop, and perhaps the decision is as the thread suggests more about ssd/rust
[09:48] <cking> apw, yep, however, I know that whatever we do it will be wrong from some subset of users :-/
[09:49] <c10ud> apw, sure, that's the main issue there "measure snappiness" but as a matter of fact till 5mins ago i feared opening a tab in firefox under such heavy load lol
[09:49] <c10ud> defaults are always tricky, yeah
[09:50] <apw> cking, well yah i assume we need some kind of latency measure for requests there must be a tool for that
[09:50] <c10ud> afaik the scheduler's war is not new though
[09:51] <cking> apw , there are tools like bonnie++ can do that 
[09:51] <cking> c10ud, I also suspect we need to figure out what's best for a set of typical applications and a typical mix of I/O on a bunch of typical modern drives
[09:53] <c10ud> yep, it's just i wtf'ed when i read "cfq is best on sata" then tried deadline and was better for me
[09:54] <viktor_d> apw, ok, i'll think about this, thank you
[09:55] <apw> https://wiki.ubuntu.com/Kernel/MainlineBuilds
[09:55] <c10ud> could even be a firefox-specific thing, no idea
[09:55] <apw> viktor_d, that is where they are hiding if you need them
[09:55] <cking> c10ud, indeed, this is the problem with tunables, everyone has different settings to suit their config
[09:56] <cking> we will put it down as something to study as a blueprint item for the next release
[09:58] <apw> cking, cool
[09:59] <c10ud> yea, i think it could be worth checking this out (also given i don't exactly have "new" hardware so i might not be the target for the new releases)
[10:01] <ohsix> if there was a metric for it that was valid in most cases it could be switched by the kernel :> you can monitor the bio queue depths and things as the system operates to find out when deadline isn't fair enough and it starts starving things
[10:02] <ohsix> maybe you could get a uevent for device congested out to userspace
[10:03] <apw> ohsix, userspace activity triggered by disk conjection is never going to fly
[10:03] <ohsix> there's a point where it's ok, then not ok; going to have to pick that somewhere, otherwise you sacrifice one side of the fence
[10:04] <apw> ohsix, indeed but in the middle of a disk storm is not the time asking userspace to do anything is going to help
[10:04] <apw> its just going to make more stuff need the disk and that is fail
[10:05] <ohsix> eh, switching the policy to cfq while it's congested is going to make stuff need the disk more? the disk is already congested, you're just picking fairness when things are already bad, so it's not compounded and you don't pay all of the penalty for using deadline when it is
[10:06] <apw> ohsix, no you are handing off a uevent which ... needs a program to handle it, which is ... on the disk
[10:06] <apw> so inevitably by the time you react it will be far too late
[10:06] <ohsix> i see
[10:07] <ohsix> well the definition of congested can be chosen arbitrarily conservatively
[10:07] <ohsix> maybe for the 10th percentile of the best benefit you can get from deadline
[10:08] <apw> and right now we have no idea if there is any benefit other than a subjective it seems better from one person
[10:08] <ohsix> as far as i know there'd be no huge penalty for doing it, also, doesn't cfq already have a knob that basically does that?
[10:08] <apw> without any numbers who knows if deadline is better for _anyone_ else
[10:09] <apw> (it probabally is, but we have nothing to base that on)
[10:09] <ohsix> well there's probably a paper or two to be had about what it does for specific io patterns, if you have those io patterns it will be better; with ssd it's a little more certain due to the io rates and penalties for seeking being almost nil
[10:09] <ohsix> (i know there's a paper, just not where it is or by whom to cite it)
[10:10] <apw> ohsix, indeed and i have personally read exactly 0 of them, and have even less idea which access patterns we have
[10:10] <ohsix> deadline is "fair" when io takes a trivially small amount of time
[10:10] <apw> so saying 'at 10% we'll be able to switch easily' is a bit meaningless when we have nothing to take 10% of
[10:10] <ohsix> and gets progressively more unfair
[10:10] <apw> for which definition of fair though
[10:11] <apw> snappiness is not fair, snappiness is 'my shit gets done first'
[10:11] <ohsix> the same one used for cfq probably, if you consider all io to be the same class
[10:11] <apw> or if that is your definition then cfq is unfair
[10:12] <apw> we really don't give the kernel much info about which IO is important to us and which not
[10:12] <apw> for it to make fairness decisions with
[10:13] <ohsix> nod
[10:14] <brendand> bjf - hi
[10:14] <ohsix> anyways, deadline scheduling is well documented in other contexts, and how it behaves when the "run" or io queues get larger, and how to schedule among cooperating cpus or writers doing io, if one wanted to characterize it
[10:15] <apw> brendand, very early for bjf, he's probabally not going to be about for 4hrs
[10:15] <ohsix> none of the papers on the optimality can be applied to disk io tho
[10:19] <brendand> apw - any idea of the Lucid -proposed kernel is going to finish verification soon?
[10:22] <apw> brendand, it appears to be waiting on one verification, the recommendation from the engineer it to release with it either way, so i suspect it could happen today; cirtainly the deadline is up
[10:31] <apw> brendand, i suspect they are having fun with oneiric issues which is the biggest delay
[11:05] <ppisati> my electronic smuggler is closed... :(
[11:23] <apw> ogasawara, i have a patch which i'd like in the precise kernel should you be forced to do another upload for any reason.  i believe it is not an abi bumper
[11:25] <martinphone> if I install xubuntu 12.04 beta it will come with 3.2, right?
[11:38]  * ppisati -> lunch
[12:29] <brendand> herton - hi
[12:31] <herton> brendand, hi
[12:31] <brendand> herton, will verification complete on the Lucid -proposed kernel today?
[12:33] <apw> herton, there seems to be one bug unverified, but it seems the fix there was also an upstream stable patch we missed (if i am reading the last comment right) so the engineer is recommending we keep it anyhow
[12:34] <herton> brendand, probably not, there is still one bug not verified. we are waiting for one bug to be verified as apw said
[12:34] <tgardner> herton, which ones are they ?
[12:35] <herton> tgardner, bug 624510
[12:35] <ubot2> Launchpad bug 624510 in linux "Copying To USB Is Very Slow" [Undecided,Fix committed] https://launchpad.net/bugs/624510
[12:36] <herton> I talked with bjf yesterday, we could wait one more week for verification, since QA is busy now probably testing will be delayed
[12:37] <herton> apw, yeah ming we could keep it as the patch was marked for stable
[12:37] <herton> *ming said
[12:37] <apw> ok cool, thats all i had to say :)
[12:38] <tgardner> herton, you said there were 2 bugs ? whats the 2nd one ?
[12:38] <herton> tgardner, hmm, I said still one bug not verified :)
[12:40] <brendand> herton, what about oneiric?
[12:41] <tgardner> herton, prolly wanna get that one verified. there is a lot of stuff going on in that patch.
[12:42] <herton> brendand, oneiric was redone because of regressions, we decided to restart the SRU process for it, including all of master-next, since we had important fixes on there. So oneiric is on verification this week, will be released by next week, or earlier depending on how long bugs are verified
[12:42] <herton> tgardner, indeed, not a simple change
[13:02] <ogasawara> apw: ack, send it out and I'll get it applied.  I'll be surprised if we don't have another upload.
[14:48] <bjf> brendand: did you get answers for your questions ?
[14:48] <brendand> bjf, yeah. herton and apw update me. thanks
[15:02] <harry32134324> hey guys I've got a quick question
[15:03]  * ogasawara back in 20
[15:08] <apw> harry32134324, unless you ask it you won't get an answer
[15:09] <harry32134324> ahh ok :-)
[15:09] <harry32134324> so here's the deal.
[15:09] <harry32134324> i'm on 12.04 latest kernel with an intel sandy bridge
[15:09] <harry32134324> i5
[15:09] <harry32134324> when resuming my pc after a suspend it freezes
[15:10] <harry32134324> however, when rc6 is disabled everything works fine
[15:10] <harry32134324> i was previously told that my motherboard is to blame since it doesn't set voltages correctly
[15:10] <harry32134324> i have an ASRock H67M-ITX
[15:11] <harry32134324> any ideas if it can be resolved?
[15:11] <harry32134324> kernel is 3.2.0-23-generic
[15:11] <apw> if the reason is because the BIOS is setting the voltages wrong, very likely not other than applying an rc6 disable for it
[15:12] <apw> who worked out your voltages are wrong
[15:12] <harry32134324> so no way to keep rc6 enabled?
[15:13] <apw> it sounds liek the h/w is broken in that mode, so i'd guess no
[15:13] <harry32134324> hold on i can tell you who...
[15:13] <harry32134324> one of the guys that i submitted an ubuntu bug to...
[15:13] <apw> we cirtainly don't have many sandybrige people complaining any more about it, so i assume it works well in the majority of cases
[15:14] <harry32134324> hmm got it...
[15:14] <harry32134324> sucks
[15:14] <harry32134324> here's the bug i submitted:
[15:14] <harry32134324> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/964246
[15:14] <ubot2> Launchpad bug 964246 in linux "Kernel Freezes upon resume when rc6 is enabled." [Medium,Incomplete]
[15:16] <apw> harry32134324, yeah that information came from the upstream developers, seems that the bios was blamed
[15:18] <harry32134324> i upgraded my bios but still have the problem. i suppose ultimately my hardware is to blame...
[15:18] <cking> harry32134324, it does appear so
[15:18] <diwic> apw, nitpick: the description for ubuntu/ubuntu-lucid.git says "Ubuntu 11.04", should be "Ubuntu 10.04" 
[15:18] <diwic> apw, on kernel.ubuntu.com gitweb
[15:18] <apw> diwic, thanks
[15:18] <harry32134324> k guys thanks.
[15:19] <apw> harry32134324, and with the latest bios do you have an item for "iGPU voltage", the upstream bug claims success when changing it from auto to 'fixed 1.25v'
[15:19] <harry32134324> haven't tried that. i'll give a shot now.
[15:19] <apw> harry32134324, not 100% sure its the same issue he is reporting against though or not, bugs can be so unclear
[15:20] <harry32134324> well doesn't harm to give it a shot.
[15:20] <harry32134324> see you in a bit i hope :-)
[15:23] <ogasawara> cking: speaking of RC6, I was going to officially close the call for testing.  that ok with you?
[15:24] <cking> ogasawara, yep, good idea 
[15:25] <apw> ogasawara, i closed out my last wi, i think you've done yours, so i think that means only smb's is open
[15:26] <ogasawara> apw: sweet!  I didn't realize smb had one open
[15:26]  * ogasawara looks at the charts
[15:26] <apw> its a linked bug
[15:27] <smb> apw, ogasawara Is there a chance to postpone that somehow...?
[15:27] <ogasawara> smb: lets just unlink it
[15:27] <apw> yep if its just a bug and not going to be fixed, unlink it
[15:27] <apw> or maybe milestoning it to precise-updates may work
[15:27] <smb> I'd need to recreate the setup and then the aspire one I used to test seems slowly falling to pieces...
[15:28] <cking> smb, was the Aspire One tested to destruction then?
[15:29] <ogasawara> I'll be surprised if the burn down charts are smart enough to infer that precise-updates indicates POSTPONED
[15:29] <smb> cking, at least the cheap ass ssd in it seemed to be more and more unwilling (some errors reported there) and once it hided completly
[15:30] <cking> on a clear SSD you can seek forever
[15:31] <ogasawara> smb: ok, unlinked from the config-review blueprint
[15:32] <smb> ogasawara, Thanks, I try to get it tested again but it should not keep us from reaching 0 items
[15:32] <smb> Stupid mmcblk anyway...
[15:39] <harry32134324> no good unfortunately.
[15:40] <harry32134324> it was a decent try at least.
[17:14] <ogasawara> jsalisbury: bug 948235, lets close that out based on jamie's last comment (he's the original bug reporter).  if anyone else is still experiencing issues, have them open a separate bug report so we can gather their specific hw information and symptoms.
[17:14] <ubot2> Launchpad bug 948235 in linux "Intel wireless still randomly drops connection" [High,Confirmed] https://launchpad.net/bugs/948235
[17:22] <jsalisbury> ogasawara, will do.
[18:18] <cyphermox> tgardner-lunch: for when you're back; https://bugs.launchpad.net/ubuntu/+source/linux/+bug/973241 has a link to a kernel patch for the ipw2x00 wpa caps now
[18:18] <ubot2> Launchpad bug 973241 in network-manager "ipw2200 driver doesn't report any capabilities or wireless properties using the nl80211 interface to network-manager" [High,In progress]
[18:45] <ppisati> today i got the new panda and i was finally able to track down the "rebase bug" we had in the omap4, do you think there's still space for an upload?
[18:45] <ppisati> tgardner: ogasawara ^^^
[18:45] <ogasawara> ppisati: you'll just have to clear it with the release team
[18:45] <ppisati> ogasawara: k
[18:45] <ogasawara> ppisati: and they'll likely ask you to upload to the precise-proposed pocket
[18:46] <ppisati> ogasawara: and from there to the final image, right?
[18:46] <ogasawara> ppisati: then they'll pocket copy to the release pocket after it's built in proposed
[18:46] <ppisati> ok
[18:47]  * ppisati -> dinner, and after that, i'll do the pull req+prod release dance
[18:47] <ogasawara> ppisati: I'm assuming final freeze doesn't take affect until 2100UTC today, so you have a few hours I think
[18:47] <ppisati> cool
[18:47] <ppisati> ah wait
[18:47] <ppisati> UTC?
[18:47] <ppisati> it's a couple of hours away
[18:48] <ppisati> anyway
[18:48] <ogasawara> ppisati: eat fast :)
[18:48] <tgardner> eat while working...
[18:50] <ogasawara> ppisati: what's the bug# again, I can give the release team a heads up
[19:09] <ppisati> ogasawara: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/963512
[19:09] <ubot2> Launchpad bug 963512 in linux-ti-omap4 "Latest kernel updates broke video on omap4" [Critical,Confirmed]
[19:09] <ogasawara> ppisati: ack, thanks
[19:14] <ogasawara> ppisati: just to confirm, the current ti-omap4 kernel is working (as in you backed out the changes which broke video)?
[19:15] <ogasawara> ppisati: actually, can you jump into #ubuntu-release...
[20:28] <tgardner> ogasawara, pushed Precise LBM w/ixgbe OEM driver update. will send meta patch on list.
[20:28] <ogasawara> tgardner: ack
[20:40] <tgardner> ppisati, let ogasawara know when you've sent your pull request. I've gotta bolt.... see y'all tomorrow.
[20:41]  * tgardner -> EOD
[21:35] <ppisati> zinc is crawling...
[21:41] <ppisati> ogasawara: ok, mail with pull req sent
[21:41] <ogasawara> ppisati: ack
[22:03] <ogasawara> ppisati: did you want bug 963512 referenced in the changelog so that it's autclosed when we upload?
[22:03] <ubot2> Launchpad bug 963512 in linux-ti-omap4 "Latest kernel updates broke video on omap4" [Critical,Confirmed] https://launchpad.net/bugs/963512
[22:03] <ppisati> ogasawara: yes
[22:04] <ppisati> ogasawara: it's referenced in...
[22:04] <ppisati> ogasawara: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-precise.git;a=commit;h=4dc553f924976f0a595079d9fe460a2220390548
[22:04] <ppisati> "UBUNTU: blend upstream hdmi detection code and TI bits"
[22:04] <ppisati> ah crap
[22:05] <ppisati> i psated in the wrong lp
[22:05] <ogasawara> ppisati: I can fix it up
[22:05] <ppisati> ogasawara: thanks
[22:17] <ogasawara> ppisati: uploaded, just pending archive admin to approve it in the queue
[22:20] <ppisati> ogasawara: cool, thanks
[22:20] <ppisati> infinity: ^^
[22:20] <infinity> ppisati: Already done.