=== henrix_ is now known as henrix
=== vlee is now known as 36DACCIV3
=== hggdh_ is now known as hggdh
=== AceLan is now known as 23LAAZAVX
=== fejjerai is now known as 36DACCJND
=== lilstevie is now known as 92AAAT7FI
=== apb1963 is now known as 23LAAZI9B
=== sforshee is now known as 77CABAJNP
=== lcl is now known as 45PABAF32
=== TheDrums is now known as Guest98785
=== xnox is now known as 16WAAKRPZ
=== antarus_ is now known as antarus
=== jpds is now known as Guest78130
=== ayan is now known as 45PABBCA3
=== ayan is now known as 77CABAYT0
=== apb1963 is now known as 45PABBZ2G
=== ikonia is now known as Guest39856
=== shadeslayer is now known as Guest53594
[08:18]  * apw yawns
=== ara is now known as Guest80428
=== ikonia is now known as 16WAALVWB
=== shadeslayer is now known as 14WAB1TNZ
=== shadeslayer is now known as 45PABCPI0
=== pratchett.freenode.net changed the topic of #ubuntu-kernel to:  Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues February 4th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
=== lan3y is now known as Laney
=== zequence_ is now known as zequence
=== 14WAB1TNZ is now known as shadeslayer
=== 16WAALVWB is now known as ikonia
=== cjwatson_ is now known as cjwatson
=== lag is now known as Guest25521
[12:40] <zequence> infinity: Did you guys discuss including -lowlatency in master yet?
[13:47] <cjwatson> Anyone feel like working out whether bug 1265551 is verification-done for precise or not?  I need to close out the updates for 12.04.4 ASAP
[13:47] <ubot2`> Launchpad bug 1265551 in linux-firmware (Ubuntu Precise) "linux-firmware: Add Brocade FC/FCOE Adapter firmware files" [Undecided,Fix committed] https://launchpad.net/bugs/1265551
[13:48] <cjwatson> (There's another bug fixed by that update: bug 1265550.)
[13:48] <ubot2`> Launchpad bug 1265550 in linux-lts-saucy (Ubuntu Precise) "linux-firmware: iwlwifi: add firmware for 7260 / 3160 devices" [Undecided,In progress] https://launchpad.net/bugs/1265550
[14:03] <fish_> apw: it happended with 3.11 as well
[14:04] <fish_> but it *seems* it was harder to reproduce it there
[14:06] <apw> fish_, so i would recommend filing the bug, and going back through the 3.8.x kernels for one which it didn't happen
[14:07] <apw> as this seems to be a new phenomia
[14:07] <apw> we can use that to try and identify the introducing commit
[14:07] <fish_> apw: not sure sure it's new, I had to restart ~10 containers about 40 times until it crashed this time
[14:08] <fish_> and I can't reproduce it in a vagrant vm
[14:08] <apw> fish_, well you never noticed it before, and you managed to reproduce it in the original kernel you reported, so something hcanged
[14:08] <apw> fish_, so it makes sense to go back to whatever you had where you never noticed it and try and reproduce it there, now you know how
[14:11] <fish_> apw: the infrastruture is new so I haven't upgraded. could be possible that it happens with older kernels as well. but I'll try an older kernel as wlel
[14:16] <zequence> apw: Did you come to some sort of conclusion on including -lowlatency into master
[14:16] <apw> zequence, check out -6
[14:16] <apw> zequence, and indeed, could you test it ;)
[14:17] <zequence> apw: cool :)
[14:23] <zequence> linux-lowlatency is going to be maintained by Canonical from now on :)
[14:24] <apw> maintained by you, updated and uploaded by us as we do stable etc
[14:25] <apw> ie we'll do the security bits etc as a part of our normal work flow
[14:31] <zequence> apw: Alright. So, I supply you with patches? There's only one thing I'd like to change right now. It's to include a couple of kernel configs, to enable the boot parameter "threadirqs"
[14:31] <zequence> http://paste.ubuntu.com/6867381/
[14:32] <zequence> I would rather do it by adding a config file somewhere. So far, I only know of adding it to /etc/default/grub, which is not optimal, I think
[14:33] <zequence> Perhaps it can be done in /etc/sysctl.d/?
[14:34] <zequence> In that case, I could create a meta package, called ubuntustudio-kernel, break the dependency to rtirq for linux-lowlatency, and add it to ubuntustudio-kernel instead, with a supplied config to enable threadirqs
[14:36] <apw> zequence, the lowlatency flavour has that switched on in the config by defualt, in theory
[14:37] <zequence> apw: I need to test it, but I think it is only made available, and still needs a boot parameter for it to be activated
[14:37] <apw> of course it might not be working but it is on there
[14:37] <apw> +__read_mostly bool force_irqthreads = IS_ENABLED(CONFIG_IRQ_FORCED_THREADING_DEFAULT);
[14:37] <apw> in theory that is set to the (new) config optiont CONFIG_IRQ_FORCED_THREADING_DEFAULT
[14:38] <apw> and i have set that for your config
[14:39] <zequence> Ah, ok, I mixed it up with CONFIG_IRQ_FORCED_THREADING
[14:39] <zequence> That should in deed take care of it :)
[14:39] <apw> i have not looked to see if it works, it looks sane, but i have no idea how you can tell on a booted system which mode it is in 
[14:40] <apw> i assume something you do makes it obvious if it is working, either by checkng something or by your programs working "better"
[14:40] <apw> otherwise you'd not bother setting it
[14:40] <zequence> the rtirq script needs it to work, and that's how I see whether it is working
[14:41] <zequence> It sets priorities for audio devices, or tries its best to do that - helps some machines that have shared IRQs between things like their firewire port and their wifi (when using a firewire audio device)
[14:42] <zequence> So, it's very audio specific, and not something everyone will gain from
[14:43] <zequence> This is why I was considering breaking that part (threadirqs and rtirq) into a meta package, which would be more specified towards audio, but I suppose it's not that critical
[14:44]  * zequence is leaving for home
=== cristian_c is now known as Guest48079
=== ogasawara_ is now known as ogasawara
[14:57] <apw> smb, ...
[14:58] <smb> apw, yeah here maybe :)
[14:58] <apw> seems you might be in the lucky minority now
[14:59] <smb> apw, I hope script kiddies cannot spell :)
=== ogasawara is now known as Guest18719
[15:08] <apw> smb, heh indeed
[15:21] <fish_> apw: same error in 3.5 - but I figured out that softlockup_panic=1 will cause the kernel to print a stack trace
[15:21] <fish_> so bug report is coming soon 
[15:21] <apw> fish_, great, get us a stack trace in the bug and let us know the bug #; also try and give us something we can reproduce it with
=== JanC is now known as Guest76616
=== cristian__c is now known as cristian_c
[15:57] <fish_> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275809
[15:57] <ubot2`> Launchpad bug 1275809 in linux (Ubuntu) "(docker/lxc) container restart causes kernel to lockup" [Undecided,New]
=== xnox_ is now known as xnox
=== ogasawara_ is now known as ogasawara
=== ogasawara is now known as Guest5458
=== JanC_ is now known as Guest89590
=== jhenke_ is now known as jhenke
=== cristian_c is now known as Guest10114
=== Guest5458 is now known as ogasawara
[16:57] <apw>  bug 1274987
[16:57] <ubot2`> Launchpad bug 1274987 in linux (Ubuntu) "can't boot with new lowlatency kernel" [High,Confirmed] https://launchpad.net/bugs/1274987
[17:04] <arges> smb: sforshee : hey running that openstack bug repoducer, any new news?
=== jono is now known as Guest16175
[17:05] <smb> arges, Not from my side. But I had a quick email exchange with Salvatore today and he tries to come up with something that does not require devstack
[17:05] <arges> smb: ahh just after I got it all working : )
[17:05] <smb> Though he was away for Friday and this morning. 
[17:05] <arges> well i just started the tests a bit ago... maybe i'll get lucky and reproduce
[17:06] <smb> arges, You can use that knowledge at least. :)
[17:06] <smb> arges, Right
[17:08] <smb> arges, There was also a comment in the bug referring to another one. But I am not sure this is separate or another piece of the puzzle. That was something that made the injection of data fail with some obscure ext2 error
[17:28] <rtg> apw, I'm here now
[17:29] <bjf> o/
[17:30] <apw> jsalisbury, rtg, ok ... yeah PREEMPT is a three way 'choice' so ... zap the ones in there with PREEMPT in their name and do an updateconfigs
[17:30] <jsalisbury> apw, I see that CONFIG_PREEMPT_VOLUNTARY is not set in the lowlatency, should I also re-enable that one?
[17:31] <apw> jsalisbury, if you rip the one thats there, you should get the little menu to chose and can pick the _VOLUNTARY one
[17:31] <apw> which akes all the other Y/N options go the right way too
[17:33] <jsalisbury> apw, ok, so just rip out the CONFIG_PREEMPT_VOLUNTARY and re-run update configs?  The menu will do the right thing and unset the other two PREEMPTs?
[17:34] <apw> jsalisbury, right
[17:35] <apw> it'll ask you, pick the right one, and it sets the "set" as a set appropriatly
[17:35] <jsalisbury> apw, cool thanks.  I'll build a kernel and post it to the bugs.
[17:35] <apw> do tell 'em its a diagnostic kernle, not a fix
[17:36] <jsalisbury> apw, ack
[17:36] <jsalisbury> apw, I assume I select option two:
[17:36] <jsalisbury> Preemption Model
[17:36] <jsalisbury>   1. No Forced Preemption (Server) (PREEMPT_NONE)
[17:36] <jsalisbury>   2. Voluntary Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY) (NEW)
[17:36] <jsalisbury> > 3. Preemptible Kernel (Low-Latency Desktop) (PREEMPT)
[17:37] <apw> yep thats wahts on on the others
[17:37] <jsalisbury> apw, thanks.  Just wanted to make sure I got it correct :-)
[17:38] <apw> ack
[17:43] <apw> jsalisbury, if i am reading the comments bug 1275116 right (comments #25ish to #30ish) then it is possible the noirq thing is working for them
[17:43] <ubot2`> Launchpad bug 1275116 in linux (Ubuntu) "lowlatency-flavour crashes and locks up alot" [High,Confirmed] https://launchpad.net/bugs/1275116
[17:43] <apw> so the testing we want is the right testing
[17:45] <jsalisbury> apw, Yeah, a second bug commenter stated it worked for them, but the original bug reported says it did not.
[17:45] <apw> usual dogpile, anyhow, we're doing The Right Thing(tm)
[17:46] <jsalisbury> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1275116/comments/24
[17:46] <ubot2`> Launchpad bug 1275116 in linux (Ubuntu) "lowlatency-flavour crashes and locks up alot" [High,Confirmed]
[17:46] <jsalisbury> apw, Kernel is building now, I'll let you know the testing results.
[17:47] <apw> jsalisbury, thanks, appreciated
[17:48] <jsalisbury> apw, np.  thanks to you as well
[17:52] <apw> rtg, did you rip that smb patch ?
[17:52] <rtg> apw, yep
[17:52] <rtg> apw, mess you up ?
[17:52]  * apw rebases ... again
[17:53] <smb> apw, You should learn not to mess with rtg 's tree after lunch... 3:-P
[17:54] <rtg> its just the way I roll.
[17:54] <apw> smb, oh i've learned ... just some days you cannot avoid it
=== neunon is now known as Guest34825
[17:54] <apw> just was confirming thats why i had a "..." in my world, can cope
[17:55] <smb> apw, Hehe, man you love the pain, do you. 
[17:56]  * apw practices grabbing his ankles ... good for the flexibility don't you know
[17:56] <smb> apw, Unfortunately that reply from upstream just came in... or I just saw it recently
[17:56]  * smb tries to squeeze a late between the dots
[17:56] <apw> "carry large changes out of tree for as little time as possible" is reinforced by an "active" upstream
[17:57] <apw> rtg, ok i've pushed the split for hyperv
[17:57] <smb> True. Even more if the deviation is only needed because of some config setting which upstream silently declares as unstable
[17:57] <apw> now i can go an look at pulling in heap of new bits which need to go in there
[17:57] <rtg> apw, ack
[18:22] <apw> rtg, i've pushed the matching -meta changes also
[18:23] <rtg> apw, ack
[18:23] <cristian_c> Hello
[18:24] <cristian_c> I've submitted a bug report (regarding a kernel bug) on launchpad almost two years ago
[18:24] <cristian_c> recently, the bug status has been set to Triaged and I was told to read this wiki page: https://wiki.ubuntu.com/Bugs/Upstream/kernel
[18:24] <cristian_c> I've read it but I've got some doubts yet. A dev has told me to contact the kernel team for preparing a faultless upstream report
[18:25] <cristian_c> the first question:
[18:25] <cristian_c> 1) Please take care that when you provide the below information, you should be booted into the newest available upstream mainline kernel only. Failure to do this will have negative unintended consequences.
[18:25] <cristian_c> I do not know what I have to use between two different kernel since they cause different problems
[18:29] <apw> cristian_c, what is your bug number, so we can see what the original request actually was
[18:30] <cristian_c> ok, I'll post immediately
[18:30] <cristian_c> apw, #972604
[18:30] <apw> bug #972604
[18:30] <ubot2`> Launchpad bug 972604 in linux (Ubuntu) "168c:001c [HP Compaq Presario C700 Notebook PC] Wireless led button doesn't switch colors" [Low,Triaged] https://launchpad.net/bugs/972604
[18:35] <jsalisbury> cristian_c, The mainline kernel you tested was 3.13-rc5, which is very old now.
[18:35] <jsalisbury> cristian_c, It might be best to test the latest mainline kernel before opening an upstream bug report.
[18:36] <jsalisbury> cristian_c, Otherwise, upstream will just ask you test test the latest first anyway.
[18:36] <apw> yeah they get all whiney if there is a 10th of a commit on top of what you tested
[18:36] <apw> there should be a 3.14-rc1 now  i guess
[18:36] <jsalisbury> cristian_c, You can get 3.14-rc1 at: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-rc1-trusty/
[18:37] <cristian_c> jsalisbury, the last kernel I tried ha made worse the things
[18:37] <cristian_c> *has
[18:37] <cristian_c> jsalisbury, I'd like to solve the original bug
[18:37] <jsalisbury> cristian_c, those new issues that made things worse could be resolved now, which is the reasoning for testing 3.14-rc1.  
[18:37] <cristian_c> new kernel change deeply the bug
[18:38] <cristian_c> *kernels
[18:38] <cristian_c> jsalisbury, ok
[18:38] <cristian_c> I'll try the new kernel
[18:38] <jsalisbury> cristian_c, based on the testing results from 3.14-rc1, we can decide what to do next.
[18:39] <cristian_c> ok
[18:39] <cristian_c> second question:
[18:40] <cristian_c> 2) While booted into the newest mainline kernel only describe how the bug is reproducible in the latest mainline kernel only. If this is a regression, please note the specific commit. 
[18:41] <apw> man what language is that in
[18:42] <apw> i think that means "tell me how to reproduce it in the mainline kernel, if you cannot there i don't care"
[18:43] <apw> "do not tell me how to reproduce it in ubuntu's kernel as i will stop listening"
[18:43] <cristian_c> apw, yes, but I'm referring to the commit
[18:44] <cristian_c> Is it the number of commits that introduced the latest regression?
[18:44] <cristian_c> *commit
[18:44] <apw> oh, so they mean if you know it does work in a specifc older kernel (mainline only) then they do want to know where you were when it worked perfectly
[18:44] <apw> i suspect in your case it probabally has never worked
[18:44] <apw> in whihch case it is not a regression, just broken
[18:45] <cristian_c> apw, exactly, I've opened the report for a specific bug
[18:47] <cristian_c> I've tried mny kernels, but only when I tried the 3.13.0, the bug is changed
[18:47] <cristian_c> *many
[18:47] <cristian_c> I can try the 3.14-rc1
[18:47] <cristian_c> to see if it's broken yet
[18:47] <cristian_c> :)
[18:47] <cristian_c> apw, thanks
[18:47] <cristian_c> :)
[18:48] <apw> np
=== jono is now known as Guest82971
=== hyperair is now known as Guest61598
=== Guest34825 is now known as neunon
=== zz_mwhudson is now known as mwhudson
[20:08] <rtg> sforshee, here is a good one for you to have a look at: bug #1275879
[20:08] <ubot2`> Launchpad bug 1275879 in linux (Ubuntu) "Kernel panic " [High,Incomplete] https://launchpad.net/bugs/1275879
[20:09] <sforshee> rtg: ack
[20:10] <rtg> sforshee, the stack trace has xen-netfront BUG line
=== cp is now known as Guest2850
=== kgunn is now known as Guest438
=== DarkPlayer_ is now known as DarkPlayer
=== backjlack_ is now known as backjlack
=== SpamapS_ is now known as SpamapS