[PATCH 1/2] spurious check for user space address

[Luming Yu]

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-off-by: Yongkai Wu 
---
 arch/x86/mm/fault.c | 95 ++---
 1 file changed, 54 insertions(+), 41 deletions(-)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 71d4b9d4d43f..5e2a49010d87 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1004,29 +1004,7 @@ static int spurious_kernel_fault_check(unsigned long 
error_code, pte_t *pte)
return 1;
 }
 
-/*
- * Handle a spurious fault caused by a stale TLB entry.
- *
- * This allows us to lazily refresh the TLB when increasing the
- * permissions of a kernel page (RO -> RW or NX -> X).  Doing it
- * eagerly is very expensive since that implies doing a full
- * cross-processor TLB flush, even if no stale TLB entries exist
- * on other processors.
- *
- * Spurious faults may only occur if the TLB contains an entry with
- * fewer permission than the page table entry.  Non-present (P = 0)
- * and reserved bit (R = 1) faults are never spurious.
- *
- * There are no security implications to leaving a stale TLB when
- * increasing the permissions on a page.
- *
- * Returns non-zero if a spurious fault was handled, zero otherwise.
- *
- * See Intel Developer's Manual Vol 3 Section 4.10.4.3, bullet 3
- * (Optional Invalidation).
- */
-static noinline int
-spurious_kernel_fault(unsigned long error_code, unsigned long address)
+static int spurious_page_table_check(unsigned long error_code, unsigned long 
address)
 {
pgd_t *pgd;
p4d_t *p4d;
@@ -1035,19 +1013,6 @@ spurious_kernel_fault(unsigned long error_code, unsigned 
long address)
pte_t *pte;
int ret;
 
-   /*
-* Only writes to RO or instruction fetches from NX may cause
-* spurious faults.
-*
-* These could be from user or supervisor accesses but the TLB
-* is only lazily flushed after a kernel mapping protection
-* change, so user accesses are not expected to cause spurious
-* faults.
-*/
-   if (error_code != (X86_PF_WRITE | X86_PF_PROT) &&
-   error_code != (X86_PF_INSTR | X86_PF_PROT))
-   return 0;
-
pgd = init_mm.pgd + pgd_index(address);
if (!pgd_present(*pgd))
return 0;
@@ -1090,12 +1055,52 @@ spurious_kernel_fault(unsigned long error_code, 
unsigned long address)
 
return ret;
 }
+
+/*
+ * Handle a spurious fault caused by a stale TLB entry.
+ *
+ * This allows us to lazily refresh the TLB when increasing the
+ * permissions of a kernel page (RO -> RW or NX -> X).  Doing it
+ * eagerly is very expensive since that implies doing a full
+ * cross-processor TLB flush, even if no stale TLB entries exist
+ * on other processors.
+ *
+ * Spurious faults may only occur if the TLB contains an entry with
+ * fewer permission than the page table entry.  Non-present (P = 0)
+ * and reserved bit (R = 1) faults are never spurious.
+ *
+ * There are no security implications to leaving a stale TLB when
+ * increasing the permissions on a page.
+ *
+ * Returns non-zero if a spurious fault was handled, zero otherwise.
+ *
+ * See Intel Developer's Manual Vol 3 Section 4.10.4.3, bullet 3
+ * (Optional Invalidation).
+ */
+static noinline int
+spurious_kernel_fault(unsigned long error_code, unsigned long address)
+{
+   /*
+* Only writes to RO or instruction fetches from NX may cause
+* spurious faults.
+*
+* These could be from user or supervisor accesses but the TLB
+* is only lazily flushed after a kernel mapping protection
+* change, so user accesses are not expected to cause spurious
+* faults.
+*/
+   if (error_code != (X86_PF_WRITE | X86_PF_PROT) &&
+   error_code != (X86_PF_INSTR | X86_PF_PROT))
+   return 0;
+
+   return spurious_page_table_check(error_code, address);
+}
 NOKPROBE_SYMBOL(spurious_kernel_fault);
 
 int show_unhandled_signals = 1;
 
 static inline int
