[07:36] <smb> morning
[07:37] <ppisati> moin
[07:59] <cooloney> apw: hey, andy
[08:02] <cooloney> i'm trying to use aufs in quantal, but found it's not built as module. like modprobe aufs will fail.
[08:02] <cooloney> even i tried my own built kernel package from latest master-next
[08:03] <cooloney> smb, morning, ^^^
[08:03] <RAOF> Aufs has never been in mainline, right? And we've stopped patching it in - it's now overlayfs only.
[08:03] <smb> cooloney, morning, yes afaik aufs is not build to see who screams
[08:04] <smb> Its unionfs i think 
[08:04] <smb> or overlay
[08:04] <smb> bah
[08:05] <smb> RAOF, Oh btw, when I just see you around... May I express my unhappiness with X for Quantal (bug 1029582)? :)
[08:05] <ubot2> Launchpad bug 1029582 in xorg "Unusable graphics with ATI RS690M" [High,New] https://launchpad.net/bugs/1029582
[08:06] <cooloney> RAOF and smb, exactly, we are using overlayfs from upstream now. but i'm working on a bug which is on overlayfs but not on aufs
[08:06] <cooloney> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/959352
[08:06] <ubot2> Ubuntu bug 959352 in lxc "Ephemeral containers have "/rootfs" prefix in /proc/self/maps entries" [High,Confirmed]
[08:06] <cooloney> it looks like there is a bug in overlayfs, but i wanna make sure it is not on aufs.
[08:07] <cooloney> so trying to enable aufs in kernel now
[08:07] <smb> cooloney, I am not very confident that the aufs module has been kept in a buildable state... even if it is still in there
[08:10] <cooloney> smb: hmmm. looks like i can only use old kernel 
[08:21] <smb> cooloney, Well I'd probably try to follow the "rootfs" hint. There seems to be not too many places in fs/ than have it. So fs/namespace.c and fs/ramfs/inode.c seem to be the only places. namespace.c looks like a good place to start...
[08:25] <cooloney> smb: thanks, i'm looking at that. probably fs/overlayfs/inode.c, but i fail to find the lxc configuration in Quantal, looks like lxc changed a log
[08:25] <RAOF> smb: Sadface.
[08:26] <smb> cooloney, Right, maybe it would help to talk to stgraber / hallyn about the differences in mounting between ephemeral and non (like whether one uses its own namepsace or not). Since one seem affected but not the other
[08:28] <smb> RAOF, Me too, I use that laptop normally for iso tests. but right now it is not very helpful
[08:29] <smb> And I could not even tell why... To me the logs are not very bad looking... at least not that critically bad...
[08:29] <smb> Not that I know what to look for...
[08:29] <RAOF> smb: It looks like some acceleration snafu.
[08:30] <RAOF> Yeah, all the logs look fine.
[08:31] <smb> RAOF, Yeah, well I will help as much as possible. Just need someone to add someone to add a few pointers about debugging this.
[08:31] <smb> oops
[08:32] <smb> mental loop detected... abort for more coffee
[08:32] <RAOF> :)
[08:32] <RAOF> Does it actually work, just fail to display correctly?
[08:32] <RAOF> ie: if you type blindly to log in, does the screen change?
[08:33] <smb> No, with the current state I seem to get some more broken graphics and then fall back tolightdm
[08:33] <smb> Well probably you can say that works in some way a bit
[08:34] <RAOF> Ah, so it actually crashes somewhere?
[08:34] <smb> But sooner or later (if I insist on using graphics) I also had total lockups
[08:35] <smb> Let me try again and see whther there is more in and *old.log
[08:36]  * smb just was glad optional text mode worked to get sshd installed...
[08:36] <cooloney> smb: i found the templates of lxc moved from /usr/lib/lxc to /usr/share/lxc/
[08:36] <smb> Ok, right now there is a black screen but I heard drums...
[08:36] <cooloney> smb: do you know why lxc should use overlayfs? is it for chroot rootfs?
[08:38] <smb> cooloney, Well since the dictionary say ephemeral means temporary I assume their purpose is to be playgrounds to revert back to what things where when you end the container...
[08:39] <cooloney> smb: yeah, ephemeral just start the lxc container and execute some commands in it then shutdown the container
[08:40] <smb> cooloney, But also I guess your fs will be unchanged whatever you do. Thus overlay or aufs...
[08:40] <cooloney> smb: and in /usr/bin/lxc-start-ephemeral, it use overlayfs as default unionfs
[08:40]  * smb would prefer temporary for simplicity
[08:40] <RAOF> smb: Could you try adding an Xorg.conf with Option "NoAccel" "true"?
[08:41] <smb> RAOF, Yes, if I get it up in a state it is usable. Seems it exploded right after the drum sound. No ssh no nothing... arg
[08:42] <RAOF> Ok, that suggests that the driver is just sending garbage to the drm device. That's not wonderful.
[08:42] <smb> RAOF, :) No I think it makes the device a bit unhappy
[09:07] <cking> smb, http://en.wikipedia.org/wiki/Zero_insertion_force
[09:09] <cking> so many standards
[09:10]  * apw yawns
[09:12] <smb> apw, slacker. :)
[09:13] <smb> apw, cking and I already completed all of our morning whining...
[09:13] <apw> i can't speak yet, know i am moaning inside
[09:13] <cking> yep, as ever, lots of stuff to whine about
[09:14] <smb> apw, We pretend we can hear you complain then
[09:20] <cking> the old geezers whining channel
[09:50] <smb> RAOF, Ok NoAccel allows to use things... /me goes updating the bug
[10:21] <cking> apw, smb, I've sent some slub/slab results to you for your eyeballing
[10:21] <apw> cking, ack
[10:22] <smb> ok
[11:05] <apw> cking, remind me, did we decide that EFI would need FAT
[11:05] <apw> i think we did 
[11:05] <cking> yes
[11:05] <apw> thought so
[11:07] <cooloney> cking: hey, cking, i've setup ceph server on my host and i'm going to setup a ceph client on a PandaES board
[11:11] <cking> cooloney, cool, lemme know if you need any assistance
[11:14] <smb> cking, After finishing my netbook surgery I am looking at the slab/slub report. One note about the graphs: if possible I would use the same y-scale for left and right. But that is probably just my personal preferance. :) And about locality, that is the unsigned byte distance? Just wanting to understand better. Maybe I missed the real explanation,,,
[11:14] <cking> smb, it's the unsigned difference between the addresses
[11:14] <cooloney> cking: so i've mount vm'ceph fs on my host machine. if i write some file to this /mnt/cephs, can we read it out in vm?
[11:15] <smb> cking, Ah ok, thanks
[11:15]  * cooloney is going to upgrade his old macbook pro to SSD and 8G RAM, and hope to do some testing in the future
[11:15] <cking> cooloney, you can only make sense of the data on the client - on the host it's in CEPH's format
[11:16] <cooloney> cking: it means i need setup a ceph client somewhere and mount the directory in that ceph client, right?
[11:17] <cking> cooloney, yes, you need to mount it with a ceph client
[11:18] <cking> cooloney, but ceph client is built into our kernel, so it should work easily on a client
[11:19]  * henrix -> lunch
[11:37] <cooloney> cking: ok, thanks, will bring up on my pandaES
[11:38] <cooloney> apw and cking, enjoy your Olympic Game Openning
[11:38] <apw> cooloney, just waiting for the rain to start
[11:38] <cking> cooloney, so you probably need to do three tests of tests:  client on x86, server on arm, and client on arm and server on arm and finally client on arm, server on arm
[11:47] <apw> cking, on arm .. fun
[11:47] <cking> cking, gotta be thorough :-)
[11:47] <cking> bah, /me now talking to himself
[11:53] <njin> hallo guys, can be this a linux bug ?  [drm] nouveau 0000:00:05.0: PGRAPH - ERROR nsource: FORMAT_EXCEPTION nstatus:
[11:53] <njin> [drm] nouveau 0000:00:05.0: PGRAPH - ch 3 (0x000db000) subc 6 class 0x009f mthd 0x0308 data 0x00180042
[11:55] <njin> [drm] nouveau 0000:00:05.0: PGRAPH - ERROR nsource: FORMAT_EXCEPTION nstatus: INVALID_STATE BAD_ARGUMENT PROTECTION_FAULT
[11:56] <apw> njin, that is the kernel complaining about the format of a GPU command it was passed likely from mesa
[11:57] <njin> apw, thanks, so this is not an error ? my syslog is full of this
[11:58] <njin> andf the graphic is garbled
[11:59] <apw> njin, its clearly an error, its not necessarily a kernel bug, it is as likely a mesa bug as mesa writes the GPU instructions
[11:59] <njin> apw thanks, so i open a bug report against mesa
[11:59] <apw> as the X folk have more knowledge of the GPU side i tend to file their side and let them decide if its kernle :)
[12:00] <apw> i would file it against the xorg drvier for your card, and they will reassign it sensibly if its wrong
[12:00] <njin> ok, i do then, thanks again
[12:00] <apw> np
[12:00] <infinity> libdrm seems like a sane spot to assign blame.
[12:01] <infinity> It could just as easily be an overheating video card, though.
[12:01] <apw> infinity, by filing it against the ddx for nouveau the right logs get got automatically, then X bots it into the right place generally
[12:01] <apw> infinity, indeed, could be the kernel not doing powermanagement or 1000 other things :/
[12:01] <infinity> njin: File wherever apw tells you to file, but I do recommend checking your fans. :P
[12:02] <apw> if only these vendors realised they need to _support_ the crap they sell
[12:02] <apw> especially as win8 looks like its going to be an utter disaster and is driving the games people away
[12:02] <infinity> apw: Nah, I didn't mean to imply it was software overheating it, but that 99% of "my screen is garbled" video card issures are airflow and/or loose heatsinks.
[12:02] <infinity> issues...
[12:02] <njin> infinity, ok I try to put an additional one, but the case is already opened
[12:02] <apw> infinity, oh i cannot argue with your analysis at all.  i still file against ddx just to get right X info
[12:03] <infinity> njin: I didn't mean "add more fans", I just meant "check that the one on the card is still spinning, check that the heatsink is hot to touch", etc.
[12:03] <apw> those heatsinks where the paste is dried out are the worst
[12:03] <cking> or fluff stuck in the fan outlets
[12:04] <infinity> (The heatsink should be so hot that it burns your fingers under load, if it's not, it's come loose or the thermal paste has gone bad)
[12:04] <njin> infinity, fan is spinning, and cleaned
[12:04] <infinity> njin: Alright.  Then happy bug filing.  ;)
[12:04] <njin> then I file a bug against xserver-xorg-video-nouveau
[12:05] <infinity> Frying video cards is actually (seriously) why I gave up on high-end gaming. :/
[12:05] <apw> wtf i am suddenly getting 40k a second instead of 500 from the DC ... wobble
[12:05] <apw> oh i wonder if we are suffering olympic internet syndrome already
[12:05] <infinity> apw: A flood of Romney-mocking tweets, no doubt.
[12:47] <rtg> henrix, I just pushed a closing entry to Precise master-next. do some test builds on that.
[12:48] <henrix> rtg: thanks. i'll check that
[12:51] <henrix> rtg: i'm building it now, it will take a while.
[12:52] <henrix> rtg: so, there was nothing wrong with your patch. the prob was that i modified the abi directory (basically, i renamed it). since there were changes done to the arm abi, these changes were lost
[12:53] <henrix> rtg: the origin of this issue was the rename, due to the unreleased version on git
[12:55] <rtg> henrix, but you are agreed that what is in master-next right now is correct ?
[12:55] <henrix> rtg: yep, it is and it should fix the prob. the ignore file should fix it
[12:55] <rtg> henrix, and you understand _why_ the ignore files are OK in this instance ?
[12:56] <henrix> rtg: yep. i guess i overcomplicated this :(
[12:56] <henrix> rtg: solution is far less complex
[12:56] <henrix> rtg: thanks
[12:57] <rtg> henrix, normally an ABI ignore on a minor update is dangerous, but since that kernel was never published...
[12:57] <henrix> rtg: ack
[13:32] <rtg> apw, drat. I've just done a 'reset --hard' on a branch that I hadn't pushed. Is there a way to figure out what the origin SHA1 was on that branch before I lose all the commits leading up to it ?
[13:32] <rtg> original*
[13:33] <rtg> aha! ORIG_HEAD perhaps ?
[13:36] <apw> rtg, if you did a git reset --hard then git log -g will show the previous locations of the HEAD
[13:37] <apw> over time back for about 2 weeks
[13:37] <apw> this drops out a list of somethig called the reflog, git log -g shows HEADs location, git log -g <branch> does just the branch tip
[13:39] <apw> rtg, did you find it ?
[13:40] <rtg> apw, yep, ORIG_HEAD had what I needed
[13:40] <apw> rtg, ok the reflogs have a longer view should you really mess up :)
[13:40] <rtg> I assume that a 'git gc' cleans up all history wrt previous HEADs ?
[13:41] <apw> rtg, the reflogs hold references to old trees based on time, so they should be there i think it is either 14 or 21 days, then the reflog entries go and release them
[13:41] <rtg> ok
[13:42] <apw> that said my reflogs for my ubuntu-quantal head goes all the way back to 18-nov-2011 wow
[13:45] <apw> rtg ok its 90 days for entries which point at things which still exist from a the tip you are on, and 30 days for others
[13:50]  * rtg relocates...
[14:18] <josepht> I'm trying to bisect commits between mainline v3.4.6-quantal and v3.5.0-quantal.  Should I be using the Ubuntu... tags or the v3... tags?
[14:21] <rtg> josepht, likely the v3 tags since the commits are more or less linear. the Ubuntu tags could be across a rebase.
[14:21] <josepht> rtg: thanks
[14:27] <apw> bjf, https://wiki.ubuntu.com/Kernel/KernelPPA i have created a new page which describes the KernelPPA, how to make one, how to upload, how to copy to -proposed, why debug is bad etc.  but it needs the how to copy bit filling in ... perhaps you could do the honours
[14:28] <bjf> apw, will do, thanks
[14:28] <apw> bjf i have also rejigged the bottom of stable release cadance so it tells you sh
[14:29] <apw> 'who to give the package to, or where to upload it' sort of thing instead of all those details on the Kernel PPA which are now in the other page
[14:29] <bjf> nice
[14:34] <dileks> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=commitdiff;h=dc9bd4098f0cf9703f30fe2fa3c433fafddf435c
[14:34] <dileks> http://kernel.ubuntu.com/~cking/iosched/
[14:35]  * cking suspects an impending discussion about this
[14:35]  * dileks looks at Overall.. section
[14:36]  * cking recommends dileks to read the entire report rather than just drawn a conclusion from the final section
[14:37]  * dileks cross-read it
[14:37] <cking> ah
[14:37]  * dileks ...and looked at the result sheet (ods)
[14:40] <dileks> depends whats your focus... more modern hardware and filesystem, you might be on the right track
[14:40] <dileks> more on*
[14:41] <cking> dileks, like all things, some win, some lose
[14:41] <dileks> IIRC the linux-fsdevel guys have a testsuite. you tested with it?
[14:41]  * dileks checks mailbox
[14:42] <cking> dileks, no, but if I tested with all the fs test suites out there I wouldn't get any results out before 14.02 :-/
[14:45] <cking> apw, so, I think the conclusion from the slub/slab data is we should stick with slub 
[14:47] <dileks> hehe. visited donald knuths blog yesterday for 1st time... referenced from a x32abi link... and while reading more articles taocp page was listing about book part V an ETA 2020
[14:47] <cking> hopefully knuth with be alive then, we can only hope
[14:48] <cking> bjf, we got any precise SRU kernel updates coming down the pipe? I think I'm waiting for the U300 S3 bug to get verified
[14:48] <henrix> cking: on its way
[14:49] <dileks> age 74
[14:49] <bjf> cking: yup, this is prep week. 100+ are inbound
[14:49] <cking> ooh, that's a whole load of patches  in the pipe 
[14:50]  * ogasawara back in 20
[14:50] <dileks> cking: nice editing with test-results
[14:51] <cking> dileks, much appreciated :-)
[14:53] <apw> cking, slub> thanks for investigating
[14:53] <cking> apw, if you think I should explore more avenues, I'm happy to do so, but I think we have enough data to make a decision
[14:54] <apw> cking, no i trust your judgement, we had what was an arbitrary choice made "this is new and cool" some two years ago, now we have numbers to say it was cool
[14:54] <apw> cking, that is good enough for me
[14:54] <cking> and other distros are using the same config too, so that's helpful
[14:55] <rtg> apw, IIRC there was _some_ LKML data to justify the switch.
[14:56] <apw> rtg, yeah but i knew it was by someone who tended to say things were great for everyone when only had tested them on vast machines with zillions of cpus
[14:56] <rtg> well, true
[14:56] <apw> so its good to have some proper analysis tell us we made a sane choice :)  and more importantly it remains a sane choice
[14:57] <rtg> apw, I was just pointing out that our decision to change  wasn't _completely_ frivolous.
[14:58] <apw> rtg, heh sorry, i know it wasn't quite as arbitrary as i make it sound ...
[14:58] <cking> it wasn't a flip of a coin choice that's for sure
[14:58] <dileks> so, slub + deadline is todays choice?
[14:59] <apw> at least while cfq continues to have these hideous corner behaviours i recon
[14:59] <cking> dileks, slub has been our choice for quite a while
[14:59] <apw> cfq must be one of the most incongiously named drivers there is
[14:59] <rtg> dileks, yes, deadline appears to behave a little better under extreme conditions.
[15:03]  * dileks remembers discussions with fellows from grml and debian and both switched to slab... so this might have changed again
[15:04] <dileks> any link to "...LKML data to justify the switch"
[15:11] <dileks> cking: testsuite is called xfstests which you can use also for numerous other fs#s
[15:12] <cking> dileks, yes, I'm familiar with those, I used them to exercise eCryptfs a lot
[15:17]  * cking --> more coffee. when will this flippin' jet lag wear off?!
[15:19]  * dileks recommends a centrifugal machine for astronauts to kill jetlag
[15:24]  * cking recommends sleep 
[15:26] <apw> ppisati, remdind me did you tell us why we have CONFIG_SATA_AHCI_PLATFORM off on ti-omap4 ?
[15:26] <apw> ppisati, i sort of think you said it turned something ugly on
[15:27] <ppisati> apw: it breaks compilation if OMAP5 is not defined (and we don't define it)
[15:27] <apw> ppisati, ahh thanks thats the one
[16:01] <infinity> apw: It's somewhat moot anyway, unless you can figure out how to staple an AHCI controller onto your Panda.
[16:02] <apw> infinity, indeed but we are looser with things in the config review, clearly here it should be off though
[16:03] <infinity> At least until we start flirting with the idea of building unified omap kernels, yeah.
[16:03] <infinity> (Which would be nice, if omap4 and omap5 are finally being upstreamed enough to get away with it...)
[16:03] <apw> ogasawara, i think we decided we'd keep CONFIG_WAN_ROUTER on only where it might possibly have been used before, which for me is i386/amd64 and powerpc ... right ?
[16:04] <apw> infinity, oh indeed, which is one reason we try and turn on as much common stuff as we can so any future merge is easier
[16:04] <ogasawara> apw: yep
[16:04] <ppisati> infinity: omap3 + omap4 is doable for R IMO
[16:04] <apw> ogasawara, and can you remember anything about GPIO_SYSFS
[16:04] <ppisati> infinity: while omap5 is clearly impossible
[16:05] <infinity> ppisati: Well, Linaro is already doing it now, but obviously not with mainline.
[16:05] <infinity> Not sure how massive the TILT changeset still is, I haven't looked in a long time, but I trust that you're on top of it, so I try not to care. :P
[16:05] <ogasawara> apw: i remember we asked jj and he didn't have a good recommendation for it
[16:06] <ogasawara> apw:  so it seems we tabled it for later
[16:06] <apw> ogasawara, oh hrmmm ... 
[16:07] <ppisati> infinity: http://people.canonical.com/~ppisati/ti-omap4-tilt-34-on-35/tilt-3.4/
[16:07] <infinity> ppisati: So, still "huge", then.  Basically.
[16:08] <infinity> Although, they're all rather tiny changes.  Maybe they just need to upstream harder.
[16:08] <apw> heh so we can merge omap3 and 4 if we pull it out of master
[16:09] <ppisati> yes
[16:09] <infinity> apw: Which we could do if master could either (a) build linux-libc-dev without a kernel, or (b) we added a different flavour (like, say, vexpress)
[16:09] <infinity> Oh, wait, we have another flavour now.  Hi there, highbank.
[16:09] <apw> infinity, i beleive we can do that anyway
[16:10] <infinity> (Except on armel, but we'll cross that bridge when we get to it)
[16:14]  * smb -> EOW
[16:21]  * herton -> lunch
[16:23]  * ppisati -> gym
[16:46] <apw> ogasawara, ok other than GPIO_SYSFS there are only three red lines in the 'common drivers' sections, they are all bryan's fault, once my test builds are done i'll push
[16:47] <ogasawara> apw: heh, awesome thanks
[16:51] <apw> ogasawara, if we ignore ti-omap4 things are very close to as good as they are going to gt for Q i recon
[16:51] <apw> get
[16:51] <ogasawara> apw: I can be happy with that
[16:53] <apw> ogasawara, i recon we let bryan do a bit more and then relegate the rest to R's torture
[16:53] <ogasawara> apw: do we want to have a WI for cooloney/ppisati to clean up ti-omap4 or feed us annotations?
[16:53] <ogasawara> apw: whatever they don't hammer out we can grind through at UDS-R and our next sprint
[16:54] <apw> ogasawara, i think they have one for some of it anyhow... i have some open WIs for it so i may just hammer them out and use them as testing bitches
[16:54] <ogasawara> apw: ack
[16:54] <apw> s/it/general beta2 review/
[16:56]  * apw waits impatiently for gomeisa
[16:58] <apw> ogasawara, heh a 15m load average of 178 ...
[16:59] <cking> it's almost on fire
[16:59]  * cking --> food
[17:31] <apw> ogasawara, ok it seems to build for me, highbank is an abi bumper so you'd need to slip one of those underneath when you are tieing the bow
[17:31] <apw> (as and when)
[17:31] <ogasawara> apw: ack
[17:31] <apw> ogasawara, i've close that WI so we are making progress ...
[17:33] <apw> ogasawara, i think that gets us back to normalised relative to the slow even after the crap we added last week
[17:33] <apw> s/slow/slope/
[17:57]  * rtg -> lunch
[18:19]  * cking --> EOW
[19:35]  * rtg -> EOW
[19:55] <joshhunt_> i saw usn-1515-1 for a new kernel pass by the other day on the mailing list, but then it seems to have disappeared. does anyone know the status of this?
[20:03] <sbeattie> joshhunt_: hunh. that's odd. Will look.
[20:05] <sbeattie> joshhunt_: I've caused the USN to be regenerated at http://www.ubuntu.com/usn/usn-1515-1/ I'm not sure why it wasn't there before
[20:10] <joshhunt_> sbeattie: thanks
[20:11] <joshhunt_> sbeattie: yeah it was weird. i saw it in the mailing list, but then it wasn't on the rss feed/web site.