diff for duplicates of <20081117.115258.227376348.davem@davemloft.net> diff --git a/a/1.txt b/N1/1.txt index 2ce1fee..b8226b8 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,4 +1,4 @@ -From: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> +From: Linus Torvalds <torvalds@linux-foundation.org> Date: Mon, 17 Nov 2008 11:48:33 -0800 (PST) > We've asked _you_ to do NMI profiling, it shouldn't be the other way diff --git a/a/content_digest b/N1/content_digest index c9e5e32..e064bb0 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,21 +1,20 @@ "ref\020081117110119.GL28786@elte.hu\0" "ref\020081117.112157.146825192.davem@davemloft.net\0" "ref\0alpine.LFD.2.00.0811171147380.18283@nehalem.linux-foundation.org\0" - "ref\0alpine.LFD.2.00.0811171147380.18283-nfNrOhbfy2R17+2ddN/4kux8cNe9sq/dYPYVAmT7z5s@public.gmane.org\0" - "From\0David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>\0" + "From\0David Miller <davem@davemloft.net>\0" "Subject\0Re: [Bug #11308] tbench regression on each kernel release from 2.6.22 -> 2.6.28\0" "Date\0Mon, 17 Nov 2008 11:52:58 -0800 (PST)\0" - "To\0torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org\0" - "Cc\0mingo-X9Un+BFzKDI@public.gmane.org" - rjw-KKrjLPT3xs0@public.gmane.org - linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - cl-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org - efault-Mmb7MZpHnFY@public.gmane.org - " a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org\0" + "To\0torvalds@linux-foundation.org\0" + "Cc\0mingo@elte.hu" + rjw@sisk.pl + linux-kernel@vger.kernel.org + kernel-testers@vger.kernel.org + cl@linux-foundation.org + efault@gmx.de + " a.p.zijlstra@chello.nl\0" "\00:1\0" "b\0" - "From: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>\n" + "From: Linus Torvalds <torvalds@linux-foundation.org>\n" "Date: Mon, 17 Nov 2008 11:48:33 -0800 (PST)\n" "\n" "> We've asked _you_ to do NMI profiling, it shouldn't be the other way \n" @@ -31,4 +30,4 @@ "It could be a sparc specific issue, because the call chain is deeper\n" and we eat a lot more register window spills onto the stack. -da3786abec7d60c8dedf64346cabaff2cce7e51121777d644f2da712f9972f63 +b1b9169a02eef6cf02946286be00b2da99c297d11ffeb3d89f47158f773c629f
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.