-access_error(unsigned long error_code, struct vm_area_struct *vma)
+access_error(unsigned long error_code, unsigned long address, struct 
vm_area_struct *vma)
 {
/* This is only called for the current mm, so: */
bool foreign = false;
@@ -1120,19 +1125,27 @@ access_error(unsigned long error_code, struct 
vm_area_struct *vma)
if (error_code & X86_PF_WRITE) {
/* write, present and write, not present: */
if (unlikely(!(vma->vm_flags & VM_WRITE)))
-   return 1;
+   goto maybe_spurious;
return 0;
}
 
/* read, present: */
if (unlikely(error_code & X86_PF_

[PATCH 2/2] spurious check tace point

[Luming Yu]

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/include/asm/trace/exceptions.h 
b/arch/x86/include/asm/trace/exceptions.h
index 69615e387973..0cae50c5fcb2 100644
--- a/arch/x86/include/asm/trace/exceptions.h
+++ b/arch/x86/include/asm/trace/exceptions.h
@@ -44,6 +44,36 @@ DEFINE_EVENT_FN(x86_exceptions, name,
\
 DEFINE_PAGE_FAULT_EVENT(page_fault_user);
 DEFINE_PAGE_FAULT_EVENT(page_fault_kernel);
 
+DECLARE_EVENT_CLASS(spurious_fault_check,
+
+   TP_PROTO(unsigned long error_code,
+   unsigned long pte),
+   TP_ARGS(error_code,
+   pte),
+   TP_STRUCT__entry(
+   __field(unsigned long, error_code)
+   __field(unsigned long, pte)
+   ),
+   TP_fast_assign(
+   __entry->error_code = error_code;
+   __entry->pte = pte;
+   ),
+   TP_printk("error_code=%lx pte=%lx",
+__entry->error_code,
+__entry->pte
+   )
+);
+
+#define DEFINE_SPURIOUS_FAULT_CHECK_EVENT(name)\
+DEFINE_EVENT_FN(spurious_fault_check, name,\
+   TP_PROTO(unsigned long error_code,  \
+unsigned long pte),\
+   TP_ARGS(error_code, pte),   \
+   trace_pagefault_reg,\
+   trace_pagefault_unreg);
+
+DEFINE_SPURIOUS_FAULT_CHECK_EVENT(spurious_fault_1_sample);
+
 #undef TRACE_INCLUDE_PATH
 #define TRACE_INCLUDE_PATH .
 #define TRACE_INCLUDE_FILE exceptions
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 5e2a49010d87..aa9bc9609c68 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1001,6 +1001,8 @@ static int spurious_kernel_fault_check(unsigned long 
error_code, pte_t *pte)
if ((error_code & X86_PF_INSTR) && !pte_exec(*pte))
return 0;
 
+   trace_spurious_fault_1_sample(error_code, (unsigned long)pte);
+
return 1;
 }
 
-- 
2.14.4

[PATCH] reorder slow clock source read for clock source watchdog

[Luming Yu]

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/clocksource.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index ffe081623aec..8ea929e50ca6 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -225,8 +225,8 @@ static void clocksource_watchdog(struct timer_list *unused)
}
 
local_irq_disable();
-   csnow = cs->read(cs);
wdnow = watchdog->read(watchdog);
+   csnow = cs->read(cs);
local_irq_enable();
 
/* Clocksource initialized ? */
-- 
2.14.4

[PATCH v1 9/9] early pt: early start intel processor trace in early boot

[Luming Yu]

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

[PATCH v1 8/9] early pt: enable cyc packet

[Luming Yu]

enable CYC packet

Signed-off-by: Luming Yu 


0008-early-pt-enable-cyc-packet.patch
Description: Binary data

[PATCH v1 7/9] early pt: enable early pt psb packet

[Luming Yu]

enable PSB packet

Signed-off-by: Luming Yu 


0007-enable-early-pt-psb-packet.patch
Description: Binary data

[PATCH v1 6/9] early pt: enable mtc freq packet

[Luming Yu]

enable mtc freq packet

Signed-off-by: Luming Yu 


0006-early-pt-enable-mtc-freq-packet.patch
Description: Binary data

[PATCH v1 5/9] early pt: basic addr pair filter support

[Luming Yu]

(addr0 && addr1)

Signed-off-by: Luming Yu 


0005-early-pt-basic-addr-pair-filter-support-addr0-addr1.patch
Description: Binary data

[PATCH v1 4/9] early pt: boot option early_pt_buf_len

[Luming Yu]

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

[PATCH v1 3/9] early pt: boot option to enable early pt

[Luming Yu]

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

[PATCH v1 2/9] early pt: kconfig disable ftrace by default

[Luming Yu]

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

[PATCH v1 1/9] early pt: Basic support for early intel processor trace

[Luming Yu]

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/x86/events/intel/early_pt.c | 337 +++
 3 files changed, 344 insertions(+)
 create mode 100644 arch/x86/events/intel/early_pt.c


0001-Basic-support-for-early-intel-processor-trace-featur.patch
Description: Binary data

[PATCH v1 0/9] early pt: intel processor trace early support

[Luming Yu]

we can use intel processor trace facility since cpu power on
so we can try this patch to do early code analysis at basic block
level.

The basic usage is as below:

#./sptdump
#./sptdecode --pt ptout.0 -e ../linux-test/vmlinux | less

   [+  10] ext4_getblk+159 -> __getblk_gfp
[+  13] __getblk_gfp+30 -> __find_get_block
[+ 112] __find_get_block+167 ->
mark_page_accessed
[+   2] __getblk_gfp+38 -> _cond_resched
[+   7] _cond_resched+16 -> rcu_all_qs
[+  35] htree_dirblock_to_tree+324 ->
__ext4_check_dir_entry
[+   8] htree_dirblock_to_tree+352 -> ext4fs_dirhash
[+  53] ext4fs_dirhash+196 -> str2hashbuf_signed
[+  18] htree_dirblock_to_tree+233 ->
ext4_htree_store_dirent
[+  18] ext4_htree_store_dirent+52 -> __kmalloc
[+  10] __kmalloc+27 -> kmalloc_slab
[+   9] __kmalloc+248 -> _cond_resched
[+   7] _cond_resched+16 -> rcu_all_qs
[+  39] __kmalloc+303 -> __memset
[+   4] __kmalloc+231 -> memcg_kmem_put_cache
[+  17] ext4_htree_store_dirent+114 -> __memcpy
[+  14] ext4_htree_store_dirent+214 ->
rb_insert_color
[+  26] htree_dirblock_to_tree+324 ->
__ext4_check_dir_entry
[+   8] htree_dirblock_to_tree+352 -> ext4fs_dirhash
[+  53] ext4fs_dirhash+196 -> str2hashbuf_signed
[+  18] htree_dirblock_to_tree+233 ->
ext4_htree_store_dirent
[+  18] ext4_htree_store_dirent+52 -> __kmalloc
[+  10] __kmalloc+27 -> kmalloc_slab
[+   9] __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 buffer size setup
  early pt basic addr pair filter support (addr0 && addr1)
  early pt basic addr pair filter support (addr0 && addr1)
  early pt enable mtc freq packet
  enable early pt psb packet
  early pt enable cyc packet
  start early intel processor trace in early boot

 arch/x86/events/Kconfig  |   6 +
 arch/x86/events/intel/Makefile   |   1 +
 arch/x86/events/intel/early_pt.c | 443 +++
 arch/x86/kernel/smpboot.c|   2 +
 init/main.c  |   2 +
 kernel/trace/Kconfig |   2 +-
 6 files changed, 455 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/events/intel/early_pt.c

--
2.7.5

[RFC patch] I don't want to play with 64bit MMIO in 32bit kernel

[Luming Yu]

hi LKML

There is an on-going development in bugzilla for a patch to move on in
another direction for people who want to play with 64bits PCI BAR on
32bit.

https://bugzilla.kernel.org/show_bug.cgi?id=88131

But I send the patch out here to solicit comments for a sable way to
play with pci devices on modern 64bit machine which usually features
64bit BAR in a stable 32bit kernel.

The patch attached forced the BAR  memory resource allocation back to
32bit adress space in acpi root bridge case, then xhci and ixgbe works
every well based on my testing. So I think it's not necessary to use
64Bit BAR in 32bit kernel for stable reason.

Thanks /l

signed-off-by：  Luming Yu 


z
Description: Binary data

[PATCH 2/2] Add RTM C intrinsics head file For new instruction

[Luming Yu]

XBEGIN, XEND, XABORT, XTEST to enable kernel to explore the value of
Restricted Transactional Memory that can be found on your haswell laptop and
following up offerings see Chapter 12.3.3 Using HLE or RTM for lock Elision
of 64-ia-32-architectures-optimization-manual.pdf July 2013

Tested-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" : "+a" (ret) :: "memory");
+   return ret;
+}
+
+static __rtm_force_inline void _xend(void)
+{
+asm volatile(".byte 0x0f,0x01,0xd5" ::: "memory");
+}
+
+static __rtm_force_inline void _xabort(const unsigned int status)
+{
+   asm volatile(".byte 0xc6,0xf8,%P0" :: "i" (status) : "memory");
+}
+
+static __rtm_force_inline int _xtest(void)
+{
+   unsigned char out;
+   asm volatile(".byte 0x0f,0x01,0xd6 ; setnz %0" : "=r" (out) :: 
"memory");
+   return out;
+}
+
+#endif
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Add HLE devl head file and several usages in kernel

[Luming Yu]

For new Instruction Prefixes XACQUIRE and XRELEASE to enable kernel to use 
the new memory model that affects the critical sections with a hope to enable 
atomic memory concurrency in the absence of data conflicts based on description
in chapter 12 of Intel SDM optimization guide. My understanding 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 Yu 
Signed-off-by: Andi Kleen 
---
 arch/x86/include/asm/alternative.h   |   3 +
 arch/x86/include/asm/atomic.h|  12 +--
 arch/x86/include/asm/hle-emulation.h | 204 +++
 3 files changed, 213 insertions(+), 6 deletions(-)
 create mode 100644 arch/x86/include/asm/hle-emulation.h

diff --git a/arch/x86/include/asm/alternative.h 
b/arch/x86/include/asm/alternative.h
index 0a3f9c9..f38cd3a 100644
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Alternative inline assembly for SMP.
@@ -37,6 +38,8 @@
"671:"
 
 #define LOCK_PREFIX LOCK_PREFIX_HERE "\n\tlock; "
+#define LOCK_PREFIXA LOCK_PREFIX_HERE __HLE_ACQUIRE "\n\tlock; "
+#define LOCK_PREFIXR LOCK_PREFIX_HERE __HLE_RELEASE "\n\tlock; "
 
 #else /* ! CONFIG_SMP */
 #define LOCK_PREFIX_HERE ""
diff --git a/arch/x86/include/asm/atomic.h b/arch/x86/include/asm/atomic.h
index b17f4f4..91d331c 100644
--- a/arch/x86/include/asm/atomic.h
+++ b/arch/x86/include/asm/atomic.h
@@ -47,7 +47,7 @@ static inline void atomic_set(atomic_t *v, int i)
  */
 static inline void atomic_add(int i, atomic_t *v)
 {
-   asm volatile(LOCK_PREFIX "addl %1,%0"
+   asm volatile(LOCK_PREFIXA "addl %1,%0"
 : "+m" (v->counter)
 : "ir" (i));
 }
@@ -61,7 +61,7 @@ static inline void atomic_add(int i, atomic_t *v)
  */
 static inline void atomic_sub(int i, atomic_t *v)
 {
-   asm volatile(LOCK_PREFIX "subl %1,%0"
+   asm volatile(LOCK_PREFIXR "subl %1,%0"
 : "+m" (v->counter)
 : "ir" (i));
 }
@@ -88,7 +88,7 @@ static inline int atomic_sub_and_test(int i, atomic_t *v)
  */
 static inline void atomic_inc(atomic_t *v)
 {
-   asm volatile(LOCK_PREFIX "incl %0"
+   asm volatile(LOCK_PREFIXA "incl %0"
 : "+m" (v->counter));
 }
 
@@ -100,7 +100,7 @@ static inline void atomic_inc(atomic_t *v)
  */
 static inline void atomic_dec(atomic_t *v)
 {
-   asm volatile(LOCK_PREFIX "decl %0"
+   asm volatile(LOCK_PREFIXR "decl %0"
 : "+m" (v->counter));
 }
 
@@ -114,7 +114,7 @@ static inline void atomic_dec(atomic_t *v)
  */
 static inline int atomic_dec_and_test(atomic_t *v)
 {
-   GEN_UNARY_RMWcc(LOCK_PREFIX "decl", v->counter, "%0", "e");
+   GEN_UNARY_RMWcc(LOCK_PREFIXR "decl", v->counter, "%0", "e");
 }
 
 /**
@@ -127,7 +127,7 @@ static inline int atomic_dec_and_test(atomic_t *v)
  */
 static inline int atomic_inc_and_test(atomic_t *v)
 {
-   GEN_UNARY_RMWcc(LOCK_PREFIX "incl", v->counter, "%0", "e");
+   GEN_UNARY_RMWcc(LOCK_PREFIXA "incl", v->counter, "%0", "e");
 }
 
 /**
diff --git a/arch/x86/include/asm/hle-emulation.h 
b/arch/x86/include/asm/hle-emulation.h
new file mode 100644
index 000..4670002
--- /dev/null
+++ b/arch/x86/include/asm/hle-emulation.h
@@ -0,0 +1,204 @@
+#ifndef _HLE_H
+#define _HLE_H 1
+
+/*
+ * Copyright (c) 2012,2013 Intel Corporation
+ * Author: Andi Kleen
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that: (1) source code distributions
+ * retain the above copyright notice and this paragraph in its entirety, (2)
+ * distributions including binary code include the above copyright notice and
+ * this paragraph in its entirety in the documentation or other materials
+ * provided with the distribution
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+/*
+  Emulation for gcc HLE intrinsics on older compilers.
+
+  gcc 4.8+ implements HLE as an additional memory ordering model for the C11+
+  atomic intrinsics.  gcc has its own flavour which are similar to C11,
+  but use a different naming convention.
+
+  We cannot directly emulate the full memory model.
+
+  So the operations are mapp

Re: [PATCH update 0/3] HW-latency: hardware latency test 0.10

[Luming Yu]

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 the TG holiday at
> your latest version.
>

if we can make the tool upstream,  probably we can ask more people to test.
But not sure if arand is interested in this work anymore although he
gave the work
detailed review back to July , thanks Arand...
To push the patch upstream, l'd like to ping you again.

But if other maintainers also interested in the feature, I'd be very
glad to work with them.

Hello Peter,  would you like to take this tool to upstream?

Regards /l
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH update 0/3] HW-latency: hardware latency test 0.10

[Luming Yu]

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 very much Jon. 2. squashed all changes against new file I added 
>> into
>> one. 3. Make it useful on non-x86.
>
> Thanks for taking this and doing the heavy lifting to get it upstream! I
> wrote the original SMI detector really for RT debug purposes as we had
> OEM systems that would generate large latencies and it was easier to
> prove the point with nice graphs showing where the BIOS was injecting
> unwanted SMIs. Glad to see the work being done to make it more generic
> in nature. Maybe I'll come back with some ARM patches ;)
>
> Actually this exercise was very informative because it has helped shape
> my input on ARMv8 designs. I'm very keen to get away from a world in
> which world+dog feature is implemented inside an SMI-like context. It
> should be done via a dedicated management processor (on-chip) instead.
>
> Jon.
>

thanks Jon,

ping Arnd,  would you take this into your tree?

The value is when the feature finally done, we can finally have a
reliable tool  to count on for automatically sorting out hardware
problems and differences that really matter to designing your software
stack on bare metal, which means a lot to many of us dedicated to
hardware development/enabling as a software engineer, especially when
you have two similar platforms and need to rule out hardware latency
that could be the root cause.. in many case, people would have to dig
into various specs and lost...

I'd be glad to do anything to push this tool into upstream.  Please
let me know your thoughts. Thanks  /l
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH update 3/3] fs: Fix crash caused by write to dummy debugfs interface like HW_latency exposed

[Luming Yu]

[  141.311906] BUG: unable to handle kernel NULL pointer dereference at 
0008
[  141.314071] IP: [] simple_attr_write+0x2c/0x100
[  141.316195] PGD c3bd7067 PUD cb41d067 PMD 0
[  141.318287] Oops:  [#1] SMP
[  141.320338] Modules linked in: hw_latency_test lockd sunrpc iptable_mangle 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack rfcomm bnep coretemp 
kvm arc4 iwldvm mac80211 snd_hda_codec_hdmi snd_hda_codec_realtek option 
usb_wwan snd_hda_intel snd_hda_codec btusb bluetooth snd_hwdep snd_seq 
snd_seq_device snd_pcm iwlwifi thinkpad_acpi cfg80211 snd_page_alloc snd_timer 
crc32c_intel snd e1000e tpm_tis ghash_clmulni_intel tpm tpm_bios soundcore 
iTCO_wdt rfkill joydev microcode i2c_i801 wmi iTCO_vendor_support mei lpc_ich 
mfd_core pcspkr uinput i915 usb_storage i2c_algo_bit uas drm_kms_helper 
sdhci_pci sdhci drm mmc_core i2c_core video
[  141.329446] CPU 2
[  141.329467] Pid: 804, comm: bash Not tainted 3.7.0-rc2+ #5 LENOVO 
232045C/232045C
[  141.333922] RIP: 0010:[]  [] 
simple_attr_write+0x2c/0x100
[  141.336173] RSP: 0018:8800cb6c3eb8  EFLAGS: 00010286
[  141.338377] RAX: 811f8f10 RBX: 8800c4549600 RCX: 8800cb6c3f50
[  141.340573] RDX: 0002 RSI: 7fcbf9ef RDI: 8800c4549600
[  141.342744] RBP: 8800cb6c3ef8 R08: 000a R09: 7fcbf9edd740
[  141.344896] R10: 0001 R11: 0246 R12: 0002
[  141.347017] R13: 7fcbf9ef R14: 8800cb6c3f50 R15: 
[  141.349115] FS:  7fcbf9edd740() GS:88011920() 
knlGS:
[  141.351209] CS:  0010 DS:  ES:  CR0: 80050033
[  141.353314] CR2: 0008 CR3: c696c000 CR4: 001407e0
[  141.355457] DR0:  DR1:  DR2: 
[  141.357590] DR3:  DR6: 0ff0 DR7: 0400
[  141.359685] Process bash (pid: 804, threadinfo 8800cb6c2000, task 
8800cb7ccd20)
[  141.361767] Stack:
[  141.363793]  8800c4549600 7fcbf9ef 8800cb6c3ef8 
8800c4549600
[  141.365864]  0002 7fcbf9ef 8800cb6c3f50 

[  141.367905]  8800cb6c3f28 811cf27f 8800c4549600 
7fcbf9ef
[  141.369924] Call Trace:
[  141.371882]  [] vfs_write+0xaf/0x190
[  141.373827]  [] sys_write+0x55/0xa0
[  141.375745]  [] system_call_fastpath+0x16/0x1b
[  141.377661] Code: 1f 44 00 00 55 48 89 e5 48 83 ec 40 48 89 5d d8 4c 89 65 
e0 4c 89 6d e8 4c 89 75 f0 4c 89 7d f8 4c 8b bf 28 01 00 00 48 89 75 c8 <49> 83 
7f 08 00 0f 84 b1 00 00 00 4d 8d 67 50 31 f6 49 89 d5 4c
[  141.382206] RIP  [] simple_attr_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
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -819,7 +819,7 @@ ssize_t simple_attr_write(struct file *file, const char 
__user *buf,
ssize_t ret;
 
attr = file->private_data;
-   if (!attr->set)
+   if (!attr || !attr->set)
return -EACCES;
 
ret = mutex_lock_interruptible(&attr->mutex);
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH update 2/3] x86: Delete too many "Fast TSC .." in dmesg from HW_latency cyclic sampling

[Luming Yu]

"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
+++ b/arch/x86/kernel/tsc.c
@@ -393,7 +393,7 @@ success:
 */
delta *= PIT_TICK_RATE;
do_div(delta, i*256*1000);
-   pr_info("Fast TSC calibration using PIT\n");
+   pr_devel("Fast TSC calibration using PIT\n");
return delta;
 }
 
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH update 1/3] HW-latency: hardware latency test 0.10

[Luming Yu]

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 exposed on bare metal or left behind by BIOS or
interfered by SMI. Currently the patch tests TSC, CPU Frequency and
RDRAND which 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/Kconfig   |   6 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/hw_latency_test.c | 939 +
 3 files changed, 946 insertions(+)
 create mode 100644 drivers/misc/hw_latency_test.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index b151b7c..a00b039 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -114,6 +114,12 @@ config IBM_ASM
  for information on the specific driver level and support statement
  for your IBM server.
 
+config HW_LATENCY_TEST
+   tristate "Testing module to detect hardware lattency and throughput"
+   depends on DEBUG_FS
+   depends on RING_BUFFER
+   default m
+
 config PHANTOM
tristate "Sensable PHANToM (PCI)"
depends on PCI
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 2129377..c195cce 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -49,3 +49,4 @@ obj-y += carma/
 obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
 obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
 obj-$(CONFIG_INTEL_MEI)+= mei/
+obj-$(CONFIG_HW_LATENCY_TEST)  += hw_latency_test.o
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
new file mode 100644
index 000..0a4d23b
--- /dev/null
+++ b/drivers/misc/hw_latency_test.c
@@ -0,0 +1,939 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define BUF_SIZE_DEFAULT   262144UL
+#define BUF_FLAGS  (RB_FL_OVERWRITE)
+#defineU64STR_SIZE 22
+#define DEBUGFS_BUF_SIZE   1024
+#define DEBUGFS_NAME_SIZE  32
+
+#defineVERSION "0.1.0"
+#define BANNER "hardware latency test"
+#define DRVNAME"hw_latency_test"
+
+#define DEFAULT_SAMPLE_WINDOW  100 
+#defineDEFAULT_SAMPLE_WIDTH50
+#defineDEFAULT_LAT_THRESHOLD   10
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Luming Yu ");
+MODULE_DESCRIPTION("A simple hardware latency test");
+MODULE_VERSION(VERSION);
+
+static int debug;
+static int enabled;
+static int threshold;
+
+module_param(debug, int, 0);
+module_param(enabled, int, 0);
+module_param(threshold, int, 0);
+
+static struct ring_buffer *ring_buffer;
+static DEFINE_MUTEX(ring_buffer_mutex);
+static unsigned long buf_size = 262144UL;
+static struct task_struct *kthread;
+
+#ifdef CONFIG_X86_64
+static u8 *__start = (u8 *)0x8800;
+static u8 *__end = (u8 *)0xc7ff;
+#else
+static u8 *__start = (u8 *)0xc000;
+static u8 *__end = (u8 *)0x;
+#endif
+
+struct sample {
+   unsigned int cpu;
+   u64 seqnum;
+   u64 duration;
+   struct timespec timestamp;
+   u64 addr;
+   u8  unit; /*0: ns 1:us*/
+   unsigned long   lost;
+};
+
+static struct data {
+   struct mutex lock;
+   u64 count;
+   u64 max_sample;
+   u64 threshold;
+
+   u64 sample_window;
+   u64 sample_width;
+
+   atomic_t sample_open;
+
+   wait_queue_head_t wq;
+} data;
+
+static ktime_t now;
+struct sample_function {
+   const char *name;
+   u8  type; /* 0=all parallel, 1=anyone, 2=all sequential*/
+   struct list_head list;
+   int (*get_sample)(void *unused);
+};
+static struct sample_function *current_sample_func = NULL;
+static LIST_HEAD(sample_function_list);
+static DEFINE_MUTEX(sample_function_mutex);
+static int sample_function_register(struct sample_function *sf);
+static struct dentry *debug_dir;
+
+static int sample_function_register(struct sample_function *sf)
+{
+   struct list_head *entry = &sample_function_list;
+   mutex_lock(&sample_function_mutex);
+   list_add(&sf->list, entry);
+   current_sample_func = sf;
+   mutex_unlock(&sample_function_mutex);
+   return 0;
+}
+
+static int __buffer_add_sample(struct sample *sample)
+{
+   return ring_buffer_write(ring_buffer,
+   sizeof(struct sample), sample);
+}
+
+static struct sample *buffer_get_sample(struct sample *sample)
+{
+   struct ring_buffer_event *e = NULL;
+   struct sample *s = NULL;
+   unsigned int cpu = 0;

[PATCH update 0/3] HW-latency: hardware latency test 0.10

[Luming Yu]

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. squashed all changes against new file I added into
one. 3. Make it useful on non-x86.

Please review and commit 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
HW_latency exposed

 arch/x86/kernel/tsc.c  |   2 +-
 drivers/misc/Kconfig   |   6 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/hw_latency_test.c | 939 +
 fs/libfs.c |   2 +-
 5 files changed, 948 insertions(+), 2 deletions(-)
 create mode 100644 drivers/misc/hw_latency_test.c

-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [headache] 3.7.0-rc2 can't handle mutt (with 3.7G mail file) +FF (4 tabs) on a 4G memory+4 core system ?

[Luming Yu]

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.
>>
>>
>> That's also pointing towards high memory pressure.
>
> watch "cat /proc/meminfo" just showed me the progress
> mutt  was creating a very large tmp file in /tmp/ until  "memfree" reached a
> watermark then failed with a message like " no space in /tmp"
>
> sounds like I can't use mutt if my mutt mail file is close to the
> physical memory
> I have when tmp-on-tmpfs is enabled..
>
> hmmmake sens? maybe we can't use tmp-on-tmpfs feature in f18
but why not having disk to backup tmpfs under memory pressure?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [headache] 3.7.0-rc2 can't handle mutt (with 3.7G mail file) +FF (4 tabs) on a 4G memory+4 core system ?

[Luming Yu]

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/meminfo" just showed me the progress
mutt  was creating a very large tmp file in /tmp/ until  "memfree" reached a
watermark then failed with a message like " no space in /tmp"

sounds like I can't use mutt if my mutt mail file is close to the
physical memory
I have when tmp-on-tmpfs is enabled..

hmmmake sens? maybe we can't use tmp-on-tmpfs feature in f18
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [headache] 3.7.0-rc2 can't handle mutt (with 3.7G mail file) +FF (4 tabs) on a 4G memory+4 core system ?

[Luming Yu]

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 noticed that I couldn't quit from mutt due to tmpfs is full.

Maybe it was just shrinking tmpfs caused problem? then I can think of
deleting tmpfs from my setup..

/l
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/3] sched: add sched_policy and it's sysfs interface

[Luming Yu]

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 be better and more intelligent.
http://thread.gmane.org/gmane.linux.kernel/1348522

Just some random thoughts, as I didn't have chance to look into the
details of that patch set yet. But to me, we need to exploit the fact
that we could automatically bind a group of tasks on minimal set of
CPUs that can provide sufficient CPU cycles that are comparable to
a"cpu- run-average" that the task group can get in pure CFS situation
in a given period, until we see more CPU is needed.Then we probably
can maintain required CPU power available to the corresponding
workload, while leaving all other CPUs into power saving mode. The
problem is historical data suggested pattern could become invalid in
future, then we need more CPUs in future..I think this is the point we
need to know before spread or not-spread decision ...if spread would
not help CPU-run-average ,we don't need waste CPU power..but I don't
know how hard it could be. But I'm pretty sure sysfs knob is harder.
:-) /l
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/13] HW-latency: hardware latency test 0.10

[Luming Yu]

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 throughput problem exposed on bare metal or left behind by BIOS or
>> interfered by SMI. Currently the patch tests TSC, CPU Frequency and
>> RDRAND which 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 +
>>  drivers/misc/Makefile  |   1 +
>>  drivers/misc/hw_latency_test.c | 833 
>> +
>>  3 files changed, 841 insertions(+)
>>  create mode 100644 drivers/misc/hw_latency_test.c
>>
>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>> index b151b7c..5ed440b 100644
>> --- a/drivers/misc/Kconfig
>> +++ b/drivers/misc/Kconfig
>> @@ -114,6 +114,13 @@ config IBM_ASM
>>   for information on the specific driver level and support statement
>>   for your IBM server.
>>
>> +config HW_LATENCY_TEST
>> +   tristate "Testing module to detect hardware lattency and throughput"
>> +   depends on DEBUG_FS
>> +   depends on RING_BUFFER
>> +   depends on X86
>> +   default m
>> +
>>  config PHANTOM
>> tristate "Sensable PHANToM (PCI)"
>> depends on PCI
>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
>> index 2129377..c195cce 100644
>> --- a/drivers/misc/Makefile
>> +++ b/drivers/misc/Makefile
>> @@ -49,3 +49,4 @@ obj-y += carma/
>>  obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
>>  obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
>>  obj-$(CONFIG_INTEL_MEI)+= mei/
>> +obj-$(CONFIG_HW_LATENCY_TEST)  += hw_latency_test.o
>> diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
>> new file mode 100644
>> index 000..2aa3a74
>> --- /dev/null
>> +++ b/drivers/misc/hw_latency_test.c
>> @@ -0,0 +1,833 @@
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define BUF_SIZE_DEFAULT   262144UL
>> +#define BUF_FLAGS  (RB_FL_OVERWRITE)
>> +#define    U64STR_SIZE 22
>> +#define DEBUGFS_BUF_SIZE   1024
>> +#define DEBUGFS_NAME_SIZE  32
>> +
>> +#defineVERSION "0.1.0"
>> +#define BANNER "hardware latency test"
>> +#define DRVNAME"hw_latency_test"
>> +
>> +#define DEFAULT_SAMPLE_WINDOW  100
>> +#defineDEFAULT_SAMPLE_WIDTH50
>> +#defineDEFAULT_LAT_THRESHOLD   10
>> +
>> +MODULE_LICENSE("GPL");
>> +MODULE_AUTHOR("Luming Yu ");
>> +MODULE_DESCRIPTION("A simple hardware latency test");
>> +MODULE_VERSION(VERSION);
>
>
> >o SNIP
>
> Ok, hopefully this is just an unintentional oversight - but I don't
> see where you are acknowledging that the original author of most of
> this code is Jon Masters. It's fine for you to work on it, but you
> have to somewhere acknowledge where it comes from.

Thanks very much for pointing it out.

I did ACK Jon Masters in the first push of this feature in July of this year.

Yes, I will add Jon Master to be the first author of the work in right
place, I will
claim secondary place for myself . :-)

