[01:31] <DanaG> hmm, any chance of getting the find_task_by_vpid symbol re-exported? http://lists.mandriva.com/kernel-discuss/2009-07/msg00018.php
[08:12]  * apw waves
[08:13]  * smb waves back
[08:22]  * cooloney waves back to apw
[08:22] <apw> yo
[08:46] <apw> smb, up for reviewing a branch for me?  just pushed up what i think will be the netbook branch for karmic, to its official location.  could do with an eye over it
[08:47] <smb> Yeah sure, let me finish a little thing off here, then I have a look. 
[08:48] <apw> np, thanks
[09:04] <cking_> apw, who maintains those kernel team suspend/resume test scripts?
[09:05] <apw> suspend_test ?  thats mine
[09:05] <cking> I've found that sometimes we may need to ensure the RTC is sync'd with UTC for it to work.
[09:06] <apw> well we cirtainly can't change its utc status
[09:06] <apw> as it may be localtime for windows, do you mean that we should note its not and use a different time?
[09:08] <cking> not sure of the correct workaround - it's just that I've seen one user where hwclock --utc --systohc fixed the problem - so I expect some how we need to check for this kind of localtime/UTC difference
[09:08] <apw> we got into a lot of trouble for doing that in the past :)  windows like it to be localtime
[09:09] <cking> hrm
[09:10] <cking> that certainly concurs with my experience when I was installing Windoze 7 to benchmark the I/O - the clock was 1 hour out
[09:11] <apw> well i can see how it wouldn't work if the clock isn't in UTC
[09:11] <apw> hrm, actually better check the kerel
[09:12] <apw> we use an absolute utc seconds in the kernel interface, need to figure out if it _is_ utc in the interface
[09:12] <smb> apw, Looking at your netbook branch, most things look neat (want that insert-changes for jaunty too. :)) but the "start new release" seems to create abi files with -6.25 numbers. Are you not needing -400.0?
[09:13] <apw> hrm, error
[09:13] <apw> will check thanks
[09:14] <smb> oh sorry, my fault
[09:14] <apw> smb, oh no its actually removing them
[09:14] <smb> yeah just saw so
[09:14] <apw> but that is wrong, that should be in the previous commits
[09:14] <apw> ie. the abi should have been zapped two commites before
[09:14] <apw> will sort that out thanks
[09:15] <smb> right, makes sense
[09:18] <apw> cking, if you have a machine you can set the clock to localtime om
[09:18] <apw> on, then you could test something for me
[09:18] <cking> ok I do have one here
[09:18] <cking> ready for testing
[09:18] <apw> date '+%s'; cat /sys/class/rtc/rtc0/since_epoch
[09:18] <apw> what does that say
[09:20] <apw> hrm i think mine may be in localtime too
[09:20] <apw> apw@dm$ date '+%s'; cat /sys/class/rtc/rtc0/since_epoch
[09:20] <apw> 1250842773
[09:20] <apw> 1250846375
[09:20] <cking> Hrm. It's a hardy box which don't have that proc file
[09:20] <apw> pup
[09:20] <apw> usb stick?
[09:20] <cking> yeah - gimme 10
[09:23] <apw> cking, the test i am sure you can guess, but basically can you test setting a sleep at date +%s output + 30s and suspend, and then try at the proc file output + 30s and suspend... see whcih is correct
[09:24] <cking> will do once I've got the machine booted
[09:24] <apw> yep. and you suck eggs by first removing the shell ...
[09:27] <cking> to see if it's fired one can use: cat /proc/driver/rtc | grep alarm_IRQ | awk '{ print $3 }'
[09:29] <apw> interesting
[09:30] <cking> yes = IRQ is triggered
[09:31] <cking> after it's should have fired, it will be no (IRQ has fired)
[09:32] <apw> so its in the inverse of whether it fired?
[09:32] <apw> smb, ok i've hopefully fixed the branch and repushed
[09:33] <cking> yep - check out http://kernel.ubuntu.com/git?p=cking/scripts/.git;a=commit;h=3577ea60c525f4e3d91b2f7afa009fa68e4a6ff8
[09:36] <cking> date '+%s'; cat /sys/class/rtc/rtc0/since_epoch - gives me:
[09:36] <cking> 1250843781
[09:36] <cking> 1250843773
[09:39] <smb> apw, Ok, if the intention is to do no abi checks at all it seems to be good
[09:39] <apw> for the first version i don't have any abi information
[09:39] <apw> once thats built i will pull the abi info from the builds and we can start checking it
[09:40] <apw> i suppose i should have taken the abi from the tip really shouldn't i
[09:40] <apw> bum
[09:40] <smb> Oh right, the logic with -0.0 would not work here
[09:40] <apw> i guess 400.0 could contain the tip of the karmic trees info
[09:41] <apw> dunno if i care enough to fight it
[09:41] <smb> you could have, it should be good. In the fist version it looked half like you tried to have that
[09:41] <smb> It should be fine both ways
[09:43] <smb> apw, I would rather leave it as is (in favour of getting a condensed jaunty patchset for abstracted ;-))
[09:43] <smb> But I am biased here
[09:44] <apw> yeah i think i'll leave it for now as i have tested the result
[09:44] <apw> yours is next
[09:47] <cking> using since_epoch looks like the trick to fix it
[09:53] <apw> cking, thanks ... will put something together there
[09:55] <cking> apw, it may be worth doing a sanity check that the alarm works before doing those suspend tests, c.f. my script earlier
[09:56] <cking> just bear in mind that since_epoch won't work for Hardy kernels
[09:56] <apw> yeah, will do
[10:21] <apw> smb, ok just pushed the squashed version to my repo, cast an eye over it and if you are happy you can pull it into master
[10:23] <cking> time for a coffee
[10:23] <smb> apw, great. thanks. will do
[10:23] <apw> cking, thats 11s'ies
[10:23] <cking> I've been working since 7
[10:26] <apw> then you are allowed
[10:26] <cking> much appreciated
[10:28] <apw> though now i want one ... grrr
[10:31] <cking> autosuggestion 1: apw 0
[10:35]  * apw slaps cking 
[10:36] <smb> apw, Would the jaunty branch still need the insertchanges to follow abstracted debian? (just as I saw that in the karmic netbook branch)
[10:36] <apw> oh yeah, that would be needed over there too
[10:36] <apw> converted to main branch
[10:36] <apw> shall i do that
[10:37]  * apw _will_ do that
[10:37] <smb> apw, Would be neat if you just dropped into your repo. Then I pick and test the whole
[10:37]  * smb give apw one of those famous hugs
[10:37] <apw> daniel back i can't breath :)
[10:38] <smb> hehe
[10:39] <amitk> apw: cking: so are you two going on vacation together?
[10:39] <apw> heheh ... can you imagine ... i'd end up eating his children, i am untrained
[10:39] <amitk> heh
[10:40] <apw> smb, applied to both karmic and my jaunty branch
[10:41] <smb> apw, cool pulling and testing
[10:43] <apw> smb, it had better be right by now!  i am tired of a-d ...
[10:43]  * apw callls now 11:00
[10:43] <smb> apw, I'd be very careful to report otherwise.
[10:44]  * smb looks and sees 11:44
[10:44] <apw> see i am late for my coffee, *slurp*
[10:44] <smb> You can never be late, just in the wrong timezone
[10:46] <apw> we i want to be late, so i can have it now and now wait for 11
[11:00] <cking> yawn
[12:33] <apw> smb, the hardy changelog has no 24.58 in it, is that to be expected?
[12:34] <smb> apw, yes. it was a proposed that will be overridden (actually never went there, but I kept the numbers)
[12:37] <apw> smb, ok thanks
[12:41] <smb> apw, Oh, there is something I have to tell you about the abstracted builds
[12:41] <apw> good or bad?
[12:41] <smb> \o/ seems all files are present
[12:41] <apw> hurrah thank goodness for that
[12:41] <apw> and only the right ones i assume :)
[12:43] <smb> Well it does not exactly tell about the contents. Probably I check on the abi and config files, just to be safe...
[12:43] <apw> i am assuming the contents are the same
[12:43] <apw> presumably we could make a source tarball before and after those commits
[12:43] <apw> and then compare them
[12:43] <apw> as in -x them and diff -u the two trees
[12:44] <apw> they should be the same
[12:44] <smb> But it has the same number of packages as before and the packages contain the same files. The only change could be in generated files that do not lead to files being present
[12:44] <apw> and i likely mena the binary actually
[12:44] <apw> bah i say upload it to a ppa, and see what it makes :)
[12:44] <smb> :) yeah. that is sort of the next step
[12:45] <smb> and boot the produced kernel
[13:15] <juliux> hi
[13:16] <juliux> it is possible to disable the powersaving on the vga port?
[13:17] <juliux> i have here a server which crashes sometimes and then i can't press a key to get the vga/monitor back online;)
[13:22] <apw> juliux, i am pretty sure that would be possible from userspace
[13:22] <apw> is it a raw VT or showing X
[13:23] <juliux> raw VT
[13:23] <juliux> no x is running
[13:28] <smb> juliux, Does "setterm -powersave off" work?
[13:29] <juliux> smb: i will try it out
[13:29] <smb> juliux, maybe needs a "-blank 0", I am not sure
[13:29] <juliux> cannot (un)set powersave mode
[13:31] <smb> juliux, seems only to work typed on the console
[13:32] <juliux> i am logged in via ssh atm
[13:32] <juliux> i will try it directly at the system
[13:32] <smb> juliux, Just tried it with a system here ssh does not work. On the console it does do something
[13:35] <juliux> smb: ok
[13:36] <juliux> but seeterm is only working if i am logged in, right?
[13:38] <smb> From the description is sound like echoing control sequences to the current terminal. Probably its ok as long as the term has the right caps (and ssh virt term does not)
[13:38] <smb> But I have not tried otherwise
[15:08] <bjf> amitk, ?
[15:09] <amitk> bjf: so you've applied all the patches (1st set) as-is (including support for every FSL SoC), right?
[15:09] <bjf> amitk, that is correct, I believe there were only two patches that that didn't get applied "as-is"
[15:10] <amitk> but I thought that when you did the second set (earlier), you'd tweezed out only the imx51-specific bits
[15:10] <bjf> amitk, that is correct
[15:10] <bjf> amitk, that i what I attempted to do
[15:10] <ogra> amitk, btw, does the current build boot for you on the B1 ?
[15:10] <ogra> doesnt work for me 
[15:11] <amitk> ogra: not tried it. I'm working on fec ATM
[15:11] <ogra> ah, ignore me then, FEC is more important
[15:12] <amitk> bjf: so in your git tree on kernel.u.c, you now have the 1st set (~60 patches) applied as-is and the 2nd second imx51-specific?
[15:12] <bjf> amitk, no
[15:13] <bjf> amitk, I have a fsl branch in my repo, that contains all ER9-SP patches (300+) applied "as-is"
[15:13] <amitk> aah, ok
[15:14] <bjf> amitk, it _is_ confusing
[15:14] <amitk> I'll find it impossible to replicate that on karmic. When we are having trouble just porting imx51-specific bits, I can't imagine the effort the forward port the entire SoC stack
[15:15] <amitk> *the effort to
[15:16] <bjf> amitk, I understand
[15:17] <bjf> amitk, the only way for all the soc support on karmic is for FSL to do it themselves 
[15:17] <bjf> amitk, at some point there are going to move to a more recent kernel
[15:18] <amitk> bjf: so what do you suggest? Should I stick to just porting the single squashed patch that I had in jaunty to karmic and add the new ER9-SP patches on top?
[15:19] <bjf> amitk, I think that is all that you can do, as long as we are only supporting reference design boards then we should be ok
[15:20] <bjf> amitk, if we have to support an OEM customer, then we are going to have problems (bigger problems than just supporting the reference design)
[15:20] <bjf> amitk, just supporting a single reference design is going to be tough enough
[15:21]  * amitk nods
[15:30] <smb> *** Jaunty master tree is now abstracted ***
[15:34] <bjf> smb, must be time for some fsl pathing then :-)
[15:35] <smb> bjf, I wonder how you guessed. :)
[15:36] <rtg> bjf, patching --> patching ?
[15:36] <rtg> pathing*
[15:38] <bjf> rtg, ack  (pathing -> patching)
[15:38] <bjf> rtg, pathing is a new technique we use on fsl patches when we apply them
[15:38]  * rtg thinks bjf is smoking something
[15:40] <ogra> so are you pathing your patches too ? 
[16:27] <mdz> I just had my first real, live kernel crash which was saved as a dump automagically in Karmic
[16:32] <ogra> heh, first time i see someone happy about a kernel crash :)
[16:33]  * ogra is happy he finally has a kernel since today at all ... dont want that to crash though
[16:52] <bjf> rtg, mvl-dove tree is missing the "ubuntu" directory tree
[16:53] <rtg> bjf, thats because its a straightforward rebase from their repo. I've no Ubuntu goodness in it (yet)
[16:53] <bjf> rtg, I'm going to need that though aren't I?
[16:53] <rtg> bjf, the most obvious thing missing is aufs for the LiveCD
[16:54] <bjf> rtg, apparmour
[16:54] <rtg> bjf, yep, you're gonna need it. its the next thing I'm working on, but there are some build issues.
[16:54] <rtg> bjf, you can still run without AA
[16:54] <bjf> rtg, I'll ignore it for now
[17:52] <bjf> rtg, my new dove-z0 flavour generates: Could not open /home/bradf/karmic/mvl-karmic/debian/linux-image-2.6.31-200-dove-z0/lib/modules/2.6.31-200-dove-z0/modules.alias at debian.mvl-dove/tests/check-aliases line 10.
[17:53] <rtg> bjf, thats the VERSION bs. I don't think you got rebased correctly.
[17:53] <bjf> rtg, haven't rebased since your change, didn't know the two were related, thanks
[17:54] <rtg> bjf, git reset --hard HEAD~10; git fetch origin; git rebase origin/mvl-dove
[18:00] <rtg> bjf, did you notice there are some updates in the dove git repo in the -rc5 branch?
[18:11] <bjf> rtg, those weree the updates I recently posted and you've already pulled
[18:11] <rtg> bjf, correct, but I also changed the config files as art of those changes
[18:11] <rtg> part*
[18:12] <bjf> rtg, ah, you are talking about *our* dove repo not *marvell's* dove repo, my mistake
[18:12] <bjf> rtg, I'll look at the latest changes you've made
[18:13] <bjf> rtg, to our dove branch
[18:13] <rtg> bjf, yeah, sorry.
[18:13] <bjf> rtg, np, my confusion
[18:42] <NCommander> rtg, can you upload a .2 of the dove metapackage so we can get around the failed to upload issues :-/
[18:43] <rtg> NCommander, if I _knew_ what the problem was....
[18:43] <NCommander> rtg, <bigjools> NCommander: the package is building a binary version that already existing
[18:44] <NCommander> rtg, usually happens when a binary package moves between packages, or similar cases
[18:44] <ameno> apw: are the vanilla builds now totally broken? :)
[18:44] <apw> ameno, maybe?
[18:45] <rtg> NCommander, its a new package. what could be colliding?
[18:45] <ameno> apw: no dir for the last two days
[18:46] <apw> ameno, ahh they were disabled today hwile i fixed a bug, must have missed the mornign build
[18:46] <apw> yeah its off building something now
[18:46] <NCommander> rtg, I'm looking more indepth
[18:46] <ameno> oki, thanks
[18:46] <apw> good job you mentioned it today though :)
[18:46] <NCommander> rtg, I think LP crapped itself; your package is both superseeded AND published: https://edge.launchpad.net/ubuntu/+source/linux-meta-mvl-dove/2.6.31.200.1
[18:47] <smb> apw, Hm, I hope it knows that the configs in jaunty are now under debian.master...
[18:47] <apw> claims to superceed itself
[18:48] <NCommander> apw, thats a bug :-/
[18:48] <apw> smb, it does, well only cause its got fixed for karmic
[18:48] <apw> a bit of luck i fixed it earlier this week 
[18:48] <smb> apw, Phew, yeah :)
[18:48] <apw> else you'd be doing it
[18:49]  * smb hides
[18:52] <NCommander> rtg, bah, fixed (in theory)
[18:52] <NCommander> rtg, the source package was promoted to main while the metapackage was building
[18:53] <NCommander> rtg, which caused LP to loose its mind since it tried to find a now non-existant package in universe, and promptly bombed during upload
[18:53] <rtg> NCommander, its the kind of problem I like, i.e., one I don't have to fix.
[18:54] <NCommander> rtg, thanks for your hard work in this. Remind me when we next meet in meatspace to buy you $BEVERAGE
[18:54] <rtg> NCommander, $BEVERAGES
[18:54] <ogra> $BEVERAGES++
[18:54]  * NCommander sets a price limit of $10 dollars or less per BEVERAGE
[18:55] <laga> apw: yay, thanks again for that AUFS fix
[18:55] <apw> laga, np, what woke you up there?
[18:55] <laga> apw: it just got uploaded/published i think
[18:56] <laga> and i got the bug mail
[18:56] <apw> ahh yes it is being
[19:08] <NCommander> rtg, failed again, needs version bump. sorry :-/
[19:08] <rtg> NCommander, uno momento
[19:12] <rtg> NCommander, done
[19:12] <NCommander> rtg, thank you
[19:33] <pef> hello
[20:06] <rtg> bjf-afk, new dove bits, enabled the ubuntu build, rebased against master to bing things up to -rc6
[20:51] <ameno> apw: jfyi, the headers seem to be fixed (recompiled the virtualbox module with them), but the source package is still broken