=== hughhalf is now known as hughhalf_afk
=== hughhalf_afk is now known as hughhalf
[16:43] <Kano> hi, when will there be 3.18 rc6 in vivid?
[16:44] <Kano> its rebased but not tagged
[17:00] <sajan> I was wondering if someone can tell me when the following iwlwifi patch would be pulled in and available in the Ubuntu kernel.  I installed 3.17.1 on a Utopic system and doesn't seem to be there. - http://bit.ly/15f4WIn.  Would it be there in the next 3.17.x build?  If so, when does that happen?  Thanks.
[17:13] <sforshee> sajan: I'm not sure when that will make it to vivid. It should be in the utopic kernel that was just released, but it won't make it into trusty for several more weeks.
[17:14] <sajan> sforshee: Thanks.
[18:34] <infinity> sforshee: If it's in utopic, it's in vivid.
[18:34] <infinity> Well, vivid-proposed.
[18:49] <binBASH> Hi tinoco, I saw you assigned yourself https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1318551
[18:49] <ubot5> Launchpad bug 1318551 in linux (Ubuntu) "Kernel Panic - not syncing: An NMI occurred, please see the Integrated Management Log for details." [High,Confirmed]
[18:49] <binBASH> If you need more info you can write me :-)
[18:50] <tinoco> binBASH: hey
[18:50] <tinoco> i did..  cause i just got a UA bug around this
[18:50] <tinoco> recommended customer to (workaround) deactivate max cstates 
[18:50] <tinoco> asked him to update their firmware (using some HP already reported cases)
[18:50] <tinoco> and im investigating little further now
[18:51] <tinoco> i got a crash on the idle task :D
[18:51] <binBASH> The workaround I use is noautogroup kernel boot parameter
[18:51] <tinoco> binBASH: i´ve seen the bisect. you made it ?
[18:51] <binBASH> Nope, because I dunno where I should start
[18:52] <binBASH> I'm not kernel specialist, sorry
[18:52] <tinoco> binBASH: did it work with you ?
[18:52] <tinoco> have u tried de-activating c-states ?
[18:52] <binBASH> Could try it
[18:52] <tinoco> could you ? and report it back on the public bug ?
[18:52] <binBASH> If bios allows it. I have the issue on my desktop...
[18:53] <tinoco> try appending this to kernel cmdline (/etc/default/grub) "intel_idle.max_cstate=0 processor.max_cstate=0"  
[18:53] <tinoco> and/or disabling it by BIOS
[18:53] <tinoco> binBASH: what server are u using ?
[18:53] <tinoco> is it a proliant ? or just your workstation ?
[18:54] <binBASH> Well, I have it on multiple systems
[18:54] <tinoco> :\ hum
[18:54] <binBASH> But the desktop here is Gigabyte board...
[18:55] <binBASH> Cheap Desktop HW :)
[18:55] <tinoco> yep. but it might be related to samething
[18:55] <tinoco> good for us if you can test these and report it on the public bug
[18:55] <tinoco> its always good to get feedback from other platforms 
[18:55] <binBASH> I will try it in the next 5 mins :)
[18:56] <binBASH> Just let me finish eating up my dinner please
[18:56] <tinoco> great :D . did noautogroup solve the thing for you ?
[18:56] <binBASH> yup
[18:56] <binBASH> it did. No issue with it
[18:56] <tinoco> hum.. it might be related to the way idle_task handles cpu instructions
[18:56] <tinoco> i´ll check code and see what is modified by using this
[18:56] <tinoco> binBASH: really appreciate 
[18:56] <tinoco> let me know any feedback you might have regarding this
[18:57] <binBASH> When I don't use the param it crash during boot in 99%
[18:57] <tinoco> binBASH: yep.. i´ve been informed people are getting this randomly with proliant servers
[18:57] <tinoco> i received a kernel dump with the idle task causing the panic
[18:57] <tinoco> and found the public bug.. looks like it fits on my case
[18:58] <binBASH> yeah, it can happen also after boot process randomely. It crashs so bad even Magic-Sysreq doesn't work then
[18:58] <tinoco> yep.. lets see if c-states being disabled handles the issue
[18:58] <tinoco> if they do.. i´ll look deeper why
[18:58] <binBASH> ok, sec. I'll add the params you gave to cmd line
[18:59] <tinoco> take your time ;) lol
[19:01] <binBASH> Ok, will reboot now, brb
[19:08] <binBASH> ok tinoco, I've tested boot now several times, the params don't fix it
[19:09] <tinoco> binBASH: what about disabling C-states under BIOS ?
[19:09] <tinoco> do you have that option ?
[19:09] <binBASH> I can test it as well np
[19:10] <tinoco> binBASH: please, tks
[19:11] <binBASH> tinoco: The mainboard I'm using btw. is Gigabyte H77-D3H with Intel i7-3770K cpu
[19:12] <tinoco> im getting errors with this: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz      
[19:12] <tinoco> but i´ve seen cases where upgrading bios/firmware solved similar issues for proliant
[19:13] <binBASH> Do you have EFI system?
[19:13] <binBASH> Because I'm using EFI boot
[19:13] <tinoco> binBASH: have u tried upgrading your firmwar e?
[19:13] <binBASH> Nope
[19:13] <tinoco> i wonder if we are having the same problem here
[19:13] <tinoco> cause people informed about not using c-states to fix
[19:14] <tinoco> and you fixed by changing way scheduler behaves
[19:14] <tinoco> is it possible for you to generate a crash
[19:14] <binBASH> I will try to disable C-states in bios
[19:14] <tinoco> and upload it to the case ?
[19:14] <tinoco> yep, please
[19:14] <binBASH> reboot brb... :)
[19:14] <tinoco> ;)
[19:25] <binBASH> tinoco: nope, didn't fix it
[19:25] <tinoco> yep.. i think we might be facing different things
[19:25] <tinoco> anyway, could you generate a kernel dump
[19:25] <tinoco> and attach to the public case ?
[19:26] <tinoco> i can further analyse if is the same case, if they are related or not
[19:26] <tinoco> binBASH: but i would suggest you a bios update before
[19:26] <tinoco> just in case
[19:26] <tinoco> and tks for the tries, anyway :)
[19:28] <binBASH> np
[19:28] <binBASH> Will try to find out how to do it :)
[19:28] <tinoco> binBASH: https://wiki.ubuntu.com/Kernel/CrashdumpRecipe
[19:29] <binBASH> Yeah, currently reading it, thx