>
> Thanks
>
> John
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/13] HW-latency: hardware latency test 0.10

[Luming Yu]

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 throughput problem exposed on bare metal or left behind by BIOS or
>> interfered by SMI. Currently the patch tests TSC, CPU Frequency and
>> RDRAND which 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 +
>>  drivers/misc/Makefile  |   1 +
>>  drivers/misc/hw_latency_test.c | 833 
>> +
>>  3 files changed, 841 insertions(+)
>>  create mode 100644 drivers/misc/hw_latency_test.c
>>
>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>> index b151b7c..5ed440b 100644
>> --- a/drivers/misc/Kconfig
>> +++ b/drivers/misc/Kconfig
>> @@ -114,6 +114,13 @@ config IBM_ASM
>> for information on the specific driver level and support statement
>> for your IBM server.
>>
>> +config HW_LATENCY_TEST
>> + tristate "Testing module to detect hardware lattency and throughput"
>> + depends on DEBUG_FS
>> + depends on RING_BUFFER
>> + depends on X86
>> + default m
> Is there any reason this tester couldn't easily be made to work for !x86?
>

Only problem is that I don't have platform to test.

> Also I think it would make more sense to squash all fixes, and submit fixes 
> for the things like
> '[PATCH 07/13] HW-latency: delete too many "Fast TSC calibration using PIT" 
> in cpufreq sampling'
> before the actual patch. It seems this is not necessarily a hw-latency 
> specific patch to me.

Correct. I can do that later. I don't care it's a single big patch or
a patch series. It depends on how to help maintainers who would be
interested in taking  this feature into upstream. Although I will take
all responsibility to fix all bugs coming with it and the future
enhancement of  the feature.

The biggest problem to me right now for this feature is to find it a
way into upstream. I WILL do everything necessary. One big patch
instead of 13 patches-set is fine. Making it platform neutral is fine
too as long as it's necessary to make it upstream.

>
> ~Maarten
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 02/13] HW-latency: Fix a lockdep warnning

[Luming Yu]

[  150.733088] in_atomic(): 1, irqs_disabled(): 1, pid: 19, name: migration/2
[  150.735456] INFO: lockdep is turned off.
[  150.738903] irq event stamp: 28
[  150.741255] hardirqs last  enabled at (27): [] 
_raw_spin_unlock_irq+0x30/0x50
[  150.744884] hardirqs last disabled at (28): [] 
_raw_spin_lock_irq+0x1f/0x90
[  150.748505] softirqs last  enabled at (24): [] 
__do_softirq+0x167/0x3d0
[  150.752121] softirqs last disabled at (19): [] 
call_softirq+0x1c/0x30
[  150.755709] Pid: 19, comm: migration/2 Tainted: GW3.7.0-rc2+ #2
[  150.759361] Call Trace:
[  150.762952]  [] ? print_irqtrace_events+0xd0/0xe0
[  150.766610]  [] __might_sleep+0x18c/0x250
[  150.769140]  [] mutex_lock_nested+0x40/0x390
[  150.772765]  [] ? trace_hardirqs_on+0xd/0x10
[  150.776392]  [] ? _raw_spin_unlock_irq+0x30/0x50
[  150.778899]  [] ? read_tsc+0x9/0x20
[  150.782546]  [] get_freq_sample+0x33/0xd0 [hw_latency_test]
[  150.786249]  [] stop_machine_cpu_stop+0xab/0x110
[  150.789964]  [] cpu_stopper_thread+0xd6/0x1b0
[  150.792528]  [] ? cpu_stop_queue_work+0x80/0x80
[  150.795044]  [] ? perf_event_alloc+0x5e/0x4a0
[  150.797572]  [] ? __schedule+0x442/0xa00
[  150.800079]  [] ? 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, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
index 2aa3a74..e970642 100644
--- a/drivers/misc/hw_latency_test.c
+++ b/drivers/misc/hw_latency_test.c
@@ -149,7 +149,7 @@ static int get_random_bytes_sample(void *unused)
u64 sample = 0;
int ret = 1;
 
-   buffer = kzalloc(1024, GFP_KERNEL);
+   buffer = kzalloc(1024, GFP_ATOMIC);
 
start = ktime_get();
do {
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 04/13] HW-latency: Differentiate three modes to use CPU carry out testing

[Luming Yu]

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/misc/hw_latency_test.c
index 8a8c6ba..4303644 100644
--- a/drivers/misc/hw_latency_test.c
+++ b/drivers/misc/hw_latency_test.c
@@ -47,6 +47,7 @@ static unsigned long buf_size = 262144UL;
 static struct task_struct *kthread;
 
 struct sample {
+   unsigned int cpu;
u64 seqnum;
u64 duration;
struct timespec timestamp;
@@ -70,6 +71,7 @@ static struct data {
 static ktime_t now;
 struct sample_function {
const char *name;
+   u8  type; /* 0=all parallel, 1=anyone, 2=all sequential*/
struct list_head list;
int (*get_sample)(void *unused);
 };
@@ -186,14 +188,11 @@ static int get_freq_sample(void *unused)
u32 sample = 0;
int ret = 1;
unsigned int cpu_tsc_freq;
-   static DEFINE_MUTEX(freq_pit_mutex);
 
start = ktime_get();
do {
t1 = ktime_get();
-   mutex_lock(&freq_pit_mutex);
cpu_tsc_freq = x86_platform.calibrate_tsc();
-   mutex_unlock(&freq_pit_mutex);
t2 = ktime_get();
total = ktime_to_us(ktime_sub(t2, start));
diff = abs(cpu_tsc_freq - tsc_khz);
@@ -249,23 +248,30 @@ out:
 
 struct sample_function tsc_sample = {
.name   = "tsc",
+   .type   = 0,
.get_sample = get_tsc_sample,
 };
 
 struct sample_function tsc_freq_sample = {
.name   = "freq",
+   .type   = 2,
.get_sample = get_freq_sample,
 };
 
 struct sample_function random_bytes_sample = {
.name   = "random_bytes",
+   .type   = 0,
.get_sample = get_random_bytes_sample,
 };
 
+static DECLARE_BITMAP(testing_cpu_map, NR_CPUS);
+
 static int kthread_fn(void *unused)
 {
int err = 0;
u64 interval = 0;
+   int cpu;
+   struct cpumask *testing_cpu_mask = to_cpumask(testing_cpu_map);
int (*get_sample)(void *unused);

mutex_lock(&sample_function_mutex);
@@ -274,10 +280,31 @@ static int kthread_fn(void *unused)
else
goto out;
 
+   cpumask_or(testing_cpu_mask, testing_cpu_mask, cpu_online_mask);
while (!kthread_should_stop()) {
mutex_lock(&data.lock);
-   
-   err = stop_machine(get_sample, unused, cpu_online_mask);
+
+   switch (current_sample_func->type) {
+   case 0:
+   err = stop_machine(get_sample, unused, 
testing_cpu_mask);
+   break;
+   case 1:
+   err = stop_machine(get_sample, unused, NULL);
+   break;
+   case 2:
+   for_each_cpu(cpu, cpu_online_mask) {
+   cpumask_clear(testing_cpu_mask);
+   cpumask_set_cpu(cpu, testing_cpu_mask);
+   err = stop_machine(get_sample, unused, NULL);
+   if (err)
+   break;
+   }
+   break;
+   default:
+   mutex_unlock(&data.lock);
+   goto err_out;
+   }
+
if (err) {
mutex_unlock(&data.lock);
goto err_out;
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 10/13] HW-latency: add address range for x86-32

[Luming Yu]

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/hw_latency_test.c
@@ -46,8 +46,13 @@ static DEFINE_MUTEX(ring_buffer_mutex);
 static unsigned long buf_size = 262144UL;
 static struct task_struct *kthread;
 
+#ifdef CONFIG_X86_64
 static u8 *__start = (u8 *)0x8800;
 static u8 *__end = (u8 *)0xc7ff;
+#elif CONFIG_X86_32
+static u8 *__start = (u8 *)0xc000;
+static u8 *__end = (u8 *)0x;
+#endif
 
 struct sample {
unsigned int cpu;
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 07/13] HW-latency: delete too many "Fast TSC calibration using PIT" in cpufreq sampling

[Luming Yu]

"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
+++ b/arch/x86/kernel/tsc.c
@@ -393,7 +393,7 @@ success:
 */
delta *= PIT_TICK_RATE;
do_div(delta, i*256*1000);
-   pr_info("Fast TSC calibration using PIT\n");
+   pr_devel("Fast TSC calibration using PIT\n");
return delta;
 }
 
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 13/13] HW-latency: some sample data format change

[Luming Yu]

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/drivers/misc/hw_latency_test.c
@@ -671,13 +671,15 @@ static ssize_t debug_sample_fread(struct file *filp, char 
__user *ubuf,
goto out;
}
}
+
len = snprintf(buf, sizeof(buf), "[%d]%010lu.%010lu\t%llu%2s\t[%llx]\n",
sample->cpu,
sample->timestamp.tv_sec,
sample->timestamp.tv_nsec,
sample->duration,
sample->unit ? "us":"ns",
-   sample->addr);
+   (((u64) (current_sample_func->get_sample)
+   == (u64) get_mem_sample) ? sample->addr: 0));
if (len > cnt)
goto out;
if (copy_to_user(ubuf, buf,len))
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 12/13] HW-latency: Add sample unit in sample data

[Luming Yu]

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
@@ -60,6 +60,7 @@ struct sample {
u64 duration;
struct timespec timestamp;
u64 addr;
+   u8  unit; /*0: ns 1:us*/
unsigned long   lost;
 };
 
@@ -130,7 +131,7 @@ static struct sample *buffer_get_sample(struct sample 
*sample)
return sample;
 }
 
