=== mwhudson is now known as zz_mwhudson
=== zz_mwhudson is now known as mwhudson
[07:31] <ppisati> 1 2 3 test...
=== mwhudson is now known as zz_mwhudson
[08:19] <smb> ppisati, nobody is here to hear you screaming. :)
[08:19] <ppisati> nobody can hear you scream! :)
[08:20] <ppisati> let me start mumble so you can hear it at least... :)
[08:20] <smb> Heh
[09:09]  * apw yawns
[09:10]  * apw has a vision of ppisati being attached to large electrodes ... bzzzzztttt
[09:10] <RAOF> Bees!
[09:12] <apw> RAOF, Beeeees :)
=== psivaa_ is now known as psivaa
=== zz_mwhudson is now known as mwhudson
=== mwhudson is now known as zz_mwhudson
[12:13] <phillw> hi, please do not laugh :P when using make to compile a kernel up, how do I specify which .config file to use? 
[12:18] <phillw> I've made what I believe are the changes I want using menuconfig and saved the resulting file as .myconfig
[12:28] <phillw> sorry about that, the build a new kernel cooked my laptop! I'm stansferring over to the dedicated server :)
=== ricmm_ is now known as ricmm
[13:40] <eagles0513875> apw: re the multitouch patch can you follow up as I never got a response on the kernel input mailing list and it has been more then a few days
[13:47] <rtg> apw, 3.13.0-3 seems to have wrecked my user experience on a Dell M1710. nouveau crashes almost immediately.
[13:47] <apw> rtg, woh unexpected, was there anything much in there at all ?
[13:48] <rtg> just the rebase to -rc8 AFAICT
[13:48] <rtg> -2 works fine
[13:48] <rtg> guess I'll try the vanilla kernels first
[13:48] <apw> rtg, when you say crash does it bug ?
[13:49] <rtg> apw, all I get is the tail end of the stack dump
[13:49] <apw> arses
[13:49] <rtg> can't tell if its bugging or not
[13:52] <apw> is it locked so hard you cannot get in ?
[13:52] <rtg> yup
[13:52] <apw> phillw, depends if you are talking about a "make" in a mainline tree where it uses .config, or a debian package where it is "harder"
[13:55] <apw> rtg might be worth seing if you can boot it without graphics and the ssh in tail -f /var/log/syslog and then start X
[13:56] <phillw> apw I was at http://bodhizazen.net/Tutorials/kernel#easy and had worked out which pentium chips I wanted etc.... then headed to http://bodhizazen.net/Tutorials/kernel#Compile but suspect that I need to tell that command the name of my .config file?
[13:57] <rtg> apw, ack - rebooting to vanilla -rc7 and -rc8 just to be sure
[14:08] <rtg> apw, the last line printed with vanilla -rc8 is :
[14:08] <rtg> drivers/video/fbmem.c:                  printk(KERN_INFO "fb: conflicting fb hw usage 
[14:08] <rtg> that is without the  splash screen
[14:09] <smb> Hey that sounds a bit like the framebuffer eject problem all over the place again
[14:10] <rtg> smb, weren't you looking at a bug like that ?
[14:10] <smb> rtg, VMs and cirrus
[14:10] <rtg> hmm
[14:10] <smb> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1269401
[14:10] <ubot2> Launchpad bug 1269401 in linux (Ubuntu) "[Trusty] Switching framebuffers fails on VMs using cirrus" [Medium,Confirmed]
[14:11] <smb> I was told there should be a user-space fix that prevents load of the generic fb for certain cases
[14:11] <smb> In theory also cirrus but something seems to have gone amiss
[14:11]  * henrix remembers something like that on lkml...
[14:12] <smb> Main problem is plymouth doing something with the current fb even without splash
[14:13] <smb> So releasing the current one for another one cannot free resources
[14:13] <apw> rtg, hrm, nasty
[14:14] <rtg> apw, at least there are some google hits on that string
[14:14] <apw> not sure why the -rc7->-rc8 would expose that any more than before
[14:15] <rtg> apw, dunno. back in a asec, gonna migrate to my workstation so I can mess with this laptop and not disappear constantly.
[14:31] <apw> rtg, any luck ?
[14:33] <rtg> apw, uh, working on a couple of distractions. I'll get back to it in a sec
[14:36] <phillw> smb rtg https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1080674 it goes back a lot further :) As no one will fix it, I just use the work around.
[14:36] <ubot2> Launchpad bug 1080674 in cairo "[QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics). Affects KVM but not VBox." [Medium,Confirmed]
[14:39] <smb> phillw, Without looking into the bug... likely that is the background gfx issue when not using the cirrus drm driver... 
[14:40] <smb> Which iirc is a bug in the cirrus x driver in conjunction with probably llvm-pipe + unity
[14:40] <smb> and no nobody seems to care much about that
[14:40] <phillw> smb I did run with that bug for a while, but there is a limit as to how many brick walls you wish to bash your head on :)
[14:42] <smb> Sure and given the (not)performance of using llvm-pipe for 3d gfx anyway there seems to be a lost ground for running desktop in a VM (warning: very personal and opinion)
[14:44] <phillw> smb I'm not a kernel person! but the word 'cirrus' causes my ears to pick up, as I still have to use https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1080674/comments/43 when installing desktop systems into KVM
[14:44] <ubot2> Launchpad bug 1080674 in cairo "[QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics). Affects KVM but not VBox." [Medium,Confirmed]
[14:49] <smb> phillw, Right the current better option is to use a different virtual gfx card. If we can solve the race with the framebuffer you would have a kernel-mode-settting driver (the mentioned cirrus module) which then gets you X to use a generic kvm drivers which gives not corrupted gfx
[14:49] <smb> *shat should be generic kms
[14:52] <phillw> smb: like forrest gump, simple be, simple do. That work around works for me.. as to if https://bugs.freedesktop.org/show_bug.cgi?id=58574 will ever be fixed? Well, let's just say I'm not holding my breath :)
[14:52] <ubot2> Freedesktop bug 58574 in Driver/cirrus "pixmap regression with cirrus graphics driver" [Normal,New]
[14:54] <smb> phillw, Neither would I (hold my breath) :)
[14:56] <phillw> he he,,, well, I'm back to build a kernel on a VM that will not over heat and shut down... I'll be able to state how 12.04lts server to 14.04 lts server goes when I have made a new kernel :)
[15:07] <eagles0513875> apw: ping
=== manjo` is now known as manjo
[16:00] <rtg> apw, -rc8+ may have solved the problem
[16:10] <phillw> rtg: is it worth me trying http://bodhizazen.net/Tutorials/kernel and build a kernel, as the server spent 2 hours on upgrading to 14.04 and still has 3.8.0 as the kernel (NOT what I spent 2 hours waiting for)
[16:11] <phillw> :)
[16:12] <phillw> rtg: I have linux-3.13-rc8 on the VM.... your call :)
[16:12] <rtg> phillw, you upgraded to trusty and you _still_ have the raring kernel ?
[16:13] <phillw> rtg: indeed.... but that is a server test issue... i actually need trusty for a community respin
[16:14] <phillw> rtg: ali@amjjawad:~/src$ uname -a
[16:14] <phillw> Linux amjjawad 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[16:15] <rtg> I assume you rebooted ?
[16:15] <phillw> you assume correctly :)
[16:15] <rtg> dpkg -l|grep linux-image
[16:16] <phillw> ali@amjjawad:~/src$ Linux amjjawad 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[16:16] <phillw> No command 'Linux' found, did you mean:
[16:16] <phillw>  Command 'linux' from package 'user-mode-linux' (universe)
[16:16] <phillw> Linux: command not found
[16:16] <phillw> ali@amjjawad:~/src$ 
[16:17] <phillw> rtg:  this worked better
[16:17] <phillw> ali@amjjawad:~/src$ dpkg -l | grep linux-image
[16:17] <phillw> ii  linux-image-3.8.0-29-generic                          3.8.0-29.42~precise1                                      amd64        Linux kernel image for version 3.8.0 on 64 bit x86 SMP
[16:18] <rtg> cat /etc/lsb-release
[16:19] <phillw> rtg: ali@amjjawad:~/src$ cat /etc/lsb-release 
[16:19] <phillw> DISTRIB_ID=Ubuntu
[16:19] <phillw> DISTRIB_RELEASE=14.04
[16:19] <phillw> DISTRIB_CODENAME=trusty
[16:19] <phillw> DISTRIB_DESCRIPTION="Ubuntu Trusty Tahr (development branch)"
[16:19] <phillw> ali@amjjawad:~/src$ 
[16:19] <rtg> phillw, you upgraded from 12.04 ?
[16:20] <phillw> indeed, my best guess is that the server kernel was not allowed to update.... server kernels are funny things!
[16:21] <phillw> server was 12.04.3
[16:22] <rtg> phillw, hmm, I may know what happened. guess I'd better go fix that.
[16:23] <phillw> that's fine. can you ping me on #phillw (in case I have left here) to let me know what to do to bring that test area for 14.04 "up to speed". many thanks :)
[16:24] <BenC> apw: I'm having serious issues with 3.13. When it hits initramfs, I get immediate kernel stack overflow in random processes
[16:24] <BenC> apw: Are you guys syncing to a newer -rc soon?
[16:26] <rtg> BenC, we're up to -rc8 now. then next one should be the 3.13 release
[16:32] <BenC> rtg: I may have rebased before you did -rc8. When was that?
[16:32] <rtg> a couple days ago I think. apw did it
[16:33] <BenC> Nope, I'm on rc8
[16:33] <BenC> Let me check upstream tree and see if there's anything of interest
[16:35] <phillw> rc8 is the latest they advertise on https://www.kernel.org/ no doubt, there is another link I should look at :)
[16:36] <apw> BenC, hrm, thats very odd indeed stack overflow as in stack space exceeded implosions ?
[16:36] <rtg> BenC, there is on poerpc patch after -rc8
[16:37] <BenC> apw: As in, something is recursively going on inside the kernel, through a sys call from userspace
[16:37] <BenC> Unsure if the details, because it's no certain process or syscall
[16:38] <apw> rtg, perhaps we should do an interim re
[16:38] <apw> rtg, perhaps we should do an interim rebase, if they sound plausible
[16:38] <rtg> apw, I'm thinking about rebasing against tip for the nouveau fix
[16:39] <apw> that said, i don't think this one powerpc fix can be relevant
[16:39] <rtg> apw, it definitely blocks on console_lock() in -rc8, but works with tip. there are 4 patches that look to be of interest
[16:39] <apw> but if you needed to do it for that ... that'd be worth it
[16:39] <apw> as we are still rebasing and all
[16:39] <BenC> I'll inspect the patches and see if it fixes me before rebasing on your update
[16:40] <rtg> apw, you have anything in the pipe yu wanna commit ?
[16:40] <apw> BenC, this doesn't look hopeful, it is all old h/w
[16:41] <BenC> Ok, first I'll back out all of my sauce and see if that alleviates the issue
[16:41] <BenC> Best to make sure of that first
[16:41] <apw> rtg, nothing other than whats already pushed, i am trialing splitting out the hyper-v tools into their own tools package, might make maintenace easier and slim the virtual images
[16:41] <rtg> apw, ack, then I'll package and upload
[16:49] <phillw> if you guys would like a VM (OVH) I do still have a free one with unique ipV4. build it, break it as often as you wish :)
[17:22] <phillw> rtg please give me a ping when you have it fixed (or a note to phillw@phillw.net ) It seams I now have a queue :)
[17:26] <bjf[afk]> phillw, that's what bugs are for ... have you filed one?
[17:29] <phillw> bjf[afk]:  Nope I did not, as rtg sated that he saw the issue, I saw no reason to "raise paper work". We are sill in alpha area and a chat is often better than a bug report.... unless some one wants to get into the "I closed most bugs" report.... which the kernel team do not play in :D
=== bjf[afk] is now known as bjf
[17:31] <bjf> phillw, "paper work" is for just such a thing .. so you get notified of fixes. this has nothing to do with bug-games people play
[17:35] <phillw> bjf: I arrived here to ask a question, the question has been asked and an answer given. Had the person who is solving the issue wished a bug report to be raised, I'm quite sure he would have asked me to do so..... When it comes to devs... I approach quietly and do as I'm told :)
=== zz_mwhudson is now known as mwhudson
[19:50] <phillw> bjf: I cannot file a bug for the in ability to move from 12.04 to 14.04 at kernel level. As it is a server, the log in sequence to try and register a bug is none working
[20:06] <bjf> jsalisbury, we want to keep an eye on bug 1269917
[20:06] <ubot2> Launchpad bug 1269917 in linux (Ubuntu) "Kernel GPF" [Undecided,Incomplete] https://launchpad.net/bugs/1269917
[20:06] <jsalisbury> bjf, ack
[20:08] <bjf> jsalisbury, that apport collect failed to capture dmesg. i've not seen that HookError_source_linux.txt msg before.
[20:10] <jsalisbury> bjf, I haven't seen that one before either.  I'll see if it's happened before and keep an eye out for new ones.  
[20:26] <jsalisbury> bjf, think I should request testing of 3.11.10.3 and or mainline in bug 1269917 ?
[20:26] <ubot2> Launchpad bug 1269917 in linux (Ubuntu) "Kernel GPF" [High,Incomplete] https://launchpad.net/bugs/1269917
[20:26] <bjf> jsalisbury, no, i want them to test this new saucy kernel once it gets built
[20:26] <jsalisbury> bjf, got it, thanks.
[20:26] <bjf> jsalisbury, with 700+ commits in it we might get lucky
[20:26] <jsalisbury> bjf, yeah
[20:27] <jsalisbury> bjf, looks like saucy-proposed will be at 3.11.10.3 anyway.
[20:27] <bjf> jsalisbury, yes
[21:03] <phillw> jsalisbury: i mentioned an issue earlier, but as the machine is in flux, I cannot fully raise a bug
[21:03] <phillw> (16:19:56) rtg: phillw, you upgraded from 12.04 ?
[21:03] <phillw> (16:20:50) phillw: indeed, my best guess is that the server kernel was not allowed to update.... server kernels are funny things!
[21:03] <phillw> (16:21:26) phillw: server was 12.04.3
[21:03] <phillw> (16:22:05) rtg: phillw, hmm, I may know what happened. guess I'd better go fix that.
[21:04] <phillw> jsalisbury: I most likely have the log on the VM but cannor send them to you good people :(
[21:05] <bjf> phillw, you can use: https://bugs.launchpad.net/ubuntu/+source/linux/+filebug to file a bug from a different system if that helps
[21:06] <jsalisbury> phillw, Would you be able to open a bug report manually at launchpad.net ?  You should be able to select Ubuntu as the distro and Linux as the package.
[21:06] <jsalisbury> heh, or just follow the link from bjf :-)
[21:07] <phillw> jsalisbury:  and bjf oh, i need to go password hunting :)
[21:08] <phillw> ahh, wonderful... it requires GUI.... :(
[21:09] <phillw> ali@amjjawad:~$ https://bugs.launchpad.net/ubuntu/+source/linux/+filebug
[21:09] <phillw> -bash: https://bugs.launchpad.net/ubuntu/+source/linux/+filebug: No such file or directory
[21:09] <phillw> ali@amjjawad:~$ 
[21:12] <jsalisbury> phillw, You would need to enter that URL in a web browser, not from the command line.
[21:12] <phillw> jsalisbury: that is a server VM (KVM) is has no browser
[21:13] <apw> lynx ?
[21:14] <phillw> apw: the VM is a try to be 14.04, but the upgrade has messed up and it still have 12.04 kernel. 
[21:23] <phillw> jsalisbury: scroll back to (12:12:39) UTC and do feek free to join #phillw to tell me off :)
[21:23] <phillw> s/feek/feel/
[21:24] <phillw> and, of course, being CLI... have no idea of the command to issue :)
[21:33] <phillw> jsalisbury: Linux amjjawad 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[21:39] <phillw> that does seem a bug when you issue dist-upgrade -d .... this does need resolving as it spends two hours doing things and leaves you with 
[21:39] <phillw> ali@amjjawad:~$ uname -a
[21:39] <phillw> Linux amjjawad 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 16:19:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[21:39] <phillw> and 
[21:39] <phillw> ali@amjjawad:~$  cat /etc/lsb-release
[21:39] <phillw> DISTRIB_ID=Ubuntu
[21:39] <phillw> DISTRIB_RELEASE=14.04
[21:39] <phillw> DISTRIB_CODENAME=trusty
[21:39] <phillw> DISTRIB_DESCRIPTION="Ubuntu Trusty Tahr (development branch)"
[21:39] <phillw> ali@amjjawad:~$ 
[21:40] <phillw> jsalisbury:  ^^
[22:13] <infinity> phillw: apt-get install linux-generic
[22:14] <infinity> phillw: And the migration path for lts-backport kernels is known to be a bit sketchy right now, we need to solve that.
[22:14] <hallyn> sforshee: sorry i've not had a chance to test that patch myself, but it looked good to me (and i assume you've tested it yourself)
[22:14] <hallyn> will install and test it tomorrow. 
[22:14] <sforshee> hallyn: I have, but I noticed something today that makes me think there's something else going on
[22:15] <sforshee> upstart opens console with O_NOCTTY, which should prevent it owning the tty
[22:15] <sforshee> so I still don't know how upstart ends up owning that tty
[22:15] <phillw> infinity: thanks, I'll try that. 
[22:17] <hallyn> sforshee: ah.  interesting.
[22:18] <hallyn> potentially a bug elsewhere then...
[22:18] <sforshee> yeah, not sure where though
[22:18] <sforshee> is there some way I could strace init when it starts in the container?
[22:23] <phillw> infinity: no major errors, can I ask it to be a new kernel, or is it still too unstabe?
[22:23] <infinity> phillw: It'll default to being the current kernel, and we're all running it.
[22:27] <phillw> infinity: when I go to http://bodhizazen.net/Tutorials/kernel#easy for my non-pae kernel build how do I tell it to use the the .config file I want them it to use,?
[22:30] <infinity> phillw: Read the paragraph you linked to me?
[22:31] <phillw> infinity:  bohdi-zazen is on #phillw  -- much easier to chat there?
[22:32] <infinity> phillw: Dude, you just asked me how to do the thing that that paragraph tells you how to do.  Pretty sure more chatting won't clear that up.
[22:34] <phillw> infinity: and I install kernel 3.13 on to that 12.04 VM?
[22:34] <phillw> that is what I'm awaiting for,
[22:37] <infinity> phillw: What 12.04 VM?  You were talking about a 14.04 system above...
[22:37] <infinity> phillw: Or, so lsb_release claimed.
[22:41] <phillw> infinity: That is why you say what you say, and the bug team go "we do not believe you".... But, I actually believe bohdi-zazen who is on #phillw.