=== Ming is now known as Guest98249 === smb` is now known as smb [07:36] morning [07:37] moin [07:59] apw: hey, andy [08:02] i'm trying to use aufs in quantal, but found it's not built as module. like modprobe aufs will fail. [08:02] even i tried my own built kernel package from latest master-next [08:03] smb, morning, ^^^ [08:03] Aufs has never been in mainline, right? And we've stopped patching it in - it's now overlayfs only. [08:03] cooloney, morning, yes afaik aufs is not build to see who screams [08:04] Its unionfs i think [08:04] or overlay [08:04] bah [08:05] RAOF, Oh btw, when I just see you around... May I express my unhappiness with X for Quantal (bug 1029582)? :) [08:05] Launchpad bug 1029582 in xorg "Unusable graphics with ATI RS690M" [High,New] https://launchpad.net/bugs/1029582 [08:06] 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] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/959352 [08:06] Ubuntu bug 959352 in lxc "Ephemeral containers have "/rootfs" prefix in /proc/self/maps entries" [High,Confirmed] [08:06] it looks like there is a bug in overlayfs, but i wanna make sure it is not on aufs. [08:07] so trying to enable aufs in kernel now [08:07] 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] smb: hmmm. looks like i can only use old kernel [08:21] 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] 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] smb: Sadface. [08:26] 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] RAOF, Me too, I use that laptop normally for iso tests. but right now it is not very helpful [08:29] And I could not even tell why... To me the logs are not very bad looking... at least not that critically bad... [08:29] Not that I know what to look for... [08:29] smb: It looks like some acceleration snafu. [08:30] Yeah, all the logs look fine. [08:31] 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] oops [08:32] mental loop detected... abort for more coffee [08:32] :) [08:32] Does it actually work, just fail to display correctly? [08:32] ie: if you type blindly to log in, does the screen change? [08:33] No, with the current state I seem to get some more broken graphics and then fall back tolightdm [08:33] Well probably you can say that works in some way a bit [08:34] Ah, so it actually crashes somewhere? [08:34] But sooner or later (if I insist on using graphics) I also had total lockups [08:35] 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] smb: i found the templates of lxc moved from /usr/lib/lxc to /usr/share/lxc/ [08:36] Ok, right now there is a black screen but I heard drums... [08:36] smb: do you know why lxc should use overlayfs? is it for chroot rootfs? [08:38] 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] smb: yeah, ephemeral just start the lxc container and execute some commands in it then shutdown the container [08:40] cooloney, But also I guess your fs will be unchanged whatever you do. Thus overlay or aufs... [08:40] smb: and in /usr/bin/lxc-start-ephemeral, it use overlayfs as default unionfs [08:40] * smb would prefer temporary for simplicity [08:40] smb: Could you try adding an Xorg.conf with Option "NoAccel" "true"? [08:41] 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] Ok, that suggests that the driver is just sending garbage to the drm device. That's not wonderful. [08:42] RAOF, :) No I think it makes the device a bit unhappy [09:07] smb, http://en.wikipedia.org/wiki/Zero_insertion_force [09:09] so many standards [09:10] * apw yawns [09:12] apw, slacker. :) [09:13] apw, cking and I already completed all of our morning whining... [09:13] i can't speak yet, know i am moaning inside [09:13] yep, as ever, lots of stuff to whine about [09:14] apw, We pretend we can hear you complain then [09:20] the old geezers whining channel [09:50] RAOF, Ok NoAccel allows to use things... /me goes updating the bug === yofel_ is now known as yofel [10:21] apw, smb, I've sent some slub/slab results to you for your eyeballing [10:21] cking, ack [10:22] ok [11:05] cking, remind me, did we decide that EFI would need FAT [11:05] i think we did [11:05] yes [11:05] thought so [11:07] 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] cooloney, cool, lemme know if you need any assistance [11:14] 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] smb, it's the unsigned difference between the addresses [11:14] 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] 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] cooloney, you can only make sense of the data on the client - on the host it's in CEPH's format [11:16] cking: it means i need setup a ceph client somewhere and mount the directory in that ceph client, right? [11:17] cooloney, yes, you need to mount it with a ceph client [11:18] cooloney, but ceph client is built into our kernel, so it should work easily on a client [11:19] * henrix -> lunch [11:37] cking: ok, thanks, will bring up on my pandaES [11:38] apw and cking, enjoy your Olympic Game Openning [11:38] cooloney, just waiting for the rain to start [11:38] 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] cking, on arm .. fun [11:47] cking, gotta be thorough :-) [11:47] bah, /me now talking to himself [11:53] hallo guys, can be this a linux bug ? [drm] nouveau 0000:00:05.0: PGRAPH - ERROR nsource: FORMAT_EXCEPTION nstatus: [11:53] [drm] nouveau 0000:00:05.0: PGRAPH - ch 3 (0x000db000) subc 6 class 0x009f mthd 0x0308 data 0x00180042 [11:55] [drm] nouveau 0000:00:05.0: PGRAPH - ERROR nsource: FORMAT_EXCEPTION nstatus: INVALID_STATE BAD_ARGUMENT PROTECTION_FAULT [11:56] njin, that is the kernel complaining about the format of a GPU command it was passed likely from mesa [11:57] apw, thanks, so this is not an error ? my syslog is full of this [11:58] andf the graphic is garbled [11:59] 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] apw thanks, so i open a bug report against mesa [11:59] 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] i would file it against the xorg drvier for your card, and they will reassign it sensibly if its wrong [12:00] ok, i do then, thanks again [12:00] np [12:00] libdrm seems like a sane spot to assign blame. [12:01] It could just as easily be an overheating video card, though. [12:01] 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] infinity, indeed, could be the kernel not doing powermanagement or 1000 other things :/ [12:01] njin: File wherever apw tells you to file, but I do recommend checking your fans. :P [12:02] if only these vendors realised they need to _support_ the crap they sell [12:02] especially as win8 looks like its going to be an utter disaster and is driving the games people away [12:02] 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] issues... [12:02] infinity, ok I try to put an additional one, but the case is already opened [12:02] infinity, oh i cannot argue with your analysis at all. i still file against ddx just to get right X info [12:03] 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] those heatsinks where the paste is dried out are the worst [12:03] or fluff stuck in the fan outlets [12:04] (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] infinity, fan is spinning, and cleaned [12:04] njin: Alright. Then happy bug filing. ;) [12:04] then I file a bug against xserver-xorg-video-nouveau [12:05] Frying video cards is actually (seriously) why I gave up on high-end gaming. :/ [12:05] wtf i am suddenly getting 40k a second instead of 500 from the DC ... wobble [12:05] oh i wonder if we are suffering olympic internet syndrome already [12:05] apw: A flood of Romney-mocking tweets, no doubt. [12:47] henrix, I just pushed a closing entry to Precise master-next. do some test builds on that. [12:48] rtg: thanks. i'll check that [12:51] rtg: i'm building it now, it will take a while. [12:52] 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] rtg: the origin of this issue was the rename, due to the unreleased version on git [12:55] henrix, but you are agreed that what is in master-next right now is correct ? [12:55] rtg: yep, it is and it should fix the prob. the ignore file should fix it [12:55] henrix, and you understand _why_ the ignore files are OK in this instance ? [12:56] rtg: yep. i guess i overcomplicated this :( [12:56] rtg: solution is far less complex [12:56] rtg: thanks [12:57] henrix, normally an ABI ignore on a minor update is dangerous, but since that kernel was never published... [12:57] rtg: ack [13:32] 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] original* [13:33] aha! ORIG_HEAD perhaps ? [13:36] rtg, if you did a git reset --hard then git log -g will show the previous locations of the HEAD [13:37] over time back for about 2 weeks [13:37] this drops out a list of somethig called the reflog, git log -g shows HEADs location, git log -g does just the branch tip [13:39] rtg, did you find it ? [13:40] apw, yep, ORIG_HEAD had what I needed [13:40] rtg, ok the reflogs have a longer view should you really mess up :) [13:40] I assume that a 'git gc' cleans up all history wrt previous HEADs ? [13:41] 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] ok [13:42] that said my reflogs for my ubuntu-quantal head goes all the way back to 18-nov-2011 wow [13:45] 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] 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] josepht, likely the v3 tags since the commits are more or less linear. the Ubuntu tags could be across a rebase. [14:21] rtg: thanks [14:27] 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] apw, will do, thanks [14:28] bjf i have also rejigged the bottom of stable release cadance so it tells you sh [14:29] '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] nice [14:34] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=commitdiff;h=dc9bd4098f0cf9703f30fe2fa3c433fafddf435c [14:34] 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] ah [14:37] * dileks ...and looked at the result sheet (ods) [14:40] depends whats your focus... more modern hardware and filesystem, you might be on the right track [14:40] more on* [14:41] dileks, like all things, some win, some lose [14:41] IIRC the linux-fsdevel guys have a testsuite. you tested with it? [14:41] * dileks checks mailbox [14:42] 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] apw, so, I think the conclusion from the slub/slab data is we should stick with slub [14:47] 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] hopefully knuth with be alive then, we can only hope [14:48] 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] cking: on its way [14:49] age 74 [14:49] cking: yup, this is prep week. 100+ are inbound [14:49] ooh, that's a whole load of patches in the pipe [14:50] * ogasawara back in 20 [14:50] cking: nice editing with test-results [14:51] dileks, much appreciated :-) [14:53] cking, slub> thanks for investigating [14:53] 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] 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] cking, that is good enough for me [14:54] and other distros are using the same config too, so that's helpful [14:55] apw, IIRC there was _some_ LKML data to justify the switch. [14:56] 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] well, true [14:56] 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] apw, I was just pointing out that our decision to change wasn't _completely_ frivolous. [14:58] rtg, heh sorry, i know it wasn't quite as arbitrary as i make it sound ... [14:58] it wasn't a flip of a coin choice that's for sure [14:58] so, slub + deadline is todays choice? [14:59] at least while cfq continues to have these hideous corner behaviours i recon [14:59] dileks, slub has been our choice for quite a while [14:59] cfq must be one of the most incongiously named drivers there is [14:59] 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] any link to "...LKML data to justify the switch" [15:11] cking: testsuite is called xfstests which you can use also for numerous other fs#s [15:12] 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] ppisati, remdind me did you tell us why we have CONFIG_SATA_AHCI_PLATFORM off on ti-omap4 ? [15:26] ppisati, i sort of think you said it turned something ugly on [15:27] apw: it breaks compilation if OMAP5 is not defined (and we don't define it) [15:27] ppisati, ahh thanks thats the one === ev_ is now known as ev [16:01] apw: It's somewhat moot anyway, unless you can figure out how to staple an AHCI controller onto your Panda. [16:02] infinity, indeed but we are looser with things in the config review, clearly here it should be off though [16:03] At least until we start flirting with the idea of building unified omap kernels, yeah. [16:03] (Which would be nice, if omap4 and omap5 are finally being upstreamed enough to get away with it...) [16:03] 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] 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] apw: yep [16:04] infinity: omap3 + omap4 is doable for R IMO [16:04] ogasawara, and can you remember anything about GPIO_SYSFS [16:04] infinity: while omap5 is clearly impossible [16:05] ppisati: Well, Linaro is already doing it now, but obviously not with mainline. [16:05] 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] apw: i remember we asked jj and he didn't have a good recommendation for it [16:06] apw: so it seems we tabled it for later [16:06] ogasawara, oh hrmmm ... [16:07] infinity: http://people.canonical.com/~ppisati/ti-omap4-tilt-34-on-35/tilt-3.4/ [16:07] ppisati: So, still "huge", then. Basically. [16:08] Although, they're all rather tiny changes. Maybe they just need to upstream harder. [16:08] heh so we can merge omap3 and 4 if we pull it out of master [16:09] yes [16:09] 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] Oh, wait, we have another flavour now. Hi there, highbank. [16:09] infinity, i beleive we can do that anyway [16:10] (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] 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] apw: heh, awesome thanks [16:51] 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] get [16:51] apw: I can be happy with that [16:53] ogasawara, i recon we let bryan do a bit more and then relegate the rest to R's torture [16:53] apw: do we want to have a WI for cooloney/ppisati to clean up ti-omap4 or feed us annotations? [16:53] apw: whatever they don't hammer out we can grind through at UDS-R and our next sprint [16:54] 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] apw: ack [16:54] s/it/general beta2 review/ [16:56] * apw waits impatiently for gomeisa [16:58] ogasawara, heh a 15m load average of 178 ... [16:59] it's almost on fire [16:59] * cking --> food [17:31] 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] (as and when) [17:31] apw: ack [17:31] ogasawara, i've close that WI so we are making progress ... [17:33] ogasawara, i think that gets us back to normalised relative to the slow even after the crap we added last week [17:33] s/slow/slope/ [17:57] * rtg -> lunch [18:19] * cking --> EOW === JanC_ is now known as JanC [19:35] * rtg -> EOW [19:55] 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] joshhunt_: hunh. that's odd. Will look. [20:05] 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] sbeattie: thanks [20:11] sbeattie: yeah it was weird. i saw it in the mailing list, but then it wasn't on the rss feed/web site.