-static int buffer_add_sample(u64 sample)
+static int buffer_add_sample(u64 sample, u8 unit)
 {
int ret = 0;
unsigned int cpu = smp_processor_id();
@@ -144,6 +145,7 @@ static int buffer_add_sample(u64 sample)
s.duration = sample;
s.timestamp = CURRENT_TIME;
s.addr = (u64) __start;
+   s.unit = unit;
ret = __buffer_add_sample(&s);
 
if (sample > data.max_sample)
@@ -184,7 +186,7 @@ static int get_random_bytes_sample(void *unused)
 
} while (total <= data.sample_width);
 
-   ret = buffer_add_sample(sample);
+   ret = buffer_add_sample(sample, 1);
 out:
kfree(buffer);
return ret;
@@ -219,7 +221,7 @@ static int get_freq_sample(void *unused)
 
} while (total <= data.sample_width);
 
-   ret = buffer_add_sample(sample);
+   ret = buffer_add_sample(sample, 1);
 out:
return ret;
 }
@@ -252,7 +254,7 @@ static int get_tsc_sample(void *unused)
 
} while (total <= data.sample_width);
 
-   ret = buffer_add_sample(sample);
+   ret = buffer_add_sample(sample, 0);
 out:
return ret;
 }
@@ -289,7 +291,7 @@ static int get_mem_sample(void *unused)
 
} while (total <= data.sample_width);
 
-   ret = buffer_add_sample(sample);
+   ret = buffer_add_sample(sample, 0);
 out:
return ret;
 }
@@ -669,11 +671,12 @@ static ssize_t debug_sample_fread(struct file *filp, char 
__user *ubuf,
goto out;
}
}
-   len = snprintf(buf, sizeof(buf), "[%d]%010lu.%010lu\t%llu\t[%llx]\n",
+   len = snprintf(buf, sizeof(buf), "[%d]%010lu.%010lu\t%llu%2s\t[%llx]\n",
sample->cpu,
sample->timestamp.tv_sec,
sample->timestamp.tv_nsec,
sample->duration,
+   sample->unit ? "us":"ns",
sample->addr);
if (len > cnt)
goto out;
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 11/13] HW-latency: fix a warnning in previous patch

[Luming Yu]

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
index 6e69d31..bcce8f4 100644
--- a/drivers/misc/hw_latency_test.c
+++ b/drivers/misc/hw_latency_test.c
@@ -49,7 +49,7 @@ static struct task_struct *kthread;
 #ifdef CONFIG_X86_64
 static u8 *__start = (u8 *)0x8800;
 static u8 *__end = (u8 *)0xc7ff;
-#elif CONFIG_X86_32
+#else
 static u8 *__start = (u8 *)0xc000;
 static u8 *__end = (u8 *)0x;
 #endif
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 08/13] HW-latency: A stupid memory scanner for raw memory latency test

[Luming Yu]

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(-)

diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
index 78436da..f47b911 100644
--- a/drivers/misc/hw_latency_test.c
+++ b/drivers/misc/hw_latency_test.c
@@ -46,11 +46,15 @@ static DEFINE_MUTEX(ring_buffer_mutex);
 static unsigned long buf_size = 262144UL;
 static struct task_struct *kthread;
 
+static u8 *__start = (u8 *)0x8800;
+static u8 *__end = (u8 *)0xc7ff;
+
 struct sample {
unsigned int cpu;
u64 seqnum;
u64 duration;
struct timespec timestamp;
+   u64 addr;
unsigned long   lost;
 };
 
@@ -134,6 +138,7 @@ static int buffer_add_sample(u64 sample)
s.seqnum = data.count;
s.duration = sample;
s.timestamp = CURRENT_TIME;
+   s.addr = (u64) __start;
ret = __buffer_add_sample(&s);
 
if (sample > data.max_sample)
@@ -247,6 +252,42 @@ out:
return ret;
 }
 
+static int get_mem_sample(void *unused)
+{
+   ktime_t start, t1, t2;
+   s64 diff, total = 0;
+   u64 sample = 0;
+   int ret = 1;
+   u8  temp;
+
+   now = start = ktime_get();
+   do {
+   t1 = now;
+   now = t2 = ktime_get();
+
+   total = ktime_to_ns(ktime_sub(t2, start));
+   temp = *__start++;
+   diff = ktime_to_ns(ktime_sub(t2, t1));
+
+   if (diff < 0) {
+   printk(KERN_ERR BANNER "time running backwards\n");
+   goto out;
+   } 
+
+   if (diff > sample)
+   sample = diff;
+
+   if (__start == __end) {
+   __start = (u8 *)0x8800;
+   printk(KERN_INFO BANNER "one pass finished, jmp to the 
beginning\n");
+   }
+
+   } while (total <= data.sample_width);
+
+   ret = buffer_add_sample(sample);
+out:
+   return ret;
+}
 
 struct sample_function tsc_sample = {
.name   = "tsc",
@@ -266,6 +307,12 @@ struct sample_function random_bytes_sample = {
.get_sample = get_random_bytes_sample,
 };
 
+struct sample_function mem_sample = {
+   .name   = "mem",
+   .type   = 1,
+   .get_sample = get_mem_sample,
+};
+
 static DECLARE_BITMAP(testing_cpu_map, NR_CPUS);
 
 static int kthread_fn(void *unused)
@@ -617,11 +664,12 @@ static ssize_t debug_sample_fread(struct file *filp, char 
__user *ubuf,
goto out;
}
}
-   len = snprintf(buf, sizeof(buf), "[%d]%010lu.%010lu\t%llu\n",
+   len = snprintf(buf, sizeof(buf), "[%d]%010lu.%010lu\t%llu\t[%llx]\n",
sample->cpu,
sample->timestamp.tv_sec,
sample->timestamp.tv_nsec,
-   sample->duration);
+   sample->duration,
+   sample->addr);
if (len > cnt)
goto out;
if (copy_to_user(ubuf, buf,len))
@@ -827,6 +875,7 @@ static int hw_test_init(void)
sample_function_register(&tsc_sample);
sample_function_register(&tsc_freq_sample);
sample_function_register(&random_bytes_sample);
+   sample_function_register(&mem_sample);
 
ret = init_stats();
if (0 != ret)
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 09/13] HW-latency: Fix unwanted crash caused by write to dummy debugfs interface

[Luming Yu]

[  141.311906] BUG: unable to handle kernel NULL pointer dereference at 
0008
[  141.314071] IP: [] simple_attr_write+0x2c/0x100
[  141.316195] PGD c3bd7067 PUD cb41d067 PMD 0
[  141.318287] Oops:  [#1] SMP
[  141.320338] Modules linked in: hw_latency_test lockd sunrpc iptable_mangle 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack rfcomm bnep coretemp 
kvm arc4 iwldvm mac80211 snd_hda_codec_hdmi snd_hda_codec_realtek option 
usb_wwan snd_hda_intel snd_hda_codec btusb bluetooth snd_hwdep snd_seq 
snd_seq_device snd_pcm iwlwifi thinkpad_acpi cfg80211 snd_page_alloc snd_timer 
crc32c_intel snd e1000e tpm_tis ghash_clmulni_intel tpm tpm_bios soundcore 
iTCO_wdt rfkill joydev microcode i2c_i801 wmi iTCO_vendor_support mei lpc_ich 
mfd_core pcspkr uinput i915 usb_storage i2c_algo_bit uas drm_kms_helper 
sdhci_pci sdhci drm mmc_core i2c_core video
[  141.329446] CPU 2
[  141.329467] Pid: 804, comm: bash Not tainted 3.7.0-rc2+ #5 LENOVO 
232045C/232045C
[  141.333922] RIP: 0010:[]  [] 
simple_attr_write+0x2c/0x100
[  141.336173] RSP: 0018:8800cb6c3eb8  EFLAGS: 00010286
[  141.338377] RAX: 811f8f10 RBX: 8800c4549600 RCX: 8800cb6c3f50
[  141.340573] RDX: 0002 RSI: 7fcbf9ef RDI: 8800c4549600
[  141.342744] RBP: 8800cb6c3ef8 R08: 000a R09: 7fcbf9edd740
[  141.344896] R10: 0001 R11: 0246 R12: 0002
[  141.347017] R13: 7fcbf9ef R14: 8800cb6c3f50 R15: 
[  141.349115] FS:  7fcbf9edd740() GS:88011920() 
knlGS:
[  141.351209] CS:  0010 DS:  ES:  CR0: 80050033
[  141.353314] CR2: 0008 CR3: c696c000 CR4: 001407e0
[  141.355457] DR0:  DR1:  DR2: 
[  141.357590] DR3:  DR6: 0ff0 DR7: 0400
[  141.359685] Process bash (pid: 804, threadinfo 8800cb6c2000, task 
8800cb7ccd20)
[  141.361767] Stack:
[  141.363793]  8800c4549600 7fcbf9ef 8800cb6c3ef8 
8800c4549600
[  141.365864]  0002 7fcbf9ef 8800cb6c3f50 

[  141.367905]  8800cb6c3f28 811cf27f 8800c4549600 
7fcbf9ef
[  141.369924] Call Trace:
[  141.371882]  [] vfs_write+0xaf/0x190
[  141.373827]  [] sys_write+0x55/0xa0
[  141.375745]  [] system_call_fastpath+0x16/0x1b
[  141.377661] Code: 1f 44 00 00 55 48 89 e5 48 83 ec 40 48 89 5d d8 4c 89 65 
e0 4c 89 6d e8 4c 89 75 f0 4c 89 7d f8 4c 8b bf 28 01 00 00 48 89 75 c8 <49> 83 
7f 08 00 0f 84 b1 00 00 00 4d 8d 67 50 31 f6 49 89 d5 4c
[  141.382206] RIP  [] simple_attr_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
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -819,7 +819,7 @@ ssize_t simple_attr_write(struct file *file, const char 
__user *buf,
ssize_t ret;
 
attr = file->private_data;
-   if (!attr->set)
+   if (!attr || !attr->set)
return -EACCES;
 
ret = mutex_lock_interruptible(&attr->mutex);
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 06/13] HW-latency: cycle through all online cpus to re-test cpufreq

[Luming Yu]

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
index 256b1c0..78436da 100644
--- a/drivers/misc/hw_latency_test.c
+++ b/drivers/misc/hw_latency_test.c
@@ -297,7 +297,7 @@ static int kthread_fn(void *unused)
for_each_cpu(cpu, cpu_online_mask) {
cpumask_clear(testing_cpu_mask);
cpumask_set_cpu(cpu, testing_cpu_mask);
-   err = stop_machine(get_sample, unused, NULL);
+   err = stop_machine(get_sample, unused, 
testing_cpu_mask);
if (err)
break;
}
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 05/13] HW-latency: Add CPU field in sample output

