Hi Linus !
Here are a few more powerpc changes for 3.10. I've merged your
tree in at some point (which I generally avoid) in order to get
the compat network fixes as soon as possible.
Mostly regressions, and stuff I judged could/should still go in at
this stage.
I'm still waiting on some more fixes to the signal handling
vs. transactional memory (this is really ugly btw) which are
hopefully coming next week.
Cheers,
Ben.
The following changes since commit 1612e111e4e565422242727efb59499cce8738e4:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-06-06 18:09:05 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
for you to fetch changes up to 227331303afdca06e44dcda41d27b72015153827:
powerpc: Print instruction when logging unhandled exceptions (2013-06-09 17:29:16 +1000)
----------------------------------------------------------------
Anton Blanchard (1):
powerpc: Print instruction when logging unhandled exceptions
Benjamin Herrenschmidt (1):
Merge remote-tracking branch 'origin/master' into merge
Gavin Shan (1):
powerpc/eeh: Don't check RTAS token to get PE addr
Kevin Hao (1):
powerpc/pci: Check the bus address instead of resource address in pcibios_fixup_resources
Michael Ellerman (3):
powerpc: Rename PMU interrupts from CNT to PMI
powerpc/perf: Fix deadlock caused by calling printk() in PMU exception
powerpc: Partial revert of "Context switch more PMU related SPRs"
Michael Neuling (4):
powerpc/power8: Fix oprofile and perf
powerpc/pseries: Simplify denormalization handler
powerpc/power8: Update denormalization handler
powerpc/hw_breakpoints: Add DABRX cpu feature to fix 32-bit regression
arch/powerpc/include/asm/cputable.h | 17 +++--
arch/powerpc/kernel/cputable.c | 8 +--
arch/powerpc/kernel/entry_64.S | 28 --------
arch/powerpc/kernel/exceptions-64s.S | 90 ++++++++------------------
arch/powerpc/kernel/irq.c | 2 +-
arch/powerpc/kernel/pci-common.c | 4 +-
arch/powerpc/kernel/process.c | 3 +-
arch/powerpc/kernel/traps.c | 11 +++-
arch/powerpc/perf/core-book3s.c | 2 +-
arch/powerpc/platforms/pseries/eeh_pseries.c | 12 ++--
10 files changed, 60 insertions(+), 117 deletions(-)
On Sun, Jun 9, 2013 at 12:56 AM, Benjamin Herrenschmidt
<[email protected]> wrote:
>
> Here are a few more powerpc changes for 3.10. I've merged your
> tree in at some point (which I generally avoid) in order to get
> the compat network fixes as soon as possible.
>
> Mostly regressions, and stuff I judged could/should still go in at
> this stage.
Not pulled, because your hamster smells of eldeberries.
This is not just bugfixes. In fact, as far as I can tell, this
*introduces* bugs, with that "get_user()" in the exception path that
can apparently happen with irqs disabled and will thus potentially
result in new warnings that just make things unreadable.
I'm f*cking tired of people having problems understanding "we're past
rc5". If it's not something you would call stable material, you
shouldn't send it to me.
Linus
[ Is Jeremy the patchwork maintainer? If not, can people forward this
to the real maintainer? ]
On Sun, Jun 9, 2013 at 2:33 PM, Linus Torvalds
<[email protected]> wrote:
>
> This is not just bugfixes. In fact, as far as I can tell, this
> *introduces* bugs, with that "get_user()" in the exception path that
> can apparently happen with irqs disabled and will thus potentially
> result in new warnings that just make things unreadable.
Looking at that particular commit, I also notice that the commit
itself is buggered in other ways too.
It says:
Date: Thu Jun 6 19:42:54 2013 +0000
which surprised me due to the odd timezone, and it turns out it is
pure and utter crap.
Google finds the patch in patchwork, and "Show headers" there shows
the expected timezone
Date: Fri, 7 Jun 2013 15:42:54 +1000
and it turns out that apparently 'patchwork' is just making up random
times, because when you download the email as an mbox, it will turn
this into that corrupt and incorrect
Date: Thu, 06 Jun 2013 19:42:54 -0000
thing which is apparently how you got the wrong timestamp to begin with.
That odd time doesn't even make any sense that I can see, because
those two times have absolutely nothing in common afaik. Unless
timezones work differently down under. It looks like some west-coast
local time, but then it says "-0000" which is code for "I have no
f*cking clue what I'm doing".
Just to make things extra exciting, patchwork actually shows yet
*another* date string when you just look at the patch in the web
interface:
Date June 7, 2013, 5:42 a.m.
and that actually seems to be the *correct* UTC version of that
original email date. I have no idea what that "Thu, 06 Jun 2013
19:42:54 -0000" date is, and where it came from. But it is utter
shite.
Can somebody please make sure that patchwork doesn't destroy
timezone/date information? I'm assuming this has been going on
forever, and I just noticed because I looked at that particular commit
for other reasons, and went "Is Anton in Europe now?".
Linus
On Sun, 2013-06-09 at 14:33 -0700, Linus Torvalds wrote:
> On Sun, Jun 9, 2013 at 12:56 AM, Benjamin Herrenschmidt
> <[email protected]> wrote:
> >
> > Here are a few more powerpc changes for 3.10. I've merged your
> > tree in at some point (which I generally avoid) in order to get
> > the compat network fixes as soon as possible.
> >
> > Mostly regressions, and stuff I judged could/should still go in at
> > this stage.
>
> Not pulled, because your hamster smells of eldeberries.
>
> This is not just bugfixes. In fact, as far as I can tell, this
> *introduces* bugs, with that "get_user()" in the exception path that
> can apparently happen with irqs disabled and will thus potentially
> result in new warnings that just make things unreadable.
Ah right, brown paper bag for Anton and I :(
I shouldn't have put that one in, it was a last minute bad decision
after spending time tracking another stupid sigill in userspace (this
time FSL CPUs not implementing some optional instructions that Fedora
compiler seems configured to generate nowadays).
> I'm f*cking tired of people having problems understanding "we're past
> rc5". If it's not something you would call stable material, you
> shouldn't send it to me.
I've taken out that commit and the rename of the PMU interrupt (which
while trivial probably wasn't important enough). Everything else is
regressions/stable material.
That does mean I rebased, but normally nobody bases on that merge branch
so it should be fine.
I'll send a new pull request.
Cheers,
Ben.
> Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hi Linus,
> Is Jeremy the patchwork maintainer?
Yep, that's me.
> and it turns out that apparently 'patchwork' is just making up random
> times, because when you download the email as an mbox, it will turn
> this into that corrupt and incorrect
>
> Date: Thu, 06 Jun 2013 19:42:54 -0000
>
> thing which is apparently how you got the wrong timestamp to begin with.
We keep all patch dates in UTC, but were generating the Date header
incorrectly. Now fixed:
$ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date
Date: Fri, 07 Jun 2013 05:42:54 -0000
Commit is at:
http://git.ozlabs.org/?p=patchwork;a=commitdiff;h=e7353352
Cheers,
Jeremy
On Sun, Jun 9, 2013 at 7:44 PM, Jeremy Kerr <[email protected]> wrote:
>
> We keep all patch dates in UTC, but were generating the Date header
> incorrectly. Now fixed:
No, not fixed.
Keeping patch dates in UTC *corrupts* the date.
I'll ask people to stop using patchworks if it cannot keep track of
emailed dates. The date very much is a local time WITH A TIMEZONE.
And it does matter.
> $ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date
> Date: Fri, 07 Jun 2013 05:42:54 -0000
No. The date from the email was
Date: Fri, 7 Jun 2013 15:42:54 +1000
and we want *that* date. Not some random date that patchwork makes up
that has no relevance.
I know you have that date, because it shows up when asking for the
headers in patchwork. Just use the right one, don't make up incorrect
ones.
Linus
On Sun, Jun 9, 2013 at 8:06 PM, Linus Torvalds
<[email protected]> wrote:
>
> And it does matter.
.. the rationale for this is that the work pattern of people is
actually interesting information. You can do things like this:
git log --pretty=%aD --author=Torvalds
to see what my work pattern is, and I think that's *interesting*.
Gathering statistics like whether people are generally doing 9-5
Mon-Fri is actually interesting data. You can do things like this:
git log --since=6.months --pretty=%aD --author=Torvalds |
cut -c1-3 |
sort |
uniq -c |
sort -n
and see (for example) that I do slow down on weekends.
Same goes for things like what time of day ends up being most
productive. You can do the statistics for me, and see that I tend to
do the bulk of my pulls in the mornings (peak between 9-11) and that
I'm not a night-owl (*big* drop-off after 8PM - that's what kids do to
you). You can see a few really early-morning cases, but I suspect they
were when I was jetlagged.
So the date data is actually meaningful data. It's not just random noise.
And to do these kinds of things, you absolutely have to have
local-time with proper timezone information. Anything that screws that
up is *broken*. git gets this right, unlike a lot of other broken
SCM's. Git gets it right for a reason.
Yeah, yeah, when people forward other peoples patches they often drop
the date field, and the date of the patch ends up being the time that
the last version of the patch got sent rather than anything else, so
many of the statistics aren't valid. But a _tool_ that actively
corrupts the date and time of a patch is just broken.
Linus
On Sun, Jun 9, 2013 at 8:20 PM, Linus Torvalds
<[email protected]> wrote:
>
> .. the rationale for this is that the work pattern of people is
> actually interesting information. You can do things like this:
>
> git log --pretty=%aD --author=Torvalds
Final side note: for me, and other git users that apply other peoples
patches, it's probably better to use
git log --pretty=%cD --committer=Torvalds
instead.
Interestingly, that shows a different pattern than my "authorship"
statistics, which are mainly pull requests. It turns out I commit
patches much more in the afternoon. The reason is probably simple: in
the mornings, I have pull requests waiting from overnight, so a fair
number of pull requests where I am author at 9-11. But my biggest
source of patches tends to be Andrew Morton, who sends the patches in
the afternoon, so suddenly the commit counts skew towards being
between 3pm-8pm when you take all my commits into accoint.
Doing
git log --since=6.months --pretty=%aD --grep=Signed.*Andrew.Morton
backs that up: most of the commits that have sign-offs by Andrew are
sent in the afternoon.
I just find details like that really interesting, where you can
actually mine for the workpatterns of people.
Linus
Hi Linus,
> No. The date from the email was
>
> Date: Fri, 7 Jun 2013 15:42:54 +1000
>
> and we want *that* date.
Ah, gotchya.
So, we now use the original date header (if present) in the mbox views:
$ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date
Date: Fri, 7 Jun 2013 15:42:54 +1000
... for all your data-mining needs.
Cheers,
Jeremy
On Sun, Jun 9, 2013 at 9:20 PM, Jeremy Kerr <[email protected]> wrote:
>
> So, we now use the original date header (if present) in the mbox views:
>
> $ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date
> Date: Fri, 7 Jun 2013 15:42:54 +1000
>
> ... for all your data-mining needs.
Goodie, and I see that it even works with old patches. Thanks.
Linus