[09:43] <apw> cking, mooin
[09:43] <cking> apw, hiya
[10:58] <pgraner> apw, ping
[11:00]  * ppisati -> back in 10mins
[11:21] <apw> pgraner, pong
[11:23] <pgraner> apw, hey just a heads up I'm getting lots of MCEs in the new kernel and my box has locked up twice a few mins after resuming from suspend
[11:23] <pgraner> apw, I'm traveling today but will debug when I get home
[11:24] <apw> pgraner, that sounds bad, -9 yes?  drop back to -7 and see if it persists, could always be true
[11:27] <pgraner> apw, will do, also lots of strange ecryptfs errors now with this kernel as well
[11:27] <apw> pgraner, cking has the same machine and is having no trouble ... hmm
[11:28] <cking> very nearly almost the same machine
[11:28] <pgraner> apw, this is what I get right before it hangs
[11:28] <pgraner> [ 2097.443535] [Hardware Error]: Machine check events logged
[11:28] <pgraner> [ 2152.493292] CPU2: Package power limit notification (total events = 2551)
[11:28] <pgraner> [ 2152.493297] CPU0: Package power limit notification (total events = 2548)
[11:28] <pgraner> [ 2152.493300] CPU3: Package power limit notification (total events = 2551)
[11:28] <pgraner> [ 2152.493302] CPU1: Package power limit notification (total events = 2548)
[11:28] <pgraner> [ 2152.494510] CPU0: Package power limit normal
[11:28] <pgraner> [ 2152.494514] CPU2: Package power limit normal
[11:28] <pgraner> [ 2152.494516] CPU3: Package power limit normal
[11:28] <pgraner> [ 2152.494518] CPU1: Package power limit normal
[11:29]  * apw is pretty sure there was no ecryptfs changes in the mix between -7 and -9
[11:29] <pgraner> apw: this is what I get
[11:29] <pgraner> [ 1697.455029] Valid eCryptfs headers not found in file header region or xattr region
[11:29] <pgraner> [ 1697.455032] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO
[11:30] <pgraner> apw, just keep your eye out, could be just my crap box
[11:30] <apw> pgraner, i suspect that is an empty file in your lowerdir, that was hitting rtg too
[11:30] <apw> probabally caused by all the crashing you are having
[11:30]  * pgraner nods
[11:31] <pgraner> apw, well time to take this steaming pile of dung offline for a bit, got a flight to catch
[11:31] <apw> luck man
[11:31] <pgraner> apw, thanks later
[12:01]  * ppisati -> out for lunch
[15:19] <jsalisbury> **
[15:19] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:19] <jsalisbury> **
[15:20] <kirkland> pgraner: try: find $HOME/.Private -size 0
[15:20] <kirkland> pgraner: looking for 0-byte files
[15:20] <kirkland> pgraner: which, ecryptfs considers "invalid" since there are no headers
[15:20] <kirkland> pgraner: sorry, you need a trailing slash
[15:21] <kirkland> pgraner: find $HOME/.Private/ -size 0
[15:21] <tgardner> kirkland, I've a patch in progress with tyhicks to print inode numbers which will make those bogus files easier to find
[15:21] <kirkland> tgardner: cool
[15:21] <kirkland> tgardner: pgraner: here's another trick:
[15:21] <kirkland> ecryptfs-find $(find $HOME/.Private/ -size 0)
[15:22] <kirkland> that'll show you decrypted (real) filenames of the offenders
[15:22] <tgardner> kirkland, then you can do 'find $HOME/.Private/ -inum INODE'
[15:22] <kirkland> tgardner: I have one right now, /home/kirkland/.speech-dispatcher/speechd.sock
[15:22] <kirkland> no effing clue what that is
[15:22] <kirkland> so i'm removing it
[15:22] <tgardner> kirkland, that is generally your only option
[15:23] <tgardner> kirkland, cking is about to start doing some thorough ecryptfs testing. I expect he'll shake out a few more bugs
[15:23] <cking> that's my plan :-)
[15:26] <kirkland> tgardner: cool
[15:26] <kirkland> cking: awesome, thanks
[15:26] <cking> tgardner, kirkland, any specific releases to concentrate on?
[15:27] <tyhicks> kirkland: Are you running precise? Did you have any hard crashes that could have resulted in that zero length file?
[15:27] <tyhicks> cking: Are you asking about kernel or ecryptfs-utils releases?
[15:28] <cking> tyhicks, well, I suppose both if necessary
[15:28] <tgardner> cking, lets start with precise, then work backwards. Lucid definitely needs some love
[15:29] <cking> ack
[15:29] <tyhicks> Ah, I was misunderstanding the question. I agree with tgardner.
[15:30]  * cking has a nice ivybridge multicore box with raid to try this out
[15:30] <kirkland> tyhicks: I am not running precise yet
[15:30] <kirkland> tyhicks: still on 11.10
[15:30] <kirkland> cking: kernel or userspace releases?
[15:30] <tyhicks> kirkland: Any recent hard crashes?
[15:30] <kirkland> cking: i agree with tgardner 
[15:31] <kirkland> tyhicks: nothing in a very long time
[15:31] <kirkland> tyhicks: however, i shutdown my laptop almost every day now
[15:31] <cking> kirkland, gonna start with precise userspace + kernel
[15:31] <kirkland> tyhicks: whereas before, i'd suspend/resume for weeks at a time
[15:31] <tgardner> kirkland, I think there still exist some inode race bugs in 11.10 that haven't been backported. tyhicks - isn't that correct?
[15:31] <kirkland> tyhicks: basically, i never used to reboot except for when there was a pending kernel update reboot
[15:31] <tyhicks> tgardner: Well, I think that the fix is still in -proposed
[15:32] <kirkland> tyhicks: however, i have a problem that I haven't tracked down, with openvpn, iwlagn, and suspend/resume
[15:32] <cking> lemme understand the domain first, then I'll write a bunch of tests and put them ultimately in a git repo 
[15:32] <kirkland> tyhicks: when i suspend my laptop at home, and resume at the office, i get 8 seconds of networking, and then poof -- no more networking until i reboot
[15:33] <tyhicks> kirkland: Strange. The reason I was asking is because tgardner has had some zero length files pop up recently.
[15:34] <kirkland> tyhicks: precise?  and he's had hard crashes, presumably?
[15:34] <kirkland> tyhicks: i reckon i'll bump up to precise in a month or so
[15:34] <tyhicks> kirkland: There's some uncertainty about when they showed up, but it is something that we need to keep a close eye out for
[15:34] <kirkland> tyhicks: current job doesn't lend itself to fighting with alpha-quality OS problems on a daily basis ;-)
[15:35] <tgardner> kirkland, no hard crashes (I think), but I've killed t-bird a time or 2 which is where my 0 length files popped up (in .cache)
[15:35] <kirkland> tyhicks: tgardner: interestingly, the file I just nuked looked like it was a "socket"
[15:36] <kirkland> tgardner: maybe keep your eyes out for your 0-byte files, and see if there's a pattern at all around sockets
[15:36] <kirkland> tgardner: tyhicks: also, it's almost always a cache file that this happens to, in my experience
[15:36] <kirkland> ie, its rarely a file that i lose sleep over
[15:37] <tyhicks> We should be passing non-regular files (like sockets) through without touching them. There may have been a regression, though.
[15:40]  * ogasawara back in 20
[16:11] <jsalisbury> apw, I noticed you were working on bug 894768  If you have a chance, can you take a look at comment #43 in that bug?  
[16:11] <ubot2> Launchpad bug 894768 in linux "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument " [High,Fix released] https://launchpad.net/bugs/894768
[16:20] <dannf> ogasawara: anything more i need to provide for #647043, other than eventual testing of proposed updates? wasn't clear to me if i should send a patch w/ my 2.6.35 backport to the list or not
[16:20] <ogasawara> bug 647043
[16:20] <ubot2> Launchpad bug 647043 in linux "Dell Studio 1536 Unable to detect USB ports (Maverick)" [Medium,In progress] https://launchpad.net/bugs/647043
[16:23] <ogasawara> dannf: so it looks like the patches have been cc'd to upstream stable and noted that they should be applied from 2.6.34 onward.  so we should get them though our normal SRU maintenance process.
[16:23] <dannf> ogasawara: is 2.6.35.y still maintained upstream? 
[16:23] <ogasawara> dannf: that I'd have to check
[16:23] <dannf> if so - i probalby need to send them my patches - they won't apply cleanly
[16:23] <dannf> (file renames)
[16:23] <apw> jsalisbury, the bug in that code was introduced realtivly soon previous to us seeing it, whether it was there long enough to be in the previous release i don't know off the top of my head
[16:24] <ogasawara> dannf: if anything, I'd suggest just sending them to the kernel-team mailing list and ask them to be applied as pre-stable
[16:25] <jsalisbury> apw, thanks for the info.
[16:25] <apw> i'll add it to my todo to try and figure it out
[16:25] <jsalisbury> apw, thanks
[16:27] <smb> dannf, 2.6.35.y looks rather neglected to me
[16:27] <smb> or abandoned even
[16:27] <dannf> ogasawara: ok. perhaps i should wait until the corresponding stable updates flow into oneiric/precise trees and then do that for mav/nat? i don't want to cause extra work, and it seems like getting the fix in devel is normal policy
[16:28] <dannf> smb: yeah - its not a longterm one afaik, and i don't know of anyone who's picked up maintenance
[16:28] <dannf> s/in devel/in devel before backporting/
[16:29] <apw> dannf, if they are fixes you are sending in for those others, its almost better to have the fix for everything at once
[16:29] <apw> so one person can apply them and make sure they are all on at once
[16:29] <apw> (not that i have a clue what they fix :)
[16:29] <ogasawara> dannf: +1 to what apw just said
[16:30] <dannf> ok
[16:30] <dannf> usb-doesn't-work-at-all on some laptops
[16:30] <dannf> is what it fixes
[16:30] <ogasawara> dannf: I'll go ahead and just pick the patches for Precise right now (hoping they cherry-pick cleanly)
[16:30] <apw> bah why would we want that for :)
[16:30] <dannf> ogasawara: yeah, they do - should all the way back to natty
[16:31] <dannf> ogasawara: thanks
[16:31] <ogasawara> dannf: for Oneiric and earlier we'll need a proper SRU (ie patches sent to mailing list, 2 Ack's, etc)
[16:32] <dannf> ogasawara: ok.
[16:52]  * ogasawara runs to make coffee before meeting
[16:57] <cking> apw, http://download.intel.com/technology/computing/vptech/Intel%28r%29_VT_for_Direct_IO.pdf
[16:57] <bjf> -meeting
[17:04] <ogra_> ppisati, hummm ... did you see the mail from ndec about basing the omap4 kernel for precise on 3.3 instead of 3.2 ?
[17:07] <ogra_> ppisati, i have no idea if thats doable for you guys wrt maintining it, could you answer the thread ?
[17:09] <ppisati> ogra_: saw the email, and and we are discussing what to do
[17:09] <ogra_> great
[17:09] <ppisati> ogra_: my gut feeling is that, if we can we are gonna stay with 3.2
[17:09] <ogra_> take your time, we can bring it up in the friday call 
[17:09] <ogra_> so dont make a rushed decision, i will defend whatever the kernel team decides here :)
[17:12] <ppisati> if it's not mandatory to have hw accelerated video decoding and the new X stuff (that, anyway, will still require some PPA components), we are going to stay with 3.2 for P and suggest people to install Q kernel if they need these new features
[17:13] <ogra_> well, its mandatory to have working GLES
[17:14] <ppisati> does it work now?
[17:14] <ogra_> we had releases without multimedia stuff before, but never had one where GLES was broken
[17:14] <ogra_> so as long as the latter works i'm fine ...
[17:15] <ogra_> there is a lot of work going on to make unity (3D) work in precise, so the GLES bits are kind of essential :)
[17:15] <ppisati> ok, but since it's arm hw we can tell people to switch to unity 2d and no one can complaing so much about it
[17:16] <ppisati> anywa
[17:16] <ppisati> y
[17:16] <ppisati> how do i check about this GLES stuff?
[17:16] <ogra_> that would mean 2 years of wasted work on porting unity to GLES 
[17:16] <ogra_> i dont think thats acceptable 
[17:16] <ppisati> ok, but Linaro is holding to 3.1 since some multimedia stuff is broken in 3.2
[17:17] <ppisati> and some pieces won't be ready for P anyway
[17:17] <ogra_> right, as i say, multimedia is fine to not have 
[17:17] <ppisati> so, either way, we are going to ship a "broken" product
[17:17] <ogra_> graphics support is essential to have 
[17:17] <ppisati> but when you say graphic support
[17:17] <ppisati> what you mean?
[17:17] <ppisati> a working X?
[17:17] <ogra_> the prob is what will TI do wrt making GLES still work on 3.2 if they skip it
[17:17] <ogra_> a working accelerated X, yes
[17:18] <ppisati> well, X works with the actual P kernels
[17:18] <ogra_> framebuffer or accelerated ? what did you test :P 
[17:18] <ogra_> (i.e. did you install the dkms PVR drivers ?)
[17:18] <ppisati> nope
[17:18] <ogra_> right
[17:18] <ppisati> that is not avai;lable
[17:19] <ogra_> it is, if you click the icon on the desktop they get installed 
[17:19] <ppisati> let me try
[17:19] <ogra_> (the TI icon i mean ... that code might currently be broken though but will be fixed before A2)
[17:20] <ppisati> can't i apt-get $something?
[17:20] <ogra_> it installs the DKMS based PVR driver from the TI PPA ... this part is supposed to mive to restricted soon 
[17:20] <ogra_> *move
[17:20] <ogra_> did it not work ?
[17:20] <ppisati> so, does the icon work right now?
[17:21] <ogra_> i have no idea, but it definitely will for A2
[17:21] <ogra_> aqnd thats not the point 
[17:22] <ogra_> we always shipped with GLES support threough this icon, in precise that will be handled a bit differently but this shouldnt be your headdache, what we need to make sure is that GLES works in the final release
[17:22] <ppisati> ok
[17:22] <ppisati> so GLES is mandatory, got it
[17:22] <ogra_> we can live without fullHD video playback imho
[17:23] <ogra_> so multimedia isnt actually mandatory ... we had that in the past 
[17:23] <ppisati> icon doesn't work
[17:23] <ppisati> let me install via PPA
[17:23] <ogra_> right, thats what the icon does
[17:24] <ogra_> (as i said, the driver stuff will move to restricted and be handled by jockey for final release)
[17:24] <ogra_> (so there wont be an icon anymore but he "additinal hw drivers are availabel" dialog instead)
[17:24] <ppisati> pvr-omap4-dkms?
[17:25] <ogra_> they currently should work if you manually install them, linaro develops the unity fixes based on that 
[17:25] <ogra_> just install the metapackage 
[17:25] <ogra_> ubuntu-omap4-extras-graphics or so 
[17:25] <ogra_> but as i said, linaro uses that driver daily so it should currently work 
[17:25] <ppisati> nope
[17:25] <ogra_> if it doesnt we have to fix it before final release
[17:25] <ppisati> they use it on 3.1 i guess
[17:25] <ogra_> but even that doesnt matter 
[17:26] <ogra_> we have rto have it *by release date* ... working with teh kernel we ship then ....  thats the point 
[17:26] <ppisati> but it
[17:26] <ppisati> 's impossible even if we move to 3.3
[17:27] <ppisati> because some components won't be ready
[17:27] <ppisati> so, in both directions, we are screwed
[17:27] <ogra_> i dont know, the mail only talks about multimedia (codecs and syslink etc)
[17:27] <ogra_> that doesnt touch GLES at all
[17:27] <ppisati> ok, so first le't gather some info about this GLES dkms
[17:28] <ogra_> i dont think anything changed about it since the 2.x.x days 
[17:28] <ogra_> and it should just work even with the current kernel we have in the archive
[17:28] <ppisati> they said syslink is broken in 3.2
[17:29] <ppisati> dunoo if it's a dependency
[17:29] <ogra_> yes, syslink is for video playback 
[17:29] <ogra_> nothing to do with 3D support
[17:29] <ogra_> lets discuss it at the call wheer ndec can give input
[17:29] <ppisati> agrred
[17:30] <ppisati> *e
[17:30] <ogra_> I#m pretty sure syslink and GLES are independent 
[17:30] <ppisati> i hope they are
[17:46] <ppisati> uhm
[18:25] <rsalveti> ppisati: sgx and syslink are quite independent 
[18:25] <rsalveti> ppisati: and it's a lot easier to enable sgx
[18:25] <rsalveti> because it's out of the tree
[18:25] <rsalveti> and something the ti lt will work on anyway 
[18:50] <ogasawara> dannf: for bug 647043, I assume you have hw to test with?  If so, what arch?  I wanted to have you install a Precise test kernel before I push the patches to the main repo.
[18:50] <ubot2> Launchpad bug 647043 in linux "Dell Studio 1536 Unable to detect USB ports (Maverick)" [Medium,In progress] https://launchpad.net/bugs/647043
[18:50] <dannf> ogasawara: i386, pae
[18:50] <ogasawara> dannf: ack, thanks
[19:21] <ogasawara> dannf: test kernel -> http://people.canonical.com/~ogasawara/lp647043/i386/
[19:21] <ogasawara> dannf: I'll post a comment to the bug with the same info, if you could respond with your feedback there that would be great
[19:21] <dannf> ogasawara: absolutely, thanks!
[19:46] <tjaalton> does precise not have aufs? sbuild seems unhappy
[19:49] <tjaalton> ok so overlayfs seems to have replaced it
[19:56] <geri> ji
[19:56] <geri> hi
[19:57] <geri> how can i recompile the kernel usb driver and manually load it with modeprobe? is that possible?
[19:57] <ohsix> usb is many drivers, if you mean usbcore no
[19:57] <geri> i patched the usb driver and dont want to always recompile and install the kernel
[19:58] <ohsix> what did you patch it for? it's possible to get ubuntu to include it, or the upstream kernel
[19:58] <LetoThe2nd> geri: let me introduce you.
[19:58] <geri> i modified drivers/usb/class/cdc-acm.c
[19:59] <LetoThe2nd> ohsix: we've seen the ticket for some days in #ubuntu-de. its a kind of queue modification patch to cdc-acm.c to quirk some ti msp430 dev kit.
[19:59] <ohsix> that driver is a module already isn't it? you can write your own dkms thing but i don't know what the rules are for overriding existing modules
[20:00] <geri> i successfully tested the patch but i dont want to always rebuild and install the kernel....
[20:00] <LetoThe2nd> ohsix: he patches the kernel source directly and wants to only rebuild the particular module, as the bottom line,
[20:00] <geri> if there is some way to manually build the usb driver and manually load it with modprobe...would be helpful
[20:01] <LetoThe2nd> geri: its not "the usb driver"
[20:01] <LetoThe2nd> geri: for clarity, please refer to it as cdc-acm
[20:01] <geri> ok
[20:02] <ohsix> it's a usb class driver, kernel.org and ubuntu would probably be receptive into adding it
[20:03] <ohsix> what's the nature of the failure when it's not present? what kind of quirk is it?
[20:03] <LetoThe2nd> ohsix: they certainly won't, because it breaks blocking of incoming characters.
[20:04] <ohsix> so you need a quitk for the _class_ not the actual device
[20:05] <LetoThe2nd> geri: BTW, here a link to dkms as he mentioned: https://help.ubuntu.com/community/DKMS
[20:05] <geri> whats the goal now?
[20:07] <LetoThe2nd> geri: i'd suggest reading that page.
[20:07] <geri> thats the only way to succeed?
[20:07] <LetoThe2nd> geri: from an architectural way, it looks very good to me.
[20:08] <geri> which kernel source should i use?
[20:08] <geri> kernel.org?
[20:09] <LetoThe2nd> geri: read the link, find out and be surprised :)
[20:09] <LetoThe2nd> ohsix: found the link (post #6): http://groups.google.com/group/ti-launchpad/browse_frm/thread/e414bf066fbd1d59/1dacabc8a4f00ab6?pli=1
[20:09] <LetoThe2nd> ohsix: i don'T you want that in production code ;)
[20:09] <ohsix> there's a git tree for all the ubuntu kernel versions, you'd get cdc-acm from there and build your own version
[20:10] <LetoThe2nd> s/don'T/don't think/
[20:12] <ohsix> yea that doesn't look like a "fix"
[20:12] <geri> no?
[20:12] <ohsix> it's a semantics change since the driver or device is fruity
[20:13] <ohsix> yea, by fix i mean it probably wouldn't be accepted as-is
[20:13] <LetoThe2nd> ohsix: thats why i said "quirk something". i personally believe its snakeoil anyway, or that it merely curing the symptoms of something completely different.
[20:14] <LetoThe2nd> .. like a b0rken tty hardware peropheral or something.
[20:14] <geri> LetoThe2nd, where is this awesome-20091211-v1.1.tgz. ?
[20:14] <ohsix> yea, someone hitting the datasheets can probably find a way to reset the device or something in a way that it works correctly
[20:15] <LetoThe2nd> geri: think a bit about it, and maybe you'll come to the conclusion that there could also be printed $superawesomecodeexamplethingthatdoesntevenexist.08154711.tar.gz
[20:30] <SpamapS> I just upgraded my MBA 4,1 (11") to precise and the touchpad doesn't seem to work at all...
[20:32] <SpamapS> also the keyboard seems to be flaky.. sometimes its stops accepting keystrokes for a while (took me 3 tries to type ths message)
[20:34] <slangasek> bjf: http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html seems to have broken again?
[20:35] <bjf> sigh
[20:35] <bjf> slangasek: looking into it
[20:35] <slangasek> cheers ):
[20:35] <slangasek> :)
[20:42] <bryce> hey, anyone remember if there's a tool for changing the framebuffer resolution at run time (assuming X is not running)?
[20:50] <SpamapS> yeah, something definitely broken with the precise kernel.. had to roll back to my oneiric kernel to make the system usable again. :-/
[20:50]  * SpamapS will try upstream kernel shortly