we saw a suspected spurious fault that failed VMA
access check but passed spurious check for a user
space address access of (rw,execut). The patch is
trying to catch the case which might have indicated
a stale TLB (software bug found) and a harmful
spruious fault.
Signed-off-by: Luming Yu
Signed
Add a trace point for debugging spurious fault problem.
Signed-off-by: Luming Yu
Signed-off-by: Yongkai Wu
---
arch/x86/include/asm/trace/exceptions.h | 30 ++
arch/x86/mm/fault.c | 2 ++
2 files changed, 32 insertions(+)
diff --git a/arch/x86
we saw a suspected spurious fault that failed VMA
access check but passed spurious check for a user
space address access of (rw,execut). The patch is
trying to catch the case which might have indicated
a stale TLB (software bug found) and a harmful
spruious fault.
Signed-off-by: Luming Yu
Signed
Add a trace point for debugging spurious fault problem.
Signed-off-by: Luming Yu
Signed-off-by: Yongkai Wu
---
arch/x86/include/asm/trace/exceptions.h | 30 ++
arch/x86/mm/fault.c | 2 ++
2 files changed, 32 insertions(+)
diff --git a/arch/x86
the clock source watchdog (HPET) in skx is much slower
than the clock source TSC. The long latency in the first
call may trigger a false postive TSC unstable noise.
Let the fast one follows the slow one should fix it.
Signed-off-by: Luming Yu
Signed-off-by: Yongkai Wu
---
kernel/time
the clock source watchdog (HPET) in skx is much slower
than the clock source TSC. The long latency in the first
call may trigger a false postive TSC unstable noise.
Let the fast one follows the slow one should fix it.
Signed-off-by: Luming Yu
Signed-off-by: Yongkai Wu
---
kernel/time
enable intel PT to trace kernel boot && runtime
Signed-off-by: Luming Yu <luming...@intel.com>
0009-start-early-intel-processor-trace-in-early-boot.patch
Description: Binary data
enable intel PT to trace kernel boot && runtime
Signed-off-by: Luming Yu
0009-start-early-intel-processor-trace-in-early-boot.patch
Description: Binary data
enable CYC packet
Signed-off-by: Luming Yu <luming...@intel.com>
0008-early-pt-enable-cyc-packet.patch
Description: Binary data
enable CYC packet
Signed-off-by: Luming Yu
0008-early-pt-enable-cyc-packet.patch
Description: Binary data
enable PSB packet
Signed-off-by: Luming Yu <luming...@intel.com>
0007-enable-early-pt-psb-packet.patch
Description: Binary data
enable PSB packet
Signed-off-by: Luming Yu
0007-enable-early-pt-psb-packet.patch
Description: Binary data
enable mtc freq packet
Signed-off-by: Luming Yu <luming...@intel.com>
0006-early-pt-enable-mtc-freq-packet.patch
Description: Binary data
enable mtc freq packet
Signed-off-by: Luming Yu
0006-early-pt-enable-mtc-freq-packet.patch
Description: Binary data
(addr0 && addr1)
Signed-off-by: Luming Yu <luming...@intel.com>
0005-early-pt-basic-addr-pair-filter-support-addr0-addr1.patch
Description: Binary data
(addr0 && addr1)
Signed-off-by: Luming Yu
0005-early-pt-basic-addr-pair-filter-support-addr0-addr1.patch
Description: Binary data
for early pt buffer size setup
Signed-off-by: Luming Yu <luming...@intel.com>
0004-boot-option-early_pt_buf_len-for-early-pt-buffer-siz.patch
Description: Binary data
for early pt buffer size setup
Signed-off-by: Luming Yu
0004-boot-option-early_pt_buf_len-for-early-pt-buffer-siz.patch
Description: Binary data
boot option "early_pt" to enable early pt
Signed-off-by: Luming Yu <luming...@intel.com>
0003-boot-option-early_pt-to-enable-early-pt.patch
Description: Binary data
boot option "early_pt" to enable early pt
Signed-off-by: Luming Yu
0003-boot-option-early_pt-to-enable-early-pt.patch
Description: Binary data
Recommend to disable ftrace for pt by default though pt
works perfectly for tracing ftrace code
Signed-off-by: Luming Yu <luming...@intel.com>
0002-Recommend-to-disable-ftrace-for-pt-by-default.patch
Description: Binary data
Recommend to disable ftrace for pt by default though pt
works perfectly for tracing ftrace code
Signed-off-by: Luming Yu
0002-Recommend-to-disable-ftrace-for-pt-by-default.patch
Description: Binary data
with zero dependencies on other technologies in linux kernel,
1.Per cpu dump for basic block level code analysis
2.I can trace any code including myself right after it's enabled
Signed-off-by: Luming Yu <luming...@intel.com>
---
arch/x86/events/Kconfig | 6 +
arch/x86/events
with zero dependencies on other technologies in linux kernel,
1.Per cpu dump for basic block level code analysis
2.I can trace any code including myself right after it's enabled
Signed-off-by: Luming Yu
---
arch/x86/events/Kconfig | 6 +
arch/x86/events/intel/Makefile | 1 +
arch
__kmalloc+248 -> _cond_resched
The patch borrows some idea/code and tools from Andi Kleen's
simple-pt project.
Luming Yu(9):
Basic support for early intel processor trace features with zero deps
boot option early_pt to enable early pt
boot option early_pt_buf_len for early pt buf
__kmalloc+248 -> _cond_resched
The patch borrows some idea/code and tools from Andi Kleen's
simple-pt project.
Luming Yu(9):
Basic support for early intel processor trace features with zero deps
boot option early_pt to enable early pt
boot option early_pt_buf_len for early pt buf
BAR in 32bit kernel for stable reason.
Thanks /l
signed-off-by： Luming Yu
z
Description: Binary data
BAR in 32bit kernel for stable reason.
Thanks /l
signed-off-by： Luming Yu luming...@intel.com
z
Description: Binary data
-by: Luming Yu
Signed-off-by: Luming Yu
Signed-off-by: Andi Kleen > 24) & 0xff)
+
+#define __rtm_force_inline __attribute__((__always_inline__)) inline
+
+static __rtm_force_inline int _xbegin(void)
+{
+ int ret = _XBEGIN_STARTED;
+ asm volatile(".byte 0xc7,0xf8 ; .long 0&
-by: Luming Yu luming...@intel.com
Signed-off-by: Luming Yu luming...@intel.com
Signed-off-by: Andi Kleen a...@linux.intel.com
---
arch/x86/include/asm/rtm.h | 58 ++
1 file changed, 58 insertions(+)
create mode 100644 arch/x86/include/asm/rtm.h
diff --git
is that it can
give your atomic operations some certian of relif from strictly sequentially
consistent atomic semantics to acquire-release model in terms of happens-before
semantic that only applies to the dependent variables.
see gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync
Signed-off-by: Luming
is that it can
give your atomic operations some certian of relif from strictly sequentially
consistent atomic semantics to acquire-release model in terms of happens-before
semantic that only applies to the dependent variables.
see gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync
Signed-off-by: Luming
On Mon, Nov 19, 2012 at 3:30 PM, Jon Masters wrote:
> On 11/18/2012 04:30 AM, Luming Yu wrote:
>
>> I'd be glad to do anything to push this tool into upstream. Please
>> let me know your thoughts. Thanks /l
>
> I'm also happy to help test. I'll take a look over
On Mon, Nov 19, 2012 at 3:30 PM, Jon Masters j...@redhat.com wrote:
On 11/18/2012 04:30 AM, Luming Yu wrote:
I'd be glad to do anything to push this tool into upstream. Please
let me know your thoughts. Thanks /l
I'm also happy to help test. I'll take a look over the TG holiday
On Mon, Nov 12, 2012 at 12:13 PM, Jon Masters wrote:
> On 11/10/2012 09:48 PM, Luming Yu wrote:
>
>> Update the previous patch series to ACK all comments I've recevied so far
>> for the tool: e.g. 1.Acked Jon Masters in source code as many code are from
>> jcm, thanks ve
On Mon, Nov 12, 2012 at 12:13 PM, Jon Masters j...@redhat.com wrote:
On 11/10/2012 09:48 PM, Luming Yu wrote:
Update the previous patch series to ACK all comments I've recevied so far
for the tool: e.g. 1.Acked Jon Masters in source code as many code are from
jcm, thanks very much Jon. 2
_write+0x2c/0x100
[ 141.384326] RSP
[ 141.386401] CR2: 0008
[ 141.388548] ---[ end trace 9c28eee46fcb7871 ]---
Signed-off-by: Luming Yu
---
fs/libfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/libfs.c b/fs/libfs.c
index 7cc37ca..bc51574 100644
--
"Fast TSC calibration using PIT" should be a devel info.
Signed-off-by: Luming Yu
---
arch/x86/kernel/tsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index cfa5d4f..7765546 100644
--- a/arch/x86/kernel/tsc.c
+++
is a new CPU instruction to get random number introduced in
new CPU like Intel Ivy Bridge in stop_machine context,which is choosen to
make sure testers fully control their system under test to rule out some
level of unwanted noise.
Signed-off-by: Jon Masters
Signed-off-by: Luming Yu
---
drivers/misc
to misc tree. I will update the patch series if anyone
has anymore comments.
Thanks very much!!!
Luming Yu (3):
HW-latency: hardware latency test 0.10
x86: Delete too many "Fast TSC .." in dmesg from HW_latency cyclic
sampling
fs: Fix crash caused by write to dummy debugfs inte
to misc tree. I will update the patch series if anyone
has anymore comments.
Thanks very much!!!
Luming Yu (3):
HW-latency: hardware latency test 0.10
x86: Delete too many Fast TSC .. in dmesg from HW_latency cyclic
sampling
fs: Fix crash caused by write to dummy debugfs interface like
is a new CPU instruction to get random number introduced in
new CPU like Intel Ivy Bridge in stop_machine context,which is choosen to
make sure testers fully control their system under test to rule out some
level of unwanted noise.
Signed-off-by: Jon Masters j...@redhat.com
Signed-off-by: Luming Yu
Fast TSC calibration using PIT should be a devel info.
Signed-off-by: Luming Yu luming...@intel.com
---
arch/x86/kernel/tsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index cfa5d4f..7765546 100644
--- a/arch/x86/kernel
08 00 0f 84 b1 00 00 00 4d 8d 67 50 31 f6 49 89 d5 4c
[ 141.382206] RIP [811f8f3c] simple_attr_write+0x2c/0x100
[ 141.384326] RSP 8800cb6c3eb8
[ 141.386401] CR2: 0008
[ 141.388548] ---[ end trace 9c28eee46fcb7871 ]---
Signed-off-by: Luming Yu luming...@intel.com
On Thu, Nov 8, 2012 at 9:00 AM, Luming Yu wrote:
> On Thu, Nov 8, 2012 at 8:34 AM, Ortwin Glück wrote:
>>
>>
>> On 08.11.2012 14:28, Luming Yu wrote:
>>>
>>> As I just noticed that I couldn't quit from mutt due to tmpfs is full.
>>
>>
&
On Thu, Nov 8, 2012 at 8:34 AM, Ortwin Glück wrote:
>
>
> On 08.11.2012 14:28, Luming Yu wrote:
>>
>> As I just noticed that I couldn't quit from mutt due to tmpfs is full.
>
>
> That's also pointing towards high memory pressure.
watch "cat /proc/meminf
On Thu, Nov 8, 2012 at 7:09 AM, Ortwin Glück wrote:
> To me this looks like an issue with swap. Can you try without swap
> (swapoff)?
Not sure but my random guess is it could be related to a small tmpfs
in my setting
tmpfs1869900 240 1869660 1% /tmp
As I just
On Thu, Nov 8, 2012 at 7:09 AM, Ortwin Glück o...@odi.ch wrote:
To me this looks like an issue with swap. Can you try without swap
(swapoff)?
Not sure but my random guess is it could be related to a small tmpfs
in my setting
tmpfs1869900 240 1869660 1% /tmp
As
On Thu, Nov 8, 2012 at 8:34 AM, Ortwin Glück o...@odi.ch wrote:
On 08.11.2012 14:28, Luming Yu wrote:
As I just noticed that I couldn't quit from mutt due to tmpfs is full.
That's also pointing towards high memory pressure.
watch cat /proc/meminfo just showed me the progress
mutt
On Thu, Nov 8, 2012 at 9:00 AM, Luming Yu luming...@gmail.com wrote:
On Thu, Nov 8, 2012 at 8:34 AM, Ortwin Glück o...@odi.ch wrote:
On 08.11.2012 14:28, Luming Yu wrote:
As I just noticed that I couldn't quit from mutt due to tmpfs is full.
That's also pointing towards high memory
On Tue, Nov 6, 2012 at 8:09 AM, Alex Shi wrote:
> This patch add the power aware scheduler knob into sysfs:
The problem is user doesn't know how to use this knob.
Based on what data, people could select one policy which could be surely
better than another?
"Packing small tasks" approach could
On Tue, Nov 6, 2012 at 8:09 AM, Alex Shi alex@intel.com wrote:
This patch add the power aware scheduler knob into sysfs:
The problem is user doesn't know how to use this knob.
Based on what data, people could select one policy which could be surely
better than another?
Packing small tasks
On Sun, Nov 4, 2012 at 4:23 PM, John Kacur wrote:
> On Mon, Nov 5, 2012 at 2:59 AM, Luming Yu wrote:
>>
>> This patch is the first step to test some basic hardware functions like
>> TSC to help people understand if there is any hardware latency as well
>> as through
On Sun, Nov 4, 2012 at 4:07 PM, Maarten Lankhorst
wrote:
> Hey,
>
> Op 05-11-12 02:59, Luming Yu schreef:
>> This patch is the first step to test some basic hardware functions like
>> TSC to help people understand if there is any hardware latency as well
>> as through
On Sun, Nov 4, 2012 at 4:07 PM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
Hey,
Op 05-11-12 02:59, Luming Yu schreef:
This patch is the first step to test some basic hardware functions like
TSC to help people understand if there is any hardware latency as well
as throughput problem
On Sun, Nov 4, 2012 at 4:23 PM, John Kacur jka...@redhat.com wrote:
On Mon, Nov 5, 2012 at 2:59 AM, Luming Yu luming...@gmail.com wrote:
This patch is the first step to test some basic hardware functions like
TSC to help people understand if there is any hardware latency as well
as throughput
] [] ? stop_machine_cpu_stop+0x110/0x110
[ 150.802512] [] kthread+0xed/0x100
[ 150.805825] [] ? flush_kthread_worker+0x190/0x190
[ 150.808051] [] ret_from_fork+0x7c/0xb0
[ 150.810161] [] ? flush_kthread_worker+0x190/0x190
Signed-off-by: Luming Yu
---
drivers/misc/hw_latency_test.c | 2 +-
1 file changed
0: all online cpus
1: any one of online cpus
2: all online cpus sequentially run test
Signed-off-by: Luming Yu
---
drivers/misc/hw_latency_test.c | 37 -
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/hw_latency_test.c b/drivers
Add address range for x86-32
Signed-off-by: Luming Yu
---
drivers/misc/hw_latency_test.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
index f47b911..6e69d31 100644
--- a/drivers/misc/hw_latency_test.c
+++ b/drivers/misc
"Fast TSC calibration using PIT" should be a devel info.
Signed-off-by: Luming Yu
---
arch/x86/kernel/tsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index cfa5d4f..7765546 100644
--- a/arch/x86/kernel/tsc.c
+++
some trival format changes
Signed-off-by: Luming Yu
---
drivers/misc/hw_latency_test.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
index 0b79b5e..549ea13 100644
--- a/drivers/misc/hw_latency_test.c
+++ b
ns and us
Signed-off-by: Luming Yu
---
drivers/misc/hw_latency_test.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
index bcce8f4..0b79b5e 100644
--- a/drivers/misc/hw_latency_test.c
+++ b
drivers/misc/hw_latency_test.c:52:7: warning: "CONFIG_X86_32" is not defined
[-Wundef]
Signed-off-by: Luming Yu
---
drivers/misc/hw_latency_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
ind
It's simple memory latency test without any consideration of memory
hierarchy and memory model. It just does simply scan byte by byte.
Signed-off-by: Luming Yu
---
drivers/misc/hw_latency_test.c | 53 --
1 file changed, 51 insertions(+), 2 deletions
_write+0x2c/0x100
[ 141.384326] RSP
[ 141.386401] CR2: 0008
[ 141.388548] ---[ end trace 9c28eee46fcb7871 ]---
Signed-off-by: Luming Yu
---
fs/libfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/libfs.c b/fs/libfs.c
index 7cc37ca..bc51574 100644
--
Fix a typo to enable cycling through all online cpus to get cpufreq
sample from all cpus sequentially.
Signed-off-by: Luming Yu
---
drivers/misc/hw_latency_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
The filed tells user the sample is from which cpu.
Signed-off-by: Luming Yu
---
drivers/misc/hw_latency_test.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
index 4303644..256b1c0 100644
--- a/drivers/misc
To test rdrand on CPU like Ivy Bridget, we need feature aware random function.
Signed-off-by: Luming Yu
---
drivers/misc/hw_latency_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
index e970642..8a8c6ba
is a new CPU instruction to get random number introduced in
new CPU like Intel Ivy Bridge in stop_machine context,which is choosen to
make sure testers fully control their system under test to rule out some
level of unwanted noise.
Signed-off-by: Luming Yu
---
drivers/misc/Kconfig | 7
67778876ns[0]
[1]1352079798.011667778884ns[0]
[2]1352079798.011667778852ns[0]
[3]1352079798.011667778852ns[0]
[0]1352079798.061767781489ns[0]
[1]1352079798.061767781484ns[0]
[2]1352079798.0617677814 74ns[0]
[3]1352079798.
52ns[0]
[3]1352079798.011667778852ns[0]
[0]1352079798.061767781489ns[0]
[1]1352079798.061767781484ns[0]
[2]1352079798.061767781474ns[0]
[3]1352079798.061767781461ns[0]
^C
Luming Yu (13):
HW-latency: hardware latency test 0.10
HW
is a new CPU instruction to get random number introduced in
new CPU like Intel Ivy Bridge in stop_machine context,which is choosen to
make sure testers fully control their system under test to rule out some
level of unwanted noise.
Signed-off-by: Luming Yu luming...@intel.com
---
drivers/misc/Kconfig
To test rdrand on CPU like Ivy Bridget, we need feature aware random function.
Signed-off-by: Luming Yu luming...@intel.com
---
drivers/misc/hw_latency_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
index
The filed tells user the sample is from which cpu.
Signed-off-by: Luming Yu luming...@intel.com
---
drivers/misc/hw_latency_test.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
index 4303644..256b1c0 100644
Fix a typo to enable cycling through all online cpus to get cpufreq
sample from all cpus sequentially.
Signed-off-by: Luming Yu luming...@intel.com
---
drivers/misc/hw_latency_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc
It's simple memory latency test without any consideration of memory
hierarchy and memory model. It just does simply scan byte by byte.
Signed-off-by: Luming Yu luming...@intel.com
---
drivers/misc/hw_latency_test.c | 53 --
1 file changed, 51 insertions
08 00 0f 84 b1 00 00 00 4d 8d 67 50 31 f6 49 89 d5 4c
[ 141.382206] RIP [811f8f3c] simple_attr_write+0x2c/0x100
[ 141.384326] RSP 8800cb6c3eb8
[ 141.386401] CR2: 0008
[ 141.388548] ---[ end trace 9c28eee46fcb7871 ]---
Signed-off-by: Luming Yu luming...@intel.com
drivers/misc/hw_latency_test.c:52:7: warning: CONFIG_X86_32 is not defined
[-Wundef]
Signed-off-by: Luming Yu luming...@intel.com
---
drivers/misc/hw_latency_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc
ns and us
Signed-off-by: Luming Yu luming...@intel.com
---
drivers/misc/hw_latency_test.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
index bcce8f4..0b79b5e 100644
--- a/drivers/misc
some trival format changes
Signed-off-by: Luming Yu luming...@intel.com
---
drivers/misc/hw_latency_test.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
index 0b79b5e..549ea13 100644
--- a/drivers/misc
Add address range for x86-32
Signed-off-by: Luming Yu luming...@intel.com
---
drivers/misc/hw_latency_test.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
index f47b911..6e69d31 100644
--- a/drivers/misc/hw_latency_test.c
Fast TSC calibration using PIT should be a devel info.
Signed-off-by: Luming Yu luming...@intel.com
---
arch/x86/kernel/tsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index cfa5d4f..7765546 100644
--- a/arch/x86/kernel
0: all online cpus
1: any one of online cpus
2: all online cpus sequentially run test
Signed-off-by: Luming Yu luming...@intel.com
---
drivers/misc/hw_latency_test.c | 37 -
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/misc
[ 150.802512] [810938fd] kthread+0xed/0x100
[ 150.805825] [81093810] ? flush_kthread_worker+0x190/0x190
[ 150.808051] [816f00ec] ret_from_fork+0x7c/0xb0
[ 150.810161] [81093810] ? flush_kthread_worker+0x190/0x190
Signed-off-by: Luming Yu luming...@intel.com
On Sat, Aug 18, 2012 at 4:16 AM, Chris Friesen
wrote:
> On 08/17/2012 01:50 PM, Matthew Garrett wrote:
>>
>> On Fri, Aug 17, 2012 at 01:45:09PM -0600, Chris Friesen wrote:
>>>
>>> On 08/17/2012 12:47 PM, Matthew Garrett wrote:
>>
>>
>>> The datasheet for the Xeon E5 (my variant at least) says it
On Sat, Aug 18, 2012 at 4:16 AM, Chris Friesen
chris.frie...@genband.com wrote:
On 08/17/2012 01:50 PM, Matthew Garrett wrote:
On Fri, Aug 17, 2012 at 01:45:09PM -0600, Chris Friesen wrote:
On 08/17/2012 12:47 PM, Matthew Garrett wrote:
The datasheet for the Xeon E5 (my variant at least)
On Wed, Jul 4, 2012 at 10:36 AM, Frederic Weisbecker wrote:
> On Wed, Jul 04, 2012 at 10:12:43PM +0800, Luming Yu wrote:
>> On Wed, Jul 4, 2012 at 9:25 PM, Frederic Weisbecker
>> wrote:
>> > On Wed, Jul 04, 2012 at 08:42:29PM +0800, Luming Yu wrote:
>> >
On Wed, Jul 4, 2012 at 10:36 AM, Frederic Weisbecker fweis...@gmail.com wrote:
On Wed, Jul 04, 2012 at 10:12:43PM +0800, Luming Yu wrote:
On Wed, Jul 4, 2012 at 9:25 PM, Frederic Weisbecker fweis...@gmail.com
wrote:
On Wed, Jul 04, 2012 at 08:42:29PM +0800, Luming Yu wrote:
On Tue, Jul 3
On Wed, Jun 27, 2012 at 11:00 PM, Luming Yu wrote:
> On Mon, Jun 25, 2012 at 9:37 PM, Luming Yu wrote:
>> On Tue, Jun 26, 2012 at 5:23 AM, Luming Yu wrote:
>>> The patch is the fist step to test some basic hardware functions like
>>> TSC to help people understa
On Wed, Jun 27, 2012 at 11:00 PM, Luming Yu luming...@gmail.com wrote:
On Mon, Jun 25, 2012 at 9:37 PM, Luming Yu luming...@gmail.com wrote:
On Tue, Jun 26, 2012 at 5:23 AM, Luming Yu luming...@gmail.com wrote:
The patch is the fist step to test some basic hardware functions like
TSC to help
NAK for now.
I'm trying to add lockdep , so please don't delete it until it could
be proved really useless...
Please don't hurry...
On 11/7/07, Simon Horman <[EMAIL PROTECTED]> wrote:
> per_cpu_offset() was added as part of a lockdep patch,
> "[PATCH] lockdep: add per_cpu_offset()"
>
NAK for now.
I'm trying to add lockdep , so please don't delete it until it could
be proved really useless...
Please don't hurry...
On 11/7/07, Simon Horman <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 30, 2007 at 05:50:56PM +0900, Simon Horman wrote:
> > On Tue, Oct 30, 2007 at 12:36:22AM -0700,
NAK for now.
I'm trying to add lockdep , so please don't delete it until it could
be proved really useless...
Please don't hurry...
On 11/7/07, Simon Horman [EMAIL PROTECTED] wrote:
On Tue, Oct 30, 2007 at 05:50:56PM +0900, Simon Horman wrote:
On Tue, Oct 30, 2007 at 12:36:22AM -0700, David
NAK for now.
I'm trying to add lockdep , so please don't delete it until it could
be proved really useless...
Please don't hurry...
On 11/7/07, Simon Horman [EMAIL PROTECTED] wrote:
per_cpu_offset() was added as part of a lockdep patch,
[PATCH] lockdep: add per_cpu_offset()
Hello list,
there is a typo in the definition of per_cpu_offset because, for ia64,
the __per_cpu_offset is an array.
extern unsigned long __per_cpu_offset[NR_CPUS];
-#define per_cpu_offset(x) (__per_cpu_offset(x))
+#define per_cpu_offset(x) (__per_cpu_offset[x])
Thanks,
Luming
Signed-off-by:
Hello list,
there is a typo in the definition of per_cpu_offset because, for ia64,
the __per_cpu_offset is an array.
extern unsigned long __per_cpu_offset[NR_CPUS];
-#define per_cpu_offset(x) (__per_cpu_offset(x))
+#define per_cpu_offset(x) (__per_cpu_offset[x])
Thanks,
Luming
Signed-off-by:
Hello list,
There is a "ttyS1 irq is -1" problem observed on tiger4 which cause
the serial port broken.
It is because that there is __no__ ACPI IRQ resource assigned for the
serial port. So the value of the IRQ for the port is never changed
since it got initialized to -1. The attached patch falls
Hello list,
There is a ttyS1 irq is -1 problem observed on tiger4 which cause
the serial port broken.
It is because that there is __no__ ACPI IRQ resource assigned for the
serial port. So the value of the IRQ for the port is never changed
since it got initialized to -1. The attached patch falls
The only problem known as to the acpi throttling changes in the mm tree
is a typo ,and the patch to fix it is available here. Please test and
get results back to me. BTW,the log shows that the acpi-cpufreq.ko has
problem. Would please also try not to load acpi-cpufreq.
The only problem known as to the acpi throttling changes in the mm tree
is a typo ,and the patch to fix it is available here. Please test and
get results back to me. BTW,the log shows that the acpi-cpufreq.ko has
problem. Would please also try not to load acpi-cpufreq.
1 - 100 of 160 matches
Mail list logo
