=== Ming is now known as Guest98249 | ||
=== smb` is now known as smb | ||
smb | morning | 07:36 |
---|---|---|
ppisati | moin | 07:37 |
cooloney | apw: hey, andy | 07:59 |
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:02 |
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:03 |
smb | Its unionfs i think | 08:04 |
smb | or overlay | 08:04 |
smb | bah | 08:04 |
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:05 |
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:06 |
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:07 |
cooloney | smb: hmmm. looks like i can only use old kernel | 08:10 |
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:21 |
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:25 |
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:26 |
smb | RAOF, Me too, I use that laptop normally for iso tests. but right now it is not very helpful | 08:28 |
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:29 |
RAOF | Yeah, all the logs look fine. | 08:30 |
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:31 |
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:32 |
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:33 |
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:34 |
smb | Let me try again and see whther there is more in and *old.log | 08:35 |
* 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:36 |
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:38 |
cooloney | smb: yeah, ephemeral just start the lxc container and execute some commands in it then shutdown the container | 08:39 |
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:40 |
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:41 |
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 | 08:42 |
cking | smb, http://en.wikipedia.org/wiki/Zero_insertion_force | 09:07 |
cking | so many standards | 09:09 |
* apw yawns | 09:10 | |
smb | apw, slacker. :) | 09:12 |
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:13 |
smb | apw, We pretend we can hear you complain then | 09:14 |
cking | the old geezers whining channel | 09:20 |
smb | RAOF, Ok NoAccel allows to use things... /me goes updating the bug | 09:50 |
=== yofel_ is now known as yofel | ||
cking | apw, smb, I've sent some slub/slab results to you for your eyeballing | 10:21 |
apw | cking, ack | 10:21 |
smb | ok | 10:22 |
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:05 |
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:07 |
cking | cooloney, cool, lemme know if you need any assistance | 11:11 |
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:14 |
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:15 |
cooloney | cking: it means i need setup a ceph client somewhere and mount the directory in that ceph client, right? | 11:16 |
cking | cooloney, yes, you need to mount it with a ceph client | 11:17 |
cking | cooloney, but ceph client is built into our kernel, so it should work easily on a client | 11:18 |
* henrix -> lunch | 11:19 | |
cooloney | cking: ok, thanks, will bring up on my pandaES | 11:37 |
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:38 |
apw | cking, on arm .. fun | 11:47 |
cking | cking, gotta be thorough :-) | 11:47 |
cking | bah, /me now talking to himself | 11:47 |
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:53 |
njin | [drm] nouveau 0000:00:05.0: PGRAPH - ERROR nsource: FORMAT_EXCEPTION nstatus: INVALID_STATE BAD_ARGUMENT PROTECTION_FAULT | 11:55 |
apw | njin, that is the kernel complaining about the format of a GPU command it was passed likely from mesa | 11:56 |
njin | apw, thanks, so this is not an error ? my syslog is full of this | 11:57 |
njin | andf the graphic is garbled | 11:58 |
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 :) | 11:59 |
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:00 |
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:01 |
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:02 |
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:03 |
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:04 |
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:05 |
rtg | henrix, I just pushed a closing entry to Precise master-next. do some test builds on that. | 12:47 |
henrix | rtg: thanks. i'll check that | 12:48 |
henrix | rtg: i'm building it now, it will take a while. | 12:51 |
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:52 |
henrix | rtg: the origin of this issue was the rename, due to the unreleased version on git | 12:53 |
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:55 |
henrix | rtg: yep. i guess i overcomplicated this :( | 12:56 |
henrix | rtg: solution is far less complex | 12:56 |
henrix | rtg: thanks | 12:56 |
rtg | henrix, normally an ABI ignore on a minor update is dangerous, but since that kernel was never published... | 12:57 |
henrix | rtg: ack | 12:57 |
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:32 |
rtg | aha! ORIG_HEAD perhaps ? | 13:33 |
apw | rtg, if you did a git reset --hard then git log -g will show the previous locations of the HEAD | 13:36 |
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:37 |
apw | rtg, did you find it ? | 13:39 |
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:40 |
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:41 |
apw | that said my reflogs for my ubuntu-quantal head goes all the way back to 18-nov-2011 wow | 13:42 |
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:45 |
* rtg relocates... | 13:50 | |
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:18 |
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:21 |
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:27 |
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:28 |
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:29 |
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:34 |
* cking suspects an impending discussion about this | 14:35 | |
* dileks looks at Overall.. section | 14:35 | |
* cking recommends dileks to read the entire report rather than just drawn a conclusion from the final section | 14:36 | |
* dileks cross-read it | 14:37 | |
cking | ah | 14:37 |
* dileks ...and looked at the result sheet (ods) | 14:37 | |
dileks | depends whats your focus... more modern hardware and filesystem, you might be on the right track | 14:40 |
dileks | more on* | 14:40 |
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:41 | |
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:42 |
cking | apw, so, I think the conclusion from the slub/slab data is we should stick with slub | 14:45 |
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:47 |
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:48 |
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:49 |
* ogasawara back in 20 | 14:50 | |
dileks | cking: nice editing with test-results | 14:50 |
cking | dileks, much appreciated :-) | 14:51 |
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:53 |
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:54 |
rtg | apw, IIRC there was _some_ LKML data to justify the switch. | 14:55 |
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:56 |
rtg | apw, I was just pointing out that our decision to change wasn't _completely_ frivolous. | 14:57 |
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:58 |
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. | 14:59 |
* dileks remembers discussions with fellows from grml and debian and both switched to slab... so this might have changed again | 15:03 | |
dileks | any link to "...LKML data to justify the switch" | 15:04 |
dileks | cking: testsuite is called xfstests which you can use also for numerous other fs#s | 15:11 |
cking | dileks, yes, I'm familiar with those, I used them to exercise eCryptfs a lot | 15:12 |
* cking --> more coffee. when will this flippin' jet lag wear off?! | 15:17 | |
* dileks recommends a centrifugal machine for astronauts to kill jetlag | 15:19 | |
* cking recommends sleep | 15:24 | |
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:26 |
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 | 15:27 |
=== ev_ is now known as ev | ||
infinity | apw: It's somewhat moot anyway, unless you can figure out how to staple an AHCI controller onto your Panda. | 16:01 |
apw | infinity, indeed but we are looser with things in the config review, clearly here it should be off though | 16:02 |
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:03 |
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:04 |
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:05 |
ogasawara | apw: so it seems we tabled it for later | 16:06 |
apw | ogasawara, oh hrmmm ... | 16:06 |
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:07 |
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:08 |
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:09 |
infinity | (Except on armel, but we'll cross that bridge when we get to it) | 16:10 |
* smb -> EOW | 16:14 | |
* herton -> lunch | 16:21 | |
* ppisati -> gym | 16:23 | |
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:46 |
ogasawara | apw: heh, awesome thanks | 16:47 |
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:51 |
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:53 |
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:54 |
* apw waits impatiently for gomeisa | 16:56 | |
apw | ogasawara, heh a 15m load average of 178 ... | 16:58 |
cking | it's almost on fire | 16:59 |
* cking --> food | 16:59 | |
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:31 |
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:33 |
* rtg -> lunch | 17:57 | |
* cking --> EOW | 18:19 | |
=== JanC_ is now known as JanC | ||
* rtg -> EOW | 19:35 | |
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? | 19:55 |
sbeattie | joshhunt_: hunh. that's odd. Will look. | 20:03 |
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:05 |
joshhunt_ | sbeattie: thanks | 20:10 |
joshhunt_ | sbeattie: yeah it was weird. i saw it in the mailing list, but then it wasn't on the rss feed/web site. | 20:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!