[10:45] <caribou> morning,
[10:46] <caribou> did someone hear about an Oneiric kernel issue wrt KVM ?
[10:46] <caribou> Everytime that I start an Oneiric VM, it fails to shutdown properly & I end up having to 'virsh destroy' the instance
[10:46] <caribou> I don't see that with any other version
[12:31]  * apw waves
[14:24] <apw> ppisati, about ?  do you normally prepare uploads for herton for natty/ti-omap4 and lucid/fsl-imx51 or do they do them ?
[14:33] <ppisati> apw: i do
[14:52] <ppisati> kexec on arm? just 75 patches away from master, but it works now! :)
[15:44] <cking_> ppisati, yay well done!
[15:56] <jsalisbury> **
[15:56] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:56] <jsalisbury> **
[16:12] <ppisati> "
[16:28] <Pietjepuk> Hy all !!  this line: int cx231xx_tuner_callback(void *ptr, int component, int command, int arg) is cousing a kernel oops : BUG: unable to handle kernel NULL pointer dereference at  (null) ..... I have no clue of c language... is this simple to solve ???  More details are here : http://pastebin.com/7Jh80Zev
[16:30] <Pietjepuk> Hy all !!  this line: int cx231xx_tuner_callback(void *ptr, int component, int command, int arg) is cousing a kernel oops : BUG: unable to handle kernel NULL pointer dereference at  (null) ..... I have no clue of c language... is this simple to solve ???  More details are here : http://pastebin.com/7Jh80Zev
[16:40] <GrueMaster> I see new SRU kernels in the pipeline for ARM systems.  For me to be able to test them for publishing before EOY, they need to be available before this Thursday, 22 Dec.  Otherwise I won't be able to get to them until 3 Jan.
[17:13] <apw> GrueMaster, yeah doko is very keen to have them in -proposed so they can put them on the buildds
[17:13] <apw> GrueMaster, these carry the mmap fix, though i am inclined to say if they pass light testing from you, we get them tested for that bug by putting them on a buildd and testing the affected package build
[17:14] <apw> GrueMaster, actually i think doko has a quick test for the fix rather than that java nightmare you were using
[17:16] <Pietjepuk> Hy all !!  this line: int cx231xx_tuner_callback(void *ptr, int component, int command, int arg) is cousing a kernel oops : BUG: unable to handle kernel NULL pointer dereference at  (null) ..... I have no clue of c language... is this simple to solve ???  More details are here : http://pastebin.com/7Jh80Zev
[17:22] <apw> Pietjepuk, in general not easy to solve from just that information no
[17:22] <apw> Pietjepuk, is this with some kind of extra backport modules from somewhere?
[17:23] <Pietjepuk> this is trying to modify the cx231xx driver for use with a new device...
[17:23] <apw> Pietjepuk, it looks like the detect probe failed and the driver didn't cope with its own probe function failing ... poor driver i'd suggest
[17:24] <Pietjepuk> So I understood wrong in assuming that if I appoint a (useless but not empty) value this will not occur ?
[17:25] <Pietjepuk> this is used in a function I do not need in the driver ... a tuner init... the whole function can be deleted for my purpose, but I don't know how...
[17:27] <ppisati> brb
[17:30] <apw> Pietjepuk, it is likely the driver will use the pointer you return
[17:30] <Pietjepuk> Allready tried just to comment it out (http://pastebin.com/x5s7WWsW line 682-717), but this returns an error, seems cx231xx_tuner_callback is used lateron allso... 
[17:30] <apw> many other drivers have no tuner so there must be a way to say that
[17:32] <Pietjepuk> ... I allready tried swtching usb id's... no matter which device in the code I use I get the same error... Allso if I select one which has a tuner.. ( but of course I connect the wrong device afterwards... )
[17:32] <apw> but you are definataly into very specific media tuner knowledge, so you are probabally going to get more useful help on their channel than here, we are more generalists really
[17:34] <Pietjepuk> apw: ... you are probably right, but I thought this would be an easy thing to get out of the way... obviously it's not.... (They sugested I put it in their ML .. but I'm kinda to impatient maybe...)
[17:35] <apw> without the h/w in hand and a firm grasp of the framework here and of C you are in a world of difficulty really
[17:37] <Pietjepuk> Think I'll have to go with the mailinglist then.... Thanks for your time !
[18:04] <GrueMaster> apw: Sorry, had to step out for a bit.  The testing I do is mostly automated, and only takes 3.5 hours at this time for most systems (imx51 & dove are quicker).
[18:05] <GrueMaster> So the time it takes to run is mostly irrelevant.  I have a qrt test that fails w/o the mmap fix, so the results should be fairly quick.
[18:06] <GrueMaster> My only problem is I will be out of state starting Friday, and won't be able to do the manual tests for SRU (which take ~5 minutes, but need to be hands-on).
[19:05] <apw> GrueMaster, yes with luck you should have testable images by 09:00 GMT, even if they are just in the c-k-t PPA, and in -proposed as soon as i can get an AA to hit buttons
[22:25] <mustafa_> Hi everyone,  i want to join kernel team to contribute the development
[22:26] <mustafa_> what should i do?
[22:58] <JanC> say around longer...
[22:58] <JanC> stay*