[Luming Yu]

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/hw_latency_test.c
+++ b/drivers/misc/hw_latency_test.c
@@ -124,11 +124,13 @@ static struct sample *buffer_get_sample(struct sample 
*sample)
 static int buffer_add_sample(u64 sample)
 {
int ret = 0;
+   unsigned int cpu = smp_processor_id();
 
if (sample > data.threshold) {
struct sample s;
 
data.count++;
+   s.cpu = cpu;
s.seqnum = data.count;
s.duration = sample;
s.timestamp = CURRENT_TIME;
@@ -615,7 +617,8 @@ static ssize_t debug_sample_fread(struct file *filp, char 
__user *ubuf,
goto out;
}
}
-   len = snprintf(buf, sizeof(buf), "%010lu.%010lu\t%llu\n",
+   len = snprintf(buf, sizeof(buf), "[%d]%010lu.%010lu\t%llu\n",
+   sample->cpu,
sample->timestamp.tv_sec,
sample->timestamp.tv_nsec,
sample->duration);
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 03/13] HW-latency: Use get_random_bytes_arch

[Luming Yu]

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 100644
--- a/drivers/misc/hw_latency_test.c
+++ b/drivers/misc/hw_latency_test.c
@@ -155,7 +155,7 @@ static int get_random_bytes_sample(void *unused)
do {
 
t1 = ktime_get();
-   get_random_bytes(buffer, 1024);
+   get_random_bytes_arch(buffer, 1024);
t2 = ktime_get();
total = ktime_to_us(ktime_sub(t2, start));
diff = ktime_to_us(ktime_sub(t2, t1));
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 01/13] HW-latency: hardware latency test 0.10

[Luming Yu]

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 exposed on bare metal or left behind by BIOS or
interfered by SMI. Currently the patch tests TSC, CPU Frequency and
RDRAND which 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 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/hw_latency_test.c | 833 +
 3 files changed, 841 insertions(+)
 create mode 100644 drivers/misc/hw_latency_test.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index b151b7c..5ed440b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -114,6 +114,13 @@ config IBM_ASM
  for information on the specific driver level and support statement
  for your IBM server.
 
+config HW_LATENCY_TEST
+   tristate "Testing module to detect hardware lattency and throughput"
+   depends on DEBUG_FS
+   depends on RING_BUFFER
+   depends on X86
+   default m
+
 config PHANTOM
tristate "Sensable PHANToM (PCI)"
depends on PCI
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 2129377..c195cce 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -49,3 +49,4 @@ obj-y += carma/
 obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
 obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
 obj-$(CONFIG_INTEL_MEI)+= mei/
+obj-$(CONFIG_HW_LATENCY_TEST)  += hw_latency_test.o
diff --git a/drivers/misc/hw_latency_test.c b/drivers/misc/hw_latency_test.c
new file mode 100644
index 000..2aa3a74
--- /dev/null
+++ b/drivers/misc/hw_latency_test.c
@@ -0,0 +1,833 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define BUF_SIZE_DEFAULT   262144UL
+#define BUF_FLAGS  (RB_FL_OVERWRITE)
+#defineU64STR_SIZE 22
+#define DEBUGFS_BUF_SIZE   1024
+#define DEBUGFS_NAME_SIZE  32
+
+#defineVERSION "0.1.0"
+#define BANNER "hardware latency test"
+#define DRVNAME"hw_latency_test"
+
+#define DEFAULT_SAMPLE_WINDOW  100 
+#defineDEFAULT_SAMPLE_WIDTH50
+#defineDEFAULT_LAT_THRESHOLD   10
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Luming Yu ");
+MODULE_DESCRIPTION("A simple hardware latency test");
+MODULE_VERSION(VERSION);
+
+static int debug;
+static int enabled;
+static int threshold;
+
+module_param(debug, int, 0);
+module_param(enabled, int, 0);
+module_param(threshold, int, 0);
+
+static struct ring_buffer *ring_buffer;
+static DEFINE_MUTEX(ring_buffer_mutex);
+static unsigned long buf_size = 262144UL;
+static struct task_struct *kthread;
+
+struct sample {
+   u64 seqnum;
+   u64 duration;
+   struct timespec timestamp;
+   unsigned long   lost;
+};
+
+static struct data {
+   struct mutex lock;
+   u64 count;
+   u64 max_sample;
+   u64 threshold;
+
+   u64 sample_window;
+   u64 sample_width;
+
+   atomic_t sample_open;
+
+   wait_queue_head_t wq;
+} data;
+
+static ktime_t now;
+struct sample_function {
+   const char *name;
+   struct list_head list;
+   int (*get_sample)(void *unused);
+};
+static struct sample_function *current_sample_func = NULL;
+static LIST_HEAD(sample_function_list);
+static DEFINE_MUTEX(sample_function_mutex);
+static int sample_function_register(struct sample_function *sf);
+static struct dentry *debug_dir;
+
+static int sample_function_register(struct sample_function *sf)
+{
+   struct list_head *entry = &sample_function_list;
+   mutex_lock(&sample_function_mutex);
+   list_add(&sf->list, entry);
+   current_sample_func = sf;
+   mutex_unlock(&sample_function_mutex);
+   return 0;
+}
+
+static int __buffer_add_sample(struct sample *sample)
+{
+   return ring_buffer_write(ring_buffer,
+   sizeof(struct sample), sample);
+}
+
+static struct sample *buffer_get_sample(struct sample *sample)
+{
+   struct ring_buffer_event *e = NULL;
+   struct sample *s = NULL;
+   unsigned int cpu = 0;
+
+   if (!sample)
+   return NULL;
+   
+   mutex_lock(&ring_buffer_mutex);
+   for_each_online_cpu(cpu) {
+   e = ring_buffer_consume(ring_buffer, cpu, NULL, &sample->lost);
+   if (e)
+   break;
+   }
+   if (e) {
+   s = ring_buffer_event_data(e);
+ 

[PATCH 00/13] A simple hardware detector for latency as well as throughtput ver 0.10

[Luming Yu]

oot@ivb hw_latency_test]# echo 1 > enable 
[root@ivb hw_latency_test]# cat sample 

[0]1352079798.011667778876ns[0]
[1]1352079798.011667778884ns[0]
[2]1352079798.011667778852ns[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-latency: Fix a lockdep warnning
  HW-latency: Use get_random_bytes_arch
  HW-latency: Differentiate three modes to use CPU carry out testing
  HW-latency: Add CPU field in sample output
  HW-latency: cycle through all online cpus to re-test cpufreq
  HW-latency: delete too many "Fast TSC calibration using PIT" in
cpufreq sampling
  HW-latency: A stupid memory scanner for raw memory latency test
  HW-latency: Fix unwanted crash caused by write to dummy debugfs
interface
  HW-latency: add address range for x86-32
  HW-latency: fix a warnning in previous patch
  HW-latency: Add sample unit in sample data
  HW-latency: some sample data format change

 arch/x86/kernel/tsc.c  |   2 +-
 drivers/misc/Kconfig   |   7 +
 drivers/misc/Makefile  |   1 +
 drivers/misc/hw_latency_test.c | 922 +
 fs/libfs.c |   2 +-
 5 files changed, 932 insertions(+), 2 deletions(-)
 create mode 100644 drivers/misc/hw_latency_test.c

-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [discussion]sched: a rough proposal to enable power saving in scheduler

[Luming Yu]

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 doesn't
>>> do C7 so never powers down the LLC.  However, as you said earlier
>>> once you can put the socket into C6 which saves about 30W compared
>>> to C1E.
>>>
>>> So as far as I can see with this CPU at least you would benefit from
>>> shutting down a whole socket when possible.
>>
>>
>> Having any active cores on the system prevents all packages from going
>> into PC6 or deeper. What I'm not clear on is whether less deep package C
>> states are also blocked.
>>
>
> Right, we need the memory controller.
>
> The E5 datasheet is a bit ambiguous, it reads:
>
>
> A processor enters the package C3 low power state when:
>  -At least one core is in the C3 state.
>  -The other cores are in a C3 or lower power state, and the processor has
> been granted permission by the platform.
>
>
> Unfortunately it doesn't specify whether that is the other cores in the
> package, or the other cores on the whole system.
>

Hardware limitations is just part of the problem. We could find them
out from various white papers or data sheets, or test out.To me, the
key problem in terms of power and performance balancing still lies in
CPU and memory allocation method.  For example, on a system we can
benefit from shutting down a whole socket when possible, if a workload
allocates 50% CPU cycles and 50% memory bandwidth and space on a two
socket system(modern), an ideal allocation method ( I assume it's our
goal of the discussion) should leave CPU, cache, memory controller and
memory on one socket ( node) completely idle and in deepest power
saving mode. But obviously, we need to spread as much as possible
across all cores in another socket(to race to idle). So from the
example above, we see a threshold that we need to reference before
selecting one from two complete different policy: spread or not
spread... As long as there is hardware limitation, we could always
need knob like that referenced threshold to adapt on different
hardware in one kernel

/l
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: CPU isolation question again

[Luming Yu]

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 Tue, Jul 3, 2012 at 7:28 PM, Frederic Weisbecker  
>> >> wrote:
>> >> > On Wed, Jun 27, 2012 at 09:22:09PM +0800, Luming Yu wrote:
>> >> >> Hi there,
>> >> >>
>> >> >> I noticed some discussion about CPU isolation which points me to the
>> >> >> patch set (https://lkml.org/lkml/2011/8/15/245). I'm currently
>> >> >> preparing a RFC-patch-set to automatically pick up a few suitable CPUs
>> >> >> to isolate then kick them out of service for a while. We need to
>> >> >> balance between  thermal & power management And overall system
>> >> >> performance during this operation as much as possible. So
>> >> >> software-cpu-online-offline interface could not be a good option to
>> >> >> me. But to make sure I'm not blindly running on a dead-end path, I'd
>> >> >> check with experts here to ensure it makes some sense to isolate CPUs
>> >> >> to this level, and the idea also makes some sense, and the most
>> >> >> important is it's not implemented yet.
>> >> >
>> >> > I don't understand what you are trying to do and how exactly. How do you
>> >> > plan to do this isolation and how do you want to balance between thermal
>> >> > and power?
>> >>
>> >> My question could be wrong as the question arose several weeks ago
>> >> when I came across
>> >>  drivers/acpi/acpi_paid.c which looks like a real user who need to
>> >> request system automatically
>> >> pick up a few CPU to get them isolated and deactivated. Later on, I
>> >> noticed tglx's cpu hot plug re-work.
>> >> I realized we could reuse the interface to do isolation and deactivation 
>> >> work.
>> >>
>> >> Of cause, to pick up which ones to isolate and deactivate is another 
>> >> problem.
>> >>
>> >> cc'ed the author and ACPI maintainer of the driver as well as tglx.
>> >
>> > May be I'm confused because we both have our own definition of isolation.
>> > I'm not sure what kind of CPU isolation you're looking for.
>>
>> At first, it needs not avaiable to scheduler.  Then, it needs in
>> deepest power saving mode.
>> At last, it needs available to scheduler again on demand.
>> Sounds very like a typical soft offline cpu, but needs to be low light 
>> weight.
>
> I see. So indeed the latest developments made in CPU hotplug could make it a 
> solution
> for you.

I hope it works as it can solve half of my question if the interface
is light enough.  Another half is about a method to tap which set of
logical processors to isolate. We could leave the question to Admin,
or we could automatically sort it out from an ordered list. Not sure
how many type of cpu set we can find from existing APIs..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch update-v1] a simple hardware detector for latency as well as throughput ver. 0.1.0

[Luming Yu]

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 understand if there is any hardware latency as well
>>> as throughput problem exposed on bare metal or left behind by BIOS or
>>> interfered by SMI. Currently the patch tests TSC, CPU Frequency, and
>>> RDRAND, which is a new CPU instruction to get random number introudced
>>> in new CPU like Intel Ivy Bridge, in stop_machine context.
>>>
>>> The tsc samples (ns) below are from a P4 system. You can change from 0
>>> to 1000 in /sys/kernel/debug/hw_atency_test/threshold to TSC sample at ms.
>>
>> typo.
>>
>> s/ms/us/
>>
>>>
>>> [root@p4 linux]# rmmod hw_latency_test
>>> [root@p4 linux]# insmod drivers/misc/hw_latency_test.ko
>>> [root@p4 linux]# echo tsc > /sys/kernel/debug/hw_latency_test/current
>>> [root@p4 linux]# echo 1 > /sys/kernel/debug/hw_latency_test/enable
>>> [root@p4 linux]# cat /sys/kernel/debug/hw_latency_test/sample
>>> 1340657264.0434121340   388
>>> 1340657264.0935125912   379
>>> 1340657265.0436123548   404
>>> 1340657265.0937122432   441
>>> 
>>> ^C
>>> [root@p4 linux]# echo 0 > /sys/kernel/debug/hw_latency_test/enable
>>>
>>> Signed-off-by: Luming  Yu 
>>> ---
>>> I will add more tests after the first patch gets merged for those guys
>>> who want to directly play with new hardware functions, and latency and
>>> bandwidth is concern, or simply out of curiosity. The patch is based on
>>> hardware latency dector written by Jcm in RT-tree. I assume I can add
>>> Jcm's signed off here.
>>>
>>>
>>>  drivers/misc/Kconfig   |7 +
>>>  drivers/misc/Makefile  |2 +
>>>  drivers/misc/hw_latency_test.c |  833 
>>> 
>>>  3 files changed, 842 insertions(+), 0 deletions(-)
>>>
>>>
>>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>>> index c779509..a5216b5 100644
>>> --- a/drivers/misc/Kconfig
>>> +++ b/drivers/misc/Kconfig
>>> @@ -123,6 +123,13 @@ config IBM_ASM
>>>  for information on the specific driver level and support statement
>>>  for your IBM server.
>>>
>>> +config HW_LATENCY_TEST
>>> +   tristate "Testing module to detect hardware lattency and throughput"
>>> +   depends on DEBUG_FS
>>> +   depends on RING_BUFFER
>>> +   depends on X86
>
> I begun the tool on X86, but bear in mind that use standard kernel interface
> as much as possible. I was trying to measure CPU Frequency, but the use of
> calibrate_tsc forced me add a X86 dependency here.
>
> Other finding is recalibrate_cpu_khz() is a null function in SMP.
> But the only two users (p4-clockmod.c and powernow-k7.c) themselves
> could lack of users roo these days.
>
> Let me know if there are any other comments.
>
> My plan for the tool is to push it in 3.6 or 3.7. So I will routinely
> get back to the thread probably weekly or bi-weekly in the time frame.
> :-)
> The 0.2 will based on what I can see in upstream of the tool.
>
> Thanks!!!

ping Arnd,  I need to a commit ID in a tree for this work. :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] ia64: remove per_cpu_offset()

[Luming Yu]

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()"
> (a875a69f8b00a38b4f40d9632a4fc71a159f0e0d),
> but ia64 doesn't have lockdep, nor does it use per_cpu_offset()
> anywhere else.
>
> This came up because Yu Lumming noticed that the ia64 version
> of per_cpu_offset() actually has a syntax error. Amusing as it seems
> to have been in the tree for months.
>
> > -#define per_cpu_offset(x) (__per_cpu_offset(x))
> > +#define per_cpu_offset(x) (__per_cpu_offset[x])
>
> Dave Miller suggested that rather than fixing the unused code it would be
> better to just remove it all together.
>
> Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
>
> diff --git a/include/asm-ia64/percpu.h b/include/asm-ia64/percpu.h
> index c4f1e32..2870f8d 100644
> --- a/include/asm-ia64/percpu.h
> +++ b/include/asm-ia64/percpu.h
> @@ -46,7 +46,6 @@
>  #ifdef CONFIG_SMP
>
>  extern unsigned long __per_cpu_offset[NR_CPUS];
> -#define per_cpu_offset(x) (__per_cpu_offset[x])
>
>  /* Equal to __per_cpu_offset[smp_processor_id()], but faster to access: */
>  DECLARE_PER_CPU(unsigned long, local_per_cpu_offset);
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
-
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/

Re: [PATCH] fix typo in per_cpu_offset

[Luming Yu]

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 Miller wrote:
> > > From: Simon Horman <[EMAIL PROTECTED]>
> > > Date: Tue, 30 Oct 2007 16:15:13 +0900
> > >
> > > > Though curiuously with my config nothing uses per_cpu_offset()
> > > > (I added a bogus call to produce an error.) Is it actually
> > > > used on ia64?
> > >
> > > It is unused, and in that regard should probably be deleted.
> > >
> > > include/asm-generic/percpu.h defines a seemingly similarly
> > > unused per_cpu_offset() macro define as well
> >
> > It looks like they were both added by "[PATCH] lockdep: add 
> > per_cpu_offset()"
> > (a875a69f8b00a38b4f40d9632a4fc71a159f0e0d)
> >
> > Perhaps they were used at that time?
>
> I looked into this a little further:
>
> I'm pretty much convinced that the asm-ia64 version of per_cpu_offset()
> is unused as ia64 doesn't have lockdep. I will send a patch to get rid
> of it. The generic version might be used on mips, sh or arm with
> CONFIG_SMP, as these architectures have lockdep. I did managed to
> produce a compiler error on mips by removing the asm-generic version of
> per_cpu_offset().
>
> --
> Horms
>   H: http://www.vergenet.net/~horms/
>   W: http://www.valinux.co.jp/en/
>
>
-
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/

[PATCH] fix typo in per_cpu_offset

[Luming Yu]

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: Yu Luming <[EMAIL PROTECTED]>


correct_per_cpu_offset.patch
Description: Binary data

[RFC patch] fallback to "no irq" hack for case of no pnp_irq allocated for 8250_pnp

[Luming Yu]

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 back to the
"no irq" hack for this case. It works for me. Please review and test.

Thanks,
Luming

Signed-off-by: Yu Luming <[EMAIL PROTECTED]>

 8250_pnp.c |3 +++
 1 files changed, 3 insertions(+)


8250_pnp.patch
Description: Binary data

Re: 2.6.22-rc4-mm1 -- x86_64 ACPI panic

[Luming Yu]

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.

http://www.ussg.iu.edu/hypermail/linux/kernel/0706.0/2509.html

On 6/7/07, Andrew Morton <[EMAIL PROTECTED]> wrote:

On Wed, 06 Jun 2007 15:00:17 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote:

> Getting this on a bigger x86_64 (bl6-13):
>
> Unable to handle kernel NULL pointer dereference at  RIP:
>  [] acpi_processor_throttling_seq_show+0xa7/0xd6
> PGD 2d77067 PUD 34c3067 PMD 0
> Oops:  [1] SMP
> CPU 3
> Modules linked in: video output button battery asus_acpi ac lp
> parport_pc parport floppy nvram amd_rng rng_core i2c_amd756 i2c_core
> Pid: 1634, comm: head Not tainted 2.6.22-rc4-mm1-autokern1 #1
> RIP: 0010:[]  []
> acpi_processor_throttling_seq_show+0xa7/0xd6
> RSP: 0018:810003c9de48  EFLAGS: 00010246
> RAX: 0020 RBX: 8100029e7800 RCX: 
> RDX: 002a RSI: 805993e4 RDI: 810002d714c0
> RBP: 810002d714c0 R08: 810003f82051 R09: 810002d714c0
> R10:  R11:  R12: 
> R13:  R14:  R15: 7fff64fd2b90
> FS:  2b3545aec6f0() GS:810001683a40() knlGS:
> CS:  0010 DS:  ES:  CR0: 8005003b
> CR2:  CR3: 03966000 CR4: 06e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: 0ff0 DR7: 0400
> Process head (pid: 1634, threadinfo 810003c9c000, task 810001c8c810)
> Stack:  00d0 810002d714c0 0001 0001
>  2000 802ab6eb 810003c9df50 810002915d00
>  810002d714f0 810002fa2000  fffb
> Call Trace:
>  [] seq_read+0x105/0x28e
>  [] seq_read+0x0/0x28e
>  [] proc_reg_read+0x80/0x9a
>  [] vfs_read+0xcb/0x153
>  [] sys_read+0x45/0x6e
>  [] system_call+0x7e/0x83
>
>
> Code: 45 8b 44 0d 00 44 89 e1 0f 45 d0 31 c0 49 ff c4 49 83 c5 28
> RIP  [] acpi_processor_throttling_seq_show+0xa7/0xd6
>  RSP 
> CR2: 
> FATAL: Error inserting acpi_cpufreq
> 
(/lib/modules/2.6.22-rc4-mm1-autokern1/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko):
> No such device

Was the oops at modprobe time?  If so, it seems weird that
acpi_processor_throttling_seq_show() would be getting run at that stage.

(The oops trace is supposed to show the oopsing process's
task_struct.comm[], but it isn't shown here?)

Anyway, there are extensive changes in there added by git-acpi.patch.  I
suppose we can try to limp along with the below, but it'll probably just
oops later on.

--- 
a/drivers/acpi/processor_throttling.c~git-acpi-disable-acpi_processor_throttling_seq_show
+++ a/drivers/acpi/processor_throttling.c
@@ -648,6 +648,9 @@ static int acpi_processor_throttling_seq
   goto end;
   }

+   seq_puts(seq, "acpi_processor_throttling_seq_show() is busted\n");
+   goto end;
+
   seq_printf(seq, "state count: %d\n"
  "active state:T%d\n"
  "state available: T%d to T%d\n",
_

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


-
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/

Re: [2.6.22-rc4-mm1] ACPI Exception (processor_throttling)

[Luming Yu]

Please test the attached patch.

Thanks,
Luming

On 6/7/07, Maciej Rutecki <[EMAIL PROTECTED]> wrote:

ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating
_PTC [20070126]
ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating
_TSS [20070126]

On 2.6.20.9 I don't have this exceptions.

Other problem:

2.6.22rc4-mm1:
rutek:/home/maciek# cat /proc/acpi/processor/CPU0/throttling
Naruszenie ochrony pamięci (segmentation fault)

compared to 2.6.20.9:
[EMAIL PROTECTED]:~$ cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state:T0
states:
   *T0:  00%
T1:  12%
T2:  25%
T3:  37%
T4:  50%
T5:  62%
T6:  75%
T7:  87%


Other info (2.6.22-rc4-mm1):
rutek:/home/maciek# ls /proc/acpi/processor/CPU0/
info  limit  power  throttling
rutek:/home/maciek# cat /proc/acpi/processor/CPU0/info
processor id:0
acpi id: 1
bus mastering control:   yes
power management:yes
throttling control:  yes
limit interface: yes
rutek:/home/maciek# cat /proc/acpi/processor/CPU0/limit
active limit:P0:T0
user limit:  P0:T0
thermal limit:   P0:T0
rutek:/home/maciek# cat /proc/acpi/processor/CPU0/power
active state:C0
max_cstate:  C8
bus master activity: 
maximum allowed latency: 8000 usec
states:
C1:  type[C1] promotion[--] demotion[--]
latency[001] usage[] duration[]
C2:  type[C2] promotion[--] demotion[--]
latency[001] usage[] duration[]

For CPU1 is similar.

config, dmesg, acpidump:
http://www.unixy.pl/maciek/download/kernel/2.6.22-rc4-mm1/

--
Maciej Rutecki
http://www.maciek.unixy.pl





t.patch
Description: Binary data

Re: [PATCH] ACPI video: Don't export sysfs backlight interface if query _BCL fail

[Luming Yu]

Ack!


On 4/27/07, Danny Kukawka <[EMAIL PROTECTED]> wrote:

Hi,

currently the acpi video module export the backlight interface to sysfs also
if acpi_video_device_lcd_query_levels() fails to read _BLC method (e.g.
because the method is not available). In this case the userspace don't know
which brightness level are supported and can't set a brightness level (echo
return with: "write error: Invalid Argument"). This happend e.g. on a ASUS
RF1 (correct supported by the asus-laptop module).

The video module should not export the backlight interface if query _BLC fail,
because you can't set anything from userspace and this make it useless.

See also: http://bugzilla.kernel.org/show_bug.cgi?id=8375

Danny

From: Danny Kukawka <[EMAIL PROTECTED]>
Subject: ACPI video: Don't export sysfs backlight interface if query _BLC fail

if qeuery _BCL fail (e.g. because the method is missing in BIOS) don't
export the backlight interface to sysfs.

Signed-off-by: Danny Kukawka <[EMAIL PROTECTED]>
---
 video.c |   78 --
 1 file changed, 41 insertions(+), 37 deletions(-)

--- linux-2.6.21/drivers/acpi/video.c   2007-04-26 13:50:51.0 +0200
+++ linux-2.6.21/drivers/acpi/video.c   2007-04-26 13:50:53.0 +0200
@@ -531,7 +531,6 @@

-
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/

Re: drivers/video/output.c

[Luming Yu]

The user of output sysfs class is coming..
Please check out the acpi video_output patch I just sent to acpi mailing list.
I can't post link here, just because It is not in archive of the ml yet..

On 4/18/07, Brown, Len <[EMAIL PROTECTED]> wrote:

>Asides from git-bisect failing me again[1], what gives with this file?

it supports output switching, which didn't make it into 2.6.21 --
probably will be 2.6.22.

-Len
-
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/


-
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/

Re: ACPI initialization failure with v2.6.21-rc4

[Luming Yu]

Do you recall which acpi enabled kernel works for you?
If never, I guess your system don't support ACPI .
If yes, this should be resolved. Please enter a acpi bug into
bugzilla.kernel.org with sufficient info : dmesg,lspci -vvx,
/proc/ioports, acpidump output... w/ acpi=off.

On 3/18/07, Johannes Weiner <[EMAIL PROTECTED]> wrote:

[resend due to wrong mail headers last time]

Hi,

The kernel version mentioned in the subject won't boot because the ACPI
system does not get initialized; the system freezes on an outb() in
acpi_os_write_port() i.e. it does not do anything anymore and just hangs.

Here is the `stack trace' I managed to extract via debugging output:

-- acpi_os_write_port(0xb2, 240, 8)
-- acpi_hw_set_mode(ACPI_SYS_MODE_ACPI)
-- acpi_enable()
-- acpi_enable_subsystem(~ACPI_NO_ACPI_ENABLE)
-- acpi_early_init()
...

Notes:
* acpi_os_write_port(): I printk'd the arguments; the port
  formatted with %#x and the value with %u.

* acpi_enable_subsystem(): I removed ACPI_NO_HARDWARE_INIT
  from the arguments because it is not used anymore.
  In this context I want to mention that it probably can be
  removed from include/acpi/actypes.h generally.

Random question:

I noticed that acpi_gbl_FADT is declared in
include/acpi/acglobal.h but where is it actually defined and
initialized?

HTH,
Hannes
-
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/


-
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/

Re: 2.6.21-rc3-mm2 hangs my opteron during bootup, ACPI?

[Luming Yu]

try acpi=off please.

On 3/12/07, Helge Hafting <[EMAIL PROTECTED]> wrote:

I went from 2.6.18-rc5-mm1 to 2.6.21-rc3-mm2
The computer now hangs solid during boot, at this point:

usb 1-1: configuration #1 chosen from 1 choice
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0
alt 0 proto 2 vid 0x04B8 pid 0x0007
usb 1-3: new high speed USB device using ehci_hcd and address 3
pc87360: PC8736x not detected, module not inserted.
md: raid1 personality registered for level 1
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
EDAC MC: Ver: 2.0.1 Sep  2 2006
sdhci: Secure Digital Host Controller Interface driver, 0.12
sdhci: Copyright(c) Pierre Ossman
wbsd: Winbond W83L51xD SD/MMC card interface driver, 1.6
wbsd: Copyright(c) Pierre Ossman
Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22
13:55:50 2006 UTC).
ACPI: PCI Interrupt :00:06.0[A] -> GSI 17 (level, low) -> IRQ 17


Here it stops with a dead keyboard.  No sysrq, it is time for the power
button.
A 2.6.18-rc5-mm1 boot continues like this:

gameport: Trident 4DWave is pci:00:06.0/gameport0, speed 1884kHz
ALSA device list:
  #0: Trident TRID4DWAVENX PCI Audio at 0x9400, irq 17
oprofile: using NMI interrupt.
Netfilter messages via NETLINK v0.30.
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
ip_conntrack version 2.4 (2043 buckets, 16344 max) - 288 bytes per conntrack
ip_tables: (C) 2000-2006 Netfilter Core Team
joydump: ,-- START .


I'll be trying 2.6.20 next, unless adviced otherwise.

Helge Hafting
-
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/


-
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/

Re: [PATCH] ATA convert GSI to irq on ia64

[Luming Yu]

sorry, it should be
#define ATA_PRIMARY_IRQ(dev)  ide_default_irq(0x1F0)

On 2/8/07, Luming Yu <[EMAIL PROTECTED]> wrote:

if use ide_default_irq , then I guess the #if defined can be removed.
#define ATA_PRIMARY_IRQ(dev)   isa_irq_to_vector(0x1F0)


On 2/8/07, Zhang, Yanmin <[EMAIL PROTECTED]> wrote:
> If an ATA drive uses legacy mode, ata driver will choose 14 and 15 as the
> fixed irq number. On ia64 platform, such numbers are GSI and should be 
converted
> to irq vector.
>
> Below patch against kernel 2.6.20 fixes it.
>
> Signed-off-by: Zhang Yanmin <[EMAIL PROTECTED]>
>
> ---
>
> diff -Nraup linux-2.6.20/include/asm-generic/libata-portmap.h 
linux-2.6.20_fix/include/asm-generic/libata-portmap.h
> --- linux-2.6.20/include/asm-generic/libata-portmap.h   2007-02-08 
15:13:44.0 +0800
> +++ linux-2.6.20_fix/include/asm-generic/libata-portmap.h   2007-02-08 
15:20:13.0 +0800
> @@ -3,10 +3,20 @@
>
>  #define ATA_PRIMARY_CMD0x1F0
>  #define ATA_PRIMARY_CTL0x3F6
> +#if defined(__ia64__)
> +#define ATA_PRIMARY_IRQ(dev)   isa_irq_to_vector(14)
> +#else
>  #define ATA_PRIMARY_IRQ(dev)   14
> +#endif
> +
>
>  #define ATA_SECONDARY_CMD  0x170
>  #define ATA_SECONDARY_CTL  0x376
> +#if defined(__ia64__)
> +#define ATA_SECONDARY_IRQ(dev) isa_irq_to_vector(15)
> +#else
>  #define ATA_SECONDARY_IRQ(dev) 15
> +#endif
> +
>
>  #endif
> -
> 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/
>


-
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/

Re: [PATCH] ATA convert GSI to irq on ia64

[Luming Yu]

if use ide_default_irq , then I guess the #if defined can be removed.
#define ATA_PRIMARY_IRQ(dev)   isa_irq_to_vector(0x1F0)


On 2/8/07, Zhang, Yanmin <[EMAIL PROTECTED]> wrote:

If an ATA drive uses legacy mode, ata driver will choose 14 and 15 as the
fixed irq number. On ia64 platform, such numbers are GSI and should be converted
to irq vector.

Below patch against kernel 2.6.20 fixes it.

Signed-off-by: Zhang Yanmin <[EMAIL PROTECTED]>

---

diff -Nraup linux-2.6.20/include/asm-generic/libata-portmap.h 
linux-2.6.20_fix/include/asm-generic/libata-portmap.h
--- linux-2.6.20/include/asm-generic/libata-portmap.h   2007-02-08 
15:13:44.0 +0800
+++ linux-2.6.20_fix/include/asm-generic/libata-portmap.h   2007-02-08 
15:20:13.0 +0800
@@ -3,10 +3,20 @@

 #define ATA_PRIMARY_CMD0x1F0
 #define ATA_PRIMARY_CTL0x3F6
+#if defined(__ia64__)
+#define ATA_PRIMARY_IRQ(dev)   isa_irq_to_vector(14)
+#else
 #define ATA_PRIMARY_IRQ(dev)   14
+#endif
+

 #define ATA_SECONDARY_CMD  0x170
 #define ATA_SECONDARY_CTL  0x376
+#if defined(__ia64__)
+#define ATA_SECONDARY_IRQ(dev) isa_irq_to_vector(15)
+#else
 #define ATA_SECONDARY_IRQ(dev) 15
+#endif
+

 #endif
-
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/


-
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/

Re: hwsusp defunct

[Luming Yu]

For acpi issues, please enter bug into bugzilla.kernel.org with dmesg,
acpidump output .


On 2/7/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:

Cc: linux-acpi
not-cc: linux-pm

Rafael J. Wysocki napsal(a):
> On Tuesday, 6 February 2007 12:18, Jiri Slaby wrote:
>> This is blindly written dmesg after resume. See it whole at [2]:
>> Suspending device 0.0
>> ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (7) is 
beyon
>> d end of object [20070126]
>> ACPI Error (psparse-0537): Method parse/execution failed 
[\_SB_.PCI0.IDE0.GTM_]
>> (Node dfe64fcc), AE_AML_PACKAGE_LIMIT
>> ACPI Error (psparse-0537): Method parse/execution failed 
[\_SB_.PCI0.IDE0.CHN0._
>> GTM] (Node dfe649f0), AE_AML_PACKAGE_LIMIT
>> ...
>> hda: selected mode 0x45
>> ACPI Error (dsopcode-0481): Attempt to CreateField of length zero [20070126]
>> ACPI Error (psparse-0537): Method parse/execution failed 
[\_SB_.PCI0.IDE0.RATA]
>> (Node dfe64ec8), AE_AML_OPERAND_VALUE
>> ACPI Error (psparse-0537): Method parse/execution failed 
[\_SB_.PCI0.IDE0.CHN0.D
>> RV1._GTF] (Node dfe64964), AE_AML_OPERAND_VALUE
>> do_drive_get_GTF: Run _GTF error: status = 0x3006
>
> This looks like an ACPI-vs-IDE problem.  You can try to use libata drivers 
instead
> of the "old IDE" ones.
>
>> $ ls -l /sys/block/hda/device
>> lrwxrwxrwx 1 root root 0 úno  6 12:14 /sys/block/hda/device ->
>> ../../devices/pci:00/:00:1f.1/ide0/0.0
>> $ ls -l /sys/block/hda/device/driver
>> lrwxrwxrwx 1 root root 0 úno  6 12:15 /sys/block/hda/device/driver ->
>> ../../../../../bus/ide/drivers/ide-disk
>> $ ls -l /sys/block/hda/device/driver/0.0
>> lrwxrwxrwx 1 root root 0 úno  6 12:16 /sys/block/hda/device/driver/0.0 ->
>> ../../../../devices/pci:00/:00:1f.1/ide0/0.0
>> # lspci -vvvxxs :00:1f.1
>> 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE 
Controller
>> (rev 02) (prog-if 8a [Master SecP PriP])
>>  Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard
>>  Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
>> Stepping- SERR- FastB2B-
>>  Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
>> SERR- >  Latency: 0
>>  Interrupt: pin A routed to IRQ 5
>>  Region 0: I/O ports at 01f0 [size=8]
>>  Region 1: I/O ports at 03f4 [size=1]
>>  Region 2: I/O ports at 0170 [size=8]
>>  Region 3: I/O ports at 0374 [size=1]
>>  Region 4: I/O ports at fc00 [size=16]
>>  Region 5: Memory at 3010 (32-bit, non-prefetchable) [size=1K]
>> 00: 86 80 db 24 07 00 80 02 02 8a 01 01 00 00 00 00
>> 10: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
>> 20: 01 fc 00 00 00 00 10 30 00 00 00 00 43 10 a6 80
>> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
>>
>> Do you want acpidump?
>
> I'm not an ACPI expert, it won't tell me a lot, but perhaps you should add
> linux-acpi to the Cc list. ;-)
[...]
 > [1]
 >   http://www.fi.muni.cz/~xslaby/sklad/config-mm
 > [2]
 >   http://www.fi.muni.cz/~xpapiez/test/dmesg-mm.txt

Ok, acpi folks, any suggests?

thanks,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
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/


-
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/

Re: 2.6.20 PCI Cannot allocate resource region 2

[Luming Yu]

none on the card, a flash or a firmware .. it has a 24c02 EEPROM for
vendor information, that's all


Ok, sounds like windows driver can fix the broken EEPROM  on you card.
Otherwise, I can not explain how windows driver can fix the problem for linux.
Anyway, this issue is NOT linux problem. right?
-
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/

Re: 2.6.20 PCI Cannot allocate resource region 2

[Luming Yu]

dang !

rebooted it into 2.6.17.7

no errors, during a bootup, BIST isn't running anymore
running M$ did change the status from dead to alive ??? shocked !!


Interesting!  does windows driver fixes the broken firmware/flash on this card?



attached lspci output in the very same setup as earlier, no difference
in anything, except that it was rebooted into windows.

the PCI config dump would help ?



I guess you would never reproduce this issue again unless you can
restore the broken firmware/flash on this card. :-)
-
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/

Re: 2.6.19.2 oops after resume from ram (corruption?)

[Luming Yu]

On 2/1/07, Mike Galbraith <[EMAIL PROTECTED]> wrote:

On Thu, 2007-02-01 at 08:42 +1100, Nigel Cunningham wrote:
> Hi.
>
> On Wed, 2007-01-31 at 11:56 +0100, Mike Galbraith wrote:
> > Greetings,
> >
> > I received the below upon first poke of firefox icon after a resume.
>
> Are you able to reproduce it reliably? Failing that, could you try
> enabling some the kernel configuration options that help with debugging
> memory corruption (slab corruption checking in particular will probably
> be the most useful thing here).

No, it's a never before seen event.  That said, I have had a couple of
dead box after resume events with other kernels in the last few months,
so I may have had corruption of a more deadly variety.  Unfortunately,
when I'm resuming, my serial console box is almost guaranteed to be off.


if you have dead serial console, or no serial console at all on you
laptop. Probably you can try the alternative of firewire with
http://www.suse.de/~bk/firewire/
Ah,  linux S3 resume is still a problem.
-
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/

Re: Timeouts on ICH7 PATA drive with ata_piix; ide_generic works perfectly

[Luming Yu]

From the dmesg, I found a problem NOT relative to the PATA driver.

I would like to know if cpu freq driver works? If not, please enter a
acpi bug on bugzilla.kernel.org.

"[   17.368000] ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT,
Index (0FFFD) is beyond end of object [20060707]
[   17.368000] ACPI Error (psparse-0537): Method parse/execution
failed [\_PR_.CPU1._PSS] (Node c1468ba8), AE_AML_PACKAGE_LIMIT
[   17.368000] ACPI Exception (acpi_processor-0235):
AE_AML_PACKAGE_LIMIT, Evaluating _PSS [20060707]
[   17.368000] ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT,
Index (0FFFD) is beyond end of object [20060707]
[   17.368000] ACPI Error (psparse-0537): Method parse/execution
failed [\_PR_.CPU2._PSS] (Node c14689f0), AE_AML_PACKAGE_LIMIT
[   17.368000] ACPI Exception (acpi_processor-0235):
AE_AML_PACKAGE_LIMIT, Evaluating _PSS [20060707]
"

On 2/4/07, Keenan Pepper <[EMAIL PROTECTED]> wrote:

I just upgraded the kernel on my System76 Gazelle laptop (basically an
ASUS Z62FP without the Microsoft tax) and the hard drive began
freezing every few minutes. I blacklisted ata_piix and the problem
went away, so that really narrows down where the bug has to be. Here's
the relevant part of the dmesg:

[  924.00] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
[  924.00] ata1.01: cmd a0/01:00:00:00:00/00:00:00:00:00/b0 tag 0
cdb 0x25 data 8 in
[  924.00]  res 40/00:03:00:00:00/00:00:00:00:00/b0 Emask
0x4 (timeout)
[  931.004000] ata1: port is slow to respond, please be patient (Status 0xd0)
[  954.028000] ata1: port failed to respond (30 secs, Status 0xd0)
[  954.028000] ata1: soft resetting port
[  954.38] ata1.00: configured for UDMA/100
[  954.56] ata1.01: configured for UDMA/33
[  954.56] ata1: EH complete

Complete dmesg and lspci -vvx are attached; please CC me because I'm
not subscribed. My sincere apologies if this is already fixed in the
main kernel.

Keenan Pepper



-
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/

Re: 2.6.20 PCI Cannot allocate resource region 2

[Luming Yu]

On 2/5/07, Manu Abraham <[EMAIL PROTECTED]> wrote:

Hi,

I get this error on booting up 2.6.20 (Similar error on 2.6.17.7 also,
the message is slightly different in 2.6.17.7)

PCI Cannot allocate resource region 2 of device :02:0a.0

Just did a search about this message around the kernel source tree.
The interesting thing is that I see the following comments at several
different arch/drivers files. Is it related to your problem?

*  Known BIOS problems we have to work around:
*  - I/O or memory regions not configured
*  - regions configured, but not enabled in the command register
*  - bogus I/O addresses above 64K used
 *  - expansion ROMs left enabled (this may sound harmless, but given
 *the fact the PCI specs explicitly allow address decoders to be
 *shared between expansion ROMs and other resource regions, it's
*at least dangerous)
-
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/

Re: kernel BUG: loading acpi_cpufreq causes segmentation fault with 2.6.20-RC7-RT3

[Luming Yu]

Please try a base kernel to verify if it is rt patch issue.

kernel BUG at drivers/acpi/osl.c:373!

I never see this before. Please post dmesg && acpidump output. (It
would be better to post them on bugzilla ). My guess is that ACPI is
just disabled. But if acpi is disabled, acpi_cpufreq module shouldn't
get installed.


On 2/2/07, Henri Hunnekens <[EMAIL PROTECTED]> wrote:

Loading the acpi_cpufreq module causes a segmentation fault with
kernel version 2.6.20-rt7-rt3.

Does anyone know how to fix this?

Henri

kernel BUG at drivers/acpi/osl.c:373!
invalid opcode:  [#1]
PREEMPT SMP
Modules linked in: acpi_cpufreq freq_table cap_over commoncap i2c_dev uhci_hcd i
2c_i801 i2c_core ehci_hcd
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010297   (2.6.20-rc7-rt3 #1)
EIP is at acpi_os_write_port+0x2d/0x36
eax: 0001   ebx: 0832   ecx: 0001   edx: 0001
esi: de561920   edi:    ebp: dd3d1c90   esp: dd3d1c8c
ds: 007b   es: 007b   ss: 0068   preempt: 0001
Process modprobe (pid: 2543, ti=dd3d task=de656660 task.ti=dd3d)
Stack:  dd3d1cf0 e0074455 0001 dd3d1ce0 c039bff2 dcf84940 
   df40d000 0001 0001 dd3d1cd0 c016612f 0002 0001 dc010832
   0001  002cc108 002cc108 c03f1302  df2d0d80 e00742d0
Call Trace:
 [] show_trace_log_lvl+0x1a/0x30
 [] show_stack_log_lvl+0xb8/0xf0
 [] show_registers+0x1e0/0x300
 [] die+0x125/0x260
 [] do_trap+0x82/0xd0
 [] do_invalid_op+0x97/0xb0
 [] error_code+0x7c/0x84
 [] acpi_cpufreq_target+0x185/0x290 [acpi_cpufreq]
 [] __cpufreq_driver_target+0x3f/0x50
 [] cpufreq_governor_performance+0x1e/0x30
 [] __cpufreq_governor+0x24/0xd0
 [] __cpufreq_set_policy+0xeb/0x140
 [] cpufreq_set_policy+0x4e/0x80
 [] cpufreq_add_dev+0x31a/0x3e0
 [] sysdev_driver_register+0x59/0xa0
 [] cpufreq_register_driver+0x67/0x100
 [] acpi_cpufreq_init+0x9d/0xa4 [acpi_cpufreq]
 [] sys_init_module+0x137/0x1b90
 [] syscall_call+0x7/0xb
 ===
Code: f9 10 89 e5 53 89 c3 89 d0 74 12 83 f9 20 74 16 83 f9 08 75 16 0f b6 c2 89
 da ee eb 12 0f b7 c2 89 da 66 ef eb 09 89 da ef eb 04 <0f> 0b eb fe 5b 31 c0 5d
 c3 55 89 e5 5d c3 55 85 c0 89 e5 89 c1
EIP: [] acpi_os_write_port+0x2d/0x36 SS:ESP 0068:dd3d1c8c
 Segmentation fault
-
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/


-
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/

Re: 2.6.20-rc6 libata PATA ATAPI CDROM is not working

[Luming Yu]

Does acpi=off make cdrom work?

On 1/27/07, Joel Soete <[EMAIL PROTECTED]> wrote:

Hello all,

I just tested libata with this newest 2.6.20-rc6 but no changes ;-(

Any news?

Thanks,
Joel

Joel Soete wrote:
> Hello Tejun,
>
> Tejun Heo wrote:
>> Joel Soete wrote:
>>> Hello Alan, Jeff,
>>>
>>> Reading a paper on this new libata, I just want to try but failled yet
>>> for what said this thread "ATAPI CDROM" ;_(.
>>>
>>> I first test the latest stable 2.6.19.1 without luck, so I also want to
>>> try latest 2.6.20-rc2 unfortunately without more success.
>>
>> I'm attaching two patches.  One against 2.6.19 the other against
>> 2.6.20-rc3.  Both have about the same effect.  Please apply and report
>> what happens and full dmesg.
>>
>> Thanks and happy new year.
>>
> Happy new year too ;-)
>
> Because of lack of time I only test your patch against 2.6.20-rc3.
>
> Unfortunately it doesn't help yet, sorry (i would very like to be of
> more help).
>
> I here attache the full dmesg of my i386 boxe.
>
> Thanks again,
> Joel
>
>
-
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/


-
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/

Re: Intel PCI-E bridge ACPI resources and possibly related SATA unstability problems on ASUS A8Js

[Luming Yu]

On 1/26/07, Martin Drab <[EMAIL PROTECTED]> wrote:

On Thu, 25 Jan 2007, Oleg Verych wrote:

> On Thu, Jan 25, 2007 at 01:28:56PM +0100, Martin Drab wrote:
> > On Thu, 25 Jan 2007, Oleg Verych wrote:
> >
> > > gmane.linux.kernel:
> > > > recently I got my hands on an ASUS A8Js notebook (Core 2 Duo T7200,
> > > > Intel 945 PM PCI-E Chipset, for details see attached log). After booting
> > > > the latest 2.6.20-rc5-git3 kernel (but the same behaviour occurs also 
with
> > > > the 2.6.19.2, didn't try any other), some strange behaviour can be
> > > > observed.
> > >
> > > There were disscussions about mmconfig and what nightmare it brought to
> > > PCI(E) configuration in scope of BIOS, chip bugs. Here's (one of) such:
> > > 
> > >
> > > > At first the following messages appear in the log:
> > > >
> > > > ...
>   [   40.303154] PCI: BIOS *Bug*: MCFG area at e000 is not 
E820-reserved
> > > > [   40.303157] PCI: Not using MMCONFIG.
> > > >
> > > > (not sure whether this is really a problem)
> > >
> > > I think it may be the major problem.
> >
> > Hmm, it may be. Was there suggested any solution (or at least proposal)
> > that I may try?
>
> Try fix BIOS bugs: 

ASUS refused to help fixing the BIOS with words that ASUS notebooks do not
support Linux. So if we do not workaround this somehow, Linux would really
be unusable on this HW. :(


Does pci=nommconf work for you. Also why not use memmap=exactmap  ...
boot command line to workaround this bios bug?
-
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/

Re: SATA ahci Bug in 2.6.19.x

[Luming Yu]

On 1/26/07, Stephen Evanchik <[EMAIL PROTECTED]> wrote:

On 1/25/07, Luming Yu <[EMAIL PROTECTED]> wrote:
> From the log:
> 2.6.18.3:
> ACPI: PCI Interrupt :00:0f.0[B] -> GSI 21 (level, low) -> IRQ 217
> 2.6.20-rc5:
> "ACPI: PCI Interrupt :00:0f.0[B] -> GSI 21 (level, low) -> IRQ 21"
>
> Sounds like acpi interrupt configure problem. Please try acpi=off first.


Still does not recognize the SATA device (and the machine fails to
come up). I tested this with 2.6.19.2, 2.6.20-rc5 and -rc6 this
evening. I am going to build a vanilla 2.6.18 and see if that still
works as I am currently running an FC5 kernel.


Is there any difference in dmesg with acpi=off?
what is your sata driver?
-
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/

Re: SATA ahci Bug in 2.6.19.x

[Luming Yu]

From the log:

2.6.18.3:
ACPI: PCI Interrupt :00:0f.0[B] -> GSI 21 (level, low) -> IRQ 217
2.6.20-rc5:
"ACPI: PCI Interrupt :00:0f.0[B] -> GSI 21 (level, low) -> IRQ 21"

Sounds like acpi interrupt configure problem. Please try acpi=off first.
-
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/

Re: IO-APIC + timer doesn't work - 2.6.20-rc5 on abit KN9-Ultra b ios 1.6

[Luming Yu]

I didn't get a chance to try the -mm patch, but booting with acpi=off
works - other than no acpi, of course :)

What now?

Well, this should be ACPI interrupt configure issue.
Please feel free to enter a bug on bugzilla.kernel.org.
And, post acpidump output, /proc/interrupts ,lspci -vvx, dmesg for
(acpi=off ) there.

Thanks,
Luming
-
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/

Re: IO-APIC + timer doesn't work - 2.6.20-rc5 on abit KN9-Ultra bios 1.6

[Luming Yu]

On 1/25/07, Eamonn Hamilton <[EMAIL PROTECTED]> wrote:

I've also just found bug #7820 on bugzilla which has a patch which may
address this issue from Ingo.

I'll give that a shot as well.



Yes, that patch workaround the problem. But it is just a workaround.
It would be much helpful to others by fixing the original problem.
-
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/

Re: IO-APIC + timer doesn't work - 2.6.20-rc5 on abit KN9-Ultra bios 1.6

[Luming Yu]

what about acpi=off?

On 1/24/07, Eamonn Hamilton <[EMAIL PROTECTED]> wrote:

Hi,

I can't get any kernel up to 2.6.20-rc5 to boot without using noapic on
an ABIT KN9-Ultra with a dual-core Athlon.

I booted with apic=debug as suggested and got the following :

ENABLING IO-APIC IRQs
.. TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1
.. MP-BIOS bug: 8254 timer not connected to IO-APIC
... trying to set up timer (IRQ0) through the 8252A ... failed
... trying to set up timer as Virtual Wire IRQ ... failed
... trying to set up timer as ExtINT IRQ ... failed :(

The bios is the latest, although in various posts on the web it would
appear this occurs in older versions also.

What can I do to help resolve this?

Cheers,
Eamonn
--
Eamonn Hamilton <[EMAIL PROTECTED]>


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-
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/


-
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/

Re: 2.6.19.2 sky2/acpi crashes

[Luming Yu]

On 1/24/07, Lionel Landwerlin <[EMAIL PROTECTED]> wrote:

Le mardi 23 janvier 2007 à 16:30 -0500, Len Brown a écrit :
> On Tuesday 23 January 2007 07:27, Lionel Landwerlin wrote:
> > Le mardi 23 janvier 2007 à 17:22 +0800, Luming Yu a écrit :
> > > Please try to remove processor module.
> >
> > Ok, that's done. Same problem.
>
> any difference with "idle=poll"?
> if yes, how about "idle=halt"?

idle=poll seems to fix the problem (cpu fan is running almost at full
speed). Maybe I should run a longer test... For now it consists to run
about 15 torrents and watching HDTV through ethernet device.

idle=halt does not :


It sounds like issues relative to Processor C state.
Please enter a bug in ACPI category on bugzilla.kernel.org
-
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/

Re: Suspend to RAM generates oops and general protection fault

[Luming Yu]

On 1/23/07, Jean-Marc Valin <[EMAIL PROTECTED]> wrote:

Luming Yu a écrit :
> what about removing psmouse module?

Trying that now. Any particular reason you suspect that one?



I suspect it is due to broken modules. If not psmouse, please trying a
boot with minimal modules loaded, and re-test .

Thanks,
Luming
-
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/

Re: 2.6.19.2 sky2/acpi crashes

[Luming Yu]

Please try to remove processor module.

On 1/23/07, Lionel Landwerlin <[EMAIL PROTECTED]> wrote:

Hi,

I'm running a macbook with a Marvell ethernet controller, and I have a
lots of freezes when using the ethernet controller under a load of
~100K/s. Since I'm running a 2.6.19.2 kernel, I'm able to get some
report from the kernel. Here they are :

Jan 23 09:30:57 cocoduo kernel: [  662.92] NETDEV WATCHDOG: eth0:
transmit timed out
Jan 23 09:30:57 cocoduo kernel: [  662.92] sky2 eth0: tx timeout
Jan 23 09:30:57 cocoduo kernel: [  662.92] sky2 eth0: transmit ring
493 .. 471 report=494 done=494
Jan 23 09:30:57 cocoduo kernel: [  662.92] sky2 status report lost?
Jan 23 09:31:06 cocoduo kernel: [  672.832000] BUG: soft lockup detected
on CPU#0!
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [softlockup_tick
+155/208] softlockup_tick+0x9b/0xd0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [update_process_times
+49/128] update_process_times+0x31/0x80
Jan 23 09:31:06 cocoduo kernel: [  672.832000]
[smp_apic_timer_interrupt+145/176] smp_apic_timer_interrupt+0x91/0xb0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [apic_timer_interrupt
+31/36] apic_timer_interrupt+0x1f/0x24
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [_spin_lock_bh+18/32]
_spin_lock_bh+0x12/0x20
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [pg0
+946878101/1068803072] sky2_tx_timeout+0xf5/0x1d0 [sky2]
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [dev_watchdog+0/208]
dev_watchdog+0x0/0xd0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [dev_watchdog+192/208]
dev_watchdog+0xc0/0xd0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [run_timer_softirq
+273/400] run_timer_softirq+0x111/0x190
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [__do_softirq+116/240]
__do_softirq+0x74/0xf0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [do_softirq+59/80]
do_softirq+0x3b/0x50
Jan 23 09:31:06 cocoduo kernel: [  672.832000]
[smp_apic_timer_interrupt+150/176] smp_apic_timer_interrupt+0x96/0xb0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [apic_timer_interrupt
+31/36] apic_timer_interrupt+0x1f/0x24
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [pg0
+943208348/1068803072] acpi_processor_idle+0x1fd/0x3b9 [processor]
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [cpu_idle+116/208]
cpu_idle+0x74/0xd0
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [start_kernel+872/1072]
start_kernel+0x368/0x430
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  [unknown_bootoption
+0/624] unknown_bootoption+0x0/0x270
Jan 23 09:31:06 cocoduo kernel: [  672.832000]  ===

As most of the time, the keyboard gets locked and the network driver is
down, I can get more informations.

Here my hardware configuration :

Apple Macbook 2GHz (x86, not amd64)
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and
945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile
945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML
Express Integrated Graphics Controller (rev 03)
00:07.0 Performance counters: Intel Corporation Unknown device 27a3 (rev
03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High
Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express
Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express
Port 2 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
#1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
#2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
#3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
#4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI
Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface
Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE
Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family)
Serial ATA Storage Controller IDE (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller
(rev 02)
01:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E
Gigabit Ethernet Controller (rev 22)
02:00.0 Ethernet controller: Atheros Communications, Inc. Unknown device
001c (rev 01)
03:03.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61)

I hope some fix could be released soon.

--
Lionel Landwerlin <[EMAIL PROTECTED]>

-
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/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the

Re: Suspend to RAM generates oops and general protection fault

[Luming Yu]

what about removing psmouse module?

On 1/23/07, Jean-Marc Valin <[EMAIL PROTECTED]> wrote:

>>> will be a device driver. Common causes of suspend/resume problems from
>>> the list you give below are acpi modules, bluetooth and usb. I'd also be
>>> consider pcmcia, drm and fuse possibilities. But again, go for unloading
>>> everything possible in the first instance.
>> Actually, the reason I sent this is that when I showed the oops/gpf to
>> Matthew Garrett at linux.conf.au, he said it looked like a CPU hotplug
>> problem and suggested I send it to lkml. BTW, with 2.6.20-rc5, the
>> suspend to RAM now works ~95% of the time.
>
> Try a kernel without CONFIG_SMP... that will verify if it is SMP
> related.

Well, this happens to be my main work machine, which I'm not willing to
have running at half speed for several weeks. Anything else you can suggest?

Jean-Marc
-
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/


-
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/

Re: BUG: linux 2.6.19 unable to enable acpi

[Luming Yu]

On 1/17/07, Matheus Izvekov <[EMAIL PROTECTED]> wrote:

On 1/17/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-01-17 at 02:01 -0200, Matheus Izvekov wrote:
> > Just tried linux for the first time on this old machine, and i got
> > this problem. dmesg below:
>
>
> did this machine EVER support acpi ?
>
>

It used to support power button events, dont know what else. Is there
anything I can do to check how good the acpi support is?


Did you check BIOS setting? Is there any ACPI related menuitems?
Does MS windows work?
Have you ever tried other kernel  i.e. 2.6.18, 2.6.17, 2.6.16..?
-
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/

Re: sonypc with Sony Vaio VGN-SZ1VP

[Luming Yu]

Luming has a sony laptop and can help with this, but
he can't be the permanent maintainer any more than I can, for the same reason.
If we can get past #1, then I recommend we apply the patch series in -mm to
the acpi-test tree and go from there.


Yes, I happen to have a sony laptop. So, I can help the permanent
maintainer of sony acpi driver on acpi related issues.
--Luming
-
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/

Re: [patch 1/5] video sysfs support - take 2: Add dev argument for backlight_device_register.

[Luming Yu]

On 12/30/06, Richard Purdie <[EMAIL PROTECTED]> wrote:

On Wed, 2006-11-08 at 00:33 +0800, Yu Luming wrote:
> This patch set adds generic abstract layer support for acpi video driver to 
have
> generic user interface to control backlight and output switch control by 
leveraging
> the existing backlight sysfs class driver, and by adding a new video output 
sysfs
> class driver.
>
> Patch 1/5:  adds dev argument for backlight_device_register to link the class 
device
> to real device object. The platform specific driver should find a way to get 
the real
> device object for their video device.
>
> signed-off-by: Luming Yu <[EMAIL PROTECTED]>
> ---
>  drivers/acpi/asus_acpi.c|2 +-
>  drivers/acpi/ibm_acpi.c |2 +-
>  drivers/acpi/toshiba_acpi.c |3 ++-
>  drivers/video/backlight/backlight.c |7 +--
>  include/linux/backlight.h   |2 +-
>  5 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c
> index 27597c5..1d97cdf 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -190,8 +190,10 @@ static int fb_notifier_callback(struct n
>   * Creates and registers new backlight class_device. Returns either an
>   * ERR_PTR() or a pointer to the newly allocated device.
>   */
> -struct backlight_device *backlight_device_register(const char *name, void 
*devdata,
> -struct backlight_properties 
*bp)
> +struct backlight_device *backlight_device_register(const char *name,
> + struct device *dev,
> + void *devdata,
> + struct backlight_properties *bp)
>  {
>   int i, rc;
>   struct backlight_device *new_bd;

This patch breaks several platforms. If you're going to add parameters
to a function like backlight_device_register, you could at least grep
the tree and update all the users :-(.


yes, you are right.  I just noticed that there are so many users when I sent
out that patch. And all these users were disabled when I was testing patch.
I'm sorry for that.



To top it off, someone noticed some of the failures and fixed them but
nobody thought to fix the drivers in drivers/video/backlight itself and
a mac reference seems to have escaped too.


If my memory serves me well,  there is a patch for mac in mm.
Not sure other drivers in video/backlight. But I should have sent it
to some place.
Need to check.



I'll send a patch to to Andrew to clean up this mess...


thank you!
-
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/

Re: 2.6.20-rc3 regression: suspend to RAM broken on Mac mini Core Duo

[Luming Yu]

> > It didn't. It looks like it is unusable, becuase it isn't reliable in
> > 2.6.20-rc3.
>
> Is this issue still present in -rc4?

I used 2.6.20-rc4 in single user mode, and applied 2 patches from
netdev to get wake on LAN support. This way I was able to set up an
automatic suspend/resume loop. It looked good, but after e.g. 20
minutes, the resume hang. So it is reproduceable with 2.6.20-rc4.
Unfortunately, I can not test the same with 2.6.18, as the wake on LAN
patches need 2.6.20-rc.


Hmm, do you mean this is the first time of this kind of testing?
Is this issue related to LAN driver?
I guess you should be able to set up an automatic suspend/resume loop
with /proc/acpi/alarm, and test similar with 2.6.18.

--Luming
-
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/

[Patch] resume PIT

[Luming Yu]

[PATCH] resume PIT for x86_64


Signed-off-by: Luming Yu <[EMAIL PROTECTED]>




diff -BruN 0/arch/x86_64/kernel/i8259.c 1/arch/x86_64/kernel/i8259.c
--- 0/arch/x86_64/kernel/i8259.c2005-03-07 23:29:42.0 +0800
+++ 1/arch/x86_64/kernel/i8259.c2005-03-09 12:53:10.0 +0800
@@ -477,6 +477,7 @@
 void call_function_interrupt(void);
 void invalidate_interrupt(void);
 void thermal_interrupt(void);
+void i8254_timer_resume(void);
 
 static void setup_timer(void)
 {
@@ -493,6 +494,11 @@
return 0;
 }
 
+void i8254_timer_resume(void)
+{
+   setup_timer();
+}
+
 static struct sysdev_class timer_sysclass = {
set_kset_name("timer"),
.resume = timer_resume,
diff -BruN 0/arch/x86_64/kernel/time.c 1/arch/x86_64/kernel/time.c
--- 0/arch/x86_64/kernel/time.c 2005-03-07 23:32:23.0 +0800
+++ 1/arch/x86_64/kernel/time.c 2005-03-09 12:53:10.0 +0800
@@ -46,7 +46,7 @@
 #ifdef CONFIG_CPU_FREQ
 static void cpufreq_delayed_get(void);
 #endif
-
+extern void i8254_timer_resume(void);
 extern int using_apic_timer;
 
 DEFINE_SPINLOCK(rtc_lock);
@@ -980,6 +980,8 @@
 
if (vxtime.hpet_address)
hpet_reenable();
+   else
+   i8254_timer_resume();
 
sec = ctime + clock_cmos_diff;
write_seqlock_irqsave(&xtime_lock,flags);


i8254.patch
Description: Binary data