[03:04] <alexlist> Hi folks...
[03:07] <alexlist> Any chance we can get CONFIG_NETWORK_PHY_TIMESTAMPING enabled by default, e.g. in the -lowlatency kernel?
[05:03] <infinity> alexlist: It's be a performance hit.
[05:03] <infinity> alexlist: What's the argument for?
[05:46] <alexlist> infinity: ok understood. That means I'll have to roll my own... I need precise timestamps in order to measure latency :)
[07:22] <genkgo> jsalisbury: Just read your comments on the Microsoft backup problem
[07:22] <genkgo> jsalisbury: do you know whether MIcrosoft has actually done some commits on this issue in the new kernel (4.1?)
[07:24] <genkgo> jsalisbury: more specifically, are those commits newer than their commits in bug 1445195?
[07:24] <genkgo> jsalisbury: nonetheless, i am happy there is action on this topic :)
[09:29] <tseliot> apw: hey
[09:30] <apw> hiya
[09:31] <tseliot> apw: have you read this: http://www.phoronix.com/scan.php?page=article&item=linux-42-of&num=2
[09:32] <tseliot> apw: they seem to blame it on CONFIG_OF. The kernel panics here too
[09:32]  * apw gets out his salt-shaker
[09:32] <tseliot> :)
[09:33] <tseliot> apw: would it be possible to disable CONFIG_OF in the mainline builds?
[09:33] <tseliot> that would help our testing
[09:33] <apw> tseliot, if they are on there likely they are coming from the unstable tree (ours)
[09:34] <tseliot> apw: right, so, who do I have to bug to get that change into the unstable tree?
[09:35] <apw> i can look at it
[09:35] <tseliot> apw: thanks
[09:35] <apw> i am sure he will be claiming to be the reason its fixed when it changes
[09:36] <tseliot> :)
[09:36] <tseliot> anybody can say whatever they want, it still doesn't change actual facts ;)
[09:39] <apw> "For some reason, the Ubuntu vanilla kernel packages have started enabling CONFIG_OF", that'd be because it started being enablable for x86 when it wasn't before, and the mainline config generator is not precient
[09:42] <tseliot> hmm... :)
[09:48] <tseliot> apw: so, it was enabled by accident. Although I find the way he put it much more amusing
[09:50] <apw> heh no not by accident, the option was expanded to new architectures (all) because "It is also desirable to expand the compile coverage of the DT code.", and the mainline builder defaults it on because it is on on the existing architectures
[10:21] <tseliot> apw: oh, ok. So it's simply a bug in the code then?
[10:30] <apw> tseliot, i'd not call that a bug
[10:31] <apw> tseliot, i'd call that sensible behaviour, selecting the same abilities in as many arches as possible
[10:31] <tseliot> a feature? :D
[10:31] <apw> that it doesn't work on there is more of a problem
[10:31] <tseliot> apw: no, I mean, the kernel panic
[10:31] <apw> oh the panic, thats just broken indeed
[10:31] <tseliot> that, to me, seems like a bug
[10:32] <tseliot> I agree that the config system is sensible
[10:32] <apw> yeah and it should be fixed and that it was found because they made it enable everywhere is helpful
[10:32] <apw> i guess, do you have the panic ?
[10:32] <tseliot> yes
[10:32] <apw> could you file a bug against linux with it for me, so i can reference it in the "off" for x86
[10:33] <tseliot> apw: shall I use ubuntu-bug after the panic or would a simple bug report be enough?
[10:35] <apw> tseliot, as its not an official version it won't let you, a simple report with the panic stack will do me, 
[10:35] <tseliot> oh, right
[10:47] <tseliot> apw: BTW has asm/i387.h been dropped in 4.2?
[10:49] <tseliot> I can see it in 4.0.0-4 but it's not there in 4.2rc2
[10:51] <TJ-> tseliot: see commit df6b35f
[10:52] <tseliot> TJ-: thanks a lot :)
[13:42] <Odd_Bloke> bjf: Are you all moved off the PS4 argyle?  If so, I'll let IS know they can bring the environment down.
[13:43] <bjf> Odd_Bloke, we think we are i think you should shut the old one down so we know for sure
[13:44] <bjf> apw, ^
[13:51] <apw> bjf, ack
[13:52] <apw> bjf, as far as i know everything has been updated and i have just re-re-started the only persistent bit i have
[13:55] <apw> bjf, and ... if it explodes we want to know indeed
[14:07] <Odd_Bloke> Cool.
[14:07] <bjf> Odd_Bloke, let us know when it's down/gone
[15:34] <jsalisbury> ##
[15:34] <jsalisbury> ## Kernel team meeting today @ 17:00 UTC
[15:34] <jsalisbury> ##
[15:45] <jsalisbury> genkgo, There are no new commits that were specifically targeted this bug.  This new test kernel has all HV related commits currently in mainline.  It will confirm where or not an entirely new patch is needed to fix the bug.
[15:50] <tseliot> apw: I've just filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1474447 . Unfortunately I don't see any data about the panic in kern.log. I will upload a screenshot
[15:51] <apw> tseliot, thanks
[15:53] <genkgo> jsalisbury: thanks, i will test it, but my guess is that this really needs a fix/commit by ms
[15:53] <jsalisbury> genkgo, ack, that's what this will confirm.
[16:13] <apw> tseliot, ok i've turned OF for x86 and marked it up against your bug
[16:13] <apw> tseliot, so the new mainlines should have that off
[16:20] <tseliot> apw: thanks a lot!
[16:54] <jsalisbury> ##
[16:54] <jsalisbury> ## Kernel team meeting in 5 minutes
[16:54] <jsalisbury> ##
[19:32] <swair>  Why do the run queues have locks? Isn't the scheduler the only 'entity' which touches the run queue?